EIP sắp tới ảnh hưởng đến việc xác nhận trước như thế nào

Bởi Aikaterini-Panagiota Stouka và Conor McMenamin , cả hai đều là Nethermind.

Bài viết này được hoàn thành nhờ nguồn tài trợ từ Quỹ PBS. Cảm ơn Lin Oshitani và Davide Rezzoli vì những đánh giá và bình luận hữu ích của họ. Quan điểm là của tác giả.

Giới thiệu

Xác nhận trước là một loại cam kết cụ thể từ những người đề xuất và xây dựng khối, cung cấp cho người dùng sự đảm bảo về việc bao gồm/thực hiện giao dịch của họ trước khi người đề xuất hoặc xây dựng công bố một khối đã hoàn thành để hoàn thiện. Tuy nhiên, hầu hết các giao thức xác nhận trước đều được thiết kế và phân tích với thiết kế hiện tại của Ethereum. Nhờ có Đề xuất cải tiến Ethereum (EIP*), Ethereum luôn thay đổi và nâng cấp. Một số EIP này ảnh hưởng trực tiếp đến khả năng tương thích của các giao thức xác nhận trước, theo thiết kế hoặc như một tác dụng phụ.

Bài viết này xem xét một số EIP có tác động lớn nhất theo quan điểm của xác nhận trước và xem xét cách các EIP này sẽ ảnh hưởng đến xác nhận trước và những sửa đổi nào, nếu có, có thể được các giao thức xác nhận trước áp dụng để duy trì khả năng tương thích nếu/khi các EIP này được đưa vào Ethereum. Các EIP này tìm cách sửa đổi cách người đề xuất khối L1 được chọn, ẩn cái nhìn trước của người đề xuất , phân bổ trách nhiệm đề xuất khối trên nhiều thực thể hoặc giới thiệu các thực thể mới góp phần vào nội dung khối và khả năng chống kiểm duyệt. Báo cáo này phân tích cách các EIP này có khả năng ảnh hưởng đến xác nhận trước, dựa trên các thiết kế EIP hợp lý nhất tại thời điểm viết bài.

Tóm tắt phân tích

hình ảnh 753×629 110 KB

hình ảnh 775×853 164 KB

Phác thảo của bài viết

Trong phần Mở đầu , chúng tôi trình bày;

1. Các loại xác nhận trước, được phân loại dựa trên:
   1. Giao dịch tương ứng với lớp nào (L1 hoặc L2)
   2. Bản chất của các đảm bảo mà các xác nhận trước cung cấp (bao gồm hoặc thực hiện)
2. Các tính năng chính của giao thức xác nhận trước trong các thiết kế hiện tại:
   1. Hình phạt khi người tham dự hội nghị đi chệch hướng.
   2. Phần thưởng/tiền boa để đền bù cho người tham dự hội nghị trước.

Trong phần Khung phân tích từng EIP , chúng tôi giới thiệu khung được sử dụng để đánh giá liệu các thiết kế xác nhận trước hiện tại có bị ảnh hưởng bởi các đề xuất và EIP hay không và ảnh hưởng như thế nào.

Sau đó, mỗi phần sau đây sẽ xem xét một EIP cụ thể. Các EIP mà chúng tôi phân tích là:

1. Danh sách bao gồm. Cụ thể:
   1. Danh sách bao gồm được thực thi theo Fork-Choice (FOCIL)
   2. Thiết kế danh sách bao gồm dựa trên đấu giá để tăng cường khả năng chống kiểm duyệt trên Ethereum (AUCIL)
2. Nhiều người đề xuất đồng thời (MCP)
3. Bầu cử Lãnh đạo Bí mật Đơn (SSLE),
4. Tách người đề xuất chứng thực (APS)
5. Sự tách biệt giữa người đề xuất và người xây dựng được ghi nhận (ePBS).

Chuẩn bị

Các loại xác nhận trước

Có một số loại xác nhận trước có thể thực hiện, tùy thuộc vào lớp blockchain mà giao dịch diễn ra và bản chất của các đảm bảo mà xác nhận trước cung cấp.

Các loại xác nhận trước dựa trên lớp blockchain như sau:

1. Xác nhận trước cho các giao dịch L1; chúng tôi sẽ biểu thị chúng là xác nhận trước L1 .
2. Xác nhận trước cho các giao dịch L2 trong L2 dựa trên ; giao thức blockchain L2 trong đó thứ tự giao dịch L2 được xác định bởi L1. Trong phân loại này, có hai điểm khác biệt quan trọng:
   1. Tất cả những người đề xuất L1 đều là những người đề xuất L2. Đối với phân tích được thực hiện trong bài viết này, những xác nhận trước này không thể phân biệt được với những xác nhận trước L1. Vì lý do này và vì dễ ghi chú, chúng tôi bao gồm phân tích những xác nhận trước dựa trên L2 trong đó tất cả những người đề xuất L1 đều là những người đề xuất L2 trong phân tích những xác nhận trước L1.
   2. Một tập hợp con của những người đề xuất L1 là những người đề xuất L2. Trong bối cảnh này, một người đề xuất L2 có thể nắm giữ quyền độc quyền đề xuất các khối L2 cho nhiều hơn một khe L1. Chúng tôi sẽ biểu thị các xác nhận trước này là các xác nhận trước L2 dựa trên . Như đã đề cập ở điểm trước, 2.a, điều này loại trừ một ngoại lệ trong đó tất cả những người đề xuất L1 đều là những người đề xuất L2, được phân loại là các xác nhận trước L1 cho mục đích của bài viết này.
3. Xác nhận trước cho các giao dịch L2 trong L2 không dựa trên (ví dụ: Arbitrum , OP, giao thức blockchain Polygon Layer 2 trong đó thứ tự giao dịch được xử lý bởi bộ trình tự được kiểm soát theo rollup). Vì trong loại xác nhận trước này, thứ tự giao dịch không phụ thuộc vào người đề xuất L1, chúng tôi không mong đợi các EIP mà chúng tôi thảo luận sẽ tác động có ý nghĩa đến loại xác nhận trước này.

Các loại dựa trên bản chất của bảo lãnh thực hiện như sau:

1. Xác nhận trước bao gồm : Những xác nhận này đảm bảo rằng giao dịch sẽ được bao gồm trong khối trong tương lai.
2. Xác nhận trước khi thực hiện : Đảm bảo rằng giao dịch sẽ được đưa vào theo thứ tự cụ thể trong một khoảng thời gian cụ thể.

Lưu ý: Chúng tôi chỉ phân tích các xác nhận trước do một bên đề xuất được chỉ định cung cấp, bao gồm cả bên đề xuất/người tạo danh sách bao gồm khi có liên quan hoặc một thực thể đã được ủy quyền quyền đề xuất độc quyền. Chúng tôi bỏ qua bất kỳ phân tích nào về các xác nhận trước từ các thực thể không kiểm soát quyền đề xuất. Điều này nhằm đảm bảo phân tích tập trung vào các hình thức xác nhận trước chính dự kiến sẽ được cung cấp trên L1 và L2. Các xác nhận trước không phải của bên đề xuất và xác suất từ các thực thể không được đảm bảo sẽ đề xuất danh sách khối/bao gồm phải được tuân thủ là có thể, nhưng nằm ngoài phạm vi của bài viết này.

Lưu ý: Đối với các xác nhận trước khi đưa vào, có thể nhiều người đề xuất được chỉ định đóng vai trò là người đề xuất trước có thể đưa ra xác nhận trước cho cùng một giao dịch. Tính tương thích và hiệu quả của các mẹo sẽ phụ thuộc vào cách xử lý các xác nhận trước khi đưa vào cạnh tranh. Nói chung, những người đề xuất trước khi đưa vào phải chấp nhận rủi ro này khi đưa ra xác nhận trước. Rủi ro này trở nên cao hơn khi có nhiều người đề xuất trước cho cùng một vị trí (như trong danh sách đưa vào và nhiều EIP của người đề xuất đồng thời). Những rủi ro này có thể được giảm thiểu thông qua một trung gian ghi lại tất cả các yêu cầu và phản hồi xác nhận trước hoặc thông qua một nền tảng xác nhận trước chuyên dụng để trả tiền boa.

Trong phần còn lại của bài viết, một thực thể cung cấp xác nhận trước sẽ được gọi là hội nghị trước.

Đặc điểm của xác nhận trước trong thiết kế Ethereum hiện tại

Để xem xét cách các EIP khác nhau có thể tác động đến các thiết kế xác nhận trước, phân tích của chúng tôi xem xét cách hai cơ chế giao thức xác nhận trước quan trọng có khả năng bị ảnh hưởng bởi các EIP tương ứng. Đây là cơ chế trừng phạt và khen thưởng. Như đã nêu trong bài viết trước đây về khoản tài trợ của PBSF , các xác nhận trước phụ thuộc rất nhiều vào các động cơ để người đề xuất cung cấp và cuối cùng xác nhận các xác nhận trước. Bằng cách chứng minh tác động của từng EIP đối với các cơ chế trừng phạt và khen thưởng xác nhận trước hiện có, chúng tôi có thể xác định các điểm không tương thích xác nhận trước hoặc trong hầu hết các trường hợp, các thay đổi đối với các giao thức xác nhận trước và/hoặc các tính năng blockchain cơ bản cần thiết để kích hoạt đúng các cơ chế trừng phạt và khen thưởng, và do đó là bản thân các xác nhận trước.

Hình phạt

Tất cả các thiết kế xác nhận trước đều phụ thuộc vào một số hình thức trừng phạt và/hoặc cơ chế thực thi để ngăn cản những người tham gia trước không từ bỏ hoặc trì hoãn việc ban hành xác nhận trước. Vì mục đích phân tích của mình, chúng tôi sẽ nhóm các hình phạt này dựa trên thực thể thực thi hình phạt, lấy cảm hứng từ khuôn khổ được giới thiệu tại đây .

1. Hợp đồng thông minh: Trong tất cả các thiết kế xác nhận trước, hợp đồng thông minh có thể được sử dụng để thực thi các điều kiện liên quan đến hành vi sai trái chỉ mang tính khách quan. Một số ví dụ bao gồm vi phạm an toàn, trong đó preconfer phá vỡ thứ tự giao dịch đã xác nhận trước và vi phạm tính sống, trong đó preconfer loại trừ các giao dịch đã xác nhận trước (so sánh các điều kiện cắt giảm trong sổ đăng ký preconfer ).
2. Người giám sát ( được đề xuất tại đây ): một thực thể có thẩm quyền đặc biệt để thực thi một số hành vi hoặc hình phạt đối với những người tham gia trước. Người giám sát ban đầu được đưa vào để cho phép trao đổi công bằng các yêu cầu và phản hồi xác nhận trước, nhưng nói chung, họ có thể được sử dụng để thực thi cả các yêu cầu xác nhận trước khách quan và chủ quan. Hình phạt từ người giám sát có thể bao gồm:
   1. Cắt giảm. Người giám sát có thể tùy ý áp đặt các điều kiện cắt giảm đối với tài sản thế chấp được giao trước.
   2. Danh sách đen. Người giám sát có thể duy trì danh sách tất cả những người tham gia hội nghị trước lệch lạc và ngăn họ hoạt động như những người tham gia hội nghị trước trong một khoảng thời gian cụ thể.
   3. Mất luồng lệnh. Người giám sát có thể giảm hoặc dừng luồng lệnh (yêu cầu xác nhận trước) đối với lệnh trước bất thường thông qua một trong các phương pháp sau:
      1. Giấy xác nhận trước phải có chữ ký của cả người họp trước và người giám sát, cho phép người giám sát ngừng ký giấy xác nhận trước cho những người họp trước vi phạm.
      2. Báo hiệu. Người giám sát có thể báo hiệu rằng cuộc họp trước là sai lệch, nhắc nhở người dùng ngừng gửi yêu cầu xác nhận trước cho cuộc họp trước đó.
3. Người dùng: Người dùng có thể ngừng gửi yêu cầu xác nhận trước đến một preconfer lệch lạc, cho khe hiện tại hoặc cho các khe tương lai. Điều này sẽ được gọi là mất luồng lệnh, có thể là ngắn hạn hoặc dài hạn.

Phần thưởng/Tiền boa

Preconfers dự kiến sẽ được thưởng sau khi phát hành preconfirmation. Tiền boa có thể được trả cho preconfers thông qua phí giao dịch thông thường hoặc được quản lý và phân phối bởi một giám sát viên hoặc một hợp đồng thông minh chuyên dụng. Phân tích của chúng tôi tập trung vào cách chúng tôi mong đợi cơ chế thanh toán tiền boa và/hoặc tổng số tiền boa sẽ thay đổi theo từng EIP.

Khung phân tích từng EIP

Chúng tôi xem xét từng EIP được thảo luận trong phần Giới thiệu bằng cách sử dụng khuôn khổ sau:

1. Chúng tôi cung cấp tổng quan về EIP, tập trung vào các khía cạnh có liên quan nhất đến xác nhận trước.
2. Đối với mỗi loại hoặc nhóm loại tiền xác nhận (với một nhóm cho mỗi tiểu mục), chúng tôi thảo luận:
   1. Khả năng tương thích: Nếu phát sinh vấn đề về khả năng tương thích, chúng tôi sẽ tìm hiểu các sửa đổi tiềm năng để đảm bảo sự thống nhất.
   2. Những thay đổi về hiệu quả của hình phạt và tiền boa từ EIP.

Đối với APS, chúng tôi áp dụng một khuôn khổ khác do có một số thiết kế ứng viên, mỗi thiết kế ảnh hưởng đến khả năng tương thích của các loại tiền xác nhận khác nhau theo những cách riêng biệt. Điều này được giải thích chi tiết hơn trong Phần 4, bao gồm APS.

Mục 1. Danh sách bao gồm

Các EIP đầu tiên mà chúng tôi xem xét là các giao thức cho phép nhiều thực thể giống như người đề xuất đóng góp dữ liệu đầu vào để chặn xây dựng thông qua việc xây dựng danh sách bao gồm, với một người đề xuất được chỉ định chịu trách nhiệm xác định thứ tự giao dịch. Các giao thức này nhằm mục đích tăng cường khả năng chống kiểm duyệt trong Ethereum. Hai ví dụ nổi bật là Fork-Choice Inclusion Lists (FOCIL) (xem tại đây để biết EIP) và An Auction-Based Inclusion List Design for Enhanced Censorship Resistance on Ethereum (AUCIL) (xem tại đây để biết phiên bản in trước).

1.1. Tổng quan về FOCIL và AUCIL

Cả hai giao thức đều sử dụng một ủy ban gồm các thực thể được chọn ngẫu nhiên gọi là người bao gồm để tạo danh sách bao gồm các giao dịch.

TIÊU ĐIỂM

Người đề xuất khối tạo khối của họ và nếu có chỗ trống, họ phải bao gồm tất cả các giao dịch hợp lệ từ danh sách bao gồm. Nếu họ không làm như vậy, người chứng thực có thể từ chối khối của họ. Trong thiết kế hiện tại , người dùng không phải trả bất kỳ khoản phí nào cho người bao gồm. Chúng tôi gọi thiết kế cốt lõi này là danh sách bao gồm có điều kiện không có phí bao gồm . Các biến thể chính của giao thức cốt lõi này bao gồm:

• Danh sách bao gồm không điều kiện : Người đề xuất khối phải bao gồm tất cả các giao dịch hợp lệ từ tất cả các danh sách bao gồm của người bao gồm, ngay cả khi có tình trạng tắc nghẽn (tức là không đủ không gian để chứa tất cả các giao dịch trong mempool). Thứ tự giao dịch được xác định bởi người đề xuất khối.
• Phí bao gồm : Người dùng trả thêm phí cho ủy ban nếu giao dịch của họ được bao gồm trong cả danh sách khối và danh sách bao gồm (xem tại đây ).

ĐỒNG HÀNH

AUCIL là một giao thức khác nhằm mục đích tăng cường khả năng chống kiểm duyệt của Ethereum thông qua các danh sách bao gồm vô điều kiện (xem trang 3, 15 tại đây ). Những bổ sung chính của AUCIL là (i) có một phương pháp cân bằng tương quan cung cấp động lực cho những người bao gồm tạo IL theo một cách cụ thể và (ii) có một tổng hợp IL dựa trên đấu giá: những người tổng hợp tổng hợp các IL và gửi giá thầu, và người đề xuất khối sẽ chọn danh sách tổng hợp lớn nhất. Nếu người đề xuất khối không đáp ứng các yêu cầu cụ thể về số lượng danh sách bao gồm được đưa vào danh sách tổng hợp ( chi tiết tại đây ), thì khối của người đề xuất sẽ bị những người xác thực từ chối. Những bổ sung này (i) không phụ thuộc vào thứ tự và việc người đề xuất có thể tự thêm giao dịch hay không (ii) có thể cho phép nhiều IL hơn vì chúng tôi không cần đảm bảo rằng tất cả IL phải có sẵn cho một người tổng hợp. Trong bài viết này, chúng tôi coi việc đặt hàng được thực hiện bởi người đề xuất khối và người đề xuất khối có thể thêm nhiều giao dịch hơn (tương tự như FOCIL không điều kiện).

1.2. Phân tích xác nhận trước

Chúng tôi sắp xếp các phân tích sau đây thành các nhóm loại tiền xác nhận có chung các đặc điểm tương tự về khả năng tương thích với thiết kế tiền xác nhận hiện có, cũng như những thay đổi về hiệu quả của các hình phạt và tiền boa liên quan. Các nhóm như sau:

• Xác nhận trước khi đưa vào.
• Xác nhận trước khi thực hiện L1.
• Dựa trên xác nhận trước khi thực hiện L2.

1.2.a. Xác nhận trước khi bao gồm

Với danh sách bao gồm, có hai tác nhân riêng biệt có khả năng cung cấp xác nhận trước: người đề xuất khối và người bao gồm. Do đó, chúng tôi thảo luận về khả năng tương thích riêng cho từng tác nhân.

Khả năng tương thích: Chặn xác nhận trước của người đề xuất

Với danh sách bao gồm có điều kiện trong FOCIL:

• Người đề xuất khối vẫn có thể bao gồm tất cả các xác nhận trước trong khối của họ (vì họ chỉ được yêu cầu tôn trọng danh sách bao gồm khi có đủ chỗ)
• Quy trình bầu chọn người đề xuất khối vẫn không thay đổi. Do đó, chúng tôi không dự đoán bất kỳ vấn đề tương thích nào với các thiết kế xác nhận trước hiện có.

Trong trường hợp danh sách bao gồm vô điều kiện như trong FOCIL và AUCIL, nếu danh sách bao gồm kết hợp được biết là chiếm ít không gian hơn tổng không gian khối, chúng tôi một lần nữa không dự đoán bất kỳ vấn đề tương thích nào. Trong trường hợp này, người đề xuất khối vẫn có thể đưa ra xác nhận trước cho không gian khối còn lại.

Người đề xuất có thể đưa ra các xác nhận trước vượt quá không gian có sẵn trong các khối của họ, dự đoán rằng những người đề xuất L1 trước đó sẽ sử dụng không gian khối có sẵn để đưa các xác nhận trước này vào thay mặt cho người trước khi hội nghị. Vì danh sách bao gồm được kỳ vọng sẽ tăng cường khả năng chống kiểm duyệt, điều này làm cho việc đưa ra các xác nhận trước vượt quá không gian trong khối của người trước khi hội nghị trở nên khả thi hơn và ít rủi ro hơn.

Khả năng tương thích: Xác nhận trước của người bao gồm

Với danh sách bao gồm vô điều kiện trong FOCIL, những người bao gồm cũng có thể đưa ra xác nhận trước về việc bao gồm. Giả sử rằng FOCIL hoạt động như mong đợi (ví dụ 2/3 2/3 người chứng thực là trung thực và người đề xuất khối có mục đích tạo ra một khối hợp lệ), xác nhận trước từ những người bao gồm có cùng lợi ích như xác nhận trước từ người đề xuất khối.

Với AUCIL, các xác nhận trước do includer đưa ra có rủi ro hơn, vì như chúng tôi đã đề cập, AUCIL cho phép trường hợp danh sách include không khả dụng với tất cả các aggregator. Để có cùng các đảm bảo xác nhận trước như FOCIL, chúng tôi sẽ cần trong thiết kế AUCIL rằng người đề xuất khối bị phạt ngay cả khi họ bỏ sót một IL duy nhất.

Khả năng này của những người đưa vào danh sách bao gồm vô điều kiện để cung cấp xác nhận trước có một nhược điểm đáng chú ý: xác nhận trước chiếm không gian trong danh sách bao gồm, chủ yếu dành cho các giao dịch dễ bị kiểm duyệt. Nhược điểm này được gọi là "đông đúc" và đã được thảo luận tại đây , tại đây .

Đối với FOCIL có điều kiện, chúng tôi không mong đợi những người bao gồm đưa ra xác nhận trước, vì người đề xuất khối có thể bỏ qua các IL khi khối đầy mà không bị người xác nhận từ chối khối của họ. Ngoài ra, trong khe tiếp theo, những người bao gồm mới sẽ được bầu và người đề xuất khối của khe tiếp theo không có nghĩa vụ phải bao gồm các giao dịch từ các IL đã được phát hành cho các khối trước đó. ( Các IL duy nhất cần được tuân thủ đối với khe N+1 là những IL được truyền bá giữa giây 0 và giây 9 của khe N. ).

Hiệu quả của hình phạt và mẹo

Danh sách bao gồm có điều kiện không nên ảnh hưởng đến hiệu quả của cơ chế trừng phạt, vì những người tham dự hội nghị vẫn là những thực thể giống nhau, được bầu theo cùng một cách thức và với cùng tần suất.

Trong trường hợp FOCIL và AUCIL không điều kiện, theo quan điểm của người đề xuất khối, chúng tôi chỉ mong đợi các cơ chế trừng phạt liên quan đến các mẹo xác nhận trước trong tương lai được thực hiện, tức là các hình phạt đưa vào danh sách đen và mất luồng lệnh.

Vì danh sách bao gồm vô điều kiện phải chiếm một phần không gian khối, nên người đề xuất khối có ít không gian hơn cho các xác nhận trước. Điều này sẽ ảnh hưởng đến các mẹo xác nhận trước và, theo đó, hiệu quả của việc đưa vào danh sách đen và các hình phạt về luồng lệnh dài hạn. Tại thời điểm này, rất khó để dự đoán chính xác tác động của danh sách bao gồm vô điều kiện đối với các mẹo, nhưng chúng ta thấy ít nhất hai lực đối kháng chính:

• Danh sách bao gồm vô điều kiện làm giảm khả năng xác nhận trước và do đó làm giảm số lượng xác nhận trước để thu thập thông tin.
• Tiền boa trung bình cho mỗi lần xác nhận trước có thể tăng do nguồn cung không gian khối giảm và nhu cầu về không gian khả dụng tăng cao.

Trong trường hợp các includer hoạt động như preconfers, hiệu quả của việc đưa vào danh sách đen và mất luồng lệnh sẽ liên quan trực tiếp đến giá trị của thị trường preconfirmation danh sách include. Cũng giống như preconfirmation của người đề xuất, tần suất bầu chọn, quy mô của danh sách include và thời gian preconfirmation trước một slot có thể được đưa ra bao xa đều ảnh hưởng đến doanh thu preconfirmation của includer. Tuy nhiên, động lực chính của giá trị này sẽ đến từ nhu cầu của người dùng. Trong trường hợp không có thị trường preconfirmation giá trị cao, việc cắt giảm vẫn là một cơ chế trừng phạt khả thi.

Như đã đề cập trong phần Các loại xác nhận trước, nhiều người bao gồm đóng vai trò là người xác nhận trước bao gồm cho cùng một vị trí sẽ làm tăng nguy cơ xảy ra xung đột xác nhận trước bao gồm, điều này có thể dẫn đến rủi ro thanh toán và tiền boa cho những người xác nhận trước.

1.2.b. Xác nhận trước khi thực hiện L1

Khả năng tương thích

Trong trường hợp này, xác nhận trước chỉ có thể được đưa ra bởi người đề xuất khe N N trong khe N N. Ngoài ra, trong cả danh sách bao gồm có điều kiện và không điều kiện, người đề xuất khối vẫn giữ quyền kiểm soát đối với thứ tự của một khối. Điều này đảm bảo rằng sau khi khối cho khe N-1 N − 1 đã được công bố, người đề xuất khối cho khe N N hoàn toàn nhận thức được trạng thái L1 hoặc L2 có liên quan phải được tôn trọng khi đưa ra xác nhận trước thực thi. Do đó, chúng tôi không mong đợi bất kỳ vấn đề tương thích nào với các loại xác nhận trước này, ngoại trừ thực tế là trong danh sách bao gồm không điều kiện, người đề xuất khối chỉ nên đưa ra xác nhận trước cho không gian khối không bị chiếm dụng cho danh sách bao gồm.

Đối với các xác nhận trước khi thực hiện, các includeer không thể hoạt động như các preconfidor vì chúng không kiểm soát thứ tự các giao dịch trong các khối L1 hoặc L2.

Hiệu quả của hình phạt và mẹo

Hiệu quả của hình phạt và lời khuyên cho những xác nhận trước này cũng tương tự như hiệu quả của xác nhận trước khi đưa vào theo quan điểm của người đề xuất khối.

Vì các includeer không thể cung cấp các preconf thực thi nên phân tích của chúng không liên quan đến phần này.

1.2.c. Dựa trên xác nhận trước thực hiện L2

Khả năng tương thích

Không có vấn đề về khả năng tương thích. Các preconference thực thi L2 dựa trên có thể cung cấp các xác nhận trước ngay khi khe xác nhận trước của chúng bắt đầu. Các includer, dù là vô điều kiện hay có điều kiện, đều không thể cung cấp các preconfirm thực thi L2 dựa trên chỉ bằng cách là includer. Nếu một includer tình cờ được đăng ký là một người đề xuất L2, includer đó chỉ có thể cung cấp các preconfirm thực thi L2 dựa trên nếu includer đó cũng là preconference thực thi đang hoạt động, tức là đó là khe xác nhận trước của includer đó. Ngược lại, nếu đó là khe xác nhận trước của người khác, thì người khác đó có quyền độc quyền đề xuất các khối L2, do đó làm mất hiệu lực bất kỳ khối L2 nào do includer đề xuất.

Hiệu quả của hình phạt và mẹo

Trong danh sách bao gồm vô điều kiện, các cuộc họp trước có ít không gian khối khả dụng hơn. Nếu việc giảm này ảnh hưởng đến phần thưởng dự kiến từ các xác nhận trước cho mỗi vị trí, thì danh sách đen và luồng lệnh dài hạn cũng sẽ bị ảnh hưởng, như đã thảo luận trong Phần 1.2.a.

Ngoài ra, chúng tôi không mong đợi những thay đổi đáng kể về hiệu quả của hình phạt và tiền boa, vì những người tham dự hội nghị được bầu theo cùng một cách và với cùng tần suất có hoặc không có danh sách đưa vào.

Mục 2. Nhiều người đề xuất đồng thời (MCP)

2.1. Tổng quan về MCP

Trong MCP, hai hoặc nhiều thực thể đề xuất một khối dữ liệu cục bộ cho khe hiện tại (chúng tôi biểu thị các khối dữ liệu cục bộ này là các khối con). Khối dữ liệu cục bộ cuối cùng được hình thành bằng cách lấy hợp các giao dịch từ tất cả các khối con này, được sắp xếp theo một số quy tắc sắp xếp xác định. Quy tắc chính xác này đang được tranh luận, nhưng thứ tự phí ưu tiên đã được xem xét . BRAID là một ví dụ về giao thức MCP.

2.2. Phân tích xác nhận trước

Chúng tôi chia phân tích xác nhận trước của phần này thành:

• Xác nhận trước khi đưa vào.
• Xác nhận trước khi thực hiện.

2.2.a. Xác nhận trước khi bao gồm

Khả năng tương thích

Giả sử rằng sự hợp nhất của các khối con không lớn hơn khối cuối cùng, những người đề xuất có thể hoạt động như những người tiền hội nghị bao gồm, vì khối cuối cùng bao gồm tất cả các giao dịch từ tất cả các khối con (cũng được thảo luận tại đây , tại đây , tại đây ).

Hiệu quả của hình phạt và tiền boa

Như đã đề cập trong Phần 1, hiệu quả của danh sách đen và mất luồng lệnh dài hạn phụ thuộc vào các mẹo dự kiến từ các xác nhận trước cho mỗi kỷ nguyên. Mẹo càng cao thì các hình phạt này càng hiệu quả. Mặc dù người đề xuất nên được bầu thường xuyên hơn trong MCP so với giao thức một người đề xuất, nhưng kích thước của các khối con phải tỷ lệ thuận với nghịch đảo của số người đề xuất để duy trì việc sử dụng băng thông mạng. Nói cách khác, tổng không gian khả dụng cho các xác nhận trước phải giữ nguyên trong MCP và thiết lập một người đề xuất. Nếu đây là trường hợp, chúng tôi không mong đợi sự thay đổi trong các mẹo tiền cấu hình bao gồm trong MCP.

Như đã đề cập trong phần Các loại xác nhận trước, nhiều người đề xuất MCP hoạt động như những người tham gia trước khi bao gồm cho cùng một vị trí làm tăng nguy cơ xung đột giữa các xác nhận trước khi bao gồm, điều này có thể mang lại rủi ro cho những người tham gia trước khi bao gồm. Điều này sẽ phụ thuộc vào:

• Cách triển khai MCP cụ thể xử lý các giao dịch trùng lặp.
• Tiền boa được trả cho những người tham gia trước khi giao dịch khi có nhiều hơn một người tham gia trước cung cấp xác nhận trước cho cùng một giao dịch:
  • chỉ trả một khoản tiền boa, ví dụ cho người đề xuất có khối chứa bản sao hoàn thiện của các giao dịch.
  • tất cả các cuộc họp trước đều nhận được một mẹo.

2.2.b. Xác nhận trước khi thực hiện

Khả năng tương thích

Điều này phụ thuộc vào quy tắc sắp xếp, nhưng nhìn chung, người đề xuất MCP không biết thứ tự cuối cùng của khối đã hợp nhất không thể đưa ra xác nhận trước về thực thi L1. Trong triển khai MCP, trong đó các khối con được ưu tiên sắp xếp trước, người đề xuất khối con đầu tiên có thể đưa ra xác nhận trước về thực thi. Tuy nhiên, triển khai MCP như vậy vẫn chưa được xem xét đúng mức tại thời điểm này, mặc dù nó rất giống với FOCIL không điều kiện, với người đề xuất khối được ưu tiên xây dựng và sắp xếp khối trên cùng.

Đối với preconf thực thi L2, nếu một người đề xuất MCP duy nhất có quyền độc quyền đề xuất một khối L2, thì có thể thực hiện prefirm thực thi L2. Ngược lại, nếu nhiều hơn một người đề xuất MCP có thể đề xuất một khối L2, thì prefirm thực thi không tương thích.

Mục 3. Bầu cử Lãnh đạo bí mật duy nhất

3.1. Tổng quan về SSLE

Trong các cấu trúc hiện có của Single Secret Leader Election (SSLE), một điểm chung là lịch trình xác thực cho kỷ nguyên tiếp theo được giữ ẩn; chỉ có xác thực viên được bầu mới biết các vị trí cụ thể mà họ được chỉ định làm người dẫn đầu (= người đề xuất), với một người dẫn đầu duy nhất cho mỗi vị trí. Điều này được thiết kế để tăng cường khả năng bảo vệ Từ chối dịch vụ (DoS). Mô tả cụ thể về giao thức SSLE là Whisk , được trình bày bên dưới.

Whisk , một phiên bản sửa đổi của giao thức được giới thiệu tại đây , hoạt động như sau. Ban đầu, trong thời gian khởi động, mỗi trình xác thực cam kết với một bí mật ngẫu nhiên dài hạn. Sau đó, một tập hợp con ngẫu nhiên của các trình xác thực, được chọn thông qua RANDAO, được chọn để cam kết với bí mật dài hạn của chúng bằng cách sử dụng tính ngẫu nhiên mới. Các cam kết này sau đó được xáo trộn và ngẫu nhiên lại bởi các nhà lãnh đạo của khoảng thời gian hiện tại. Từ nhóm các trình xác thực được xáo trộn này, một tập hợp con ngẫu nhiên khác gồm một cho mỗi khe được chọn thông qua RANDAO để đóng vai trò là người lãnh đạo khe cho khoảng thời gian tiếp theo. Phương pháp chỉ định sao cho chỉ có trình xác thực được chỉ định cho một khe (biết bí mật tương ứng với khe) mới biết được chỉ định khe. Để chứng minh quyền lãnh đạo cho một khe nhất định, trình xác thực phải chứng minh quyền sở hữu đối với cam kết tương ứng (mà không tiết lộ bí mật dài hạn của họ). Họ đạt được điều này bằng cách sử dụng bằng chứng không kiến thức để chứng minh rằng họ biết bí mật được nhúng trong cam kết và bí mật này khớp với bí mật dài hạn của họ, được liên kết mật mã với danh tính của họ.

3.2. Phân tích xác nhận trước

Chúng tôi chia phần phân tích của Phần 3 thành:

• Bao gồm và xác nhận trước khi thực hiện L1.
• Dựa trên xác nhận trước khi thực hiện L2.

3.2.a. Bao gồm và xác nhận trước thực hiện L1

Khả năng tương thích

Trong các thiết kế SSLE, nếu người tham dự trước sẵn sàng tiết lộ danh tính của họ trước, thì chúng tôi không mong đợi các vấn đề về khả năng tương thích với các thiết kế xác nhận trước hiện có. Tất nhiên, điều này phá vỡ tính bí mật của cuộc bầu cử.

Mặt khác, nếu người tham gia trước muốn ẩn danh trước khi đề xuất một khối, thì việc xây dựng cơ chế xác nhận trước đòi hỏi phải điều chỉnh cẩn thận. Chúng tôi cung cấp tổng quan cấp cao về giao thức xác nhận trước đã sửa đổi tương thích bên dưới.

Để người xác thực chứng minh họ đủ điều kiện tham gia hội nghị trước cho vị trí N N trong khi vẫn ẩn danh, người xác thực phải chứng minh hai tuyên bố sau là đúng:

• Người xác thực là người đứng đầu của khe N N.
  Việc sử dụng bằng chứng không có kiến thức để chứng minh tuyên bố này cũng đã được thảo luận tại đây và tại đây . Trong trường hợp cụ thể của Whisk , người xác thực cần chứng minh rằng họ biết bí mật dài hạn ẩn trong cam kết liên quan đến khe N N.
• Nếu hình phạt liên quan đến việc cắt xén, người xác thực cần chứng minh rằng họ hiện đang đăng ký cắt xén, ví dụ như trong hợp đồng đăng ký .
  Một cách để đạt được điều này là hợp đồng thông minh đăng ký duy trì một cây Merkle chỉ thêm vào chứa các khóa công khai của tất cả các trình xác thực đã đăng ký, chẳng hạn như hiện có trong hợp đồng đăng ký chung . Sau đó, preconfer có thể cung cấp bằng chứng chứng minh rằng họ sở hữu khóa riêng tương ứng với khóa công khai có trong cây Merkle này (tương tự như các kỹ thuật được sử dụng trong Zcash ).
• Nếu hình phạt liên quan đến việc đưa vào danh sách đen, người xác thực cần chứng minh rằng họ không thuộc nhóm bị đưa vào danh sách đen.
  Một cách để thực hiện điều này là người giám sát (hoặc hợp đồng thông minh) sẽ duy trì một tập hợp những người tham gia hội nghị trước bị đưa vào danh sách đen và những người không bị đưa vào danh sách đen, và những người tham gia hội nghị trước phải chứng minh rằng họ là thành viên của tập hợp không bị đưa vào danh sách đen, ví dụ như sử dụng bằng chứng bao gồm cây Merkle thưa thớt.

Về khả năng tương thích của các mẹo, nếu các mẹo được đưa ngay cho preconfer, preconfer sẽ cần tiết lộ một địa chỉ trước slot của họ, điều này có khả năng tiết lộ danh tính của họ. Thay vào đó, các mẹo có thể được trả cho một hợp đồng thông minh và được giải ngân cho preconfer sau slot N N , trừ khi không đáp ứng được các điều kiện cắt giảm nào. Sau khi slot N N trôi qua, danh tính của người xác thực sẽ trở nên công khai. Do đó, các mẹo và hình phạt có thể được áp dụng từ thời điểm đó.

Các hình phạt liên quan đến danh tiếng do người dùng áp đặt không dễ áp dụng trong khi vẫn giữ danh tính của người tham gia trước được ẩn danh. Có thể kích hoạt các công cụ danh tiếng ẩn danh để cho phép người tham gia trước truyền đạt danh tiếng cho người dùng. Tuy nhiên, vì danh tiếng được dự định thay thế danh sách đen và các giao thức liên quan đến người giám sát khác, điều này có nghĩa là danh tiếng của mỗi người tham gia trước cần được duy trì trên cơ sở từng người dùng, điều này rất phức tạp và có khả năng không phù hợp với mục đích.

Hiệu quả của hình phạt và tiền boa

Như đã đề cập ở phần trước, SSLE không có tiết lộ danh tính trước khiến các hình phạt dựa trên danh tiếng trở nên cực kỳ phức tạp và có khả năng không hiệu quả. Các cơ chế trừng phạt khác vẫn phải có hiệu quả, mặc dù cần phải thực hiện cẩn thận theo cách thực hiện đã thảo luận ở phần trước.

Nhu cầu về preconfirmatons theo preconfirmation SSLE về lý thuyết phần lớn sẽ không thay đổi. Tuy nhiên, xét đến sự phức tạp bổ sung mà preconfirmation SSLE gây ra, chúng tôi kỳ vọng những người đề xuất sẽ yêu cầu các mẹo preconfirmation cao hơn để trở thành preconference.

Cuối cùng, nếu tần suất bầu cử thay đổi và làm thay đổi phần thưởng dự kiến từ các xác nhận trước theo từng kỷ nguyên, hiệu quả của việc đưa vào danh sách đen hoặc mất luồng lệnh cũng sẽ bị ảnh hưởng, như đã thảo luận ở các phần trước.

3.2.b. Dựa trên xác nhận trước thực hiện L2

Khả năng tương thích

Hãy nhớ rằng loại xác nhận trước này có thể được một preconference phát hành khi khe xác nhận trước của họ bắt đầu, có thể bao gồm một hoặc nhiều khe L1. Hãy nhớ rằng để cung cấp các xác nhận trước thực hiện sớm hơn khe đề xuất của họ, những người preconference cần biết trước về preconference. Để cho phép tiết lộ trước về preconference (hoặc lịch trình của những người preconference không có danh tính), chúng ta cần một cơ chế buộc/khuyến khích tất cả những người preconference tiết lộ khe của họ, theo cách tương tự như cách được mô tả trong Phần 3.2.a (bằng cách tiết lộ danh tính của họ hoặc bằng cách sử dụng bằng chứng không có kiến thức để chứng minh rằng họ đủ điều kiện là những người preconference cho một khe cụ thể).

Giải pháp khả thi - Sử dụng Overseer: Trong các hệ thống L2, một Overseer có thể đặt thời hạn cho việc tiết lộ trước khi hội nghị. Điều này buộc tất cả các preconfer phải tiết lộ vai trò của họ theo thời hạn cố định, ví dụ như vài giây sau khi lịch trình xác thực được xác định bởi giao thức SSLE. Sau thời hạn, các khe cắm với preconfer trở nên cố định, cho phép một lịch trình preconfer xác định. Tuy nhiên, cách tiếp cận này đưa ra một vấn đề về tính sống động tiềm ẩn khi người giám sát có thể từ chối một preconfer tiết lộ vai trò của họ theo thời gian.

Để giảm thiểu điều này và loại bỏ sự phụ thuộc vào tính sống động của người giám sát, người giám sát có thể bị hạn chế chỉ cắt, cắt bất kỳ preconference nào không tiết lộ vai trò của họ trước thời hạn cụ thể. Giải pháp thay thế này đi kèm với nhược điểm riêng của nó: lookahead không còn mang tính xác định nữa. Nếu lookahead không mang tính xác định, các xác nhận trước khi thực hiện cho một cửa sổ xác nhận trước của nhiều hơn một khe có nguy cơ bị vô hiệu hóa bởi người đề xuất tiết lộ vai trò của họ là preconference hợp lệ trong một khe trước đó trong cửa sổ xác nhận trước. Do đó, chúng tôi thấy giải pháp lookahead do người giám sát thực thi là giải pháp khả thi hơn cho các xác nhận trước khi thực hiện L2 dựa trên.

Hiệu quả của hình phạt và tiền boa

Hiệu quả của tiền boa và hình phạt dự kiến sẽ giống như những gì đã thảo luận trong phần trước về SSLE.

Phần 4. Tách người đề xuất chứng thực (APS)

4.1. Tổng quan về APS

Trong APS , vai trò của người đề xuất thực hiện được tách khỏi các nhiệm vụ xác thực khác, chẳng hạn như xác nhận. Sự tách biệt này cho phép những người đề xuất thực hiện tinh vi hơn tham gia vào Ethereum đồng thời giảm thiểu sự lan tỏa động cơ từ người đề xuất sang người xác thực, những người nên vẫn là một phần của bộ xác thực phi tập trung cao độ. Hai trong số các thiết kế APS chính là Đấu giá thực hiện (EA) và Vé thực hiện (ET).

Trong cả hai thiết kế, vai trò của người đề xuất thực hiện được giao cho các thực thể cạnh tranh tinh vi. Trong EA, những người đề xuất được lựa chọn một cách xác định thông qua một cuộc đấu giá, trong khi ở ET, họ được chọn ngẫu nhiên thông qua một cuộc xổ số mà họ đã mua vé trước đó (xem tại đây, tại đây , tại đây , tại đây ).

4.2. Phân tích xác nhận trước

Chúng tôi xây dựng các phân tích sau đây xung quanh hai khía cạnh thiết kế chính của APS được mô tả ở trên:

• Khi cuộc đấu giá APS được tiến hành . Cụ thể là, người đề xuất thực hiện cho vị trí N N được bầu trước bao lâu. Các đề xuất bao gồm:
  • Nhiều khe ở phía trước (ví dụ 32 khe).
  • Dt D t giây sau khi khối cho khe N-1 N − 1 được đề xuất (đề xuất được trình bày tại đây ; đề xuất được biểu thị là vé thực hiện trước 2 khe với tính ngẫu nhiên ). Trong thiết kế này, người đề xuất thực hiện khe N N được xác định thông qua tính ngẫu nhiên được trích xuất Dt D t giây sau khi đề xuất khối cho khe N-1 N − 1 .
  • Trong thời gian diễn ra phiên đấu giá đúng lúc (JIT).
• Có được phép bán lại quyền đề xuất trong giao thức hay không, nghĩa là liệu người đề xuất được bầu có thể bán lại quyền đề xuất của họ hay không.

Đối với mỗi loại APS trong khía cạnh thiết kế này, chúng tôi phác thảo loại xác nhận trước nào tương thích và không tương thích. Cuối cùng, trong tiểu mục cuối cùng, chúng tôi thảo luận về tác động dự kiến của APS đối với hiệu quả của hình phạt và tiền boa.

4.2.a. Khả năng tương thích: Khi đấu giá APS được thực hiện

Về khả năng tương thích, những người tham gia trước sẽ là người chiến thắng trong các cuộc đấu giá hoặc xổ số APS tương ứng. Điều này mở đường cho các cổng tập trung, những người có thể cung cấp xác nhận trước thay mặt cho người xác thực trong thiết lập Ethereum hiện tại, để loại bỏ người trung gian này và tự trở thành người đề xuất để giảm thiểu chi phí/tối đa hóa doanh thu. Do đó, chúng tôi mong đợi những người đề xuất thực hiện L1 và người xác nhận trước sẽ tinh vi hơn theo APS, với tần suất lựa chọn của họ tách biệt với số tiền họ gửi.

Như đã thảo luận ở đây , trong các thiết kế APS, trong đó RANDAO là nguồn ngẫu nhiên duy nhất, tồn tại sự đánh đổi giữa một thuộc tính được gọi là ngăn ngừa MEV đa khe và khả năng tương thích với các xác nhận trước . MEV đa khe đề cập đến hiện tượng mà việc trở thành người đề xuất nhiều khe liên tiếp mang lại nhiều MEV hơn tổng MEV có sẵn từ từng khe riêng lẻ (xem tại đây ). Cấu trúc được trình bày ở đây giải quyết sự đánh đổi này bằng cách ngăn ngừa MEV đa khe trong khi vẫn hỗ trợ một số loại xác nhận trước nhất định. Tuy nhiên, nó giả định rằng người đề xuất thực hiện cho khe N N được chọn bằng cách sử dụng tính ngẫu nhiên được trích xuất Dt D t giây sau khi khối cho khe trước đó được đề xuất. Dưới đây, chúng tôi trình bày chi tiết về những suy nghĩ này:

• Trong các thiết kế mà người đề xuất thực hiện được chọn trước nhiều khe, chúng tôi mong đợi thấy tất cả các loại xác nhận trước. Nhược điểm của các thiết kế này là dễ bị MEV đa khe.
• Các thiết kế trong đó người đề xuất thực hiện cho khe N N được bầu Dt D t giây sau khi đề xuất khối cho khe N-1 N − 1 (được trình bày tại đây ) ngăn chặn MEV đa khe và chỉ hỗ trợ các xác nhận trước bao gồm và thực hiện được ban hành trong chính khe. Dt D t nhỏ hơn dẫn đến nhiều thời gian hơn và các xác nhận trước có giá trị hơn. Nhược điểm của các thiết kế này là chúng giả định tính ngẫu nhiên được trích xuất sau khi đề xuất khối cho khe N N.
• Các thiết kế trong đó việc bầu chọn người đề xuất thực hiện diễn ra trong khe, ví dụ như đấu giá đúng lúc, ngăn chặn MEV đa khe vì người đề xuất thực hiện của khe N N đề xuất một tải trọng trước khi biết người đề xuất thực hiện cho khe N+1 N + 1. Tuy nhiên, chúng tôi không mong đợi các thiết kế bầu chọn đúng lúc này hỗ trợ bất kỳ loại xác nhận trước nào của người đề xuất.

4.2.b. Khả năng tương thích: Bán lại quyền đề xuất trong giao thức

Các thiết kế mà người đề xuất thực hiện được chọn nhiều vị trí trước nhưng được phép bán lại quyền của họ trong giao thức vẫn có thể hỗ trợ xác nhận trước, miễn là một trong những điều sau đây được áp dụng:

• Có một cơ chế thực thi tại chỗ để người đề xuất thực hiện ban đầu có thể thực thi bất kỳ xác nhận trước nào được cung cấp cho người đề xuất mua quyền đề xuất. Cơ chế thực thi chính xác sẽ rất quan trọng:
  • Bắt buộc sắp xếp thứ tự đầu khối L1 của danh sách giao dịch cụ thể: tất cả các loại xác nhận trước có thể được cung cấp và thực thi bởi người đề xuất ban đầu.
  • Chỉ bao gồm L1: Người đề xuất ban đầu có thể cung cấp
    • xác nhận trước khi bao gồm.
    • dựa trên xác nhận trước thực hiện L2 trong đó tất cả các giao dịch được xác nhận trước L2 (1) yêu cầu chữ ký từ người đề xuất ban đầu và (2) có thể được bao gồm trong một giao dịch L1 duy nhất.
      Tuy nhiên, xác nhận trước khi thực hiện L1 không được hỗ trợ vì người đề xuất ban đầu không thể thực thi lệnh.