PoH एक क्रिप्टोग्राफिक टाइमकीपिंग मैकेनिज्म है जो लगातार हैश सीक्वेंस बनाकर यह साबित करता है कि ब्लॉकचेन में शामिल होने से पहले घटनाएं किस क्रम में हुईं। Solana के Alpenglow अपग्रेड के साथ इसे fixed slot scheduling से बदला जा रहा है।

अध्याय 3: Solana

अवलोकन

Solana एक हाई-परफॉर्मेंस Layer-1 ब्लॉकचेन है जिसने 2020 में अपना mainnet लॉन्च किया और खुद को "दुनिया का सबसे तेज़ ब्लॉकचेन" के रूप में प्रस्तुत किया। Ethereum जिन scalability समस्याओं से जूझ रहा था — धीमी processing speed और ऊँची fees — उन्हें Solana ने मौलिक architectural innovation के ज़रिए हल करने की कोशिश की। Solana का तरीका सिर्फ मौजूदा तकनीक को बेहतर बनाना नहीं था, बल्कि Parallel Execution और Proof of History (PoH) जैसी अपनी मौलिक तकनीकों को एक साथ जोड़कर प्रति सेकंड हज़ारों transactions process करने का लक्ष्य रखना था — यही चीज़ इसे बाकी ब्लॉकचेन से अलग बनाती है।

इस अध्याय में हम उन 7 मुख्य अवधारणाओं की गहराई से पड़ताल करेंगे जो Solana को Solana बनाती हैं। Architecture-स्तर की innovations जैसे Parallel Execution और Proof of History (PoH) से शुरू करके, सुरक्षा और developer-friendliness बढ़ाने वाले Program Derived Address (PDA), fees की संरचना में क्रांति लाने वाले Local Fee Markets, और नेटवर्क efficiency बढ़ाने वाले Gulf Stream एवं Turbine तक सब कुछ विस्तार से समझेंगे। अंत में Solana के भविष्य को तय करने वाले Alpenglow upgrade को भी शामिल किया गया है, ताकि Solana की वर्तमान स्थिति और आने वाले कल की एक संपूर्ण तस्वीर सामने आ सके।

Solana अपनी बेहतरीन performance के लिए जितना सराहा जाता है, उतना ही नेटवर्क outages और centralization की चिंताओं जैसी व्यावहारिक सीमाओं के लिए आलोचना भी झेलता है। इस अध्याय के ज़रिए आप Solana की तकनीकी खूबियों और trade-offs दोनों को संतुलित दृष्टि से समझ सकेंगे, और blockchain scalability की समस्या के प्रति Solana के अपने अनूठे नज़रिए का आलोचनात्मक मूल्यांकन कर सकेंगे।

Parallel Execution

परिभाषा

Parallel Execution वह तरीका है जिसमें Solana transactions को process करता है — यानी अलग-अलग accounts को access करने वाले transactions को एक साथ कई CPU cores पर simultaneously execute किया जाता है। इसे संभव बनाने की मूल शर्त यह है कि "हर transaction को पहले से यह घोषित करना होता है कि वह किन accounts को read या write करेगा।" Runtime इस घोषणा के आधार पर transactions के बीच टकराव (conflict) का पहले से पता लगा लेता है — जो transactions आपस में नहीं टकरातीं, उन्हें parallel में चलाया जाता है, और जो एक ही account को access करती हैं, उन्हें sequentially process किया जाता है। Solana इस mechanism को Sealevel नामक parallel runtime के ज़रिए implement करता है।

मुख्य बिंदु

सुपरमार्केट की कई checkout lanes बनाम एकल queue: Ethereum एक global state पर sequentially access करने वाली single queue की तरह काम करता है। Solana इसके विपरीत एक बड़े supermarket की तरह काम करता है जहाँ कई checkout lanes एक साथ चलती हैं — अलग-अलग accounts को process करने वाली transactions स्वतंत्र रूप से parallel में execute होती हैं। अगर दो customers (transactions) अलग-अलग items (accounts) checkout कर रहे हैं, तो उन्हें एक ही लाइन में खड़े होने की ज़रूरत नहीं।
Pre-declaration का महत्व: हर Solana transaction को execute होने से पहले अपने access किए जाने वाले accounts की सूची अनिवार्य रूप से declare करनी होती है। यह शर्त parallel execution को सक्षम बनाने की पूर्वापेक्षा है, लेकिन साथ ही developers पर अतिरिक्त design बोझ भी डालती है। ऐसी structures जहाँ runtime के दौरान dynamically accounts तय होते हों, उन्हें Solana में implement करना अधिक जटिल हो जाता है।
Performance लाभ: Parallel execution ही वह सबसे बुनियादी कारण है जिसकी वजह से Solana प्रति सेकंड हज़ारों transactions process करने का दावा करता है। आधुनिक servers में दर्जनों CPU cores होते हैं, इसलिए सैद्धांतिक रूप से cores की संख्या के अनुपात में processing performance में वृद्धि हासिल की जा सकती है।
Conflict होने पर sequential processing: एक ही account को access करने वाली transactions को अभी भी sequentially process करना पड़ता है। जब कोई लोकप्रिय DeFi protocol या NFT minting event हो और बहुत सारी transactions एक ही account पर केंद्रित हो जाएँ, तो parallel execution का फायदा कम हो जाता है और bottleneck पैदा हो सकता है।
Ethereum से मौलिक अंतर: Ethereum का EVM global state transition को अपना मूल model मानता है और sequential execution के लिए optimized है। Ethereum में parallel execution लाने के लिए account access prediction या optimistic parallelization जैसे जटिल अतिरिक्त designs की ज़रूरत होगी, जबकि Solana ने शुरू से ही parallel execution को अपना design principle माना है।

Proof of History (PoH)

परिभाषा

Proof of History (PoH) Solana द्वारा ईजाद किया गया एक cryptographic timekeeping mechanism है। यह लगातार SHA-256 hash sequence generate करके mathematically साबित करता है कि ब्लॉकचेन में कुछ घटनाएँ एक निश्चित क्रम में, एक निश्चित समय पर हुईं। सामान्य blockchains में nodes को events के क्रम और समय पर consensus बनाने के लिए जटिल message exchanges की ज़रूरत होती है। PoH ने इस प्रक्रिया को cryptographic timestamps से replace कर consensus में लगने वाले overhead को कम किया और processing speed बढ़ाई। हालाँकि यह ध्यान देना ज़रूरी है कि PoH एक स्वतंत्र consensus algorithm नहीं है — यह Solana के Proof of Stake (PoS) आधारित consensus mechanism, Tower BFT, को सहायता देने वाला एक timekeeping layer है।

मुख्य बिंदु

लगातार hash sequence: PoH को sequential hashing के ज़रिए implement किया जाता है जिसमें पिछले hash का output अगले hash का input बनता है। इस sequence की computation में समय लगता है, इसलिए किसी hash value का अस्तित्व यह साबित करता है कि उससे पहले के सभी hashes ज़रूर पहले compute हुए होंगे। यानी क्रम के साथ छेड़छाड़ संभव नहीं है।
विश्वसनीय global clock की भूमिका: पारंपरिक distributed systems में nodes के बीच time synchronization एक कठिन समस्या है। PoH blockchain में एक built-in cryptographic clock प्रदान करता है, जिससे बाहरी timestamp server के बिना भी सभी participants events का relative order verify कर सकते हैं।
Tower BFT के साथ संबंध: PoH खुद consensus achieve नहीं करता। वास्तविक consensus की जिम्मेदारी Tower BFT की है, और PoH उसे समय की जानकारी देता है। PoH द्वारा बनाई गई slot और epoch structure के ऊपर validators अपने votes डालते हैं।
Leader schedule के साथ समन्वय: Solana हर slot के लिए block produce करने वाले leader validator को पहले से निर्धारित करता है। PoH का time flow इस leader schedule के साथ synchronized रहता है, जिससे हर leader अपने slot में transactions process करके अगले leader को seamlessly handoff करता है।
Alpenglow में PoH की समाप्ति: PoH Solana की पहचान बन गई थी, लेकिन Alpenglow upgrade में इसे पूरी तरह हटाया जाएगा। Fixed slot scheduling इसकी जगह लेगा, जिससे एक सरल और तेज़ consensus संभव हो सकेगा। PoH जो timekeeping भूमिका निभाता था, वह एक नए तरीके से पूरी की जाएगी।

Program Derived Address (PDA)

परिभाषा

Program Derived Address (PDA) Solana में एक विशेष प्रकार का address है जिसे कोई program (smart contract) mathematically generate करता है और जिसकी कोई corresponding private key नहीं होती। सामान्य Solana wallet addresses public key-private key pairs से बनते हैं, जहाँ private key का मालिक उस address की assets को manage करता है। इसके विपरीत, PDA किसी specific program की ID और seed values को मिलाकर elliptic curve के बाहर एक off-curve point के रूप में mathematically derive किया जाता है — इसलिए कोई private key exist नहीं करती, और केवल वही program PDA को "sign" करके control कर सकता है जो उसका owner है।

मुख्य बिंदु

Escrow custody की समस्या का समाधान: DeFi में escrow functionality ऐसी situations पैदा करती है जहाँ किसी third party को अस्थायी रूप से funds रखने होते हैं। पारंपरिक तरीके में इन funds को manage करने वाली key किसी को (या multisig को) रखनी पड़ती है, जो insider fraud या hacking का जोखिम पैदा करती है। PDA में private key नहीं होती, इसलिए कोई भी इंसान PDA में रखे funds को मनमाने ढंग से नहीं निकाल सकता। केवल owning program की logic द्वारा अनुमत conditions में ही funds move हो सकती हैं।
केवल program ही PDA को sign कर सकता है: Solana runtime किसी specific program को अपने PDA की तरफ से sign करने की अनुमति देता है। इसे "program signing" या "CPI (Cross-Program Invocation) with signer" कहते हैं। यही mechanism enable करता है कि program PDA account की assets को move करे या उसका data बदले।
Deterministic address generation: PDA हमेशा एक ही program ID और seed values से एक ही address generate करता है। इस deterministic विशेषता की वजह से कोई भी participant किसी specific PDA का address पहले से calculate और verify कर सकता है, जिससे transparency और predictability सुनिश्चित होती है।
विविध उपयोग के मामले: Escrow के अलावा PDA का उपयोग AMM (Automated Market Maker) के liquidity pools, NFT metadata storage accounts, user-specific state storage accounts, और on-chain configuration data जैसे Solana DApp development के core patterns में व्यापक रूप से होता है।
Ethereum से तुलना: Ethereum के smart contracts भी अपना खुद का address रखते हैं और assets store कर सकते हैं। लेकिन Solana का PDA, account model और program ownership structure की विशिष्टताओं की वजह से asset custody को अधिक explicit और granular तरीके से implement करता है।

Local Fee Markets

परिभाषा

Local Fee Markets Solana का fee-निर्धारण mechanism है जिसमें पूरे नेटवर्क की congestion के बजाय individual account level पर fees तय होती हैं। Ethereum में network-wide demand के आधार पर base fee निर्धारित होती है, इसलिए किसी एक DApp में congestion होने पर बिल्कुल असंबंधित दूसरी transactions की fees भी बढ़ जाती हैं। इसके विपरीत, Solana के Local Fee Markets में जब किसी specific account पर transactions की भीड़ लगती है, तो केवल उस account से संबंधित transactions की priority fee बढ़ती है — दूसरे accounts को handle करने वाली transactions प्रभावित नहीं होतीं।

मुख्य बिंदु

Account-level fee निर्धारण: Solana की हर transaction में एक base fee और एक वैकल्पिक priority fee होती है। जब किसी specific account को access करने वाली transactions बढ़ती हैं, तो उस account के लिए priority fee की प्रतिस्पर्धा शुरू हो जाती है। किसी लोकप्रिय NFT minting या DeFi liquidation event जैसी situations में जब किसी account पर demand केंद्रित होती है, तब यह effect स्पष्ट रूप से दिखता है।
Ethereum के global fee market से तुलना: Ethereum पर किसी popular NFT मिंटिंग के दौरान gas price पूरे नेटवर्क में आसमान छू जाती है, जिससे simple token transfer जैसे असंबंधित transactions भी महँगे हो जाते हैं। Solana का Local Fee Markets यह समस्या सैद्धांतिक रूप से हल करता है — congestion का प्रभाव उसी account तक सीमित रहता है।
Parallel Execution के साथ synergy: Local Fee Markets तब सबसे प्रभावी होते हैं जब Parallel Execution के साथ मिलकर काम करते हैं। जहाँ congested account की transactions महँगी fees देकर आपस में प्रतिस्पर्धा करती हैं, वहीं दूसरे accounts की transactions parallel execution lanes में कम fees पर सामान्य रूप से process होती रहती हैं।
वास्तविक सीमाएँ — spam के प्रति vulnerability: Local Fee Markets सैद्धांतिक रूप से एक elegant design है, लेकिन व्यवहार में extreme spam attacks या bot traffic के दौरान यह अपूर्ण तरीके से काम करता है — यह आलोचना इस पर लगती रहती है। जब spam transactions कई accounts पर distributed attack करती हैं, या network-level saturation होती है, तो अकेला Local Fee Markets mechanism नेटवर्क की quality guarantee करने में अपर्याप्त साबित होता है। यही Solana के पिछले network performance degradation के कारणों में से एक रहा है।
QUIC upgrade के साथ संबंध: Solana ने spam की समस्या सुधारने के लिए transaction transmission protocol को UDP से QUIC में बदला और stake-weighted QoS (Quality of Service) जैसे supplementary measures लागू किए। यह इस बात की व्यावहारिक स्वीकृति है कि Local Fee Markets अकेले पर्याप्त नहीं हैं।

Gulf Stream

परिभाषा

Gulf Stream Solana का transaction forwarding protocol है। Bitcoin और Ethereum जैसी अधिकांश blockchains में transactions को public mempool में broadcast किया जाता है जहाँ सभी nodes उन्हें store करते हैं और leader (miner या validator) उनमें से चुनता है। Gulf Stream इसके बजाय transactions को सीधे वर्तमान और आगामी scheduled leaders को forward करता है। यह इसलिए संभव है क्योंकि Solana, PoH-based leader schedule की मदद से भविष्य के leaders को पहले से जानता है।

मुख्य बिंदु

Mempool-रहित architecture: Solana कोई public mempool नहीं चलाता। इसके बजाय Gulf Stream के ज़रिए transactions पूरे नेटवर्क में broadcast नहीं होतीं, बल्कि सीधे ज़रूरी leaders को forward होती हैं। इससे broadcast phase में होने वाले network overhead और latency कम होती है।
Leader schedule का उपयोग: PoH द्वारा बनाए गए leader schedule की वजह से Solana के सभी nodes पहले से जानते हैं कि आने वाले कई slots में कौन leader होगा। Gulf Stream इस जानकारी का उपयोग करके transactions को न केवल current leader को, बल्कि अगले scheduled leaders को भी पहले से deliver करता है — ताकि leader के block production शुरू करने से पहले ही उसके पास process करने के लिए transactions मौजूद हों।
Latency कम होने का प्रभाव: Public mempool method में transaction पूरे network में propagate होने के बाद leader उसे select करता है, जिससे propagation delay होती है। Gulf Stream यह propagation path छोटा करके transaction को leader तक पहुँचने का समय घटाता है, और परिणामस्वरूप confirmation speed बढ़ती है।
MEV पर प्रभाव: Public mempool न होने से Ethereum में common front-running MEV मुश्किल हो जाता है। हालाँकि Solana में भी leader द्वारा अपने पास forward हुई transactions को reorder करने के रूप में MEV मौजूद है, और इस पर चर्चा सक्रिय है।
Centralization की चिंता: जब transactions सीधे कुछ scheduled leaders को forward होती हैं, तो सैद्धांतिक रूप से वे leaders किसी specific transaction को censor कर सकते हैं या priority में हेरफेर कर सकते हैं। यह Solana architecture की decentralization संबंधी आलोचनाओं में से एक है।

Turbine

परिभाषा

Turbine Solana का block propagation protocol है। जब leader एक block produce करता है, तो उसे network के सभी validators को deliver करना होता है। हज़ारों validators को सीधे बड़े block data भेजने के लिए भारी network bandwidth की ज़रूरत होगी। Turbine इस समस्या को हल करने के लिए block को छोटे टुकड़ों में तोड़ता है जिन्हें 'shreds' कहते हैं, और उन्हें validators के एक tree structure के माध्यम से वितरित करता है। यह BitTorrent जैसे peer-to-peer file sharing protocols से प्रेरित है। हर validator कुछ shreds receive करता है और उन्हें अगले validators को forward करता है, जिससे पूरे network में data efficiently फैल जाता है। Turbine में redundancy encoding भी शामिल है जिससे आंशिक data से भी पूरे block को reconstruct किया जा सकता है।

मुख्य बिंदु

Shred-based data distribution: Block को shreds में तोड़ने से हर validator को एक बार में बड़ी मात्रा में data download करने की ज़रूरत नहीं रहती। इससे block propagation में लगने वाला समय कम होता है और network bandwidth की खपत distribute हो जाती है।
Tree structure के ज़रिए propagation: Turbine validators को एक hierarchical tree में organize करता है। Leader पहले tree के top-level nodes को shreds भेजता है, और वे nodes उन्हें नीचे के validators को forward करते हैं। इस cascade structure से data तेज़ी से पूरे network में फैलता है।
Erasure coding के ज़रिए resilience: Turbine में Reed-Solomon जैसी erasure coding तकनीक का उपयोग होता है। इसका मतलब है कि कुछ shreds missing होने पर भी बाकी shreds से पूरा block reconstruct किया जा सकता है। यह network unreliability के सामने block propagation को robust बनाता है।
High throughput को support करना: Solana प्रति सेकंड बड़ी संख्या में transactions process करता है, इसलिए blocks का size भी बड़ा हो सकता है। Turbine इन large blocks को efficiently propagate करने का mechanism प्रदान करता है, जिसके बिना high throughput का लाभ network propagation bottleneck से खत्म हो जाता।
Validator network के लिए bandwidth requirement: Turbine के बावजूद, Solana validators को अन्य blockchains की तुलना में अधिक bandwidth और hardware की ज़रूरत होती है। यह requirement validator participation में entry barrier बढ़ाती है और centralization की चिंताओं में योगदान देती है।
Alpenglow के साथ evolution: Alpenglow upgrade, Rotor नाम का एक नया block dissemination protocol लाएगा जो Turbine की जगह लेगा या उसे बेहतर बनाएगा। Rotor को lower latency finality के साथ align करने के लिए design किया गया है।

Alpenglow

परिभाषा

Alpenglow, Solana का एक महत्वपूर्ण upcoming consensus upgrade है जो मौजूदा PoH-आधारित consensus architecture को पूरी तरह बदल देगा। इसके दो मुख्य components हैं: Votor — एक नया voting protocol जो 1-2 rounds में finality achieve करने का लक्ष्य रखता है, और Rotor — एक नया block dissemination mechanism जो Turbine की जगह लेगा। Alpenglow का प्राथमिक लक्ष्य Solana की मौजूदा लगभग 12.8 सेकंड की finality को घटाकर 100-150 milliseconds तक लाना है। यह सुधार user experience और DeFi जैसे time-sensitive applications के लिए गेम-चेंजर साबित हो सकता है।

मुख्य बिंदु

PoH को पूरी तरह हटाना: Alpenglow का सबसे radical बदलाव

Proof of History (PoH)

मुख्य बिंदु

अध्याय 3: Solana

अवलोकन

Parallel Execution

परिभाषा

मुख्य बिंदु

संबंधित अवधारणाएँ

Proof of History (PoH)

परिभाषा

मुख्य बिंदु

संबंधित अवधारणाएँ

Program Derived Address (PDA)

परिभाषा

मुख्य बिंदु

संबंधित अवधारणाएँ

Local Fee Markets

परिभाषा

मुख्य बिंदु

संबंधित अवधारणाएँ

Gulf Stream

परिभाषा

मुख्य बिंदु

संबंधित अवधारणाएँ

Turbine

परिभाषा

मुख्य बिंदु

संबंधित अवधारणाएँ

Alpenglow

परिभाषा

मुख्य बिंदु

이 개념을 포함한 30일 코스

BG इस पैटर्न का विश्लेषण करे तो?