Đấu giá State Lock: Hướng tới xây dựng khối hợp tác

Rất cám ơn Quintus , Louis và Shea vì những cuộc thảo luận và nhận xét đã truyền cảm hứng cho bài đăng này.

BJ506v_E2.jpg 1024×1024 266 KB

Tổng quan

Do tính chất công khai theo giá đầu tiên của cuộc đấu giá tăng MEV , người tìm kiếm đã được khuyến khích tích hợp theo chiều dọc, trở thành “người xây dựng tìm kiếm” để đặt giá thầu “chiến lược hơn”. Sự phân chia theo chiều dọc này nhằm đạt được lợi thế trong cuộc đấu giá MEV-Boost đã gây ra hậu quả đáng tiếc là làm tăng đáng kể các rào cản gia nhập đối với hoạt động chênh lệch giá thống kê và theo đó, đã tạo ra một cấu trúc thị trường không thuận lợi, nơi các “nhà xây dựng-người tìm kiếm” mới xuất hiện. Luồng đơn đặt hàng mua số lượng lớn từ các nhà xây dựng khác và trợ cấp các khối như một “chi tiêu quảng cáo” hiệu quả để đạt được sự ngang bằng về quy trình đặt hàng với các nhà xây dựng khối đương nhiệm. Những nỗ lực nhằm loại bỏ lợi thế này khỏi “đấu thầu chiến lược” chủ yếu tập trung vào việc sửa đổi cuộc đấu giá thành hình thức đấu thầu kín , tất cả đều thất bại khi chúng đưa ra các vectơ thông đồng mới khi không có công nghệ cam kết riêng tư và đáng tin cậy như MPC, FHE và TEE.

Vay mượn rất nhiều từ tài liệu về hệ thống phân tán, bài đăng này phác thảo một đề xuất cho phép khả năng “khóa trạng thái” trong phiên đấu giá tăng cường mev, với tính năng tiếp theo là cung cấp khả năng hiển thị về “trạng thái bị khóa” này. Kết quả cuối cùng của cách tiếp cận này là các nhà xây dựng khối không còn bị “ dừng hoạt động đường ống ” một cách hiệu quả do sự không chắc chắn trong việc xây dựng phần còn lại của khối, điều này mở ra cơ hội cho “Xây dựng khối hợp tác”. Theo thuật ngữ hệ thống phân tán, chúng tôi đang tạo ra một hệ thống kiểm soát đồng thời nhiều phiên bản phi tập trung “ boot leg ” cho máy trạng thái phân tán ethereum bằng cách tận dụng khả năng hiển thị .

Ưu điểm chính của phương pháp này là nó duy trì quyền riêng tư cơ bản và khả năng cập nhật giá thầu cho những người tìm kiếm cạnh tranh trong các hoạt động chênh lệch giá tốc độ cao này, hỗ trợ hoạt động chênh lệch giá chung hơn so với các phương pháp tiếp cận “theo làn” trước đây và có thể dễ dàng triển khai vào thị trường hiện tại. Hạn chế chính là việc nó tạo ra một “sự lưu trữ giả” của các giao dịch chênh lệch giá đơn lẻ ở đầu khối và đưa ra một phương thức kiểm duyệt mới và vectơ đau buồn. Vì đề xuất này chỉ là bản phác thảo nên vẫn còn nhiều ẩn số xung quanh cách định giá chi phí để khóa trạng thái một cách hiệu quả, ảnh hưởng đến chiến lược đặt giá thầu của người tìm kiếm và cách khái quát hóa cuộc đấu giá ngoài khả năng khóa một nhóm trạng thái duy nhất.

Thuộc tính mong muốn cho cuộc đấu giá khóa trạng thái

Mặc dù chưa đầy đủ, nhưng một số đặc tính thuận lợi có thể thấy rõ ngay lập tức:

1. An toàn tủ khóa - Tiết lộ địa chỉ của người đã khóa trạng thái trước khi việc chặn được xác nhận sẽ tạo ra một vectơ DoS được nhắm mục tiêu.
2. Khả năng cập nhật giá thầu - Người tìm kiếm cam kết khóa trạng thái sẽ có thể cập nhật các tham số giao dịch của họ miễn là nó không sửa đổi danh sách truy cập trạng thái.
3. Hiển thị trạng thái bị khóa - Các khe lưu trữ ở trạng thái bị khóa phải được hiển thị công khai cho người xây dựng khối.
4. Thanh toán khóa được đảm bảo - Cho dù người tìm kiếm có cập nhật giá thầu hay không, giao dịch thanh toán phải được đưa vào khối để có trạng thái khóa.
5. Khả năng chống ngồi xổm - Đảm bảo chi phí để khóa một lượng lớn trạng thái là cực kỳ cao để ngăn chặn sự đau buồn.
6. Nhận thức về sự tranh chấp - Giá của sự thiếu hụt sẽ phản ánh số tiền lãi bằng văn bản gửi đến trạng thái đó.

Danh sách truy cập

Trong phần lớn bài đăng này, chúng tôi đề cập đến trạng thái bị khóa dưới dạng “danh sách truy cập”. Trong ngữ cảnh của EIP-2930 , danh sách truy cập trạng thái A A được định nghĩa là một chuỗi các bộ dữ liệu:

Ở đâu:

• Địa chỉ \text{address} là địa chỉ Ethereum của hợp đồng hoặc Tài khoản thuộc sở hữu bên ngoài (EOA) mà giao dịch tương tác.
• [\text{storageKey__1, \text{storageKey__2, \ldots] [ storageKey 1 , storageKey 2 , … ] đại diện cho danh sách các khóa lưu trữ trong kho lưu trữ của hợp đồng được chỉ định mà giao dịch sẽ truy cập.

Một danh sách truy cập ví dụ cho một trao đổi được hiển thị trong Phụ lục A.

Đề xuất: Đấu giá khóa đơn chạy tiếp sức

Đại diện cho người tìm kiếm là S S , người chuyển tiếp là R R và người xây dựng khối một phần là PB P B , quá trình đấu giá diễn ra như sau:

1. Đấu giá mở :

• Trước thời điểm giới hạn T_{cutoff} T c u t of f giây vào vị trí, người tìm kiếm gửi cam kết khóa trạng thái của họ tới R R với hai giao dịch riêng biệt:

  \text{SubmitStateCommitment}(n, A, tx_{state}, tx_{thanh toán}, b)
  SubmitStateCommitment ( n , A , t x s ta t e , t x p a y m e n t , b ) _

  Ở đâu

  • n n : Số vị trí.
  • A A : Danh sách truy cập.
  • tx_{state} t x s t a t e : Giao dịch truy cập trạng thái.
  • tx_{Payment} t x p a y m e n t : Giao dịch thanh toán đảm bảo chi phí khóa được bao trả.
  • b b : Giá trị dự thầu,

  và sau khi nộp R R xác nhận:

  • b b phải đáp ứng hoặc vượt quá chi phí dự trữ khóa dựa trên A A .
    • Chi phí dự trữ khóa được xác định bởi:
  \text{LockCost}(A) = C \times |A|
  Giá Khóa ( A ) = C × | A |

  Ở đâu:

  • C C thể hiện chi phí cố định trên mỗi khe lưu trữ và |A| | A | là số lượng vị trí lưu trữ trong danh sách truy cập A A cho tx_{state} t x s t a t e . Cách tiếp cận này làm cho việc khóa một lượng lớn trạng thái trở nên tốn kém hơn nhưng lại không phải là một quy tắc định giá lý tưởng.
  • • tx_{state} t x s t a t e phải là một giao dịch có danh sách truy cập bằng A A .
  • • tx_{thanh toán} t x p a y m e n t phải là một giao dịch thanh toán cho người xác thực từ EOA không có dữ liệu cuộc gọi.
  • • ( tx_{state} t x s t a t e , tx_{thanh toán} t x p a y m e n t ) được mô phỏng cùng nhau ở đầu khối thanh toán số tiền mà b b đã hứa .

1. Lựa chọn người chiến thắng :

• Tại T_{cutoff} T c u to f f , R R chọn giá thầu cao nhất:
  b_{max} = \max(\{b_i | b_i \geq \text{LockCost}(A_i), \forall i \in S\})
  b m a x = max ( { b i | b i ≥ LockCost ( A i ) , ∀ i ∈ S } )
  • R R sau đó tiết lộ danh sách truy cập trúng thưởng A_{max} A m a x được liên kết với b_{max} b m a x cho bất kỳ ai gọi:

1. Cập nhật giá thầu và gửi khối một phần :
   Hai hoạt động chính có thể diễn ra sau khi lựa chọn người chiến thắng:

• Người tìm kiếm chiến thắng addr_{max} a d d r m a x có thể cập nhật giao dịch truy cập trạng thái của họ được hỗ trợ thông qua:

  \text{UpdateStateCommitment}(n, addr_{max}, A_{max}, tx_{state\_new}, b_{new})
  UpdateStateCommitment ( n , a d r m a x , A m a x , t x s t a t e _ n e w , b n e w ) _

  Ở đâu:

  • n n phải bằng vị trí gần đây nhất được liên kết với giá thầu trúng thầu từ addr_{max} a d d r m a x
  • R R phải xác thực rằng giao dịch truy cập trạng thái được cập nhật tx_{state\_new} t x s t a t e _ n e w có danh sách truy cập tương đương với A_{max} A m a x .
  • và giao dịch thanh toán tx_{thanh toán} t x p a y m e n ngầm không thay đổi.

• Người xây dựng khối một phần truy vấn GetLockedState(n) G e t L o c k e d S t a t e ( n ) cho A_{max} A m a x , xây dựng các khối một phần dựa trên thông tin này và gửi chúng bằng cách sử dụng:

  \text{SubmitPartialPayload}(TX_{list}, b_{PB})
  SubmitPartialPayload ( T X l i s t , b P B )

  Ở đâu:

  • TX_{list} T X l i s t bao gồm danh sách các giao dịch
  • b_{PB} b P B đại diện cho giá thầu cho khối một phần.

  và khi nhận được một phần tải trọng, rơle ( R R ) sẽ thực hiện các bước sau:

  • 1. Kết hợp giao dịch : R R tạo
  \text{CollabBlock = }(tx_{state}, tx_{thanh toán},TX_{list})
  CollabBlock = ( t x s t a t e , t x p a y m e n t , T X l i s t )
  • 2. Xác thực khối : R R mô phỏng CollabBlock C o l a b B l o c k để thực hiện xác thực khối thông thường cũng như đảm bảo giá trị giá thầu khối kết hợp bằng b_{max} + b_{PB} b m a x + b P B .
  • 3. Xử lý thanh toán : R R tạo, ký và chèn giao dịch thanh toán để thanh toán cho người xác thực và người xây dựng khối một phần
  • 4. Tính toán gốc trạng thái : Nếu xác thực thành công, R R tính toán gốc trạng thái của khối và các trường liên quan để đảm bảo khả năng tương thích với thông số kỹ thuật EL và CL mới nhất, chèn vào khối đèn hiệu với các thuộc tính tải trọng mới nhất và sẵn sàng cho các cuộc gọi getHeader từ người xác nhận.

Dưới đây là sự thể hiện của một nghệ sĩ về quá trình đấu giá trên.

Ảnh chụp màn hình 2024-02-03 lúc 3.58.51 chiều 1850×1312 253 KB

Có thể xem bản phác thảo sơ bộ về những thay đổi đối với thông số kỹ thuật của rơle trong Phụ lục B.

Phân tích

Cách tiếp cận này đáp ứng hầu hết các mục tiêu cốt lõi của chúng tôi đối với hệ thống khóa trạng thái: đảm bảo An toàn cho tủ khóa , Khả năng cập nhật giá thầu , Khả năng hiển thị trạng thái bị khóa và Thanh toán khóa được đảm bảo , tạo bước đột phá ban đầu ở Khả năng chống chiếm đoạt và không cố gắng nhận biết sự tranh chấp . Hơn nữa, Khả năng hiển thị trạng thái bị khóa đặt nền tảng cho việc xây dựng khối hợp tác bằng cách cho phép các nhà xây dựng thêm các khối một phần vào các giao dịch chênh lệch giá hàng đầu một cách tự tin hơn. Thiết kế có chủ ý tránh kiểm tra các giao dịch xung đột trong khi Gửi một phần phần tải trọng thanh toán để tránh chặn bất kỳ giao dịch nào khác cũng có ý định chạm vào trạng thái khóa gây tranh cãi. Các nhà xây dựng BBlock được tự do gửi các khối có xung đột, nhưng giờ đây họ đã biết trước về xung đột, đây là một cải tiến so với thị trường ngày nay và tạo ra động lực để tham gia. Người tìm kiếm cũng được khuyến khích tham gia vì nó giúp việc truy cập vào stat arb dễ dàng hơn và tăng khả năng đưa vào khối. Rơle đảm nhận thêm công việc và do đó, tăng thêm chi phí, nhưng cách tiếp cận này bình thường hóa khả năng kiếm lợi nhuận thông qua cuộc đấu giá ở mức giá thứ hai giữa các rơle theo hình thức khuyến khích vòng vo.

Một lĩnh vực cần quan tâm là chuyển sang xây dựng khối lấy rơle làm trung tâm hơn và bình thường hóa các công cụ xây dựng rơle . Phản ứng ban đầu thiên vị và thận trọng của tôi là chúng ta sẽ ổn với xu hướng này miễn là nó không tạo ra ý kiến về việc khối nào được xây dựng hoặc mang lại lợi thế bất bình đẳng cho bên này so với bên kia. Từ POV này, rơle sẽ tiếp tục chứa nhiều logic liên quan đến đấu giá hơn với tư cách là bên thứ ba đáng tin cậy trong mạng lưới các nhà xây dựng, mỗi phần logic bổ sung sẽ giúp thúc đẩy việc xây dựng khối hợp tác nhiều hơn.

Cách tiếp cận này không yêu cầu thay đổi giao thức và có thể chạy song song với phiên đấu giá mev-boost hiện tại. Ngoài ra, nó tạo ra một cách tiếp cận “theo làn” mà không giới hạn nó ở một loại chênh lệch giá duy nhất, nhưng không được khái quát hóa đầy đủ vì nó hạn chế các hoạt động chênh lệch giá hàng đầu trong một giao dịch. Do đó, việc khám phá hỗ trợ gói là một khám phá lý tưởng trong tương lai, nhưng nếu được thực hiện một cách ngây thơ, có thể tạo ra những rắc rối bổ sung thông qua một con đường mới để gửi toàn bộ khối.

Tuy nhiên, có một số điều phức tạp khi áp dụng phương pháp này trực tiếp. Một là nó gặp phải vấn đề khởi động nguội. Nếu khi ra mắt, chỉ một người tìm kiếm đã phát triển khả năng cạnh tranh trong phiên đấu giá này, thì họ có thể sẽ chiếm ưu thế trong một thời gian ngắn và rất rẻ, tùy thuộc vào giá vốn dự trữ của khóa. Điểm kép của điều này là chỉ cần sự tham gia của một người tìm kiếm để ném tuyết vào phần còn lại. Một lĩnh vực khác cần cải tiến là thiết kế này chỉ tập trung vào trường hợp rơle đơn, nhưng trên thực tế, có rất nhiều rơle hoạt động độc lập. Một ý kiến cho rằng có thể việc đồng bộ hóa không thành vấn đề vì việc hủy giá thầu là một vấn đề chuyển tiếp chéo tương tự không được đảm bảo . Trong kịch bản đa rơle, trường hợp tốt nhất là mỗi người đồng ý về trạng thái bị khóa. Trong trường hợp xấu nhất, mỗi đường dẫn có một tập trạng thái khác nhau và các trình tạo khối một phần xây dựng cho tất cả các đường dẫn tiềm năng. Điều này tạo ra nhiều công việc hơn, nhưng ít nhất, nó có thể song song hóa và vẫn là một sự cải thiện đáng kể so với hiện trạng. Một lĩnh vực khác cần khám phá trong tương lai là cách tiếp cận này hoạt động với chuyển tiếp lạc quan do logic xác thực phức tạp hơn của nó.

Cuối cùng, những ẩn số quan trọng nhất ở đây là cơ chế định giá khóa và ảnh hưởng của cam kết nhà nước đối với chiến lược của người tìm kiếm. Cơ chế định giá khóa rất không được xác định và rất có thể là nơi mà mọi thứ có thể trở nên sai lầm một cách hài hước; do đó, công việc tiếp theo nên cố gắng giải thích vấn đề này một cách có tính phân tích và đối nghịch. Việc kết hợp quyền truy cập trạng thái lịch sử vào cơ chế định giá cũng khó khăn vì đó là một vectơ cực lớn để cập nhật nếu được thực hiện một cách ngây thơ và không thể cắm vào khối như phí cơ bản dựa vào. Tiến trình tìm ra cơ chế này cũng sẽ giúp đánh giá mức độ kiểm duyệt của cuộc đấu giá này và đưa ra các biện pháp khuyến khích cụ thể hơn. Tác động của việc tạo ra chi phí trả trước mới để thực hiện kinh doanh chênh lệch giá thống kê cũng cần được xem xét kỹ lưỡng, nhưng trong trường hợp xấu nhất, người tìm kiếm có thể hủy giao dịch của họ một cách hiệu quả và chỉ cần trả phí mà không yêu cầu họ phải cam kết giao dịch số lượng lớn ở mức giá mà họ không còn thấy hấp dẫn dựa trên tín hiệu trên các tên miền khác.

Tiện ích bổ sung

• Thời gian đóng ngẫu nhiên có thể được sử dụng để ngăn cản việc đặt giá thầu vào giây cuối cùng. Nhưng trong trường hợp chuyển tiếp nhiều độc lập, điều này phải trả giá bằng việc tạo ra những người chiến thắng khác nhau cho mỗi chuyển tiếp.
• Cuộc đấu giá khóa cấp bang có thể sử dụng quy tắc giá thứ hai để xác định khoản thanh toán, khuyến khích đấu thầu trung thực. Điều này có thể đạt được bằng cách chèn một giao dịch hoàn lại tiền chênh lệch vào khối, với chi phí là 21k gas.
• Các loại giao dịch EIP-2930 có thể được sử dụng cho giao dịch truy cập trạng thái, nhưng chúng hỗ trợ quyền truy cập vào các khe lưu trữ được cung cấp không có danh sách truy cập nên sẽ không tạo ra sự tin cậy mù quáng. Nhìn chung, việc đi theo hướng này sẽ giúp hợp lý hóa mọi nỗ lực xây dựng hợp tác trong tương lai.
• Cấu trúc khối trong rơle cung cấp thời gian lý tưởng để cắm vào danh sách bao gồm vô điều kiện .
• Để ngỏ giá thầu để thay thế giao dịch truy cập trạng thái bằng giao dịch của bạn miễn là nó chạm vào trạng thái giống như trạng thái ban đầu. Những khuyến khích xung quanh vấn đề này có một chút không rõ ràng.
• Cho phép đấu giá song song trên mỗi danh sách truy cập chồng chéo.
  • Một thách thức ở đây là danh sách truy cập đại diện cho việc chênh lệch hai nhóm có thể được chia thành hai phiên đấu giá để chênh lệch giá cho mỗi nhóm và chi phí khóa từng nhóm riêng lẻ có thể không cao bằng việc ai đó cố gắng khóa cả hai nhóm cùng một lúc. Do đó, việc khái quát hóa đòi hỏi một số hình thức đấu giá kết hợp cho phép bạn đặt giá thầu có điều kiện để thắng một cuộc đấu giá khác.
    • Tarun đã trình bày về cách Đấu giá MEV của Jito Solana hoạt động theo cách tương tự ở đây .
  • Một thách thức khác là trong trường hợp đấu giá đơn lẻ, trạm chuyển tiếp có thể chắc chắn rằng giao dịch thắng sẽ tạo ra một danh sách truy cập nhất định. Trong trường hợp đấu giá kép, chúng ta không còn có thể chắc chắn về danh sách truy cập của giao dịch thứ 2 chỉ bằng cách xem danh sách truy cập của giao dịch đầu tiên. Điều này được minh họa bằng giao dịch thứ 2, giao dịch này phụ thuộc vào số dư được sửa đổi trong giao dịch 1. Mặc dù chúng tôi có thể phát hiện khả năng xảy ra xung đột đọc-ghi như vậy nhưng rất có thể nó không đủ cơ sở ổn định để liên tục sắp xếp các phiên đấu giá này trên trên cùng của. Rơle có thể mô phỏng giao dịch thứ 2 dựa trên người chiến thắng trong phiên đấu giá đầu tiên, nhưng điều này không cho chúng tôi đủ thời gian trong khối để thực hiện nhiều phiên đấu giá. Rất có thể, một số hạn chế về khả năng ghi và đọc trạng thái của giao dịch sẽ cần được áp dụng để khắc phục điều này.

Tính khả thi với ePBS

Thách thức đối với việc tích hợp phương pháp này với thứ gì đó giống như “ePBS” trong tương lai là chúng ta sẽ cần chuyển phiên đấu giá sang lớp chứng thực, vốn đòi hỏi một khoảng thời gian đồng bộ bổ sung. Mạng phải đi đến thống nhất về “danh sách truy cập chiến thắng” là gì, chưa kể đến các trò chơi p2p mà điều này khuyến khích ở lớp giao thức.

Một lý do chống lại việc chuyển loại thứ này vào giao thức là vì nó không ảnh hưởng đến tài nguyên trên mạng theo quan điểm của người xác thực, ít nhiều khóa sẽ không ảnh hưởng đến các yêu cầu tài nguyên cần thiết để thực hiện nhiệm vụ của người xác thực. Ngoài ra, các cuộc đấu giá khóa không gây ra rủi ro hoạt động cho mạng. Nếu cuộc đấu giá kết thúc, chúng tôi sẽ quay trở lại trạng thái xây dựng khối hiện tại. Một lập luận ủng hộ việc chuyển nó vào giao thức là cuộc đấu giá tạo ra doanh thu từ trạng thái của giao thức.

Phần kết luận

Đề xuất này phác thảo một thiết kế cho một cơ chế tương đối thô sơ để bán đấu giá khóa trạng thái hàng đầu trên Ethereum và cho phép cộng tác trong thị trường xây dựng khối. Mặc dù không phải là giải pháp kết thúc trò chơi nhưng nó tạo ra một giao diện lý tưởng để thử nghiệm các khóa trạng thái và mở khóa các khía cạnh mới của thị trường xây dựng khối, điều này có thể giúp chúng tôi thoát khỏi mức tối đa cục bộ hiện tại. Giả sử một cơ chế định giá khóa lý tưởng, cách tiếp cận này có thể nhanh chóng được triển khai và đưa chúng ta tiến một bước tới cấu trúc thị trường xây dựng tốt hơn.

ruột thừa

A. Danh sách truy cập mẫu

Danh sách truy cập mẫu cho

• hàm băm tx 0x84ba67793c7aa0140ae9f7cbc58a7bec04099672d467dfe280ec5987b5f26b46 hoán đổi Wrapped Ether cho Porktoshi Nakamoto .

Được tạo thông qua Được tạo thông qua các tập lệnh python này.

 [ { "address" : "0xa65303cbe1186f58dda9cf96b29e1e89ae90b165" , "storageKeys" : [ "0x0000000000000000000000000000000000000000000000000000000000000008" ] } , { "address" : "0xb39bc86ac75118011f646276fca48d56e54c4854" , "storageKeys" : [ "0x000000000000000000000000000000000000000000000000000000000000000d" , "0x7e3bb96fe9c3e8bf8baff39136a5e5778a1f21be90df3270983ce535ed884516" , "0x9db3014a7ecc5c8baca43505a03b4e7e24c2ec389a973d5605a299f04defc730" ] } , { "address" : "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2" , "storageKeys" : [ "0x377eec8667584e30e85471441b46e69393e5f35d2b63a0b4c26a5b1f6d059aa5" ] } ]

Đây
- 0xC02aaA...3C756Cc2 là hợp đồng mã thông báo WETH
- 0xb39BC8...e54C4854 là hợp đồng mã thông báo PORKTOSHI
- 0xA65303...AE90B165 là bể bơi PORKTOSHI/WETH Uni V2
Dựa trên các khóa lưu trữ cho hợp đồng PORKTOSHI, chúng ta có thể thấy có một số hành vi ERC20 không chuẩn vàmã nguồn xác minh điều đó nhưng không đúng.

B. Thay đổi thông số kỹ thuật rơ-le thô

Các quy tắc xác thực và logic nội bộ được giải thích trong các phần trước.

1. relay_SubmitStateCommitment

Cho phép người tham gia gửi cam kết cấp bang cho một vị trí cụ thể.

• Chấp nhận:

  • n (Số vị trí): Số nguyên biểu thị số vị trí.
  • A (Danh sách truy cập): Mảng đối tượng nêu chi tiết các khóa trạng thái ( address và storageKeys ) mà một giao dịch dự định tương tác.
  • statetx (Giao dịch đã ký): Chuỗi thập lục phân của giao dịch đã ký.
  • paymenttx (Giao dịch đã ký): Chuỗi thập lục phân của giao dịch đã ký.
  • b (Giá trị giá thầu): Số nguyên biểu thị giá trị giá thầu tính bằng wei.

• Trả về: Xác nhận gửi.

2. relay_GetLockedState

Tìm nạp danh sách truy cập được liên kết với giá thầu trúng thầu cho vị trí được chỉ định.

• Chấp nhận:

  • n (Số vị trí): Số nguyên biểu thị số vị trí mà danh sách truy cập được yêu cầu.

• Trả về:

  • Danh sách truy cập ( A ): Mảng đối tượng nêu chi tiết các khóa trạng thái ( address và storageKeys ) cho giá thầu cao nhất của vị trí được chỉ định.

3. relay_SubmitPartialPayload

Cho phép người xây dựng khối một phần gửi một tập hợp các giao dịch dưới dạng đề xuất khối một phần.

• Chấp nhận:

  • txList (Danh sách các giao dịch): Mảng các chuỗi thập lục phân biểu thị các giao dịch.
  • b (Giá trị giá thầu cho khối một phần): Số nguyên biểu thị giá trị giá thầu tính bằng wei cho khối một phần.

• Trả về: Xác nhận gửi một phần tải trọng.

sơ đồ nàng tiên cá bằng tay 1158×588 37.4 KB