Các nhà phát triển cốt lõi của Ethereum tranh cãi về quy trình, mốc thời gian Fusaka

Cuộc họp All Core Devs mới nhất của Ethereum tập trung vào quy trình, không chỉ là mã nguồn: liệu có nên tuân thủ khoảng thời gian 30 ngày đã được công bố trước đó giữa các bản phát hành client và lần fork testnet đầu tiên khi nâng cấp Fusaka đang tiến triển. Một số thành viên thúc đẩy việc tái khẳng định cam kết này để các đội ngũ hạ tầng và ứng dụng có thời gian thích nghi; những người khác lại cho rằng cần linh hoạt để tránh làm chậm tiến độ tổng thể của lộ trình.

Cuộc tranh luận diễn ra trong bối cảnh kết quả devnet có phần trái chiều. Trên Devnet-3, một bài kiểm tra không-finality theo kế hoạch đã kéo dài hơn dự kiến, theo Barnabas Busa từ đội ngũ Dev Ops. “Chúng tôi dự định thực hiện khoảng hai ngày đầu tiên, và bây giờ đã sang ngày thứ năm,” anh nói, lưu ý rằng tỷ lệ tham gia đã giảm xuống rồi lại tăng lên trên 50%. Để đạt được finality cần hơn hai phần ba tổng số stake hiệu quả đồng ý.

Ngược lại, một testnet khác đã phục hồi nhanh chóng sau khi khởi động lại đồng bộ: “Chuỗi đã phục hồi trong vòng, tôi nghĩ là hai giờ,” Busa cho biết. Bài kiểm tra này nhằm kiểm tra áp lực về cách các biến số tương tác trong một sự cố thực tế, điều này có thể giúp Ethereum phục hồi khi gặp khủng hoảng.

Đọc thêm: Nâng cấp Fusaka của Ethereum có thể bị trì hoãn

Với các bản sửa lỗi sẽ được triển khai trong vài ngày tới, kế hoạch ngắn hạn là khôi phục Devnet-3 về trạng thái hoạt động hoàn chỉnh, chạy lại bài kiểm tra và sau đó khởi động Devnet-5.

Tuy nhiên, điểm nóng lớn hơn là kỷ luật lên lịch cho các mạng công khai. Lightclient nhấn mạnh cam kết hiện tại: “Tài liệu có ghi rõ 30 ngày trước testnet đầu tiên.” Anh cảnh báo không nên thay đổi mục tiêu chỉ vì tiện lợi, dựa trên đánh giá của các core devs về thời gian mà các đội nhóm khác (không có mặt trong cuộc gọi) cần.

Mối quan tâm thực tế là làm thế nào để cải thiện nhịp độ của các đợt hard fork. Rút ngắn khoảng cách giữa các lần kiểm thử có thể đẩy nhanh tiến độ fork, nhưng cũng làm tăng nguy cơ các đội nhóm phía dưới phải phát hành cập nhật vội vàng. Lập luận ngược lại là việc kéo dài quy trình sẽ làm trì hoãn mọi thứ khác trong hàng đợi, điều mà cộng đồng Ethereum rộng lớn hơn có thể không hài lòng.

“Tôi không nghĩ chúng ta nên chọn mốc thời gian chỉ dựa trên những gì cộng đồng muốn,” Lightclient nói. “Những người phát hành phần mềm đã nói rằng họ muốn 30 ngày để cung cấp phần mềm chất lượng cao mà cộng đồng sẽ sử dụng.”

Dù vậy, cuộc trao đổi có phần căng thẳng này đã nghiêng về việc giữ nguyên quy trình đã được ghi chép trừ khi các bên liên quan yêu cầu thay đổi một cách rõ ràng.

Cũng có sự thất vọng khi phải lặp lại cùng một câu hỏi ở mỗi chu kỳ. “Tôi nghĩ rằng việc liên tục thay đổi quyết định là một tiền lệ rất xấu,” Lightclient nói, lưu ý rằng các nhà phát triển ứng dụng và L2 thường không tham gia các cuộc gọi core và họ dựa vào các khoảng thời gian dự đoán được để lên lịch phát hành của riêng mình.

Hiện tại, sự đồng thuận là tiếp tục như thể khoảng đệm 30 ngày vẫn còn hiệu lực, đồng thời chủ động lấy ý kiến mới, điều phối viên Tim Beiko cho biết. “Chúng ta nên chuẩn bị lịch trình theo những gì có trong tài liệu [quy trình] và song song đó kiểm tra với các bên liên quan bị ảnh hưởng.” Nếu một lộ trình nhanh hơn thực sự nhận được sự ủng hộ rộng rãi, nhóm sẽ chính thức hóa điều đó bằng văn bản.