Ethereum asosiy dasturchilari jarayon va Fusaka vaqt jadvali ustida bahslashmoqda

Ethereum’ning so‘nggi All Core Devs yig‘ilishi faqat kod emas, balki jarayon haqida ham bo‘ldi: Fusaka yangilanishi oldinga siljiyotgani sababli, mijozlar relizlari va birinchi testnet fork o‘rtasidagi ilgari belgilangan 30 kunlik muddatga rioya qilish yoki qilmaslik masalasi muhokama qilindi. Ba’zi ishtirokchilar infrastrukturaviy va ilova jamoalari moslashishi uchun ushbu majburiyatni yana bir bor tasdiqlashni taklif qilishdi; boshqalar esa kengroq yo‘l xaritasi kechikishining oldini olish uchun moslashuvchanlik tarafdori bo‘lishdi.

Bahs aralash devnet natijalari fonida kechdi. Dev Ops jamoasidan Barnabas Busa’ning so‘zlariga ko‘ra, Devnet-3’da rejalashtirilgan non-finality mashqi uzoq davom etdi. “Biz avval taxminan ikki kun davomida sinov o‘tkazmoqchi edik, hozir esa beshinchi kunni bosib o‘tyapmiz,” dedi u, ishtirok avval pasayib, keyin yana 50% dan oshganini ta’kidladi. Finality uchun umumiy samarali stakingning uchdan ikki qismidan ko‘prog‘i rozilik bildirish kerak.

Boshqa tomondan, alohida testnet muvofiqlashtirilgan qayta ishga tushirishdan so‘ng tezda tiklandi: “Zanjir, menimcha, ikki soat ichida tiklandi,” dedi Busa. Ushbu mashq o‘zgaruvchilar jonli hodisada qanday o‘zaro ta’sir qilishini bosim ostida sinovdan o‘tkazadi, bu esa Ethereum’ga inqirozda tiklanishga yordam berishi mumkin.

Batafsil o‘qing: Ethereum’ning Fusaka yangilanishi kechikishi mumkin

Yaqin kunlarda tuzatishlar amalga oshirilishi bilan, qisqa muddatli reja Devnet-3’ni to‘liq sog‘lom holatga qaytarish, testni qayta o‘tkazish va so‘ng Devnet-5’ni ishga tushirishdir.

Biroq, asosiy muammo ommaviy tarmoqlar uchun jadval intizomiga bog‘liq bo‘ldi. Lightclient mavjud va’dani ta’kidladi: “Bu birinchi testnetdan 30 kun oldin bo‘lishi kerakligi aytilgan.” U asosiy ishlab chiquvchilarning boshqa jamoalarga (qo‘ng‘iroqda bo‘lmagan) zarur vaqt haqidagi bahosiga asoslanib, qulaylik uchun maqsadlarni o‘zgartirishdan ogohlantirdi.

Amaliy muammo — hard forklar tezligini qanday yaxshilash. Testlar orasidagi oraliqlarni qisqartirish forklarni tezlashtirishi mumkin, lekin bu pastki jamoalarning shoshilinch yangilanishlar chiqarish xavfini oshiradi. Qarshi fikr shuki, uzoq pipeline’lar navbatdagi barcha ishlarni kechiktiradi, bu esa keng Ethereum hamjamiyatini norozi qilishi mumkin.

“Menimcha, biz jadvalni faqat hamjamiyat xohishiga qarab tanlamasligimiz kerak,” dedi Lightclient. “Dasturiy ta’minotni chiqarayotgan odamlar, hamjamiyat foydalanadigan yuqori sifatli dasturiy ta’minotni yetkazib berish uchun 30 kun kerakligini aytishdi.”

Shunga qaramay, biroz tortishuvli almashuv jarayonni yozma ravishda saqlash tarafiga og‘di, agar manfaatdor tomonlar o‘zgarishni aniq so‘ramasa.

Har bir siklda bir xil savolga qayta murojaat qilinishidan ham norozilik bo‘ldi. “Menimcha, qarorlarni doim o‘zgartirish juda yomon odat,” dedi Lightclient, ilova ishlab chiquvchilari va L2’lar odatda asosiy qo‘ng‘iroqlarda bo‘lmasligini va o‘z relizlarini rejalashtirish uchun barqaror muddatlarga tayanishini ta’kidladi.

Hozircha, konsensus 30 kunlik bufer amal qilayotgandek harakat qilish, shu bilan birga faol ravishda yangi fikrlarni yig‘ish tarafida, dedi muvofiqlashtiruvchi Tim Beiko. “Biz jadvalni [jarayon] hujjatidagi kabi tayyorlashimiz va parallel ravishda ta’sir ko‘rsatilgan manfaatdor tomonlar bilan tekshirishimiz kerak.” Agar tezlashtirilgan yo‘l haqiqatan keng qo‘llab-quvvatlansa, guruh buni yozma ravishda rasmiylashtiradi.