Vitalik: Điều gì sẽ xảy ra nếu ZK-EVM được đóng gói vào Ethereum L1?

Văn bản gốc: https://notes.ethereum.org/@vbuterin/enshrined_zk_evm
Người dịch: Cộng đồng Denlink ^[1] Nhóm dịch

Giao thức EVM lớp 2 được xây dựng trên Ethereum, bao gồm Optimistic Rollups và ZK Rollups, tất cả đều dựa trên Xác minh EVM. Tuy nhiên, điều này đòi hỏi họ phải tin tưởng vào một cơ sở mã lớn và nếu có lỗ hổng trong cơ sở mã, các máy ảo này có nguy cơ bị hack. Ngoài ra, ngay cả ZK-EVM được thiết kế hoàn toàn tương đương với L1 EVM cũng sẽ yêu cầu một số dạng cơ chế quản trị để nhân rộng các thay đổi từ L1 EVM sang triển khai EVM của chính nó.

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 Ethereum và ban quản trị Ethereum đã chịu trách nhiệm nâng cấp và sửa lỗi. Địa điểm: Về cơ bản, ZK-EVM thực hiện công việc xác thực các khối Ethereum Lớp 1! Ngoài ra, trong vài năm tới, chúng tôi hy vọng các máy khách hạng nhẹ ^[2] sẽ ngày càng trở nên mạnh mẽ hơn và sẽ sớm thực thi L1 EVM được xác thực hoàn toàn bằng cách sử dụng ZK-SNARK . Vào thời điểm đó, mạng Ethereum sẽ được tích hợp sẵn ZK-EVM. Do đó, một câu hỏi được đặt ra: tại sao không sử dụng ZK-EVM nguyên bản để tổng hợp?

Bài viết này sẽ giới thiệu một số phiên bản ZK-EVM được đóng gói có thể được triển khai và trình bày chi tiết về những cân nhắc cũng như thách thức trong thiết kế, như cũng như những gì không nên làm Lý do cho một hướng đi cụ thể. Cần cân nhắc lợi ích của việc triển khai các tính năng giao thức với lợi ích của việc để nó cho hệ sinh thái và giữ cho giao thức cơ bản đơn giản.

Bạn muốn nhận được những tính năng chính nào khi đóng gói ZK-EVM?

Chức năng cơ bản: Xác minh khối Ethereum. Tính năng giao thức (chưa được xác định liệu đó là opcode, tiền biên dịch hay cơ chế khác) phải chấp nhận (ít nhất) một gốc trước 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 trạng thái sau root thực sự nằm trên trạng thái gốc trước. Kết quả của việc thực thi khối.

Khả năng tương thích với triết lý đa khách hàng của Ethereum^[3], có nghĩa là chúng tôi hy vọng Tránh sử dụng thống chứng thực duy nhất và thay vào đó cho phép các khách hàng khác nhau sử dụng các hệ thống chứng thực khác nhau. Ngược lại, điều này có nghĩa là một số điều:

• Yêu cầu về tính khả dụng của dữ liệu: Đối với bất kỳ quá trình thực thi EVM nào thông qua ZK-EVM được đóng gói, chúng tôi mong muốnđảm bảo tính khả dụng của dữ liệu cơ bản^[4], Bằng cách này chứng minh việc sử dụng một hệ thống bằng chứng khác có thể chứng nhận lại việc thực thi và khách hàng dựa vào hệ thống bằng chứng đó có thể xác minh bằng chứng mới được tạo.

• Bằng chứng được lưu trữ bên ngoài EVM và chặn cấu trúc dữ liệu: Tính năng ZK-EVM không chấp nhận SNARK trực tiếp dưới dạng đầu vào EVM vì các máy khách khác nhau mong đợi các loại SNARK khác nhau. Thay vào đó, nó có thể tương tự như xác minh blob: giao dịch có thể bao gồm các xác nhận quyền sở hữu (tiền trạng thái, nội dung khối, trạng thái hậu) cần được chứng minh, opcode hoặc tiền biên dịch có thể truy cập nội dung của các xác nhận quyền sở hữu này và các quy tắc Đồng thuận của khách hàng sẽ kiểm tra riêng biệt tính khả dụng của dữ liệu và sự tồn tại của bằng chứng cho từng khiếu nại được đưa ra trong khối.

Khả năng kiểm tra: Nếu bất kỳ hoạt động thực thi nào được chứng minh, chúng tôi muốn dữ liệu cơ bản có sẵn cho người dùng và nhà phát triển có thể kiểm tra. 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 sẵn có của dữ liệu lại quan trọng.

Khả năng nâng cấp: Nếu tìm thấy lỗ hổng trong giải pháp ZK-EVM cụ thể, chúng tôi muốn có thể khắc phục lỗ hổng đó một cách nhanh chóng và Không cần hard fork. Điều này làm tăng thêm tầm quan trọng của bằng chứng được lưu trữ bên ngoài EVM và chặn cấu trúc dữ liệu.

Hầu như hỗ trợ - EVM: Một trong những điểm hấp dẫn của L2 là đổi mới ở cấp độ thực thi và mở rộng EVM. Nếu VM cho L2 nhất định chỉ khác một chút so với EVM thì sẽ thật tuyệt nếu các phần của L2 giống với EVM vẫn có thể sử dụng ZK-EVM trong giao thức gốc, chỉ dành cho các phần đó khác với EVM Dựa vào mã riêng của họ. Điều này có thể được thực hiện bằng cách thiết kế chức năng ZK-EVM theo cách cho phép người gọi chỉ định trường bit, mã opcode hoặc danh sách địa chỉ để được xử lý bởi một bảng được cung cấp bên ngoài thay vì bởi chính EVM. Chúng tôi cũng có thể tùy chỉnh chi phí gas trong một phạm vi giới hạn.

Mở và đóngHệ thống nhiều khách hàng

< strong >Khái niệm nhiều khách hàng có lẽ là yêu cầu quyết đoán nhất trong danh sách trên. Có 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 phải trả giá bằng việc trở thành một sự thay đổi khái niệm lớn hơn cho Ethereum (vì về cơ bản nó sẽ từ bỏ phần lớn những gì Ethereum có triết lý khách hàng lâu dài) và gây ra rủi ro lớn hơn. Trong tương lai lâu dài, chẳng hạn như khi các kỹ thuật xác minh chính thức trở nên phức tạp hơn, có thể tốt hơn nên đi theo con đường này, nhưng hiện tại nó có vẻ quá rủi ro.

Một tùy chọn khác là hệ thống nhiều khách hàng khép kín , trong đó một tập hợp các hệ thống chứng thực cố định được xác định trong giao thức. Ví dụ: chúng tôi có thể quyết định sử dụng ba ZK-EVM: PSE ZK-EVM^[5], Polygon ZK-EVM^[6] và Kakarot ^[7] . Một khối yêu cầu bằng chứng từ hai trong số ba điều này để được coi là hợp lệ. Điều này tốt hơn 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ì các trình xác nhận cho từng hệ thống bằng chứng, nhất thiết phải có tác động đối với những thứ như quy trình quản trị chính trị kết hợp các hệ thống bằng chứng mới.

Điều này dẫn tôi đến một hệ thống nhiều khách hàng mở nơi bằng chứng được đặt "bên ngoài khối" và được khách hàng cung cấp Xác minh từ đầu đến cuối. Người dùng cá nhân sẽ sử dụng ứng dụng khách mà họ muốn xác thực các khối, miễn là có người chứng minh tạo ra bằng chứng cho hệ thống bằng chứng. Các hệ thống bằng chứng có được ảnh hưởng bằng cách thuyết phục người dùng chạy chúng chứ không phải bằng cách thuyết phục các quy trình quản trị giao thức. Tuy nhiên, chi phí phức tạp của phương pháp này cao hơn, như chúng ta sẽ thấy.

Chúng tôi muốn triển khai ZK-EVM có những tính năng chính nào?

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

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

Chính xác thì chức năng ZK-EVM trong giao thức trông như thế nào?

Tương tự như giao dịch blob EIP-4844^[8], chúng tôi giới thiệu một giao dịch mới chứa các khiếu nại ZK-EVM Loại: < /p>

Tương tự như EIP-4844, đối tượng được truyền trong nhóm bộ nhớ sẽ là phiên bản sửa đổi của giao dịch:

Cái sau có thể được chuyển đổi thành cái trước, nhưng không được ngược lại. Chúng tôi cũng đã mở rộng đối tượng ô tô bên khối nhà (được giới thiệu trong EIP-4844^[9]) để bao gồm danh sách bằng chứng cho các khiếu nại được đưa ra trong khối.

Lưu ý rằng trong thực tế, rất có thể chúng tôi sẽ muốn chia sidecar thành hai sidecar riêng biệt, một cho blobs và một cho proofs, đồng thời có một mạng con riêng cho từng loại bằng chứng ( Ngoài ra còn có một mạng con cho blobs).

Trên lớp đồng thuận, chúng tôi đã thêm quy tắc xác minh: khách hàng chỉ có thể chấp nhận khối sau khi nhìn thấy bằng chứng hợp lệ cho 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 ghép transaction_and_witness_blobs là sự tuần tự hóa của cặp (Block, Witness) và khối được thực thi trên pre_state_root bằng Witness (i) hợp lệ và (ii) kết quả post_state_root đúng. Có khả năng, khách hàng có thể chọn đợi M-of-N của nhiều loại bằng chứng.

Một điểm triết học cần đề cập ở đây là việc thực thi khối có thể được xem đơn giản là bắt buộc với ZKEVMClaimTransaction One của các bộ ba (σ_pre,σ_post,Proof) được kiểm tra cùng với các bộ ba được cung cấp trong đối tượng. Do đó, việc triển khai ZK-EVM của người dùng có thể thay thế các máy khách thực thi của họ; các máy khách thực thi vẫn sẽ được sử dụng bởi (i) người chuẩn bị và người xây dựng khối cũng như (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ộ.

Xác minh và kiểm chứng

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

Thật không may, vì hệ thống chứng thực riêng lẻ không được đưa vào nên chúng không thể nhận được ưu đãi trong giao thức; tuy nhiên, chúng tôi cho rằng việc chạy so với nghiên cứu và phát triển Chi phí của người chứng nhận sẽ thấp hơn vì vậy chúng tôi có thể tài trợ cho người chứng nhận chỉ thông qua một cơ quan chung được sử dụng để tài trợ cho hàng hóa công.

Giả sử ai đó phát hành ZKEvmClaimNetworkTransaction nhưng chỉ phát hành phiên bản thử nghiệm của PSE ZK-EVM. Các nút chứng minh của Polygon ZK-EVM đã thấy điều này xảy ra, đã tính toán và xuất bản lại đối tượng bằng bằng chứng Polygon ZK-EVM.

Điều này 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 cuối cùng, từ δ đến 2δ+T_{chứng minh} (giả sử ở đây T< sub >chứng minh < 5s).

Tuy nhiên, tin tốt lànếu chúng tôi áp dụng tính hữu hạn của một thời điểm, chúng tôi gần như chắc chắn có thể kết hợp độ trễ bổ sung này với Nhiều vòng vốn có của sự chậm trễ đồng thuận được "kết nối" với nhau. Ví dụ: trong đề xuất 4 ô con ^[10] này, bước "bỏ phiếu trực tiếp" có thể chỉ cần kiểm tra tính hợp lệ của khối cơ bản, nhưng bước "đóng băng và xác nhận" đòi hỏi sự tồn tại của một chứng minh.

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

Mục tiêu lý tưởng của chức năng ZK-EVM là< mạnh>Hỗ trợ gần như EVM: Đây là EVM với một số tính năng bổ sung. Điều này có thể bao gồm các trình biên dịch trước mới, các opcode mới, các tùy chọn để viết hợp đồng bằng EVM hoặc một VM hoàn toàn khác (như trường hợp của Arbitrum Stylus^[11]) hoặc thậm chí có đồng bộ hóa Nhiều EVM song song để chéo -giao tiếp.

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

Bảng chi phí gas tùy chỉnh (người dùng không được phép giảm phí gas nhưng có thể tăng)

Tắt các mã opcode cụ thể

Đặt số khối (điều này có nghĩa là các quy tắc khác nhau tùy thuộc vào hard fork)

Đặt cờ kích hoạt toàn bộ các thay đổi EVM dành riêng cho L2 nhưng không dành cho L1 hoặc các thay đổi đơn giản khác

Để cho phép người dùng giới thiệu các tính năng mới một cách cởi mở hơn bằng cách giới thiệu các trình biên dịch trước (hoặc mã opcode) mới, chúng tôi có thể thêm các tập lệnh đầu vào/đầu ra được biên dịch sẵn được đưa vào như một phần của blob trong ZKEVMClaimNetworkTransaction tại:

Việc thực thi EVM sẽ được sửa đổi. Một mảng đầu vào sẽ được khởi tạo thành trống. Khi địa chỉ trong used_precompile_addresses được gọi lần thứ i, chúng tôi thêm InputsRecord(callee_address, gas, input_calldata) vào inputs và thay thế < được gọi mã >RETURNDATA được đặt thành outputs[i]. Cuối cùng, chúng tôi kiểm tra xem tổng cộng used_precompile_addresses đã được gọi là len(outputs) chưa và inputs_commitments có nhất quán với đầu vào không code> Kết quả của blob do quá trình tuần tự hóa SSZ tạo ra khớp với lời hứa. Mục đích của việc tiết lộ inputs_commitments là để tạo điều kiện cho 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 (được lưu dưới dạng hàm băm) và đầu ra (được lưu dưới dạng byte). Điều này là do việc thực thi cần phải đượ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. Các quá trình thực thi EVM đã được tạo sẵn đầ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 xác nhận hay không, việc này 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à do đó tính sẵn có của dữ liệu là điều bắt buộc.

Một tính năng hữu ích khác có thể là cho phép "các giao dịch đặc quyền" có thể đượ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 khi trình biên dịch trước được gọi trong một giao dịch khác (cũng có thể có đặc quyền). Đ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ế này có thể được sửa đổi để hỗ trợ các mã hoạt động mới hoặc đã sửa đổi bên cạnh các trình biên dịch trước mới hoặc đã sửa đổi. Ngay cả khi chỉ có trình biên dịch trước, thiết kế này vẫn rất mạnh mẽ. Ví dụ:

Bằng cách đặt used_precompile_addresses để bao gồm danh sách các địa chỉ tài khoản thông thường có gắn cờ nhất định trong trạng thái và tạo bằng chứng SNARK To chứng minh cấu trúc chính xác của nó, bạn có thể hỗ trợ các tính năng như kiểu Arbitrum Stylus, trong đó hợp đồng có thể viết mã của nó bằng EVM hoặc WASM (hoặc VM khác). Các giao dịch đặc quyền có thể được sử dụng để cho phép tài khoản WASM gọi lại EVM.

Bạn có thể chứng minh tính song song của nhiều EVM bằng cách thêm các kiểm tra bên ngoài để xác minh 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 khớp với nhau theo cách chính xác. hệ thống giao tiếp qua các kênh đồng bộ.

ZK-EVM loại 4^[13] có thể được chạy qua nhiều triển khai: một sẽ là Solidity hoặc cấp độ cao hơn khác. Ngôn ngữ là được chuyển đổi trực tiếp thành triển khai VM thân thiện với SNARK và một trình khác biên dịch nó thành mã EVM và thực thi nó trong ZK-EVM tích hợp sẵn. Quá trình triển khai thứ hai (chắc chắn là chậm hơn) chỉ có thể chạy trong trường hợp người chứng minh bị lỗi gửi xác nhận giao dịch dễ bị tấn công và thu tiền thưởng khi cung cấp giao dịch được xử lý khác.

Có thể triển khai một VM không đồng bộ thuần túy bằng cách làm cho tất cả các cuộc gọi trả về 0 và ánh xạ các cuộc gọi tới 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ợ cho những người chứng minh có trạng thái

Trên một thử thách với thiết kế là nó hoàn toàn không trạng thái, khiến dữ liệu của nó không hiệu quả. Sử dụng tính năng nén dữ liệu lý tưởng, việc gửi ERC20 có thể tiết kiệm không gian gấp 3 lần khi sử dụng tính năng nén có trạng thái so với chỉ sử dụng tính năng nén không trạng thái.

Ngoài ra, EVM có trạng thái không cần 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: yêu cầu phải có sẵn dữ liệu là một sự lãng phí vì chúng tôi đã biết rằng dữ liệu có sẵn vì dữ liệu đó đã được nhập hoặc tạo trong lần thực thi EVM trước đó.

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

Yêu cầu σ_pre phải trống hoặc danh sách có sẵn dữ liệu khóa và giá trị được khai báo trước hoặc thực thi trước đó của σ_{post Danh sách sub>}

To (σ_pre, σ_post, Proof ) Bộ dữ liệu thêm lời hứa blob với biên nhận do khối tạo R. Bất kỳ cam kết blob nào được tạo hoặc sử dụng trước đó đều có thể được tham chiếu trong ZKEVMClaimTransaction, bao gồm đại diện của các khối, nhân chứng, biên lai và thậm chí cả các giao dịch blob EIP-4844 thông thường, có thể với một số hạn chế về thời gian, có thể được truy cập trong quá trình thực thi ( Có thể thông qua một loạt hướng dẫn: "Chèn byte N...N+k-1 của cam kết i vào vị trí j của khối + dữ liệu chứng kiến")

(1) Về cơ bản: thay vì kết hợp xác minh EVM không trạng thái (đóng gói), hãy kết hợp chuỗi con EVM (đóng gói). (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 các đốm màu được sử dụng hoặc tạo trước đó làm từ điển. Cả hai phương pháp này sẽ tăng thêm gánh nặng cho nút chứng minh và chỉ nút chứng minh mới có thể lưu trữ nhiều thông tin hơn; trong trường hợp (2), việc thực hiện gánh nặng này bị giới hạn thời gian sẽ dễ dàng hơn so với trường hợp (1).

Các đối số cho các hệ thống đa bằng chứng khép kín và dữ liệu ngoài chuỗi

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

Tuy nhiên, các hệ thống đa chứng nhận khép kín làm tăng độ phức tạp trong quản trị và loại bỏ khả năng kiểm toán, đây là sự đánh đổi. Chi phí cao của những lợi ích này .

Nếu ZK-EVM đóng vai trò là chức năng giao thức, thì vai trò tiếp tục của dự án Layer2 là gì?

Chức năng xác minh EVM hiện do nhóm Layer2 triển khai sẽ được xử lý bởi giao thức, nhưng dự án Layer2 vẫn sẽ chịu trách nhiệm về nhiều chức năng quan trọng :< /p>

Xác thực trước nhanh: Tính hữu hạn của một vị trí có thể làm chậm các vị trí Lớp 1 mà dự án Lớp 2 đã cung cấp cho người dùng của nó Với "xác nhận trước" được hỗ trợ bởi bảo mật của chính Layer2, độ trễ thấp hơn nhiều so với một khe. Dịch vụ này sẽ tiếp tục được xử lý hoàn toàn bởi Layer2.

Chiến lược giảm nhẹ MEV : Điều này có thể bao gồm nhóm bộ nhớ được mã hóa, lựa chọn trình tự dựa trên danh tiếng và các tính năng khác mà Lớp 1 không muốn triển khai .

Phần mở rộng cho EVM : Các dự án Lớp 2 có thể bao gồm các phần mở rộng quan trọng cho EVM, mang lại giá trị lớn cho người dùng. Điều này bao gồm hầu hết EVM và các cách tiếp cận khác nhau như hỗ trợ WASM của Arbitrum Stylus và ngôn ngữ Cairo (https://www.cairo-lang.org/) thân thiện với SNARK.

Sự thuận tiện cho người dùng và nhà phát triển: Nhóm Layer2 cam kết thu hút người dùng và dự án vào hệ sinh thái của mình và khiến họ cảm thấy được chào đón. Chào mừng bạn ; họ được đền bù bằng cách thu lại MEV và phí tắc nghẽn trong mạng của họ. Mối quan hệ này sẽ tiếp tục tồn tại.