أدى مارس 2024 إلى إعادة صياغة اقتصاديات الطبقة الثانية (Layer-2) إلى الأبد. فقبل ترقية Dencun، كانت شبكات الرول أب مثل Arbitrum أو Optimism تستنزف ميزانيات الفرق التقنية لمجرد ضغط بيانات calldata على الشبكة الرئيسية (Mainnet). وكانت العقود الذكية في إيثريوم تسجل مصفوفة البايتات هذه في الحالة العامة (Global State) بشكل دائم، مما فرض على كل مُحقق (Validator) تخزينها للأبد. وقد كان ذلك يستحوذ على ما يصل إلى تسعين بالمائة من تكاليف مستخدمي L2.
لقد كسر معيار EIP-4844 هذه المعادلّة من خلال تقديم معاملات النوع الثالث والـ Blobs. لكن وراء الأرقام البراقة التي تتحدث عن خفض الرسوم بنتائج تتراوح بين 10 إلى 50 مرة، تختبئ مجموعة ضخمة من التفاصيل الهندسية الدقيقة التي عادةً ما يتغاضى عنها المسوقون.
كيف يعمل الـ Blob على مستوى الذاكرة والإجماع
الـ Blob ليس مجرد ملف يُرسل إلى البلوكتشين، بل هو مصفوفة بيانات معزولة بحجم دقيق يبلغ 131,072 بايت (128 كيلوبايت)، وتعيش بشكل موازٍ لتنفيذ آلة إيثريوم الافتراضية (EVM). لا تستطيع العقود الذكية في إيثريوم قراءة محتوى الـ Blob داخل استدعاء CALL أو STATICCALL، بل تمتلك إمكانية الوصول إلى بايت كود واحد فقط، وهو أمر تشغيلي (Opcode) خاص يسمى BLOBHASH، والذي يُرجع إصدار وهاش الالتزام (Commitment Hash).
- حجم البلوك: الهدف هو 3 Blobs (حوالي 384 كيلوبايت)، والحد الأقصى في وقت الذروة هو 6 Blobs (حوالي 768 كيلوبايت).
- دورة الحياة: حوالي 4096 حقبة (Epochs)، أي ما يقارب 18 يوماً، وبعدها تقوم عقد الإجماع بتنظيف البيانات من الأقراص الصلبة.
- عزل الميمبول (Mempool): لا تدور الـ Blobs في ميمبول التنفيذ العادي، بل تمتلك ميمبول خاص بها على مستوى عملاء الإجماع (P2P blob pool)، مما يحمي طوابير المعاملات الرئيسية من الحمل الزائد (Overload).
المعلمة | الـ calldata الكلاسيكي | بلوب EIP-4844 (Type 3)
أين تُحفظ البيانات: في حالة EVM الدائمة | في ميمبول P2P المؤقت للإجماع
فترة الاحتفاظ: للأبد | ~18 يوماً
الوصول من EVM: مباشر (عبر قراءة البايتات) | غير مباشر (فقط عبر الهاش و KZG)
التسعير: غاز تنفيذ مشترك | سوق غاز بلوب مستقل (EIP-1559)
الميزات الخفية والفخاخ المعمارية لتقنية proto-danksharding
قليلون هم من يركزون على كيفية عمل تسعير غاز الـ Blobs. فعلى عكس الغاز القياسي الذي يقفز مع كل هزة بسيطة في عالم الـ DeFi، يُدار سوق الـ Blobs بواسطة خوارزمية تصحيح مستقلة. فإذا قامت شبكات الرول أب بملء الفتحات متجاوزة الهدف المحدد بثلاثة Blobs، يبدأ السعر في الارتفاع بشكل أسي. وإذا ظلت الفتحات فارغة، يهبط السعر إلى الحد الأدنى. وعملياً، يؤدي هذا إلى وضع يصبح فيه إرسال Blob في ساعات الهدوء مكلفاً بجزء مجهري من السنت، بينما قد يرتفع السعر مئات المرات بشكل أسرع مقارنة بطبقة التنفيذ في لحظات الازدحام الشديد على الشبكة.
نقطة دقيقة أخرى تتمثل في التحقق التشفيري عبر التزامات KZG (اختصاراً لـ Kate-Zaverucha-Goldberg). إذ لا يحتاج المُحققون إلى تحميل جميع ال128 كيلوبايت للتأكد من صحة البيانات، بل يكفيهم التحقق من متعددة حدود (Polynomial) بحجم 48 بايت فقط. هذا يقلل من متطلبات المعالجة الخاصة بالمُحققين، ولكنه يلقي بالعبء كاملاً على نطاق ترددي الشبكة (Network Bandwidth).
أين ترمي بالبيانات "المزعجة" عملياً
تجعل الطبيعة المؤقتة للـ Blobs منها حاوية مثالية للبيانات التي لا تحتاج إلى سجلات محاسبية أبدية، ولكنها تتطلب ثباتاً تشفيرياً لفترة تحقق قصيرة:
- تفريغات الأوراكل والمقاييس الخام: مصفوفات بيانات وسيطة يتم توقيعها من قبل المزودين قبل تجميعها في العقد الذكي.
- لقطات حالة L3 وعوالم الألعاب: تغييرات الحالة (Delta states) التي يكفي إثبات صحتها للأسبوع الماضي فقط.
- سجلات تدقيق الباك إند (Backend audit logs): حزم المعاملات أو الإيصالات التي يجب أن تكون قابلة للتحقق علنياً، ولكنها تفقد قيمتها التشغيلية بعد شهر.
يتطلب إرسال الأحمال إلى الـ Blob عبر سكربتات بايثون باستخدام مكتبة web3.py حزمة منفصلة لتغليف البايتات داخل متعددات حدود وتوليد هاش إصدار مسبوق بـ 0x01. أي حساب خاطئ لمعلمة maxFeePerBlobGas وقت الإرسال يضمن تعليق المعاملة في الميمبول للأبد.
النظريات والاقتصاد يبدوان واضحين، ولكن كيف يبدو التعامل مع الـ Blobs على مستوى الكود؟ استخدام استدعاء send_transaction التقليدي سيؤدي إلى حدوث خطأ، لأن معاملات النوع الثالث تتطلب إعداد التزامات KZG يدوياً، وتوليد البراهين (Proofs)، وحساب حد غاز منفصل.
إرسال معاملة Type-3 باستخدام بايثون (Python)
إليك نموذج عملي لإرسال Blob باستخدام المكتبات الحديثة للتفاعل مع العقد (Geth أو Reth) التي تدعم ترقية Dencun:
import os
from eth_account import Account
from web3 import Web3
w3 = Web3(Web3.HTTPProvider("http://127.0.0.1:8545"))
key = os.environ["OPERATOR_KEY"]
acct = Account.from_key(key)
FE_COUNT, FE_PAYLOAD = 4096, 31 # 31 بايت من البيانات لكل عنصر حقل
def encode_blob(data: bytes) -> bytes:
data = len(data).to_bytes(4, "big") + data
if len(data) > FE_COUNT * FE_PAYLOAD:
raise ValueError("الحمولة (payload) لا تتسع في بلوب واحد")
data = data.ljust(FE_COUNT * FE_PAYLOAD, b"\x00")
# البايت الأكثر أهمية لكل عنصر = 0 لضمان أن القيمة أقل من معامل BLS
return b"".join(b"\x00" + data[i:i + FE_PAYLOAD]
for i in range(0, len(data), FE_PAYLOAD))
blob = encode_blob(b"EXMON Infrastructure DA Payload: batch #98412")
# سعر غاز البلوب الحالي مع هامش أمان للاستجابة لأي ارتفاع
blob_base_fee = int(w3.provider.make_request("eth_blobBaseFee", [])["result"], 16)
base_fee = w3.eth.get_block("latest")["baseFeePerGas"]
tx = {
"type": 3,
"chainId": w3.eth.chain_id,
"nonce": w3.eth.get_transaction_count(acct.address),
"gas": 21000,
"maxPriorityFeePerGas": w3.to_wei(1, "gwei"),
"maxFeePerGas": base_fee * 2 + w3.to_wei(1, "gwei"),
"maxFeePerBlobGas": max(blob_base_fee * 2, w3.to_wei(1, "gwei")),
"to": acct.address, # ليس إنشاء عقد: حقل `to` إجباري لمعاملات الـ blob
"value": 0,
"data": b"",
}
# ckzg يحسب الالتزام، البراهين، والهاش الإصداري؛ ويتم دمج الـ sidecar في المعاملة الخام raw tx
signed = Account.sign_transaction(tx, key, blobs=[blob])
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
print(f"تم إرسال معاملة الـ Blob بنجاح: {tx_hash.to_0x_hex()}")إذا لم تأخذ بعين الاعتبار تقلبات maxFeePerBlobGas، فستتعرض معاملتك للاستقرار المعلق (العلق) في ميمبول الإجماع أثناء لحظات الذروة وازدحام الرول أب، وذلك إلى أن تهدأ السوق.
معضلة العقد الأرشيفية (Archive Nodes): أين تذهب البيانات بعد 18 يوماً؟
الفخ الرئيسي عند تصميم هندسة معمارية تعتمد على الـ Blobs يتعلق بعملية حذفها. فعقد الإجماع تحافظ على محتويات الـ Blobs لمدة لا تقل عن 4096 حقبة (ما يقارب 18 يوماً)، ثم تقوم بحذفها. المعاملة نفسها والتزام KZG يبقيان على البلوكتشين إلى الأبد، ولكن يستحيل استرجاع محتوى الـ Blob الأصلي من خلالهما. إذا احتجت بعد شهر لاسترجاع بيانات الـ Blob، فستعيد لك العقدة القياسية (Standard node) رسالة خطأ.
الفرق التقنية التي تبني منتجاتها فوق EIP-4844 مجبرة على حل هذه المشكلة بواحدة من الطرق الثلاث التالية:
- جامعو الأرشيف الخاصين (Custom Archive Scrapers): إطلاق خدمات خلفية (Background services) تسحب الـ Blobs من شبكة P2P فور ظهورها وتخزينها في التخزين البارد (S3-compatible buckets).
- الأرشيف اللامركزي: استخدام شبكات مثل Celestia أو Avail أو The Graph للتخزين طويل الأجل لتوفر البيانات (Data Availability).
- التخلي عن التاريخ العميق: الاحتفاظ بالفهارس المحلية فقط خلال نافذة الأسبوعين النشطة، وإسقاط المجاميع القديمة بشكل مضغوط.
ممارسات EXMON: تحسين كفاءة التخزين
في بنية EXMON التحتية، نستخدم مساحات الـ Blobs المؤقتة لنقل سجلات المعاملات الوسيطة الثقيلة، والتفريغات الخدمية (Service dumps)، ولقطات التحقق (Verification snapshots).
هذا يتيح لنا حل مشكلتين رئيسيتين دفعة واحدة:
- توفير الميزانية: انخفضت تكاليف نشر البيانات بنسبة هائلة (بمقدار عدة مراتب) مقارنة بالطرق القديمة المعتمدة على calldata.
- نقاء البلوكتشين: لا تتكدس الحالة العامة للشبكة بالنفايات التي تفقد أهميتها بعد أسبوع، مع الحفاظ في نفس الوقت على إمكانية التحقق التشفيري بنسبة مئة بالمئة طوال فترة دورة حياة البيانات.
