原文标题：《Tương lai có thể của giao thức Ethereum, phần 4: The Verge》

原文作者：Vitalik Buterin

Original translation: 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 về phản hồi và xem xét.

Một trong những tính năng mạnh mẽ nhất của Khối链 là bất kỳ ai cũng có thể chạy một Nút trên máy tính của mình và xác minh tính chính xác của Khối链. Ngay cả khi 9596 Nút chạyNhận thức chung chuỗi (PoW, PoS) đồng ý ngay lập tức thay đổi quy tắc và bắt đầu sản xuất Khối theo quy tắc mới, mọi người chạy Nút đã xác minh hoàn toàn sẽ từ chối chấp nhận chuỗi. Người đào coin không thuộc về nhóm âm mưu này sẽ tự động tụ hợp vào chuỗi on-chain tiếp tục tuân thủ theo quy tắc cũ và tiếp tục xây dựng chuỗi này, trong khi người dùng đã xác minh hoàn toàn sẽ tuân theo chuỗi này.

Điều này là sự 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 trở thành sự thật, việc chạy một nút xác minh đầy đủ cần phải khả thi đối với đủ số người. Điều này áp dụng cả cho người tạo ra sự lan truyền (vì nếu họ không xác minh chuỗi, họ sẽ không đóng góp cho việc thực hiện các quy tắc giao thức), cũng như người dùng thông thường. Ngày nay, việc chạy nút trên máy tính xách tay tiêu dùng (bao gồm cả máy tính xách tay được sử dụng để viết bài này) là khả thi, nhưng việc làm điều này lại rất khó khăn. The Verge đang muốn thay đổi tình trạng này, làm cho chi phí tính toán của chuỗi xác minh đầy đủ trở nên rẻ hơn, để mỗi chiếc điện thoại Ví tiền, trình duyệt Ví tiền thậm chí cả đồng hồ thông minh đều mặc định thực hiện xác minh.

Bản đồ con đường The Verge 2023

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

Ngoài việc theo dõi dài hạn của toàn bộ chuỗi bằng phương pháp xác minh SNARK, một vấn đề mới khác liên quan đến việc xem xét xem cây Verkle có phải là công nghệ tốt 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 Verkle trong cây Patricia Merkle KECCAK hiện tại, chúng ta sẽ phải thay thế cây một lần nữa trong tương lai. Phương pháp tự thay thế của cây Merkle là bỏ qua việc sử dụng nhánh Merkle và sử dụng STARK, đặt chúng vào một cây nhị phân. Lịch sử cho thấy, phương pháp này luôn được coi là không thể thực hiện do chi phí và độ phức tạp kỹ thuật. Tuy nhiên, gần đây, chúng ta đã thấy Starkware chứng minh 1,7 triệu giá trị Hàm băm Poseidon mỗi giây trên một máy tính xách tay bằng ckcle STARKs, và thời gian chứng minh giá trị Hàm băm "truyền thống" khác cũng đang được rút ngắn nhanh chóng do sự xuất hiện của các công nghệ như GKB. Do đó, trong năm qua, "Verge" đã trở nên mở rộng hơn và có nhiều khả năng hơn.

The Verge：Mục Tiêu Quan Trọng

• Khách hàng không trạng thái: Không gian lưu trữ cần thiết để xác minh hoàn toàn khách hàng và đánh dấu Nút không nên vượt quá vài GB.
• (Trường hợp dài) Hoàn thành việc xác minh toàn bộ chuỗi trên đồng hồ thông minh (Nhận thức chung và thực thi). Tải xuống một số dữ liệu, xác minh SNARK và hoàn thành.

Trong chương này

• Máy khách không trạng thái: Verkle hay STARKs
• Bằng chứng hợp lệ của EVM được thực thi
• Nhận thức chung的bằng chứng hợp lệ

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

Chúng tôi muốn giải quyết vấn đề gì?

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

Điều này giảm số lượng người dùng có thể chạy một Nút Ethereum đầy đủ xác thực: Mặc dù có đủ dung lượng để lưu trữ tất cả trạng thái Ethereum thậm chí là nhiều năm lịch sử trên ổ cứng lớn ở khắp mọi nơi, nhưng máy tính mà mọi người mua mặc định thường chỉ có vài trăm đến vài ngàn megabyte lưu trữ. Kích thước trạng thái cũng mang đến sự ma sát lớn cho quá trình xây dựng Nút lần đầu: Nút cần tải xuống toàn bộ trạng thái, điều này có thể mất vài giờ hoặc vài ngày. Điều này sẽ tạo ra nhiều tác động lan rộng. Ví dụ, nó tăng đáng kể độ khó của việc nâng cấp cài đặt Nút. Theo mặt kỹ thuật, có thể hoàn tất việc nâng cấp mà không cần tắt máy - khởi động một phiên bản khách hàng mới, đợi nó đồng bộ, sau đó tắt phiên bản khách hàng cũ và chuyển Chìa khoá bảo mật - nhưng trong 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 công nghệ cho phép Nút xác minh Khối mà không cần kiểm soát toàn bộ trạng thái. Thay vào đó, mỗi Khối đi kèm với một bằng chứng, bao gồm: (i) giá trị, mã, số dư, lưu trữ tại vị trí cụ thể trong trạng thái mà Khối sẽ truy cập; (ii) chứng minh rằng các giá trị này là chính xác mã hóa.

Trong thực tế, việc thực hiện xác minh không trạng thái đòi hỏi thay đổi cấu trúc cây trạng thái của Ethereum. Điều này bởi vì cây Merkle Patricia hiện tại rất không thân thiện với bất kỳ hệ thống chứng minh mã hóa nào, đặc biệt là trong trường hợp xấu nhất. Cả 'cành' Merkle gốc và khả năng 'đóng gói' thành STARK đều vậy. Khó khăn chính đến từ một số điểm yếu của MPT:

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

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

Chúng ta có thể tính toán trường hợp tồi nhất như sau:

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

Chi phí của chi nhánh nhỏ hơn một chút (sử dụng 5 * 480 thay cho 8 * 480), vì khi có nhiều chi nhánh, phần đầu đỉnh sẽ xuất hiện nhiều lần. Nhưng ngay cả như vậy, việc tải xuống lượng dữ liệu trong một khung thời gian là hoàn toàn không thực tế. Nếu chúng ta cố gắng đóng gói nó bằng STARK, chúng ta sẽ gặp hai vấn đề: (i) KECCAK ít thân thiện với STARK; (ii) với 330 MB dữ liệu, chúng ta phải chứng minh 5 triệu cuộc gọi vòng lặp KECCAK, điều này có thể không chứng minh được cho tất cả các phần cứng ngoại trừ phần cứng tiêu dùng mạnh nhất, ngay cả khi chúng ta có thể làm cho STARK chứng minh hiệu quả hơn cho KECCAK.

Nếu chúng ta sử dụng cây nhị phân trực tiếp thay cho cây hệ thập lục phân và thực hiện xử lý Merkle bổ sung cho mã, trong trường hợp xấu nhất, tổng cộng sẽ là khoảng 30000000/2400 * 32 * (32-14+8) = 10400000 byte (14 là phép trừ dư của các bit tương đương với 2 ^ 14 nhánh và 8 là độ dài chứng minh vào các khối mã lá). Cần lưu ý rằng điều này đòi hỏi thay đổi chi phí gas, tính phí cho việc truy cập vào từng khối mã riêng lẻ; EIP-4762 đã thực hiện điều này. Dung lượng 10.4 MB tốt hơn nhiều, nhưng đối với nhiều nút, dữ liệu tải xuống trong một time slot vẫn quá nhiều. Do đó, chúng ta cần giới thiệu công nghệ mạnh mẽ hơn. Trong lĩnh vực này, có hai giải pháp tiên tiến: 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 đường cong elliptic để làm chứng ngắn hơn. Khóa mở cần phải biết rằng, bất kể chiều rộng của cây là bao nhiêu, mỗi phần chứng chỉ tương ứng với mỗi mối quan hệ cha con chỉ có 32 byte. Giới hạn duy nhất của chiều rộng cây chứng chỉ là nếu cây chứng chỉ quá rộng, hiệu suất tính toán chứng chỉ sẽ bị giảm. Đề xuất triển khai cho Ethereum có chiều rộng là 256.

Do đó, kích thước của một nhánh trong chứng minh trở thành 32 - 1 og 256(N) = 4* log 2(N) byte. Do đó, kích thước chứng minh tối đa lý thuyết là khoảng 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 byte (kết quả tính toán thực tế có thể khác nhau một chút do sự phân phối không đồng đều của khối trạng thái, nhưng là giá trị xấp xỉ đầu tiên).

Một điều cần lưu ý khác là trong tất cả các ví dụ trên, trường hợp "tệ nhất" này không phải là tệ nhất: tệ hơn nữa là kẻ tấn công chủ ý "đào" hai địa chỉ Địa chỉ, làm cho chúng có tiền tố chung dài hơn trong cây và đọc dữ liệu từ một trong hai Địa chỉ đó, điều này có thể kéo dài chiều dài của nhánh tệ nhất lên gấp đôi. Nhưng ngay cả khi có trường hợp như vậy, chiều dài chứng minh tệ nhất của cây Verkle vẫn là 2,6 MB, khá tương đồng với dữ liệu kiểm tra tệ nhất hiện tại.

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

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

Nguyên lý công nghệ này rõ ràng không cần phải nói: bạn chỉ cần tạo một cây nhị phân, lấy chứng minh có kích thước tối đa 10.4 MB để chứng minh giá trị trong khối, sau đó thay thế chứng minh bằng STARK đã được chứng minh. Như vậy, chứng minh chính chỉ chứa dữ liệu được chứng minh và một chi phí cố định từ STARK thực tế là 100-300 kB.

Thách thức chính ở đây là thời gian xác minh. Chúng ta có thể thực hiện các tính toán cơ bản tương tự như trên, chỉ khác là chúng ta tính toán không phải là số byte mà là giá trị băm. Một Khối có kích thước 10,4 MB có nghĩa là 330,000 giá trị băm. Nếu kèm theo khả năng của kẻ tấn công "đào" các Địa chỉ cây có tiền tố công cộng dài, thì số lượng giá trị băm trong trường hợp tồi tệ nhất sẽ lên đến khoảng 660,000 giá trị băm. Do đó, nếu chúng ta có thể chứng minh rằng số lượng giá trị băm mỗi giây là 200,000, thì không vấn đề gì cả.

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

1. Nhanh chóng phân tích an ninh lớn về Poseidon và làm quen đủ với nó để triển khai trên L1
2. Sử dụng hàm băm "cẩn thận" hơn, như SHA 256 hoặc BLAKE

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

Trường hợp sử dụng chứng thực ngoại trừ khối

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

• Bể nhớ: Khi giao dịch được phát sóng, các Nút trong mạng P2P cần xác minh tính hợp lệ của giao dịch trước khi phát lại. Hiện nay, việc xác minh bao gồm xác minh chữ ký, cũng như kiểm tra xem số dư có đủ và tiền tố có đúng không. Trong tương lai (ví dụ như sử dụng trừu tượng hóa tài khoản nguyên bản, chẳng hạn như EIP-7701), điều này có thể liên quan đến việc chạy một số mã EVM để truy cập trạng thái. Nếu Nút không có trạng thái, giao dịch sẽ cần có chứng minh của chứng chỉ đối tượng trạng thái.
• Danh sách bao gồm: Đây là một tính năng đề xuất, cho phép Bằng chứng về cổ phần (có thể với quy mô nhỏ và không phức tạp) được bắt buộc trong Khối tiếp theo bởi Người xác thực, mà không cần quan tâm đến ý muốn của Người tạo Khối (có thể với quy mô lớn và phức tạp). Điều này sẽ làm suy yếu khả năng của những người có quyền lực để thao túng chuỗi Khối thông qua việc Trễ giao dịch. Tuy nhiên, điều này đòi hỏi Người xác thực phải có cách xác thực tính hợp lệ của các giao dịch được liệt kê trong danh sách bao gồm.
• khách hàng ánh sáng: Nếu chúng ta muốn người dùng truy cập chuỗi thông qua ví (ví dụ như Metamask, Rainbow, Rabby, v.v.), để làm được điều này, họ cần chạy một khách hàng ánh sáng (như Helios). Mô-đun cốt lõi của Helios cung cấp cho người dùng một trạng thái gốc đã được xác minh. Và để có được trải nghiệm hoàn toàn không tin cậy, người dùng cần cung cấp chứng minh cho mỗi cuộc gọi RPC mà họ thực hiện (ví dụ, cho yêu cầu gọi mạng ETH (người dùng cần chứng minh truy cập vào tất cả các trạng thái được truy cập trong quá trình gọi).

Tất cả các trường hợp sử dụng này đều có một điểm chung, đó là chúng cần rất nhiều chứng minh nhưng mỗi chứng minh lại rất nhỏ. Do đó, chứng minh STARK không có ý nghĩa thực tế đối với chúng; ngược lại, phương pháp hiện thực nhất là sử dụng trực tiếp các nhánh Merkle. Một ưu điểm khác của nhánh Merkle là tính cập nhật: với một chứng minh của đối tượng trạng thái X có gốc là Khối B, nếu nhận được một Khối con B 2 và chứng thực của nó, có thể cập nhật chứng minh để có gốc là Khối B 2. Chứng minh Verkle cũng có thể cập nhật một cách tự nhiên.

Có liên quan gì với nghiên cứu hiện có:

• Cây Verkle
• Bài báo gốc của John Kuszmaul về cây Verkle
• Starkware
• Giấy Poseidon 2
• Ajtai (Hàm băm thay thế nhanh dựa trên độ cứng lưới tinh thể)
• Verkle.info

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

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

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

2. Hoàn thành và thử nghiệm thêm công việc chuyển tiếp, đây là phần quan trọng của sự phức tạp của bất kỳ kế hoạch triển khai không quốc tịch nào

3. Phân tích bảo mật sâu hơn về các hàm băm Poseidon, Ajtai và các hàm băm "STARK-friendly" khác

4.为 "保守"（或 "传统"）Hàm băm进一步开发超高效 STARK giao thức功能，例如基于 Binius 或 GKR 的观点。

Ngoài ra, chúng tôi sẽ sớm quyết định chọn một trong ba lựa chọn sau: (i) cây Verkle, (ii) hàm băm thân thiện STARK và (iii) hàm băm bảo thủ. Các tính chất của chúng có thể được tóm tắt đại khái trong bảng dưới đây:

Ngoài các "số tiêu đề" này, còn có một số yếu tố quan trọng khác cần được xem xét:

• Hiện nay, mã cây Verkle đã khá thành thạo. Ngoài việc sử dụng Verkle, sử dụng bất kỳ mã nào khác đều sẽ trì hoãn triển khai và có thể dẫn đến một fork cứng bị trì hoãn. Điều này cũng không quan trọng, đặc biệt là nếu chúng ta cần thêm thời gian để phân tích hàm băm hoặc triển khai trình xác thực, hoặc chúng ta có các tính năng quan trọng khác muốn sớm hơn được tích hợp vào Ethereum.
• Cập nhật gốc trạng thái bằng giá trị băm nhanh hơn sử dụng cây Verkle. Điều này có nghĩa là phương pháp dựa trên giá trị băm có thể giảm thời gian đồng bộ của Toàn bộ nút.
• Cây Verkle có thuộc tính chứng minh cập nhật thú vị - Chứng minh cập nhật của cây Verkle có thể được cập nhật. Thuộc tính này hữu ích cho mempool, danh sách chứa và các trường hợp sử dụng khác, và cũng có thể giúp cải thiện hiệu suất triển khai: Nếu trạng thái đối tượng được cập nhật, có thể cập nhật chứng minh lớp thứ hai từ dưới lên mà không cần đọc nội dung lớp cuối cùng.
• Việc chứng minh Verkle trở khó khăn hơn SNARK. Nếu chúng ta muốn giảm kích thước chứng minh xuống chỉ còn vài nghìn byte, chứng minh Verkle sẽ mang lại một số khó khăn. Điều này bởi vì việc xác minh chứng minh Verkle đòi hỏi một lượng lớn phép toán 256 bit, điều này yêu cầu hệ thống chứng minh có hoặc một chi phí lớn hoặc một cấu trúc nội bộ tùy chỉnh với một phần chứng minh Verkle 256 bit. Điều này không phải là vấn đề đối với trạng thái không có, nhưng nó đem lại nhiều khó khăn hơn.

Nếu chúng ta muốn có tính bảo mật về mặt lượng tử và hiệu quả hợp lý khi có tính khả năng cập nhật chứng cứ Verkle, một phương pháp khả thi khác là dựa trên cây Merkle dựa trên lưới lattice.

Nếu trong trường hợp xấu nhất, chứng minh hiệu suất của hệ thống không đủ cao, chúng ta có thể sử dụng công cụ gas đa chiều không mong đợi này để bù đắp điều đó: (i) calldata; (ii) tính toán; (iii) truy cập trạng thái và có thể là các tài nguyên khác có đặt giới hạn gas riêng biệt. Gas đa chiều tăng thêm sự phức tạp, nhưng như một trao đổi, nó hạn chế nghiêm ngặt tỷ lệ giữa trường hợp trung bình và trường hợp xấu nhất. Với gas đa chiều, lý thuyết về số nhánh tối đa cần chứng minh có thể giảm từ 12500 xuống ví dụ như 3000. Điều này sẽ giúp BLAKE 3 có đủ sức mạnh ngay cả trong ngày hôm nay (dù chỉ vừa đủ).

Gas đa chiều cho phép giới hạn tài nguyên của Khối gần hơn với giới hạn tài nguyên của phần cứng cấu trúc ở mức thấp

Một công cụ ngoài dự tính khác là tính toán trạng thái gốc Trễ đến khoảng thời gian sau Khối. Điều này có nghĩa là chúng ta có tới 12 giây để tính toán trạng thái gốc, điều này có nghĩa là ngay cả trong trường hợp cực đoan nhất, thời gian chứng minh mỗi giây cũng chỉ cần 60000 lần băm là đủ, điều này một lần nữa khiến chúng tôi nghĩ rằng BLAKE 3 chỉ đủ sức mạnh.

Phương pháp này có điểm yếu là sẽ tăng thêm một độ trễ khách hàng ánh sáng, nhưng cũng có các kỹ thuật tinh vi hơn có thể giảm độ trễ này xuống chỉ còn là Trễ sinh trắc nghiệm. Ví dụ, chứng minh có thể được phát sóng trên mạng ngay sau khi được sinh ra trên bất kỳ Nút nào, thay vì phải chờ đợi cho Khối tiếp theo.

Nó tương tác như thế nào với các phần khác của sơ đồ tuyến đường?

Giải quyết vấn đề không trạng thái đã làm tăng đáng kể độ khó của việc định vị đơn lẻ. Nếu có công nghệ có thể Thả cân bằng tối thiểu của việc định vị đơn lẻ, như Orbit SSF hoặc chiến lược Lớp ứng dụng, như định vị nhóm, điều này sẽ trở nên khả thi hơn.

Nếu đồng thời giới thiệu EOF, phân tích gas đa chiều sẽ trở nên dễ dàng hơn. Điều này bởi vì nguồn gốc phức tạp chính của gas đa chiều đến từ việc xử lý các cuộc gọi con không truyền toàn bộ gas của cuộc gọi cha, trong khi EOF chỉ cần đặt các cuộc gọi con như vô hiệu, vấn đề này sẽ trở nên không đáng kể (và cung cấp một phương án thay thế nội bộ cho việc sử dụng gas hiện tại của tài khoản cục bộ một phần giao thức).

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

Bằng chứng hợp lệ được thực hiện bởi EVM

Chúng tôi muốn giải quyết vấn đề gì?

Mục tiêu lâu dài của việc xác minh Khối ETH là rõ ràng - có thể xác minh Khối ETH theo cách sau đây: (i) Tải xuống Khối hoặc thậm chí chỉ tải xuống một phần nhỏ của dữ liệu sẵn có trong Khối; (ii) Xác minh một chứng chỉ nhỏ về tính hợp lệ của Khối. Đây sẽ là một hoạt động tài nguyên rất thấp, có thể được thực hiện trên điện thoại di động, ví tiền trình duyệt hoặc thậm chí trên một chuỗi khác (không có phần dữ liệu sẵn có).

Để đạt được điều này, cần phải chứng minh SNARK hoặc STARK cho (i) lớp đồng thuận (Proof of Stake) và (ii) lớp thực thi (EVM). Đối với phần đầu tiên, đó là một thách thức riêng biệt và cần được giải quyết trong quá trình cải tiến liên tục lớp đồng thuận (ví dụ: đối với quyết định cuối cùng của một khe đơn). Còn với phần sau, cần chứng minh thực thi EVM.

Nó là gì, làm thế nào hoạt động?

Từ mặt hình thức, trong đặc tả của Ethereum (ETH), EVM được xác định là một hàm chuyển trạng thái: bạn có một trạng thái trước S, một Khối B và bạn đang tính toán một trạng thái sau S' = STF(S, B). Nếu người dùng sử dụng khách hàng ánh sáng, họ không hoàn toàn sở hữu S và S', thậm chí không có E; thay vào đó, họ sở hữu một gốc trạng thái trước R, một gốc trạng thái sau R' và một giá trị băm của Khối H.

• Đầu vào chung: Gốc trạng thái trước R, Gốc trạng thái sau R', khối Hàm băm H
• Nhập riêng tư: Đối tượng trong trạng thái mà khối chương trình B, khối chương trình Q truy cập, đối tượng giống nhau sau khi thực hiện khối chương trình Q', chứng minh trạng thái (như nhánh Merkle) P
• Chủ张 1: P là một bằng chứng hợp lệ chứng minh rằng Q chứa một số phần của trạng thái được đại diện bởi R
• Chủ张 2: Nếu chạy STF trên Q, (i) quá trình thực hiện chỉ truy cập vào các đối tượng trong Q, (ii) các khối dữ liệu là hợp lệ, (iii) kết quả là Q'
• Chủ đề 3: Nếu tính toán lại trạng thái gốc mới bằng thông tin Q 'và P, ta sẽ có R'

Nếu có tình huống như vậy, bạn có thể sở hữu một phiên bản khách hàng nhẹ hoàn toàn xác minh việc thực thi EVM của Ethereum. Điều này khiến tài nguyên của khách hàng đã rất thấp. Để thực hiện một phiên bản khách hàng Ethereum hoàn toàn xác minh thực sự, bạn cũng cần làm việc tương tự với Nhận thức chung.

Hiện tại đã có sự triển khai của bằng chứng hợp lệ để sử dụng trong việc tính toán EVM và nó đã được sử dụng rộng rãi trên L2. Tuy nhiên, để làm cho bằng chứng hợp lệ EVM trên L1 trở nên khả thi, cần phải thực hiện nhiều công việc.

Có mối liên hệ nào với các nghiên cứu hiện có không?

• EFPSE ZK-EVM (vì có sự lựa chọn tốt hơn, đã ngừng sử dụng)
• Zeth, cách hoạt động của nó là biên dịch EVM vào RISC-0 ZK-VM
• ZK-EVM Xác minh chính thức项目

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

Hiện nay, hệ thống ghi chú điện tử đang tồn tại hai vấn đề chưa đủ: an ninh và thời gian xác minh.

Một bằng chứng hợp lệ an toàn cần đảm bảo rằng SNARK thực sự xác minh tính toán của EVM và không có lỗ hổng. Hai công nghệ chính để nâng cao tính bảo mật là đa xác minh và xác minh hình thức. Đa xác minh đề cập đến việc có nhiều bằng chứng hợp lệ độc lập được triển khai, tương tự như có nhiều khách hàng, nếu một khối được chứng minh bởi một tập con đủ lớn trong các triển khai này, khách hàng sẽ chấp nhận khối đó. Xác minh hình thức liên quan đến việc sử dụng các công cụ thường được sử dụng để chứng minh các định lý toán học, như Lean 4, để chứng minh rằng bằng chứng hợp lệ chỉ chấp nhận việc thực hiện chính xác các quy tắc EVM cơ bản (ví dụ như ngữ nghĩa EVM K hoặc quy tắc thi hành tầng EELS được viết bằng Python).

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

• Parallels - Hiện tại, trình xác minh EVM nhanh nhất có thể chứng minh một khối Ethereum trong vòng 15 giây. Điều này được thực hiện bằng cách song song hóa giữa hàng trăm GPU, sau đó tổng hợp công việc của họ cuối cùng lại với nhau. Lý thuyết, chúng ta hoàn toàn biết cách sản xuất một trình xác minh EVM có thể chứng minh tính toán trong thời gian O(log(N)): để một GPU hoàn thành từng bước, sau đó tạo một "cây tổng hợp":...

Có những thách thức để đạt được điều này. Ngay cả trong trường hợp xấu nhất, khi một giao dịch rất lớn chiếm toàn bộ Khối, việc phân vùng tính toán không thể được thực hiện trên cơ sở mỗi lần, mà phải được thực hiện trên cơ sở mỗi opcode (opcode của Máy ảo cơ bản như EVM hoặc RISC-V). Đảm bảo rằng "bộ nhớ" của Máy ảo nhất quán trên các phần khác nhau của bằng chứng là một thách thức chính trong quá trình thực hiện. Tuy nhiên, nếu chúng ta có thể thực hiện loại chứng minh đệ quy này, thì chúng ta biết rằng ngay cả khi không có cải tiến nào khác, ít nhất vấn đề Trễ của người chứng minh đã được giải quyết.

• Tối ưu hóa hệ thống chứng minh - Hệ thống chứng minh mới như Orion, Binius, GRK và nhiều thông tin khác có thể dẫn đến việc rút ngắn thời gian xác minh tính toán chung một lần nữa một cách đáng kể.
• Sự thay đổi khác về chi phí gas của EVM - Có nhiều điều trong EVM có thể được tối ưu hóa để làm cho nó thuận lợi hơn cho người chứng minh, đặc biệt là trong trường hợp xấu nhất. Nếu kẻ tấn công có thể xây dựng một Khối làm chậm người chứng minh trong mười phút, thì việc chỉ cần mất 4 giây để chứng minh một Khối ETH thông thường không đủ. Những thay đổi cần thiết của EVM có thể chia thành các loại sau:

• Thay đổi chi phí gas - Nếu một hoạt động mất nhiều thời gian để chứng minh, thì dù tốc độ tính toán của nó nhanh hơn, cũng nên có chi phí gas cao. EIP-7667 là một EIP được đưa ra để giải quyết vấn đề nghiêm trọng nhất trong việc này: nó tăng đáng kể chi phí gas của các hàm băm (truyền thống) vì các opcode và precompile của chúng rẻ relativ. Để bù đắp cho sự tăng chi phí gas này, chúng ta có thể giảm chi phí gas của các opcode EVM có chứng minh tương đối thấp, từ đó duy trì số lượng giao dịch trung bình không thay đổi.

• Thay đổi cấu trúc dữ liệu - Ngoài việc thay thế cây trạng thái bằng cách thân thiện với STARK, chúng ta cũng cần thay thế danh sách giao dịch, cây biên nhận và các cấu trúc khác tốn kém chi phí chứng minh. Việc Etan Kissling chuyển cấu trúc giao dịch và biên nhận sang SSZ trong EIP là một bước tiến trong hướng đó.

Ngoài ra, hai công cụ đã được đề cập trong phần trước (gas đa chiều và gốc trạng thái Trễ) cũng có thể cung cấp hỗ trợ trong lĩnh vực này. Tuy nhiên, điều đáng lưu ý là, khác với xác thực không trạng thái, việc sử dụng hai công cụ này đồng nghĩa với việc chúng ta đã có đủ kỹ thuật để hoàn thành công việc hiện tại của chúng ta, và ngay cả khi sử dụng các kỹ thuật này, xác thực ZK-EVM đầy đủ cũng cần nhiều hơn nữa công việc - chỉ cần ít hơn thôi.

Một điểm không được đề cập trong bài viết là phần cứng chứng minh: sử dụng GPU, FPGA và ASIC để tạo ra chứng minh 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 có giá trị đối với L2, nhưng không có khả năng trở thành yếu tố quyết định cho L1, vì mọi người mong muốn L1 duy trì tính phi tập trung cao, điều này có nghĩa là việc tạo ra chứng minh phải nằm trong phạm vi hợp lý của người dùng ETH, không bị hạn chế bởi phần cứng của một công ty duy nhất. L2 có thể đưa ra sự cân nhắc tích cực hơn.

Trong những lĩnh vực này, còn nhiều công việc phải làm:

• Yêu cầu chứng minh của Proof of Stake là các phần khác nhau của hệ thống có thể "chia sẻ bộ nhớ" (như bảng tra cứu). Chúng tôi biết công nghệ để làm điều này, nhưng cần phải triển khai nó.
• Chúng tôi cần phải tiến hành phân tích thêm để tìm ra tập hợp biến đổi chi phí gas lý tưởng, nhằm giảm thiểu thời gian xác minh trong trường hợp xấu nhất.
• Chúng ta cần phải làm nhiều hơn trong hệ thống chứng minh

Chi phí có thể là:

• Độ an toàn và thời gian xác thực của bộ xác minh: Nếu chọn hàm băm mạnh hơn, hệ thống chứng minh phức tạp hơn hoặc giả thiết an toàn mạnh hơn hoặc thiết kế khác, có thể rút ngắn thời gian xác thực của bộ xác minh.
• Phi tập trung và thời gian chứng minh: Cộng đồng cần đạt được sự thống nhất về 'thông số kỹ thuật' của phần cứng chứng minh mà nó đang nhắm đến. Có thể yêu cầu người chứng minh là một thực thể quy mô lớn không? Chúng tôi có hy vọng rằng một chiếc laptop tiêu dùng cao cấp có thể chứng minh một khối ETH trong vòng 4 giây? Hay nằm ở giữa hai điều đó?
• Mức độ phá vỡ tương thích ngược: Những thiếu sót khác có thể được bù đắp bằng việc 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 đồng đều đối với một số ứng dụng, buộc các nhà phát triển phải viết lại và triển khai lại mã để duy trì tính kinh tế. Tương tự, cả hai công cụ này cũng có tính phức tạp và nhược điểm riêng của chúng.

Làm thế nào nó tương tác với các phần khác của bản đồ đường đi?

Công nghệ cốt lõi cần thiết để thực hiện L1 EVM bằng chứng hợp lệ chia sẻ rất nhiều với hai lĩnh vực khác:

• Bằng chứng hợp lệ của L2 (hay còn gọi là "ZK rollup")
• Phương pháp chứng minh băm nhị phân STARK không có trạng thái

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

Ngoài ra, bằng chứng hợp lệ EVM của L1 có thể nâng cao đáng kể giới hạn gas của L1.

Bằng chứng hợp lệ của Nhận thức chung

Chúng tôi muốn giải quyết vấn đề gì?

Nếu chúng ta muốn hoàn toàn xác minh một khối ETH trong nhóm bằng SNARK, thì việc thực thi EVM không phải là phần duy nhất mà chúng ta cần phải chứng minh. Chúng ta cũng cần phải chứng minh Nhận thức chung, tức là một phần khác về việc xử lý gửi tiền, rút tiền, ký, cập nhật số dư của người xác minh và một số phần khác của Bằng chứng về cổ phần trong nhóm ETH.

Nhận thức chung比 EVM đơn giản hơn nhiều, nhưng thách thức mà nó đối mặt là chúng ta không có EVM L2 convolution, do đó phải hoàn thành phần lớn công việc dù sao. Do đó, bất kỳ việc thực hiện Nhận thức chung ETH坊 nào cũng cần phải "bắt đầu từ đầu", mặc dù hệ thống chứng minh chính nó có thể được xây dựng dựa trên công việc chia sẻ của nó.

Nó là gì, làm thế nào hoạt động?

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

• ECADD（được sử dụng để xác minh chữ ký BLS）
• Cặp (được sử dụng để xác minh chữ ký BLS)
• Giá trị băm SHA 256 (được sử dụng để đọc và cập nhật trạng thái)

Trong mỗi Khối, chúng ta cần chứng minh 1-16 BLS 12-381 ECADD cho mỗi trình xác thực (có thể có nhiều hơn một, vì chữ ký có thể được chứa trong nhiều bộ sưu tập). Điều này có thể được bù đắp bằng các kỹ thuật tính toán trước tập hợp con, vì vậy chúng ta có thể nói rằng mỗi Người xác thực chỉ cần chứng minh một ECADD BLS 12-381. Hiện tại, có 30.000 chữ ký xác thực cho mỗi vị trí. Trong tương lai, điều này có thể thay đổi theo hai hướng khi đạt được tính cuối cùng của một vị trí: nếu chúng ta đi theo con đường "vũ phu", số lượng Người xác thực trên mỗi vị trí có thể tăng lên 1 triệu. Đồng thời, nếu Orbit SSF được thông qua, số lượng trình xác nhận sẽ vẫn ở mức 32.768 hoặc thậm chí giảm xuống còn 8.192.

Cách hoạt động của BLS Aggregation: Chỉ cần một ECADD của mỗi người tham gia để xác minh chữ ký tổng cộng, thay vì một ECMUL. Tuy nhiên, 30000 ECADD vẫn là một lượng chứng cứ lớn.

Đối với việc ghép cặp, hiện tại mỗi khe chỉ có tối đa 128 chứng chỉ, điều này có nghĩa là cần xác minh 128 cặp. Thông qua ElP-7549 và các sửa đổi tiếp theo, mỗi khe có thể giảm xuống còn 16. Số lượng cặp ghép rất ít, nhưng chi phí rất cao: thời gian chạy (hoặc chứng minh) của mỗi cặp ghép dài gấp k lần so với ECADD.

Một thách thức chính của việc tính toán BLS 12-381 là không có đường cong với bậc bằng kích thước trường BLS 12-381, điều này tạo ra chi phí khá lớn cho bất kỳ hệ thống chứng minh nào. Ngược lại, cây Verkle được đề xuất cho ETH là được xây dựng trên đường cong Bandersnatch, điều này làm cho BLS 12-381 trở thành đường cong tự thể hiện trong hệ thống SNARK để chứng minh các nhánh Verkle. Một việc triển khai đơn giản có thể chứng minh được 100 G 1 phép cộng mỗi giây; để tăng tốc độ chứng minh đủ nhanh, hầu như chắc chắn cần các công nghệ tinh vi như GKR.

Đối với giá trị băm SHA 256, tình huống tồi tệ nhất hiện tại là khối chuyển đổi thời đại, toàn bộ cây cân bằng ngắn của người xác thực và nhiều cây cân bằng ngắn của người xác thực sẽ được cập nhật. Mỗi cây cân bằng ngắn của người xác thực chỉ có một byte, do đó có 1 MB dữ liệu sẽ được băm lại. Điều này tương đương với 32768 lần gọi SHA 256. Nếu có một nghìn người xác thực có số dư cao hơn hoặc thấp hơn một ngưỡng nhất định, cần cập nhật số dư hợp lệ trong bản ghi của người xác thực, điều này tương đương với một nghìn nhánh Merkle, do đó có thể cần 10000 lần giá trị băm. Cơ chế xáo trộn yêu cầu 90 Bit cho mỗi người xác thực (do đó cần 11 MB dữ liệu), nhưng điều này có thể tính toán bất kỳ lúc nào trong một thời đại. Trong trường hợp kết thúc một khe đơn, các con số này có thể tăng hoặc giảm tùy thuộc vào tình huống cụ thể. Việc xáo trộn trở nên không cần thiết, mặc dù Orbit có thể phục hồi một phần nhu cầu này.

Một thách thức khác là cần phải lấy lại tất cả trạng thái của tất cả các nhà xác thực, bao gồm cả Khóa công khai, mới có thể xác minh một Khối. Đối với 1 triệu nhà xác thực, việc chỉ đọc Khóa công khai cũng cần 48 triệu byte, cộng với các nhánh Merkle. Điều này đòi hỏi hàng triệu giá trị băm cho mỗi kỷ nguyên. Nếu chúng ta phải chứng minh tính hiệu quả của PoS, một phương pháp thực tế là một dạng tính toán có thể xác minh tăng dần nào đó: lưu trữ một cấu trúc dữ liệu độc lập bên trong hệ thống chứng minh, cấu trúc dữ liệu này được tối ưu hóa để tìm kiếm hiệu quả và chứng minh sự cập nhật đối với cấu trúc này.

Tóm lại, có rất nhiều thách thức. Để đối phó hiệu quả nhất với những thách thức này, có khả năng sẽ cần phải thiết kế lại beacon chain một cách sâu sắc, có thể đồng thời đi kèm với việc chuyển sang kết thúc một khe đơn. Những đặc điểm của việc thiết kế lại này có thể bao gồm:

• Thay đổi hàm băm của hàm băm: Hiện tại chúng tôi đang sử dụng hàm băm SHA 256 "đầy đủ", vì vậy vì lý do đệm, mỗi lần gọi đều phải tương ứng với hai lần gọi hàm nén nền tảng. Nếu chuyển sang hàm nén SHA 256, chúng tôi ít nhất có thể đạt được 2 lần lợi nhuận. Nếu chuyển sang Poseidon, chúng tôi có thể đạt được 100 lần tăng cường, giải quyết hoàn toàn tất cả các vấn đề của chúng tôi (ít nhất là trong mặt giá trị hàm băm): 1,7 triệu giá trị hàm băm mỗi giây (54 MB), thậm chí cả triệu ghi chúng ta cũng có thể "đọc" được trong vài giây trong chứng minh.
• Nếu đó là Orbit, sau đó lưu trữ trực tiếp bản ghi xác thực đã xáo trộn: Nếu chọn một số lượng nhất định của các xác thực (như 8192 hoặc 32768) làm ủy ban cho khe cắm cụ thể, sau đó đặt chúng trực tiếp vào trạng thái cạnh nhau, điều này chỉ cần ít nhất Hàm băm để đọc tất cả các Khóa công khai của xác thực vào chứng minh. Điều này cũng giúp hoàn thành tất cả các cập nhật cân đối một cách hiệu quả.
• Tổng hợp chữ ký: Bất kỳ giải pháp tổng hợp chữ ký hiệu suất cao nào đều liên quan đến một loại chứng minh đệ quy nào đó, các Nút khác nhau trong mạng sẽ chứng minh trung gian cho tập con chữ ký. Điều này tự nhiên chia sẻ công việc chứng minh cho nhiều Nút trong mạng, giảm đáng kể công việc của "người chứng minh cuối cùng".
• Các phương án chữ ký khác: Đối với chữ ký Lamport+ Merkle, chúng ta cần 256 + 32 giá trị băm để xác minh chữ ký; Nhân 32768 người ký, chúng ta có 9437184 giá trị băm. Sau khi tối ưu hóa phương án chữ ký, có thể cải thiện kết quả này thông qua một hằng số nhỏ. Nếu chúng ta sử dụng Poseidon, điều này có thể được chứng minh trong một khe cắm duy nhất. Tuy nhiên, thực tế cho thấy sử dụng phương án tổng hợp đệ quy sẽ nhanh hơn.

Có mối liên hệ nào với các nghiên cứu hiện có không?

• Chứng chỉ Ether Ethereum đơn giản (chỉ dành cho Hội đồng Đồng thuận)
• Helios trong SP 1 đơn giản
• BLS 12-381 biên dịch trước ngắn gọn
• Dựa trên Halo 2, xác minh chữ ký tập hợp BLS

Còn công việc nào cần phải làm, làm thế nào để lựa chọn:

Thực tế, chúng tôi cần mất vài năm để có được bằng chứng hợp lệ về Nhận thức chung của Ethereum. Điều này tương đương với thời gian cần thiết để thực hiện Single-slot Finality, Orbit, thay đổi thuật toán chữ ký và phân tích bảo mật, trong đó phân tích bảo mật yêu cầu đủ sự tự tin để sử dụng các hàm băm "cực đoan" như Poseidon. Do đó, cách thông minh nhất là giải quyết các vấn đề khác này và cân nhắc tính thân thiện của STARK trong quá trình giải quyết các vấn đề này.

Cân nhắc chính có thể nằm ở thứ tự thực hiện, giữa một phương pháp tiến bộ hơn và một phương pháp "thay đổi một lần nhiều" táo bạo hơn trong việc cải cách lớp đồng thuận Ethereum. Phương pháp tiến bộ là hợp lý cho EVM vì nó giảm thiểu tác động đến tính tương thích ngược. Đối với lớp đồng thuận, tác động đến tính tương thích ngược nhỏ, và việc xem xét lại các chi tiết xây dựng beacon chain một cách "toàn diện" để tối ưu hóa tính thân thiện với SNARK cũng có lợi.

Nó tương tác như thế nào với các phần khác của sơ đồ tuyến đường?

Trong quá trình thiết kế lại dài hạn cho ETH Ethereum PoS, sự thân thiện của STARK phải trở thành yếu tố hàng đầu, đặc biệt là tính kết thúc của một khe hở, Orbit, thay đổi chữ ký và việc tổng hợp chữ ký.