Phát trực tuyến Blob

Bài viết được thực hiện bởi @QED , @fradamt , @Julian với lời cảm ơn đặc biệt đến @soispoke , @aelowsson và @casparschwa vì những đóng góp quý báu của họ.

Chúng tôi đề xuất truyền phát dữ liệu khối (blob streaming ): đưa việc truyền trước dữ liệu khối liên tục, được lấy mẫu, trở thành một cơ chế ưu tiên trong giao thức, song song với làn truyền dữ liệu khối quan trọng hiện có. Việc truyền trước dữ liệu đã diễn ra thông qua nhóm dữ liệu khối (blobpool), nhưng với các đảm bảo yếu và không có lấy mẫu về tính khả dụng của dữ liệu, nó không thể được tin cậy để mở rộng thông lượng một cách an toàn. Truyền phát dữ liệu khối giới thiệu một cơ chế vé để giới hạn tốc độ truyền trước dữ liệu, cho phép mở rộng việc lấy mẫu một cách đáng tin cậy cho toàn bộ khe thời gian mà không kéo dài đường dẫn quan trọng — do đó giảm thiểu vấn đề tùy chọn miễn phí. Ngoài việc mở rộng quy mô, cơ chế này cũng cho phép khả năng chống kiểm duyệt hoàn toàn đối với các giao dịch dữ liệu khối.

Giới thiệu

Định nghĩa: JIT và AOT blobs
Chúng ta nói rằng một khối dữ liệu (blob) là JIT (just-in-time) nếu nó được truyền tải trong đường dẫn quan trọng của khe thời gian yêu cầu sự có mặt của nó. Ngược lại, chúng ta nói rằng một khối dữ liệu là AOT (ahead-of-time).

Cơ chế DA của Ethereum ban đầu được thiết kế dựa trên các blob JIT, với sự lan truyền trong đường dẫn quan trọng trên Lớp Đồng thuận (CL). Cơ chế này đã được nâng cấp thông qua PeerDAS để cho phép lấy mẫu khả dụng dữ liệu. Tuy nhiên, trên thực tế, blobpool của Lớp Thực thi (EL) đã cho phép các blob AOT bằng cách cung cấp một con đường để lan truyền trước.

Mặc dù về nguyên tắc, các blob JIT cho phép các chức năng mà blob AOT không thể cung cấp — việc đồng tạo các khối và blob là cần thiết cho khả năng kết hợp đồng bộ với L1 — nhưng trên thực tế, tất cả việc sử dụng blob hiện tại đều là AOT. Do đó, blobpool đã cho phép công việc được chuyển ra khỏi đường dẫn quan trọng, phân bổ việc sử dụng băng thông theo thời gian. Tuy nhiên, việc truyền tải trước này diễn ra với các đảm bảo yếu và không có lấy mẫu khả dụng dữ liệu, vì vậy lợi ích về khả năng mở rộng mà nó có thể mang lại là có hạn.

Ảnh 4440×2600, dung lượng 370 KB

Hình 1. Dòng thời gian của khe thời gian trực quan hóa định nghĩa JIT/AOT. Các khối dữ liệu AOT (màu cam) được truyền trước đường dẫn quan trọng; các khối dữ liệu JIT (màu vàng) được truyền trong đường dẫn quan trọng của khe thời gian yêu cầu sự sẵn có của chúng. Bất kể khi nào và bằng cách nào quá trình truyền diễn ra, các trình xác nhận sẽ kiểm tra tính khả dụng của tất cả các khối dữ liệu.

Trong bài viết này, chúng tôi đề xuất phương pháp truyền tải blob : thiết lập các blob AOT như một làn đường ưu tiên, dựa trên vé — nơi người dùng mua quyền truyền tải blob trước thời hạn — song song với một làn đường JIT được định giá tức thời — có thể được coi là các blob riêng tư hiện nay. Làn đường truyền tải này mang tính chất cộng gộp: các blob AOT được truyền tải trước đường dẫn quan trọng trong khi các blob JIT được truyền tải bên trong đường dẫn đó. Quan trọng hơn, việc giới hạn tốc độ dựa trên vé sẽ giới hạn tải truyền tải, làm cho việc truyền tải trước trở nên đáng tin cậy — chế độ xem nút nhất quán, khả năng chống lại tấn công DoS rõ ràng. Hơn nữa, vì quyền truyền tải được tách rời khỏi việc xác định tính khả dụng (không giống như trong blobpool), việc lấy mẫu tính khả dụng của dữ liệu có thể được xếp lớp an toàn lên trên, mở rộng cửa sổ lấy mẫu đến toàn bộ khe và cho phép thông lượng blob mở rộng. Do đó, cơ chế được đề xuất có thể được xem như một giải pháp thay thế cho các cơ chế lấy mẫu blobpool (ví dụ: phân mảnh dọc ,phân mảnh ngang ) có khả năng đạt được khả năng mở rộng thông lượng tương tự đồng thời cung cấp:

• Gửi người dùng: đảm bảo khả năng chống kiểm duyệt mạnh mẽ, khả năng mua trước không gian blob, nới lỏng các hạn chế về mempool đối với các giao dịch blob.
• Đối với giao thức: giới hạn tải rõ ràng và cửa sổ lan truyền đường dẫn quan trọng nhỏ hơn, giúp giảm thiểu vấn đề tùy chọn tự do .

Ảnh 3444×1240 201 KB

Hình 2. Sơ đồ hai làn của một khe thời gian. Các khối dữ liệu AOT được lan truyền trước đường dẫn quan trọng, trải đều theo thời gian; các khối dữ liệu JIT được lan truyền trong đường dẫn quan trọng cùng với dữ liệu tải trọng. Các bộ kiểm chứng xác minh tính khả dụng của tất cả các khối dữ liệu.

Thiết kế dựa trên vé có thể hỗ trợ cả blob JIT và AOT. Tuy nhiên, chúng tôi chọn giữ lại lộ trình JIT hiện có, trong đó dung lượng được định giá theo thời gian thực thay vì phân bổ bằng vé, để đáp ứng các trường hợp sử dụng không liên quan đến việc lập kế hoạch dung lượng trước, chẳng hạn như các bản tổng hợp (thuần túy) và cuối cùng là việc sử dụng blob bởi chính L1 ( các khối trong blob , các bản tổng hợp gốc ).

Trước khi đi sâu vào chi tiết của cơ chế, hãy cùng phân tích lý do tại sao việc giới thiệu làn AOT lại đáng giá, bằng cách xem xét khía cạnh cung và cầu của AOT và JIT blobs.

Góc nhìn của giao thức (phía cung ứng)

Thông lượng xử lý khối dữ liệu AOT mà hệ thống có thể cung cấp cao hơn đáng kể so với thông lượng xử lý JIT thuần túy, bởi vì các khối dữ liệu JIT phải lan truyền trong một khoảng thời gian hẹp, bị giới hạn bởi:

• Người đề xuất và nhà thầu tiếp theo cần xác định tính khả dụng trước khi hành động.
• Vấn đề lựa chọn miễn phí , và vấn đề này càng trở nên nghiêm trọng hơn khi chúng ta kéo dài thời gian lựa chọn.

Điều này tạo ra sự tăng đột biến về băng thông trong cửa sổ truyền dẫn trong khi băng thông thực tế không được sử dụng trong phần còn lại của khe thời gian. Với việc truyền dẫn trước từ các khối AOT, quá trình truyền dẫn trải rộng trên một cửa sổ thời gian lớn hơn (xem Hình 2), làm mượt mức tiêu thụ băng thông và tránh tắc nghẽn. Truyền dẫn trước hiệu quả có thể đạt được mức sử dụng băng thông ổn định ở công suất tối đa, dẫn đến tăng thông lượng.

ảnh 1462×1217 103 KB

Hình 3. Minh họa sự biến thiên băng thông trong suốt khe thời gian giữa các khối dữ liệu JIT và AOT. Các khối dữ liệu JIT yêu cầu băng thông trong khoảng thời gian ngắn hơn, dẫn đến mức tiêu thụ không ổn định hơn, trong khi sự lan truyền của các khối dữ liệu AOT được trải rộng hơn, dẫn đến mức tiêu thụ băng thông mượt mà hơn.

Góc nhìn của người dùng (phía cầu)

Trường hợp sử dụng chính của các khối JIT cho rollup là khả năng kết hợp đồng bộ với L1, điều này đòi hỏi trình tự dựa trên L1 cũng như xác thực thời gian thực. Ngược lại, các rollup được sắp xếp trình tự bên ngoài, cũng như các rollup dựa trên L1 với xác nhận trước (xem ví dụ Taiko ), có thể sử dụng các khối AOT.

Cũng có thể có một thiết kế lai của các rollup dựa trên việc kết hợp cả xác nhận trước và khả năng kết hợp đồng bộ, về cơ bản bằng cách sử dụng xác nhận trước trong hầu hết thời gian của khe L1 nhưng chuyển sang chế độ dựa trên trong giai đoạn sản xuất khối L1, sao cho các tương tác đồng bộ có thể thực hiện được trong giai đoạn này . Các rollup như vậy có thể sử dụng hỗn hợp các blob JIT và AOT, với các blob JIT là cần thiết trong giai đoạn sản xuất khối L1, để cho phép các tương tác đồng bộ với L1.

Điều quan trọng là, các khối dữ liệu JIT cũng trở nên quan trọng đối với L1, khi chúng ta nhìn về tương lai mà chúng ta đang nhanh chóng hướng tới, nơi zkEVM + DAS được sử dụng để mở rộng quy mô của chính L1 bằng cách đặt tải trọng của nó vào các khối dữ liệu , về cơ bản biến EL thành một quá trình tổng hợp tính hợp lệ.

Ngay cả khi đã xem xét các trường hợp sử dụng này, vẫn khó có thể tranh luận chính xác về việc nhu cầu đối với blob JIT so với AOT sẽ định hình như thế nào trong tương lai. Chúng ta biết rằng khả năng kết hợp đồng bộ mang lại lợi ích, nhưng lợi ích đó chính xác là gì? Chúng ta biết rằng nó tốn kém, nhưng chi phí cụ thể là bao nhiêu? Chúng ta biết rằng L1 sẽ cần blob JIT, nhưng nó sẽ tiêu thụ bao nhiêu phần trăm tổng thông lượng blob?

Chúng tôi cho rằng chúng ta không cần phải dự đoán chính xác nhu cầu trong tương lai của hai loại blob này để xác định xem việc bổ sung thêm cơ chế cho blob AOT vào giao thức có đáng giá hay không. Chừng nào còn nhu cầu đáng kể đối với blob AOT (điều này dường như rất có khả năng xảy ra, vì không phải tất cả các rollup đều muốn được dựa hoàn toàn vào AOT, và ngay cả một L1 siêu mở rộng cũng khó có thể tiêu thụ hết thông lượng blob), thì tất cả người dùng blob đều được hưởng lợi từ việc chuyển thông lượng blob AOT sang làn riêng của nó. Như đã lập luận ở trên, blob AOT có thể sử dụng băng thông bên ngoài đường dẫn quan trọng hiện đang bị bỏ trống. Việc cho phép chúng sử dụng các tài nguyên đó sẽ giải phóng đường dẫn quan trọng cho blob JIT. Điều này có nghĩa là việc giới thiệu blob AOT không chỉ mang lại lợi ích cho người dùng sử dụng chúng, mà còn cho người dùng blob JIT, những người có quyền truy cập vào nhiều tài nguyên đường dẫn quan trọng bị hạn chế hơn.

Thiết kế

Chúng tôi sẽ mô tả thiết kế, bắt đầu từ hệ thống blobpool hiện có và hướng tới kiến trúc hai làn hoàn chỉnh.

Tóm tắt: Vé tham dự blobpool

Hiện nay, việc truyền tải trước diễn ra thông qua EL blobpool, nhưng không có cơ chế nào trong giao thức để phân bổ băng thông truyền tải. Khi thông lượng blob tăng lên, blobpool nhất thiết phải bị phân mảnh — nó không có cách nào toàn cục để hạn chế dòng chảy vào, và do đó chỉ có thể làm điều đó cục bộ, ở cấp độ nút. Hơn nữa, blobpool không được hưởng lợi từ việc lấy mẫu khả dụng dữ liệu, và việc giới thiệu nó rất khó khăn: mô hình bảo mật của blobpool dựa trên việc chỉ truyền tải các giao dịch hợp lệ, có thể bao gồm, điều này khó đảm bảo khi lấy mẫu, vì một nút lấy mẫu không thể tự mình xác minh đầy đủ tính khả dụng của blob.

Ảnh 4156×1800 275 KB

Đã có nhiều bài viết về các cơ chế cấp vé blob (xem tại đây , đây , đây ), đề xuất đấu giá quyền truyền bá blob. Gần đây, một cơ chế cấp vé blobpool đã được đề xuất như một bước đi theo hướng này, bổ sung cho blobpool để đảm bảo việc truyền bá trước các blob trong blobpool có khả năng chống lại các cuộc tấn công từ chối dịch vụ (DoS), và duy trì sự đảm bảo đó ngay cả khi được triển khai cùng với cơ chế lấy mẫu blobpool (xem mempool phân mảnh theo chiều dọc và EIP-8070: Sparse Blobpool ).

Để gửi và lan truyền một blob trong blobpool, người gửi cần phải có một vé hợp lệ, được cấp thông qua tương tác với hợp đồng vé được chỉ định (ví dụ: thực hiện đấu giá giá đầu tiên). Điều này sẽ đảm bảo giới hạn số lượng blob được lan truyền qua blobpool và phân bổ không gian hạn chế một cách công bằng. Vì việc truy cập blobpool hiện được kiểm soát bằng vé trả trước thay vì kiểm tra tính hợp lệ, việc lấy mẫu cũng có thể được thực hiện một cách an toàn — các nút không còn cần phải xác minh tính khả dụng đầy đủ của blob để quyết định có lan truyền giao dịch hay không.

Ảnh 4156×1744 321 KB

Hình 5. Bổ sung thêm vé vào blobpool.

Vé Blob

Vé Blob đưa khái niệm vé tiến xa hơn, chuyển quá trình truyền tải trước sang CL và tích hợp sâu hơn vào quy trình đảm bảo tính khả dụng của dữ liệu. Điều này khác với vé blobpool ở hai điểm chính:

1. Đối với các blob AOT, người dùng chỉ cần một "vé" để đưa blob đó vào chuỗi. Cụ thể, các giao dịch blob AOT không phải trả phí cơ sở blob khi được đưa vào ; chúng chỉ trả phí gas thông thường. Do đó, tên gọi là "vé blob" thay vì "vé blobpool " — thứ bạn mua bằng "vé" thực chất là không gian blob, chứ không chỉ là không gian blobpool. Từ góc độ của giao thức, điều này là bởi vì quá trình lan truyền là nơi chúng ta thực sự tiêu thụ các tài nguyên băng thông khan hiếm. (Các blob JIT sẽ được thảo luận sau và vẫn được định giá theo giá giao ngay.)
2. Quá trình lan truyền chuyển sang CL , tái sử dụng cơ sở hạ tầng đã được phát triển sẵn cho việc lấy mẫu DA, điều mà nếu không sẽ cần phải được sao chép một cách không cần thiết trên EL. Hơn nữa, việc lấy mẫu DA về cơ bản là một phần của cơ chế đồng thuận, bởi vì DA là điều kiện tiên quyết để nhập một khối vào lựa chọn phân nhánh. Ngày nay, thay vào đó, chúng ta kết hợp việc lan truyền trước trên EL và việc thực thi tính khả dụng trên CL bằng cách gọi API của công cụ getBlobs .

Quy trình làm việc với vé như sau:

1. Mua vé : Bằng cách gửi giao dịch đến hợp đồng vé, người dùng có thể có được quyền nhân bản một khối dữ liệu (blob) vào một thời điểm nào đó trong tương lai.
2. Sự lan truyền :
   1. Blob : Sử dụng vé (vào thời gian được chỉ định), người dùng đẩy dữ liệu blob thông qua cơ sở hạ tầng lấy mẫu CL.
   2. Giao dịch Blob : Cũng sử dụng vé, giao dịch blob ( không có dữ liệu blob ) sẽ được chuyển đến mempool thông thường .
3. Đảm bảo tính bao gồm và tính khả dụng : Khi một giao dịch blob được bao gồm, các bên chứng thực sẽ đảm bảo tính khả dụng của các blob liên quan (được xác định bởi blob_tx.versioned_hashes ), chính xác như hiện tại.

Ảnh 4680×1960 365 KB

Hình 6. Quy trình làm việc của người dùng với vé blob. Người dùng nhận được vé, truyền blob trên CL và gửi giao dịch blob đến mempool EL. Sau khi được đưa vào một khối, giao dịch blob hoạt động chính xác như hiện nay, điều kiện tính hợp lệ của khối dựa trên sự sẵn có của các blob liên quan và do đó cung cấp cho người dùng sự đảm bảo tính khả dụng nghiêm ngặt.

Mỗi vé cho phép quyền nhân giống:

• Một đốm trên CL (hướng lan truyền bên phải)
• Nhiều giao dịch blob trên EL. Ví dụ, tối đa 16 giao dịch, tương ứng với số lượng giao dịch blob tối đa ( maxTxsPerAccount ) hiện được cho phép bởi Geth blobpool, cũng như số lượng tối đa mặc định được đảm bảo cho các giao dịch thông thường trong Geth mempool ( AccountSlots ). Tuy nhiên, giới hạn ở đây là trên mỗi ticket, không phải trên mỗi tài khoản .

Hai quyền này độc lập với nhau — CL và EL theo dõi việc sử dụng vé một cách riêng biệt. Điều này có nghĩa là người giữ vé có thể truyền dữ liệu blob của họ trên CL và giao dịch blob của họ trên EL song song, mà không cần sự phối hợp giữa các lớp. Việc cho phép nhiều giao dịch blob được truyền trong mempool của EL với một vé duy nhất cho phép người dùng thực hiện gửi lại mà không cần mua thêm vé, ví dụ như trong trường hợp thay đổi phí cơ bản làm vô hiệu hóa giao dịch.

Ghi chú của người dùng : Việc liên kết việc lan truyền giao dịch blob với vé, thay vì với tính hợp lệ của chúng, cho phép mempool hoạt động mà không cần tuân thủ các quy tắc nghiêm ngặt hiện đang áp dụng cho chúng. Cụ thể, cùng một địa chỉ có thể được phép xếp hàng nhiều giao dịch blob song song, bởi vì việc một giao dịch làm mất hiệu lực các giao dịch khác không phải là vấn đề đáng lo ngại — một lần nữa, quyền lan truyền là về vé, không phải về tính hợp lệ! Đây là một điểm khó khăn cụ thể đối với người gửi blob, nếu không được giải quyết thì tình trạng này sẽ chỉ trở nên tồi tệ hơn khi thông lượng của từng L2 tăng lên, vì giới hạn về số lượng blob trên mỗi giao dịch sẽ dẫn đến sự gia tăng tốc độ giao dịch từ mỗi L2.

Thiết kế lai: AOT + JIT

Dựa trên những gì chúng ta đã thảo luận cho đến nay, về nguyên tắc, AOT và JIT có thể có cấu trúc giống nhau: chúng ta có thể thiết kế hệ thống sao cho tất cả dung lượng khối, bao gồm cả dung lượng đường dẫn quan trọng, được bán thông qua vé. Trong một hệ thống như vậy, sự khác biệt giữa JIT và AOT chỉ đơn thuần là về thời gian lan truyền.

Thiết kế chỉ sử dụng vé đó hoạt động tốt đối với nhu cầu xử lý dữ liệu theo khối của các tác nhân có thể lập kế hoạch thông lượng và mua vé trước, chẳng hạn như các nhà điều hành của các quy trình tổng hợp được sắp xếp theo trình tự bên ngoài. Tuy nhiên, nó sẽ gặp trục trặc khi nhu cầu bao gồm luồng người dùng mở mà không có trình quản lý vé chuẩn: người dùng không thể được kỳ vọng sẽ tự tìm nguồn vé trước, và việc mặc định biến các nhà xây dựng thành các vé trung gian sẽ tạo ra áp lực về hàng tồn kho, vốn và sự tập trung hóa. Trong các đợt tăng đột biến về nhu cầu, lượng vé tồn kho có thể trở thành nút thắt cổ chai ngay cả khi mạng vẫn còn khả năng truyền tải đường dẫn quan trọng. Điều này không chỉ áp dụng cho chính L1 khi nó cuối cùng sử dụng các khối ( các khối trong khối ), mà còn áp dụng cho các quy trình tổng hợp dựa trên khối.

Vì lý do này, kiến trúc cuối cùng trong bài đăng này được thiết kế theo kiểu lai ghép rõ ràng, kết hợp giữa các blob AOT dựa trên vé cùng với một làn JIT được định giá theo giá giao ngay . Người dùng cuối sau đó có thể thực hiện giao dịch và thanh toán trực tiếp cho các tài nguyên blob quan trọng (blob JIT, thông qua phí cơ bản của blob), trong khi luồng được lên kế hoạch (blob AOT) có thể sử dụng vé (và được hưởng lợi từ việc này). Trong phần dữ liệu gửi đi, sự phân tách này được thể hiện rõ ràng bằng cách giới thiệu hai danh sách băm có phiên bản:

• jit_versioned_hashes : dành cho các blob mà trình tạo cam kết tức thời. Chúng được lan truyền (lấy mẫu) cùng với tải trọng và thanh toán cho tài nguyên của chúng ngay lập tức (thông qua phí cơ bản blob JIT được đặt bằng \text{bf}^{AOT} bf A O T - xem phần hợp đồng vé để biết thêm chi tiết), chính xác như làn blob hiện tại.
• aot_versioned_hashes : các blob đã được truyền tải trước đó cùng với vé , hiện đang được xác nhận là có sẵn. Việc thanh toán cho tài nguyên blob đã được thực hiện khi mua vé, không cần thanh toán ngay lập tức.

Cả hai danh sách đều quy định tính hợp lệ của tải trọng dựa trên tính khả dụng : tất cả các blob tương ứng với jit_versioned_hashes và aot_versioned_hashes phải khả dụng thì tải trọng mới trở thành chuẩn. Sự khác biệt chỉ nằm ở cách thức thanh toán và tiêu thụ tài nguyên truyền tải.

Tóm lại, tài nguyên lan truyền của mạng lưới đã được phân chia rõ ràng thành hai nhóm: đường dẫn quan trọng và ngoài đường dẫn quan trọng. Các thị trường khác nhau chi phối việc phân bổ hai tài nguyên này: một cuộc đấu giá vé trên chuỗi trước thời hạn cho dung lượng lan truyền trước và một thị trường giao ngay tức thời cho việc lan truyền trên đường dẫn quan trọng, nơi người xây dựng có quyền quyết định cuối cùng về việc đưa vào.

Cơ chế JIT là sản phẩm tương tự như cơ chế blob lane hiện nay: truyền tải theo đường dẫn quan trọng, việc đưa vào do người xây dựng điều khiển và thanh toán tức thời thông qua phí cơ bản của blob khi được đưa vào. Tuy nhiên, cần lưu ý rằng vì không có quá trình truyền tải trước blobpool cho các blob JIT, người dùng sẽ phải truyền tải blob của họ trực tiếp cho người xây dựng. Do đó, các blob JIT tương ứng với các blob riêng tư hiện nay . Cơ chế AOT mang tính bổ sung, cung cấp một đường dẫn bổ sung với các đặc tính khác nhau: mua vé trước, truyền tải trước và do đó có dung lượng cao hơn, và, như chúng ta sẽ thấy, đảm bảo khả năng chống kiểm duyệt (CR). Đường dẫn này trở thành mặc định cho bất kỳ blob nào có thể được truyền tải trước.

Năng lực JIT so với AOT

Một câu hỏi cơ bản nảy sinh trong thiết kế lai là về sự phân bổ tài nguyên: chúng ta muốn dành bao nhiêu dung lượng mạng để truyền tải dữ liệu blob cho các blob JIT và bao nhiêu cho các blob AOT? Chúng tôi đề xuất một thiết kế trong đó các ràng buộc về dung lượng được điều chỉnh bởi ba tham số, cần được thiết lập tương tự như cách thiết lập mục tiêu và giới hạn gas cho blob hiện nay:

• B_1 B 1 ( JIT max ): số lượng tối đa các khối JIT trên mỗi khe. Đây là giới hạn trên được xác định bởi thời gian chúng ta sẵn sàng dành cho đường dẫn quan trọng — và tương ứng, kích thước cửa sổ tùy chọn tự do mà chúng ta chấp nhận.
• B_2 B 2 ( blob (JIT + AOT) max ): số lượng blob tối đa trên mỗi khe thời gian, giới hạn tổng hợp cho JIT + AOT. Giới hạn này được xác định bởi thông lượng lan truyền tổng thể của mạng trong suốt một khe thời gian.
• R \leq B_1 R ≤ B 1 ( dung lượng JIT dự trữ ): một phần dung lượng JIT được bảo vệ khỏi việc sử dụng AOT.

Các tham số này tạo ra các quy tắc sau cho một vị trí n nhất định:

1. Bán vé AOT : Có thể bán tối đa B_2 - R B 2 − R vé cho một khung giờ trong tương lai. Vì R R được dành riêng cho JIT, nên tối đa B_2 - R B 2 − R khối dữ liệu có thể được lên lịch trước.
2. Dung lượng JIT : Nếu a ≤ B₂ - R a ≤ B₂ − R các blob AOT đã được lên lịch cho khe n n , thì tối đa \min(B₁,\, B₂ - a ) min ( B₁ , B 2 − a ) Các blob JIT có thể được bao gồm. Điều này đảm bảo ít nhất R R dung lượng JIT và cho phép JIT mở rộng lên tới B_1 B 1 khi nhu cầu AOT thấp.

B_2 là một ràng buộc hoàn toàn mang tính kỹ thuật, phản ánh tổng ngân sách truyền dẫn của mạng trong một khe thời gian. B_1 yêu cầu sự linh hoạt hơn: nó bị giới hạn bởi cấu trúc khe thời gian nhưng có thể được đặt thấp hơn để hạn chế cửa sổ tùy chọn tự do. Tuy nhiên, B_1 không có quan điểm cụ thể về JIT so với AOT — tất cả dung lượng vượt quá R đều được chia sẻ, vì vậy B_1 cao hơn chỉ đơn giản cho phép JIT mở rộng hơn nữa vào nhóm chia sẻ khi nhu cầu AOT thấp.

Lựa chọn thiết kế thú vị nhất là R R. Dung lượng không dành riêng B_2 - R B 2 − R là một nhóm dùng chung có thể sử dụng được bởi cả AOT (thông qua vé) và JIT (nếu nhu cầu của AOT còn chỗ). Việc đặt R R quá thấp có nguy cơ không đáp ứng đủ nhu cầu của JIT, điều này đặc biệt có vấn đề khi chính L1 dựa vào các khối dữ liệu JIT. Việc đặt R R quá cao sẽ đẩy dung lượng lẽ ra có thể được bán dưới dạng vé vào đường dẫn chỉ dành cho JIT; dung lượng dành riêng không bao giờ bị mất hoàn toàn — về nguyên tắc, bất kỳ hoạt động AOT nào cũng có thể sử dụng khối dữ liệu JIT — nhưng người dùng buộc phải thông qua các nhà xây dựng trực tiếp và mất đi sự đảm bảo về khả năng chống kiểm duyệt của giao thức.

Giá cơ bản

Về cơ bản, cơ chế cập nhật phí cơ sở blob hiện tại có thể được áp dụng như hiện nay. Với các giới hạn đã nêu, \min(B_1,\, B_2 - a) + B_2 - R min ( B 1 , B 2 − a ) + B 2 − R blobs có thể được bán trong khe, \min(B_1,\, B_2 - a) min ( B 1 , B 2 − a ) là các blob JIT cho khe thời gian hiện tại và B_2 - R B 2 − R là các vé cho khe thời gian trong tương lai. Tối đa B_1 + B_2 - R B 1 + B 2 − R blob có thể được bán trong trường hợp số lượng blob AOT được lên lịch cho khe thời gian thấp. blobSchedule.target có thể được đặt tại B_2\times2/3 B 2 × 2 / 3 và blob_gas_used được tính toán từ tổng số blob JIT và vé AOT được bán trong khe thời gian, nhân với GAS_PER_BLOB . Trên thực tế, chúng ta cũng sẽ thêm vào blobSchedule các biến mới B_1 B 1 , B_2 B 2 và R R , áp đặt các ràng buộc về dung lượng chi tiết hơn mà cơ chế tổng thể yêu cầu.

Cơ chế hợp đồng vé và định giá nhằm đạt hiệu suất cao hơn.

Như đã đề cập trước đó, để mua vé, một giao dịch được gửi đến hợp đồng vé chuyên dụng. Hợp đồng này có hai chức năng chính: tạo ra vé mới và cập nhật vé cũ nếu chúng đã được sử dụng hoặc hết hạn. Hợp đồng vé tạo ra vé AOT theo các ràng buộc về dung lượng đã nêu. Giá vé được tính theo phí cơ bản AOT, \text{bf}^{AOT} bf A O T , được thiết lập bởi dung lượng blob AOT mục tiêu thông qua cơ chế điều khiển kiểu EIP-1559. Như chúng ta đã lưu ý trước đó, phí cơ bản cho JIT được đặt bằng \text{bf}^{AOT} bf A O T .

Cụ thể, điều này có nghĩa là \text{bf}^{AOT} bf A O T tăng hoặc giảm từ vị trí i i đến vị trí i+1 i + 1 nếu số vé bán ra nhiều hơn hoặc ít hơn tương ứng so với \text{AOT}_{\text{target}} AOT target . Ở đây , \text{AOT}_{\text{target}} AOT target là một hàm của dung lượng blob AOT B_2 - R B 2 − R eg \text{AOT}_{\text{target}}=B_2 - R AOT target = B 2 − R . Quy tắc cập nhật cho phí cơ bản có thể hoàn toàn giống như quy tắc được sử dụng cho EIP-1559:

$$\text{bf}^{AOT} {i+1} = \text{bf}^{AOT} {i} \times \Big(1 + \frac{1}{8} \times \frac{\text{AOT} {i} - \text{AOT} {\text{target}}}{\text{AOT}_{\text{target}}}\Big)$$
trong đó \text{AOT}_{i} AOT i là số vé đã bán trong khe i i .

Mỗi giao dịch vé cần chỉ định bốn biến: base_fee , auction_bid , number of tickets — từ đó hợp đồng có thể trừ đi auction_bid_per_ticket = auction_bid / number of tickets , base_fee_per_ticket = base_fee / number of tickets — và sender_adress , chỉ định địa chỉ nhận vé. Để giao dịch vé đủ điều kiện nhận vé, điều kiện base_fee_per_ticket \geq\text{bf}^{AOT} ≥ bf A O T cần được thỏa mãn. Các giao dịch sau đó được sắp xếp theo thứ tự giảm dần auction_bid_per_ticket và vé được phân bổ tối đa là 2\times(B_2 - R) 2 × ( B 2 − R ) .

Trong trường hợp nhu cầu vượt quá (tức là nếu tổng số vé mà người dùng đang cố gắng mua trong một khe thời gian nhất định vượt quá giới hạn 2×(B₂ - R) 2 × ( B₂ - R ) ) , cả base_fee và auction_bid của các giao dịch mua được vé sẽ bị hủy bỏ, trong khi các giá trị tương ứng của các giao dịch không mua được vé sẽ được trả lại địa chỉ người gửi. Hãy nhớ rằng dung lượng thông lượng của AOT blob là B₂ - R B₂ - R. Do đó, tất cả các vé (lên đến B₂ - R B₂ - R vì chúng ta đặt giới hạn gấp đôi dung lượng) tương ứng với các giao dịch ở cuối danh sách giao dịch được sắp xếp sẽ trở nên hợp lệ cho khe thời gian tiếp theo. Ví dụ, giả sử B₂ - R = 5 và thứ tự người đấu giá trong khe thời gian N như sau: Alice: 3 vé, Bob: 4 vé, Charlie: 3 vé . Khi đó , Alice sẽ nhận được 3 vé cho khe thời gian N + 1 . Bob sẽ nhận được 2 vé cho vị trí N+ 1 và 2 vé cho vị trí N+ 2 , trong khi Charlie sẽ nhận được 3 vé cho vị trí N+ 2. Trong trường hợp nhu cầu không vượt quá 2 × ( B₂ - R) × ( B₂ - R ) , một giá trị tương ứng với bf^{AOT} × bf AOT × số vé number of tickets bị tiêu hao từ mỗi giao dịch.

Cuối cùng, cần lưu ý rằng không có lý do gì chỉ bán vé cho khung giờ tiếp theo. Thay vào đó, chúng ta có thể xem xét việc bán vé trong khung giờ N , có hiệu lực cho khung giờ N+ k . Việc có thể mua vé trước đó khá lâu có thể mang lại lợi ích quan trọng cho các L2, vì họ có thể sử dụng điều này để định giá giao dịch của mình chính xác hơn dựa trên kiến thức tiên nghiệm về giá của một blob nhất định. Việc xác định chi tiết của điều này — k nên lớn đến mức nào? Người dùng có nên được phép chỉ định khung giờ họ muốn mua vé từ một loạt các tùy chọn hay không ? — và vân vân vẫn là một câu hỏi mở ở thời điểm này.

Kháng cự kiểm duyệt

Một lời hứa quan trọng của làn đường AOT là khả năng chống kiểm duyệt đối với các giao dịch blob. Vé cho phép chúng ta xác định một tập hợp blob bị hạn chế mà tính khả dụng của chúng có thể được thiết lập bởi một ủy ban, để chúng có thể được đảm bảo đưa vào danh sách — mỗi vé cũng có thể được coi là cấp vai trò người đề xuất danh sách đưa vào, cho một blob duy nhất . Tuy nhiên, hệ thống cơ bản chỉ với vé blob không hoàn toàn đáp ứng được điều này. Trong phần tiếp theo, chúng ta sẽ xác định lỗ hổng, chỉ ra cách ghi lại tính khả dụng trên chuỗi thông qua hợp đồng DA giải quyết nó và xây dựng các đảm bảo đưa vào từ đầu đến cuối.

Những hạn chế của vé blob

Vé blob là một cải tiến rất có ý nghĩa, nhưng vẫn để lại một lỗ hổng trong câu chuyện về khả năng chống kiểm duyệt. FOCIL là một cơ chế chống kiểm duyệt cho phép một ủy ban đảm bảo việc đưa vào một số giao dịch nhất định (ví dụ: lấy từ mempool). Tuy nhiên, tính hợp lệ của giao dịch blob phụ thuộc vào tính khả dụng. Vì tính khả dụng chưa được ghi lại ở bất cứ đâu, nên việc đưa các giao dịch blob vào không thể được thực thi. Nguyên nhân cốt lõi là tính khả dụng chỉ có thể được xác định tại thời điểm giao dịch blob được đưa vào : ngay cả sau khi một blob được lan truyền và mọi người đã lấy mẫu nó, vẫn không có bản ghi nào về những blob nào khả dụng, và cách duy nhất để khẳng định tính khả dụng là thông qua việc đưa một giao dịch blob vào chuỗi.

Khả năng ghi âm: Hợp đồng DA

Một cách giải quyết triệt để vấn đề này là ghi lại trạng thái khả dụng một cách độc lập với việc bao gồm giao dịch blob. Chúng tôi đề xuất hai thay đổi:

1. Payload có thể chứa các mã băm có phiên bản độc lập với các giao dịch blob. Trình tạo có thể bao gồm một danh sách các mã băm có phiên bản cho các blob mà nó muốn xác nhận tính khả dụng, ngay cả khi không có các giao dịch blob tương ứng trong cùng một khối.
2. Thông tin về tính khả dụng được ghi lại trong hợp đồng DA . Khi bắt đầu mỗi khối, một lệnh gọi hệ thống ghi lại các hàm băm có phiên bản từ dữ liệu tải trọng vào hợp đồng DA. Điều này tạo ra một bản ghi về các khối dữ liệu nào khả dụng, có thể được truy vấn bởi các nút (như một phần của mempool và sự tham gia của FOCIL) cũng như bên trong EVM.

Việc thực thi tính khả dụng hoạt động chính xác như hiện nay: người xác nhận chỉ bỏ phiếu cho các khối có dữ liệu blob khả dụng. Nếu người xây dựng bao gồm một hàm băm có phiên bản cho dữ liệu không khả dụng, khối đó sẽ không nhận được xác nhận. Thay đổi duy nhất là hàm băm có phiên bản giờ đây có thể đến trực tiếp từ dữ liệu tải trọng, chứ không chỉ từ các giao dịch blob.

Ngoài ra, chúng tôi điều chỉnh hành vi trên chuỗi của các giao dịch blob để hoạt động với hợp đồng. Tính hợp lệ của giao dịch blob vẫn phụ thuộc vào sự sẵn có của các blob tương ứng, nhưng để đảm bảo điều này, chúng tôi hiện kiểm tra hợp đồng DA về sự sẵn có của blob_tx.versioned_hashes , như một phần của quá trình xác thực blob_tx . Cụ thể, chúng tôi không yêu cầu blob_tx.versioned_hashes phải được bao gồm trong payload.versioned_hashes nếu chúng đã được ghi nhận là có sẵn trong một khối trước đó. Sự sẵn có chỉ cần được thiết lập một lần.

Lưu ý: vì hợp đồng DA có thể được truy vấn trong EVM, các giao dịch thông thường cũng có thể kiểm tra tính khả dụng của blob, ví dụ: một hợp đồng có thể đặt điều kiện cho logic của nó dựa trên việc một blob cụ thể có khả dụng hay không. Các giao dịch blob vẫn có thể là giao diện chính, nhưng hợp đồng DA mở ra khả năng tương tác linh hoạt hơn với tính khả dụng.

Ảnh 2960×1456 209 KB

Hơn nữa, chúng tôi điều chỉnh cách xử lý các giao dịch blob trong mempool, để mempool có thể tận dụng thông tin về tính khả dụng trong hợp đồng. Một giao dịch blob giờ đây có thể lan truyền trong mempool nếu
hoặc:
1. Thông tin về tính khả dụng được ghi lại : Thông tin về tính khả dụng của các blob được tham chiếu được ghi lại trong hợp đồng DA, HOẶC
2. Người gửi giữ vé chưa sử dụng : Người gửi có một vé hợp lệ chưa được sử dụng trên EL (như được thấy cục bộ bởi nút).

Nói cách khác, vé chỉ cần thiết nếu giao dịch blob được lan truyền trước khi trạng thái khả dụng được ghi nhận, ví dụ như song song với chính blob đó. Sau khi trạng thái khả dụng được ghi nhận, giao dịch blob có thể được lan truyền theo các quy tắc mempool thông thường, giống hệt như một giao dịch thông thường. Điều này cũng giải quyết một hạn chế thực tế của hệ thống vé cơ bản: nếu không có hợp đồng DA, một vé chỉ cho phép một vài lần gửi giao dịch blob, và mempool phải hạn chế việc lan truyền giao dịch blob cho những người sở hữu vé. Với trạng thái khả dụng được ghi nhận, những hạn chế này biến mất — ví dụ, việc gửi lại không cần phải được xử lý theo bất kỳ cách đặc biệt nào.

Ảnh 4160×2244 533 KB

Hình 8. Toàn cảnh quá trình lan truyền blob và giao dịch blob với hợp đồng DA. Một vé cấp hai quyền lan truyền độc lập: một blob trên CL và một vài giao dịch blob trên EL. Sau khi trạng thái khả dụng được ghi lại trong hợp đồng DA, các giao dịch blob có thể lan truyền tự do mà không cần vé, cho phép gửi lại không giới hạn.

Câu chuyện đầy đủ về việc bao gồm trong các giao dịch blob

Với việc ghi nhận tính khả dụng một cách độc lập với các giao dịch blob, giờ đây chúng ta có thể cung cấp khả năng chống kiểm duyệt cho các giao dịch blob, bằng cách trước tiên đảm bảo việc bao gồm (xác định tính khả dụng) của các blob. Chúng ta thực hiện điều này bằng một cơ chế dựa trên vé blob và điều chỉnh việc thực thi lựa chọn nhánh giống như FOCIL cho các blob:

1. Mỗi thành viên của PTC (Ủy ban Đảm bảo Tính kịp thời của Tải trọng) quan sát xem những khối dữ liệu nào đã được truyền tải trước thời hạn sản xuất khối. Họ lấy mẫu các khối dữ liệu này và hình thành một cái nhìn cục bộ về tính khả dụng.
2. Các thành viên gửi danh sách các mã băm có phiên bản mà họ quan sát được là có sẵn.
3. Quyết định dựa trên đa số phiếu sẽ xác định các mã băm phiên bản nào mà người đề xuất phải đưa vào tải trọng (và do đó ghi lại trong hợp đồng DA).
4. Người đề xuất có thể bao gồm thêm các khối dữ liệu nhưng không được loại trừ những khối dữ liệu mà PTC yêu cầu.
5. Các bên xác nhận thực thi điều này: họ chỉ bỏ phiếu cho các khối bao gồm các hàm băm có phiên bản theo yêu cầu của PTC, trừ khi bên xác nhận cục bộ không thấy các khối dữ liệu đó khả dụng (an toàn luôn được ưu tiên).

Lưu ý rằng người đề xuất hiện bị ràng buộc từ cả hai phía khi nói đến việc bao gồm các khối dữ liệu: họ phải bao gồm những gì PTC yêu cầu (tính khả thi) và không thể bao gồm những gì không có sẵn (tính an toàn).

Điều quan trọng là, một khi tính khả dụng của một blob đã được ghi nhận, giao dịch blob tham chiếu đến nó sẽ trở nên tương đương với một giao dịch thông thường, bởi vì điều kiện hợp lệ bổ sung của nó được đảm bảo sẽ được đáp ứng:

• Như đã đề cập, nó có thể lan truyền mà không cần vé, theo các quy tắc mempool thông thường.
• Nó có thể được bao gồm thông qua FOCIL thông thường.

Hơn nữa, các giao dịch vé bản thân chúng cũng là các giao dịch thông thường, được hưởng lợi từ cùng một mempool và cơ sở hạ tầng FOCIL. Do đó, chúng ta có được một câu chuyện về khả năng chống kiểm duyệt từ đầu đến cuối cho các giao dịch blob.

Ảnh 3840×2076 275 KB

Hình 9. Đảm bảo bao gồm từ đầu đến cuối cho các giao dịch blob. PTC thực thi việc bao gồm các blob được lan truyền (dưới dạng băm phiên bản được ghi lại trong hợp đồng DA), trong khi FOCIL cung cấp các đảm bảo bao gồm cho các giao dịch mua vé và giao dịch blob.

Lưu ý rằng câu chuyện về khả năng chống kiểm duyệt từ đầu đến cuối này áp dụng cho các giao dịch blob sử dụng blob AOT. Ngay cả một blob AOT được lan truyền sau thời hạn PTC cho một vị trí nhất định vẫn có thể nhận được đảm bảo bao gồm từ vị trí tiếp theo trở đi, miễn là nó vẫn khả dụng — điều này phản ánh hành vi FOCIL thông thường, trong đó các giao dịch không có trong mempool trước thời hạn IL (danh sách bao gồm) không thể bị buộc đưa vào khối hiện tại nhưng có thể được đưa vào khối tiếp theo.

Mặt khác, các blob JIT, theo định nghĩa, chỉ được lan truyền khi được đưa vào một khối — không có đường dẫn lan truyền trước khi đưa vào, và do đó không có cách nào để xác định tính khả dụng của chúng và đảm bảo việc đưa chúng vào trước thời hạn. Đến khi một blob JIT được phép lan truyền, nó đã được đưa vào rồi. Chúng ta có thể coi dung lượng JIT như việc phân bổ một phần vé (phần “đường dẫn quan trọng”) cho người đề xuất, người này bán lại quyền cho người xây dựng: việc đưa vào sau đó hoàn toàn tùy thuộc vào quyết định của người xây dựng (nhưng được khuyến khích bằng phí ưu tiên). Đối với các trường hợp sử dụng thực sự cần blob JIT — đồng sáng tạo khối và blob để có khả năng kết hợp đồng bộ — không có lựa chọn nào khác ngoài việc để người xây dựng thực hiện việc này, vì vậy việc thiếu đảm bảo đưa vào là điều vốn có. Đối với các trường hợp sử dụng không thực sự cần đồng sáng tạo, một blob không được đưa vào dưới dạng JIT luôn có thể được gửi lại dưới dạng AOT, đạt được đầy đủ các đảm bảo chống kiểm duyệt được mô tả ở trên.

Chúng tôi kết thúc bằng một bức tranh toàn cảnh về thiết kế, so sánh nó với hệ thống hiện nay.

Ảnh 4720×3320 664 KB

Hình 10. Hiện tại (trên) so với Truyền dữ liệu Blob (dưới). Hiện nay, dữ liệu blob, xác định tính khả dụng và thực thi được kết hợp trong một khối duy nhất. Với truyền dữ liệu blob, các blob AOT được truyền trước qua các ticket và được xác thực dựa trên hợp đồng DA; các blob JIT được truyền trong đường dẫn quan trọng như hiện nay. Hợp đồng DA ghi lại tính khả dụng thông qua một lệnh gọi hệ thống, sau đó các giao dịch blob được xác thực dựa trên đó và thực thi bình thường.

Phụ lục

Hợp đồng hệ thống DA

Các yếu tố cần xem xét trong thiết kế

• Mô hình ghi: Ở đầu mỗi khối, một lệnh gọi hệ thống ghi lại các mã băm có phiên bản của các khối dữ liệu mà tính khả dụng của chúng đang được xác nhận trong khối đó.
• Mô hình đọc: Truy vấn hợp đồng bằng mã băm có phiên bản để kiểm tra xem dữ liệu nhị phân có sẵn hay không. Việc này cần phải đơn giản và tiết kiệm chi phí.
• Quản lý lưu trữ: Các mục nhập phải được xóa định kỳ để hạn chế sự tăng trưởng dung lượng lưu trữ. Với 128 blob trên mỗi khe, dung lượng lưu trữ không giới hạn sẽ tăng khoảng 10 GB mỗi năm.
• Truy cập khối hiện tại: Các giao dịch trong cùng khối với bản ghi trạng thái khả dụng phải có khả năng kiểm tra trạng thái khả dụng mà không cần bằng chứng bên ngoài, vì chúng không thể tạo bằng chứng cho dữ liệu vừa được ghi lại.

Thiết kế hợp đồng

Hợp đồng duy trì một cửa sổ gần đây (~128 khối) thông qua bộ đệm vòng, cho phép truy vấn không cần chứng minh O(1). Điều này bao gồm truy cập khối hiện tại và các trường hợp sử dụng tổng hợp điển hình.

Ngoài ra, người dùng có thể chứng minh sự hiện diện của mình bằng cách so sánh với versioned_hashes_root được lưu trữ trong tiêu đề của mỗi khối. Điều này giúp giảm thiểu dung lượng lưu trữ hợp đồng trong khi vẫn cho phép truy vấn tính khả dụng trong một thời gian dài, có thể nói là quá đủ để đảm bảo người dùng có thể thực hiện giao dịch trên chuỗi sau khi tính khả dụng của blob đã được xác định.

Lưu ý rằng việc kiểm tra hợp đồng DA như một phần của quá trình xác thực giao dịch blob rất tiết kiệm chi phí khi các versioned_hashes được bao gồm trong tải trọng hiện tại , vì đó là thao tác đọc nóng — các versioned_hashes đã được ghi vào hợp đồng DA khi bắt đầu khối. Mô hình sử dụng hiện tại, với việc xác định tính khả dụng diễn ra đồng thời với việc thực thi, về cơ bản không bị ảnh hưởng.

 # Constants BLOCK_WINDOW = 128 MAX_BLOBS_PER_BLOCK = 128 RECENT_RING_SIZE = BLOCK_WINDOW * MAX_BLOBS_PER_BLOCK # Storage recent_vhs_buffer: list [ Optional [ bytes ]] = [ None ] * RECENT_RING_SIZErecent_availability: dict [ bytes , int ] = {} # vh => 1 if in recent window recent_write_cursor: int = 0 def record_availability ( versioned_hashes: list [ bytes ] ): """Called via system call at block start.""" global recent_write_cursor for vh in versioned_hashes: # Clear old entry at current position old_vh = recent_vhs_buffer[recent_write_cursor] if old_vh is not None : del recent_availability[old_vh] # Record new entry recent_vhs_buffer[recent_write_cursor] = vhrecent_availability[vh] = 1 recent_write_cursor = (recent_write_cursor + 1 ) % RECENT_RING_SIZE def is_available ( versioned_hash: bytes ) -> bool : """Check availability in recent window (no proof needed).""" return recent_availability.get(versioned_hash) == 1