मार्च 2024 ने लेयर-2 इकोनॉमिक्स को हमेशा के लिए बदल दिया। Dencun से पहले, Arbitrum या Optimism जैसे रोलअप्स मेननेट पर calldata पुश करने में ही टीमों का बजट फूँक देते थे। Ethereum स्मार्ट कॉन्ट्रैक्ट्स इस बाइट एरे को हमेशा के लिए ग्लोबल स्टेट में स्टोर कर देते थे, जिससे हर एक वेंडर को इसे हमेशा के लिए संभाल कर रखना पड़ता था। L2 यूजर्स की कुल लागत का नब्बे प्रतिशत हिस्सा इसी में चला जाता था।
EIP-4844 ने तीसरे टाइप के ट्रांजैक्शन और ब्लॉक्स (blobs) को लाकर इस पूरी व्यवस्था को पलट दिया। लेकिन फीस में 10 से 50 गुना तक की कटौती के इन आकर्षक आंकड़ों के पीछे कई ऐसे तकनीकी पहलू छिपे हैं जिन पर मार्केटर्स आमतौर पर चुप्पी साध लेते हैं।
मेमोरी और कंसेंसस के स्तर पर एक ब्लोब कैसे काम करता है
ब्लोब सिर्फ ब्लॉकचेन पर भेजा गया कोई आम फाइल नहीं है। यह ठीक 131,072 बाइट्स (128 KB) का एक आइसोलेटेड डेटा एरे है जो EVM के एग्जीक्यूशन के साथ पैरेलल चलता है। Ethereum के स्मार्ट कॉन्ट्रैक्ट्स CALL या STATICCALL के भीतर ब्लोब के कंटेंट को रीड नहीं कर सकते। उनके पास केवल एक बाइटकोड तक एक्सेस होता है—जो एक खास BLOBHASH ऑपकोड है, और जो कमिटमेंट का वर्जन और हैश रिटर्न करता है।
- ब्लॉक साइज: टारगेट 3 ब्लोब (~384 KB) है, और पीक पर अधिकतम 6 ब्लोब (~768 KB) तक जा सकता है।
- लाइफस्पैन: लगभग 4096 epochs (करीब 18 दिन), जिसके बाद कंसेंसस नोड्स डिस्क से इस डेटा को साफ (prune) कर देते हैं।
- मेमपूल आइसोलेशन: ब्लोब्स सामान्य एग्जीक्यूशन मेमपूल में नहीं घूमते। कंसेंसस क्लाइंट लेवल पर इनका अपना खुद का पूल (P2P blob pool) होता है, जो मुख्य ट्रांजैक्शन कतारों को ओवरलोड से बचाता है।
पैरामीटर | क्लासिक calldata | EIP-4844 ब्लोब (Type 3)
डेटा कहाँ रहता है: स्थायी EVM state में | अस्थायी कंसेंसस p2p-पूल में
रिटेंशन टाइम: हमेशा के लिए | ~18 दिन
EVM से एक्सेस: डायरेक्ट (बाइट रीडिंग के जरिए) | इनडायरेक्ट (केवल हैश और KZG के जरिए)
प्राइसिंग: साझा execution gas | स्वतंत्र ब्लोब गैस मार्केट (EIP-1559)
प्रोटो-डैंकशार्डिंग के छिपे हुए फीचर्स और आर्किटेक्चरल ट्रैप्स
बहुत कम लोग इस बात पर ध्यान देते हैं कि ब्लोब गैस की प्राइसिंग कैसे काम करती है। स्टैंडर्ड गैस के विपरीत, जो DeFi में हर हलचल के साथ उछलती है, ब्लोब बाजार एक स्वतंत्र करेक्शन एल्गोरिदम द्वारा नियंत्रित होता है। यदि रोलअप्स टारगेट किए गए तीन ब्लोब से ऊपर स्लॉट भरते हैं, तो कीमत तेजी से बढ़ने लगती है। यदि स्लॉट खाली रहते हैं, तो कीमत न्यूनतम सीमा तक गिर जाती है। व्यवहार में, इसका मतलब यह है कि शांत घंटों के दौरान ब्लोब भेजना एक सेंट के बहुत छोटे हिस्से का खर्च लाता है, लेकिन अचानक नेटवर्क पर भीड़ बढ़ने पर कीमत एग्जीक्यूशन लेयर की तुलना में सैकड़ों गुना तेजी से उछल सकती है।
एक और बारीक बात KZG कमिटमेंट्स (Kate-Zaverucha-Goldberg) के जरिए होने वाला क्रिप्टोग्राफिक वेरिफिकेशन है। वैलिडेटर्स को डेटा की शुद्धता जांचने के लिए पूरे 128 KB को डाउनलोड करने की जरूरत नहीं होती। उनके लिए 48-बाइट के पॉलीनोमियल की जांच करना ही काफी होता है। इससे वैलिडेटर्स के सीपीयू पर लोड कम होता है, लेकिन सारा दबाव नेटवर्क बैंडविड्थ पर आ जाता है।
प्रैक्टिस में "फालतू" डेटा को कहाँ डंप करें
ब्लोब्स की अस्थायी प्रकृति उन्हें ऐसे डेटा के लिए एकदम सही कंटेनर बनाती है जिसे हमेशा के लिए संभाल कर रखने की जरूरत नहीं होती, लेकिन शॉर्ट वैलिडेशन विंडो के दौरान क्रिप्टोग्राफिक रूप से इम्यूटेबल होना जरूरी है:
- ओरेकल डम्प और रॉ मेट्रिक्स: इंटरमीडिएट डेटा एरे जिन्हें स्मार्ट कॉन्ट्रैक्ट में एग्रीगेट होने से पहले प्रोवाइडर्स द्वारा साइन किया जाता है।
- L3 स्टेट स्नैपशॉट और गेमिंग वर्ल्ड्स: डेल्टा स्टेट चेंजेस जिनकी शुद्धता पिछले हफ्ते के लिए वेरिफाई करना ही काफी होता है।
- 백엔ड ऑडिट लॉग: ट्रांजैक्शन बंडल या रसीदें जिन्हें सार्वजनिक रूप से वेरिफाई किया जाना चाहिए, लेकिन एक महीने बाद जिनका ऑपरेशनल महत्व खत्म हो जाता है।
web3.py पर पाइथन स्क्रिप्ट्स के जरिए ब्लोब में लोड डालना, बाइट्स को अलग से पॉलीनोमियल में पैक करने और 0x01 प्रिफिक्स के साथ वर्जन्ड हैश जनरेट करने की मांग करता है। सबमिट करते समय maxFeePerBlobGas की गलत गणना करने से ट्रांजैक्शन मेमपूल में ही अटक जाएगा।
थ्योरी और इकोनॉमिक्स तो ठीक हैं, लेकिन कोड लेवल पर ब्लोब्स के साथ काम करना कैसा दिखता है? एक स्टैंडर्ड send_transaction कॉल करने पर एरर आ जाएगी, क्योंकि तीसरे टाइप के ट्रांजैक्शन में KZG कमिटमेंट्स की मैनुअल तैयारी, प्रूफ्स जनरेट करने और अलग से गैस लिमिट कैलकुलेट करने की जरूरत होती है।
पायथन में Type-3 ट्रांजैक्शन भेजना
Dencun अपग्रेड को सपोर्ट करने वाले नोड (Geth या Reth) के साथ काम करने वाली अप-टू-डेट लाइब्रेरी का उपयोग करके ब्लोब भेजने का एक वर्किंग पैटर्न नीचे दिया गया है:
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("पेโหลด एक सिंगल ब्लोब में फिट नहीं बैठता")
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, # यह कॉन्ट्रैक्ट क्रिएशन नहीं है: blob-tx के लिए `to` अनिवार्य है
"value": 0,
"data": b"",
}
# ckzg कमिटमेंट, प्रूफ और versioned hash की गणना करता है; साइडकार को raw tx में इन्जेक्ट किया जाता है
signed = Account.sign_transaction(tx, key, blobs=[blob])
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
print(f"Blob-tx भेजी गई: {tx_hash.to_0x_hex()}")यदि आप maxFeePerBlobGas की वोलैटिलिटी का ध्यान नहीं रखते हैं, तो रोलअप्स के पीक लोड के समय आपका ट्रांजैक्शन कंसेंसस मेम्पूल में तब तक फंसा रहेगा जब तक कि मार्केट शांत नहीं हो जाता।
आर्काइवल नोड्स की समस्या: 18 दिन बाद डेटा कहाँ जाता है
ब्लोब्स पर आधारित आर्किटेक्चर को डिजाइन करते समय मुख्य समस्या उनके डिलीट होने से जुड़ी है। कंसेंसस क्लाइंट्स कम से कम 4096 epochs (लगभग 18 दिन) तक ब्लोब बॉडीज़ को स्टोर करते हैं, जिसके बाद वे उन्हें हटा देते हैं। ट्रांजैक्शन खुद और KZG कमिटमेंट हमेशा के लिए ब्लॉकचेन पर बने रहते हैं, लेकिन उनके जरिए ब्लोब के कंटेंट को रिकवर नहीं किया जा सकता। यदि एक महीने बाद ब्लोब का डेटा वापस चाहिए हो, तो एक स्टैंडर्ड नोड एरर रिटर्न कर देगा।
EIP-4844 के ऊपर प्रोडक्ट्स बनाने वाली टीमों को इस समस्या को इन तीन में से किसी एक तरीके से हल करना पड़ता है:
- अपने खुद के आर्काइवल स्क्रैपर्स: ऐसे बैकग्राउंड सर्विसेज को डिप्लॉय करना जो P2P नेटवर्क से ब्लोब्स के प्रकट होने पर उन्हें तुरंत डाउनलोड कर लें और कोल्ड स्टोरेज (S3-कंपैटिबल बकेट्स) में डाल दें।
- डिसेंट्रलाइज्ड आर्काइव्स: डेटा अवेलेबिलिटी के लॉन्ग-टर्म स्टोरेज के लिए Celestia, Avail या The Graph जैसे नेटवर्क्स का उपयोग करना।
- डीप हिस्ट्री को छोड़ना: केवल एक्टिव दो-हफ्ते की विंडो के लिए लोकल इंडेक्स स्टोर करना और पुराने एग्रीगेट्स को कंप्रेस फॉर्म में डंप कर देना।
EXMON प्रैक्टिस: स्टोरेज ऑप्टिमाइज़ेशन
EXMON इंफ्रास्ट्रक्चर में हम भारी इंटरमीडिएट ट्रांजैक्शन लॉग्स, सर्विस डंप्स और वेरिफिकेशन स्नैपशॉट को बाहर ले जाने के लिए अस्थायी ब्लोब स्पेसेस का उपयोग करते हैं।
इससे एक साथ दो काम हो जाते हैं:
- बजट की बचत: calldata के पुराने तरीकों की तुलना में डेटा पब्लिश करने की लागत एक ऑर्डर ऑफ मेग्नीट्यूड कम हो गई है।
- ब्लॉकचेन की शुद्धता: नेटवर्क का ग्लोबल स्टेट ऐसे कचरे से नहीं भरता जो एक हफ्ते बाद ही अपनी प्रासंगिकता खो देता है, और साथ ही डेटा के लाइफसाइकिल इंटरवल पर सौ प्रतिशत क्रिप्टोग्राफिक वेरिफायबिलिटी बनी रहती है।
