Aling mga EIP ang tiyak na isasama sa Pectra upgrade? Magdudulot ba ito ng mas mataas na inflation ng ETH?

Ang mga naaprubahang EIP ay magpapahusay sa programmability ng mga account, kahusayan ng pagpapatunay ng Ethereum, at pag-optimize ng staking, habang ang mga hindi pa tiyak na EIP ay nakatuon sa kung paano mapapabuti ang scalability ng L2.

May-akda: 0XNATALIE

Ang susunod na upgrade ng Ethereum, Pectra, ay pinangalanan mula sa kombinasyon ng Prague at Electra.

Ang Prague ay kumakatawan sa upgrade ng execution layer, na ipinangalan mula sa lungsod ng Prague kung saan ginanap ang Ethereum developer conference (Devcon 4), habang ang Electra ay sumisimbolo sa upgrade ng consensus layer, na pinangalanan ayon sa alpabetong pagkakasunod ng mga bituin. Ang napiling pangalan ng bituin na Electra ay tumutugma sa letrang "E".

Ang Pectra upgrade, bilang isa sa mga hard fork sa kasaysayan ng Ethereum na maaaring may pinakamaraming kasamang Ethereum Improvement Proposals (EIP), ay hindi lamang naglalaman ng serye ng mga proposal para sa pagpapaunlad ng operasyon ng mga validator at pagtaas ng performance ng mainnet, kundi pati na rin ng mga proposal para sa pag-optimize ng L2. Ang Pectra Devnet 4 testnet ay kakalunsad pa lamang, at kasalukuyang may 8 EIP na tiyak nang isasama sa Pectra upgrade.

Mga EIP na Tiyak na Isasama at ang Kanilang Epekto

Ang 8 EIP na ito ay may mga sumusunod na epekto sa mga user: Sa pamamagitan ng pagdaragdag ng kakayahan ng code execution sa EOA, napapataas ang flexibility ng mga account at nagiging posible ang mas kumplikadong operasyon; ang pagtaas ng staking cap ay maaaring magdulot ng mas mataas na demand para sa ETH; kasabay nito, ang pag-optimize ng proseso ng mga validator ay nagpapataas ng seguridad at kahusayan, na nagpapabilis at nagpapalawak ng throughput ng Ethereum.

1. EIP-2537 (Suporta para sa BLS signatures): Sa pamamagitan ng pagpapakilala ng serye ng precompiled contracts (precompiles), nadaragdagan ng Ethereum ang suporta para sa BLS12-381 curve operations, na nagpapahintulot sa BLS signature verification at pinapayagan ang pagsasama-sama ng maraming signature sa isang signature, kaya nababawasan ang complexity ng verification. Ang BLS signature ay isang cryptographic algorithm na kayang lumikha ng mas maliliit na signature at sumusuporta sa signature aggregation. Makakatulong ito sa mga L2 na nangangailangan ng maraming signature at data verification operations upang mas mahusay na gumana.
2. EIP-2935 (Pag-iimbak ng historical block hash sa state): Sa pamamagitan ng pag-iimbak ng pinakahuling 8192 block hash sa system contract, sinusuportahan ang Stateless Clients model at nagbibigay ng mas flexible na paraan ng pag-query ng historical block hash. Ang mga hash na ito ay maaaring direktang i-query sa pamamagitan ng contract at maaaring ibigay bilang witness na naka-bundle para sa stateless clients. Hindi na kailangang magpanatili ng buong blockchain history o mag-imbak ng malaking datos ang client, sapat na ang umasa sa block hash na naka-store sa state at mga kaugnay na patunay upang mapatunayan ang legalidad ng block at transaksyon.
3. EIP-6110 (On-chain na pagproseso ng validator deposits): Inililipat ang pagproseso ng validator deposits mula consensus layer papuntang execution layer, na ginagawa ang pagproseso at pag-verify on-chain at hindi na umaasa sa karagdagang voting mechanism sa consensus layer para kumpirmahin ang bisa ng deposit information. Pinapalakas nito ang seguridad ng deposit process, binabawasan ang delay sa pagproseso, at pinapasimple ang disenyo ng consensus layer at client.
4. EIP-7002 (Execution layer-triggered exits): Pinapayagan ang may-ari ng withdrawal credential na mag-umpisa ng exit nang mag-isa, nang hindi umaasa sa aktibong key ng validator (BLS key), kaya nadaragdagan ang autonomy ng user. Sa kasalukuyan, tanging ang aktibong key ng validator ang maaaring mag-trigger ng exit, ibig sabihin, kung mawala ang aktibong key o kung ipinagkatiwala ng validator ang validation task sa third party (tulad ng staking service provider), hindi makokontrol ng may-ari ng withdrawal credential (ang tunay na may-ari ng pondo) ang na-stake na ETH. Sa proposal na ito, pinapayagan ng execution layer na i-trigger ang exit at withdrawal ng ETH, kaya maaaring mag-umpisa ng exit ang may-ari ng withdrawal credential nang hindi umaasa sa aktibong key.
5. EIP-7251 (Pagtaas ng staking cap): Itinaas ang maximum effective balance ng validator, kaya pinapayagan ang bawat validator na mag-stake ng higit sa 32 ETH, habang nananatili ang minimum staking threshold sa 32 ETH. Layunin nitong bigyang-daan ang malalaking node operator na pagsamahin ang maraming validator upang mabawasan ang bilang ng validator sa network, kaya nababawasan ang P2P messages, signature aggregation, at storage burden.
6. EIP-7549 (Paglipat ng committee index mula sa attestation): Sa pamamagitan ng paglipat ng committee index field mula sa Attestation message, nagiging mas efficient ang consensus vote aggregation. Sa kasalukuyang consensus mechanism ng Ethereum, bawat validator ay bumoboto gamit ang: LMD GHOST vote (kasama ang block root at slot), Casper-FFG vote (kasama ang source at target info), at committee index (committee number ng validator). Dahil kasama ang committee index sa signature message, kahit pareho ang nilalaman ng boto ng maraming validator, magkaiba ang signature root kaya hindi madaling i-aggregate ang mga boto. Sa paglipat ng committee index mula sa signature message, nagiging mas efficient ang vote aggregation, nababawasan ang verification cost at network load.
7. EIP-7685 (Generic execution layer requests): Nagbibigay ng generic framework para sa execution layer (EL) upang mag-imbak at magproseso ng mga request na na-trigger ng smart contract. Sinusuportahan ng framework na ito ang mas maraming execution layer-triggered behaviors at pinapayagan ang iba't ibang uri ng request na maproseso nang sabay-sabay, pinapasimple ang proseso ng pagdagdag ng bagong uri ng request nang hindi binabago ang execution block structure.
8. EIP-7702 (Pagdaragdag ng code execution capability sa EOA): Nagdadagdag ng code execution function sa externally owned accounts (EOA), kaya pinapalakas ang flexibility at programmability ng account. Sa pamamagitan ng authorized signature, maaaring magtalaga ang EOA ng smart contract para magproxy ng ilang operasyon, tulad ng batch transaction o permission control. Sa ganitong paraan, nagkakaroon ng ilang smart contract function ang EOA nang hindi kailangang maging smart contract account.

Mga EIP na Binibigyang-pansin

Ang mga sumusunod ay ilan sa mga EIP na aktibong kinokonsidera, na pangunahing nag-o-optimize ng blob upang mapatatag ang gastos sa data publishing ng L2, pinapalakas ang transaction processing capacity ng L2, at epektibong binabawasan ang gastos ng L2. Bukod dito, ang pagtaas ng calldata cost ay maaaring makaapekto sa ETH burn rate at magdulot ng mas mataas na inflationary pressure sa ETH.

• EIP-7742 (Pag-alis ng dependency ng blob count sa pagitan ng consensus at execution layer): Tinatanggal ang coupling ng blob count sa pagitan ng consensus at execution layer, pinapasimple ang blob verification process, binabawasan ang hindi kinakailangang complexity, at pinapataas ang scalability at flexibility ng protocol. Sa kasalukuyang protocol, parehong hardcoded ang maximum value ng blob sa execution at consensus layer, kaya nagkakaroon ng redundant verification. Sa proposal na ito, tinatanggal ang blob max value verification sa execution layer at ipinapasa na lang ng consensus layer ang dynamic blob target value sa execution layer. Sa ganitong paraan, mas flexible na maia-adjust ang blob target parameter para sa future scaling needs. Ang EIP-7742 ay isa sa mga proposal na may pinakamaliit na pagtutol sa listahan ng mga EIP na kinokonsidera para sa upgrade. Ayon sa pinakabagong consensus layer meeting, sumang-ayon ang mga developer na simulan ang implementasyon ng EIP-7742 sa pectra-devnet 5, ngunit kung opisyal itong maisasama ay nakadepende pa rin sa feedback ng execution layer sa ACDE (All Core Developers Execution Layer Meeting).
• EIP 7762 (Minimum blob base fee): Itinaas ang MIN_BASE_FEE_PER_BLOB_GAS, na layuning paikliin ang oras na kinakailangan para maabot ang tamang presyo ng blob. Sa kasalukuyan, ang minimum blob base fee ay nakatakda sa 1 wei, kaya kapag mas mataas ang demand kaysa supply, napakabagal ng price discovery process (pag-alam ng tamang blob Gas price), at matagal bago maabot ang tamang fee level. Sa pamamagitan ng pagtaas ng minimum blob base fee, mapapabilis ang price adjustment, mas mabilis na maabot ang market equilibrium, at masisiguro ang network stability kahit sa peak demand.
• EIP-7623 (Pagtaas ng calldata cost): Itinaas ang cost ng calldata sa mga transaksyon upang mabawasan ang maximum block size at ang variability nito, at masiguro ang mas maayos na pagproseso ng network ng mga transaksyon. Sa kasalukuyan, ang maximum block size ay nasa 1.79 MB, ngunit dahil sa dami ng data publishing ng mga application tulad ng rollups, patuloy na tumataas ang average block size. Sa pamamagitan ng pagtaas ng calldata cost na pangunahing ginagamit para sa data availability (DA) transactions, nababawasan ang maximum block size sa humigit-kumulang 0.72 MB, na nagbibigay ng espasyo para sa pagtaas ng block Gas limit o mas maraming blob sa hinaharap. Hindi nagbabago ang transaction cost ng ordinaryong user; ang pagbabagong ito ay pangunahing nakakaapekto sa mga uri ng transaksyon na umaasa sa Ethereum para sa malakihang data storage. Gayunpaman, ang pagtaas ng calldata cost ay maaaring magpababa sa competitiveness ng Ethereum sa data storage. Bukod dito, dahil sa pagtaas ng calldata cost, maaaring bumaba ang bilang ng transaksyon, na magreresulta sa mas kaunting ETH na masusunog sa pamamagitan ng EIP-1559 mechanism, at magdudulot ng mas mataas na inflationary pressure sa ETH.
• EIP 7782 (Pagpapabilis ng slot time): Binabawasan ang slot time ng Ethereum mula 12 segundo papuntang 8 segundo, kaya mas madalas ang block generation at mas maraming transaksyon ang mapoproseso, bilang alternatibo sa pagdagdag ng blob count upang mapataas ang transaction throughput. Ngunit maaari nitong sirain ang ilang smart contract na hardcoded sa 12-segundong slot time at mapabilis ang state bloat problem ng Ethereum, na magpapataas ng storage at computation burden.
• EIP-7783 (Dahan-dahang pagtaas ng block Gas limit): Bilang mas banayad na alternatibo sa EIP-7782, sa pamamagitan ng dynamic adjustment ng block gas limit, dahan-dahang itataas ang bilang ng transaksyon na kayang i-accommodate ng bawat block, kaya pinapataas ang processing capacity ng network. Kumpara sa direktang pagpapabilis ng slot time, mas maayos ang network scaling sa pamamagitan ng gradual gas limit adjustment. Hindi kailangan ng hard fork para sa proposal na ito, ngunit maaaring makaapekto ito sa state data.

Dahil sa dami ng EIP na kasama sa Pectra upgrade, upang mabawasan ang complexity ng isang beses na upgrade at mapabilis ang pag-rollout ng ilang EIP, noong Mayo, iminungkahi ng engineering team ng Ethereum Foundation na EthPandaOps na hatiin ang Pectra sa dalawang bahagi, ngunit noon ay nag-aalala na baka maantala ang upgrade kaya hindi ito seryosong kinonsidera. Noong Setyembre, muling iminungkahi ng Ethereum researcher na si Alex Stokes ang paghahati, at sa pagkakataong ito ay nakuha ang suporta ng mga developer. Ang ganitong paghahati ay makakatulong upang matapos ang unang bahagi ng upgrade sa loob ng anim na buwan:

• Unang bahagi: Kabilang ang mga EIP na kasalukuyang tumatakbo sa Pectra Devnet testnet (ibig sabihin, ang 8 EIP na tiyak na), na mas madaling ipatupad at dumaan na sa maraming testing.
• Pangalawang bahagi: Ang mas komplikadong mga EIP (tulad ng PeerDAS, EOF-related proposals) at iba pang proposal na nangangailangan ng mas maraming oras para sa testing ay ilalagay sa ikalawang yugto. Ang mga proposal na ito ay nangangailangan ng karagdagang development, audit, at testing, lalo na ang mga may kinalaman sa coordination ng consensus at execution layer.