Nâng cấp Glamsterdam, giải pháp mở rộng quy mô L1 của Ethereum.

Bản gốc | Odaily Planet Daily jk

Bản nâng cấp Glamsterdam sắp tới cho Ethereum được các nhà phát triển cốt lõi coi là cuộc tái cấu trúc cấp độ giao thức lớn nhất kể từ The Merge. Tên gọi này xuất phát từ sự kết hợp của hai phần: bản nâng cấp lớp thực thi vẫn giữ tên "Amsterdam", được đặt theo tên địa điểm của các sự kiện Devconnect trước đó; bả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ổ chức lại cách mạng lưới xử lý các giao dịch và quản lý cơ sở dữ liệu ngày càng tăng của nó, về cơ bản cập nhật cách Ethereum tạo và xác minh các khối.

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

• Xử lý tăng tốc (Song song hóa): Tổ chức lại 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ý chậm từng giao dịch một.
• Khả năng mở rộng: Phân chia khối lượng công việc nặng nề của việc tạo và xác minh khối, giúp mạng có thêm thời gian để truyền tải 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 cho việc lưu trữ dữ liệu mới, loại bỏ các trở ngại cho việc tăng giới hạn Gas trong tương lai đồng thời tránh làm giảm hiệu suất phần cứng.

Hai đề xuất chính của bản nâng cấp tập trung vào lớp đồng thuận và lớp thực thi:

Có hai đề xuất chính về Headliner. Nguồn: Ethereum

Đề xuất nổi bật thứ nhất: ePBS, Biến "các trung gian thuê ngoài" thành "các quy tắc nội tại"

Trước tiên, chúng ta hãy thảo luận về đề xuất chính cho lớp đồng thuận, phân tách người đề xuất và người xây dựng trong giao thức, được viết tắt trong tiếng Anh là ePBS (EIP-7732).

Mỗi khi Ethereum tạo ra một khối, thực tế nó bao gồm hai bước: một người chịu trách nhiệm "chọn khối nào" (người đề xuất), và một người khác chịu trách nhiệm "thực sự tập hợp các giao dịch trong khối" (người xây dựng). Hiện tại, sự phân công lao động này không được quy định rõ ràng trong chính giao thức Ethereum, mà dựa vào một nhóm các "công ty trung gian" ngoài chuỗi (thường được gọi là các relay) để tạo điều kiện thuận lợi cho quá trình này. Mối quan hệ ngoài chuỗi này cũng tạo ra một luồng xử lý trong quá trình xác minh khối, buộc các trình xác thực phải nhanh chóng hoàn thành việc phát sóng và thực thi giao dịch trong một khoảng thời gian 2 giây ngắn ngủi, hạn chế lượng dữ liệu mà mạng có thể xử lý. Ví dụ, điều này tương tự như một nhà hàng, nơi quy trình đặt món và nấu nướng dựa vào một bên trung gian độc lập bên ngoài để điều phối việc giao món ăn; nếu bên trung gian này gặp sự cố, nhà bếp và quầy lễ tân có thể không phối hợp nhịp nhàng.

Điều mà ePBS thực hiện là tích hợp sự phân công lao động "đặt hàng - nấu nướng" vào sổ tay vận hành của nhà hàng, không còn phụ thuộc vào các bên trung gian bên ngoài. Kết quả là, một cơ chế giao hàng và thanh toán khối trên chuỗi đáng tin cậy được tích hợp trực tiếp vào chính giao thức, loại bỏ nhu cầu về 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 quay lại sử dụng các bên trung gian bên ngoài. Ngoài ra, để ngăn chặn sự hỗn loạn trong giai đoạn "giao hàng", ePBS đã thiết lập một "đội ngũ xác minh món ăn" để kiểm tra "ai đã đặt hàng" và "món ăn đã được chuẩn bị đúng giờ hay chưa", do đó mở rộng khung thời gian giao hàng ban đầu là 2 giây lên khoảng 9 giây, cho phép nhà hàng xử lý nhiều đơn hàng cùng một lúc, điều này có nghĩa là Ethereum có thể chứa nhiều dữ liệu hơn hướng đến Lớp 2.

Đề xuất chính thứ hai: BALs, Chuẩn bị "Danh sách mua sắm" trước khi khởi hành

Tiếp theo, chúng ta hãy thảo luận về đề xuất chính cho lớp thực thi, đó là danh sách truy cập cấp khối, viết tắt là BAL (EIP-7928).

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

BAL cho phép người dùng có được danh sách mua sắm ghi rõ "cần đến kệ nào và lấy mặt hàng nào" trước khi họ bắt đầu di chuyển. Với danh sách này, hệ thống có thể biết trước những giao dịch nào sẽ không "xung đột" với nhau, cho phép nhóm các giao dịch không liên quan lại với nhau và xử lý song song thay vì xếp hàng từng giao dịch một. Danh sách này cũng có một lợi ích bổ sung: khi các nút mới tham gia mạng, chúng có thể trực tiếp sao ché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, giúp tăng tốc đáng kể quá trình đồng bộ hóa cho các nút mới. Để tạo điều kiện thuận lợi cho việc lưu hành danh sách này trong mạng, Glamsterdam cũng đã đóng gói bản nâng cấp giao thức truyền tải tương ứng cho phép các nút thực sự chia sẻ các danh sách truy cập này, điều này hiện đã trở thành yêu cầu bắt buộc đối với tất cả các máy khách lớp thực thi.

Các đề xuất hỗ trợ: Đánh giá lại các hoạt động "chiếm không gian".

Ngoài hai đề xuất chính nêu trên, Glamsterdam cũng đã đưa ra hai đề xuất hỗ trợ về việc điều chỉnh giá, có thể hiểu là điều chỉnh bảng giá cho "phí lưu trữ" và "phí truy vấn" của mạng lưới.

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

Ngày ra mắt Mainnet: Chưa được xác định

Về tiến độ, Glamsterdam hiện đang ở trong một giai đoạn khá nhạy cảm. Về mặt chính thức, cuộc họp gần đây nhất có thể xác minh được của tất cả các nhà phát triển cốt lõi cho lớp thực thi (ACDE) là cuộc họp thứ 241, được tổ chức vào ngày 16 tháng 7, với chương trình nghị sự chính bao gồm cập nhật về giai đoạn Devnet của Glamsterdam và lựa chọn các đề xuất nổi bật cho bản nâng cấp tiếp theo, Hegota. Một lịch trình được tham khảo rộng rãi trong ngành cho thấy giai đoạn Devnet đã trải qua tám lần lặp lại 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, tiếp theo là việc phân nhánh mạng thử nghiệm Sepolia ban đầu được lên kế hoạch vào ngày 3 tháng 8 năm 2026, và việc phân nhánh mạng thử nghiệm Hoodi ban đầu được lên kế hoạch vào ngày 17 tháng 8 năm 2026, với ngày mục tiêu kích hoạt mạng chính được đặt ra là ngày 16 tháng 9 năm 2026.

Theo lịch trình ban đầu, dự kiến vào nửa đầu năm 2026. Nguồn: Ethereum.

Tuy nhiên, dựa trên những diễn biến mới nhất, lịch trình này có khả năng đã bị hoãn lại. Nhóm EthPandaOps gần đây đã ra mắt một testnet mới có tên 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 Sepolia và Hoodi dự kiến sẽ bị trì hoãn đến tháng 9, và mục tiêu ra mắt mainnet cũng được chuyển sang quý 4 năm 2026. Điều này đánh dấu lần thứ hai tiến độ của Glamsterdam bị chậm trễ, sau lần hoãn trước đó từ nửa đầu năm 2026 theo kế hoạch ban đầu. Các nhà phát triển cốt lõi đã nhiều lần nhấn mạnh rằng tính chính xác của bản nâng cấp được ưu tiên hơn việc đáp ứng bất kỳ ngày cụ thể nào, vì vậy cho đến khi chiều cao khối cụ thể được chốt trong cuộc họp ACD chính thức, chúng ta có thể sẽ không thấy bản nâng cấp này cho đến quý 4 hoặc thậm chí là cuối năm nay.