Deweloperzy główni Ethereum spierają się o proces, harmonogram Fusaka

Najnowsze spotkanie Ethereum All Core Devs skupiło się nie tylko na kodzie, ale także na procesie: czy należy dotrzymać wcześniej ustalonego 30-dniowego okna pomiędzy wydaniami klienta a pierwszym forkiem testnetu, gdy aktualizacja Fusaka zbliża się do realizacji. Niektórzy uczestnicy naciskali na potwierdzenie tego zobowiązania, aby zespoły infrastrukturalne i aplikacyjne miały czas na dostosowanie się; inni argumentowali za elastycznością, aby uniknąć opóźnień w szerszym harmonogramie.

Dyskusja toczyła się na tle mieszanych wyników devnetu. Na Devnet-3, planowane ćwiczenie dotyczące braku finalności trwało dłużej, jak poinformował Barnabas Busa z zespołu Dev Ops. „Chcieliśmy zrobić to przez około dwa dni, a teraz mamy już piąty dzień” – powiedział, zauważając, że udział spadł, a następnie ponownie przekroczył 50%. Finalność wymaga zgody ponad dwóch trzecich całkowitego efektywnego stake'u.

Dla kontrastu, osobny testnet szybko się zregenerował po skoordynowanym restarcie: „Łańcuch odzyskał sprawność w ciągu, myślę, dwóch godzin” – powiedział Busa. Ćwiczenie to testuje, jak zmienne współdziałają podczas rzeczywistego incydentu, co może pomóc Ethereum w odzyskaniu sprawności w sytuacji kryzysowej.

Przeczytaj więcej: Aktualizacja Fusaka Ethereum może napotkać opóźnienie

Po wprowadzeniu poprawek w najbliższych dniach, krótkoterminowy plan zakłada przywrócenie Devnet-3 do pełnej sprawności, ponowne przeprowadzenie testu, a następnie uruchomienie Devnet-5.

Jednak głównym punktem zapalnym była dyscyplina harmonogramu dla sieci publicznych. Lightclient podkreślił obowiązujące zobowiązanie: „Jest napisane 30 dni przed pierwszym testnetem.” Ostrzegł przed przesuwaniem celów dla wygody, opierając się na ocenie głównych deweloperów co do czasu potrzebnego innym zespołom, które nie są obecne na rozmowie.

Praktycznym problemem jest to, jak poprawić rytm hard forków. Skracanie przerw między testami może przyspieszyć forki, ale zwiększa ryzyko, że zespoły downstream wypuszczą pośpiesznie przygotowane aktualizacje. Przeciwnym argumentem jest to, że przedłużające się pipeline'y opóźniają wszystko inne w kolejce, co może nie spodobać się szerszej społeczności Ethereum.

„Nie sądzę, że powinniśmy wybierać terminy na podstawie tego, czego społeczność koniecznie chce” – powiedział Lightclient. „Osoby, które wydają oprogramowanie, powiedziały, że chcą 30 dni na dostarczenie wysokiej jakości oprogramowania, z którego społeczność będzie korzystać.”

Mimo to, nieco napięta wymiana zdań zmierzała w kierunku przestrzegania ustalonego procesu, chyba że interesariusze wyraźnie poproszą o zmianę.

Pojawiła się także frustracja związana z powracaniem do tego samego pytania w każdym cyklu. „Uważam, że to naprawdę zły precedens, aby ciągle pozwalać na zmiany decyzji” – powiedział Lightclient, zauważając, że deweloperzy aplikacji i L2 zazwyczaj nie uczestniczą w głównych rozmowach i polegają na przewidywalnych oknach czasowych, aby zaplanować własne wydania.

Na razie konsensus jest taki, aby postępować tak, jakby 30-dniowy bufor nadal obowiązywał, jednocześnie aktywnie zbierając nowe opinie, powiedział koordynator Tim Beiko. „Powinniśmy przygotować harmonogram zgodnie z dokumentem [procesu], a równolegle sprawdzić z interesariuszami, których to dotyczy.” Jeśli szybsza ścieżka rzeczywiście uzyska szerokie poparcie, grupa sformalizuje to na piśmie.