Glamsterdam nâng cấp, câu trả lời mở rộng L1 của Ethereum

Gốc | Odaily Sao Hỏa nhật báo jk

Cập nhật Glamsterdam sắp tới của Ethereum, được coi là cuộc tái cấu trúc cấp độ giao thức lớn nhất trong mắt các nhà phát triển cốt lõi kể từ The Merge. Tên gọi này được tạo thành từ hai phần: phần nâng cấp lớp thực thi sử dụng "Amsterdam", lấy từ địa điểm tổ chức Devconnect trước đây là Amsterdam; 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. Sau nâng cấp Fusaka trước đó, Glamsterdam thúc đẩy mở rộng 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 đang ngày càng phát triển, từ đó cập nhật cách Ethereum tạo và xác minh khối một cách căn bản.

Cuộc 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 ghi lại mối quan hệ dữ liệu, cho phép xử lý an toàn nhiều giao dịch đồng thời, thay vì xử lý tuần tự chậm chạp từng giao dịch một.
• Mở rộng: Phân chia công việc nặng nề của việc tạo và xác minh khối, cho phép mạng có nhiều thời gian hơn để truyền tải một lượng lớn dữ liệu mà không bị giả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 cho 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 chính của nâng cấp lần này nằm ở lớp đồng thuận và lớp thực thi:

Có hai đề xuất Headliner lớn. Nguồn: Ethereum

Đề xuất chính thứ nhất: ePBS, biến "nhà trung gian bên ngoài" thành "quy tắc tích hợp"

Đầu tiên nói về đề xuất chính ở lớp đồng thuận, tách biệt giữa người đề xuất và người xây dựng, viết tắt bằng tiếng Anh là ePBS (EIP-7732).

Mỗi lần Ethereum tạo khối, thực tế chia thành hai bước: một người phụ trách "chọn khối nào" (người đề xuất), một người khác phụ trách "thực sự lắp ráp 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 được quy định bởi giao thức Ethereum, mà dựa vào một nhóm "công ty trung gian" bên ngoài (gọi là trung gian) để thực hiện. Mối quan hệ bên ngoài này còn tạo ra một con đường trong quá trình xác minh khối, buộc các xác minh viên phải hoàn thành việc phát sóng và thực hiện giao dịch trong khoảng thời gian 2 giây căng thẳng, hạn chế lượng dữ liệu mà mạng có thể xử lý. Ví dụ, điều này giống như một nhà hàng có quy trình đặt món và nấu ăn, vốn cần một người kết nối bên ngoài độc lập để phối hợp việc phục vụ món ăn, một khi người kết nối này gặp trục trặc, bếp và quầy tiếp tân có thể không khớp với nhau.

Điều ePBS làm là đưa quy tắc phân công "đặt món - nấu ăn" này vào trong sổ tay quy định hoạt động của nhà hàng, không còn phụ thuộc vào người kết nối bên ngoài. Như vậy, cơ chế giao 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 giao thức, do đó không còn cần phụ thuộc vào phần mềm trung gian bên thứ ba, tuy nhiên nếu 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 sử dụng người kết nối bên ngoài. Đồng thời, để không làm cho quy trình "phục vụ món ăn" trở nên lộn xộn, ePBS còn thiết lập một "nhóm kiểm tra món ăn", kiểm tra "ai đã đặt món" và "món ăn có được phục vụ đúng giờ không", khoảng thời gian 2 giây cho việc phục vụ món ăn cũng vì vậy mà được mở rộng lên khoảng 9 giây, cho phép nhà hàng xử lý nhiều đơn hàng hơn một lần, cũng có nghĩa là Ethereum có thể chứa nhiều dữ liệu hơn hướng tới Layer2.

Đề xuất chính thứ hai: BALs, lập danh sách "mua sắm" trước khi khởi hành

Tiếp theo là đề xuất chính ở lớp thực thi, danh sách truy cập cấp khối, viết tắt bằng tiếng Anh là BALs (EIP-7928).

Hiện tại, cách Ethereum xử lý giao dịch có phần giống như một người bị bịt mắt đi siêu thị mua sắm: phải sờ thấy một sản phẩm, xác nhận đó là gì, mới có thể quyết định bước tiếp theo, vì vậy chỉ có thể xếp hàng từng món một. Bởi 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ụ như sẽ 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ự nghiêm ngặt, nếu không hai giao dịch có thể vô tình 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.

BALs giống như việc cho phép người này trước khi khởi hành, nhận được một danh sách mua sắm ghi rõ "các kệ hàng cần đến, những món cần lấy". Với danh sách này, hệ thống có thể nhìn thấy trước những giao dịch nào hoàn toàn không "đụng độ" nhau, từ đó có thể chia các giao dịch không liên quan thành nhiều nhóm, và xử lý 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 nút mới tham gia vào mạng, có thể sao chép trực tiếp kết quả cuối cùng ghi 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, do đó nút mới sẽ đồng bộ nhanh hơn rất 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 thực sự chia sẻ những 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 cho tất cả các khách hàng lớp thực thi.

Đề xuất hỗ trợ: tính toán lại phí "chiếm chỗ"

Ngoài hai đề xuất chính này, Glamsterdam còn đóng gói hai đề xuất định giá lại, 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.

• Đề xuất đầu tiên là các hoạt động như tạo tài khoản, triển khai hợp đồng 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ế mà nó chiếm dụng, bây giờ sẽ được tính phí lại theo "mỗi không gian chiếm dụng sẽ 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 là 120 GiB mỗi năm, đảm bảo rằng với phần cứng thông thường vẫn có thể duy trì hoạt động của mạng này. Đồng thời, phí lưu trữ này sẽ được mở một tài khoản riêng để tính toán, không còn trộn lẫn với phí tính toán của giao dịch, chỉ cần 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, phức tạp hơn mà không bị giới hạn bởi tổng giới hạn Gas.
• Đề xuất thứ hai là các hoạt động như truy vấn, đọc dữ liệu đã có trong mạng, trước đây định giá quá thấp, không theo kịp chi phí truy vấn thực tế sau khi khối lượng dữ liệu tăng lên, lần này sẽ tăng tiêu chuẩn phí cho các mã hoạt động 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 ai đó lợi dụng phí quá rẻ, cố tình gửi nhiều yêu cầu truy vấn để làm tắc nghẽn mạng.

Thời gian ra mắt mạng chính: hiện chưa có thời gian cụ thể

Về thời gian, Glamsterdam hiện đang ở một giai đoạn khá nhạy cảm. Ở cấp độ chính thức, cuộc họp toàn thể các nhà phát triển cốt lõi lần thứ 241 gần đây nhất có thể xác minh được 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 Devnet của Glamsterdam, cũng như bầu chọn đề xuất chính cho lần nâng cấp tiếp theo Hegota. Một lịch trình được ngành công nghiệp trích dẫn rộng rãi trước đó cho thấy, giai đoạn Devnet đã trải qua tám 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, sau đó, phân nhánh mạng thử nghiệm Sepolia dự kiến vào ngày 3 tháng 8 năm 2026, phân nhánh mạng thử nghiệm 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

Nhưng từ những động thái 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ạng thử nghiệm ngắn hạn công cộng đầu tiên mang tên Plataberget, được thiết kế đặc biệt cho Glamsterdam, việc triển khai chính thức của Sepolia và Hoodi dự kiến sẽ bị hoãn đến tháng 9, mục tiêu ra mắt mạng chính cũng sẽ được 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 sau khi đã hoãn từ 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 chính xác của nâng cấp quan trọng hơn việc phải kịp thời vào bất kỳ ngày cụ thể nào, vì vậy trước khi cuộc họp ACD chính thức xác định chiều cao khối cụ thể, chúng ta có thể phải chờ đến quý 4 hoặc thậm chí cuối năm mới thấy được nâng cấp này.