Solana mga developer ay nagsisikap na isaalang-alang ang isang bagong protocol rulebook na disenyo upang gawing mas maaasahan at mas madaling pangalagaan ang sariling-developed na validator software.
Ang propuesta, na ipinahayag noong Okt. 30, ay galing kay Brennan Watt, CEO ng Anza, ang blockchain engineering company sa likod ng Agave, isa sa mga pangunahing software program na ginagamit upang pamahalaan ang network ng Solana.
Gusto ni Watt na magtatag ng isang magkakasunod at awtorisadong spesipikasyon ang Solana na nagtatakda kung paano nila ginagawa ang mga transaksyon, pinapatotohanan ang mga bloke at nakakamit ang pagkakasundo sa kanilang blockchain, kaysa mag-asa sa mga patakaran na nakalat sa umiiral na software at hiwalay na teknikal na propuesta.
Ang pagbabago ay maaaring tugunan ang lumalaking hamon habang lumalawak ang Solana sa labas ng orihinal na validator software upang kasama ang mga alternatibong gawa ng mga nag-iisang developer tulad ng Firedancer, gawa ng trading firm na Jump Crypto.
Ang mga validator ay mga computer na nagpapatotoo sa mga transaksyon at tumutulong na mapanatili ang seguridad ng blockchain. Kahit na iba’t ibang developer ang maaaring gumawa ng software na nagpapatakbo sa mga computer na ito, kailangan ng bawat implementasyon na sumunod sa parehong mga pangunahing patakaran upang mapanatili ang pagkakasundo sa buong network.
Ang mga pagkakaibang may kaugnayan sa mga patakaran na iyon ay maaaring magdulot ng pagkakaiba-iba sa pagproseso ng mga parehong transaksyon ng mga validator, na potensyal na lumilikha ng magkakaibang pananaw sa blockchain at nagbubulag sa network reliability.
Ayon kay Watt, ang umiiral na proseso ng pag-unlad ng Solana ay nagiging hindi kinakailangang mahirap para sa mga independiyenteng koponan upang matukoy kung paano dapat magtrabaho ang network.
Sa kasalukuyang sistema, ang mga pagbabago sa protokolo ay iniihingi sa pamamagitan ng Solana Improvement Documents, kilala bilang SIMDs. Ang mga dokumentong ito ay naglalarawan sa mga hiwalay na pagpapabuti, ngunit ang buong mga patakaran sa pagpapatakbo ng network ay hindi nakapagsasama sa isang awtoritatibong sanggunian.
Bilang resulta, ang mga developer ay minsan ay kailangang suriin ang umiiral na validator code o muling bumuo ng mga desisyon sa nakaraang pag-upgrade upang maunawaan kung anong mga patakaran ang aktibo.
Sinabi ni Watt na ang paraang ito ay maaaring magproduko ng paulit-ulit o hindi konsistenteng paglalarawan ng umiiral na pag-uugali habang pinapahirapan ang pagkilala sa bawat bahagi ng protokolo na apektado ng isang propong pagpapabuti.
Ang bagong rulebook ay maaaring magbago sa proseso ng pag-upgrade ng Solana
Sa ilalim ng panukala, magpapatuloy ang mga developer sa pag-uusap tungkol sa mga posibleng pagpapabuti sa pamamagitan ng umiiral na SIMD process, ngunit ang mga pormal na teknikal na pagbabago ay ipapasa bilang mga pag-edit sa isang pinagsamang protocol specification.
Ang bawat pagbabago ay maglalarawan nang tumpak kung paano nakaaapekto ang pag-upgrade sa mga transaksyon, komunikasyon ng network, consensus at iba pang mga kaugnay na punsiyon.
Ang mga pagbabago ay masusuri ng teknikal at anumang kinakailangang pagpapahintulot sa pamamahala ay mabubuo bago ito maging bahagi ng opisyal na spesipikasyon kapag ikinabuhay sa Solana's Mainnet.
Ito ay magpapahintulot sa mga koponan na nagpapaunlad ng Agave, Firedancer at mga hinaharap na validator software na magtrabaho mula sa mga parehong dokumentadong mga kinakailangan kaysa mag-asa sa code ng ibang implementasyon bilang pangunahing sanggunian.
Saan magsisimula ang kliyente?
Ang pagbuo ng child-bank ay naglalapat ng epoch-E boundary transition isang beses bago ang mga transaksyon nito.
Ang isang karaniwang patakaran ay ginagawa ang target na malinaw. Ang pagkakatiwala sa simula at ang susunod na epoch ay magkakahiwalay na mga kailangan.
Ito ay isang draf ng spesipikasyon, hindi isang aminadong pagbabago sa protokolo. Hindi ito nagtatatag ng tamang starting-state, historical replay o tuloy-tuloy na operasyon patungo sa E+1. Walang quantified na pagpapabuti sa reliability ng client.
Maaari rin ito gawing mas epektibo ang pagsubok ng software. Kapag nagbibigay ang mga independiyenteng validator ng iba’t ibang resulta, mayroon ang mga developer na karaniwang pamantayan kung saan susuriin ang pagkakaiba at matukoy kong anong implementasyon ang kailangang ayusin.
Kumpleto na ni Watt ang draft specification na nakakapaloob sa 18 na aspeto ng operasyon ng Solana, kabilang ang pagproseso ng transaksyon, network communications, consensus, mga bayad, at mga reward ng validator.
Gayunpaman, ang draft ay limitado lamang sa isang tiyak na panahon ng kasaysayan ng blockchain ng Solana at nagtatanggap na ang mga developer ay magsisimula mula sa isang nangangalagaan na estado ng network. Kailangan pa ng karagdagang gawain upang sakop ang mga susunod na upgrade at matiyak na ang mga implementasyon ay patuloy na compatible sa paglipas ng panahon.