以太坊Glamsterdam升级：最大规模底层重构，主网日期仍悬而未决

Bài viết gốc: Odaily 星球日报 (@OdailyChina)

Tác giả: jk

Bản nâng cấp Glamsterdam sắp tới của Ethereum, theo đánh giá của các nhà phát triển cốt lõi, là cuộc tái cấu trúc giao thức lớn nhất kể từ The Merge. Cái tên này là sự kết hợp của hai phần: phần nâng cấp lớp thực thi tiếp tục sử dụng tên "Amsterdam", lấy từ thành phố đăng cai Devconnect kỳ trước; phần nâng cấp lớp đồng thuận được đặt tên là "Gloas", theo tên một ngôi sao. Tiếp nối bản nâng cấp Fusaka trước đó, Glamsterdam thúc đẩy khả năng mở rộng L1 bằng cách tái cơ cấu cách mạng lưới xử lý các giao dịch và quản lý cơ sở dữ liệu đang ngày càng phình to của mình, qua đó cập nhật một cách căn bản cách thức Ethereum tạo và xác thực các khối.

Bản nâng cấp này xoay quanh ba mục tiêu cốt lõi:

• Tăng tốc xử lý (song song hóa): Tái cấu trúc cách mạng lưới ghi lại các mối quan hệ phụ thuộc dữ liệu, cho phép xử lý an toàn một lượng lớn giao dịch cùng lúc, thay vì xử lý tuần tự từng giao dịch một cách chậm chạp.
• Mở rộng quy mô: Chia nhỏ khối lượng công việc nặng nề của việc tạo và xác thực khối, giúp mạng lưới có thêm thời gian để truyền tải một lượng dữ liệu lớn hơn mà không bị chậm lại.
• Tính bền vững: Điều chỉnh phí mạng để phản ánh chính xác chi phí phần cứng dài hạn của việc lưu trữ dữ liệu mới, dọn đường cho việc nâng giới hạn Gas trong tương lai, đồng thời tránh suy giảm hiệu suất phần cứng.

Hai đề xuất nổi bật (Headliner) của bản nâng cấp lần lượt nằm ở lớp đồng thuận và lớp thực thi:

Có hai đề xuất Headliner (đầu bảng). Nguồn: Ethereum

Đề xuất Headliner 1: ePBS - Biến "nhà môi giới trung gian" thành "quy tắc nội tại"

Trước tiên là đề xuất headliner ở lớp đồng thuận: Tách biệt người đề xuất và người xây dựng trong giao thức, viết tắt là ePBS (EIP-7732).

Mỗi lần Ethereum tạo khối thực chất diễn ra hai bước: một người chịu trách nhiệm "chọn khối nào" (người đề xuất), người kia chịu trách nhiệm "lắp ráp thực tế các giao dịch trong khối" (người xây dựng). Hiện tại, sự phân công này không phải do chính giao thức Ethereum quy định, mà được thực hiện thông qua một nhóm "công ty trung gian" ngoài chuỗi (thuật ngữ chuyên môn gọi là relay) để môi giới. Mối quan hệ ngoài chuỗi này còn tạo ra một đường truyền trong quá trình xác thực khối, buộc người xác thực phải vội vàng hoàn tất việc phát sóng và thực thi giao dịch trong một cửa sổ 2 giây căng thẳng, hạn chế lượng dữ liệu mạng lưới có thể xử lý. Ví dụ, điều này giống như một nhà hàng có khâu gọi món và nấu ăn, vốn phải dựa vào một người điều phối bên ngoài độc lập để chuyển món; nếu người điều phối này trục trặc, bếp và khu vực phục vụ khách có thể không khớp được với nhau.

Điều ePBS làm là đưa bộ quy tắc phân công "gọi món - nấu ăn" này vào sổ tay vận hành của chính nhà hàng, không còn phụ thuộc vào người điều phối bên ngoài. Nhờ vậy, cơ chế giao nhận và thanh toán khối đáng tin cậy trên chuỗi được xây dựng trực tiếp vào giao thức, không còn cần đến phần mềm trung gian của bên thứ ba. Tuy nhiên, nếu cả hai bên muốn sử dụng một số chức năng phức tạp chưa được quy định trong giao thức, họ vẫn có thể chọn tiếp tục dùng người điều phối bên ngoài. Đồng thời, để khâu "chuyển món" không còn luống cuống, ePBS còn thành lập một "nhóm kiểm tra món ăn" chuyên trách, lần lượt kiểm tra "ai đã gọi món" và "món ăn đã được làm xong và bưng ra đúng giờ hay chưa". Cửa sổ thời gian chuyển món 2 giây ban đầu nhờ đó được mở rộng lên khoảng 9 giây, giúp nhà hàng có thể xử lý nhiều đơn hàng hơn trong một lần, tức là giúp Ethereum có thể chuyên chở nhiều dữ liệu hơn cho Layer 2.

Đề xuất Headliner 2: BALs - Lên "danh sách mua sắm" trước khi khởi hành

Tiếp theo là đề xuất headliner ở lớp thực thi: Danh sách truy cập cấp khối, viết tắt là BALs (EIP-7928).

Cách Ethereum xử lý giao dịch hiện tại giống như một người bị bịt mắt đi siêu thị: phải sờ được một món hàng, xác nhận nó là gì, mới quyết định được bước tiếp theo, vì vậy chỉ có thể xếp hàng mua từng món một. Vì không biết trước một giao dịch sẽ sử dụng những dữ liệu nào, chẳng hạn như sẽ liên quan đến những tài khoản nào, hệ thống buộc phải xử lý từng giao dịch một cách tuần tự nghiêm ngặt, nếu không hai giao dịch có thể vô tình cùng muốn sửa đổi cùng một dữ liệu (ví dụ như số dư của cùng một địa chỉ), gây ra xung đột và lỗi.

BALs tương đương với việc cho người này một danh sách mua sắm ghi rõ "cần đi đến kệ nào, lấy những món gì" trước khi khởi hành. Với danh sách này, hệ thống có thể biết trước những giao dịch nào hoàn toàn không ảnh hưởng lẫn nhau, do đó có thể chia các giao dịch không liên quan thành nhiều nhóm và xử lý song song cùng lúc, không cần phải xếp hàng từng món một. Danh sách này còn có một lợi ích bổ sung: khi một nút mới tham gia mạng lưới, nó có thể trực tiếp sao chép kết quả cuối cùng được ghi trong danh sách này mà không cần phải tính toán lại toàn bộ lịch sử giao dịch phức tạp, nhờ đó quá trình đồng bộ của nút mới sẽ nhanh hơn rất nhiều. Để danh sách này thực sự lưu thông trong mạng lưới, Glamsterdam còn đi kèm một bản nâng cấp giao thức truyền tải, cho phép các nút chia sẻ thực sự các danh sách truy cập này. Giao thức truyền tải này hiện đã trở thành yêu cầu bắt buộc đối với tất cả các client lớp thực thi.

Đề xuất đi kèm: Tính toán lại chi phí cho các thao tác "chiếm chỗ"

Ngoài hai đề xuất headliner, Glamsterdam còn đóng gói thêm hai đề xuất đi kèm về việc định giá lại, có thể hiểu là điều chỉnh bảng giá cho "phí lưu kho" và "phí tra cứu" của mạng lưới.

• Đề xuất đầu tiên áp dụng cho các thao tác như tạo tài khoản mới, triển khai hợp đồng – những thao tác "chiếm chỗ vĩnh viễn" trong mạng lưới. Trước đây, mức phí không tương xứng với không gian thực tế mà chúng chiếm dụng; nay sẽ được tính phí lại theo nguyên tắc "chiếm bao nhiêu không gian thì trả bấy nhiêu tiền", với mục tiêu kiểm soát tốc độ tăng trưởng dữ liệu tổng thể của mạng lưới ở mức an toàn và có thể dự đoán được là 120 GiB mỗi năm, đảm bảo mạng lưới vẫn có thể vận hành liên tục trên phần cứng thông thường. Đồng thời, khoản phí lưu trữ này sẽ được hạch toán riêng trong một tài khoản, không còn trộn lẫn với chi phí tính toán của việc xử lý giao dịch. Miễn là nhà phát triển sẵn sàng trả thêm phí lưu trữ, họ vẫn có thể triển khai các ứng dụng có quy mô lớn hơn và phức tạp hơn mà không bị giới hạn bởi tổng giới hạn Gas một cách đột ngột.
• Đề xuất thứ hai áp dụng cho các thao tác tra cứu, đọc dữ liệu đã tồn tại trong mạng lưới. Trước đây, mức giá này được định giá thấp, không theo kịp chi phí tra cứu thực tế khi lượng dữ liệu ngày càng lớn; lần này sẽ tăng mức phí cho các opcode loại này, giúp giá cả phản ánh sát hơn tải trọng thực tế của phần cứng hiện đại, đồng thời ngăn chặn việc lợi dụng phí quá rẻ để cố tình dùng một lượng lớn yêu cầu tra cứu làm nghẽn mạng lưới.

Thời điểm lên mainnet: Hiện vẫn chưa được chốt

Về mặt lịch trình, Glamsterdam hiện đang ở một giai đoạn khá tế nhị. Về phía chính thức, cuộc họp các nhà phát triển cốt lõi lớp thực thi (ACDE) gần nhất có thể xác minh là lần thứ 241, diễn ra vào ngày 16 tháng 7, với chương trình nghị sự chính bao gồm báo cáo tiến độ mới nhất của giai đoạn Glamsterdam Devnet, cũng như bỏ phiếu chọn đề xuất headliner cho bản nâng cấp tiếp theo Hegota. Một lịch trình được giới trong ngành trích dẫn rộng rãi trước đó cho thấy, giai đoạn Devnet có tổng cộng 8 vòng lặp từ 0 đến 7, kéo dài từ ngày 28 tháng 3 năm 2026 đến ngày 8 tháng 7 năm 2026. Sau đó, việc fork của testnet Sepolia dự kiến ban đầu vào ngày 3 tháng 8 năm 2026, fork của testnet Hoodi dự kiến ban đầu vào ngày 17 tháng 8 năm 2026, và ngày mục tiêu kích hoạt mainnet là 16 tháng 9 năm 2026.

Lịch trình ban đầu dự kiến trong nửa đầu năm 2026, Nguồn: Ethereum

Tuy nhiên, nhìn từ những diễn biến mới nhất, lịch trình này rất có thể đã bị đẩy lùi. Nhóm EthPandaOps gần đây đã ra mắt một testnet mới tên là Plataberget, đây là testnet công khai ngắn hạn đầu tiên được thiết kế riêng cho Glamsterdam. Việc triển khai chính thức trên Sepolia và Hoodi dự kiến sẽ bị hoãn đến tháng 9 mới tiến hành, và mục tiêu lên mainnet cũng tương ứng bị dời sang quý 4 năm 2026. Đây là lần thứ hai lịch trình của Glamsterdam bị trượt, sau khi trước đó từng bị hoãn khỏi mục tiêu ban đầu là nửa đầu năm 2026. Các nhà phát triển cốt lõi đã nhiều lần nhấn mạnh rằng tính đúng đắn của bản nâng cấp được ưu tiên hơn việc chạy đua với bất kỳ mốc thời gian cụ thể nào. Vì vậy, trước khi cuộc họp ACD chính thức chốt số block cụ thể, chúng ta có thể phải đợi đến quý 4 hoặc thậm chí cuối năm mới có thể thấy bản nâng cấp này.