Bài viết mới của Vitalik: Tương lai có thể của giao thức Ethereum - The Verge

Thực tế, chúng ta cần nhiều năm nữa mới có thể đạt được bằng chứng tính hợp lệ của đồng thuận Ethereum.

Tiêu đề gốc: 《Possible futures of the Ethereum protocol, part 4: The Verge》

Tác giả: Vitalik Buterin

Biên dịch: Mensh, ChainCatcher

 

Đặc biệt cảm ơn Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams và Uma Roy đã phản hồi và duyệt bài.

Một trong những tính năng mạnh mẽ nhất của blockchain là bất kỳ ai cũng có thể chạy một node trên máy tính của mình và xác minh tính đúng đắn của blockchain. Ngay cả khi 9596 node đang chạy đồng thuận chuỗi (PoW, PoS) đều đồng ý thay đổi quy tắc ngay lập tức và bắt đầu sản xuất block theo quy tắc mới, thì bất kỳ ai đang chạy node xác minh đầy đủ đều sẽ từ chối chuỗi đó. Những người tạo coin không thuộc nhóm âm mưu này sẽ tự động tập trung vào một chuỗi tiếp tục tuân theo quy tắc cũ và tiếp tục xây dựng chuỗi đó, còn người dùng xác minh đầy đủ sẽ đi theo chuỗi này.

Đây là điểm khác biệt then chốt giữa blockchain và hệ thống tập trung. Tuy nhiên, để tính năng này thực sự tồn tại, việc chạy một node xác minh đầy đủ cần phải khả thi đối với đủ nhiều người. Điều này áp dụng cho cả người tạo block (vì nếu họ không xác minh chuỗi, họ không đóng góp vào việc thực thi quy tắc giao thức) lẫn người dùng thông thường. Ngày nay, việc chạy node trên laptop tiêu dùng (bao gồm cả chiếc laptop tôi đang dùng để viết bài này) là khả thi, nhưng thực sự rất khó khăn. The Verge nhằm thay đổi điều này, làm cho chi phí tính toán xác minh chuỗi đầy đủ trở nên rẻ, để mọi ví điện thoại, ví trình duyệt thậm chí đồng hồ thông minh đều mặc định xác minh.

Lộ trình The Verge 2023

Ban đầu, "Verge" đề cập đến việc chuyển lưu trữ trạng thái Ethereum sang cây Verkle — một cấu trúc cây cho phép bằng chứng gọn nhẹ hơn, có thể thực hiện xác minh block Ethereum không trạng thái. Node có thể xác minh một block Ethereum mà không cần lưu trữ bất kỳ trạng thái Ethereum nào (số dư tài khoản, mã hợp đồng, không gian lưu trữ...) trên ổ cứng, đổi lại là phải xử lý vài trăm KB dữ liệu bằng chứng và vài trăm mili giây thời gian bổ sung để xác minh một bằng chứng. Ngày nay, Verge đại diện cho một tầm nhìn lớn hơn, tập trung vào việc đạt được xác minh hiệu quả tài nguyên tối đa cho chuỗi Ethereum, bao gồm không chỉ công nghệ xác minh không trạng thái mà còn sử dụng SNARK để xác minh toàn bộ thực thi Ethereum.

Bên cạnh việc tập trung lâu dài vào xác minh toàn bộ chuỗi bằng SNARK, một vấn đề mới khác là liệu cây Verkle có phải là công nghệ tối ưu nhất không. Cây Verkle dễ bị tấn công bởi máy tính lượng tử, vì vậy nếu chúng ta thay thế cây KECCAK Merkle Patricia hiện tại bằng cây Verkle, sau này chúng ta vẫn phải thay thế cây một lần nữa. Phương pháp tự thay thế của cây Merkle là bỏ qua việc sử dụng nhánh Merkle, thay vào đó dùng STARK, đặt nó vào cây nhị phân. Trong lịch sử, phương pháp này bị coi là không khả thi do chi phí và độ phức tạp kỹ thuật. Tuy nhiên gần đây, chúng ta thấy Starkware đã sử dụng ckcle STARKs trên một laptop để chứng minh 1,7 triệu hàm băm Poseidon mỗi giây, và nhờ các công nghệ như GKB, thời gian chứng minh các hàm băm "truyền thống" cũng đang giảm nhanh chóng. Vì vậy, trong năm qua, "Verge" đã trở nên cởi mở hơn, với nhiều khả năng khác nhau.

The Verge: Mục tiêu then chốt

• Khách hàng không trạng thái: không gian lưu trữ cần thiết cho khách hàng xác minh đầy đủ và node đánh dấu không nên vượt quá vài GB.
• (Dài hạn) Xác minh đầy đủ chuỗi (đồng thuận và thực thi) trên đồng hồ thông minh. Tải về một số dữ liệu, xác minh SNARK, xong.

Trong chương này

• Khách hàng không trạng thái: Verkle hay STARKs
• Bằng chứng tính hợp lệ thực thi EVM
• Bằng chứng tính hợp lệ đồng thuận

Xác minh không trạng thái: Verkle hay STARKs

Chúng ta cần giải quyết vấn đề gì?

Ngày nay, client Ethereum cần lưu trữ hàng trăm GB dữ liệu trạng thái để xác minh block, và con số này tăng lên mỗi năm. Dữ liệu trạng thái gốc tăng khoảng 30GB mỗi năm, mỗi client phải lưu thêm một số dữ liệu bổ sung để cập nhật bộ ba hiệu quả.

Điều này làm giảm số lượng người dùng có thể chạy node xác minh đầy đủ Ethereum: mặc dù ổ cứng lớn đủ để lưu trữ toàn bộ trạng thái Ethereum thậm chí nhiều năm lịch sử rất phổ biến, nhưng máy tính mà người ta mua mặc định thường chỉ có vài trăm GB lưu trữ. Kích thước trạng thái cũng gây ra ma sát lớn khi thiết lập node lần đầu: node phải tải toàn bộ trạng thái, có thể mất hàng giờ hoặc hàng ngày. Điều này tạo ra nhiều hệ quả dây chuyền. Ví dụ, nó làm tăng đáng kể độ khó khi nhà sản xuất node nâng cấp cấu hình node của mình. Về mặt kỹ thuật, có thể nâng cấp mà không dừng hoạt động — khởi động một client mới, chờ đồng bộ, sau đó tắt client cũ và chuyển khóa — nhưng trên thực tế, điều này rất phức tạp về mặt kỹ thuật.

Nó hoạt động như thế nào?

Xác minh không trạng thái là một kỹ thuật cho phép node xác minh block mà không cần nắm toàn bộ trạng thái. Thay vào đó, mỗi block đi kèm một bằng chứng, bao gồm: (i) giá trị, mã, số dư, lưu trữ tại các vị trí cụ thể trong trạng thái mà block sẽ truy cập; (ii) bằng chứng mật mã chứng minh các giá trị này là đúng.

Trên thực tế, để thực hiện xác minh không trạng thái cần thay đổi cấu trúc cây trạng thái của Ethereum. Bởi vì cây Merkle Patricia hiện tại cực kỳ không thân thiện với bất kỳ sơ đồ bằng chứng mật mã nào, đặc biệt là trong trường hợp xấu nhất. Dù là nhánh Merkle "gốc" hay khả năng "bọc" thành STARK đều như vậy. Khó khăn chính xuất phát từ một số điểm yếu của MPT:

1. Đây là cây 16 nhánh (mỗi node có 16 node con). Điều này có nghĩa, trong cây kích thước N, một bằng chứng trung bình cần 32*(16-1)*log16(N) = 120*log2(N) byte, hoặc khoảng 3840 byte với cây 2^32 mục. Với cây nhị phân, chỉ cần 32*(2-1)*log2(N) = 32*log2(N) byte, khoảng 1024 byte.

2. Mã không được Merkle hóa. Điều này có nghĩa để chứng minh quyền truy cập mã tài khoản, cần cung cấp toàn bộ mã, tối đa 24000 byte.

 

Chúng ta có thể tính trường hợp xấu nhất như sau:

30000000 gas / 2400 (chi phí đọc tài khoản lạnh) * (5 * 488 + 24000) = 330000000 byte

Chi phí nhánh giảm nhẹ (dùng 5*480 thay vì 8*480), vì khi có nhiều nhánh, phần đỉnh của chúng bị lặp lại. Nhưng dù vậy, lượng dữ liệu cần tải trong một slot là hoàn toàn phi thực tế. Nếu chúng ta cố gắng bọc nó bằng STARK, sẽ gặp hai vấn đề: (i) KECCAK không thân thiện với STARK; (ii) 330MB dữ liệu nghĩa là phải chứng minh 5 triệu lần gọi hàm KECCAK round, điều này vượt quá khả năng của hầu hết phần cứng tiêu dùng, ngay cả khi chúng ta làm cho STARK chứng minh KECCAK hiệu quả hơn.

Nếu chúng ta thay cây 16 nhánh bằng cây nhị phân và Merkle hóa mã bổ sung, thì trường hợp xấu nhất sẽ là 30000000/2400*32*(32-14+8) = 10400000 byte (14 là số bit dư thừa cho 2^14 nhánh, 8 là độ dài bằng chứng vào lá mã). Lưu ý, điều này cần thay đổi chi phí gas, tính phí cho mỗi khối mã riêng biệt; EIP-4762 làm như vậy. 10.4 MB tốt hơn nhiều, nhưng với nhiều node, tải dữ liệu này trong một slot vẫn quá nhiều. Do đó, chúng ta cần công nghệ mạnh hơn. Có hai giải pháp hàng đầu: cây Verkle và cây băm nhị phân STARKed.

Cây Verkle

Cây Verkle sử dụng cam kết vector dựa trên elliptic curve để tạo bằng chứng ngắn hơn. Chìa khóa là, bất kể độ rộng cây, mỗi phần bằng chứng cha-con chỉ 32 byte. Giới hạn duy nhất về độ rộng cây là nếu cây quá rộng, hiệu suất tính toán bằng chứng giảm. Đề xuất cho Ethereum là độ rộng 256.

Vì vậy, kích thước nhánh đơn lẻ trong bằng chứng là 32 - log256(N) = 4*log2(N) byte. Do đó, kích thước bằng chứng tối đa lý thuyết là 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 byte (do phân bố trạng thái không đều, kết quả thực tế hơi khác, nhưng gần đúng là được).

Lưu ý thêm, trong tất cả ví dụ trên, "trường hợp xấu nhất" này chưa phải là tệ nhất: tệ hơn là kẻ tấn công cố tình "đào" hai địa chỉ có tiền tố chung dài trong cây, rồi đọc dữ liệu từ một địa chỉ, có thể làm nhánh dài gấp đôi. Nhưng ngay cả vậy, bằng chứng xấu nhất của cây Verkle là 2.6MB, tương đương dữ liệu kiểm tra xấu nhất hiện nay.

Chúng ta cũng tận dụng điều này để làm một việc khác: làm cho chi phí truy cập không gian lưu trữ "liền kề" rất rẻ: nhiều khối mã của cùng hợp đồng hoặc các slot lưu trữ liền kề. EIP-4762 định nghĩa adjacency, chỉ tính phí 200 gas cho truy cập liền kề. Trong trường hợp này, kích thước bằng chứng xấu nhất là 30000000 / 200*32 - 4800800 byte, vẫn trong phạm vi chấp nhận được. Nếu muốn giảm thêm, có thể tăng nhẹ phí truy cập liền kề.

Cây băm nhị phân STARKed

Kỹ thuật này rất rõ ràng: chỉ cần làm một cây nhị phân, lấy bằng chứng tối đa 10.4 MB, chứng minh giá trị trong block, sau đó dùng STARK chứng minh. Như vậy, bằng chứng chỉ chứa dữ liệu được chứng minh, cộng thêm chi phí cố định 100-300kB từ STARK thực tế.

Thách thức chính ở đây là thời gian xác minh. Chúng ta có thể tính toán tương tự như trên, chỉ khác là tính số hàm băm thay vì byte. Một block 10.4 MB nghĩa là 330000 hàm băm. Nếu thêm khả năng kẻ tấn công "đào" địa chỉ có tiền tố chung dài, trường hợp xấu nhất là 660000 hàm băm. Nếu chứng minh được 200.000 hàm băm mỗi giây thì không vấn đề gì.

Trên laptop tiêu dùng dùng hàm băm Poseidon, các con số này đã đạt được, và Poseidon được thiết kế đặc biệt thân thiện với STARK. Tuy nhiên, hệ thống Poseidon còn khá mới, nên nhiều người chưa tin tưởng vào độ an toàn của nó. Do đó, có hai hướng thực tế:

1. Phân tích bảo mật Poseidon nhanh chóng và kỹ lưỡng, đủ tự tin để triển khai trên L1
2. Dùng hàm băm "bảo thủ" hơn, như SHA256 hoặc BLAKE

Nếu chứng minh hàm băm bảo thủ, vòng STARK của Starkware hiện chỉ chứng minh được 10-30k hàm băm mỗi giây trên laptop tiêu dùng. Tuy nhiên, công nghệ STARK đang tiến bộ nhanh chóng. Ngay cả hiện nay, công nghệ dựa trên GKR cũng cho thấy tốc độ này có thể tăng lên 100-200k.

Trường hợp sử dụng bằng chứng ngoài xác minh block

Ngoài xác minh block, còn ba trường hợp sử dụng quan trọng khác cần xác minh không trạng thái hiệu quả hơn:

• Mempool: Khi giao dịch được phát tán, node trong mạng P2P cần xác minh giao dịch hợp lệ trước khi phát lại. Hiện nay xác minh bao gồm kiểm tra chữ ký, số dư đủ và nonce đúng. Trong tương lai (ví dụ, dùng native account abstraction như EIP-7701), có thể cần chạy một số mã EVM truy cập trạng thái. Nếu node không trạng thái, giao dịch cần kèm bằng chứng trạng thái.
• Danh sách bao gồm: Đây là tính năng đề xuất cho phép validator PoS (có thể nhỏ và không phức tạp) buộc block tiếp theo phải chứa giao dịch, bất kể ý muốn của block builder (có thể lớn và phức tạp). Điều này làm giảm khả năng kẻ có quyền lực thao túng blockchain bằng cách trì hoãn giao dịch. Tuy nhiên, validator cần cách xác minh tính hợp lệ của giao dịch trong danh sách bao gồm.
• Light client: Nếu muốn người dùng truy cập chain qua ví (như Metamask, Rainbow, Rabby...), họ cần chạy light client (như Helios). Module cốt lõi của Helios cung cấp cho người dùng root trạng thái đã xác minh. Để có trải nghiệm hoàn toàn không cần tin cậy, người dùng cần cung cấp bằng chứng cho mỗi RPC họ thực hiện (ví dụ, với eth_call, cần bằng chứng cho tất cả trạng thái truy cập trong quá trình gọi).

Tất cả các trường hợp này đều cần khá nhiều bằng chứng, nhưng mỗi bằng chứng đều nhỏ. Do đó, bằng chứng STARK không thực tế cho chúng; thay vào đó, tốt nhất là dùng nhánh Merkle trực tiếp. Ưu điểm khác của nhánh Merkle là có thể cập nhật: với một bằng chứng cho đối tượng trạng thái gốc block B, nếu nhận được block con B2 và bằng chứng của nó, có thể cập nhật bằng chứng để gốc là block B2. Bằng chứng Verkle cũng có thể cập nhật tự nhiên.

Liên hệ với nghiên cứu hiện có:

• Verkle trees
• Bài báo gốc của John Kuszmaul về Verkle tree
• Starkware
• Poseidon2 paper
• Ajtai (hàm băm nhanh thay thế dựa trên độ cứng lattice)
• Verkle.info

Còn có thể làm gì?

Công việc chính còn lại là

1. Phân tích thêm về hậu quả của EIP-4762 (thay đổi chi phí gas không trạng thái)

2. Hoàn thiện và kiểm thử chương trình chuyển đổi, đây là phần phức tạp chính của bất kỳ triển khai không trạng thái nào

3. Phân tích bảo mật thêm cho Poseidon, Ajtai và các hàm băm "thân thiện STARK" khác

4. Phát triển thêm các tính năng giao thức STARK siêu hiệu quả cho hàm băm "bảo thủ" (hoặc "truyền thống"), ví dụ dựa trên Binius hoặc GKR.

Thêm vào đó, chúng ta sẽ sớm quyết định chọn một trong ba lựa chọn: (i) cây Verkle, (ii) hàm băm thân thiện STARK và (iii) hàm băm bảo thủ. Đặc điểm của chúng được tóm tắt trong bảng dưới đây:

Bên cạnh các "con số tiêu đề" này, còn một số yếu tố quan trọng khác:

• Ngày nay, mã cây Verkle đã khá hoàn thiện. Ngoài Verkle, dùng mã khác sẽ trì hoãn triển khai, rất có thể trì hoãn một hard fork. Điều này cũng không sao, nhất là nếu cần thêm thời gian để phân tích hàm băm hoặc triển khai validator, hoặc có các tính năng quan trọng khác muốn đưa vào Ethereum sớm hơn.
• Cập nhật root trạng thái bằng hàm băm nhanh hơn dùng cây Verkle. Điều này nghĩa là phương pháp dựa trên hàm băm có thể giảm thời gian đồng bộ node đầy đủ.
• Cây Verkle có thuộc tính cập nhật bằng chứng thú vị — bằng chứng Verkle có thể cập nhật. Thuộc tính này hữu ích cho mempool, danh sách bao gồm và các trường hợp khác, đồng thời có thể giúp tăng hiệu quả triển khai: nếu đối tượng trạng thái được cập nhật, có thể cập nhật bằng chứng tầng áp chót mà không cần đọc nội dung tầng cuối.
• Cây Verkle khó chứng minh SNARK hơn. Nếu muốn giảm kích thước bằng chứng xuống vài KB, bằng chứng Verkle sẽ gặp khó khăn. Vì xác minh bằng chứng Verkle đòi hỏi nhiều phép toán 256 bit, điều này yêu cầu hệ thống bằng chứng hoặc phải có chi phí lớn, hoặc có cấu trúc nội bộ tùy chỉnh chứa phần bằng chứng Verkle 256 bit. Điều này không phải vấn đề với không trạng thái, nhưng sẽ gây khó khăn hơn.

Nếu muốn có khả năng cập nhật bằng chứng Verkle một cách an toàn với lượng tử và hiệu quả hợp lý, một hướng khác là dùng cây Merkle dựa trên lattice.

Nếu trong trường hợp xấu nhất, hệ thống bằng chứng không đủ hiệu quả, chúng ta có thể tận dụng công cụ bất ngờ là gas đa chiều: đặt giới hạn gas riêng cho (i) calldata; (ii) tính toán; (iii) truy cập trạng thái và các tài nguyên khác. Gas đa chiều tăng độ phức tạp, nhưng đổi lại, nó giới hạn chặt hơn tỷ lệ giữa trường hợp trung bình và xấu nhất. Với gas đa chiều, số nhánh tối đa cần chứng minh có thể giảm từ 12500 xuống ví dụ 3000. Điều này khiến BLAKE3 thậm chí ngày nay cũng (vừa đủ) đáp ứng.

Gas đa chiều cho phép giới hạn tài nguyên block gần hơn với giới hạn tài nguyên phần cứng cơ bản

Một công cụ bất ngờ khác là trì hoãn tính toán root trạng thái đến slot sau block. Như vậy, chúng ta có trọn 12 giây để tính root trạng thái, nghĩa là ngay cả trong trường hợp cực đoan, chỉ cần chứng minh 60000 hàm băm mỗi giây là đủ, lại khiến BLAKE3 vừa đủ đáp ứng.

Nhược điểm của phương pháp này là tăng độ trễ light client lên một slot, nhưng cũng có kỹ thuật tinh vi hơn để giảm độ trễ này chỉ còn độ trễ tạo bằng chứng. Ví dụ, bằng chứng có thể được phát trên mạng ngay khi bất kỳ node nào tạo ra, không cần chờ block tiếp theo.

Nó tương tác thế nào với các phần khác của lộ trình?

Giải quyết vấn đề không trạng thái làm tăng đáng kể độ khó của staking đơn lẻ. Nếu có công nghệ giảm số dư tối thiểu staking đơn lẻ, như Orbit SSF hoặc chính sách tầng ứng dụng như staking nhóm nhỏ, điều này sẽ khả thi hơn.

Nếu đồng thời triển khai EOF, phân tích gas đa chiều sẽ dễ dàng hơn. Bởi vì độ phức tạp thực thi lớn nhất của gas đa chiều là xử lý các lệnh gọi con không truyền toàn bộ gas của cha, còn EOF chỉ cần làm cho lệnh gọi con như vậy là bất hợp pháp, vấn đề này trở nên tầm thường (và native account abstraction sẽ cung cấp giải pháp thay thế trong giao thức cho trường hợp sử dụng gas một phần hiện tại).

Xác minh không trạng thái và hết hạn lịch sử còn có một sự cộng hưởng quan trọng. Ngày nay, client phải lưu gần 1TB dữ liệu lịch sử; dữ liệu này lớn gấp nhiều lần dữ liệu trạng thái. Ngay cả khi client không trạng thái, trừ khi chúng ta giải phóng trách nhiệm lưu trữ dữ liệu lịch sử, giấc mơ client không lưu trữ gần như không thể thành hiện thực. Bước đầu tiên là EIP-4444, nghĩa là lưu trữ dữ liệu lịch sử trên torrents hoặc Portal Network.

Bằng chứng tính hợp lệ thực thi EVM

Chúng ta cần giải quyết vấn đề gì?

Mục tiêu lâu dài của xác minh block Ethereum rất rõ ràng — nên có thể xác minh block Ethereum bằng cách: (i) tải block, hoặc thậm chí chỉ tải một phần nhỏ dữ liệu lấy mẫu khả dụng trong block; (ii) xác minh một bằng chứng nhỏ về tính hợp lệ của block. Đây sẽ là một thao tác tiêu tốn rất ít tài nguyên, có thể thực hiện trên client di động, ví trình duyệt, thậm chí trên chain khác (không có phần dữ liệu khả dụng).

Để đạt được điều này, cần chứng minh SNARK hoặc STARK cho (i) lớp đồng thuận (tức là bằng chứng cổ phần) và (ii) lớp thực thi (tức là EVM). Phần đầu là một thách thức riêng, nên được giải quyết khi tiếp tục cải tiến lớp đồng thuận (ví dụ, hướng tới single-slot finality). Phần sau cần bằng chứng thực thi EVM.

Nó là gì, hoạt động ra sao?

Về mặt hình thức, trong đặc tả Ethereum, EVM được định nghĩa là một hàm chuyển đổi trạng thái: bạn có trạng thái trước S, một block B, bạn tính trạng thái sau S' = STF(S, B). Nếu người dùng dùng light client, họ không có đầy đủ S và S', thậm chí cả E; thay vào đó, họ có root trạng thái trước R, root trạng thái sau R' và hash block H.

• Đầu vào công khai: root trạng thái trước R, root trạng thái sau R', hash block H
• Đầu vào riêng tư: thân block B, các đối tượng trong trạng thái truy cập bởi block Q, các đối tượng giống nhau sau khi thực thi block Q', bằng chứng trạng thái (như nhánh Merkle) P
• Khẳng định 1: P là bằng chứng hợp lệ, chứng minh Q chứa một phần trạng thái đại diện bởi R
• Khẳng định 2: Nếu chạy STF trên Q, (i) quá trình thực thi chỉ truy cập các đối tượng bên trong Q, (ii) block hợp lệ, (iii) kết quả là Q'
• Khẳng định 3: Nếu dùng thông tin từ Q' và P để tính lại root trạng thái mới, sẽ ra R'

Nếu có điều này, có thể có một light client xác minh đầy đủ thực thi EVM của Ethereum. Điều này làm tài nguyên client đã rất thấp. Để có client Ethereum xác minh đầy đủ thực sự, còn cần làm tương tự cho đồng thuận.

Bằng chứng tính hợp lệ cho tính toán EVM đã tồn tại và được L2 sử dụng rộng rãi. Nhưng để bằng chứng tính hợp lệ EVM khả thi trên L1, còn nhiều việc phải làm.

Liên hệ với nghiên cứu hiện có?

• EFPSE ZK-EVM (đã ngừng vì có lựa chọn tốt hơn)
• Zeth, hoạt động bằng cách biên dịch EVM sang RISC-0 ZK-VM
• Dự án xác minh hình thức ZK-EVM

Còn có thể làm gì?

Ngày nay, bằng chứng tính hợp lệ hệ thống sổ cái điện tử còn thiếu ở hai mặt: bảo mật và thời gian xác minh.

Một bằng chứng tính hợp lệ an toàn cần đảm bảo SNARK thực sự xác minh tính toán EVM và không có lỗ hổng. Hai kỹ thuật chính để tăng bảo mật là đa validator và xác minh hình thức. Đa validator nghĩa là có nhiều triển khai bằng chứng tính hợp lệ độc lập, giống như có nhiều client, nếu một block được một tập con đủ lớn các triển khai này chứng minh, client sẽ chấp nhận block đó. Xác minh hình thức liên quan đến việc dùng công cụ thường dùng để chứng minh định lý toán học, như Lean4, để chứng minh bằng chứng tính hợp lệ chỉ chấp nhận thực thi đúng đặc tả EVM nền tảng (ví dụ EVM K semantics hoặc đặc tả lớp thực thi Ethereum bằng python (EELS)).

Thời gian xác minh đủ nhanh nghĩa là bất kỳ block Ethereum nào cũng được xác minh trong chưa đầy 4 giây. Hiện nay, chúng ta còn khá xa mục tiêu này, dù đã gần hơn nhiều so với hai năm trước. Để đạt được mục tiêu, cần tiến bộ ở ba hướng:

• Song song hóa — hiện validator EVM nhanh nhất có thể chứng minh một block Ethereum trung bình trong 15 giây. Điều này đạt được bằng cách song song hóa trên hàng trăm GPU, sau đó tổng hợp công việc của chúng lại. Về lý thuyết, chúng ta hoàn toàn biết cách tạo validator EVM chứng minh tính toán trong thời gian O(log(N)): cho một GPU thực hiện mỗi bước, sau đó làm "cây tổng hợp":

Thực hiện điều này có nhiều thách thức. Ngay cả trong trường hợp xấu nhất, tức là một giao dịch lớn chiếm toàn bộ block, việc chia nhỏ tính toán không thể làm theo giao dịch mà phải theo opcode (opcode của EVM hoặc RISC-V...). Đảm bảo "bộ nhớ" của VM nhất quán giữa các phần bằng chứng là thách thức chính khi triển khai. Tuy nhiên, nếu làm được chứng minh đệ quy kiểu này, chúng ta biết ít nhất vấn đề độ trễ validator đã được giải quyết, dù các mặt khác chưa cải thiện.

• Tối ưu hệ thống bằng chứng — các hệ thống bằng chứng mới như Orion, Binius, GRK và nhiều thông tin khác rất có thể sẽ lại rút ngắn đáng kể thời gian xác minh tính toán tổng quát.
• Các thay đổi chi phí gas EVM khác — nhiều thứ trong EVM có thể tối ưu để thân thiện hơn với validator, đặc biệt trong trường hợp xấu nhất. Nếu kẻ tấn công có thể tạo block khiến validator bị chặn 10 phút, thì chỉ chứng minh block Ethereum thông thường trong 4 giây là chưa đủ. Các thay đổi EVM cần thiết có thể chia thành:
• Thay đổi chi phí gas — nếu một thao tác mất nhiều thời gian để chứng minh, dù tính toán nhanh, cũng nên có chi phí gas cao. EIP-7667 đề xuất xử lý vấn đề nghiêm trọng nhất này: tăng mạnh chi phí gas cho các hàm băm (truyền thống), vì opcode và precompile của chúng khá rẻ. Để bù lại, có thể giảm chi phí gas cho opcode EVM có chi phí chứng minh thấp, giữ throughput trung bình không đổi.
• Thay thế cấu trúc dữ liệu — ngoài việc thay cây trạng thái bằng phương pháp thân thiện STARK, còn cần thay danh sách giao dịch, cây biên nhận và các cấu trúc có chi phí chứng minh cao khác. Đề xuất chuyển cấu trúc giao dịch và biên nhận sang SSZ của Etan Kissling là một bước theo hướng này.

Ngoài ra, hai công cụ đề cập ở phần trước (gas đa chiều và trì hoãn root trạng thái) cũng giúp ích ở đây. Tuy nhiên, khác với xác minh không trạng thái, dùng hai công cụ này nghĩa là chúng ta đã có đủ công nghệ cho công việc hiện tại, còn xác minh ZK-EVM đầy đủ vẫn cần nhiều việc hơn — chỉ là ít hơn thôi.

Một điểm chưa đề cập là phần cứng validator: dùng GPU, FPGA và ASIC để tạo bằng chứng nhanh hơn. Fabric Cryptography, Cysic và Accseal là ba công ty tiến bộ trong lĩnh vực này. Điều này rất giá trị cho L2, nhưng khó trở thành yếu tố quyết định cho L1, vì cộng đồng rất muốn L1 duy trì phi tập trung cao, nghĩa là tạo bằng chứng phải nằm trong khả năng hợp lý của người dùng Ethereum, không bị giới hạn bởi phần cứng của một công ty. L2 có thể chấp nhận đánh đổi tích cực hơn.

Còn nhiều việc phải làm trong các lĩnh vực này:

• Song song hóa bằng chứng yêu cầu các phần khác nhau của hệ thống bằng chứng có thể "chia sẻ bộ nhớ" (như bảng tra cứu). Chúng ta biết kỹ thuật này, nhưng cần triển khai.
• Cần phân tích thêm để tìm tập thay đổi chi phí gas lý tưởng, giảm tối đa thời gian xác minh trường hợp xấu nhất.
• Cần làm thêm về hệ thống bằng chứng

Cái giá có thể là:

• Bảo mật và thời gian validator: nếu chọn hàm băm táo bạo hơn, hệ thống bằng chứng phức tạp hơn hoặc giả định bảo mật táo bạo hơn hoặc thiết kế khác, có thể rút ngắn thời gian validator.
• Phi tập trung và thời gian validator: cộng đồng cần đồng thuận về "thông số kỹ thuật" phần cứng validator nhắm tới. Có chấp nhận validator là thực thể lớn không? Chúng ta muốn laptop tiêu dùng cao cấp chứng minh block Ethereum trong 4 giây? Hay ở giữa?
• Mức độ phá vỡ tương thích ngược: các thiếu sót khác có thể bù bằng thay đổi chi phí gas tích cực hơn, nhưng điều này có thể làm tăng chi phí không cân xứng cho một số ứng dụng, buộc dev phải viết lại và triển khai lại code để duy trì hiệu quả kinh tế. Hai công cụ này cũng có độ phức tạp và nhược điểm riêng.

Nó tương tác thế nào với các phần khác của lộ trình?

Công nghệ cốt lõi cần thiết để đạt được bằng chứng tính hợp lệ EVM L1 phần lớn trùng với hai lĩnh vực khác:

• Bằng chứng tính hợp lệ L2 (tức là "ZK rollup")
• Phương pháp "bằng chứng băm nhị phân STARK" không trạng thái

Nếu thành công triển khai bằng chứng tính hợp lệ trên L1, cuối cùng có thể đạt được staking đơn lẻ dễ dàng: ngay cả máy tính yếu nhất (bao gồm điện thoại hoặc đồng hồ thông minh) cũng có thể staking. Điều này càng tăng giá trị của việc giải quyết các hạn chế staking đơn lẻ khác (như giới hạn tối thiểu 32ETH).

Thêm vào đó, bằng chứng tính hợp lệ EVM L1 có thể tăng đáng kể giới hạn gas của L1.

Bằng chứng tính hợp lệ đồng thuận

Chúng ta cần giải quyết vấn đề gì?

Nếu muốn dùng SNARK xác minh đầy đủ một block Ethereum, thì thực thi EVM không phải phần duy nhất cần chứng minh. Còn phải chứng minh đồng thuận, tức là phần xử lý nạp rút, chữ ký, cập nhật số dư validator và các yếu tố khác của phần bằng chứng cổ phần Ethereum.

Đồng thuận đơn giản hơn EVM nhiều, nhưng thách thức là chúng ta không có L2 EVM convolution, nên dù sao phần lớn công việc vẫn phải làm. Do đó, bất kỳ triển khai bằng chứng đồng thuận Ethereum nào cũng cần "làm từ đầu", dù hệ thống bằng chứng có thể xây dựng dựa trên công việc chung.

Nó là gì, hoạt động ra sao?

Beacon chain được định nghĩa là một hàm chuyển đổi trạng thái, giống như EVM. Hàm chuyển đổi trạng thái chủ yếu gồm ba phần:

• ECADD (dùng xác minh chữ ký BLS)
• Pairing (dùng xác minh chữ ký BLS)
• SHA256 hash (dùng đọc và cập nhật trạng thái)

Trong mỗi block, cần chứng minh 1-16 ECADD BLS12-381 cho mỗi validator (có thể nhiều hơn một, vì chữ ký có thể nằm trong nhiều tập hợp). Có thể bù lại bằng kỹ thuật tính trước tập con, nên có thể nói mỗi validator chỉ cần chứng minh một ECADD BLS12-381. Hiện mỗi slot có 30000 chữ ký validator. Trong tương lai, khi đạt single-slot finality, con số này có thể thay đổi hai hướng: nếu đi theo "brute force", số validator mỗi slot có thể tăng lên 1 triệu. Nếu dùng Orbit SSF, số validator giữ ở 32768, thậm chí giảm xuống 8192.

BLS aggregation hoạt động thế nào: xác minh tổng chữ ký chỉ cần một ECADD cho mỗi người tham gia, thay vì một ECMUL. Nhưng 30000 ECADD vẫn là lượng bằng chứng lớn.

Về pairing, hiện mỗi slot tối đa có 128 bằng chứng, nghĩa là cần xác minh 128 pairing. Qua ElP-7549 và các sửa đổi tiếp theo, mỗi slot có thể giảm còn 16. Số pairing ít nhưng chi phí rất cao: mỗi lần chạy (hoặc chứng minh) pairing tốn thời gian gấp hàng nghìn lần ECADD.

Một thách thức lớn khi chứng minh phép toán BLS12-381 là không có đường cong có bậc bằng kích thước trường BLS12-381, điều này làm tăng chi phí cho bất kỳ hệ thống bằng chứng nào. Ngược lại, cây Verkle đề xuất cho Ethereum xây dựng trên đường cong Bandersnatch, khiến BLS12-381 trở thành đường cong tự nhiên trong hệ thống SNARK để chứng minh nhánh Verkle. Một triển khai đơn giản có thể chứng minh 100 phép cộng G1 mỗi giây; để tốc độ đủ nhanh, gần như chắc chắn cần kỹ thuật thông minh như GKR.

Với SHA256 hash, trường hợp xấu nhất hiện nay là block chuyển epoch, toàn bộ cây cân bằng validator và nhiều số dư validator được cập nhật. Cây cân bằng validator chỉ một byte mỗi validator, nên có 1 MB dữ liệu được hash lại. Tương đương 32768 lần gọi SHA256. Nếu có một nghìn validator vượt hoặc dưới ngưỡng, cần cập nhật số dư hiệu lực trong bản ghi validator, tương đương một nghìn nhánh Merkle, có thể cần mười nghìn hash. Cơ chế xáo trộn cần 90 bit mỗi validator (tức là 11 MB dữ liệu), nhưng có thể tính ở bất kỳ thời điểm nào trong epoch. Khi đạt single-slot finality, các con số này có thể tăng giảm tùy trường hợp. Xáo trộn không còn cần thiết, dù Orbit có thể khôi phục phần nào nhu cầu này.

Một thách thức khác là cần lấy lại toàn bộ trạng thái validator, gồm cả public key, để xác minh một block. Với 1 triệu validator, chỉ riêng đọc public key đã cần 48 triệu byte, cộng thêm nhánh Merkle. Điều này cần hàng triệu hash mỗi epoch. Nếu phải chứng minh tính hợp lệ PoS, một cách thực tế là dùng một dạng tính toán có thể xác minh tăng dần: lưu một cấu trúc dữ liệu riêng trong hệ thống bằng chứng, tối ưu cho tra cứu hiệu quả và chứng minh cập nhật cấu trúc đó.

Tóm lại, có nhiều thách thức. Để đối phó hiệu quả nhất, gần như chắc chắn cần thiết kế lại sâu beacon chain, có thể đồng thời với chuyển sang single-slot finality. Thiết kế lại này có thể gồm:

• Thay đổi hàm băm: hiện dùng SHA256 "đầy đủ", nên mỗi lần gọi phải gọi hai lần hàm nén do padding. Nếu chuyển sang hàm nén SHA256, ít nhất được lợi 2 lần. Nếu chuyển sang Poseidon, có thể lợi 100 lần, giải quyết triệt để vấn đề hash (ít nhất về hash): với 1,7 triệu hash mỗi giây (54MB), ngay cả 1 triệu bản ghi validator cũng có thể "đọc" vào bằng chứng trong vài giây.
• Nếu là Orbit, lưu trực tiếp bản ghi validator đã xáo trộn: nếu chọn số validator nhất định (như 8192 hoặc 32768) làm ủy ban cho slot, thì đặt chúng cạnh nhau trong trạng thái, chỉ cần tối thiểu hash để đọc tất cả public key validator vào bằng chứng. Cũng giúp cập nhật số dư hiệu quả.
• Tổng hợp chữ ký: bất kỳ sơ đồ tổng hợp chữ ký hiệu suất cao nào cũng sẽ dùng một dạng chứng minh đệ quy, các node trong mạng chứng minh trung gian cho tập con chữ ký. Điều này tự nhiên phân chia công việc chứng minh cho nhiều node, giảm đáng kể khối lượng cho "validator cuối cùng".
• Sơ đồ chữ ký khác: với chữ ký Lamport+ Merkle, cần 256 + 32 hash để xác minh chữ ký; nhân với 32768 người ký, ra 9437184 hash. Tối ưu sơ đồ chữ ký có thể cải thiện thêm bằng một hằng số nhỏ. Nếu dùng Poseidon, có thể chứng minh trong một slot. Nhưng thực tế, dùng sơ đồ tổng hợp đệ quy sẽ nhanh hơn.

Liên hệ với nghiên cứu hiện có?

• Bằng chứng đồng thuận Ethereum ngắn gọn (chỉ cho sync committee)
• Helios trong SP1 ngắn gọn
• BLS12-381 precompile ngắn gọn
• Xác minh chữ ký tập hợp BLS dựa trên Halo2

Còn việc gì phải làm, cân nhắc thế nào:

Thực tế, chúng ta cần nhiều năm nữa mới có thể đạt được bằng chứng tính hợp lệ của đồng thuận Ethereum. Điều này tương đương thời gian cần để đạt single-slot finality, Orbit, thay đổi sơ đồ chữ ký và phân tích bảo mật, mà phân tích bảo mật cần đủ tự tin để dùng hàm băm "táo bạo" như Poseidon. Do đó, cách khôn ngoan nhất là giải quyết các vấn đề khác này, đồng thời cân nhắc tính thân thiện STARK khi làm.

Những đánh đổi chính có thể là về trình tự thao tác, giữa phương pháp cải cách lớp đồng thuận Ethereum dần dần và phương pháp "thay đổi nhiều thứ cùng lúc" táo bạo hơn. Với EVM, phương pháp dần dần là hợp lý vì giảm thiểu ảnh hưởng đến tương thích ngược. Với lớp đồng thuận, ảnh hưởng đến tương thích ngược nhỏ hơn, và việc suy nghĩ lại toàn diện về cách xây dựng beacon chain để tối ưu hóa tính thân thiện SNARK cũng có lợi.

Nó tương tác thế nào với các phần khác của lộ trình?

Khi thiết kế lại dài hạn PoS Ethereum, tính thân thiện STARK phải là ưu tiên hàng đầu, đặc biệt là single-slot finality, Orbit, thay đổi sơ đồ chữ ký và tổng hợp chữ ký.