Tác giả | jk
Bản nâng cấp Glamsterdam sắp tới của Ethereum, được các nhà phát triển cốt lõi coi là đợt tái cấu trúc cấp giao thức có phạm vi thay đổi lớn nhất kể từ sau The Merge. Tên gọi 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 "Amsterdam", lấy cảm hứng từ địa điểm tổ chức Devconnect trước đây là thành phố Amsterdam; phần nâng cấp lớp đồng thuận thì đượ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 mở rộng quy mô L1 bằng cách tái cấu trúc cách mạng xử lý giao dịch và quản lý cơ sở dữ liệu ngày càng phát triển của nó, cập nhật một cách căn bản phương thức Ethereum tạo và xác thực các khối.
Đợt nâng cấp này tập trung vào 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 ghi lại các phụ thuộc dữ liệu, cho phép nó xử lý an toàn một lượng lớn giao dịch đồng thời, 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ỏ công việc nặng nhọc của việc tạo và xác thực khối, cho mạng nhiều thời gian hơn để truyền tải một lượng dữ liệu lớn hơn mà không làm chậm tốc độ.
- 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 lâu dài của việc lưu trữ dữ liệu mới, dọn đường cho việc nâng cao giới hạn Gas trong tương lai, đồng thời tránh tình trạng suy giảm hiệu suất phần cứng.
Hai đề xuất trọng tâm của đợt nâng cấp lần lượt thuộc về lớp đồng thuận và lớp thực thi:

Có hai đề xuất Headliner (trọng tâm). Nguồn: Ethereum
Đề xuất trọng tâm thứ nhất: ePBS, biến "bên trung gian thuê ngoài" thành "quy tắc tích hợp sẵn"
Đầu tiên nói về đề xuất trọng tâm của 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 tiếng Anh là ePBS (EIP-7732).
Mỗi lần Ethereum tạo một khối, thực chất được chia làm hai bước: một người phụ trách việc "chọn khối nào" (người đề xuất), một người khác phụ trách việc "thực sự lắp ráp 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à phải dựa vào một loạt "công ty trung gian" ngoài chuỗi (tiếng lóng gọi là relay) để ghép nối hoàn thành. Mối quan hệ ngoài chuỗi này cũng tạo ra một đường dẫ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 thành việc phát và thực thi giao dịch trong cửa sổ thời gian căng thẳng 2 giây, hạn chế lượng dữ liệu mạng có thể xử lý. Ví dụ, điều này giống như việc một nhà hàng, khâu tiếp nhận đơn hàng và khâu chế biến món ăn, ban đầu phải dựa vào một người liên lạc bên ngoài độc lập để phối hợp truyền món ăn, một khi người liên lạc này trục trặc, bếp và quầy thanh toán có thể không khớp với nhau.
ePBS làm việc, chính là đưa bộ quy tắc phân công "nhận đơn - nấu ăn" này, viết vào sổ tay quy trình vận hành của chính nhà hàng, không còn phụ thuộc vào người liên lạc bên ngoài. Bằng cách này, cơ chế phân phối khối và thanh toán đáng tin cậy trên chuỗi được xây dựng trực tiếp vào chính giao thức, từ đó không còn cần dựa vào 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ố tính năng phức tạp chưa được quy định trong giao thức, vẫn có thể lựa chọn tiếp tục sử dụng người liên lạc bên ngoài. Đồng thời, để không còn làm khâu "truyền món" trở nên lộn xộn, ePBS còn đặc biệt thành lập một "nhóm kiểm tra món ăn", lần lượt kiểm tra hai việc "ai đã đặt món" và "món ăn có được làm kịp thời và lên bàn không", cửa sổ thời gian truyền món 2 giây trước đây cũng vì thế được mở rộng thành khoảng 9 giây, cho phép nhà hàng xử lý nhiều đơn hàng hơn cùng một lúc, tức là cho phép Ethereum mang theo nhiều dữ liệu hơn hướng tới Layer 2.
Đề xuất trọng tâm thứ hai: BALs, trước khi xuất phát hãy liệt kê sẵn "danh sách mua sắm"
Tiếp theo nói về đề xuất trọng tâm của lớp thực thi, Danh sách truy cập cấp độ khối, viết tắt tiếng Anh là BALs (EIP-7928).
Cách Ethereum xử lý giao dịch hiện tại, hơi giống như một người bịt mắt đi siêu thị mua đồ: trước tiên phải sờ đến một món hàng, xác nhận là gì, mới có thể quyết định bước tiếp theo đi thế nào, vì vậy chỉ có thể xếp hàng 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, ví dụ liên quan đến những tài khoản nào, hệ thống phải xử lý giao dịch theo thứ tự từng giao dịch một cách nghiêm ngặt, nếu không hai giao dịch có thể vô tình đồng thời muốn sửa đổi cùng một dữ liệu (ví dụ số dư của cùng một địa chỉ), gây ra xung đột lỗi.
BALs tương đương với việc để người này trước khi xuất phát, nhận được một "danh sách mua sắm" ghi rõ "sẽ đến kệ nào, sẽ lấy món đồ nào". Có danh sách này, hệ thống từ trước đã có thể nhìn ra những giao dịch nào hoàn toàn không "đánh nhau" với nhau, vì vậy có thể chia các giao dịch không liên quan với nhau thành vài nhóm, xử lý đồng thời song song, mà 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, có thể sao chép trực tiếp kết quả cuối cùng được ghi lại trong danh sách này, mà không cần phải tính toán lại tất cả các giao dịch lịch sử phức tạp, như vậy nút mới đồng bộ tiến độ sẽ nhanh hơn nhiều. Để phối hợp với danh sách này thực sự lưu thông trong mạng, Glamsterdam còn đóng gói một nâng cấp giao thức truyền tải đi kèm, cho phép các nút có thể thực sự chia 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 thao tác "chiếm chỗ"
Ngoài hai đề xuất trọng tâm này, Glamsterdam còn đóng gói hai đề xuất đi kèm định giá lại, có thể hiểu là đã điều chỉnh bảng giá riêng cho "phí lưu kho" và "phí truy vấn" của mạng.
- Đề xuất thứ nhất: Đối với 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 sẽ "chiếm chỗ vĩnh viễn" trong mạng, phí trước đây không tương xứng với không gian thực tế nó chiếm dụng, bây giờ sẽ tính phí theo nguyên tắc "mỗi phần không gian chiếm dụng thì thu phí tương ứng", mục tiêu là kiểm soát tốc độ tăng trưởng dữ liệu của toàn mạng ở mức an toàn, có thể dự đoán được là 120 GiB mỗi năm, đảm bảo rằng phần cứng thông thường cũng có thể tiếp tục vận hành mạng này. Đồng thời, khoản phí lưu kho này sẽ được tính toán riêng trong một tài khoản, không còn trộn lẫn với phí tính toán xử lý giao dịch, chỉ cần nhà phát triển sẵn sàng trả thêm một chút phí lưu kho, vẫn có thể triển khai các ứng dụng quy mô lớn hơn, phức tạp hơn, không bị giới hạn Gas tổng cộng chặn lại ngay lập tức.
- Đề xuất thứ hai: Đối với các thao tác như truy vấn, đọc dữ liệu đã có trong mạng, định giá trước đây thấp, không theo kịp chi phí truy vấn thực tế sau khi lượng dữ liệu tăng lên như hiện nay, lần này sẽ nâng tiêu chuẩn thu phí cho loại opcode này, để giá cả gần hơn với tình trạng tải thực tế của phần cứng hiện đại, đồng thời cũng có thể ngăn chặn việc có người lợi dụng giá quá rẻ, cố ý dùng một lượng lớn yêu cầu truy vấn để làm tắc nghẽn mạng.
Thời gian triển khai mạng chính: Hiện tại vẫn chưa xác định
Về mặt lịch trình, Glamsterdam hiện đang ở trong một giai đoạn khá tinh tế. Về mặt chính thức, lần họp tất cả nhà phát triển cốt lõi lớp thực thi (ACDE) gần đây nhất có thể kiểm chứng là lần thứ 241, vào ngày 16 tháng 7, 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 Devnet Glamsterdam, và bỏ phiếu chọn đề xuất trọng tâm cho đợt nâng cấp tiếp theo Hegota. Một lịch trình được trích dẫn rộng rãi trong ngành trước đây cho thấy, giai đoạn Devnet đã trải qua tám vòng lặp từ 0 đến 7, thời gian 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 đó hard fork mạng testnet Sepolia dự kiến vào ngày 3 tháng 8 năm 2026, hard fork mạng testnet Hoodi dự kiến vào ngày 17 tháng 8 năm 2026, ngày mục tiêu kích hoạt mạng chính là ngày 16 tháng 9 năm 2026.

Lịch trình ban đầu là nửa đầu năm 2026, Nguồn: Ethereum
Tuy nhiên, từ các động thái mới nhất, lịch trình này nhiều khả năng đã bị lùi lại. Đội ngũ EthPandaOps gần đây đã ra mắt mạng testnet công cộng ngắn hạn mới có tên là Plataberget, đây là mạng testnet công cộng đầu tiên được thiết kế riêng cho Glamsterdam, việc triển khai chính thức Sepolia và Hoodi dự kiến sẽ bị hoãn lại đến tháng 9 mới theo kịp, mục tiêu ra mắt mạng chính cũng tương ứng lùi lại đến quý 4 năm 2026. Đây cũng là lần thứ hai Glamsterdam xuất hiện sự trượt ngày kể từ khi trước đó bị lùi từ nửa đầu năm 2026 theo dự kiến ban đầu. Các nhà phát triển cốt lõi trước đây đã nhiều lần nhấn mạnh, tính chính xác của việc nâng cấp được ưu tiên hơn việc kịp bất kỳ ngày cụ thể nào, do đó trước khi cuộc họp ACD chính thức khóa độ cao khối cụ thể, chúng ta có thể phải đến quý 4 hoặc thậm chí cuối năm mới thấy được đợt nâng cấp này.







