Bài viết này được viết bởi Chanyang Ju ( wooju ), Nhà nghiên cứu tại Radius . Cảm ơn Hugo đã đóng góp cho PoC và AJ đã xem xét bài viết này.

1. Tóm tắt

Bài viết này giới thiệu State Lock Commitment , một cơ chế cam kết không gian khối mới cho Proposer-Builder Separation (PBS). Các cam kết dựa trên bao gồm hiện tại không đảm bảo tính nhất quán trong thực hiện, dẫn đến việc người tìm kiếm áp dụng các chiến lược tránh rủi ro làm giảm hiệu quả thị trường. Chúng tôi đề xuất một phương pháp tiếp cận thành phần kép vượt ra ngoài các lời hứa bao gồm đơn giản. Đầu tiên, một Cam kết loại trừ được đưa ra: một sự bảo lưu trước, không phụ thuộc vào người xây dựng, đảm bảo một trạng thái cụ thể sẽ không bị thay đổi bởi các giao dịch xung đột. Tiếp theo là một Cam kết bao gồm tiêu chuẩn (xác nhận trước) cho gói thắng trong phiên đấu giá tiếp theo. Cùng nhau, các cam kết này cung cấp các đảm bảo mạnh mẽ tương đương với Cam kết thực hiện , cho phép người tìm kiếm đấu giá với sự tự tin hơn. Kiến trúc bao gồm một Cổng (dành cho người đề xuất) và một LockEngine (dành cho người xây dựng), cho phép người đề xuất đấu giá các quyền trạng thái độc quyền, ngăn ngừa xung đột, tăng doanh thu và thúc đẩy thị trường MEV mạnh mẽ và hiệu quả hơn.

1.1 Bối cảnh

Phân tách Người đề xuất-Người xây dựng (PBS) coi không gian khối là một tài sản có thể giao dịch, cho phép người đề xuất đấu giá quyền xây dựng một khối. Điều này cho phép ủy quyền một phần việc xây dựng khối thông qua các cam kết được bán cho những người tham gia bên ngoài, chẳng hạn như người xây dựng và người tìm kiếm. Hiện tại, hầu hết các cam kết này đều dựa trên cơ chế bao gồm (như danh sách bao gồm và xác nhận trước), mặc dù thị trường vẫn đang tiếp tục phát triển.

Tuy nhiên, không có hệ thống nào được áp dụng rộng rãi để đảm bảo một gói dữ liệu sẽ thực thi đúng trạng thái mong muốn, do những hạn chế về mặt kỹ thuật và kinh tế. Kết quả là:

• Ngay cả khi một gói được xác nhận trước được đưa vào một khối, thì việc thực thi dự định của nó vẫn có thể thay đổi hoặc giao dịch có thể thất bại nếu trạng thái bị thay đổi trước đó.
• Vì chỉ đảm bảo bao gồm thôi là không đủ để thực hiện nhất quán nên người tìm kiếm phải phòng ngừa rủi ro, ngăn chặn việc đấu thầu quá mức.
• Việc thực hiện thường xuyên nhưng không thành công sẽ làm suy yếu niềm tin vào các cam kết và làm giảm hiệu quả thị trường, cuối cùng làm giảm doanh thu của bên đề xuất.

Để tiến triển, các cam kết về không gian khối phải phát triển vượt ra ngoài những lời hứa bao gồm đơn giản và hướng tới các đảm bảo ở cấp độ thực thi nhằm đảm bảo tính nhất quán của trạng thái.

1.2 Giải pháp: Cam kết khóa trạng thái

Để giải quyết các hạn chế này, chúng tôi giới thiệu Cam kết Khóa Trạng thái : một cơ chế trong đó người đề xuất cam kết rõ ràng quyền thực thi độc quyền đối với trạng thái mà một gói truy cập. Cam kết này vượt ra ngoài phạm vi bao gồm đơn thuần bằng cách đảm bảo phạm vi trạng thái được xác định trong khối không bị thay đổi, cho phép thực thi gói ổn định.

Thay vì áp dụng khóa trạng thái toàn cục, phương pháp của chúng tôi áp dụng Khóa Trạng thái Cục bộ trên từng bó. Điều này tránh đồng bộ hóa toàn cục hoặc kiểm soát trên toàn bộ mempool, thay vào đó chỉ hạn chế các phạm vi trạng thái có khả năng xung đột. Một khía cạnh quan trọng của kiến trúc này là người đề xuất phải liên tục truyền đạt quyền thực thi độc quyền cho một trạng thái EVM cụ thể cho tất cả các builder. Nói cách khác, ngay cả khi các builder khác nhau xây dựng các khối ứng viên khác nhau, ràng buộc này phải hoạt động như một quy tắc hạn chế truy cập chung cho tất cả các tùy chọn đang được xem xét.

Cam kết khóa trạng thái hoạt động theo hai giai đoạn, đóng vai trò như một ràng buộc một phần đối với người xây dựng:

1. Cam kết loại trừ: Người đề xuất tuyên bố một stateScope cụ thể là ứng viên khóa và thông báo điều này tới tất cả người xây dựng, hướng dẫn họ không bao gồm các giao dịch xung đột.
2. Cam kết bao gồm: Sau khi phiên đấu giá cho stateScope kết thúc, xác nhận trước gói giành được quyền đưa vào khối cuối cùng.

Việc sử dụng song song hai cam kết này làm tăng đáng kể khả năng thực hiện gói nhất quán và tránh xung đột. Trong một số điều kiện nhất định, điều này có thể cung cấp mức độ đảm bảo thực hiện cao (cam kết thực hiện). Khi Cam kết Loại trừ được lan truyền đến tất cả các nhà xây dựng và được thực thi nhất quán, người tìm kiếm sẽ có được lợi thế cạnh tranh với giả định rằng "sẽ không ai chạm vào trạng thái được chỉ định của tôi", ngay cả khi không có đảm bảo bao gồm rằng "gói của tôi sẽ ở đầu khối".

Do đó, một lời hứa bao gồm dựa trên ràng buộc cấp tiểu bang (loại trừ) có thể được xem như một phần của chuỗi cam kết thực hiện liên tục. Là một ràng buộc không phụ thuộc vào nhà xây dựng, cơ chế này có thể định hình lại cả động lực xây dựng khối lẫn các động lực và cạnh tranh trong tương lai của thị trường MEV.

1.2.1 Tổng quan

Thành phần & Trách nhiệm

Luồng thủ tục

1. Nộp và Đấu giá: Người tìm kiếm nộp một gói hàng lên Cổng thông tin.
2. Phối hợp & Bắt đầu đấu giá: Cổng mô phỏng gói để tự động trích xuất stateScope của nó (ví dụ: danh sách truy cập) và bắt đầu đấu giá cho stateScope cụ thể này.
3. Loại trừ: Trong khi phiên đấu giá đang diễn ra, người đề xuất (thông qua Cổng thông tin) sẽ thông báo stateScope là ứng viên khóa. Điều này hoạt động như một Cam kết Loại trừ ban đầu và được truyền đến tất cả người xây dựng tham gia.
4. Đấu giá & Xác nhận trước: Các nhà xây dựng, nhận thức được ràng buộc này, sẽ tạm thời xây dựng các khối để tránh xung đột giao dịch. Khi phiên đấu giá kết thúc, một yêu cầu xác nhận trước cho gói chiến thắng sẽ được gửi đến các nhà xây dựng.
5. Thực thi & Xây dựng: Trình xây dựng xác minh cam kết đã ký và đảm bảo khối cuối cùng tuân thủ ràng buộc stateScope bằng cách bao gồm gói đã được xác nhận trước. Sau đó, trình xây dựng có thể giải phóng loại trừ và tiếp tục xây dựng khối.

1.2.2 Ý nghĩa kiến trúc

Kiến trúc này mang lại những lợi thế rõ rệt so với các mô hình hiện có như danh sách bao gồm (ví dụ: EIP-7547) và cho phép thị trường không gian khối chi tiết và linh hoạt hơn. Cụ thể, Cam kết Loại trừ cung cấp cho người tìm kiếm sự đảm bảo trước về khả năng thực thi của gói và cung cấp cho người xây dựng các tiêu chí rõ ràng để tránh xung đột, cho phép nó hoạt động như một cam kết thực thi trên thực tế.

Theo mô hình này, người đề xuất có thể khai báo song song nhiều Cam kết Loại trừ không xung đột, gán một LockId duy nhất cho mỗi stateScope tương ứng. Mỗi khóa được liên kết với một gói riêng biệt, và đối với bất kỳ phạm vi trạng thái nào giống hệt hoặc chồng chéo, chỉ một người chiến thắng được chọn và cấp một xác nhận trước duy nhất.

Cấu trúc này mang lại những lợi ích sau:

• Tập trung vào trạng thái, không tập trung vào giao dịch: Bằng cách tập trung vào phạm vi trạng thái thay vì toàn bộ danh sách giao dịch, người đề xuất mang lại cho các nhà xây dựng sự linh hoạt hơn. Các nhà xây dựng chỉ cần tránh một vùng trạng thái nhỏ hơn, được xác định rõ ràng, cho phép họ tự do tối ưu hóa phần còn lại của khối.
• Đấu giá song song, không xung đột: Người đề xuất có thể chạy nhiều phiên đấu giá đồng thời cho các phạm vi trạng thái không chồng chéo. Điều này cho phép bao gồm nhiều chiến lược MEV độc lập trong một khối duy nhất, tối đa hóa giá trị của nó.
• Cải thiện động lực cho tất cả người tham gia:
  • Người tìm kiếm: Đạt được sự chắc chắn trong việc thực hiện nhanh hơn thời gian chặn, cho phép họ đấu thầu mạnh mẽ hơn và tự tin triển khai các chiến lược đòi hỏi nhiều vốn.
  • Người đề xuất: Tạo ra các nguồn doanh thu mới bằng cách đấu giá quyền truy cập độc quyền của tiểu bang và tối đa hóa phần thưởng khối bằng cách bao gồm an toàn nhiều gói có giá trị cao.
  • Nhà xây dựng: Nhận được các ràng buộc rõ ràng, sớm, cho phép họ tối ưu hóa việc xây dựng khối mà không cần chờ danh sách giao dịch đầy đủ. Điều này giúp tăng cường tính linh hoạt và hiệu quả chiến lược của họ so với các kịch bản có ràng buộc toàn cục.

Về cơ bản, Cam kết Khóa Trạng thái có thể chuyển đổi thị trường không gian khối từ một thị trường đảm bảo bao gồm đơn giản thành một thị trường tương lai tinh vi cho trạng thái Ethereum. Nó cung cấp những đảm bảo cần thiết cho một hệ sinh thái MEV ổn định, hiệu quả và sinh lời hơn.

1.3 Thành phần cơ sở hạ tầng: Gateway và LockEngine

Để triển khai cấu trúc cam kết dựa trên ràng buộc trạng thái này trong cơ sở hạ tầng PBS, chúng tôi đề xuất mở rộng chức năng Commit-Boost hiện có. Cụ thể, chúng tôi mở rộng vai trò của Signer ( người ký), chịu trách nhiệm tạo cam kết của người đề xuất, và Gateway (trung gian điều phối gói), để xử lý các cam kết cấp trạng thái. Tương ứng, một mô-đun phụ trợ mới, LockEngine (khóa) , được giới thiệu ở phía trình xây dựng. Thiết kế này cho phép xử lý nhất quán các xác nhận trước dựa trên ràng buộc trạng thái mà không cần sửa đổi đáng kể cơ sở hạ tầng PBS/MEV-Boost hiện có.

1.3.1 Cổng vào

• Vai trò: Cơ sở hạ tầng chuyển tiếp ngoài chuỗi chuyển tiếp các yêu cầu cam kết của người đề xuất, điều phối sự cạnh tranh giữa các gói và xử lý việc thu thập và phân phối chữ ký thông qua tích hợp với Người ký.
• Chức năng:
  • Nhận và quản lý các gói dựa trên stateScope của chúng.
  • Quản lý xung đột giữa các gói cạnh tranh cho cùng một stateScope .
  • Nhận và phối hợp các gói hàng và giá thầu từ những người tìm kiếm tham gia đấu giá.
  • Chuyển tiếp yêu cầu cam kết và yêu cầu chữ ký của người đề xuất đến Người ký.
  • Truyền đạt kết quả cam kết tới người xây dựng và người tìm kiếm.
• Đặc trưng:
  • Một trung gian ngoài chuỗi hoạt động bên ngoài giao thức PBS cốt lõi và không tương tác trực tiếp với trình xác thực.
  • Có thể được cấu hình như một cơ sở hạ tầng rơle trung tính để hỗ trợ nhiều chiến lược khác nhau.

1.3.2 Người ký

• Vai trò: Một giao thức tạo ra các cam kết dựa trên chữ ký cho các lời hứa loại trừ/bao gồm của bên đề xuất. Giao thức này nhận được quyền ký được ủy quyền từ bên đề xuất thông qua khóa proxy để xử lý việc tạo chữ ký. Mục đích của nó là cho phép cộng tác không cần tin cậy giữa bên đề xuất và bên xây dựng, đồng thời nâng cao tính an toàn và hiệu quả của các giao dịch MEV.
• Chức năng:
  • Xử lý các cam kết trên cơ sở stateScope .
  • Điều phối các chữ ký BLS (cam kết → tiết lộ → quy trình tổng hợp).
  • Cung cấp chức năng ngăn chặn các hành động xác nhận/tiết lộ trùng lặp cho cùng một vị trí.
  • Ngăn chặn các hành động xác nhận/tiết lộ trùng lặp cho cùng một LockId .
• Đặc trưng:
  • Xử lý chữ ký cho các yêu cầu được chuyển tiếp bởi Gateway (mô hình ủy quyền chữ ký của người đề xuất).
  • Nhiều Cổng có thể chia sẻ cùng một phiên bản Signer (tính trung lập).
  • Được lắp đặt như một xe đẩy bên cạnh nút đề xuất, có khả năng chạy song song hoặc tích hợp vào MEV-Boost.

1.3.3 LockEngine (Xe đẩy có thùng)

• Vai trò: Một mô-đun xe đẩy hỗ trợ người xây dựng tuân thủ các ràng buộc stateScope do người đề xuất đặt ra trong quá trình xây dựng khối.
• Chức năng:
  • Xác minh chữ ký cam kết do Người ký phát hành.
  • Phát hiện xung đột cho từng stateScope và lọc các giao dịch cho phù hợp.
  • Chủ động loại bỏ các giao dịch xung đột khỏi mempool của trình xây dựng.
  • Hỗ trợ sắp xếp lại giao dịch và kết hợp lại gói.
• Đặc trưng:
  • Có thể vận hành như một xe đẩy mà không cần sửa đổi logic cốt lõi của người chế tạo.
  • Nhận thông tin cam kết và stateScope từ người đề xuất hoặc Gateway.
  • Đảm bảo tránh xung đột stateScope ở giai đoạn trước khi thực hiện.

1.4 Định nghĩa các thành phần chính

• Người đề xuất
  • Đề xuất các khối trên Beacon Chain.
  • Ủy quyền ký cho Người ký thông qua khóa proxy.
  • Dựa trên các gói tìm kiếm và danh sách truy cập tương ứng ( stateScope ) nhận được từ Gateway, khai báo khóa trên các phạm vi trạng thái không tranh chấp (tức là yêu cầu Cam kết loại trừ + bao gồm).
  • Yêu cầu Người ký ký vào kết quả đấu giá trúng thưởng.
• Cổng vào
  • Nhận các gói từ người tìm kiếm và trích xuất danh sách truy cập của họ ( stateScope ) thông qua mô phỏng EVM.
  • Xác định xung đột giữa các gói truy cập vào cùng một phạm vi trạng thái.
  • Chuyển tiếp tất cả các gói và siêu dữ liệu liên quan đến Relay.
  • Thông báo gói trúng thưởng cho Người đề xuất.
  • Chuyển tiếp yêu cầu ký cam kết của Người đề xuất tới Người ký.
  • Ghi lại và truyền bá tất cả các yêu cầu cam kết và kết quả xử lý của chúng.
• Tiếp sức
  • Nhận tất cả các gói và thông tin đấu thầu từ Gateway.
  • Truyền thông tin về các gói đã chọn đến Gateway và Proposer.
  • Sau khi nộp khối, xác minh xem nhà thầu có thực sự hoàn thành Cam kết của Người đề xuất hay không (ví dụ: bao gồm, nêu rõ tránh xung đột, bao gồm trong chiều cao đã chỉ định).
  • Trong trường hợp không tuân thủ, nó có thể thu thập bằng chứng cắt giảm và chuyển tiếp chúng đến AVS hoặc mạng lưới giám sát.
• Người ký tên
  • Theo yêu cầu của Người đề xuất, ký Cam kết loại trừ/bao gồm theo cách có thể xác minh được cho các nhà thầu xây dựng.
  • Xử lý chữ ký (ví dụ: sử dụng BLS) theo thẩm quyền được ủy quyền của người đề xuất.
• Người xây dựng
  • Xây dựng các khối tuân thủ theo các ràng buộc dựa trên stateScope nhận được thông qua LockEngine.
  • Phải bao gồm gói được chỉ định trong xác nhận trước và không được bao gồm (hoặc phải sắp xếp lại) các giao dịch xung đột với stateScope .
  • Có thể bị phạt như cắt hoặc chặn nếu vi phạm các điều kiện này.
• Khóa động cơ
  • Một mô-đun xe đẩy chạy dọc theo nút xây dựng.
  • Nhận thông tin xác nhận trước và ràng buộc trạng thái ( stateScope , LockId , v.v.) từ Gateway.
  • Giám sát mempool của trình xây dựng để lọc hoặc sắp xếp lại các giao dịch xung đột với stateScope .
  • Hỗ trợ đảm bảo gói đã xác nhận trước được đưa vào khối.
  • Cho phép người xây dựng tuân thủ các ràng buộc của người đề xuất mà không cần sửa đổi logic cốt lõi của nó.
• Người tìm kiếm
  • Xác định các cơ hội MEV ngoài chuỗi, xây dựng các gói và gửi chúng đến Cổng.
  • Không cần phải chỉ định rõ ràng stateScope cho gói của họ; Gateway sẽ tự động trích xuất nó.
  • Cạnh tranh với những người tìm kiếm khác trong cùng phạm vi trạng thái, với gói chiến thắng sẽ nhận được xác nhận trước cuối cùng.
  • Có thể sử dụng các chiến lược đấu thầu tích cực hơn cho các gói đã cam kết do giảm thiểu rủi ro thất bại khi thực hiện.

2. Các tính năng chính

2.1 Khóa trạng thái cục bộ (Cam kết loại trừ)

Trước khi đưa ra xác nhận trước, người đề xuất khai báo một ràng buộc truy cập độc quyền vào phạm vi trạng thái ( stateScope ) mà một gói cụ thể truy cập để đảm bảo việc thực thi của nó. Khai báo này hoạt động như một Cam kết Loại trừ . Nó hoạt động như một cơ chế phòng ngừa để ngăn ngừa xung đột bằng cách yêu cầu người đề xuất đơn phương thông báo cho người xây dựng rằng trạng thái được chỉ định là ngoài giới hạn.

Trong mô hình này, Khóa trạng thái được thiết lập mà không cần đàm phán trước với người xây dựng và được áp dụng theo quy trình sau:

1. Cam kết loại trừ bao gồm các trường sau:
   • LockId
   • stateScope // Một tập hợp các tài khoản dựa trên danh sách truy cập
   • inclusionHeight // Xác định trạng thái theo góc nhìn của người tìm kiếm
   • signature
2. Sau khi phân tích phạm vi trạng thái của một gói nhất định, người đề xuất sẽ khai báo một ràng buộc truy cập độc quyền cho phạm vi đó. stateScope là danh sách địa chỉ các trạng thái được các giao dịch trong gói truy cập.
3. Tuyên bố này được truyền đến tất cả các nhà xây dựng thông qua Gateway.
4. LockEngine (ở phía người xây dựng) nhận được thông báo này và áp dụng nó như một hạn chế truy cập trạng thái cục bộ.
5. Trong khi LockId đang hoạt động, trình xây dựng không được bao gồm bất kỳ giao dịch xung đột nào trong khối của nó.

2.2 Xác nhận trước (Cam kết hòa nhập)

Xác nhận trước là một lời hứa mật mã từ bên đề xuất để đưa một gói cụ thể vào một khối được chỉ định. Nó hoạt động như Cam kết Bao gồm , quyết định kết quả của phiên đấu giá không gian khối. Cam kết này được thực hiện trên cơ sở Cam kết Loại trừ, nghĩa là khả năng thực thi của nó đã được đảm bảo trước.

2.2.1 Quy trình tạo xác nhận trước

1. Người đề xuất sẽ đưa ra xác nhận trước cho gói thầu trúng thầu, sau đó được Người ký ký và chuyển đến nhà thầu xây dựng.
2. Cam kết hòa nhập bao gồm các trường sau:
   • LockId // Phù hợp với khóa từ Cam kết loại trừ
   • bundleTxs
   • inclusionHeight
   • signature

2.2.2 Vai trò và tác động

• Người đề xuất: Có trách nhiệm đưa gói vào inclusionHeight được chỉ định trong Cam kết bao gồm.
• Trình xây dựng: Xây dựng khối dựa trên các ràng buộc từ cả Cam kết loại trừ và Cam kết bao gồm.
• LockEngine: Thực thi kiểm soát quyền truy cập vào phạm vi trạng thái theo Cam kết loại trừ.

Mặc dù Cam kết loại trừ (phòng ngừa xung đột nhà nước) và Cam kết bao gồm (lời hứa bao gồm khối) là các thành phần riêng biệt, nhưng chúng mang lại những hiệu ứng sau khi hoạt động cùng nhau:

• Đối với Người tìm kiếm: Đảm bảo rằng gói dữ liệu họ gửi sẽ được thực thi ở trạng thái cụ thể và sẽ không bị lỗi do xung đột trạng thái.
• Đối với người đề xuất: Cung cấp khuôn khổ để kết hợp các gói không xung đột song song.
• Đối với người xây dựng: Cung cấp tính linh hoạt để xây dựng các khối trước thời hạn mà không cần phải chờ đợi bộ sản phẩm hoàn chỉnh.

2.3 Xử lý ràng buộc của trình xây dựng

Người xây dựng nhận được hai loại ràng buộc từ người đề xuất: một hạn chế truy cập trạng thái cho một stateScope (Cam kết Loại trừ) và một lời hứa bao gồm cho một gói cụ thể (Cam kết Bao gồm, tức là xác nhận trước). Chúng hoạt động như những ràng buộc cấu trúc mà người đề xuất phải tuân thủ để khối được coi là ứng viên hợp lệ. Đây không chỉ là một khuyến nghị đơn thuần mà là một điều kiện bắt buộc. Các cam kết được thực hiện thông qua đường dẫn sau:

Người đề xuất → Cổng → Rơ le → Người xây dựng (thông qua xe đẩy LockEngine)

Relay đảm bảo rằng Cam kết của Người đề xuất được truyền đạt nhất quán đến tất cả các nhà xây dựng trên toàn mạng, ngăn chặn bất kỳ nhà xây dựng nào đơn phương bỏ qua hoặc lách các ràng buộc.

2.3.1 Ràng buộc cam kết của người đề xuất

Người xây dựng phải xây dựng khối của mình theo hai ràng buộc sau:

1. Ràng buộc loại trừ StateScope
   • Người đề xuất tạo một khóa (cam kết) không cho phép xung đột trạng thái đối với một stateScope cụ thể.
   • Gateway nhận khai báo khóa này và truyền nó đến mạng lưới xây dựng thông qua Relay. Mỗi khóa được xác định bằng một LockId duy nhất.
   • Người xây dựng phải xử lý mọi giao dịch truy cập vào phạm vi này theo một trong những cách sau:
     • Không bao gồm nó (loại trừ nghiêm ngặt).
     • Đặt hàng sau khi đã xác nhận đơn hàng để đảm bảo không xảy ra xung đột trạng thái.
2. Ràng buộc bao gồm xác nhận trước
   • Người đề xuất hứa hẹn bằng mật mã (xác nhận trước) rằng một gói cụ thể sẽ được đưa vào ở độ cao khối được chỉ định ( inclusionHeight ).
   • Người xây dựng phải bao gồm gói này ở vị trí đã chỉ định. Nếu không, khối sẽ không hợp lệ theo quan điểm của người đề xuất.

Hai điều kiện này hoạt động song song với nhau. Nếu vi phạm một trong hai điều kiện, bên đề xuất có thể từ chối nhận khối nhà hoặc áp dụng hình phạt cho bên xây dựng.

2.3.2 Thực thi và xác minh ràng buộc

Các rơle và bên xác minh thứ ba (ví dụ: Cổng, AVS) có thể tự mình xác minh xem khối của nhà xây dựng có phản ánh trung thực các Cam kết của Người đề xuất hay không dựa trên các tiêu chí sau. Việc xác minh này giả định rằng thông tin trong cả Cam kết Loại trừ và Cam kết Bao gồm đều công khai và kèm theo chữ ký mã hóa của người đề xuất.

• Xác minh cam kết loại trừ

  • Thông tin cam kết:
    • LockId
    • stateScope
    • inclusionHeight
    • Chữ ký của người đề xuất
  • Quy trình xác minh:
    1. Relay tiếp nhận và lưu trữ Cam kết loại trừ do người đề xuất đưa ra.
    2. Nó mô phỏng hoặc phân tích tĩnh ứng viên khối do trình xây dựng gửi đến để trích xuất tập hợp các trạng thái mà các giao dịch bên trong khối đó truy cập.
    3. Nó kiểm tra xem tập hợp các trạng thái được truy cập đã trích xuất này có giao nhau với stateScope đã cam kết hay không.
       • Đã tìm thấy giao lộ → Vi phạm loại trừ.
       • Không có giao lộ → Đã loại trừ.
  • Bằng chứng vi phạm:
    • Relay có thể tạo ra bằng chứng cắt giảm bằng cách trình bày khối vi phạm cùng với Cam kết loại trừ tương ứng, chứng minh rằng "khối này đã vi phạm stateScope được người đề xuất khóa rõ ràng".

• Xác minh cam kết bao gồm

  • Thông tin cam kết:
    • LockId
    • bundleTxs
    • inclusionHeight
    • Chữ ký của người đề xuất
  • Quy trình xác minh:
    1. Relay kiểm tra chiều cao của khối do người xây dựng gửi so với inclusionHeight .
    2. Nó xác minh rằng có cùng một nhóm giao dịch được bao gồm trong khối.
    3. Nó xác nhận rằng thứ tự bao gồm và vị trí thực hiện đáp ứng các điều kiện được xác định trong cam kết (ví dụ: đặt ở trên cùng, thực hiện sau khi khóa).
       • Không bao gồm hoặc thứ tự không đúng → Vi phạm bao gồm.
       • Đã bao gồm chính xác → Đã bao gồm đầy đủ.
  • Bằng chứng vi phạm:
    • Relay có thể tạo bằng chứng Vi phạm Bao gồm bằng cách trình bày tiêu đề khối và danh sách giao dịch đã gửi làm bằng chứng cho thấy "người xây dựng đã không bao gồm gói đã hứa ở độ cao khối đã chỉ định".

• Cơ chế giải trình

  Quá trình xác minh này có thể được tự động hóa ở cấp độ Relay. Trong trường hợp vi phạm, các hành động sau có thể được thực hiện:

  • Chém (thông qua Đệ trình bằng chứng chém):

    • Bằng chứng vi phạm (Cam kết + tập giao dịch của khối vi phạm) được gửi tới hợp đồng trên chuỗi.
    • Cọc của người xây dựng tương ứng sẽ bị đốt hoặc bị phạt.

  • Loại trừ dựa trên danh tiếng:

    • Mạng Relay/Gateway đánh dấu nhà xây dựng vi phạm là không đáng tin cậy.
    • Sau đó, người đề xuất từ chối cơ hội tạo doanh thu cho nhà thầu đó.

  • Các con đường mở rộng trong tương lai, chẳng hạn như chứng thực TEE và xác minh dựa trên bằng chứng ZK, cũng có thể được xem xét.

    Phương pháp xác minh	Sự miêu tả
    Dựa trên TEE	Sử dụng chứng thực từ xa cho các khối được tạo trong môi trường thực thi đáng tin cậy (TEE) như SGX.
    Dựa trên ZK	Tạo Bằng chứng không kiến thức cho thứ tự giao dịch và đường dẫn thực hiện trong stateScope để được xác minh bởi Gateway/AVS.

3. Đấu giá song song trên Commit-Boost

3.1 Sơ đồ trình tự

Parallel_Auction_on_Commit-Boost 1920×2123 107 KB

3.2 Quy trình

1. Khởi tạo đấu giá

• Gateway tuyên bố bắt đầu phiên đấu giá cho một vị trí cụ thể (ví dụ: slot N )
• Phát sóng StartAuction(slot N) tới tất cả những người tìm kiếm tham gia

1. Gửi gói và định nghĩa StateScope

• Searcher1 → Gateway : gửi một gói chứa:
  • txList1
  • bid1
  • inclusionHeight
• Gateway :
  • Mô phỏng gói và trích xuất AccessList
  • Trích xuất stateScope tương ứng
  • Tạo một LockId duy nhất cho gói

1. Yêu cầu cam kết loại trừ và ký kết

• Gateway → Signer : RequestSig(LockId, stateScope)
• Signer :
  • Dấu hiệu của ExclusionCommitment
  • Trả về ExclusionSig
• Gateway → LockEngine : gửi ExclusionCommitment
• LockEngine :
  • Xác minh cam kết
  • Chuẩn bị cho việc lọc giao dịch dựa trên stateScope

1. Phát sóng và lọc StateScope

• Gateway :
  • Phát sóng stateScope tới tất cả Searchers
  • Ngăn chặn các giá thầu chồng chéo và khuyến khích sự khác biệt về chiến lược
• LockEngine :
  • Lọc các giao dịch mempool xung đột với stateScope bị khóa
  • Cung cấp danh sách các giao dịch không xung đột đã được lọc cho Builder
• LockEngine → Builder : DeliverFilteredTxList
• Builder : bắt đầu xây dựng khối dựa trên các giao dịch đã lọc

1. Đấu thầu bổ sung và hoàn tất đấu giá

• Searcher2 → Gateway : gửi một gói khác
  • Bao gồm:
    • txList2
    • bid2
    • inclusionHeight
• Gateway
  • So sánh giá thầu và chọn gói chiến thắng (ví dụ: Searcher2 )
  • Khai báo EndAuction và thông báo kết quả

1. Phát hành cam kết hòa nhập

• Gateway → Signer : RequestSig(bundleHash, inclusionHeight)
• Signer :
  • Ký cam InclusionCommitment (xác nhận trước)
  • Trả về InclusionSig
• Gateway → LockEngine : gửi Cam kết Bao gồm đã ký

1. Xây dựng khối cuối cùng

• LockEngine :
  • Xác minh InclusionSig
• LockEngine → Builder : Send(txList2)
• Builder :
  • Xây dựng khối bao gồm danh sách giao dịch đã cho
  • Đảm bảo gói được bao gồm ở inclusionHeight đã chỉ định

1. Bằng chứng về việc gửi và bao gồm khối

• Builder → Proposer : nộp khối đã hoàn thiện
• Builder → Gateway : gửi InclusionProof(bundle)
• Gateway → Relay : chuyển tiếp InclusionProof(bundle)
• Relay :
  • Xác minh việc thực hiện cam kết.
  • Nếu cần thiết, truyền bá bằng chứng đến AVS hoặc cơ sở hạ tầng giám sát khác

4. Xử lý các điều kiện và xung đột về chủng tộc

4.1 Quy tắc xung đột xác nhận trước

• Chỉ có thể cấp một xác nhận trước hợp lệ cho cùng một stateScope .
  • Mỗi LockId chỉ được gán cho một người tìm kiếm chiến thắng.
  • Vào thời điểm đấu giá, Gateway sẽ xác định xem có xung đột trạng thái hay không và chỉ chọn một người chiến thắng từ các gói cạnh tranh cho cùng một stateScope .
• Nếu stateScope truy cập các trạng thái không liên quan lẫn nhau, các xác nhận trước có thể được đưa ra song song.
  • Gateway có thể chạy đấu giá cho nhiều LockId song song.
  • Trình xây dựng, thông qua LockEngine, quản lý nhiều LockId song song, phối hợp các gói để cùng tồn tại trong khối mà không bị nhiễu.

4.2 Tiêu chí phát hiện xung đột và vị trí

• Tiêu chí xung đột:
  • Xung đột được xác định nếu hai gói truy cập vào một trạng thái ( stateScope ) có chứa cùng một địa chỉ hợp đồng hoặc mục cấp khe.
  • stateScope có thể được định nghĩa ở cấp độ hợp đồng hoặc cấp độ khe cắm; có sự đánh đổi giữa độ phức tạp của việc triển khai và mức độ song song có thể đạt được.
• Vị trí phát hiện xung đột:
  • Cổng: Mô phỏng các gói tìm kiếm và trích xuất danh sách truy cập của chúng.
  • LockEngine: Thực hiện lọc theo thời gian thực trên mempool của trình xây dựng để loại bỏ hoặc sắp xếp lại các giao dịch xung đột trước.

4.3 Cam kết không thành công và hình phạt

Người xây dựng có thể phải đối mặt với hình phạt chém hoặc các hình phạt khác nếu vi phạm bất kỳ điều kiện nào sau đây:

• Không bao gồm gói chiến thắng ở inclusionHeight đã chỉ định.
• Khiến gói bị lỗi bằng cách bao gồm một giao dịch khác truy cập vào cùng một stateScope trước gói đã được xác nhận trước.
• Bỏ qua hoặc thao túng thông tin đã ký từ xác nhận trước khi xây dựng khối.
• Nộp bản chứng minh và cắt bỏ:
  • Cổng hoặc người tìm kiếm có thể gửi khối có liên quan và Cam kết tương ứng (Loại trừ/Bao gồm) tới AVS hoặc mô-đun xác minh trên chuỗi.
  • Có thể sử dụng InclusionProof (ví dụ: bằng chứng Merkle) hoặc dữ liệu khối đầy đủ làm bằng chứng.
• Xử lý ngoại lệ:
  • Nếu Cam kết Bao gồm không được ban hành sau Cam kết Loại trừ:
    • LockEngine (trình xây dựng) có thể tự động mở khóa sau một khoảng thời gian nhất định.
    • Cần phải thiết lập thời gian khóa tối đa (ví dụ: trong vòng 8 giây).
    • Người xây dựng có thể tiến hành xây dựng theo khối, loại trừ giao dịch có liên quan.
  • Trong trường hợp việc đưa vào không hợp lệ do các sự kiện như tổ chức lại chuỗi, cần phải phân biệt giữa lỗi của bên đề xuất và lỗi của bên xây dựng.

5. Triển khai bằng chứng khái niệm (PoC)

Giao thức này không chỉ là một đề xuất lý thuyết; chúng tôi đã tiến hành một thử nghiệm Proof-of-Concept (PoC) thực tế bằng cách mở rộng kiến trúc Commit-Boost dưới dạng giao thức Local State Lock. Thiết kế tập trung vào việc tái sử dụng tối đa cơ sở hạ tầng PBS hiện có và thiết kế Commit-Boost, đồng thời bổ sung các chức năng mới.

5.1 Phạm vi thực hiện

PoC đã triển khai hai quy trình cam kết chính sau đây trong mã:

1. Cam kết loại trừ
   • Đã xác định stateScope cho một gói được người tìm kiếm gửi đến.
   • Người đề xuất đã tạo ra thông báo “phòng ngừa xung đột” dựa trên stateScope này và gửi đến tất cả người xây dựng.
   • LockEngine của trình xây dựng đã nhận được thông tin này, lọc các giao dịch xung đột khỏi mempool và cập nhật trạng thái cục bộ của nó.
2. Cam kết hòa nhập
   • Người đề xuất đã xác định người chiến thắng thông qua phiên đấu stateScope .
   • Người chiến thắng (người tìm kiếm) đã nhận được xác nhận trước, bao gồm LockId , bundleHash , inclusionHeight , v.v.
   • Tài liệu này được ký thông qua mô-đun Người ký và chuyển đến người xây dựng.

5.2 Luồng hoạt động (PoC)

Luồng thực thi đầu cuối được triển khai trong PoC như sau:

1. Người tìm kiếm → Cổng: Gửi một gói và cung cấp thông số kỹ thuật stateScope của gói đó.
2. Gateway → Proposer: Thu thập một tập hợp các gói và xác định xung đột. Đối với các stateScope rời rạc, nó chạy các phiên đấu giá song song.
3. Người đề xuất → Người xây dựng: Phát đi Cam kết loại trừ. Phát hành Cam kết bao gồm cho gói trúng thưởng.
4. Builder (LockEngine): Thực thi Cam kết Loại trừ bằng cách loại trừ các giao dịch xung đột. Thực thi Cam kết Bao gồm bằng cách đưa gói vào khe được chỉ định.

5.3 Kết quả thực nghiệm chính

• Đảm bảo thực hiện có thể dự đoán được:
  • Các gói Searcher được thực thi mà không có xung đột từ các gói cạnh tranh truy cập cùng một trạng thái, vì khóa được áp dụng ở cấp độ stateScope .
• Xác nhận tính khả thi của đấu giá song song:
  • Chúng tôi đã xác nhận rằng nhiều gói có thể nhận được xác nhận trước cùng lúc khi stateScope của chúng không giao nhau.
• Dễ dàng tích hợp Builder:
  • Bằng cách triển khai LockEngine như một sidecar, chúng tôi đã xác minh rằng các ràng buộc cam kết có thể được áp dụng mà không cần sửa đổi đáng kể đối với logic xây dựng hiện có.

5.4 Hạn chế và công việc trong tương lai

• PoC được triển khai tập trung vào mức độ chi tiết ở cấp độ hợp đồng thay vì khóa ở cấp độ khe cắm.
• Một số trường hợp ngoại lệ, chẳng hạn như các tình huống tổ chức lại, xử lý thời gian chờ khóa và gửi bằng chứng cắt giảm, vẫn chưa được triển khai.
• Công việc trong tương lai sẽ yêu cầu tích hợp xác minh khối dựa trên TEE/ZK và xác định stateScope chi tiết hơn.

Tài liệu tham khảo

https://github.com/radiusxyz/parallel-auction-commit-boost
https://ethresear.ch/t/state-lock-auctions-towards-collaborative-block-building/18558
https://ethresear.ch/t/commit-boost-proposer-platform-to-safely-make-commitments/20107
https://eips.ethereum.org/EIPS/eip-2930
https://eips.ethereum.org/EIPS/eip-7547