Giải trình tự không thể ngăn cản: Phân lô Không cần cho phép để tăng khả năng phục hồi khi cuộn lên

Unstoppable Sequencing được phát triển với sự hợp tác của Spire, tận dụng chuyên môn của họ trong việc chia sẻ blob. Xin cảm ơn @norswap , @donnoh , ETH , Ilia Shirobokov , Julie và đội ngũ Spire đã phản hồi.

Giới thiệu

Trình tự cuộn lên (rollup sequencer) sở hữu sức mạnh to lớn. Chúng quyết định giao dịch nào được đưa vào, theo thứ tự nào và khi nào. Chúng là những người gác cổng của L2. Điều gì sẽ xảy ra khi những người gác cổng này gặp sự cố hoặc kiểm duyệt người dùng?

Thông thường, người dùng dựa vào "bắt buộc bao gồm", một cơ chế để tạo giao dịch L2 bằng cách tạo giao dịch L1. Tuy nhiên, mặc dù bắt buộc bao gồm vẫn duy trì một lối thoát, nhưng nó không đủ để hỗ trợ hoạt động liên tục của một roll-up do chi phí gas L1 khi gửi giao dịch riêng lẻ thay vì theo lô.

Giải pháp: tạo ra một quy trình xử lý hàng loạt Không cần cho phép và khả thi về mặt kinh tế cho tất cả mọi người. Nếu L1 hoạt động, quá trình tổng hợp vẫn tiếp tục hoạt động với Xuất lượng gần như bình thường — ngay cả khi trình sắp xếp bị lỗi hoặc bị tấn công. Đây chính là Giải trình tự Không thể Ngăn cản.

Tại sao sự hòa nhập bắt buộc lại thất bại ngày nay

Sự hòa nhập bắt buộc diễn ra như thế nào?

Lấy OP Stack làm ví dụ, đây là quy trình:

1. Người dùng gọi hàm depositTransaction trên hợp đồng OptimismPortal2 và chỉ định chi tiết về giao dịch L2 mà họ muốn thực hiện.

2. Hợp đồng cổng thông tin phát ra một sự kiện mà các nút OP Stack trung thực biết để đọc, chuyển đổi thành giao dịch Máy ảo Ethereum (EVM) thực tế và chèn vào Block L2 khi trình tự ngừng hoạt động.

Điểm mấu chốt là mỗi giao dịch L2 cần một giao dịch L1 riêng. Các giao dịch L1 này tốn ít nhất 100.000 đơn vị gas , ngay cả trong trường hợp đơn giản nhất .

Bây giờ hãy xem xét các giao dịch được xử lý theo lô được đăng bởi một trình sắp xếp rollup. Xử lý theo lô cho phép trình sắp xếp khớp hàng trăm hoặc hàng nghìn giao dịch L2 trong một giao dịch L1 duy nhất. Ví dụ: trong giao dịch L1 này, Base đã đăng tải 384kb giao dịch rollup. Một giao dịch chuyển khoản đơn giản có dung lượng khoảng 100 byte, trong khi một giao dịch hoán đổi Sàn phi tập trung (DEX) gần 1kb hơn, nghĩa là dung lượng tăng thêm từ xử lý theo lô ít nhất là 100:1.

Base đã trả bao nhiêu tiền gas L1 cho việc tăng công suất gấp 100 lần này? Cùng mức giá với một giao dịch bao gồm bắt buộc duy nhất, vì hiện nay các blob về cơ bản được đăng tải miễn phí do không bị tắc nghẽn!

Giá của blobspace chắc chắn sẽ tăng theo nhu cầu tổng hợp, nhưng nó sẽ luôn rẻ hơn nhiều so với calldata hoặc tương tác hợp đồng vì đây là phương tiện dự kiến ​​để cung cấp dữ liệu tổng hợp.

Nếu Sequencer bị lỗi thì sao?

Khi trình sắp xếp ngoại tuyến, việc đưa vào bắt buộc trở thành lựa chọn duy nhất. Nếu không có hiệu quả tăng lên nhờ xử lý theo lô, chi phí đưa vào giao dịch sẽ tăng lên gấp bội. Người dùng không còn lựa chọn nào khác ngoài việc thoát.

Việc buộc phải đưa vào có thể dẫn đến việc thoát hàng loạt, nhưng phải trả giá đắt. Mỗi người dùng phải:

• Trả 100k L1 gas cho giao dịch bắt buộc khởi tạo lệnh rút tiền trên L2
• Trả thêm 200.000+ gas L1 để hoàn tất thủ tục L1.

Chi phí tăng lên theo số lượng tài sản người dùng cần rút và số lượng giao dịch cần thiết để bắt đầu rút tiền (ví dụ: thanh toán khoản vay trước khi rút). Cuối cùng, chi phí gas L1 sẽ tăng vọt khi mọi người cố gắng rút tiền cùng lúc.

Giả sử 250.000 gas L1 cho mỗi người dùng rút tiền, 10 triệu người dùng, giá gas tăng 100 gwei và giá ETH là 4.000 đô la, chúng ta có tổng chi phí để thoát là:

250k gas per user * 10M users * 100 gwei gas price / 1e18 * $4k ETH price = $1B USD

Chi phí rất lớn, nhưng mô hình vẫn lạc quan vì nó giả định rằng tất cả các tài sản có giá trị đều có thể được chuyển sang L1. Điều này có thể đúng với các tài sản được bắc cầu với các biểu diễn L1 hiện có, nhưng đối với các tài sản được phát hành gốc trên rollup, vẫn chưa rõ liệu Consensus xã hội có phát triển xung quanh một tài sản L1 "tương đương" hay không.

Cuối cùng, sau khi tất cả các khoản phí đã được thanh toán và tất cả tài sản của người dùng đã được an toàn trên L1, thì sao? Người dùng không thể tiếp tục sử dụng L1, vì quá tốn kém! Đây là lý do tại sao họ sử dụng rollup ngay từ đầu. Nhưng liệu chúng ta có thể mong đợi họ gửi lại vào một rollup khác có cùng lỗ hổng sau khi đã trải qua trải nghiệm phá hủy giá trị nghiêm trọng của một đợt thoát hàng loạt không?

Điểm mấu chốt ở đây là: để hệ sinh thái Ethereum rollup có thể tồn tại, các rollup phải loại bỏ nhu cầu thoát hàng loạt do lỗi trình tự bằng cách cho phép chuỗi hoạt động mà không cần trình tự tập trung.

Giải pháp: Dân chủ hóa nền kinh tế Rollup

Để cho phép quá trình tổng hợp hoạt động mà không cần máy giải trình tự tập trung, chúng ta phải cung cấp cho người dùng thông thường quyền truy cập vào các công cụ kinh tế giúp cho quá trình giải trình tự tập trung trở nên khả thi.

Máy sắp xếp chuỗi có ba lợi thế quan trọng giúp tăng cường tính kinh tế:

1. Xử lý hàng loạt : Kết hợp nhiều giao dịch L2 thành một lần gửi L1 duy nhất. Đây là lợi ích hiệu quả cơ bản của việc tổng hợp.

2. Truy cập Blob : Sử dụng lưu trữ blob thay vì phát hành sự kiện hợp đồng. Blob được xây dựng chuyên dụng cho tính khả dụng của dữ liệu rollup và sẽ luôn là vector DA hiệu quả nhất của Ethereum. Tuy nhiên, người dùng nên có lựa chọn sử dụng calldata nếu nó rẻ hơn, giống như các trình sắp xếp rollup hiện nay.

3. Tính kinh tế theo quy mô : Theo quy tắc giao thức Ethereum, blob là giao dịch mua bán kiểu "tất cả hoặc không có gì"—bạn không thể chỉ mua 10KB dung lượng blob. Các trình sắp xếp tập trung tích lũy đủ giao dịch để sử dụng blob một cách hiệu quả. Người dùng cá nhân không thể làm được điều đó, vì vậy chúng ta cần một phương pháp sắp xếp cho phép người dùng chia sẻ blob và do đó tránh phải trả tiền cho dung lượng họ không sử dụng.

Giới thiệu về Unstoppable Sequencing

Unstoppable Sequencing là một khuôn khổ cho việc phân nhóm phi tập trung cần thiết để duy trì khả năng cuộn lên và khả năng chống kiểm duyệt khi trình tự chính hoạt động không bình thường.

Thuật ngữ

• Sequencer : một thực thể xây dựng các lô giao dịch L2 có thứ tự.
• Batcher : một thực thể đăng các lô giao dịch L2 đã được xây dựng lên L1. Trình sắp xếp và batcher có thể là cùng một thực thể, nhưng mục đích là để batcher đóng vai trò chuyên biệt xử lý việc chia sẻ blob.
• Nút rollup : phần mềm xác định trạng thái rollup bằng cách sử dụng lịch sử L1. "Xác định" nghĩa là tất cả các nút rollup trung thực sẽ xác định được cùng một trạng thái khi có cùng lịch sử L1.
• Máy khách Consensus Rollup : phần mềm trích xuất các lô từ dữ liệu L1 và gửi danh sách giao dịch và siêu dữ liệu đến máy khách thực thi để xây dựng và thực thi các khối. Ví dụ: op-node
• Máy khách thực thi Rollup : phần mềm thực thi các khối và lưu trữ trạng thái Rollup. Ví dụ: op-geth

Ở đây chúng tôi giả định rằng bản tổng hợp chia tách quá trình thực thi và Consensus như trong OP Stack và trên chính L1, nhưng điều này không cần thiết cho lời giải thích.

Vai trò và Quyền

Giải pháp Unstoppable Sequencing không yêu cầu loại bỏ các trình giải trình tự tập trung/được cấp phép. Các trình giải trình tự tập trung có thể cung cấp các dịch vụ cao cấp (tính khả dụng cao, xác nhận trước, khả năng kết hợp đồng bộ cuối cùng với các rollup khác) yêu cầu không gian khối và phí được đảm bảo.

Trong mô hình Giải trình tự không thể ngăn cản, có hai vai trò của trình tự:

• Trình tự ưu tiên : mỗi Block L1 có tối đa một trình tự ưu tiên. Các lô của trình tự này luôn được đặt ở đầu Block L2 và trình tự này được đảm bảo một tỷ lệ phần trăm không gian khối L2 có thể cấu hình được.

• Trình sắp xếp Không cần cho phép : tất cả những người còn lại. Các lô của họ nằm sau các lô của trình sắp xếp ưu tiên trong Block L2 và Block Space của họ không được đảm bảo—họ sử dụng toàn bộ gas không được trình sắp xếp ưu tiên tiêu thụ.

Phương pháp Giải trình tự không thể ngăn cản không phụ thuộc vào cách chọn trình tự ưu tiên và tỷ lệ gas Block L2 mà chúng được đảm bảo.

Một rollup dựa trên "thuần túy" có thể không cần trình sắp xếp thứ tự ưu tiên. Một rollup khác có thể có trình sắp xếp thứ tự ưu tiên nhưng chỉ đảm bảo 50% không gian khối, giúp họ ngang hàng với người dùng thông thường, v.v.

Không có phương pháp "một kích thước phù hợp cho tất cả" để thiết lập các thông số này. Giải trình tự không thể ngăn cản đảm bảo khả năng phục hồi tối đa trong việc lựa chọn các thông số, và quan trọng là, bất kể lựa chọn nào, Giải trình tự không thể ngăn cản vẫn mang lại mức độ bảo vệ tương tự ngay cả khi không có trình sắp xếp ưu tiên.

Vai trò của Batcher hoàn toàn Không cần cho phép trong các trường hợp gọi; bất kỳ ai cũng có thể đăng các lô được tạo bởi trình sắp xếp ưu tiên hoặc trình sắp xếp Không cần cho phép .

Định dạng hàng loạt (Có thể quét ở bất kỳ đâu trong Dữ liệu L1)

Trong Unstoppable Sequencing, các lô là chuỗi byte có thể được nhúng ở bất kỳ đâu trong dữ liệu cuộc gọi Ethereum hoặc tải trọng blob và được phát hiện bằng cách quét từng giao dịch Ethereum L1 riêng lẻ, mà không cần lọc theo (ví dụ) địa chỉ đăng bài đặc quyền.

Tại sao lại tự do như vậy? Các ràng buộc đối với các giao dịch DA đủ điều kiện sẽ hạn chế khả năng chia sẻ blob. Ví dụ: nếu hai rollup yêu cầu bài đăng của chúng phải được gửi đến những người nhận khác nhau, chúng không thể chia sẻ blob. Unstoppable Sequencing hướng đến khả năng tương thích tối đa với tất cả các giao thức batch, loại bỏ chi phí tìm kiếm batch ở khắp mọi nơi để tăng hiệu quả cho người dùng.

Các lô không thể dừng bao gồm tiêu đề 36 byte theo sau là các giao dịch được mã hóa RLP (và chữ ký 65 byte cho các lô ưu tiên):

 [PROTOCOL_ID] [CHAIN_ID] [VERSION] [ROLE] [LENGTH] [RLP_TX_LIST] [SIG if ROLE=1]

Mã giao thức (22 byte: 0x756e73746f707061626c652073657175656e63696e67 ): Chuỗi "unstoppable sequencing" được mã hóa dưới dạng hex. Mã định danh này cho phép các nút rollup phát hiện các lô nằm ở bất kỳ đâu trong blob hoặc calldata bằng cách quét chuỗi byte "ma thuật" này.

ID chuỗi (8 byte): Xác định chuỗi mà lô nhắm tới.

Phiên bản (1 byte): Phiên bản 1 hiện nay.

Vai trò (1 byte): Phân biệt các loại lô. 0 cho Không cần cho phép, 1 cho mức độ ưu tiên.

Chiều dài (4 byte): Chỉ định số byte dữ liệu giao dịch RLP theo sau.

RLP_TX_LIST : Các giao dịch thực tế, được mã hóa dưới dạng danh sách RLP Ethereum chuẩn.

Chữ ký (65 byte, chỉ ưu tiên): Chữ ký ECDSA bao gồm [CHAIN_ID][VERSION][ROLE][RLP_TX_LIST] . Điều này chứng minh lô này đến từ trình sắp xếp ưu tiên.

Khối một phần (“Mảnh vỡ Block ”)

Giải trình tự không thể ngăn cản xử lý mỗi lô như một Block L2 một phần . Nhiều lô trong cùng một Block L1 được kết hợp thành một Block L2 duy nhất, do đó:

• Những người tham gia nhỏ không cần phải tự mình lấp đầy cả một Block , và
• Chúng ta tránh được tình trạng lãng phí công sức “hoàn toàn hỗn loạn” khi chỉ có một người đề xuất toàn khối “chiến thắng”.

Phí hoạt động như thế nào?

Theo trực giác, mỗi trình sắp xếp chuỗi sẽ nhận được phí từ các giao dịch trong lô mà chúng đã đăng. Điều này khả thi đối với trình sắp xếp chuỗi ưu tiên, nhưng không khả thi đối với trình sắp xếp chuỗi Không cần cho phép vì người đề xuất Block L1 luôn có thể chạy trước trình sắp xếp chuỗi với một bản sao lô của riêng họ.

Sự sắp xếp này khuyến khích những người đề xuất Block L1 đầu tư vào việc giải trình tự roll-up, điều này có thể cung cấp Xuất lượng cần thiết trong trường hợp bộ giải trình tự ưu tiên gặp sự cố nghiêm trọng. Nhưng động lực nào để đăng các lô Không cần cho phép nếu bạn không phải là người đề xuất khối L1?

Ngay cả khi không có phí giao thức, các trình tự Không cần cho phép vẫn có thể được thúc đẩy bởi:

• Thỏa thuận phụ với người dùng / thỏa thuận thanh toán trước
• Vận hành các ứng dụng tổng hợp lớn cần có các giao dịch riêng
• MEV hoặc các lợi ích gián tiếp khác từ việc đặt hàng giao dịch

Tùy chọn cuối cùng và "tính năng tương lai" cho giao thức là cho phép người dùng chỉ định trình tự ưu tiên của họ, người duy nhất (ngoài họ) có thể sắp xếp các giao dịch của họ và nhận phí.

Xác định trạng thái L2 từ các lô

Bây giờ chúng ta hãy xem xét quy trình từ đầu đến cuối, bắt đầu từ góc nhìn của trình sắp xếp Không cần cho phép và kết thúc bằng việc tạo ra Block L2 xác định.

Bước 1: Tạo hàng loạt, Gửi và Chia sẻ Blob

Trình sắp xếp Không cần cho phép sẽ thu thập các giao dịch của người dùng thông qua các lệnh gọi RPC chuẩn ( eth_sendRawTransaction ). Khi trình sắp xếp đã thu thập đủ giao dịch để đăng, nó sẽ:

1. Bao bọc chúng trong định dạng hàng loạt Unstoppable Sequencing
2. Mã hóa lô để tương thích với blob bằng phương pháp toBlobs của viem (xử lý ràng buộc mô-đun trường BLS)

Tại thời điểm này, trình sắp xếp chuỗi đã sẵn sàng gửi một giao dịch blob chứa lô giao dịch đến L1. Tuy nhiên, nếu làm vậy, chúng sẽ cạnh tranh để giành cùng sáu khe blob như các rollup giải trình tự tập trung khổng lồ. Điều này không khả thi về mặt kinh tế, đó là lý do tại sao Unstoppable Sequencing được thiết kế với mục đích chia sẻ blob.

Vì việc chia sẻ blob đòi hỏi sự phối hợp giữa nhiều trình sắp xếp nên việc chia sẻ blob là một dịch vụ riêng biệt là điều hợp lý.

Chúng tôi đã phát triển các khía cạnh chia sẻ blob của giao thức này với sự hợp tác của Spire , sử dụng sản phẩm DA Builder của họ. Chúng tôi tin rằng sản phẩm của họ là hoàn thiện nhất và sẽ sử dụng nó trong quá trình triển khai Unstoppable Sequencing trên Facet Chuỗi. Tuy nhiên, cách tiếp cận tổng thể ở đây không phụ thuộc vào nhà cung cấp; bất kỳ trình tổng hợp tương thích nào cũng hoạt động được.

Để sử dụng dịch vụ chia sẻ như Spire, người dùng sẽ lấy chính xác giao dịch blob mà họ thường gửi đến L1 và gửi đến điểm cuối RPC của Spire. Sau đó, Spire giải mã blob, kết hợp dữ liệu của nó với dữ liệu của các trình sắp xếp khác thành một blob mới và đăng lên L1.

Spire thậm chí còn hỗ trợ các phương thức RPC của Flashbots như eth_sendBundle để các trình sắp xếp chuỗi có thể gửi các lô đến Spire ngay khi nhận được một giao dịch người dùng duy nhất và gửi lại một lô mới nhắm mục tiêu đến cùng một Block L1 cho mỗi giao dịch người dùng mới mà chúng nhận được. Điều này giúp loại bỏ gánh nặng về thời gian tối ưu cho từng trình sắp xếp chuỗi.

Lưu ý: nếu tính kinh tế của blob không khả thi ngay cả khi có dịch vụ tổng hợp blob, trình sắp xếp luôn có thể đăng lô lên L1 dưới dạng calldata.

Bước 2: Khám phá và xác thực (nút quét mọi thứ )

Đối với mỗi Block L1, nút lặp lại mọi giao dịch L1 theo thứ tự và kiểm tra:

1. Sau đó, dữ liệu cuộc gọi của tx
2. Mỗi blob được gắn vào tx đó (theo chỉ số blob tăng dần).

Nó quét từng luồng byte để tìm Unstoppable PROTOCOL_ID và khi khớp, phân tích tiêu đề có độ dài cố định và xác thực:

• CHAIN_ID khớp với bản tổng hợp,
• VERSION được hỗ trợ,
• RLP_TXS giải mã chính xác
• Đối với các lô ưu tiên ( ROLE=1 ), SIG xác minh dựa trên một tập hợp được ủy quyền cụ thể cho từng lô
• Đảm bảo tổng giới hạn gas của tất cả các giao dịch trong tất cả các lô ưu tiên không vượt quá mức phân bổ gas được đảm bảo cụ thể cho từng đợt.

Các lô không đúng định dạng hoặc không khớp sẽ bị bỏ qua. Các lô hợp lệ sẽ được chuyển sang bước tiếp theo.

Bước 3: Tổng hợp và sắp xếp

Nút thu thập tất cả các lô hợp lệ từ Block L1 và sắp xếp chúng bằng khóa sắp xếp sau:

• ưu tiên ? 0 : 1
• Chỉ số giao dịch L1
• độ lệch byte trong calldata
• chỉ số blob
• độ lệch byte trong blob

Nghĩa là, các lô ưu tiên sẽ được ưu tiên trước và nếu một giao dịch có các lô trong cả calldata và blob, thì tất cả các lô calldata sẽ được ưu tiên trước các lô blob.

Mỗi lô được "mở gói" thành các giao dịch thành phần, giữ nguyên thứ tự của chúng trong lô và các giao dịch bao gồm bắt buộc giao dịch đơn truyền thống được thêm vào. Tóm lại:

1. Tất cả các giao dịch theo lô ưu tiên
2. Tất cả các giao dịch hàng loạt Không cần cho phép
3. Tiền gửi / giao dịch bắt buộc truyền thống

Kết quả là một danh sách có thứ tự xác định các giao dịch L2, nhưng máy khách thực hiện cuộn lên có thể không xây dựng được Block L2 từ danh sách này vì một số giao dịch có thể không hợp lệ.

Trong Ethereum, “lỗi” giao dịch được chia thành hai loại:

1. Giao dịch không thành công (Khối hợp lệ) : Khi chức năng hợp đồng hoàn nguyên hoặc giao dịch hết gas thì giao dịch vẫn có thể được đưa vào Block hợp lệ.

2. Giao dịch không hợp lệ (Block-Invalid) : Một số lỗi giao dịch làm mất hiệu lực toàn bộ Block, khiến máy khách thực thi từ chối giao dịch đó. Ví dụ:

   • Không đủ tiền trong tài khoản để trang trải chi phí gas
   • Giá trị Nonce không hợp lệ
   • Triển khai hợp đồng vượt quá giới hạn kích thước

Trong quá trình tạo Block đơn lẻ truyền thống, Block Producer có thể loại bỏ tất cả các giao dịch không hợp lệ trước khi gửi. Tuy nhiên, cách tiếp cận này không khả thi khi kết hợp các lô từ nhiều bên trong hệ thống Giải trình tự Không thể dừng lại.

Bước 4: Thực hiện và Lọc

Giải pháp là "lọc bỏ" các giao dịch làm mất hiệu lực khối khỏi danh sách có thứ tự các giao dịch L2 mà nút đã tạo ở bước trước.

Tuy nhiên, việc xác định các giao dịch không hợp lệ không phải là điều có thể thực hiện "một cách tĩnh" trong máy khách Consensus rollup vì tính hợp lệ của giao dịch có thể phụ thuộc vào kết quả thực hiện các giao dịch trước đó trong Block.

Do đó, Unstoppable Sequencing yêu cầu thực thi các sửa đổi máy khách để kích hoạt tính năng lọc này. Quy trình hoạt động như sau:

1. Máy khách Consensus gửi các giao dịch đến máy khách thực thi trong lệnh gọi engine_forkchoiceUpdated thông thường.

2. Máy khách thực hiện bắt đầu xây dựng Block L2 bằng cách sử dụng các giao dịch này, thực hiện từng giao dịch một theo thứ tự.

3. Khi máy khách thực thi gặp phải giao dịch không hợp lệ, thay vì dừng quá trình do lỗi, nó sẽ bỏ qua giao dịch và chuyển sang giao dịch tiếp theo trong danh sách.

Những hạn chế và sự đánh đổi

Trình tự Không cần cho phép phải đối mặt với sự không chắc chắn

Trình tự ưu tiên có thứ tự dự đoán được và phân bổ gas được đảm bảo. Trình tự Không cần cho phép không biết thứ tự thực thi cuối cùng của chúng. Nếu Block L2 đầy vào thời điểm các giao dịch của lô Không cần cho phép cố gắng mua gas, chúng sẽ bị lọc ra.

Kẻ tấn công có thể lợi dụng cơ chế này bằng cách gửi nhiều lô trước một trình sắp xếp Không cần cho phép nhất định để cố gắng loại chúng khỏi Block. Tuy nhiên, việc spam liên tục sẽ tạo ra chi phí đáng kể cho kẻ tấn công vì phí cơ sở Block của L2 tăng lên để đáp trả.

Khi một số hoặc toàn bộ giao dịch trong một lô không nằm trong Block L2, các giao dịch này sẽ bị mất theo quan điểm của giao thức. Nghĩa là, nếu trình sắp xếp muốn thử đưa các giao dịch vào một Block L2 khác, chúng sẽ phải đăng lại lô đó lên L1 trong một giao dịch mới.

Một "tính năng tương lai" tiết kiệm chi phí hơn nhưng phức tạp hơn sẽ là nút tổng hợp duy trì "mempool" các giao dịch đã lọc và tự động bao gồm chúng mà không cần gửi lại trên các khối L2 trong tương lai.

Xác nhận trước và khả năng kết hợp đồng bộ

Một số tính năng nâng cao yêu cầu khả năng mô phỏng kết quả giao dịch một cách đáng tin cậy:

• Xác nhận trước : Người dùng muốn có sự đảm bảo về việc thực hiện giao dịch trước khi đưa vào L1
• Khả năng kết hợp đồng bộ : Các lệnh gọi liên chuỗi cần mô phỏng xác định

Những dịch vụ này chỉ có thể được cung cấp một cách đáng tin cậy bởi bất kỳ ai đăng đợt đầu tiên—người sắp xếp thứ tự ưu tiên khi hoạt động hoặc người đề xuất L1 nếu người sắp xếp thứ tự ưu tiên không hoạt động.

Điều này tạo ra sự phân công lao động tự nhiên: trình sắp xếp theo thứ tự ưu tiên cung cấp các dịch vụ cao cấp và đảm bảo, trong khi xử lý theo lô Không cần cho phép đảm bảo chuỗi vẫn chống kiểm duyệt và hoạt động trong mọi điều kiện.

Thế còn thư rác thì sao?

Một hệ thống Không cần cho phép sẽ dễ dàng bị spam. Kẻ tấn công có thể đăng hàng nghìn giao dịch không hợp lệ trên nhiều blob, buộc các nút phải xử lý rác. Liệu Unstoppable Sequencing có thể xử lý được vấn đề này không?

Giới hạn hiện tại là 6 blob cho mỗi Block có nghĩa là tối đa ~7.500 giao dịch spam cho mỗi Block 12 giây, mức có thể xử lý được đối với phần cứng hiện nay.

Khi không gian blobspace phát triển, điều này có thể trở thành một thách thức, nhưng việc giải quyết thách thức này phải trả giá bằng sự không cần xin phép và khả năng phục hồi.

Phần kết luận

L2 được xây dựng dựa trên cơ chế xử lý theo lô. Việc bao gồm bắt buộc theo cách truyền thống phá vỡ mô hình này bằng cách quay lại các giao dịch riêng lẻ, khiến việc duy trì hoạt động bình thường trở nên bất khả thi khi bộ sắp xếp chuỗi bị lỗi.

Unstoppable Sequencing giải quyết vấn đề này bằng cách cho phép xử lý hàng loạt Không cần cho phép— bất kỳ ai cũng có thể tạo và đăng các hàng loạt, được nhúng ở bất kỳ đâu trong dữ liệu L1, chia sẻ chi phí thông qua chia sẻ blob. Cách tiếp cận này đòi hỏi thêm độ phức tạp, nhưng nó đảm bảo L2 có thể vượt qua kiểm duyệt, lỗi và tấn công. Miễn là ai đó có thể đăng một hàng loạt ở đâu đó trên L1, chuỗi sẽ tiếp tục hoạt động.