Bản nâng cấp Glamsterdam trên Hoodi dự kiến diễn ra vào ngày 26 tháng 10 năm 2026, lúc 17:42:48 UTC, với giới hạn gas của testnet tăng lên 200 triệu tại cùng epoch kích hoạt. Sau khi Glamsterdam được kích hoạt trên Sepolia vào ngày 6 tháng 10, đợt triển khai tiếp theo yêu cầu các nhà vận hành Hoodi cập nhật cả client thực thi lẫn client đồng thuận. Thông báo ngày 16 tháng 10 của Ethereum Foundation không ấn định ngày triển khai trên mainnet.
Điểm chính
- Hoodi dự kiến được kích hoạt ở epoch 132,352 và slot 4,235,264, đồng thời giới hạn gas tăng lên 200 triệu.
- Các trình xác thực Hoodi phải cập nhật client thực thi, beacon node đồng thuận và client trình xác thực, đồng thời xem xét các nhiệm vụ mới liên quan đến builder.
- Các nhà phát triển nên kiểm thử các giả định về gas và việc ước tính gas theo các quy tắc sửa đổi; người dùng và nhà vận hành mainnet không cần thực hiện hành động nào theo thông báo này.
Mục lục
Lịch trình Glamsterdam Hoodi và tình trạng triển khai
Hoodi là đợt triển khai testnet tiếp theo theo lịch trình của Glamsterdam, bản nâng cấp kết hợp nâng cấp lớp thực thi Amsterdam với nâng cấp lớp đồng thuận Gloas. Giới hạn gas dự kiến là 200 triệu, bằng với mức của Sepolia.
Thông báo Glamsterdam Hoodi của Ethereum Foundation phân biệt thời hạn triển khai testnet này với việc triển khai trên mainnet. Các nhóm phát triển client chưa quyết định thời điểm kích hoạt trên mainnet, và các bản phát hành tương thích với mainnet sẽ được thông báo riêng.
| Hạng mục |
Chi tiết |
| Triển khai trên Sepolia |
Đã kích hoạt vào ngày 6 tháng 10 năm 2026, lúc 13:53:36 UTC; epoch 353,024, slot 11,296,768. |
| Triển khai trên Hoodi |
Dự kiến vào ngày 26 tháng 10 năm 2026, lúc 17:42:48 UTC; epoch 132,352, slot 4,235,264. |
| Giới hạn gas của Hoodi |
Dự kiến tăng lên 200 triệu tại epoch kích hoạt, bằng với mức của Sepolia. |
| Triển khai trên mainnet |
Ngày kích hoạt chưa được quyết định; thông báo này không lên lịch nâng cấp mainnet. |
Những gì nhà vận hành Hoodi cần cập nhật
Trước khi kích hoạt, các node không tham gia staking cần có client thực thi và đồng thuận tương thích. Các trình xác thực cũng phải bảo đảm cả beacon node lẫn client trình xác thực của họ đã được cập nhật. Phần mềm không hỗ trợ các quy tắc mới sẽ không thể theo dõi mạng sau nâng cấp.
Thông báo liệt kê các bản phát hành lớp đồng thuận của Grandine, Lighthouse, Lodestar, Nimbus, Prysm và Teku. Bảng client thực thi nêu phiên bản của Besu, Ethrex và Nethermind, trong khi Erigon, go-ethereum và Reth chưa có phiên bản được liệt kê. Nhà vận hành chỉ nên chọn các bản phát hành có ghi chú xác nhận rõ ràng rằng chúng hỗ trợ đợt kích hoạt Hoodi theo lịch trình.
Bảng công cụ liệt kê commit-boost 0.12.0-rc1. Hướng dẫn bổ sung về khả năng tương thích của builder và trình xác thực vẫn đang chờ xác nhận. Nhà vận hành sử dụng hạ tầng xây dựng block bên ngoài nên xem hướng dẫn Glamsterdam của hạ tầng đó, cùng với hướng dẫn của client về mục tiêu giới hạn gas của trình xác thực.
Vì sao quy trình builder và xác thực thay đổi
Đối với các nhóm trình xác thực và builder, mức độ sẵn sàng không chỉ đơn thuần là cài đặt tệp nhị phân.
EIP-7732, cơ chế tách biệt proposer-builder được tích hợp vào giao thức, đưa ra các trách nhiệm được giao thức quy định cho một quy trình trước đây phụ thuộc nhiều hơn vào middleware đáng tin cậy. Các nhóm cần kiểm tra công cụ của mình để bảo đảm đáp ứng các nhiệm vụ và giao diện mới.
Theo quy trình này, proposer cam kết với payload thực thi của builder trước khi builder công bố payload đó. Giao thức Ethereum quản lý khoản thanh toán cho proposer, trong khi một ủy ban giám sát tính kịp thời của payload kiểm tra việc công bố đúng hạn và khả năng cung cấp dữ liệu blob. Việc tách các kiểm tra đồng thuận khỏi kiểm tra thực thi cũng giúp trình xác thực có thêm thời gian đánh giá payload thực thi.
Thay đổi đáng chú ý còn lại, EIP-7928, hướng đến công việc xác thực của client. Danh sách truy cập cấp block bắt buộc xác định các tài khoản và vùng lưu trữ được block tác động đến, đồng thời ghi nhận các thay đổi trạng thái sau giao dịch. Client có thể sử dụng thông tin đó để xử lý song song việc đọc đĩa và xác thực giao dịch, cũng như tính toán state root hiệu quả hơn. Kết hợp lại, các thay đổi này hỗ trợ năng lực thực thi cao hơn, đồng thời giữ cho việc xác thực vẫn khả thi đối với nhà vận hành node.
Các nội dung ứng dụng cần tập trung kiểm thử
Việc định giá lại gas khiến các giả định trong hợp đồng trở thành ưu tiên kiểm thử. EIP-8037 tăng chi phí tạo trạng thái và tính phí riêng cho khoản này, trong khi EIP-8038 thay đổi chi phí truy cập trạng thái. Các thay đổi khác theo lịch trình ảnh hưởng đến lượng gas cơ bản của giao dịch, calldata, danh sách truy cập và cách hạch toán gas của block.
Các hợp đồng sử dụng mức gas cấp cố định, giới hạn được mã hóa cứng hoặc giả định về lượng gas còn lại có thể cần điều chỉnh. Nhà phát triển nên dùng hướng dẫn về tác động của việc định giá lại để xác định các hợp đồng bị ảnh hưởng và kiểm thử việc ước tính gas trên Sepolia cũng như, sau khi kích hoạt, trên Hoodi.
Việc kiểm thử cũng nên bao quát các thay đổi liên quan đến log, opcode và giao diện client. Các bổ sung theo lịch trình gồm log chuyển ETH, opcode số slot, giới hạn kích thước hợp đồng tối đa cao hơn và một hợp đồng factory xác định.
Kết luận
Thời hạn trước mắt áp dụng cho hạ tầng Hoodi: các client và công cụ tương thích phải sẵn sàng trước ngày 26 tháng 10. Nhà phát triển có một đợt triển khai testnet để kiểm tra hành vi của ứng dụng, trong khi việc kích hoạt trên mainnet vẫn là bước riêng và chưa được lên lịch.
Đọc thêm tin tức
Tin tức khác từ FinanceVelix
Tuyên bố miễn trừ trách nhiệm
Bài viết FinanceVelix này cung cấp thông tin chung, không phải lời khuyên tài chính, đầu tư, pháp lý hoặc thuế dành riêng cho từng cá nhân. Giá tiền mã hóa có thể biến động nhanh và bạn có thể mất toàn bộ số tiền đã đầu tư. Các thông tin phản ánh tài liệu có tại thời điểm xuất bản và có thể thay đổi. Hãy tự xác minh các thông tin quan trọng và tham khảo chuyên gia đủ năng lực khi cần. Việc đề cập đến một tài sản, công ty hoặc dịch vụ không đồng nghĩa với sự xác nhận hay khuyến nghị.
