Nag-aaway ang mga pangunahing developer ng Ethereum tungkol sa proseso, Fusaka timeline

Ang pinakabagong All Core Devs ng Ethereum ay tumuon hindi lamang sa code kundi pati na rin sa proseso: kung dapat bang igalang ang naunang ipinahayag na 30-araw na pagitan sa pagitan ng mga release ng client at ng unang testnet fork habang papalapit ang Fusaka upgrade. May ilang kalahok na iginiit na dapat panatilihin ang pangakong ito upang magkaroon ng sapat na oras ang mga infrastructure at app teams na makapag-adapt; ang iba naman ay nagsabing dapat maging flexible upang maiwasan ang mas malawak na pagkaantala sa roadmap.

Naganap ang debate na ito sa gitna ng halo-halong resulta ng devnet. Sa Devnet-3, ang planadong non-finality exercise ay tumagal, ayon kay Barnabas Busa mula sa Dev Ops team. “Plano naming gawin ito ng mga dalawang araw muna, pero ngayon ay umabot na kami sa ikalimang araw,” aniya, at binanggit na bumaba ang partisipasyon at pagkatapos ay muling tumaas ng higit sa 50%. Kinakailangan ng finality na higit sa dalawang-katlo ng kabuuang effective stake ang sumang-ayon.

Sa kabilang banda, isang hiwalay na testnet ang mabilis na nakabawi matapos ang coordinated restart: “Ang chain ay nakabawi sa loob ng, sa tingin ko, dalawang oras,” sabi ni Busa. Ang pagsasanay na ito ay sinusubukan kung paano nagkaka-interaksyon ang mga variable sa isang aktwal na insidente, na makakatulong sa Ethereum na makabawi sa panahon ng krisis.

Basahin pa: Maaaring maantala ang Fusaka upgrade ng Ethereum

Sa pagdating ng mga pag-aayos sa mga susunod na araw, ang agarang plano ay ibalik ang Devnet-3 sa buong kalusugan, ulitin ang pagsubok at pagkatapos ay simulan ang Devnet-5.

Ngunit ang mas malaking isyu ay ang disiplina sa pag-schedule para sa mga pampublikong network. Binigyang-diin ni Lightclient ang kasalukuyang pangako: “Nakalagay na 30 araw bago ang unang testnet.” Nagbabala siya laban sa pagbabago ng mga pamantayan para lamang sa kaginhawaan, batay sa pagtatasa ng core devs sa oras na kailangan ng ibang teams na wala sa tawag.

Ang praktikal na alalahanin ay kung paano mapapabuti ang daloy ng mga hard fork. Ang pagpapaikli ng pagitan ng mga pagsubok ay maaaring magpabilis ng mga fork, ngunit pinapataas din ang panganib na maglabas ng minadaling updates ang mga downstream teams. Ang kabaligtaran namang argumento ay ang matagal na pipeline ay nagpapabagal sa lahat ng iba pang nasa pila, na maaaring hindi ikatuwa ng mas malawak na Ethereum community.

“Hindi ko iniisip na dapat tayong pumili ng timeline batay sa gusto ng community,” sabi ni Lightclient. “Ang mga taong gumagawa ng software ang nagsabing gusto nila ng 30 araw para makapaghatid ng mataas na kalidad na software na gagamitin ng community.”

Gayunpaman, ang medyo mainit na palitan ng opinyon ay nauwi sa pagpapanatili ng nakasulat na proseso maliban na lamang kung hayagang hilingin ng mga stakeholder ang pagbabago.

Mayroon ding pagkadismaya sa paulit-ulit na pagbalik sa parehong tanong bawat cycle. “Sa tingin ko ay masamang precedent ang palaging pagpapalit ng desisyon,” sabi ni Lightclient, at binanggit na ang mga app developer at L2s ay kadalasang wala sa core calls at umaasa sa predictable na window para ma-schedule ang kanilang sariling releases.

Sa ngayon, ang consensus ay magpatuloy na parang nananatili pa rin ang 30-araw na buffer, habang aktibong kumukuha ng bagong input, ayon kay coordinator Tim Beiko. “Dapat nating ihanda ang schedule base sa nakasaad sa [process] document at kasabay nito ay kumonsulta sa mga stakeholder na apektado.” Kung ang mas mabilis na proseso ay tunay na may malawak na suporta, pormal itong itatala sa sulat.