Đồng tác giả là Conor McMenamin và Lin Oshitani , cả hai đều thuộc Nethermind Research .

Tóm tắt

Chúng tôi phác thảo một khuôn khổ để phân tích các giao thức tìm cách thực thi trao đổi công bằng kịp thời của các xác nhận trước. Trong khuôn khổ này, chúng tôi phác thảo rõ ràng các thiết kế giao thức trao đổi công bằng kịp thời chiếm ưu thế. Chúng tôi thảo luận về tính khả thi của các giao thức tối ưu này đối với các thiết kế L1 và L2 hiện có và áp dụng khuôn khổ của chúng tôi vào các giao thức xác nhận trước hiện có.

Lời cảm ơn và Tuyên bố miễn trừ trách nhiệm

Bài viết này đã nhận được tài trợ từ Quỹ PBS . Xin chân thành cảm ơn Davide Rezzoli , Ellie Davidson và Christian Matt vì những đánh giá hữu ích của họ. Mọi quan điểm được nêu ra đều là của tác giả và không nhất thiết đại diện cho Nethermind, PBSF hoặc người đánh giá.

Giới thiệu

Xác nhận trước (preconf) đã nổi lên như một chủ đề được quan tâm trong hệ sinh thái Ethereum như một con đường để cung cấp thời gian xác nhận nhanh hơn cho người dùng, giống với trải nghiệm người dùng gần như tức thời của Web2. Để preconf có hiệu lực, cần phải có động lực để những người đề xuất khối trả chi phí cơ hội để xác nhận trạng thái sớm hơn trong khe đề xuất của họ và trở thành người xác nhận trước . Điều này trái ngược với tình trạng hiện tại của việc xây dựng các khối ngay tại thời điểm kết thúc khe đề xuất. Động lực này sẽ ở dạng phí, trong đó người dùng chỉ định thời gian ưu tiên để cung cấp preconf và những người xác nhận trước chọn chấp nhận phí hay không để đổi lấy việc đáp ứng thời gian và sở thích thực hiện của người dùng.

Tài liệu này tập trung vào việc hiểu không gian thiết kế để đảm bảo preconf có thể được cung cấp kịp thời theo sở thích của người dùng. Chúng tôi định nghĩa preconf như sau:

Định nghĩa 1: Xác nhận trước

Xác nhận trước giao dịch là cam kết về việc đưa giao dịch vào hoặc thực hiện trước khi giao dịch được đưa vào khối L1 do người đề xuất L1 ký.

Nó cần có cơ hội được gửi đến L1. Đối với L1 preconf, điều này có thể có nghĩa là được xác nhận trước bằng:

• người đề xuất L1,
• một người được ủy quyền để xác nhận trước thay mặt cho người đề xuất L1,
• một người xây dựng có cơ hội thắng cuộc đấu giá quyền xây dựng một khối nhà do người đề xuất L1 đề xuất, ví dụ như mev-commit .

Thiết kế preconf L2 có thể được cung cấp bởi bất kỳ bên nào ở trên, đặc biệt là trong trường hợp rollup dựa trên và preconf dựa trên . Tuy nhiên, preconf L2 thường được cung cấp bởi một trình sắp xếp tập trung do quản trị của L2 chỉ định với quyền độc quyền đề xuất các khối L2 trên L1.

Bất kể ai có thể cung cấp preconf, người dùng cần một số đảm bảo rằng một thực thể có khả năng xác nhận trước một giao dịch một cách có ý nghĩa sẽ cung cấp preconf. Vì một số giao thức preconf/preconf nhất định dẫn đến ít doanh thu hơn cho người đề xuất được chỉ định so với việc chỉ xác nhận giao dịch , nên người dùng có thể sẽ cần khuyến khích người đề xuất xác nhận trước các giao dịch. Điều này đặc biệt đúng trong các giao thức mà người đề xuất không cần xin phép, không có nghĩa vụ cung cấp preconf. Các giải pháp đang được xem xét để khuyến khích người đề xuất xác nhận trước các giao dịch phụ thuộc vào việc trao đổi công bằng kịp thời các preconf. Phần còn lại của tài liệu này tập trung vào đặc tính này của trao đổi công bằng kịp thời; nó là gì, nó được thực thi như thế nào, khi nào nó được giữ nguyên và khi nào thì không.

Với tư cách là lợi ích độc lập, chúng tôi chứng minh cách thức trao đổi giao dịch công bằng có thể đạt được trong các thiết lập trò chơi lặp lại mà không cần bên thứ ba đáng tin cậy, một điều không thể đã biết trong các trò chơi một lần. Mặc dù các đảm bảo trao đổi công bằng được cung cấp trong khuôn khổ của chúng tôi dựa trên các ưu đãi, nhưng các ưu đãi này tỷ lệ thuận với chi phí cho thực thể xác nhận giao dịch khi phá vỡ trao đổi công bằng. Các chi phí này có thể cao tùy ý. Điều này trở nên rõ ràng khi thực thể cung cấp preconf đang chơi một trò chơi lặp lại với các khoản thanh toán dương nhất quán để cung cấp trao đổi công bằng và/hoặc một khoản thanh toán "ngày tận thế" tiêu cực cho việc đi chệch hướng. Các ưu đãi này tương ứng với việc thu phí để cung cấp trao đổi công bằng và nắm giữ lượng token lớn có giá trị gắn liền với sự tin tưởng vào blockchain cơ bản. Bất kỳ động cơ một lần nào để đi chệch hướng bị giới hạn bởi các chi phí này thì sẽ trở nên phi lý. Điều này phù hợp với các kết quả lý thuyết trò chơi nhưĐịnh lý Folk .

Tổ chức của bài viết

Chúng tôi bắt đầu bằng cách giới thiệu khái niệm trao đổi công bằng kịp thời, sau đó là giới thiệu một khuôn khổ để xem xét và so sánh các giải pháp trao đổi công bằng kịp thời. Khuôn khổ này mô tả các thành phần cần thiết cho bất kỳ giao thức trao đổi công bằng kịp thời nào, cũng như các thuộc tính chính và mong muốn của bất kỳ giao thức nào như vậy. Với khuôn khổ này trong tay, chúng tôi sử dụng nó để xác định các giải pháp tối ưu cho giao thức trao đổi công bằng kịp thời tùy thuộc vào các ràng buộc thiết kế của blockchain cơ bản. Sau đó, chúng tôi áp dụng khuôn khổ của mình cho cả các giao thức tiền cấu hình hiện tại và tương lai, bao gồm thảo luận về tính phù hợp chung của các cổng như một giải pháp tiền cấu hình L1.

Trao đổi công bằng kịp thời

Trong văn học truyền thống , tài sản trao đổi công bằng được định nghĩa như sau:

Định nghĩa 2: Trao đổi công bằng

Khi hai bên trao đổi các mục kỹ thuật số (ví dụ: hợp đồng điện tử, thanh toán hoặc chữ ký), cả hai bên đều nhận được các mục mong đợi hoặc không bên nào nhận được.

Tuy nhiên, như chúng ta đã thấy trong phần giới thiệu, đối với preconf, tính kịp thời của trao đổi là chìa khóa. Để nắm bắt trực giác này, chúng tôi giới thiệu một thuộc tính được gọi là trao đổi công bằng kịp thời , hay viết tắt là TFE:

Định nghĩa 3: Trao đổi công bằng kịp thời (TFE)

Khi hai bên trao đổi các mục kỹ thuật số (ví dụ: hợp đồng điện tử, thanh toán hoặc chữ ký), cả hai bên đều nhận được các mục mong đợi hoặc không bên nào nhận được. Hơn nữa, thông báo về trao đổi phải xảy ra trong một khoảng thời gian mục tiêu, mục tiêu, do một trong các bên chỉ định .

Các mục được trao đổi trong TFE là mẹo preconf, do người dùng cung cấp và bản thân preconf, do người xác nhận trước cung cấp. Hơn nữa, thời gian mục tiêu được người dùng chỉ định trong yêu cầu preconf.

Diễn viên TFE

Có ba tác nhân cần xem xét trong tất cả các giao thức tiền cấu hình TFE:

• Người dùng : Thực thể đang yêu cầu preconf kịp thời.

• Người xác nhận trước : Thực thể cung cấp preconf. Trong bài viết này, chúng tôi giả định rằng những người xác nhận trước là hợp lý, lựa chọn các hành động tối đa hóa tiện ích mong đợi của họ trong một khoảng thời gian nhất định. Hiệu quả của một hình phạt cụ thể phụ thuộc vào việc người xác nhận trước có phải là:

  • Xác nhận trước một lần : ẩn danh, không cần cấp phép và/hoặc chỉ xác nhận trước cho một số lượng nhỏ các khe xác nhận trước cố định.
  • Người xác nhận trước trò chơi lặp lại: người nổi tiếng, được cấp phép và/hoặc được mong đợi tham gia vào giao thức cho một số lượng lớn các vị trí tiền hội nghị/vô thời hạn.

  Mặc dù đây là các phân loại đa chiều, nhưng chúng chỉ dành cho mục đích chung. Trong các phân loại này, bộ xác thực Ethereum thường được mô tả là một lần, vì các trình xác thực hiện được bầu để dự kiến đề xuất 1 khối một lần sau mỗi 140 ngày trong khi thời gian chờ hiện tại để tham gia hoặc thoát khỏi bộ xác thực là dưới 1 ngày . Mẫu cho các trình xác nhận trước trò chơi lặp lại là các trình sắp xếp tập trung trên L2, trong khi các cổng được ủy quyền trên L1 có khả năng là trò chơi lặp lại, mặc dù các chi tiết về thiết kế cổng vẫn đang được hình thành.

• Overseer : Thực thể (hoặc các thực thể) giám sát TFE bằng một số hành động có thể buộc hoặc khuyến khích preconfirmer cung cấp TFE. Trong phạm vi phân loại “overseer”, có nhiều thiết kế giám sát khả thi. Overseer—cho dù là một thực thể đơn lẻ hay một nhóm—có thể được triển khai theo hai cách: chính thức, với chỉ định rõ ràng trong giao thức, hoặc không chính thức, không có chỉ định rõ ràng, như mô tả bên dưới.

  • Chính thức :
    • Quyết định tại rollup genesis.
    • Được bầu bởi chính quyền.
    • Được bầu thông qua yêu cầu nắm giữ mã thông báo, ví dụ như Proof-of-Stake, để phù hợp với một hoặc cả hai:
      • giao thức preconf.
      • giao thức đồng thuận cơ bản.
    • Một trình giám sát ngầm thông qua một số hình thức cắt liên chủ thể, trong đó các trình xác thực của giao thức đồng thuận cơ bản có thể phối hợp để cắt một trình xác nhận trước độc hại. Xem tại đây , tại đây và tại đây để biết thêm chi tiết về cắt liên chủ thể. Loại giải pháp này thực sự chỉ cần thiết cho TFE tiền cấu hình L1 dựa trên trình giám sát. Vì tính phù hợp của việc phối hợp các trình xác thực L1 để cắt là một cuộc tranh luận mang tính triết học hơn là một cuộc tranh luận mang tính kỹ thuật, chúng tôi sẽ bỏ qua phần thảo luận thêm về kỹ thuật này trong bài viết này.
  • Không chính thức : Người giám sát không được chỉ định rõ ràng trong giao thức. Ví dụ, họ là:
    • Người dùng, cụ thể là ví hoặc nút đầy đủ L2 hoạt động thay mặt người dùng, theo dõi những người xác nhận trước và/hoặc truyền bá thông điệp đến những người dùng khác khi nghi ngờ TFE ( giám sát người dùng ) .

Lý do cần có người giám sát xuất phát từ kết quả bất khả thi theo truyền thống cho rằng TFE giữa những người xác nhận trước không tin cậy và người dùng không thể được đảm bảo nếu không có người giám sát để hòa giải tranh chấp. Với sự bất khả thi này, bất kỳ giải pháp TFE nào được giới thiệu trong tài liệu này sẽ tận dụng:

1. Một người giám sát đáng tin cậy. Chúng tôi gọi những giải pháp như vậy là thỏa mãn TFE đáng tin cậy.
2. Người giám sát không đáng tin cậy nhưng hợp lý về mặt kinh tế. Chúng tôi gọi các giải pháp như vậy là thỏa mãn TFE kinh tế.

Những đặc tính này của TFE đáng tin cậy hoặc kinh tế không nói lên điều gì về mức độ mà người giám sát có thể ảnh hưởng đến kiểm duyệt và tính sống động của giao thức đồng thuận cơ bản, hoặc động cơ chính xác của người xác nhận trước hợp lý để hành xử trung thực. Phân loại chính xác của những đặc tính này được giải thích trên cơ sở từng giao thức và được tóm tắt trong phần tiếp theo.

Tại sao một người xác nhận trước hợp lý lại đi chệch khỏi TFE trong các giao thức TFE kinh tế?

Động lực để một người xác nhận trước đi chệch khỏi TFE xuất phát từ sự thay đổi về giá trị của các giao dịch cơ bản hoặc quyền truy cập trạng thái được xác nhận trước theo thời gian. Cụ thể, một số loại MEV như chênh lệch giá CEX-DEX đã được chứng minh là tăng theo kỳ vọng theo thời gian. Hơn thế nữa, khi quy mô của mempool tăng lên, thì sự kết hợp của các lệnh giao dịch cũng tăng theo, đây cũng là nguồn giá trị cho những người đề xuất và người xác nhận trước với khả năng trì hoãn việc xác nhận giao dịch cho đến thời điểm cuối cùng có thể.

Tính chất của dung dịch TFE

Hai đặc tính chính quyết định hiệu quả của giải pháp TFE:

• Hình phạt : Giả định về độ tin cậy hoặc cơ chế kinh tế nào đảm bảo TFE đạt được như mong đợi của người dùng?
• Sự phụ thuộc vào người giám sát : Người giám sát đưa ra những giả định hoặc rủi ro tin cậy bổ sung nào liên quan đến kiểm duyệt và sự phụ thuộc?

Hình phạt

Tất cả các hình phạt TFE đều được kích hoạt bởi vi phạm TFE, với các vi phạm tương ứng với việc preconfirmer vi phạm phạm vi thời gian mục tiêu của yêu cầu preconf. Sức mạnh có thể có của bảo đảm TFE gần như tương ứng trực tiếp với sức mạnh của hình phạt, mà chúng tôi phác thảo theo thứ tự sức mạnh gần đúng (từ mạnh nhất đến yếu nhất) bên dưới.

1. Hình phạt thời gian thực Một giám sát viên được cấp phép xử lý tất cả các yêu cầu preconf và thực thi rằng các preconf tương ứng với mỗi yêu cầu thỏa mãn TFE. Điều này có thể được thực hiện theo các bước sau:
   1. Một preconf chỉ có giá trị khi và chỉ khi người giám sát ký vào preconf đó.
   2. Người giám sát phải chuyển tiếp yêu cầu đến người xác nhận trước.
   3. Mẹo trước khi họp chỉ có giá trị khi và chỉ khi người giám sát ký vào biên bản họp trước.
2. Hình phạt sau khi phạm tội:
   1. Slashing: Người xác nhận trước mất một số tiền được xác định trước được quy định bởi giao thức preconf. Mặc dù vi phạm ngụ ý rằng một hoặc nhiều yêu cầu không được TFEd, người dùng được bảo vệ gián tiếp của TFE vì người xác nhận trước hợp lý sẽ tránh rủi ro cho tài sản thế chấp được đặt cược của họ bằng cách vi phạm TFE. Yêu cầu một người giám sát được cấp phép để làm trung gian cho các vi phạm TFE.
   2. Danh sách đen: Người xác nhận trước bị đưa vào danh sách đen khỏi preconfing trong một khoảng thời gian xác định. Yêu cầu người giám sát được cấp phép để cập nhật danh sách đen.
   3. Mất luồng lệnh ngắn hạn: Nếu preconfirmer vi phạm TFE, preconfirmer sẽ mất luồng lệnh preconf từ người dùng trong thời gian còn lại của khe preconf hiện tại (có thể kéo dài qua nhiều khe đồng thuận Ethereum). Mất luồng lệnh này có thể được kích hoạt bởi giám sát người dùng hoặc một số giám sát viên được cấp phép.
   4. Mất luồng lệnh dài hạn: Nếu preconfirmer vi phạm TFE, preconfirmer sẽ mất luồng lệnh preconf cho tất cả các khe preconf trong tương lai. Một lần nữa, mất luồng lệnh này có thể được kích hoạt bởi giám sát người dùng hoặc một số giám sát viên được cấp phép.

Chúng tôi đã ra lệnh cho các Hình phạt TFE sau này theo cách mà bất kỳ giao thức nào triển khai hình phạt 2.x 2. x cũng có thể triển khai 2.(x+1) 2. ( x + 1 ) , \forall x \in \{a,b,c\} ∀ x ∈ { a , b , c } , với các thay đổi giao thức bổ sung tối thiểu, ví dụ bất kỳ giao thức nào có các thực thể được cấp phép có khả năng b b ., đưa một người xác nhận trước vào danh sách đen, có thể sử dụng các thực thể được cấp phép đó để báo hiệu cho người dùng và ví ngừng gửi c c ., lệnh ngắn hạn và d d . dài hạn cho người xác nhận trước vi phạm.

Sự phụ thuộc của sự sống vào người giám sát

Thuộc tính này của TFE nhằm mục đích xác định mức độ phơi nhiễm mà giao thức preconf và giao thức blockchain cơ bản có trên Overseer. Mặc dù mối đe dọa tác động đến tính sống có thể được sử dụng để ngăn chặn hành vi sai trái của preconfirmer, nhưng nó cũng có thể thay đổi các thuộc tính kiểm duyệt và tính sống của chuỗi mà preconf đang được cung cấp.

Một TFE đặt Overseer vào đường dẫn phụ thuộc quan trọng để duy trì hoạt động sẽ coi một giao thức TFE là không phù hợp để triển khai trên một giao thức có yêu cầu nghiêm ngặt về duy trì hoạt động.

hình ảnh 1171×361 82 KB

Để đơn giản, trong tài liệu này, chúng tôi tránh việc xác định mức độ phụ thuộc vào sự sống trong tương lai vượt quá “sự phụ thuộc vào sự sống” hoặc “không phụ thuộc vào sự sống”.

Một khuôn khổ để so sánh các giải pháp TFE

Với các thuộc tính và phân loại của phần trước trong tay, giờ đây chúng ta đã có thể so sánh các giao thức preconf dựa trên sức mạnh trừng phạt và loại preconfirmer của chúng. Tóm tắt lại các thành phần mà chúng tôi đã phác thảo, các giải pháp TFE phải xác định các thành phần sau. Phần tô đậm thể hiện cách triển khai lý tưởng của từng thành phần, tất cả các thành phần khác đều như nhau:

1. Định nghĩa của người giám sát :
   1. Người giám sát có trang trọng không?
      • Không: Không cần phải quản lý và trợ cấp cho người giám sát.
      • Có: Cần có sự quản lý và/hoặc trợ cấp để lựa chọn và giám sát người giám sát.
   2. (Đối với các triển khai cụ thể) Người giám sát có thể xác định và báo cáo lỗi TFE như thế nào?
2. Thực thi & Hình phạt : Những hình phạt nào được áp dụng đối với những người vi phạm TFE? Chúng tôi đã phân loại các hình phạt này như sau:
   1. Thực thi thời gian thực
   2. chém
   3. Danh sách đen
   4. Mất dòng lệnh ngắn hạn
   5. Mất dòng lệnh dài hạn

Đối với mỗi giải pháp TFE, chúng tôi chủ yếu quan tâm đến hai thuộc tính. Phần tô đậm thể hiện sự thỏa mãn lý tưởng của từng thuộc tính, tất cả các yếu tố khác đều như nhau:

1. Hiệu quả của hình phạt: Hình phạt có được kỳ vọng là có hiệu quả trong việc đảm bảo TFE không? Chúng tôi cố gắng giữ sự thỏa mãn của thuộc tính này như một biến bậc ba:
   1. Cao: hình phạt rất hiệu quả.
   2. Trung bình: hình phạt có thể được tham số hóa để có hiệu quả Cao hoặc Thấp và các chi tiết thực hiện chính xác sẽ rất quan trọng.
   3. Thấp: hình phạt không có hiệu quả.
2. Sự phụ thuộc của tính sống động vào người giám sát: Người giám sát có thể ảnh hưởng đến khả năng chống kiểm duyệt và tính sống động của blockchain cơ bản không?
   • Không: Lý tưởng nhất là không nên phụ thuộc vào người giám sát về độ sống động.
   • Có: Có sự phụ thuộc, điều này không được mong muốn.

Trước khi xác định các giao thức cụ thể, chúng tôi hiện cung cấp hiểu biết cấp cao về cách mỗi cơ chế thực thi TFE hoạt động khi có One-Shot và Repeated-Game Preconfirmers. Để thực hiện điều này, đối với mỗi sự kết hợp của loại người đề xuất và cơ chế thực thi, chúng tôi chỉ định một bộ ba mô tả:

( 1. Sự sống phụ thuộc vào người giám sát,
2. Cần có một người giám sát chính thức
3. Hiệu quả của hình phạt

Bảng 1: Phân tích các kết hợp của loại người đề xuất và cơ chế thực thi. Các mục in đậm chỉ ra mức độ thỏa mãn mong muốn chung của từng tài sản, tức là:
1. Không phụ thuộc vào người giám sát.
2. Không yêu cầu giám sát chính thức.
3. Hiệu quả thực thi và trừng phạt cao.

* phụ thuộc vào giá trị mong đợi của luồng lệnh còn lại trong khe preconf.
** tùy thuộc vào số lượng gạch chéo.

Giải pháp TFE tối ưu trong khuôn khổ của chúng tôi

Nếu chúng ta chỉ tập trung vào các mục nhập tuple được in đậm, thì có một lớp chung của giải pháp TFE có thể triển khai ngày nay đáp ứng tối ưu tất cả các thuộc tính. Đây là “ các tiền xác nhận trò chơi lặp lại với tổn thất dòng lệnh ngắn hạn và dài hạn ” trong Bảng 1.

Đối với L2, các trình tự tập trung được bầu bởi quản trị L2 là ứng cử viên lý tưởng cho việc này. Trên L1, việc giới thiệu một trình xác nhận trước trò chơi lặp lại khi có một bộ xác thực phi tập trung hoạt động như người đề xuất không phải là điều hiển nhiên. Chúng tôi hoãn thảo luận về các cổng, một triển khai tiềm năng của các trình xác nhận trước trò chơi lặp lại trên L1, sang phần thảo luận.

hình ảnh 692×399 56.1 KB

Tập trung vào L2, một trình tự tập trung được bầu bởi quản trị L2 được "căn chỉnh tối đa" theo cùng cách mà chúng ta hình dung một giám sát viên được bầu bởi quản trị sẽ như thế nào. Chúng ta có thể rất tự tin rằng một trình tự tập trung sẽ không vi phạm TFE vì, khi có sự giám sát của người dùng, việc làm như vậy có nguy cơ khiến người dùng rời đi và làm mất giá trị của các token quản trị/trình tự: mất mát dòng lệnh dài hạn tối đa trong khuôn khổ của chúng ta.

Tuy nhiên, các trình tự tập trung tạo ra một điểm lỗi duy nhất dọc theo đường dẫn quan trọng cho kiểm duyệt và tính sống động trong thời gian ngắn. Mặc dù chế độ lỗi này có thể chấp nhận được trong khuôn khổ TFE, nhưng người dùng trình tự tập trung L2 phải dùng đến hộp thư đến bị trì hoãn để giải trình tự, có khả năng dẫn đến sự chậm trễ 24 giờ hoặc hơn, tùy thuộc vào thiết kế hộp thư đến bị trì hoãn của bản tóm tắt.

Vậy thì giải pháp tối ưu trong môi trường không có máy giải trình tự tập trung là gì?

Giải pháp TFE tối ưu cho xác nhận trước mà không cần máy giải trình tự tập trung

Bây giờ chúng tôi phác thảo các môi trường chính mà preconf sẽ được sử dụng bên ngoài các thiết lập trình tự tập trung và các giải pháp TFE phù hợp/hiệu quả nhất cho từng môi trường.

Xác nhận trước L2 với Bộ đề xuất L2 phi tập trung

Thiết lập này bao gồm các giao thức L2 như Taiko và Surge .

Khuyến nghị: Người giám sát chính thức có khả năng cắt. Điều này tương ứng với trường hợp “ người xác nhận trước một lần có khả năng cắt ” trong Bảng 1.

Tại sao?: Cơ chế thực thi có hiệu quả cao, không phụ thuộc vào người giám sát, người giám sát có thể được lựa chọn thông qua quản trị tổng hợp để phù hợp tối đa với thành công lâu dài của L2.

hình ảnh 692×527 73,4 KB

Chúng ta hãy cùng xem xét các thành phần:

• Người giám sát:
  • Ai: Người giám sát có thể là một TTP duy nhất, nhiều TTP, người xác nhận trước đã chọn, AVS độc lập hoặc người xác thực đã chọn. Người giám sát được khuyến nghị để được quản lý bởi quản trị rollup, vì rollup là người được khuyến khích cung cấp UX tốt để đổi lấy tổn thất doanh thu ngắn hạn.
  • Cơ chế phát hiện lỗi: Người giám sát sẽ đưa ra sự đồng thuận về việc phát hành bản preconf kịp thời.
• Thực thi và trừng phạt :
  • Nếu việc phát hành kịp thời không diễn ra, thì sự đồng thuận của ủy ban có thể được gửi đến ví như một tín hiệu cảnh báo hoặc được đăng lên L1 để:
    • Đưa người xác nhận trước vào danh sách đen.
    • Cắt bỏ người xác nhận trước.

Của cải:

• Sức mạnh của sự bảo đảm
  • Với tư cách là người dùng, bất kỳ yêu cầu preconf nào bạn gửi đi chỉ có bảo đảm kinh tế về preconf của TFE. Tuy nhiên, miễn là ủy ban giám sát trung thực, người xác nhận trước sẽ được khuyến khích duy trì TFE để tránh cắt giảm.
• Sự phụ thuộc của sự sống vào người giám sát
  • Không, vì việc cắt giảm chỉ có hiệu lực hồi tố.

Xác nhận trước L1

Không giống như trường hợp của L2 preconf, không có giao thức được khuyến nghị rõ ràng nào cho L1 preconf vì mỗi giao thức mang lại những sự đánh đổi khác nhau. Do đó, chúng tôi đưa ra hai khuyến nghị dựa trên các yêu cầu sau

1. Khuyến nghị “theo hướng nhanh” : Chúng tôi muốn kích hoạt và tạo động lực cho các cuộc họp trước L1 ngay lập tức, mặc dù phải đưa vào một người giám sát chính thức không được bầu theo giao thức cơ bản.
2. Khuyến nghị “chậm mà chắc” : Thay vì đưa một giám sát viên chính thức vào đường ống xây dựng khối L1, chúng tôi đợi cho đến khi nghiên cứu về ủy quyền cổng và/hoặc tách biệt người chứng thực-người đề xuất hoàn thiện. Vào thời điểm đó, “lan can bảo vệ” (được thảo luận trong Phụ lục) có thể được triển khai để ngăn chặn độc quyền và sự kết hợp giữa giám sát người dùng và danh tiếng của người xác nhận trước có thể đóng vai trò là giải pháp TFE.

Khuyến nghị “theo đường nhanh”: Sử dụng một hoặc nhiều giao thức giám sát bên ngoài để thực thi cắt giảm đối với các vi phạm TFE. Mô tả về giao thức này giống hệt với giao thức được mô tả trong phần trước: Xác nhận trước L2 với Bộ đề xuất L2 phi tập trung , mặc dù có thiết kế ít rõ ràng hơn đối với giám sát viên chính thức.

Tại sao?: Cơ chế thực thi có hiệu quả cao và không phụ thuộc vào người giám sát.

Tại sao không?: Câu hỏi mở liên quan đến việc thực hiện giám sát chính thức trên L1.

hình ảnh 692×527 78,7 KB

Khuyến nghị “chậm nhưng chắc chắn”: Sử dụng một số hình thức giám sát người dùng TFE không chính thức để xác định và báo hiệu các hành vi vi phạm TFE cho cộng đồng rộng lớn hơn.

Tại sao?: Không phụ thuộc vào người giám sát, cũng như không yêu cầu phải có người giám sát chính thức.

Tại sao không?: Cơ chế thực thi kém hiệu quả nếu không có người xác nhận trước trong trò chơi.

hình ảnh 692×399 56.1 KB

Chúng ta hãy cùng xem xét các thành phần:

• Người giám sát:
  • Ai: Người dùng cuối của giao thức preconf.
  • Cơ chế phát hiện lỗi: Giám sát cục bộ các bản phát hành kịp thời của preconf. Trên thực tế, việc giám sát sẽ được thực hiện bởi ví của họ hoặc các nút đầy đủ mà họ kết nối.
• Thực thi và trừng phạt :
  • Dừng gửi luồng lệnh của người dùng đến người xác nhận trước nếu phát hiện vi phạm TFE.
  • Làm tổn hại danh tiếng của người xác nhận trước vì luồng lệnh không được xác nhận trước.

Của cải:

• Sức mạnh của sự bảo đảm
  • Với tư cách là người dùng, yêu cầu preconf bạn gửi sẽ không có bảo đảm TFE. Tuy nhiên, mối đe dọa của cơ chế trừng phạt như đã nêu ở trên cung cấp một số bảo đảm kinh tế rằng preconfirmer duy trì TFE. Orderflow có giá trị càng cao mà preconfirmer mất thông qua cơ chế thực thi, thì bảo đảm TFE càng mạnh. Bảo đảm TFE thông qua giám sát người dùng mạnh hơn khi preconfirmer có uy tín, có khả năng được bầu lại, cũng như khi các yêu cầu ở giai đoạn đầu trong khe, vì tất cả những điều này đều đòi hỏi chi phí cơ hội cao hơn để phá vỡ TFE so với các phương án thay thế; không có uy tín, không có khả năng được bầu lại để preconfirmer, ít hoặc không có orderflow còn lại trong khe preconfirmer.
• Sự phụ thuộc của sự sống vào người giám sát
  • Không có.

Áp dụng khuôn khổ của chúng tôi vào các giao thức hiện có

Chúng tôi phác thảo một số giao thức preconf nổi tiếng nhất đang được sử dụng/đề xuất sử dụng hiện nay và cách các giao thức này phù hợp với khuôn khổ TFE của chúng tôi.

Mev-cam kết

Mev-commit được mô tả như sau.

hình ảnh 818×338 83,5 KB

Chúng ta hãy cùng xem xét các thành phần:

• Người giám sát:
  • Ai: Trong mev-commit, người giám sát là chuỗi/ủy ban chịu trách nhiệm đạt được sự đồng thuận về việc đáp ứng các yêu cầu preconf . Ban đầu, các thành viên ủy ban là những người xác thực được liệt kê trắng đang chạy sự đồng thuận bằng chứng thẩm quyền, nhưng có kế hoạch bao gồm bất kỳ người xác thực nào được đặt lại và chọn tham gia .
  • Cơ chế phát hiện lỗi: Ủy ban sẽ thống nhất về việc có phát hành bản preconf đúng hạn hay không.
• Hình phạt :
  • Các mẹo preconf sẽ giảm chất lượng tùy thuộc vào thời điểm cung cấp preconf muộn.
  • Nếu TFE bị vi phạm, ví dụ như một người xác nhận trước từ chối một thỏa thuận trước, thì những người xác nhận trước có thể bị cắt bỏ .

Của cải:

• Sức mạnh của sự bảo đảm
  • Hiện tại, số tiền cắt giảm cho việc vi phạm các điều kiện yêu cầu preconf trong mev-commit là thấp, gần bằng với tiền boa được trả. Trong khuôn khổ của chúng tôi, số tiền cắt giảm này tương đương với tổn thất dòng lệnh ngắn hạn hơn là số tiền cắt giảm gây mất động lực, ví dụ >1 ETH. Mặc dù có kế hoạch triển khai số tiền cắt giảm cao tùy ý , nhưng thiết kế như vậy vẫn chưa được triển khai.
• Sự phụ thuộc của sự sống vào người giám sát
  • Sự phụ thuộc vào độ sống trước khi cấu hình: Có. Nếu ủy ban giám sát có vấn đề về độ sống hoặc bắt đầu kiểm duyệt, thì không thể giải quyết được các cấu hình trước.
  • Phụ thuộc vào tính hoạt động của giao dịch chung: Không. Người xác nhận trước không có nghĩa vụ phải sử dụng mev-commit và có thể lấy nguồn giao dịch bình thường từ bên ngoài mev-commit.

Cà phê espresso

Espresso không nhất thiết phải được xây dựng để xử lý TFE, mặc dù nó có thể dễ dàng được điều chỉnh để cho phép TFE. Bây giờ chúng tôi mô tả kiến trúc Espresso và cách nó có thể xử lý TFE.

hình ảnh 818×338 83,5 KB

Chúng ta hãy cùng tìm hiểu các thành phần của Espresso:

• Người giám sát:
  • Ai: Người giám sát là một ủy ban gồm những người xác thực đã được chọn tham gia.
  • Cơ chế phát hiện lỗi: Ủy ban sẽ đưa ra sự đồng thuận và sự đồng thuận này sẽ quyết định xem bản preconf có được phát hành đúng hạn hay không.
• Thực thi và trừng phạt :
  • Nếu TFE bị vi phạm, thì giao dịch L2 không thể được đưa vào khối L2 vì chứng chỉ đủ điều kiện biểu quyết từ ủy ban giám sát là yêu cầu bắt buộc để khối L2 có hiệu lực.

Của cải:

• Sức mạnh của sự bảo đảm
  • Chỉ cần phần lớn ủy ban trung thực thì người dùng có thể yên tâm rằng các giao dịch sẽ không được thực hiện trừ khi có bản phát hành trước thời hạn tương ứng.
• Sự phụ thuộc của sự sống vào người giám sát
  • Phụ thuộc vào độ sống trước khi cấu hình: Có.
  • Phụ thuộc chung về tính sống động của giao dịch: Espresso có hai thiết kế khả thi cho các rollup lựa chọn tham gia vào các preconf của Espresso. Các thiết kế này có hoặc không có lối thoát trong trường hợp lỗi tính sống động (quá nhiều thời gian đã trôi qua kể từ khi khối rollup được gửi đến L1).
    • Nếu không có lối thoát, các giao dịch chung sẽ phụ thuộc vào ủy ban giám sát.
    • Với cửa thoát hiểm , tính sống động cuối cùng của các giao dịch được duy trì. Tuy nhiên, tính sống động ngắn hạn (tính sống động trước thời hạn cửa thoát hiểm) và khả năng chống kiểm duyệt phụ thuộc vào ủy ban giám sát.

Thiết kế cổng L1

Gateway được kỳ vọng là các thực thể tinh vi, có uy tín mà những người đề xuất L1 có thể chọn thuê ngoài. Gateway gần như chắc chắn được phân loại là các tiền xác nhận trò chơi lặp lại do khoản đầu tư cần thiết để trở thành các thực thể tinh vi, tiên tiến về mặt công nghệ và có uy tín. Mặc dù về mặt lý thuyết, điều này có vẻ giống với các trình tự tập trung trên L2, nhưng việc thiếu cơ chế bao gồm bắt buộc hiện tại khi đối mặt với một gateway hoạt động không tốt khiến cơ chế thực thi về cơ bản trở nên khác biệt. Điều này đặc biệt rõ ràng đối với việc thực thi TFE và hiệu quả thực thi tương ứng.

Nếu giám sát người dùng được sử dụng để giám sát TFE từ một cổng, người dùng hiện tại sẽ không có cơ chế thay thế nào để gửi giao dịch đến L1 khi cổng hoạt động không bình thường. Vấn đề này trở nên nghiêm trọng khi cổng độc quyền, đây là một khả năng riêng biệt do bản chất tập trung của vai trò (được mô tả trong Phụ lục).

Với điều này trong tâm trí, có vẻ như đối với TFE cổng, hoặc bất kỳ yêu cầu chủ quan nào từ cổng được thực thi, thì cần có một người giám sát chính thức. Các dịch vụ được xác thực tích cực (AVS) là những ứng cử viên khả thi để triển khai một người giám sát như vậy. Tuy nhiên, một người giám sát chính thức có khả năng cắt giảm chủ quan những người xác nhận trước L1 (bao gồm cả người đề xuất) là một lĩnh vực thiết kế gây tranh cãi . Mức độ mà một người giám sát chính thức nên được phép cắt giảm chủ quan những người xác nhận trước L1 vẫn chưa rõ ràng và nằm ngoài phạm vi của công việc này. Hơn nữa, chúng tôi tin rằng một con đường khả thi hơn để đạt được các đảm bảo người xác nhận trước trò chơi lặp lại trên L1 là thông qua việc áp dụng một số hình thức Phân tách Người xác nhận-Người đề xuất , một lĩnh vực nghiên cứu mở khác.

Phần kết luận

Không gian thiết kế cho các giải pháp TFE luôn phát triển, theo cách tương tự như không gian L1 và L2 luôn phát triển. Bài viết này thiết lập một khuôn khổ để hiểu, đánh giá và so sánh các giải pháp TFE. Một trong những điểm cốt lõi rút ra từ khuôn khổ này là nhu cầu của bất kỳ giải pháp TFE nào để chỉ định người giám sát, cách người giám sát thực thi TFE và cách người giám sát có thể ảnh hưởng đến kiểm duyệt và tính sống động của các giao dịch trên blockchain cơ bản.

Đối với các rollup, chúng tôi đề xuất các giải pháp TFE sử dụng các giám sát viên “có trách nhiệm” có nhiều thứ để đạt được hoặc mất tùy thuộc vào sự thành công của (hoặc sự rời khỏi) rollup của họ. Các giám sát viên như vậy được đặt ở vị trí hoàn hảo để xử lý bản chất chủ quan của việc trao đổi công bằng kịp thời các preconf.

Đối với L1, không có giải pháp TFE nào rõ ràng là vượt trội hơn để đề xuất. Trong thiết kế L1 hiện tại với các trình xác thực không cần cấp phép đóng vai trò là người đề xuất, có thể cần phải có sự giám sát chính thức. Ai sẽ nổi lên như một người giám sát chính thức đáng tin cậy và khả năng trừng phạt của họ nên lớn đến mức nào vẫn chưa rõ ràng. Đề xuất chính của chúng tôi liên quan đến các preconf L1 và TFE là triển khai các rào cản cần thiết để bảo vệ sự kiểm duyệt và tính sống động của L1 trước sự xuất hiện của những người đề xuất và cổng thông tin thống trị.

Phụ lục

Thảo luận về Cổng mở rộng

Theo thiết kế L1 hiện tại của những người đề xuất được bầu chọn ngẫu nhiên từ bộ xác thực, việc lựa chọn cổng của những người đề xuất này chắc chắn sẽ giống như một "thị trường cổng", nơi các cổng cạnh tranh về số tiền doanh thu dự kiến mà họ có thể hứa với những người đề xuất; về cơ bản là một cuộc đấu giá trước thời hạn.

Cạnh tranh về doanh thu của người đề xuất phụ thuộc vào cả sự tinh vi của cổng (khả năng xây dựng khối & trích xuất MEV, khả năng chịu rủi ro, kết nối, cơ sở hạ tầng nói chung) và danh tiếng để đảm bảo người dùng gửi luồng lệnh của họ đến cổng. Sau khi được bầu, một cổng sẽ có quyền truy cập độc quyền để cung cấp preconf thực thi. Điều này tạo ra một bánh đà tự duy trì của:

uy tín → luồng lệnh → giá trị khối → lợi nhuận → xác suất bầu cử → uy tín…

Đây là một hệ thống tập trung:

1. Bản chất trước thời hạn của cuộc đấu giá có nghĩa là các cổng thanh toán sẽ cạnh tranh về doanh thu trung bình của người đề xuất trong thời gian dài .
   a. Trong bất kỳ khoảng thời gian nào, chỉ có thể có một cổng có doanh thu đề xuất trung bình cao nhất. Mặc dù cổng có doanh thu đề xuất dự kiến cao nhất để xác nhận trước một vị trí có thể thay đổi cuối cùng, nhưng điều này sẽ không thay đổi trong các khung thời gian ngắn và trung bình (tháng đến năm), do thời gian mà các đối thủ cạnh tranh có thể mất để đạt được ưu thế về công nghệ. Điều này đã được thấy nhiều lần trong các thị trường giao dịch tần suất cao hiện đại (được thảo luận tại đây , tại đây và tại đây ), nơi tốc độ và chất lượng thực hiện có thể so sánh được, nếu không liên quan trực tiếp đến các yêu cầu của cổng.

   b. Trừ khi các cổng nhỏ hơn có thể thuyết phục người dùng dành riêng luồng lệnh của họ cho họ—ngay cả khi điều đó có nghĩa là thực hiện chậm trễ—hoặc thuyết phục người xác thực ủy quyền cho họ mặc dù mang lại doanh thu thấp hơn, thì bất kỳ thị trường cổng nào cuối cùng cũng sẽ trở thành thị trường kẻ thắng sẽ giành tất cả.

2. Những người mới tham gia cần phải đầu tư đáng kể vào công nghệ để cạnh tranh với một cổng thông tin thống trị. Điều này tạo ra một cuộc chạy đua vũ trang công nghệ mà chỉ một số ít cá nhân có nguồn lực cao mới có thể tham gia.

Trong mô hình người chiến thắng sẽ giành được tất cả này, các giải pháp cổng L1 giống nhất với phân loại L2 của trình sắp xếp tập trung. Những người đề xuất L1 có lý trí riêng lẻ sẽ chọn cổng trả tiền cao nhất. Điều này để lại một thực thể duy nhất sắp xếp toàn bộ L1, tạo ra sự phụ thuộc rõ ràng vào kiểm duyệt và tính sống động. Cổng có lợi nhuận cao nhất có thể tùy ý chọn kiểm duyệt các cá nhân hoặc thậm chí ngừng tạo khối, ví dụ như trong quá trình bảo trì. Miễn là cổng chiếm ưu thế vẫn có lợi nhuận cao hơn đối thủ cạnh tranh gần nhất, người dùng buộc phải gửi giao dịch đến cổng hoặc được sắp xếp trong tình trạng tệ hơn đáng kể (ví dụ: chờ người đề xuất tiếp theo không chọn tham gia cổng).

Bảo vệ chống lại việc độc quyền các Cổng (giả sử các Cổng được thông qua)

Có những rào cản có thể được đưa ra để hạn chế những hậu quả tiêu cực của bản chất kẻ thắng sẽ được tất cả của trò chơi, một số trong số đó được chúng tôi liệt kê dưới đây:

1. Danh sách bao gồm: Danh sách bao gồm sẽ hạn chế đáng kể quyền kiểm duyệt và ảnh hưởng đến tính sống động của một cổng thông tin chi phối. Ngay cả khi vậy, TFE sẽ chỉ có thể thực thi được bằng một số cách để trừng phạt rõ ràng cổng thông tin (thông qua một người giám sát chính thức, xem điểm tiếp theo) hoặc giảm luồng lệnh của cổng thông tin. Với một cổng thông tin chi phối, việc giảm luồng lệnh sẽ có nghĩa là di chuyển sang một hệ sinh thái blockchain khác.
2. Giám sát viên chính thức: Với sự xuất hiện của một cổng thông tin thống trị, việc giám sát người dùng tự nó có thể không đủ mạnh để thực thi các vi phạm TFE, do hiện tại không có cách thay thế nào để gửi giao dịch đến L1. Một giám sát viên chính thức có khả năng đưa các cổng thông tin vào danh sách đen hoặc cắt bỏ có thể là một biện pháp bảo vệ có thể chấp nhận được. Tuy nhiên, như đã đề cập trước đó trong bài viết, vẫn chưa rõ giám sát viên chính thức sẽ được chọn như thế nào làm cơ chế để quản lý trình tự L1. Sự đa dạng của các giám sát viên L1/giám sát viên L1 theo tầng, mỗi giám sát viên có khả năng cắt bỏ riêng, có thể là một lĩnh vực nghiên cứu thú vị về vấn đề này.
3. Tăng tốc tách biệt Attestor-Proposer: Mặc dù không phải là một rào chắn trực tiếp, tách biệt attestor proposaler là một triển khai trong giao thức của việc ủy quyền cổng ngoài giao thức mà các cổng sẽ phụ thuộc vào. Bất kỳ giải pháp trong giao thức nào cũng sẽ cô lập bộ attestor phi tập trung khỏi bản chất tối đa hóa lợi nhuận của việc đề xuất. Bất kỳ cơ chế bầu cử người đề xuất nào trong tương lai này đều cần phải có các rào chắn trong giao thức để xử lý một người đề xuất thống trị mới nổi.

Tóm lại, các giải pháp cổng L1 có vẻ có thể chấp nhận được trong ngắn hạn. Tuy nhiên, nếu không có biện pháp bảo vệ rõ ràng để chống lại việc cổng độc quyền sắp xếp theo trình tự L1, các giải pháp tiền cấu hình cổng nên được áp dụng một cách thận trọng.