Phân loại các đảm bảo xác nhận trước và các điều kiện Slashing của chúng trong Rollup

Bài viết này được dịch máy
Xem bản gốc

Phân loại các đảm bảo xác nhận trước và các điều kiện Slashing của chúng trong Rollup

Cảm ơn mteam và Justin Drake đã phản hồi và bình luận về bài viết này. Cảm ơn Ink L2 đã tài trợ cho nghiên cứu của tôi

Các xác nhận trước trong các bản tổng hợp lạc quan có thể cung cấp nhiều mức độ đảm bảo khác nhau cho người dùng, từ sự bao gồm cơ bản đến sự đảm bảo mạnh mẽ về thứ tự và kết quả thực hiện. Tuy nhiên, việc thiếu một phân loại chính thức đã dẫn đến sự chồng chéo và đôi khi là các định nghĩa trùng lặp trong các cuộc thảo luận. Tài liệu này đề xuất một danh mục có cấu trúc về các đảm bảo xác nhận trước, với mục tiêu thiết lập ranh giới rõ ràng giữa từng loại. Tài liệu này cũng xác định các điều kiện Slashing liên quan và độ phức tạp về mặt tính toán cần thiết để thực thi chúng, cho phép các thiết kế tổng hợp lý luận chặt chẽ về sự an toàn, UX và sự đánh đổi trong quá trình triển khai.

Có bốn đảm bảo thiết yếu cho việc xác nhận trước:

  • Bao gồm
    • Để thực thi việc bao gồm thông qua tin nhắn đã ký, trình tự xác nhận trước phải bao gồm giao dịch trong Block đã chỉ định.
  • Đặt hàng
    • Việc thực thi sắp xếp thông qua tin nhắn đã ký yêu cầu trình tự xác nhận trước phải bao gồm giao dịch ở số thứ tự đã chỉ định trong Block đã chỉ định.
  • Thực hiện thành công
    • Thành công thực hiện đảm bảo giao dịch sẽ không bị đảo ngược, bất kể trạng thái đầu vào chính xác hay mức tiêu thụ gas . Tuy nhiên, nó không đảm bảo thay đổi trạng thái cụ thể trừ khi cam kết sau trạng thái cũng được thực hiện.
  • Bảo lãnh sau nhà nước
    • Việc thực thi bảo đảm sau trạng thái thông qua tin nhắn đã ký yêu cầu trình tự xác nhận trước phải bao gồm giao dịch và đảm bảo các tham số trước trạng thái và đột biến sau trạng thái trong quá trình thực thi khớp với phản hồi đã ký từ trình tự xác nhận trước.

Thể loại 0

Đảm bảo bao gồm. Không đảm bảo về thành công trong việc đặt hàng hoặc thực hiện.

Đây là bảo đảm yếu nhất. Người giao dịch nhận được bảo đảm bao gồm thông qua phản hồi xác nhận trước. Tuy nhiên, việc sắp xếp không được bảo đảm và kết quả thực hiện không chắc chắn.

Điều kiện Slashing cho danh mục này sẽ là bằng chứng cho thấy giao dịch không được đưa vào cây giao dịch.

Tuy nhiên, bằng chứng không bao gồm đối với một cây giao dịch không có thứ tự có thể phức tạp về mặt tính toán trong Máy ảo Ethereum (EVM) do yêu cầu bằng chứng loại trừ đối với tất cả các giao dịch trong cây giao dịch.

Ví dụ:

Bao gồm Sàn phi tập trung (DEX) Mempool cho lệnh giới hạn
Người dùng gửi lệnh giới hạn đến Sàn phi tập trung (DEX) dựa trên rollup. Trình sắp xếp cung cấp bảo đảm đã ký rằng giao dịch sẽ được đưa vào Block tiếp theo, nhưng thứ tự cuối cùng không được chỉ định. Điều này cho phép giao diện Sàn phi tập trung (DEX) hiển thị cho người dùng rằng lệnh của họ sẽ được xem xét, nhưng không đưa ra lời hứa về thành công hoặc kết quả thực hiện (có thể bị ảnh hưởng bởi Slippage (Trượt giá), điều kiện chạy đua hoặc chạy trước)

Thể loại 1

Đảm bảo bao gồm và sắp xếp. Không đảm bảo thực hiện thành công.

Điều kiện Slashing cho danh mục này sẽ là bằng chứng cho thấy giao dịch không được đưa vào cây giao dịch.

Việc sử dụng số thứ tự cho giao dịch trình tự đã ký sẽ làm giảm độ phức tạp về mặt tính toán bằng cách cho phép chứng minh không bao gồm là chứng minh bằng phản chứng bằng cách cung cấp giao dịch theo trình tự đã chỉ định và chứng thực Cây Merkle Patricia (PMT) đi kèm.

Ví dụ:

Đúc NFT với Khe ưu tiên
Trong quá trình thả NFT, người dùng có thể trả tiền cho các vị trí Mint ưu tiên. Trình sắp xếp trả về một xác nhận trước đã ký hứa rằng một giao dịch đúc sẽ được đưa vào một vị trí trình tự cụ thể. Tuy nhiên, nếu người dùng không đủ tiền hoặc gas, giao dịch vẫn có thể hoàn nguyên. Điều này đảm bảo tính công bằng trong việc sắp xếp trong khi chuyển giao rủi ro thực hiện cho người dùng.

Thể loại 2

Đảm bảo thành công trong việc bao gồm và thực hiện. Không đảm bảo về việc đặt hàng hoặc sau khi ra lệnh.

Thể loại này đảm bảo rằng giao dịch sẽ được thực hiện mà không có sự đảo ngược mà không có bất kỳ đảm bảo nào về đầu vào hoặc đầu ra của cây trạng thái cho việc thực hiện giao dịch. Đảm bảo này cho phép trình tự phát hành xác nhận trước khả năng trích xuất MEV từ các giao dịch được xác nhận trước trong khi vẫn đảm bảo chắc chắn cho người giao dịch về sự thành công của việc thực hiện.

Điều kiện Slashing cho loại này sẽ giống hệt với loại 0. Tuy nhiên, bằng chứng không đảo ngược sẽ yêu cầu thực hiện lại Block trong Máy ảo Ethereum (EVM) cho đến khi giao dịch được thực hiện.

Ví dụ:

Giao dịch Sàn phi tập trung (DEX) bị giới hạn trượt giá với tính linh hoạt của MEV
Người dùng gửi giao dịch đến Sàn phi tập trung (DEX) với mức Slippage (Trượt giá) tối đa được chỉ định (ví dụ: "bán 1000 USDC với giá ít nhất 0,98 ETH"). Trình sắp xếp trả về xác nhận trước đảm bảo giao dịch sẽ thành công (tức là không hoàn nguyên), miễn là giá sau giao dịch nằm trong phạm vi Slippage (Trượt giá) của người dùng. Trình sắp xếp có thể tự do sắp xếp lại giao dịch này so với các giao dịch khác và trích xuất MEV (ví dụ: bằng cách kẹp giữa) miễn là việc thực hiện cuối cùng nằm trong giới hạn và thành công. Điều này mang lại sự tự tin cho việc thực hiện của người dùng mà không yêu cầu một thứ tự cụ thể hoặc trạng thái gốc.

Thể loại 3

Đảm bảo bao gồm, thực hiện thành công và trạng thái sau. Không đảm bảo về thứ tự.

Đây là sự đảm bảo mạnh nhất. Sự đảm bảo này cung cấp cho người giao dịch sự đảm bảo về việc bao gồm giao dịch và đột biến trạng thái sau. Mặc dù thứ tự có thể được suy ra một cách tự nhiên, nhưng nó không được thực thi nghiêm ngặt, vì trạng thái trước và sau của giao dịch có thể được xác minh độc lập. Điều này cho phép vị trí của giao dịch trong Block thay đổi mà không ảnh hưởng đến kết quả thực hiện của nó, miễn là ngữ cảnh trạng thái của nó vẫn bị cô lập.

Điều kiện Slashing sẽ giống hệt với loại 2 với việc bổ sung bằng chứng Máy ảo Ethereum (EVM) về trạng thái sau sẽ xác thực các đột biến trạng thái sau.

Ví dụ:

Hợp đồng ký quỹ hoặc thanh toán có điều kiện
Trong cầu nối chuỗi chéo hoặc kênh thanh toán, người dùng gửi giao dịch với kỳ vọng rằng giao dịch sẽ dẫn đến đột biến hậu trạng thái chính xác (ví dụ: balanceOf(user) += 1 ETH). Trình sắp xếp ký xác nhận trước không chỉ cam kết bao gồm và thực hiện thành công mà còn cam kết gốc hậu trạng thái cụ thể sẽ dẫn đến. Điều này cho phép xác nhận trước đóng vai trò là xác thực Ngoài chuỗi trong các giao thức bắc cầu hoặc cam kết có điều kiện, với các điều kiện Slashing mạnh nếu vi phạm.

:white_check_mark: = Đảm bảo |:x: = Không đảm bảo

Loại Bao gồm Đặt hàng Thực hiện thành công Bảo lãnh sau nhà nước Tính toán Slashing
0 :white_check_mark::x::x::x: TRÊN)
1 :white_check_mark::white_check_mark::x::x: 0(1)
2 :white_check_mark::x::white_check_mark::x: O(n) + O(m)
3 :white_check_mark::x::white_check_mark::white_check_mark: O(n) + O(m)

* O(m) ngụ ý thực hiện giao dịch

Chú thích về độ phức tạp của điều kiện Slashing :
Trong khi cách tiếp cận ngây thơ để xác minh các điều kiện Slashing (ví dụ, chứng minh không bao gồm hoặc trạng thái sau không chính xác) có thể yêu cầu các hoạt động O(n) hoặc O(m) trong Máy ảo Ethereum (EVM), thì các chi phí này có thể được giảm đáng kể thông qua các hệ thống Bằng chứng mật mã . Nếu rollup tận dụng SNARK (hoặc các bằng chứng ngắn gọn tương tự), thì toàn bộ quá trình xác minh Slashing —bất kể là kiểm tra bao gồm, thành công thực hiện hay tính hợp lệ sau trạng thái—có thể được nén thành chi phí xác minh theo thời gian không đổi on-chain, về cơ bản là giảm độ phức tạp tính toán xuống O(1).

Tại sao phải phân biệt giữa loại 2 và loại 3?
Loại 2 đảm bảo thực hiện thành công nhưng không đảm bảo hậu trạng thái. Điều này có nghĩa là trình sắp xếp có thể sắp xếp lại giao dịch trong Block, có khả năng thay đổi trạng thái trước và sau của nó, miễn là nó không hoàn nguyên. Tính linh hoạt này cho phép trích xuất MEV hoặc tối ưu hóa hàng loạt trong khi vẫn đảm bảo giao dịch "thành công".

Ngược lại, Thể loại 3 đảm bảo rõ ràng trạng thái sau , nghĩa là trình sắp xếp phải đảm bảo giao dịch dẫn đến một trạng thái chuyển đổi cụ thể. Việc sắp xếp lại chỉ được phép nếu trạng thái trước của giao dịch bị cô lập—tức là không bị ảnh hưởng bởi các giao dịch xung quanh. Nếu trạng thái trước không bị cô lập, thì việc sắp xếp trở nên cố định ngầm, vì bất kỳ thay đổi nào trong việc sắp xếp sẽ làm mất hiệu lực trạng thái sau dự kiến. Tuy nhiên, bản thân việc sắp xếp không phải là điều kiện Slashing —chỉ có sự không khớp trong trạng thái sau đã cam kết mới có thể cắt được.


Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
2
Thêm vào Yêu thích
1
Bình luận