Thực hiện chậm trễ với zkVMs

Bởi Kev và Julian. Cảm ơn Toni và Francesco đã phản hồi.

Delayed execution là một bản nâng cấp được đề xuất cho Ethereum giúp tăng Gas Limit. Thay vì cần phải thực thi Block trước khi xác nhận, với delayed execution, người xác nhận sẽ vượt qua các kiểm tra đơn giản trên Block **và bỏ phiếu cho khối đó trước khi thực hiện các giao dịch. Thay đổi Máy ảo Ethereum (EVM) hiện tại bằng zkVM là một bản nâng cấp Ethereum khác được đề xuất để tăng Gas Limit. Với zkVM, người xác nhận chỉ cần xác minh bằng chứng ngắn gọn rằng Block đã được thực hiện hợp lệ. Bài đăng này khám phá sự tương tác giữa delayed execution và zkVM. Lưu ý rằng một trong những mục tiêu chính của delayed execution là tạo điều kiện cho việc chứng minh zkVM trên Ethereum L1.

Chúng tôi đề xuất giao trách nhiệm chứng minh việc thực hiện đúng Block n cho người xây dựng Block đó, nhưng cho phép người xây dựng đó đưa bằng chứng vào Block của khe n+1 .

Đề xuất này cải thiện sự liên kết động cơ của việc chứng minh, đặc biệt là đối với cái gọi là " prover killers ". Prover killers là các khối được xây dựng đặc biệt để tốn kém khi chứng minh, trong khi lại tương đối rẻ khi tạo ra. Chúng tận dụng sự bất đối xứng giữa những gì giao thức Ethereum tính phí theo đơn vị gas cho các hoạt động và chi phí thực tế mà người chứng minh phải chịu. Nếu người xây dựng khe n+1 chịu trách nhiệm chứng minh Block n , thì người xây dựng khe n có thể tạo ra một prover killer như vậy để làm đau lòng người xây dựng khe n+1 . Đề xuất này loại bỏ sự không tương thích về động cơ đó bằng cách chỉ định trách nhiệm chứng minh Block n cho người xây dựng khe n .

Một trường hợp đặc biệt mà sự liên kết khuyến khích được cải thiện hữu ích là nếu có vấn đề Liveness của trình xây dựng. Giả sử có một trình xây dựng cực kỳ mạnh mẽ tạo ra một Block lớn rồi ngoại tuyến (hoặc một nhóm các trình xây dựng hoạt động giống như trình xây dựng này). Trong trường hợp đó, các trình xây dựng dự phòng nhỏ hơn có thể không tạo được bằng chứng cho Block trước đó. Kiến thức này có thể cho phép (nhóm) trình xây dựng "giữ tiền chuộc Ethereum" và trích tiền thuê. Nếu trình xây dựng khe n chịu trách nhiệm về bằng chứng của khe n , hiện tượng này sẽ biến mất. Nếu trình xây dựng ngoại tuyến, nội dung Block sẽ bị bỏ qua (như mô tả bên dưới) và trình xây dựng khe tiếp theo có thể xây dựng một Block mà nó có thể tự chứng minh. Do đó, đề xuất này giúp tách Xuất lượng khỏi quá trình xây dựng cục bộ vì nó có lợi cho Liveness của quá trình sản xuất Block .

Đề xuất bằng chứng cùng khe cắm

• Slot n , t=0 : Người xây dựng slot n truyền bá Block beacon. Tải trọng thực thi được đóng gói thành một blob và được gossiped.

• Khe n , t=X (Giống như t = 2): Người chứng thực xác thực tĩnh Block đèn hiệu như được nêu trong Đề xuất cải tiến Ethereum (EIP) thực thi bị trì hoãn.

• Khe n , t=Y (Giống như t = 9) (Hạn chót quan sát bằng chứng): Người chứng thực đóng băng quan điểm của họ về việc liệu có bằng chứng nào khả dụng hay không, lấy gốc trước trạng thái và cam kết kzg cho một blob làm đầu vào và đưa ra gốc sau trạng thái.

• Khe n+1 , t=0 : Người xây dựng khe n+1 bao gồm bằng chứng thực hiện đúng Block trước đó nếu có.

• Khe n+1 , t=X : Người kiểm tra xác thực hoàn toàn Block n . Mỗi người kiểm tra thực hiện bằng cách chạy các kiểm tra sau đây đối với chế độ xem cục bộ của mình.

  • Bằng chứng của Block n có sẵn tại thời điểm quan sát bằng chứng không?
  • Nếu vậy, bằng chứng có đúng không?
  • Nếu vậy, blob có tương ứng với cam kết kzg trong blob không?

  Nếu người chứng thực trả lời có cho tất cả các câu hỏi, thì nó sẽ bỏ phiếu cho Block n+1 nếu nó bao gồm bằng chứng của Block n . Nếu người chứng thực trả lời không cho câu hỏi đầu tiên, thì nó sẽ bỏ phiếu cho Block nếu một trong hai điều kiện sau đây xảy ra:

  • Không có bằng chứng nào được đưa vào Block.
  • Một bản chứng minh chính xác đã được đưa vào cam kết kzg tương ứng với một blob có sẵn.

Nếu không có bằng chứng nào cho Block n được đưa vào Block n+1 hoặc dữ liệu blob tương ứng với bằng chứng không khả dụng, Block n+1 sẽ coi việc thực thi Block n là no-op, nghĩa là trạng thái trước của Block n+1 giống hệt với trạng thái trước của Block n . Cơ chế này đảm bảo rằng cả dữ liệu bằng chứng và dữ liệu tải trọng đều khả dụng, đảm bảo tính bảo mật và Liveness. Như Toni và Francesco lập luận ở đây , việc coi Block là no-op không làm lộ dữ liệu khả dụng miễn phí, vì Block Producer từ bỏ phần thưởng thực thi để có được dữ liệu khả dụng "miễn phí".

Lưu ý rằng người chứng thực của khe n cũng xác thực đầy đủ Block n-1 và người chứng thực của khe n+1 cũng xác thực tĩnh Block n+1 . Xác thực đầy đủ bao gồm việc xác minh tính đúng đắn và tính kịp thời của bằng chứng như mô tả ở trên.

Những cân nhắc thêm

Kiến trúc Same-Slot Proof dựa trên view-merge, một tiện ích fork-choice được Francesco mô tả trong bài đăng này. View-merge giả định rằng độ trễ mạng thấp hơn một hằng số nào đó, Δ . Thời hạn quan sát bằng chứng nên được đặt chậm nhất là t = 12 - Δ . Nếu độ trễ mạng nhỏ hơn Δ , chế độ xem của người xây dựng là siêu tập của các chế độ xem đóng băng của người chứng thực, nghĩa là người chứng thực sẽ không buộc người xây dựng phải đưa vào một bằng chứng được đồn đại sau thời hạn quan sát bằng chứng, ngăn chặn các cuộc tấn công split-view. View-merge là cùng một tiện ích fork-choice hỗ trợ các thiết kế như MEV-Burn và FOCIL .

Cuối cùng, lưu ý rằng kiến ​​trúc Same-Slot Proof không phụ thuộc vào việc một hay nhiều zkVM được bảo vệ. Nếu cần bằng chứng của nhiều bằng chứng zkVM, người xác thực xác thực đầy đủ một Block nên kiểm tra xem có nhiều bằng chứng chính xác được đưa vào Block hay không, nếu cần, theo quan điểm cục bộ của họ.