Vitalik: Thảo luận về các loại phiên bản "ZK-EVM tích hợp" khác nhau và những thách thức về thiết kế

Từ: Vitalik Buterin

Tổng hợp: 1912212.eth, Foresight News

Các giao thức EVM lớp 2 trên ETH, bao gồm các bản tổng hợp lạc quan và bản tổng hợp ZK, dựa trên xác thực EVM. Tuy nhiên, điều này đòi hỏi họ phải tin tưởng vào một cơ sở mã khổng lồ và nếu có lỗi trong cơ sở mã đó, các máy ảo này có nguy cơ bị tấn công. Ngoài ra, điều này có nghĩa là ngay cả ZK-EVM, muốn hoàn toàn tương đương với L1 EVM, cũng cần một số hình thức quản trị để sao chép các thay đổi đối với L1 EVM vào thực tiễn EVM của riêng họ.

Tình huống này không lý tưởng, vì các dự án này đang sao chép chức năng đã tồn tại trong giao thức ETH Workshop và ETH Governance đã chịu trách nhiệm nâng cấp và sửa lỗi: ZK-EVM về cơ bản là công việc tương tự như xác nhận các khối Xưởng ETH Lớp 1!Ngoài ra, trong những năm tới, chúng tôi hy vọng các máy khách nhẹ sẽ ngày càng trở nên mạnh mẽ hơn và sớm đạt đến điểm mà ZK-SNARK được sử dụng để xác thực đầy đủ việc thực thi EVM Lớp 1. Tại thời điểm đó, mạng ETH sẽ xây dựng hiệu quả ZK-EVM tích hợp. Vì vậy, câu hỏi đặt ra: tại sao không làm cho bản thân ZK-EVM cũng phù hợp cho các bản tổng hợp?

Trong bài viết này, chúng ta sẽ xem xét một vài phiên bản “ZK-EVM tích hợp” có thể được triển khai và thảo luận về sự đánh đổi và thách thức thiết kế, cũng như lý do không đi theo một hướng cụ thể. Lợi ích của việc triển khai các tính năng giao thức nên được cân nhắc với lợi ích của việc để mọi thứ cho hệ sinh thái và giữ cho giao thức cơ bản đơn giản.

Chúng ta muốn những tính năng chính nào từ ZK-EVM tích hợp?

• Chức năng cơ bản: Xác thực ETH khối. Hàm giao thức (chưa rõ liệu đó là opcode, precompilation hay cơ chế khác) nên chấp nhận ít nhất một gốc tiền trạng thái, một khối và một gốc sau trạng thái làm đầu vào và xác minh rằng gốc sau trạng thái thực sự là kết quả của việc thực thi khối.
• Tương thích với nhiều khách hàng của ETH Square. Điều này có nghĩa là chúng tôi chỉ muốn tránh một hệ thống chứng thực và thay vào đó cho phép các máy khách khác nhau sử dụng các hệ thống chứng thực khác nhau. Điều này dẫn đến các điểm sau:
• Yêu cầu về tính khả dụng của dữ liệu: Đối với bất kỳ thực thi EVM nào sử dụng ZK-EVM tích hợp để chứng minh, chúng tôi muốn đảm bảo tính khả dụng của dữ liệu cơ bản để người chứng minh sử dụng hệ thống chứng thực khác có thể chứng thực lại việc thực thi và cho phép khách hàng dựa vào hệ thống chứng thực đó xác thực các bằng chứng mới được tạo.
• Bằng chứng tồn tại bên ngoài cấu trúc dữ liệu EVM và khối: Tính năng ZK-EVM tích hợp không lấy SNARK làm đầu vào trong EVM, vì các máy khách khác nhau sẽ mong đợi các loại SNARK khác nhau. Thay vào đó, nó có thể tương tự như xác thực blob: một giao dịch có thể bao gồm các tuyên bố (trạng thái trước, nội dung khối, trạng thái sau) cần được chứng thực, nội dung có thể được truy cập bởi opcode hoặc trình biên dịch trước và các quy tắc đồng thuận phía máy khách sẽ kiểm tra tính khả dụng của dữ liệu và bằng chứng tồn tại cho từng khiếu nại riêng biệt.
• Khả năng kiểm toán. Nếu bất kỳ thực thi nào được chứng minh, chúng tôi muốn dữ liệu cơ bản có thể sử dụng được để trong trường hợp xảy ra sự cố, người dùng và nhà phát triển có thể kiểm tra nó. Trên thực tế, điều này bổ sung thêm một lý do khác tại sao các yêu cầu về tính khả dụng của dữ liệu rất quan trọng.
• Khả năng nâng cấp. Nếu phát hiện giải pháp ZK-EVM có lỗi, chúng tôi muốn có thể khắc phục nhanh chóng. Điều này có nghĩa là không cần một hard fork để sửa chữa. Điều này làm tăng thêm lý do tại sao các bằng chứng tồn tại bên ngoài EVM và các cấu trúc dữ liệu khối.
• Hỗ trợ hầu hết tất cả các EVM. Một trong những điểm thu hút của L2 là đổi mới ở lớp thực thi và mở rộng quy mô EVM. Nếu máy ảo cho một L2 nhất định chỉ khác một chút so với EVM, thì sẽ thật tuyệt nếu L2 vẫn có thể sử dụng ZK-EVM trong giao thức gốc trong các phần giống như EVM và chỉ dựa vào mã riêng của nó trong các phần khác nhau. Điều này có thể đạt được bằng cách thiết kế chức năng ZK-EVM cho phép người gọi chỉ định các trường bit hoặc danh sách opcode hoặc địa chỉ được xử lý bởi các bảng được cung cấp bên ngoài thay vì chính EVM. Chúng tôi cũng có thể làm cho chi phí gas mở để chỉnh sửa ở một mức độ nào đó.

Hệ thống đa khách hàng “mở” và “đóng”

“Triết lý đa khách hàng” có lẽ là yêu cầu chủ quan nhất trong danh sách này. Có một tùy chọn để từ bỏ nó và tập trung vào sơ đồ ZK-SNARK, điều này sẽ đơn giản hóa thiết kế, nhưng với chi phí là một “bước ngoặt triết học” lớn hơn cho Hội thảo ETH (vì nó thực sự từ bỏ triết lý đa khách hàng lâu đời của Hội thảo) và đưa ETH ra những rủi ro lớn hơn. Trong tương lai, khi công nghệ xác minh chính thức trở nên tốt hơn, có thể tốt hơn để chọn con đường này, nhưng bây giờ có vẻ như rủi ro là quá lớn.

Một tùy chọn khác là một hệ thống đa máy khách khép kín, nơi một tập hợp các hệ thống chứng thực cố định được biết đến trong giao thức. Ví dụ: chúng tôi có thể quyết định sử dụng ba ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM và Kakarot. Một khối yêu cầu bằng chứng được cung cấp bởi hai trong số ba khối này là hợp lệ. Điều này tốt hơn so với một hệ thống bằng chứng duy nhất, nhưng nó làm cho hệ thống ít thích ứng hơn vì người dùng phải duy trì trình xác thực cho từng hệ thống bằng chứng tồn tại và chắc chắn sẽ có các quy trình quản trị chính trị để kết hợp các hệ thống bằng chứng mới, v.v.

Điều này thúc đẩy tôi thích một hệ thống đa khách hàng mở, nơi các bằng chứng được đặt “bên ngoài khối” và được xác minh bởi khách hàng riêng lẻ. Người dùng cá nhân có thể sử dụng bất kỳ máy khách nào họ muốn xác thực các khối, miễn là ít nhất một prover tạo ra bằng chứng cho hệ thống chứng thực đó. Hệ thống chứng thực sẽ đạt được ảnh hưởng bằng cách thuyết phục người dùng chạy chúng, không phải bằng cách thuyết phục quá trình quản trị giao thức. Tuy nhiên, cách tiếp cận này có chi phí phức tạp cao hơn, như chúng ta sẽ thấy.

Chúng ta muốn đạt được những đặc tính chính nào từ việc triển khai ZK-EVM?

Ngoài tính chính xác chức năng cơ bản và đảm bảo an toàn, thuộc tính quan trọng nhất là tốc độ. Mặc dù chúng ta có thể thiết kế tính năng ZK-EVM trong giao thức, không đồng bộ và chỉ trả về mỗi câu trả lời được khai báo sau khi trì hoãn N vị trí, vấn đề trở nên dễ dàng hơn nhiều nếu chúng ta có thể đảm bảo một cách đáng tin cậy rằng bằng chứng sẽ được tạo ra trong vài giây, bất kể điều gì xảy ra trong mỗi khối là khép kín.

Mặc dù ngày nay phải mất nhiều phút hoặc hàng giờ để tạo ra các bằng chứng cho các khối ETH, chúng tôi biết rằng không có lý do lý thuyết nào để ngăn chặn song song hàng loạt: chúng tôi luôn có thể kết hợp đủ GPU để chứng minh các phần riêng lẻ của việc thực thi khối một cách riêng biệt và sau đó đặt các bằng chứng lại với nhau bằng SNARK đệ quy. Ngoài ra, tăng tốc phần cứng thông qua FPGA và ASIC có thể giúp tối ưu hóa hơn nữa các bằng chứng. Tuy nhiên, đi đến thời điểm này là một thách thức kỹ thuật rất lớn không nên đánh giá thấp.

Tính năng ZK-EVM có thể trông như thế nào trong giao thức?

Tương tự như các giao dịch blob EIP-4844, chúng tôi đã giới thiệu một loại giao dịch mới có chứa các tuyên bố ZK-EVM:

Điều quan trọng cần lưu ý là trong thực tế, chúng ta có thể muốn chia sideload thành hai sideload riêng biệt, một cho blob và một cho bằng chứng, và thiết lập một mạng con riêng cho từng loại bằng chứng (và một mạng con bổ sung cho blob).

Ở lớp đồng thuận, chúng tôi đã thêm quy tắc xác thực chỉ chấp nhận một khối nếu khách hàng thấy bằng chứng hợp lệ của từng khiếu nại trong khối. Bằng chứng phải là ZK-SNARK, chứng minh rằng việc nối giao dịch \ _and \ _witness \ _blobs là tuần tự hóa của cặp (Khối, Nhân chứng) và khối được thực thi với pre \ _state \ _root trên Nhân chứng

(i) là hợp lệ, và

(ii) Xuất bài đăng chính xác \ _state \ _root. Có thể, khách hàng có thể chọn chờ đợi nhiều loại bằng chứng về M-of-N.

Điều quan trọng cần lưu ý ở đây là bản thân việc thực thi khối có thể được coi đơn giản là một trong những bộ ba cần được kiểm tra cùng với bộ ba được cung cấp trong đối tượng ZKEVMClaimTransaction (σpre, σpost, Proof). Do đó, việc triển khai ZK-EVM của người dùng có thể thay thế máy khách thực thi của nó; máy khách thực thi sẽ vẫn được thực thi

(i) Provers và Block Builders và:

và (ii) các nút quan tâm đến việc lập chỉ mục và lưu trữ dữ liệu để sử dụng cục bộ.

Ngoài ra, vì kiến trúc này tách biệt việc thực thi khỏi xác nhận, nó có thể cung cấp tính linh hoạt và hiệu quả hơn cho các vai trò khác nhau trong hệ sinh thái ETH. Ví dụ: một prover có thể tập trung vào việc tạo ra các bằng chứng mà không phải lo lắng về các chi tiết cụ thể của việc thực thi, trong khi các máy khách thực thi có thể được tối ưu hóa để đáp ứng nhu cầu của người dùng cụ thể, chẳng hạn như đồng bộ hóa nhanh hoặc khả năng lập chỉ mục nâng cao.

Xác minh và chứng thực lại

Giả sử có hai máy khách ETH, một sử dụng PSE ZK-EVM và một sử dụng Polygon ZK-EVM, tại thời điểm này, cả hai triển khai đã phát triển đến mức chúng có thể chứng minh việc thực thi khối ETH trong vòng chưa đầy 5 giây và đối với mỗi hệ thống chứng minh, có đủ tình nguyện viên độc lập chạy phần cứng để tạo bằng chứng.

Thật không may, vì các hệ thống bằng chứng riêng lẻ không được chính thức hóa, chúng không thể được khuyến khích trong giao thức, tuy nhiên, chúng tôi dự đoán rằng chi phí chạy bằng chứng sẽ thấp hơn so với nghiên cứu và phát triển, vì vậy chúng tôi có thể dễ dàng tài trợ cho các nhà chứng minh thông qua các tổ chức được tài trợ cho hàng hóa công cộng.

Giả sử ai đó xuất bản ZKEvmClaimNetworkTransaction, nhưng họ chỉ xuất bản bằng chứng về phiên bản PSE ZK-EVM. Proof Node của Polygon ZK-EVM nhìn thấy điều này, tính toán và xuất bản lại đối tượng, cùng với Proof of the Polygon ZK-EVM.

Điều này sẽ làm tăng tổng độ trễ tối đa giữa nút trung thực sớm nhất chấp nhận một khối và nút trung thực mới nhất chấp nhận cùng một khối từ δ lên 2δ + Tprove (giả sử Tprove<5s ở đây).

Tuy nhiên, tin tốt là nếu chúng ta áp dụng tính cuối cùng của một vị trí, chúng ta gần như chắc chắn có thể “đường ống” sự chậm trễ bổ sung này cùng với độ trễ đồng thuận nhiều vòng vốn có trong SSF. Ví dụ: trong đề xuất 4 vị trí này, bước “bỏ phiếu đầu” có thể chỉ cần kiểm tra tính hợp lệ của khối cơ sở, nhưng bước “đóng băng và xác nhận” sẽ yêu cầu sự hiện diện của bằng chứng.

Tiện ích mở rộng: Hỗ trợ “gần như EVM”

Mục tiêu mong muốn cho tính năng ZK-EVM là hỗ trợ “gần như EVM”: EVM với các tính năng bổ sung. Điều này có thể bao gồm biên dịch trước, opcode mới, hợp đồng có thể là EVM hoặc các máy ảo hoàn toàn khác nhau (ví dụ: trong Arbitrum Stylus) hoặc thậm chí nhiều EVM song song với giao tiếp chéo đồng bộ.

Một số sửa đổi có thể được hỗ trợ một cách đơn giản: chúng ta có thể xác định ngôn ngữ cho phép ZKEVMClaimTransaction vượt qua mô tả đầy đủ về quy tắc EVM đã sửa đổi. Điều này có thể được sử dụng trong các tình huống sau:

1. Bảng chi phí gas tùy chỉnh (người dùng không được phép giảm chi phí gas, nhưng họ có thể tăng chúng)
2. Vô hiệu hóa một số opcodes nhất định
3. Đặt số khối (điều này có nghĩa là có các quy tắc khác nhau tùy thuộc vào hard fork)
4. Đặt cờ để kích hoạt toàn bộ các thay đổi EVM đã được tiêu chuẩn hóa cho L2 nhưng không được sử dụng cho L1 hoặc các thay đổi đơn giản khác

Để cho phép người dùng thêm chức năng mới theo cách cởi mở hơn, ví dụ bằng cách giới thiệu một bản biên dịch sẵn (hoặc opcode) mới, chúng ta có thể thêm một cách để bao gồm các bản ghi đầu vào / đầu ra được biên dịch trước trong phần blob của ZKEVMClaimNetworkTransaction:

class PrecompileInputOutputTran(Container):used_precompile_addresses: List[Address][VersionedHash]inputs_commitments: Danh sách[Bytes]kết quả đầu ra: Danh sách

Việc thực thi EVM sẽ được sửa đổi như sau. Một mảng được gọi là đầu vào sẽ được khởi tạo dưới dạng trống. Bất cứ khi nào địa chỉ trong used_precompile_addresses được gọi, chúng ta thêm một đối tượng InputsRecord(callee_address, Gas, input_calldata) vào đầu vào và đặt RETURNDATA được gọi là đầu ra[i]。 Cuối cùng, chúng tôi kiểm tra xem sử dụng \ _precompile \ _addresses được gọi là len (đầu ra) tổng số lần và đầu vào \ _commitments khớp với kết quả của cam kết của blob kết quả đối với tuần tự hóa SSZ của đầu vào. Mục đích của việc phơi bày đầu vào \ _commitments là để cho phép SNARK bên ngoài chứng minh mối quan hệ giữa đầu vào và đầu ra.

Lưu ý sự bất đối xứng giữa đầu vào và đầu ra, trong đó đầu vào được lưu trữ trong hàm băm và đầu ra được lưu trữ theo byte phải được cung cấp. Điều này là do việc thực thi cần được thực hiện bởi một máy khách chỉ nhìn thấy đầu vào và hiểu EVM. Thực thi EVM đã tạo đầu vào cho chúng, vì vậy chúng chỉ cần kiểm tra xem đầu vào được tạo có khớp với đầu vào được khai báo hay không, chỉ yêu cầu kiểm tra hàm băm. Tuy nhiên, đầu ra phải được cung cấp đầy đủ cho họ, vì vậy dữ liệu sẵn có phải có sẵn.

Một tính năng hữu ích khác có thể là cho phép “giao dịch đặc quyền” được gọi từ bất kỳ tài khoản người gửi nào. Các giao dịch này có thể được chạy giữa hai giao dịch khác hoặc trong một giao dịch khác (và có thể là đặc quyền), trong khi gọi precompilation. Điều này có thể được sử dụng để cho phép các cơ chế không phải EVM gọi lại EVM.

Thiết kế có thể được sửa đổi để hỗ trợ opcode mới hoặc sửa đổi, ngoài các bản biên dịch trước mới hoặc sửa đổi. Ngay cả khi chỉ biên dịch trước, thiết kế rất mạnh mẽ. Ví dụ:

Chức năng như Arbitrum Stylus có thể được hỗ trợ bằng cách cài đặt used \ _precompile \ _addresses để bao gồm danh sách các địa chỉ tài khoản thông thường với một cờ nhất định được đặt trong đối tượng tài khoản của chúng trong trạng thái và tạo SNARK chứng minh rằng chúng được xây dựng chính xác, nơi hợp đồng có thể viết mã của nó trong EVM hoặc WASM (hoặc máy ảo khác). Các giao dịch đặc quyền có thể được sử dụng để cho phép các tài khoản WASM gọi lại EVM.

Bằng cách thêm kiểm tra bên ngoài để đảm bảo rằng các bản ghi đầu vào / đầu ra và các giao dịch đặc quyền được thực hiện bởi nhiều EVM được khớp theo cách chính xác, một hệ thống song song gồm nhiều EVM giao tiếp với nhau qua kênh đồng bộ hóa có thể được chứng minh.

ZK-EVM loại 4 có thể hoạt động bằng cách có nhiều triển khai: một triển khai chuyển đổi Solidity hoặc một ngôn ngữ cấp cao hơn khác trực tiếp thành máy ảo thân thiện với SNARK và một triển khai khác biên dịch nó thành mã EVM và thực thi nó trong ZK-EVM theo quy định. Việc triển khai thứ hai (và chắc chắn chậm hơn) chỉ có thể chạy nếu người chứng minh thất bại gửi một giao dịch tuyên bố có lỗi và nếu họ có thể cung cấp rằng cả hai xử lý các giao dịch khác nhau, tiền thưởng có thể được thu thập.

Bạn có thể triển khai một máy ảo không đồng bộ thuần túy bằng cách trả về 0 cho tất cả các cuộc gọi và ánh xạ các cuộc gọi đến các giao dịch đặc quyền được thêm vào cuối khối.

Tiện ích mở rộng: Hỗ trợ Bằng chứng Nhà nước

Thách thức với thiết kế trên là nó hoàn toàn không có trạng thái, điều này làm cho nó kém về hiệu quả dữ liệu. Với tính năng nén dữ liệu lý tưởng, nén trạng thái có thể làm cho ERC20 tiết kiệm không gian hơn tới 3 lần so với nén không trạng thái đơn thuần.

Thêm vào đó, EVM trạng thái không bắt buộc phải cung cấp dữ liệu nhân chứng. Trong cả hai trường hợp, nguyên tắc đều giống nhau: thật lãng phí khi yêu cầu dữ liệu có sẵn khi chúng ta đã biết rằng dữ liệu có sẵn vì nó được nhập hoặc tạo ra bởi việc thực thi EVM trước đó. **

Nếu chúng tôi muốn làm cho tính năng ZK-EVM ở trạng thái, chúng tôi có hai tùy chọn:

Yêu cầu σpre phải là null hoặc danh sách các khóa và giá trị được khai báo trước mà dữ liệu có sẵn hoặc một số σpost đã được thực thi trước đó.

Thêm một cam kết blob vào bộ dữ liệu (σpre, σpost, proof) cho biên lai R được tạo bởi khối. Bất kỳ cam kết blob nào được tạo hoặc sử dụng trước đó có thể được tham chiếu trong ZKEVMClaimTransaction và được truy cập trong quá trình thực hiện, bao gồm các cam kết đại diện cho các khối, nhân chứng, biên lai hoặc thậm chí các giao dịch blob EIP-4844 thông thường (có thể có một số giới hạn thời gian, có thể được tham chiếu bởi một loạt các hướng dẫn: “Chèn byte N của cam kết i tại vị trí j của khối + dữ liệu nhân chứng… N+k-1”)

(1) Ý nghĩa cơ bản là: thay vì thiết lập xác minh EVM không trạng thái, chúng tôi sẽ thiết lập một chuỗi con EVM.

và (2) về cơ bản tạo ra một thuật toán nén trạng thái tích hợp tối thiểu sử dụng blob được sử dụng hoặc tạo trước đó làm từ điển. Cả hai đều đặt gánh nặng lên nút prover và chỉ có nút prover để lưu trữ thêm thông tin;

Trong trường hợp (2), việc hạn chế gánh nặng này sẽ dễ dàng hơn, trong khi trong trường hợp (1) thì khó khăn hơn.

Đối số cho các hệ thống đa prover khép kín và dữ liệu ngoài chuỗi

Một hệ thống đa prover khép kín, trong đó có một số lượng chứng minh cố định trong cấu trúc M-of-N, tránh được phần lớn sự phức tạp được mô tả ở trên. Đặc biệt, một hệ thống đa đính kèm khép kín không cần phải lo lắng về việc đảm bảo rằng dữ liệu tồn tại trên chuỗi. Ngoài ra, một hệ thống đa gắn khép kín sẽ cho phép các bằng chứng ZK-EVM được thực thi ngoài chuỗi, làm cho chúng tương thích với các giải pháp plasma EVM.

Tuy nhiên, các hệ thống đa phụ thuộc khép kín làm tăng độ phức tạp của quản trị và làm suy yếu khả năng kiểm toán, đây là một chi phí cao cần được cân nhắc với những lợi thế này.

Nếu chúng ta xây dựng trong ZK-EVM và biến nó thành một tính năng giao thức, vai trò liên tục của dự án L2 là gì?

Các chức năng xác thực EVM hiện đang được thực hiện bởi chính nhóm L2 sẽ được xử lý bởi giao thức, nhưng dự án L2 vẫn sẽ chịu trách nhiệm cho một số chức năng quan trọng:

• Xác nhận trước nhanh: Tính cuối cùng của một khe cắm có thể làm chậm các khe L1, trong khi L2 đã cung cấp cho người dùng dịch vụ được hỗ trợ xác nhận trước với bảo mật riêng, với độ trễ ít hơn nhiều so với một khe cắm. Dịch vụ này sẽ tiếp tục là trách nhiệm duy nhất của L2.
• Chiến lược giảm thiểu MEV: Điều này có thể bao gồm các tính năng như mempool được mã hóa, lựa chọn tuần tự dựa trên danh tiếng, v.v., mà L1 không muốn thực hiện.
• Tiện ích mở rộng cho EVM: Các dự án cấp 2 có thể giới thiệu các phần mở rộng đáng kể cho EVM mang lại giá trị đáng kể cho người dùng của họ. Điều này bao gồm “gần như EVM” và các cách tiếp cận hoàn toàn khác nhau, chẳng hạn như hỗ trợ WASM của Arbitrum Stylus và ngôn ngữ Cairo thân thiện của SNARK.
• Thuận tiện cho người dùng và nhà phát triển: Các nhóm cấp 2 nỗ lực rất nhiều trong việc thu hút người dùng và dự án vào hệ sinh thái của họ và khiến họ cảm thấy được chào đón; họ được trả tiền bằng cách thu thập MEV và phí tắc nghẽn trong mạng của họ. Mối quan hệ này là ở đây để ở lại.