Bây giờ, chúng ta bàn về mở rộng quy mô.
Có hai nhóm chính: ngắn hạn và dài hạn.
Về mở rộng quy mô ngắn hạn, tôi đã trình bày ở nơi khác. Cụ thể như sau:
Danh sách truy cập ở cấp khối (sẽ triển khai trong Glamsterdam) cho phép xác thực các khối song song.
ePBS (sẽ triển khai trong Glamsterdam) có nhiều tính năng, trong đó một điểm nổi bật là cho phép sử dụng an toàn phần lớn thời gian của mỗi slot (thay vì chỉ vài trăm mili giây) để xác thực khối.
Việc điều chỉnh lại giá gas đảm bảo chi phí gas của từng thao tác phù hợp với thời gian thực thi thực tế (và các chi phí khác liên quan). Chúng tôi cũng đang thử nghiệm sớm với gas đa chiều, bảo đảm mỗi loại tài nguyên có giới hạn riêng biệt. Cả hai cơ chế này đều giúp tận dụng phần lớn hơn của mỗi slot để xác thực khối mà không lo các trường hợp ngoại lệ.
Việc triển khai gas đa chiều sẽ theo lộ trình nhiều giai đoạn.
Đầu tiên, tại Glamsterdam, chúng tôi tách riêng chi phí “tạo trạng thái” và chi phí “thực thi và calldata”. Hiện tại, một lệnh SSTORE thay đổi slot từ khác 0 sang khác 0 mất 5.000 gas, còn thay đổi từ 0 sang khác 0 mất 20.000 gas. Một trong các điều chỉnh giá gas ở Glamsterdam sẽ tăng mạnh phần chênh lệch này (ví dụ lên 60.000); mục tiêu của chúng tôi khi thực hiện điều này cùng với tăng giới hạn gas là mở rộng năng lực thực thi nhiều hơn năng lực mở rộng kích thước trạng thái, lý do đã được tôi phân tích trước đây (
g-state-by-creating-new-forms-of-state/24052
). Vì vậy, tại Glamsterdam, lệnh SSTORE đó sẽ tính 5.000 gas “thông thường” và (ví dụ) 55.000 gas “tạo trạng thái”.
Gas tạo trạng thái sẽ KHÔNG được tính vào giới hạn gas giao dịch khoảng 16 triệu, nên việc tạo hợp đồng lớn (quy mô lớn hơn hiện nay) sẽ khả thi.
Một thách thức đặt ra là: cơ chế này vận hành thế nào trong EVM? Các opcode EVM (GAS, CALL…) đều giả định chỉ có một chiều gas. Giải pháp của chúng tôi là duy trì hai bất biến:
Nếu bạn thực hiện một call với X gas, call đó sẽ có X gas sử dụng cho “thông thường” HOẶC “tạo trạng thái” HOẶC các chiều khác trong tương lai
Nếu bạn gọi opcode GAS, nó trả về bạn Y gas, sau đó bạn thực hiện một call với X gas, bạn vẫn còn ít nhất Y-X gas, có thể dùng cho bất kỳ chức năng nào, sau khi call để thực hiện các thao tác tiếp theo
Chúng tôi xây dựng N+1 “chiều” gas, mặc định N=1 (tạo trạng thái), chiều bổ sung gọi là “reservoir”. Quá trình thực thi EVM mặc định sẽ ưu tiên tiêu thụ các chiều “chuyên biệt” nếu có thể, còn lại sẽ lấy từ reservoir. Ví dụ, nếu bạn có (100.000 gas tạo trạng thái, 100.000 reservoir), khi bạn dùng SSTORE để tạo trạng thái mới ba lần, lượng gas còn lại sẽ lần lượt là (100.000, 100.000) -> (45.000, 95.000) -> (0, 80.000) -> (0, 20.000). GAS trả về reservoir. CALL chuyển tiếp lượng gas chỉ định từ reservoir, cộng với toàn bộ gas không thuộc reservoir.
Sau đó, chúng tôi sẽ áp dụng định giá đa chiều, nơi các chiều khác nhau có thể có giá gas thả nổi riêng biệt. Điều này giúp đảm bảo sự bền vững kinh tế dài hạn và tối ưu hóa hiệu quả (tham khảo
vitalik.eth.limo/general/2024/0
). Cơ chế reservoir giải quyết vấn đề sub-call đề cập ở cuối bài viết đó.
Với mở rộng quy mô dài hạn, có hai trụ cột: ZK-EVM và blobs.
Với blobs, kế hoạch là tiếp tục cải tiến PeerDAS, hướng tới trạng thái cuối cùng lý tưởng có thể xử lý khoảng 8 MB/giây dữ liệu. Như vậy là đủ cho nhu cầu của Ethereum, không nhằm trở thành một lớp dữ liệu toàn cầu. Hiện tại, blobs chủ yếu phục vụ các L2. Trong tương lai, dữ liệu khối Ethereum sẽ được đưa trực tiếp vào blobs. Điều này cần thiết để ai đó có thể xác thực một chuỗi Ethereum đã mở rộng quy mô lớn mà không cần tự tải và thực thi lại: ZK-SNARKs loại bỏ nhu cầu thực thi lại, còn PeerDAS trên blobs giúp xác thực tính khả dụng mà không cần tự tải dữ liệu.
Với ZK-EVM, mục tiêu là từng bước nâng cao “mức độ yên tâm” khi dựa vào nó:
Khách hàng cho phép bạn tham gia với vai trò attester sử dụng ZK-EVM sẽ xuất hiện vào năm 2026. Chúng chưa đủ an toàn để mạng lưới vận hành hoàn toàn trên đó, nhưng ví dụ 5% mạng dựa vào chúng thì ổn. (Nếu ZK-EVM gặp sự cố, bạn không bị slashed, chỉ có rủi ro xây dựng trên khối không hợp lệ và mất doanh thu)
Năm 2027, chúng tôi sẽ khuyến nghị một bộ phận lớn hơn của mạng vận hành trên ZK-EVM, đồng thời tập trung xác minh hình thức, tối đa hóa bảo mật, v.v. Ngay cả khi chỉ 20% mạng chạy ZK-EVM cũng giúp tăng mạnh gaslimit, vì như vậy có thể nâng gaslimit cao mà vẫn có lối đi rẻ cho solo staker, vốn dưới 20%.
Khi sẵn sàng, chúng tôi sẽ chuyển sang mô hình chứng minh bắt buộc 3 trên 5. Để một khối hợp lệ, cần có 3 trong 5 loại bằng chứng từ các hệ thống khác nhau. Đến lúc này, chúng tôi kỳ vọng tất cả các node (trừ node cần lập chỉ mục) sẽ dựa vào bằng chứng ZK-EVM.
Tiếp tục cải tiến ZK-EVM, làm cho nó ngày càng mạnh, được xác minh hình thức, v.v. Điều này cũng sẽ liên quan đến các nỗ lực thay đổi VM (ví dụ RISC-V)





