LUCID: Bộ nhớ được mã hóa với khả năng truyền tải dữ liệu phân tán.

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

Bài viết của Anders Elowsson

Cảm ơn Julian Ma , Benedikt Wagner và Justin Florentine vì những phản hồi và đánh giá. Cảm ơn cả những người tham gia các buổi họp ở Berlin đầu tháng Giêng, nơi một số đặc tính của thiết kế đã được thảo luận: Julian , Thomas , Justin , Vitalik , Caspar , Marios , Ansgar và Francesco .

1. Tổng quan

Bài viết này giới thiệu LUCID, một thiết kế mempool được mã hóa giúp thu hẹp khoảng cách giữa bên đưa vào và bên đề xuất, đồng thời tuân thủ các cơ chế Ethereum hiện có như ePBS , BALs và các giá thầu xây dựng có thể kiểm toán ( ABBs ). Thiết kế này có tính đa năng và có thể được sử dụng cho, ví dụ, tự giải mã không cần tin cậy bởi người gửi, giải mã bởi một bên đáng tin cậy hoặc trong các thiết kế ngưỡng. LUCID là một từ viết tắt thể hiện các tính năng chính:

  • IL – Thiết kế này dựa trên danh sách bao gồm (IL) được thực thi bởi lựa chọn phân nhánh, giống như FOCIL, nhưng được sửa đổi tạm thời để cấp cho người bao gồm quyền bao gồm công bằng hơn cũng như khả năng mã hóa để bảo vệ MEV. Do đó, người bao gồm hoạt động giống như người đề xuất hơn. Các IL có thể được sắp xếp so le để cải thiện khả năng chống kiểm duyệt, tạo điều kiện thuận lợi cho việc xác nhận trước bao gồm phi tập trung và thưởng cho người bao gồm mà không gây ra sự thiếu hiệu quả trong mạng.
  • U – Có hai lựa chọn thiết kế IL được xem xét: đấu giá giá thống nhất trên các danh sách bao gồm ( UPIL ), trong đó xếp hạng các giao dịch dựa trên phí mà người gửi đưa ra để được đưa vào; IL vô điều kiện (UIL), trong đó người đưa vào xác định thứ tự ưu tiên cho danh sách của riêng họ.
  • C – Các IL có thể mang theo các bản mã trong các giao dịch được niêm phong (ST) được lan truyền trong một mempool được mã hóa và có thể được đóng gói. Các ST được cam kết trong ABB.
  • D – Dữ liệu được truyền tải theo phương thức phân tán và chỉ bao gồm các tham chiếu đến các giao dịch IL trong biểu diễn mạng . Biểu diễn đồng thuận vẫn là một dữ liệu thực thi khép kín và bao gồm các vé ST được sử dụng để ghi nợ người gửi ST cũng như các ST đã được giải mã.

Nhiều thành phần được mô tả trong bài viết này có thể được áp dụng riêng lẻ hoặc kết hợp với nhau. Ví dụ, có thể chỉ chạy lược đồ mã hóa mà không cần truyền tải dữ liệu phân tán (DPP); nhược điểm duy nhất là hiệu quả phát sóng kém hơn. Lịch trình phát triển của LUCID được trình bày bên dưới.

Phần 2 giới thiệu cho người đọc vấn đề cần giải quyết và Phần 3 xem xét kỹ hơn thiết kế mã hóa. Phần 4 trình bày DPP và Phần 5 thảo luận về cách xử lý tùy chọn tiết lộ trong thiết kế. Phần 6 cuối cùng đưa ra một cuộc thảo luận ngắn gọn, trong đó Phần 6.1 mô tả chi tiết cách cấu trúc một EIP khả thi tối thiểu. Phụ lục A hoàn thiện tầm nhìn cho DPP bằng cách đề xuất danh sách bao gồm so le (SIL), trong đó các trình bao gồm dần dần xây dựng tải trọng trong suốt khe thời gian. Phụ lục B trình bày một thiết kế chặt chẽ hơn, trong đó các ST cần được giải mã được chỉ định trong tải trọng thay vì trong ABB. Phụ lục C cuối cùng trình bày một sơ đồ giải mã mà các trình giải mã có thể triển khai.

Dòng thời gian

Hình 1 cung cấp cái nhìn tổng quan về cơ chế LUCID.

Hình 1
Hình 1 1920×1391 167 KB

Hình 1. Dòng thời gian LUCID. Các nhà xây dựng tạo ra các ABB với cam kết về các giao dịch đã được niêm phong. Các ABB này được bao gồm trong khối tín hiệu để cho phép các bộ giải mã giải phóng khóa kịp thời trước khi khe thời gian tiếp theo bắt đầu. Các giao dịch được liệt kê trong IL có thể được bao gồm trong tải trọng bằng cách tham chiếu.

  • Trước T_1 T 1 – Các trình bao gồm truyền bá các IL mà, ngoài các giao dịch văn bản thuần (PT), có thể kết hợp cả các ST. Các ST được bao gồm riêng lẻ hoặc theo gói (nền màu xanh đậm), và có thể được lấy từ một mempool mã hóa công khai. Mỗi ST bao gồm một vé ST đã ký được sử dụng để tính phí người gửi và liên kết với bộ giải mã cũng như văn bản mã encrypted_tx cũng được bao gồm trong ST. encrypted_tx được giải mã thành một PT đã ký có thể có trường from khác với ST, cùng với ToB_fee_per_gas sẽ được sử dụng để sắp xếp PT ở đầu khối (ToB) sau khi được giải mã. Người gửi mã hóa các giao dịch cho bộ giải mã trong một thiết kế mở theo hướng dẫn ngoài giao thức của bộ giải mã (và nếu có thể, sử dụng khóa công khai của nó), hoặc có thể tự giải mã mà không cần tin tưởng. Phụ lục A mô tả cách các IL có thể được sắp xếp so le để đạt được phạm vi bao phủ tốt hơn và Phụ lục C đưa ra một ví dụ về thiết kế mã hóa mà bộ giải mã có thể triển khai.
  • T_1 T 1 – Các bên xác nhận (màu tím) của khe n n đóng băng chế độ xem của họ đối với các IL được truyền đi cũng như các khóa giải mã cho khối trước đó.
  • Sau T_1 T 1 – Khi các nhà xây dựng tin tưởng rằng họ đã quan sát được tất cả các IL và khóa liên quan (những IL và khóa nằm trong chế độ xem đóng băng của hầu hết các người chứng thực), họ sẽ tạo ABB (một ExecutionPayloadBid mở rộng) để giành quyền xây dựng khối (hình chữ nhật màu xanh). Các ABB này chứa “cam kết ST” của hàm băm của các ST và các gói ST trong IL. ABB cũng đánh dấu các khóa giải mã đã được quan sát từ khe trước đó.
  • T_2 T 2 – Vào đầu khe n n , bên đề xuất chọn một ABB chiến thắng, có phạm vi bao quát ít nhất bằng quan điểm của chính họ về các IL và khóa cần thiết. Họ đưa ABB đó vào khối tín hiệu.
  • Sau T_2 T 2 – Khi quan sát ABB, các nút bắt đầu yêu cầu bất kỳ IL nào bị thiếu cũng như các byte ST được tham chiếu bởi các cam kết ST của ABB. Người gửi và người giải mã cũng có thể độc lập truyền bá các byte đó ngay bây giờ.
  • T_3 T 3 – Những người xác nhận ở vị trí n n bỏ phiếu cho khối đầu chuỗi hiện tại. Nếu khối beacon bị thiếu hoặc nếu ABB được bao gồm không vượt qua kiểm toán của họ do thiếu IL hoặc khóa từ chế độ xem đóng băng của họ, họ sẽ chỉ ra khối trước đó là khối đầu chuỗi theo quan điểm của họ. Nếu ABB vượt qua kiểm toán của họ, họ sẽ xác nhận một cách lạc quan cho khối đó.
  • Sau T_3 T 3 (Giải phóng tải trọng) – Người xây dựng giải phóng tải trọng, trong đó cũng chứa các vé ST. Các giao dịch đầu tiên (hình chữ nhật màu trắng) là các ST đã được giải mã, đã được cam kết trước đó trong khối n-1 n − 1 , được sắp xếp theo phí ToB đã giải mã trên mỗi gas. Các PT thông thường từ vị trí hiện tại tiếp theo (hình chữ nhật màu đen), được người xây dựng sắp xếp tự do. Người xây dựng tham chiếu các giao dịch IL bằng chỉ mục vào IL thay vì truyền chúng lại (sử dụng một danh sách riêng trong biểu diễn mạng).
  • Sau T_3 T 3 (Tái cấu trúc tải trọng) – Mỗi máy khách giải quyết các tham chiếu giao dịch IL dựa trên bộ nhớ đệm cục bộ của nó về IL cũng như các cam kết ST và tập hợp toàn bộ tải trọng. Nó tính toán và xác minh gốc tải trọng và tiến hành thực thi tải trọng. Các ST được ABB bao gồm chọn để giải mã ở khe tiếp theo được thể hiện trong tải trọng thực thi bằng một danh sách các vé ST, được tính phí theo giới hạn gas_limit đầy đủ được chỉ định của chúng.
  • Sau T_3 ( Giải phóng khóa) – Mỗi bộ giải mã quan sát các cam kết ST trong ABB được bao gồm trong khối tín hiệu. Nó xác nhận rằng ABB có dữ liệu chính xác cho cam kết ST của riêng nó (ví dụ: liên quan đến gas_obligation chỉ định lượng gas nó tiêu thụ), rằng tổng của tất cả các mục gas_obligation nằm trong phần được phân bổ của tải trọng tiếp theo ( ToB_gas_limit ), và rằng khối tín hiệu đã được chứng thực. Nó truyền bá (các) khóa đã ký tiết lộ các ST phù hợp với khối tiếp theo. (Các) khóa được lan truyền P2P và được các người chứng thực của khối tiếp theo quan sát trước thời hạn của họ tại T_5 . Sau đó , ToB của tải trọng n+ 1 có thể được xây dựng với các ST đã giải mã được sắp xếp theo ToB.
  • T_4 T 4 – Ủy ban về tính kịp thời của tải trọng (PTC) bỏ phiếu về tính kịp thời của tải trọng. Với thiết kế phân tán, các IL mang các giao dịch được tham chiếu trong tải trọng hoặc các ST/ST-bundle đầy đủ đã được cam kết cũng phải đến được thành viên PTC vào thời điểm này để cuộc bỏ phiếu cho thấy tải trọng được coi là kịp thời.
  • T_4 T 4 hoặc T_5 T 5 – Thời hạn cho các khóa đã phát hành có thể được thực thi bằng cách bỏ phiếu trường bit PTC về tính kịp thời của chúng, hoặc bằng cách những người chứng thực của khe n+1 n + 1 đóng băng chế độ xem của họ về các khóa đã phát hành và sử dụng hợp nhất chế độ xem. Những người chứng thực bỏ phiếu cho ABB tiếp theo tùy thuộc vào việc tuân thủ bỏ phiếu trường bit PTC hoặc chế độ xem khóa bị đóng băng.
  • Sau T_5 T 5 – Quá trình diễn ra theo cùng một quỹ đạo như sau T_1 T 1 (đối với khe trước đó). Các ST đã giải mã từ khe n n được thêm vào ToB, được sắp xếp theo phí ToB và tính phí đó. Vì các ST được giải mã trước khi khối n n được xây dựng, thiết kế này hoàn toàn tương thích với BAL: người xây dựng khối n+1 n + 1 thực hiện và chuẩn bị BAL như bình thường.

2. Giới thiệu

Một mối lo ngại đối với các chuỗi khối phi tập trung như Ethereum là sự độc quyền mà người đề xuất duy nhất nắm giữ đối với việc đưa giao dịch vào mỗi khối, điều này có thể dẫn đến kiểm duyệt và phúc lợi người dùng không tối ưu. Vì lý do này, các thiết kế với nhiều người đề xuất đồng thời (MCP) đã được đề xuất ( 1 , 2 , 3 , 4 ). Nhiều năm nghiên cứu về danh sách bao gồm (IL) (ví dụ: 1 , 2 ) song song đã dẫn đến thiết kế danh sách bao gồm được thực thi bằng lựa chọn Fork ( FOCIL ). Thông qua EIP-7805 , FOCIL đã được chấp nhận như là lựa chọn chính để tạo điều kiện chống kiểm duyệt (CR) trong Ethereum, cho phép một số người đưa vào truyền bá IL của các giao dịch để được đưa vào khối tiếp theo. Tuy nhiên, khi khối đầy, người đề xuất vẫn có quyền kiểm duyệt các giao dịch, ngay cả khi họ sẵn sàng trả nhiều hơn số giao dịch thực sự được đưa vào. Hơn nữa, một tỷ lệ lớn các giao dịch có thể bị kiểm duyệt phải được truyền bá riêng tư để tránh MEV, và do đó không thể dựa vào FOCIL để chống kiểm duyệt.

Đã có nhiều thiết kế IL khác nhau được đề xuất, trong đó người đề xuất có ít quyền kiểm soát hơn đối với nội dung của khối. IL vô điều kiện (UIL) yêu cầu tất cả các giao dịch được liệt kê phải được đưa vào nếu chúng đáp ứng các tiêu chí đưa vào thông thường. EIP-8046 đã giới thiệu một cuộc đấu giá giá thống nhất trên các danh sách đưa vào (UPIL), đảm bảo rằng người đề xuất không còn có thể bỏ qua các IL khi khối đầy. Các giao dịch được xếp hạng theo mức phí mà chúng đề nghị trả, và những giao dịch sẵn sàng trả nhiều nhất sẽ được đưa vào, mỗi giao dịch trả cùng một mức phí cơ bản thống nhất trong khối, mức phí này sẽ bị đốt cháy. Điều này cung cấp CR mạnh mẽ và có lợi cho các giao dịch nhạy cảm về thời gian và thị trường phí đa chiều. Tuy nhiên, UIL và UPIL không ngăn chặn MEV vì các giao dịch vẫn phải được truyền bá công khai.

Để ngăn chặn MEV (Mempool Encryption), các giao dịch phải được giữ bí mật cho đến khi được cam kết. Nhiều thiết kế đã được đề xuất cho các mempool được mã hóa, chẳng hạn như mã hóa ngưỡng có thể tận dụng cam kết của người đề xuất , các lược đồ cam kết-tiết lộ như trong các giao dịch kín , hoặc sự kết hợp của cả hai. Các giao dịch kín có thể tận dụng ABB ( Account-Based Block) theo ePBS. Một lược đồ cam kết-tiết lộ dưới sự thực thi lựa chọn phân nhánh, như trong các giao dịch kín, có thể tạo điều kiện thuận lợi hơn nữa cho nhiều lược đồ mã hóa ngoài giao thức—một dạng giao dịch kín tổng quát . Một thiết kế theo hướng này nhưng với giải mã cùng vị trí cũng đã được đề xuất gần đây dưới dạng bài đăng nghiên cứu và EIP ( Electric Instructor Improvement). Một chiến lược khác là dựa vào các mempool được mã hóa tài khoản thông minh , cũng đã được đề xuất dưới dạng EIP .

Một lập luận theo quan điểm của Hayek về việc xây dựng khối phi tập trung là một nhóm người tham gia rộng hơn sẽ cùng nhau có được kiến thức cần thiết để tạo ra một khối tốt. Có thể thấy rằng chỉ bằng cách bảo vệ đóng góp của từng người tham gia vào khối đó khỏi MEV (Mean Time Value - Giá trị tham chiếu) và đảm bảo tính bao gồm cho các giao dịch khả thi, chúng ta mới thực sự cho phép họ truyền đạt kiến thức đó một cách không cần tin tưởng lẫn nhau.

Danh sách bao gồm thường gây ra sự dư thừa dữ liệu : các giao dịch được truyền tin trong mempool, sau đó thông qua IL, và cuối cùng được truyền tin lại bên trong tải trọng thực thi. Thay vào đó, bằng cách coi việc truyền tin danh sách bao gồm như một bước “điền trước”, tải trọng có thể được phân phối hiệu quả trong suốt thời gian khe thay vì được truyền theo kiểu bùng nổ vào cuối. Do đó, việc truyền cùng một byte hai lần (một lần trong truyền tin IL, một lần trong phong bì tải trọng) trong một cửa sổ khe duy nhất được tránh. Giảm kích thước của ExecutionPayloadEnvelope giảm thiểu độ trễ lan truyền, cho phép thời gian khe ngắn hơn, IL lớn hơn hoặc khối lớn hơn. Thiết kế này tương thích với việc phân đoạn tải trọng ( 1 , 2 ), điều này sẽ chỉ đơn giản hoạt động trên các tải trọng đã được nén ở một mức độ nào đó theo DPP.

Mặc dù DPP tăng hiệu quả mạng, nhưng nó không giải quyết được sự нееfficienсy của việc nhiều IL truyền tải cùng một giao dịch. Cần có một giải pháp trong giao thức để giảm sự trùng lặp, và bài viết này đề xuất danh sách bao gồm so le (Phụ lục A) cho mục đích này, đồng thời cũng tạo điều kiện thuận lợi cho việc xác nhận trước không cần tin cậy. Để hạn chế số lượng khóa giải mã độc lập cần được đối chiếu trước khi thực thi, các ST có thể được nhóm lại trước khi được cam kết. Bài viết này đề xuất LUCID, thực hiện các giao dịch được niêm phong tổng quát (mở rộng trên 1 , 2 ) đồng thời nâng cấp các bên bao gồm để bảo vệ các giao dịch khỏi MEV và có quyền bình đẳng đối với không gian khối, do đó thu hẹp khoảng cách giữa bên bao gồm và bên đề xuất.

3. Thiết kế mã hóa

Thiết kế mã hóa được mô tả đầu tiên bằng cơ chế UPIL, và những thay đổi cần thiết cho cơ chế UIL được trình bày trong Mục 3.10. FOCIL thông thường (IL có điều kiện) cũng có thể được sử dụng theo thiết kế chung. Cần nhấn mạnh rằng một số tính năng được nêu trong Mục 3-4, chẳng hạn như DPP, UPIL và các gói, không quan trọng đối với một mempool được mã hóa LUCID cơ bản, như được thảo luận thêm trong Mục 6.1.

3.1 Giao dịch niêm phong

Một giao dịch được niêm phong (ST) bao gồm một vé ST đã ký và một văn bản mã hóa encrypted_tx . ST có các trường sau:

  • from đó ký tên vào vé ST và thanh toán phí.
  • các trường thông thường nonce , gas_limit , max_fee_per_gas , max_priority_fee_per_gas , max_ranking_fee_per_gas ,
  • decryptor_address của thực thể chịu trách nhiệm giải mã.
  • decryptor_fee sẽ được thanh toán khi thực hiện giao dịch văn bản gốc đã được giải mã, với điều kiện là from vốn được cấp.
  • reveal_commitment , trong đó reveal_commitment = hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas)) liên kết tải trọng văn bản thuần được tiết lộ với một vé đã thanh toán cụ thể.
  • ciphertext_hash , trong đó ciphertext_hash = keccak256(encrypted_tx) liên kết các byte mã hóa,
  • encrypted_tx , được giải mã thành RevealedTransaction(plaintext_tx, ToB_fee_per_gas) .

Với tinh thần thúc đẩy một giải pháp tổng quát, ý tưởng cơ bản là giao thức chỉ quy định cách các máy khách phân tích và mở encrypted_tx , trong khi để cho các bộ giải mã tự định nghĩa (ngoài giao thức) cấu trúc mã hóa ký quỹ khóa/lai mà họ sử dụng. Cụ thể, encrypted_tx là một lớp bao bọc:

 encrypted_tx = header_len:u16 || header || ct_demct_dem = nonce || aead_ciphertext

Phần header không thể hiểu được đối với giao thức và có thể chứa bất kỳ siêu dữ liệu nào dành riêng cho bộ giải mã cần thiết để khôi phục khóa DEM (ví dụ: mã hóa khóa công khai lai ( HPKE )/đóng gói KEM, văn bản mã hóa ngưỡng dưới khóa giải mã ngưỡng, v.v.). Bộ giải mã công bố các hướng dẫn ngoài giao thức mô tả cách người gửi điền vào header và cách khóa DEM k_dem được tạo ra cho một vé nhất định. Tại thời điểm tiết lộ, bộ giải mã chỉ phát hành vật liệu khóa DEM cho mỗi vé này ( k_dem ) để bất kỳ ai cũng có thể giải mã ct_dem và xác thực việc tiết lộ so với reveal_commitment .

Bộ giải mã cần đảm bảo khóa k_dem được giải phóng gắn liền với ngữ cảnh của vé đã thanh toán (ví dụ: bằng cách tạo ra nó bằng cách sử dụng mã hóa phân tách theo miền của (chain_id, ticket.from, ticket.nonce) làm đầu vào KDF ( info HPKE nếu sử dụng HPKE) và/hoặc dữ liệu liên kết AEAD). Điều này làm cho khóa được tiết lộ trở nên đặc thù cho từng vé, do đó việc giải phóng tài liệu giải mã cho một vé không giúp giải mã các bản mã được đính kèm với các vé khác ngay cả khi các byte header được sao chép giữa các vé (bất kỳ bí mật dài hạn nào được khôi phục từ tiêu đề không bao giờ được tiết lộ). Phụ lục C đưa ra một ví dụ về cấu trúc như vậy (cảm ơn Benedikt Wagner). Đối với việc tự giải mã không cần tin cậy, người gửi có thể giữ mọi thứ đơn giản (ví dụ: đặt header_len = 0 và chọn trực tiếp một khóa DEM mới cho mỗi vé).

 class RevealedTransaction ( Container ):plaintext_tx: Transaction # Type 2 transaction ToB_fee_per_gas: uint64 class RevealCommitmentPreimage ( Container ):ticket_from: ExecutionAddressticket_nonce: uint64plaintext_tx: TransactionToB_fee_per_gas: uint64 class STTicket ( Container ): from : ExecutionAddressnonce: uint64gas_limit: uint64max_fee_per_gas: uint64max_priority_fee_per_gas: uint64max_ranking_fee_per_gas: uint64decryptor_address: ExecutionAddressdecryptor_fee: uint64reveal_commitment: Bytes32ciphertext_hash: Bytes32signature: Bytes65 # Signature by `from` over the ticket fields class SealedTransaction ( Container ):ticket: STTicketencrypted_tx: ByteList[MAX_ENCRYPTED_TX_BYTES]

Giới gas_limit phải đủ để trang trải chi phí dữ liệu cuộc gọi cho kích thước byte của encrypted_tx , bị giới hạn bởi MAX_TRANSACTION_GAS_LIMIT và sẽ được tính phí đầy đủ — sẽ không có khoản hoàn trả nào khi quan sát mức sử dụng gas thực tế sau khi thực thi. plaintext_tx đã được giải mã bên trong RevealedTransaction là một giao dịch EIP-1559 (loại 2) với max_priority_fee_per_gas = 0 , max_fee_per_gas = 0 (vì giao dịch đã được giải mã đã được trả trước bằng vé ST) và gas_limit = ticket.gas_limit .

Mã nonce của vé ST sử dụng lại mã nonce tài khoản thông thường của Ethereum và được tiêu thụ bất kể bản mã có được tiết lộ sau đó hay không, vì phí ST được tính bất kể việc thực thi có thành công hay không. Người gửi ST ký vào vé ST. Chữ ký được tính toán trên một bản tóm tắt phân tách theo miền bao gồm chain_id (và fork/version) và hash-tree-root của các trường vé (không bao gồm signature ).

Dữ liệu văn bản gốc bên trong encrypted_tx được người gửi văn bản gốc ký riêng như một phần của plaintext_tx . Các nút xác thực ST bằng cách xác minh chữ ký vé và kiểm tra xem ciphertext_hash có khớp với hàm băm của encrypted_tx hay không.

3.2 Các gói giao dịch đã niêm phong

Các giao dịch được niêm phong được cam kết trong ABB. Nếu mempool được mã hóa trở nên phổ biến, số lượng lớn các cam kết riêng biệt và khóa giải mã có thể gây áp lực lên mạng, đặc biệt là khi Ethereum mở rộng quy mô. Do đó, có lý do để giới hạn số lượng cam kết đối với các ST trong ABB, đồng thời vẫn đảm bảo thông lượng cao. Vì vậy, các ST có thể được nhóm lại với nhau và được cam kết chung.

Tất cả các giao dịch trong một gói phải có cùng decryptor_address và gói đó phải được ký bởi thực thể kiểm soát địa decryptor_address . Có thể cho phép các gói mang toàn bộ ST, hoặc chỉ chứa các hàm băm với chữ ký trên các hàm băm đó. Điều này để lại nhiệm vụ cho bên bao gồm (includer) tái tạo lại toàn bộ gói ST. Có vẻ hợp lý khi yêu cầu IL mang toàn bộ byte ST, vì những byte này phải có sẵn trước thời hạn của PTC. Nếu IL tham chiếu đến gói không có sẵn khi được quan sát trong khối tín hiệu, toàn bộ gói phải được truyền P2P.

Khả năng bao gồm các giao dịch mempool được mã hóa không được đóng gói vẫn mang lại lợi ích vì ba lý do riêng biệt:

  1. Bất kỳ ST nào cũng có thể được thực thi nếu được bao gồm trong IL, cung cấp khả năng chống spam cho mempool công cộng.
  2. Các thiết kế như giải mã ngưỡng có thể hoạt động mà không cần bộ điều phối trình tự đóng gói các giao dịch từ trước.
  3. Người dùng không cần phải phân phối các gói dữ liệu cho từng ST riêng lẻ mà họ muốn giải mã một cách không cần tin cậy.

3.3 Cam kết ST

Các giao dịch được niêm phong được ghi nhận trong "cam kết ST" trong ABB, hoặc riêng lẻ, hoặc là một phần của các gói được lấy từ mempool mã hóa công khai (hoặc có thể được cung cấp ngoài giao thức, có khả năng tận dụng các thiết kế tương tự như MEV boost). Danh sách bao gồm cung cấp một đường dẫn bao gồm quan trọng cho các cam kết ST — người xây dựng phải tuân thủ các cam kết mà họ đề xuất. Mỗi cam kết ST chỉ định bốn trường:

 class STCommitment ( Container ):bundle: bool # False if ST, True if ST-bundle commitment_root: Bytes32 # ticket_root if ST, bundle_root if bundle decrypt: Bitfield # indices to release keys to decrypt the tx gas_obligation: uint64 # sum of gas_limit over entries with decrypt=1

Cam kết ST được xác định thông qua commitment_root , đó có thể là gốc cây băm SSZ của vé đã ký ticket_root = hash_tree_root(STTicket) hoặc của gói đã ký, bundle_root , bao gồm tất cả các mục ticket_root trong gói. Một scheduled_root khả thi trên các mục ticket_root với decrypt=1 được thảo luận trong Phần 6.3. Lưu ý rằng các byte mã hóa được liên kết với vé thông qua ciphertext_hash = keccak256(encrypted_tx) , được bao gồm trong vé đã ký.

3.4 Phân bổ và giới hạn khí đốt ToB

Mỗi IL có một lượng cam kết ST nhất định, ban đầu có thể được đặt khá thấp; ví dụ, mỗi IL có thể cam kết MAX_COMMITS_PER_IL = 4 cam kết ST. Cũng có thể cho phép người xây dựng thực hiện các cam kết riêng của mình, ví dụ như MAX_COMMITS_PER_IL cam kết ST. Tuy nhiên, để đơn giản hóa thiết kế, có lẽ cách dễ nhất là chỉ cần cấp cho người xây dựng một IL riêng. Có một lượng phân bổ max_bytes_per_inclusion_list cho mỗi IL, giống như trong FOCIL. Lượng này thay đổi theo giới hạn gas để người bao gồm không bị bất lợi so với người đề xuất khi gas_limit của khối tăng lên. Nó có thể được tính toán như sau: max_bytes_per_inclusion_list = gas_limit/(IL_COMMITTEE_SIZE * GAS_PER_AGG_IL_BYTES) . Việc thiết lập GAS_PER_AGG_IL_BYTES = 2**9 sẽ cho kích thước byte IL là 7.15 KiB ở giới hạn gas là 60M khi sử dụng IL_COMMITTEE_SIZE = 16 như trong FOCIL. Các cam kết ST vẫn được tính vào max_bytes_per_inclusion_list .

Mỗi khối có một ToB_gas_limit dành cho các giao dịch đã được giải mã, được đặt bằng một phần nhỏ của tổng gas_limit của khối trước đó, tạm thời là 1/4 * gas_limit . Ngoài ra còn có ToB_marginal_ranking_fee_per_gas , được tính bằng giá trị lớn nhất của marginal_ranking_fee_per_gas của khối hiện tại (như được quy định trong EIP-8046) và ranking_fee_per_gas của ST có thứ hạng cao nhất bị loại trừ khỏi phân bổ ToB_gas_limit cho khối tiếp theo.

3.5 Hồ sơ dự thầu xây dựng có thể kiểm toán (ABB)

Bên xây dựng đưa ra các giá thầu xây dựng có thể kiểm toán (ABB) để giành quyền xây dựng tải trọng. ABB mở rộng ExecutionPayloadBid bằng cách bao gồm ToB_marginal_ranking_fee_per_gas , các cam kết ST và một trường bit về sự tuân thủ khóa cho các cam kết ST của khối trước đó:

 class ILCommitments ( Container ):IL_root: Bytes32commits: List [STCommitment, MAX_COMMITS_PER_IL] class ILKeyAdherence ( Container ):key_adherence: List [Boolean, MAX_COMMITS_PER_IL] class ABB ( Container ):... # existing fields of the ExecutionPayloadBid ToB_marginal_ranking_fee_per_gas: uint64IL_data: List [ILCommitments, IL_COMMITTEE_SIZE]key_adherence: List [ILKeyAdherence, IL_COMMITTEE_SIZE] # one bitfield per previous IL in a list of bitfields

Trình tạo sẽ loại bỏ các ST trùng lặp của các cam kết ST bằng cách sử dụng (ticket.from, ticket.nonce) . Chỉ có thể có một ST có cùng (ticket.from, ticket.nonce) trong tập hợp đã loại bỏ trùng lặp được đưa vào tải trọng, với bit decrypt được đặt thành 1 Tất cả các ST khác có cùng (ticket.from, ticket.nonce) phải có bit decrypt được đặt thành 0 Hơn nữa, các ST tạo ra chuỗi ticket- nonce không hợp lệ cho ticket.from , hoặc không được tính phí khi bắt đầu tính phí vé (Mục 3.9), cũng được loại bỏ theo cùng một cách. Một quy tắc xác định được áp dụng để xác định ST nào cần giữ lại trong quá trình loại bỏ trùng lặp, chọn trường hợp trong gói có nhiều ST nhất và giải quyết trường hợp bằng cách sử dụng committee_index của IL.

Nếu có nhiều hơn một cam kết IL cho một gói ST cụ thể, các cam kết trùng lặp sẽ đặt decrypt mã thành mã hóa số 0 chuẩn (một bit 0) để tiết kiệm không gian, và chỉ gói ST từ IL có committee_index cao nhất mới được giữ lại. Để tránh tính dễ bị thay đổi, khi decrypt không có bit nào được đặt, nó phải được mã hóa chính xác là 0 (một bit 0) và được hiểu là mặt nạ toàn số 0 bất kể độ dài gói; các mã hóa toàn số 0 khác đều không hợp lệ.

Đối với các ST trùng lặp trong cùng một gói, tất cả đều dùng chung địa decryptor_address ), do đó việc loại bỏ trùng lặp hoàn toàn là vấn đề kế toán của bộ giải mã. Lưu ý thêm rằng người xây dựng không được tự do thiết lập các bit decrypt theo ý muốn. Những người xác nhận, người xây dựng (và tất cả các nút khác) cho vị trí n+ 1 sẽ xem xét các bit decrypt được thiết lập một cách nghiêm ngặt để tạo điều kiện thuận lợi cho các quy tắc xác định (ví dụ: loại bỏ trùng lặp), mà không bỏ sót các ST hợp lệ được IL đưa ra. Nếu tải trọng không vượt qua kiểm tra của họ, giao thức sẽ chuyển sang quy trình khôi phục trong trường hợp tải trọng không hợp lệ, như được mô tả trong Mục 4.5.

Các ST đã được loại bỏ trùng lặp cuối cùng được đưa vào bằng cách đặt decrypt = 1 nếu ranking_fee_per_gas của chúng vượt quá ToB_marginal_ranking_fee_per_gas , việc phân định bằng cách sử dụng ticket_root . Sau khi xác định các ST cần đưa vào, gas_obligation được đặt cho mỗi cam kết ST là tổng của tất cả các mục gas_limit với decrypt = 1 trong cam kết đó. ToB_marginal_ranking_fee_per_gas có thể được sử dụng thêm để nén trường bit decrypt sao cho chỉ bao gồm phạm vi giao dịch cho phép có ranking_fee_per_gas đủ lớn.

Thuộc commitment_root trong ABB cho phép bộ giải mã xác định nó và giải phóng các khóa giải mã khi quan sát thấy một khối tín hiệu kịp thời, ngay cả trước khi dữ liệu được giải phóng. Mỗi IL_root được bao gồm trong ABB để giải quyết sự mơ hồ trong trường hợp có sự không rõ ràng, như được thảo luận thêm trong Phần 4.3 liên quan đến DPP.

Có hai phương pháp có thể được sử dụng để tránh việc các nhà thầu phải truyền tải toàn bộ ABB cho mỗi lần đấu thầu. Nhà thầu có thể chỉ định sự khác biệt so với giá thầu trước đó cho mỗi giá thầu mới, bao gồm cả mã băm để tham chiếu. Có thể dự đoán rằng các cam kết ST được thiết lập trước thời hạn đấu thầu, có nghĩa là sự khác biệt trong các giá thầu sau chỉ cần bao gồm các thay đổi về giá trị đấu thầu và tải trọng từ các PT đến muộn. Lựa chọn khác là thiết lập một sơ đồ kéo, trong đó giá thầu của nhà thầu được rút gọn, và người đề xuất sẽ kéo ABB từ nhà thầu thắng cuộc trước khi công bố.

3.6 Giấy chứng nhận

Người kiểm chứng so sánh ABB với IL mà họ đã quan sát được. Họ xác nhận rằng:

  • Tổng giá trị của tất cả các mục gas_obligation nằm trong giới hạn ToB_gas_limit .
  • Mọi IL được quan sát kịp thời mà không có sự mơ hồ đều được chỉ định chính xác trong ABB, dựa trên ToB_marginal_ranking_fee_per_gas đã được công bố.

Các danh sách bao gồm trong ABB mà người xác nhận chưa quan sát sẽ không được xem xét. Các nút yêu cầu các IL này sau khi quan sát chúng trong ABB và PTC cuối cùng sẽ bỏ phiếu về tính kịp thời của chúng.

3.7 Phát hành chính thức

Bộ giải mã quan sát ToB_marginal_ranking_fee_per_gas và gas_obligation được quy định trong ABB được truyền đi cùng với khối beacon n n . Nó xác minh rằng ToB_marginal_ranking_fee_per_gas và trường bit decrypt thực sự tạo ra gas_obligation được chỉ định cho cam kết ST của chính nó và tổng của tất cả các mục gas_obligation nằm trong giới hạn ToB_gas_limit . Đây là một yêu cầu để giải phóng khóa giải mã. Cụ thể, nếu tải trọng sau đó hóa ra không hợp lệ hoặc không đúng thời điểm, cam kết ST của bộ giải mã sẽ luôn nằm trong giới hạn ToB_gas_limit . Điều này có nghĩa là chúng vẫn có thể được đưa vào ToB trong tải trọng hợp lệ tiếp theo, như được thảo luận thêm trong Phần 4.5.

Nếu IL chịu trách nhiệm liệt kê ST (hoặc gói) không khả dụng, bộ giải mã sẽ (nếu chưa thực hiện trước đó) phát sóng toàn bộ byte ST (hoặc nội dung gói) có ticket_root / bundle_root khớp với commitment_root trong ABB, để các nút có thể xác thực khóa đã phát hành trước thời hạn PTC. Khi bộ giải mã (hoặc bất kỳ ai) cung cấp toàn bộ byte SealedTransaction cho một ST đã cam kết, các nút sẽ kiểm tra xem hash_tree_root(st.ticket) == commitment_root và keccak256(st.encrypted_tx) == st.ticket.ciphertext_hash . Khi bộ giải mã tin tưởng rằng khối beacon sẽ trở thành chuẩn tắc (ví dụ: sau khi quan sát các chứng thực cho nó), nó sẽ phát hành khóa của mình.

Tại thời điểm phát hành khóa, bộ giải mã công bố vật liệu khóa đối xứng như mô tả trong Mục 3.1. Các khóa được phát hành trong một thông báo được ký bởi decryptor_address và xác định cam kết ST liên quan bằng chỉ committee_index và commit_index , bao gồm cả số khe và beacon_block_root của khối đèn hiệu mang ABB liên quan. Đối với các gói, các khóa được gói trong một danh sách có cùng độ dài với số bit decrypt được đặt thành 1 , được sắp xếp theo cùng một cách như trong gói đã cam kết.

Các thông điệp khóa được truyền tải qua P2P. Các nút chuyển tiếp bất kỳ thông điệp khóa nào được định dạng tốt, nhắm mục tiêu đến một cam kết có trong ABB được xác định bởi (beacon_block_root, slot) và được ký bởi decryptor_address được chỉ định trong cam kết ST. Một khóa hợp lệ nếu nó giải mã văn bản mã hóa đã cam kết thành RevealedTransaction(plaintext_tx, ToB_fee_per_gas) sao cho hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas)) == ticket.reveal_commitment và plaintext_tx đã giải mã thỏa mãn các trường cố định bắt buộc ( max_priority_fee_per_gas = 0 , max_fee_per_gas = 0 và gas_limit = ticket.gas_limit ). Người gửi văn bản gốc đã giải mã và nonce không bắt buộc phải khớp với from và nonce của người gửi ST.

Các khóa nhắm mục tiêu cùng một beacon_block_root , committee_index và commit_index mà không giống hệt nhau về mặt byte được coi là sự mơ hồ. Các khóa mơ hồ được xử lý tương tự như sự mơ hồ IL trong FOCIL: các nút truyền hai thông điệp khóa đã ký khác biệt đầu tiên mà chúng quan sát được cho cùng một mục tiêu để báo hiệu sự mơ hồ, và người xây dựng có thể tự do bỏ qua các ST mà người giải mã đã mơ hồ. Người xác nhận chấp nhận sự bỏ sót đó nếu họ đã quan sát thấy bằng chứng mơ hồ trước thời hạn xác nhận của họ.

3.8 phiếu bầu PTC

PTC bỏ phiếu về DA liên quan đến việc phát sóng tải trọng và dữ liệu blob. Để tuân thủ việc lan truyền phân tán tải trọng (Mục 4), phiếu bầu của PTC cũng liên quan đến tính khả dụng của tất cả dữ liệu cần thiết để tái tạo ExecutionPayload đã cam kết: các byte giao dịch văn bản thuần được tham chiếu ( tx_reference ) và các cam kết ST được tham chiếu cũng như các byte ST/bundle cơ bản được tham chiếu bởi các cam kết đó.

Do đó, bên xây dựng có trách nhiệm đảm bảo rằng các IL mà họ đã đăng ký trong ABB của mình đã được gửi đến trước khi PTC bỏ phiếu, nhưng các bộ giải mã cũng có thể tự động truyền các byte ST tương ứng nếu không có IL. Các vấn đề khác liên quan đến chủ đề này được thảo luận trong Phần 4.3. Sau khi tái tạo tải trọng với sự hỗ trợ của các IL đã lưu trữ, các thành viên PTC xác minh rằng gốc của tải trọng là chính xác. Họ cũng xác nhận bằng phiếu bầu của mình rằng ABB đã được chỉ định chính xác, như có thể thấy trong tải trọng.

Tùy chọn, mỗi thành viên PTC cũng phát sóng một trường bit đã ký cho biết những cam kết ST nào được lên lịch giải mã ở khe tiếp theo đã nhận được thông điệp khóa hợp lệ trước thời hạn khóa. Trường bit này được lập chỉ mục trên các cam kết ST của ABB lập lịch với mặt nạ decrypt khác không, theo thứ tự chuẩn tắc bởi (committee_index, commit_index) (tức là bằng cách quét IL_data theo committee_index tăng dần và commits[] theo commit_index tăng dần). Lý do sử dụng phiếu bầu PTC được thảo luận trong Phần 6.3.

Bên xây dựng và các bên xác nhận ở vị trí n+ 1 đưa ra quyết định về tính kịp thời dựa trên kết quả bỏ phiếu PTC. Để hợp nhất các quan điểm, các bên xác nhận có thể đóng băng quan điểm của họ về các phiếu bầu PTC trước khi bắt đầu vị trí n+ 1 . Sau đó, bên xây dựng có thể thực thi quan điểm của mình về tính kịp thời khi một khóa nhận được từ 45-55% số phiếu bầu (dưới 45%, các bên xác nhận thực thi là không kịp thời; trên 55%, các bên xác nhận thực thi là kịp thời, miễn là họ đã quan sát được khóa đó trước thời hạn bỏ phiếu). Tùy chọn, bên xây dựng có thể có khả năng truyền bá một cấu trúc riêng biệt với các phiếu bầu đã quan sát được để hợp nhất các quan điểm.

3.9 Thanh toán và bao gồm

Biểu diễn đồng thuận của tải trọng thực thi được mở rộng với danh sách st_tickets và danh sách decrypted_transactions (cả hai đều được mô tả trong Phần 4.2). Chúng được sử dụng để tính phí cho các ST.

Thu phí vé ST

Mỗi vé ST trong st_tickets sẽ trừ vào ticket.gas_limit * (base_fee_per_gas + ToB_marginal_ranking_fee_per_gas) + ticket.decryptor_fee từ ticket.from , trong đó ToB_marginal_ranking_fee_per_gas được lấy từ ABB có cam kết ST đã lên lịch cho vé đó (tức là ABB xác định tập hợp đang chờ xử lý). Không có khoản hoàn trả nào trong khối n+ 1 dựa trên gas_used thực tế đã sử dụng, và nếu ST không được giải mã, chỉ có decryptor_fee được hoàn trả. Một khối không hợp lệ nếu bất kỳ vé nào trong st_tickets không thể được tính phí đầy đủ.

Các nút xác minh rằng ToB_marginal_ranking_fee_per_gas (xem Mục 3.4) đã được thiết lập chính xác bằng cách so sánh nó với ranking_fee_per_gas của ST có thứ hạng cao nhất, hợp lệ và không nằm trong ToB. Vì ST được tính phí dựa trên gas_limit hiển thị công khai chứ không phải lượng gas thực tế đã sử dụng, nên việc kiểm tra khả năng cấp vốn tại thời điểm cam kết là tĩnh và không phụ thuộc vào việc thực hiện các giao dịch khác. Điều này tránh được các vấn đề phụ thuộc vòng tròn đòi hỏi phải kiểm tra số dư thận trọng trong cơ chế xếp hạng của UPIL.

Bao gồm và tính phí các ST đã được giải mã

Các nút quan sát việc phát hành khóa và giải mã các giao dịch ST cục bộ. Người xây dựng khối n+ 1 thu thập tất cả các khóa mà nó có thể tìm thấy và tạo ra một ABB chứa trường bit với các khóa hợp lệ mà nó tuân thủ. Người xác nhận yêu cầu người xây dựng phải tuân thủ tất cả các khóa hợp lệ kịp thời, trong đó tính kịp thời được xác định thông qua việc hợp nhất chế độ xem hoặc bỏ phiếu PTC như đã nêu trước đó. Các ST không thể giải mã bằng khóa đã phát hành sẽ bị bỏ qua.

Các nút xác thực từng giao dịch ToB đã giải mã dựa trên vé ST cụ thể đã tạo ra nó (thông qua ST đầy đủ và khóa tương ứng). Việc tiết lộ chỉ hợp lệ nếu hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas)) == ticket.reveal_commitment và plaintext_tx đã giải mã đáp ứng các trường cố định bắt buộc ( max_priority_fee_per_gas = 0 , max_fee_per_gas = 0 và gas_limit = ticket.gas_limit ).

Bước đầu tiên trong quá trình xử lý decrypted_transactions là hoàn trả ticket.decryptor_fee cho tất cả các ST chưa được giải mã. Người gửi được xác định là những người có chỉ số bị thiếu trong ticket_index (Mục 4.2). Thay vào đó, decryptor_fee từ decrypted_transactions được ghi có vào ticket.decryptor_address tương ứng. Cuối cùng, giao thức sẽ trừ và đốt phí ToB ticket.gas_limit * ToB_fee_per_gas từ ticket.from . Nếu ticket.from không đủ để trang trải khoản phí này, giao dịch sẽ không được bao gồm.

Người dùng gửi nhiều ST có plaintext_tx đã giải mã có cùng from và có nonce tuần tự nên đảm bảo ToB_fee_per_gas tương thích với nonce, vì các giao dịch đã giải mã được sắp xếp chủ yếu theo ToB_fee_per_gas trong khi quá trình thực thi vẫn tuân theo thứ tự nonce của mỗi người gửi.

3.10 Phiên bản IL không điều kiện

Đối với phiên bản IL không điều kiện, một vài sửa đổi đã được thực hiện, được trình bày chi tiết ở đây. Ý tưởng là theo đuổi “FOCIL không điều kiện”, tuân thủ nhiều nguyên tắc thiết kế của FOCIL, nhưng cho phép danh sách của mỗi includer là không điều kiện. Bên cạnh việc là một con đường khả thi để tạo ra một mempool được mã hóa như trong LUCID, nó cũng có thể hữu ích trong một thị trường phí đa chiều như trong EIP-7999. Thông tin chi tiết và phân tích thêm về FOCIL không điều kiện ngoài những gì đã được nêu ở đây sẽ được trình bày riêng.

UIL với tràn

Phí max_bytes_per_inclusion_list ToB_marginal_ranking_fee_per_gas được loại bỏ khỏi ABB. Mỗi IL được phép tiêu thụ ít nhất ST_gas_min_per_IL gas ToB, một con số được tính bằng ST_gas_min_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE . Lượng gas ToB thực tế mà IL có thể tiêu thụ phụ thuộc vào lượng gas mà các IL khác tiêu thụ. max_bytes_per_inclusion_list có thể được thiết lập sao cho các IL có thể lấp đầy dữ liệu cuộc gọi lên đến ST_gas_min_per_IL hoặc thấp hơn. Thứ tự của các cam kết ST, và thứ hai là thứ tự của các ST trong các gói, xác định thứ tự ưu tiên do IL chỉ định. Trình tạo tăng lượng gas tối đa mà một IL có thể tiêu thụ cho đến khi tổng của tất cả các mục gas_obligation vượt quá ToB_gas_limit , và sau đó giảm mức tối đa đó để loại bỏ giao dịch được thêm vào cuối cùng. Do đó, tổng số (không trùng lặp) của các mục gas_obligation phải nằm trong giới ToB_gas_limit , giống như trước đây.

Các bên xác nhận kiểm tra xem mọi cam kết ST được quan sát đúng hạn gas_obligation được chỉ định chính xác hay không, dựa trên giá trị tối đa của tất cả các mục gas_obligation và các bit decrypt đã được công bố. Mỗi bên giải mã cũng xác minh điều này cho cam kết của riêng họ. Họ giải phóng khóa cho các giao dịch có decrypt = 1 , sao cho tổng giới hạn gas của ST bằng gas_obligation .

UIL không bị tràn

Theo phiên bản IL không điều kiện và không tràn, mỗi IL được giới hạn ở mức ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE của lượng khí ToB. Vì giới hạn này cố định cho mỗi IL, trường gas_obligation có thể được bỏ qua trong ABB. Vì các bên tham gia vẫn có thể có ý kiến trái chiều, nên việc giữ lại commitment_root trong ABB có vẻ hợp lý.

UIL cùng với UPIL

Một thiết kế khả thi khác là cho phép IL bao gồm vô điều kiện ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE , và cho phép các giao dịch bổ sung được bao gồm theo UPIL. Phần vượt quá sau đó được giới hạn bởi max_bytes_per_inclusion_list .

4. Sự lan truyền tải trọng phân tán

Tải trọng dựa trên các tham chiếu đến dữ liệu giao dịch đã được lan truyền trước đó và các cam kết ST trước đó, thay vì sao chép các byte giao dịch trong quá trình phát sóng tải trọng. Biểu diễn đồng thuận được mở rộng với st_tickets và decrypted_transactions (Mục 4.2), nhưng danh sách transactions thông thường vẫn là danh sách các byte giao dịch đầy đủ như trong tải trọng thực thi hiện nay. Biểu diễn mạng được gửi qua P2P khác biệt và được sử dụng như một tối ưu hóa tạm thời.

4.1 Biểu diễn mạng

Một phương thức phát sóng tải trọng nhẹ được giới thiệu. Bên cạnh việc mang theo toàn bộ byte giao dịch cho các giao dịch không bắt nguồn từ danh sách bao gồm, DistributedExecutionPayloadEnvelope cũng bao gồm một danh sách các con trỏ đến các giao dịch mà các nút được kỳ vọng đã có (hoặc có thể lấy) từ các IL chuẩn. Mỗi ILTransactionPointer cũng chỉ định vị trí của giao dịch IL trong danh sách transactions cuối cùng của khối (biểu diễn đồng thuận).

 class ILTransactionPointer ( Container ):committee_index: uint8 # 0..IL_COMMITTEE_SIZE-1 tx_index: uint16 # index into the canonical IL body for this committee_index position: uint32 # index in the final full transactions list

Biểu diễn mạng của tải trọng không đề cập đến các ST. ABB do người xây dựng tạo ra cũng đủ để tái tạo một cách xác định các vé ST và các ST đã giải mã. Cụ thể, các cam kết ST trong ABB lập lịch, với bit decrypt do người xây dựng chỉ định, xác định các vé ST mà tải trọng bao gồm và thứ tự của chúng. Tương tự, các bit key_adherence xác định các ST đã giải mã cần được bao gồm, với thứ tự của chúng được xác định bởi phí ToB. Các chi tiết khác liên quan đến việc khôi phục được thảo luận trong Phần 4.5.

Do đó, cụ thể, DistributedExecutionPayloadEnvelope phản ánh các trường tiêu đề ExecutionPayload (mọi thứ cần thiết để tính toán lại block_hash ), nhưng dựa vào các con trỏ ( ILTransactionPointer ) cho các giao dịch có nguồn gốc từ IL và ABB để tái tạo ST-ticket và ST đã được giải mã.

4.2 Biểu đạt đồng thuận

Biểu diễn đồng thuận của tải trọng thực thi được mở rộng với hai danh sách bổ sung, st_tickets và decrypted_transactions .

st_tickets

st_tickets là danh sách các vé ST đã ký được tính phí khi bắt đầu xử lý khối và tương ứng với tập hợp các cam kết ST đang chờ xử lý (tức là chưa được tính phí). Người xây dựng phải bao gồm mọi vé ST mà nó đặt decrypt=1 trong cam kết ST của ABB của nó. Trong quá trình khôi phục (Mục 4.5), người xây dựng chỉ được bao gồm các vé ST tương ứng với các cam kết ST đang chờ xử lý trong ABB tổ tiên có liên quan với decrypt = 1 còn lại sau khi lọc xác định (loại bỏ trùng lặp, tính khả thi của nonce, khả năng tính phí).

Danh sách st_tickets có thứ tự chuẩn: nó được xây dựng bằng cách quét IL_data của ABB lập lịch theo committee_index tăng dần, sau đó quét commits[] theo commit_index tăng dần, và (đối với các gói) quét các mục theo tx_index tăng dần, và bao gồm vé ST cho mỗi mục còn lại sau khi lọc xác định.

decrypted_transactions

decrypted_transactions là danh sách các giao dịch ToB đã được giải mã được thực thi ToB trong khối hiện tại. Mỗi mục nhập chứa (ticket_index, plaintext_tx, ToB_fee_per_gas) , trong đó ticket_index là chỉ mục trỏ đến st_tickets của khối đã lên lịch các giao dịch hiện đang được giải mã (thường là khối trước đó). ticket_index được bao gồm như một con trỏ nhẹ khi xử lý khối, và một khối không hợp lệ nếu cùng một ticket_index xuất hiện nhiều hơn một lần trong decrypted_transactions . Bất cứ khi nào hai tập hợp st_tickets (Mục 4.5) trỏ đến cùng một danh sách decrypted_transactions , ticket_index sẽ được đánh số sao cho st_tickets sau được đánh số bắt đầu từ len(st_tickets) .

Mục nhập chỉ hợp lệ nếu hash_tree_root(RevealCommitmentPreimage(t.from, t.nonce, plaintext_tx, ToB_fee_per_gas)) == t.reveal_commitment cho t = st_tickets[ticket_index] . Thứ tự ToB phải giảm dần theo ToB_fee_per_gas , ưu tiên xử lý trường hợp bằng ticket_index , bỏ qua các mục không thể thực thi do thứ tự nonce khi đạt đến.

Các đặc tính của biểu diễn đồng thuận

Danh sách transactions thông thường vẫn là danh sách các byte giao dịch đầy đủ như trong định dạng tải trọng thực thi hiện nay. Khối beacon bao gồm một SignedExecutionPayloadBid cam kết với tải trọng đầy đủ, cụ thể là thông qua block_hash của nó như trong EIP-7732. Định dạng tải trọng dựa trên con trỏ chỉ được sử dụng như một tối ưu hóa mạng tạm thời: các nút tái tạo lại ExecutionPayload đầy đủ cục bộ, tính toán/xác minh block_hash kết quả so với tiêu đề đã cam kết, và sau đó máy khách lớp thực thi thực hiện và lưu trữ dữ liệu giao dịch đầy đủ như bình thường. Việc đồng bộ hóa hoạt động trên các khối đầy đủ; con trỏ không bao giờ trở thành một phần của đối tượng đồng thuận.

4.3 Cam kết gốc IL trong ABB để bảo vệ chống lại sự mơ hồ

Một trình bao gồm có thể truyền bá nhiều IL xung quanh thời điểm khối được xây dựng. Trình xây dựng có thể chỉ quan sát một trong những IL này trước khi cam kết tải trọng và quyết định bao gồm các giao dịch từ IL đó. Có nguy cơ các nút trên mạng thay vì quan sát IL từ trình bao gồm lại quan sát một IL khác, dẫn đến sự mơ hồ về IL nào mà trình xây dựng đã tham chiếu. Do đó, trình xây dựng xác định IL "chuẩn" duy nhất từ mỗi trình bao gồm bằng cách bao gồm một IL_root SSZ 32 byte cho mỗi IL_root trong ABB. Cụ thể, nếu tải trọng được phân phối tham chiếu bất kỳ giao dịch nào từ thành viên ủy ban i thông qua ILTransactionPointer(committee_index=i, ...) , thì ABB được bao gồm trong khối beacon phải bao gồm một IL_root không rỗng cho i .

Nếu trình xây dựng không quan sát thấy IL từ trình bao gồm, nó sẽ để trống toàn bộ mục đó. Nó có thể tự do bao gồm gốc của các IL đã quan sát được mà nó sẽ không tham chiếu trong khối của mình, nếu muốn làm mờ nội dung của payload trước khi tiết lộ, nhưng cũng có thể bỏ qua việc này.

Các nút được hướng dẫn luôn chuyển tiếp IL chuẩn ngay cả khi có sự mơ hồ (cùng với một IL bổ sung để chỉ ra sự mơ hồ đó). Nếu các nút đã chuyển tiếp hai IL từ cùng một bên bao gồm và biết rằng IL thứ ba là chuẩn, chúng cũng sẽ chuyển tiếp IL thứ ba khi nhận được nó. Trình xây dựng sẽ gieo lại các IL chuẩn của mình sau khi công bố giá thầu nếu nó quan sát thấy sự mơ hồ. Vẫn có thể phạt các bên bao gồm vì sự mơ hồ, và dường như việc này càng phù hợp hơn trong DPP, do tầm quan trọng ngày càng tăng của DA của các IL.

4.4 Tái tạo tải trọng

Sự phức tạp nằm ở chính ứng dụng khách CL. Quy trình làm việc như sau:

  1. Tiếp nhận IL: Máy khách CL nhận IL thông qua P2P và lưu trữ chúng trong bộ nhớ đệm cục bộ được đặt khóa bởi IL_root .
  2. Tiếp nhận tải trọng: Nó nhận SignedDistributedExecutionPayloadEnvelope , xác minh chữ ký của trình tạo và kiểm tra xem (slot, beacon_block_root, builder_index, block_hash) của nó có khớp với SignedExecutionPayloadBid đã được cam kết trong khối beacon hay không.
  3. Giải quyết và tái tạo:
    • Máy khách giải quyết tất cả các mục ILTransactionPointer bằng cách tra cứu IL_root chuẩn cho committee_index từ ABB trong khối beacon, lấy IL đó từ bộ nhớ đệm của nó (yêu cầu nếu thiếu) và đọc toàn bộ giao dịch tại tx_index . Nó hợp nhất các giao dịch này với transactions đầy đủ của envelope bằng cách chèn từng giao dịch IL vào position duy nhất của nó trong danh sách cuối cùng.
    • Máy khách xây dựng st_tickets một cách xác định từ ABB lập lịch (thông thường là ABB của khe hiện tại; trong quá trình phục hồi, là ABB tổ tiên chưa được tính phí). Nó quét IL_data → commits[] ->(bundle tx_index ) theo thứ tự chuẩn, áp dụng các quy tắc lọc xác định (loại bỏ trùng lặp, tính khả thi của nonce, khả năng tính phí), lấy các byte SealedTransaction tương ứng và trích xuất vé ST cho mỗi mục còn lại.
    • Máy khách xây dựng và sắp xếp các decrypted_transactions một cách xác định từ các cam kết ST mà việc giải mã đến hạn cho khối này: trong hoạt động bình thường, đây là các cam kết ST đã lên lịch của khối cha; trong quá trình khôi phục, điều này có thể bao gồm các cam kết đến hạn từ cả tổ tiên đầy đủ gần nhất và khối trống đầu tiên (Mục 4.5). Đối với mỗi cam kết như vậy có thông báo khóa đã phát hành hợp lệ mà ABB tuân thủ, nó sẽ giải mã để lấy RevealedTransaction(plaintext_tx, ToB_fee_per_gas) , xác định vé đã tính phí tương ứng t và xác minh: hash_tree_root(RevealCommitmentPreimage(t.from, t.nonce, plaintext_tx, ToB_fee_per_gas)) == t.reveal_commitment . Sau đó, nó tạo một mục nhập decrypted_transactions bao gồm ticket_index của t trong st_tickets . Cuối cùng, nó sắp xếp theo thứ tự giảm dần ToB_fee_per_gas , sử dụng ticket_index để phân định thứ tự khi có sự trùng lặp, và áp dụng kiểm tra khả năng thanh toán cho mỗi giao dịch theo thứ tự đó (loại bỏ bất kỳ mục nào không đạt yêu cầu).
  4. Xác minh: Máy khách tính toán block_hash kết quả và xác minh nó so với SignedExecutionPayloadBid trong khối beacon.
  5. Thực thi: Máy khách chuyển ExecutionPayload đã được định dạng hoàn chỉnh cho API của công cụ ( engine_newPayload ).
  6. Bỏ phiếu PTC: Các nút tiếp tục lấy các byte/khóa IL/ST bị thiếu và thử lại quá trình tái tạo khi dữ liệu mới đến. Các thành viên PTC bỏ phiếu "kịp thời" tại T_4 chỉ khi họ đã tái tạo hoàn toàn dữ liệu và xác minh block_hash ; nếu không , họ bỏ phiếu "không kịp thời".

4.5 Khôi phục khi bị từ chối tải trọng

Người gửi có quyền nhận các giao dịch đã giải mã của họ được đưa vào khối tiếp theo nếu ABB của khối beacon chỉ định mục gas_obligation chính xác cho cam kết ST của họ, tổng của tất cả các mục gas_obligation nằm trong giới hạn ToB_gas_limit và cam kết ST cũng như khóa giải mã của họ có sẵn. Tuy nhiên, tải trọng n n có thể bị từ chối, không phải do lỗi của người gửi hoặc người giải mã, sau khi các khóa giải mã được phát hành. Trong trường hợp này, tải trọng tiếp theo phải bao gồm cả các ST đã giải mã được lên lịch cho tải trọng n n và các ST có khóa được phát hành trong khe n n , được lên lịch cho n+1 n + 1 .

Cụ thể, các ST đã được giải mã của một khối là các ST thỏa mãn các điều kiện sau:

  • có sẵn byte và khóa ST.
  • được liệt kê trong ABB được chỉ định chính xác, trong đó ABB
    • Đây không phải là ABB của vị trí hiện tại.
    • Các cam kết ST đã được giải mã của nó vẫn chưa được đưa lên chuỗi khối.

Do đó, khi một khối trống (không có dữ liệu), dữ liệu tiếp theo phải bao gồm các ST đã được giải mã mà khối trống đó đáng lẽ phải bao gồm, cũng như các ST (đã được giải mã) mà khối trống đó đã cam kết trong ABB. Dữ liệu phục hồi sau đó không thể cam kết với các ST mới (như Potuz đã đề xuất ở đây ), mà thay vào đó phải cho biết liệu các cam kết ST của khối trống hiện có sẵn hay không (byte + khóa), bằng cách sử dụng bit key_adherence . Các bit này cũng đánh dấu các vé ST, mà trong quá trình phục hồi phải được đưa vào cùng một dữ liệu với các ST đã được giải mã. Nếu khối không bao gồm các ST đã được giải mã sao cho chuỗi được phục hồi, nó cũng phải được bỏ phiếu là trống, và nhiệm vụ phục hồi lại thuộc về dữ liệu tiếp theo.

Theo đặc tả cơ bản, các ST đã giải mã được phân bổ tối đa 1/4 giới hạn gas. Điều này đảm bảo rằng khi một tải trọng bị thiếu, tải trọng tiếp theo có thể bao gồm hai bộ ST đã giải mã, tiêu thụ tối đa 1/2 giới hạn gas của khối.

5. Hé lộ các tùy chọn trong LUCID

Một mối lo ngại tiềm ẩn trong sơ đồ cam kết-tiết lộ giao dịch kín là tính tùy chọn của việc tiết lộ. Một số giao dịch kín sẽ được sử dụng để "chạy ngược thời gian", ví dụ như, các thay đổi về giá CEX.

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