Ethereum Nhắm Đến Ngày 6 Tháng 10 Để Kích Hoạt Nâng Cấp Glamsterdam Trên Sepolia

6 giờ trước đây
11 phút đọc
5 lượt xem

Nâng cấp Glamsterdam trên Ethereum

Các nhà phát triển Ethereum đã tạm thời lên lịch cho việc nâng cấp Glamsterdam được kích hoạt trên mạng thử nghiệm Sepolia vào lúc 13:53 UTC vào ngày 6 tháng 10 năm 2026. Tuy nhiên, một bài kiểm tra devnet riêng vẫn cần được thực hiện trước khi nhánh thử nghiệm công cộng có thể tiến hành.

Ghi chú từ cuộc họp ACDC #186 và báo cáo tiếp theo từ nhà nghiên cứu giao thức Ethereum, Christine D. Kim, cho thấy rằng ngày này vẫn còn phụ thuộc vào các điều kiện nhất định.

Các nhà phát triển vẫn chưa hoàn tất việc kích hoạt Glamsterdam ổn định trên một mạng phát triển riêng khi họ quyết định lịch trình cho Sepolia. Kế hoạch thử nghiệm đã tiến triển thêm một bước. Kim cho biết vào ngày 11 tháng 9 rằng sự chú ý đã chuyển sang Glamsterdam-Devnet-11, dự kiến sẽ ra mắt vào thứ Hai, ngày 14 tháng 9. Các kế hoạch trước đó đã xác định Devnet-10 là bài kiểm tra lớn tiếp theo.

Đã khoảng một tuần kể từ khi bài viết này được gửi đến các người đăng ký Substack của tôi, và các điều kiện về ngày nâng cấp thử nghiệm Sepolia vào ngày 6 tháng 10 vẫn còn hiệu lực. Cập nhật nhỏ duy nhất bây giờ là tất cả mọi ánh mắt đang hướng về việc ra mắt Glam-Devnet-11 vào thứ Hai tới, không phải Devnet-10.

Điều kiện và thảo luận về mạng chính

Ngày kích hoạt vẫn chưa được xác nhận cho mạng thử nghiệm Hoodi hoặc mạng chính Ethereum. Các nhà phát triển đã thảo luận về khả năng phát hành mạng chính vào tháng 12, nhưng kết quả thử nghiệm sẽ xác định xem lịch trình đó có thực tế hay không.

Trong cuộc họp đồng thuận của tất cả các nhà phát triển cốt lõi vào ngày 3 tháng 9, các thành viên đã đồng ý về epoch 351232 của Sepolia cho việc kích hoạt đề xuất.

Kim báo cáo rằng thời gian tương ứng sẽ là ngày 6 tháng 10 lúc 13:53 UTC. Cuộc họp diễn ra trước khi các nhà phát triển chứng minh hiệu suất ổn định trên các mạng thử nghiệm riêng được sử dụng cho Glamsterdam.

Việc chọn epoch cung cấp cho các nhóm khách hàng, nhà điều hành hạ tầng và các nhà phát triển ứng dụng một mục tiêu lập kế hoạch chung, nhưng không đảm bảo việc kích hoạt sẽ diễn ra như dự kiến. Các nhà phát triển có thể hoãn nhánh nếu giai đoạn thử nghiệm tiếp theo phát hiện ra một lỗi lớn hoặc nếu các nhóm khách hàng không thể chuẩn bị các bản phát hành đáng tin cậy.

Thử nghiệm và các vấn đề phát sinh

Điều kiện này vẫn còn liên quan sau khi Devnet-9 gặp phải các vấn đề về tính cuối cùng. Theo tài liệu cuộc họp, mạng này bao gồm khoảng 1.000 nút xác thực, khiến nó trở thành devnet Glamsterdam lớn nhất theo số lượng xác thực tại thời điểm đó. Tính cuối cùng yêu cầu đủ các xác thực đồng ý về trạng thái của chuỗi.

Khi một mạng thử nghiệm không thể hoàn tất, các nhà phát triển phải xác định xem nguyên nhân có liên quan đến phần mềm khách hàng, sự tham gia của các xác thực, cấu hình mạng hay một tương tác giữa các thay đổi giao thức riêng biệt.

Kế hoạch ban đầu đã gọi cho Devnet-10 sau khi xuất hiện các lỗi trong các thử nghiệm trước đó. Cập nhật mới nhất của Kim hiện xác định Devnet-11 là bài kiểm tra tiếp theo mà các nhà phát triển đang theo dõi, cho thấy rằng chuỗi thử nghiệm riêng đã tiến triển vượt ra ngoài kế hoạch trước đó.

Một Devnet-11 ổn định sẽ cung cấp cho các nhóm khách hàng Ethereum một môi trường khác để thử nghiệm các thông số kết hợp của Glamsterdam. Các nhóm layer-2, nhà cung cấp staking và các nhà điều hành hạ tầng khác cần các triển khai khách hàng hoạt động trước khi họ có thể an toàn thử nghiệm hệ thống của mình với nhánh đề xuất.

Sự đa dạng của khách hàng làm cho quá trình này trở nên phức tạp hơn. Ethereum hoạt động thông qua một số khách hàng thực thi và đồng thuận được phát triển độc lập, và việc nâng cấp phải hoạt động trên các tổ hợp khách hàng khác nhau.

Một lỗi chỉ giới hạn trong một triển khai vẫn có thể làm gián đoạn một mạng thử nghiệm khi các xác thực bị ảnh hưởng nắm giữ đủ trọng số. Chương trình nghị sự ACDC #186 ghi nhận các yêu cầu từ LidoOptimism cho ít nhất một ngày ổn định trước khi nhánh.

Kết luận và hướng đi tiếp theo

Chương trình nghị sự đã liệt kê các sửa lỗi khách hàng và khả năng tương tác thành công là những vấn đề cần xác nhận trước Sepolia. Một Devnet-11 thất bại hoặc không ổn định sẽ không tự động hủy bỏ việc kích hoạt vào ngày 6 tháng 10. Các nhà phát triển sẽ cần đánh giá nguyên nhân và thời gian cần thiết để sửa chữa.

Một vấn đề nghiêm trọng có thể khiến họ xem xét lại ngày trong một cuộc họp của tất cả các nhà phát triển cốt lõi. Các thử nghiệm Glamsterdam trước đó đã phát hiện ra các lỗi ở cả hai bên của kiến trúc Ethereum.

Kỹ sư vận hành phát triển Ethereum Foundation, Stefan Starflinger, báo cáo rằng Devnet-8 đã tiết lộ một vấn đề ở lớp đồng thuận liên quan đến các khối lặp lại một băm cha mẹ. “Bạn có thể khiến toàn bộ mạng dừng lại,” Starflinger nói khi mô tả kịch bản thử nghiệm.

Vấn đề này ảnh hưởng đến hệ thống chịu trách nhiệm cho sự đồng thuận khối. Devnet-9 sau đó đã gặp phải tình trạng không hoàn tất, khiến các kỹ sư phải điều tra thêm nhiều trường hợp biên trong một tập hợp xác thực lớn hơn.

Ở phía thực thi, nhà nghiên cứu Ethereum Foundation, Maria Silva, báo cáo một vấn đề triển khai liên quan đến EIP-8037. Đề xuất này thay đổi cách Ethereum tính phí gas cho việc tạo ra trạng thái mới, bao gồm các tài khoản, hợp đồng và mục lưu trữ mới.

EIP-8037 tách biệt chi phí tạo trạng thái khỏi chi phí thực thi bình thường thông qua một mô hình gas đa chiều. Đặc điểm đã công bố của nó cho biết thiết kế nhằm kiểm soát sự tăng trưởng trạng thái khi Ethereum nâng giới hạn gas khối của mình. Đề xuất vẫn đang trong quá trình xem xét đồng nghiệp.

Vấn đề được phát hiện yêu cầu các khách hàng thực thi phải sửa đổi các triển khai của họ và dẫn đến công việc về đặc điểm. Như crypto.news đã báo cáo trong việc đưa tin về tiến trình devnet trước đó của Glamsterdam, EIP-8037 đã được thử nghiệm cùng với các thay đổi giao thức khác của nâng cấp.

Thử nghiệm phục vụ một mục đích khác với việc phê duyệt từng đề xuất một cách riêng lẻ. Các nhà phát triển phải xác nhận rằng tất cả các thay đổi được chọn hoạt động cùng nhau trên nhiều khách hàng, cấu hình xác thực và mẫu giao dịch.

Các nhà phát triển đã từ chối lên lịch Glamsterdam trên Hoodi trong khi Sepolia vẫn còn điều kiện. Hoodi dự kiến sẽ phục vụ như một giai đoạn thử nghiệm công cộng thứ hai, cung cấp cho các nhà điều hành staking và các nhóm giao thức một môi trường khác gần gũi hơn với điều kiện mạng chính.

Nhà phát triển Teku, Enrico del Fante, đã ủng hộ việc chờ đợi trước khi sửa ngày Hoodi. Trong cuộc họp ACDC #186, ông đã đề cập đến các vấn đề gần đây của Devnet-9 và ủng hộ việc cho phép thêm thời gian thử nghiệm sau quyết định Sepolia.

Một việc kích hoạt mạng chính vào tháng 12 vẫn là một mục tiêu khả thi, không phải là một khoảng thời gian ra mắt đã được xác nhận. Việc lên lịch Sepolia vào đầu tháng 10 giữ đủ thời gian lịch cho một giai đoạn thử nghiệm công cộng khác và chuẩn bị phát hành khách hàng, miễn là thử nghiệm tiến triển mà không có sự chậm trễ kéo dài.

Các nhà phát triển chưa công bố một epoch mạng chính, dấu thời gian kích hoạt hoặc lịch phát hành khách hàng cuối cùng. Không có thời hạn chính thức nào được công bố cho việc quyết định xem ngày 6 tháng 10 có còn phù hợp cho Sepolia hay không.

Sự kiện quy trình ngay lập tức là việc ra mắt Devnet-11 dự kiến vào ngày 14 tháng 9. Các nhóm khách hàng sẽ xem xét tính cuối cùng, hành vi giữa các khách hàng và các sửa chữa được giới thiệu sau các thử nghiệm trước đó trước khi quyết định xem Sepolia có thể tiến hành theo lịch trình hiện tại hay không.