Tỷ lệ trúng blob lý thuyết dựa trên mempool của Lớp Thực thi

Công việc này được thực hiện với sự hợp tác của các đồng nghiệp tại ProbeLab và với sự hỗ trợ của Quỹ Ethereum. Báo cáo được trình bày nhằm phân tích tỷ lệ trúng blob lý thuyết mà một Ứng viên Consensus có thể mong đợi khi truy vấn các Ứng viên Lớp Thực thi của mình về các giao dịch blob được đưa vào một khối beacon được đề xuất.

Xin chân thành cảm ơn nhóm mạng của Quỹ Ethereum và nhóm EthPandaOps vì những phản hồi có giá trị của họ.

Động lực

Ethereum đang tìm cách mở rộng xuất lượng blob của mình thông qua PeerDAS, một bước đầy hứa hẹn có thể cho phép số lượng blob cao hơn đáng kể mà không yêu cầu mọi nút tải xuống và xử lý tất cả dữ liệu của riêng mình. Mặc dù điều này rất tốt cho khả năng mở rộng, nhưng nó mang lại những thách thức mới cho các validator xây dựng khối cục bộ. Những nhà xây dựng cục bộ này vẫn cần phải phát sóng tất cả các blob mà họ tham chiếu trong cửa sổ lan truyền khối 4 giây, điều này không phải lúc nào cũng khả thi dưới các ràng buộc về băng thông.

Để giảm bớt gánh nặng đó, khái niệm về xây dựng khối phân tán đã được đề xuất. Phương pháp này cho phép các validator cục bộ đưa vào bất kỳ giao dịch blob nào mà họ đã biết, với giả định rằng những người khác trong mạng cũng có thể đã nhìn thấy những blob đó. Thay vì phát lại toàn bộ tập blob thông qua GossipSub, ý tưởng là dựa vào mạng để giúp lấp đầy các khoảng trống. Khi một nút phát hiện một giao dịch blob được đưa vào một khối mà nó cũng lưu giữ cục bộ (được xác minh qua lệnh RPC engine_getBlobs tới Lớp Thực thi), nó có thể đảm nhận trách nhiệm bắt đầu phát sóng GossipSub của mình, hiệu quả làm giảm tải cho người đề xuất khối ban đầu.

Để đánh giá liệu việc phân phối blob hợp tác như vậy có thể hoạt động trong thực tế hay không, chúng tôi nhằm mục tiêu định lượng tính khả dụng lý thuyết của các giao dịch blob tại thời điểm đề xuất khối. Nghiên cứu này sẽ xem xét các xu hướng mempool và khả năng hiển thị giao dịch blob để hiểu liệu việc xây dựng khối phân tán có thể hỗ trợ số lượng blob cao hơn một cách thực tế mà không làm quá tải các validator cục bộ.

• 14.76% các giao dịch blob đến từ một "nguồn riêng" (*), và 85.78% còn lại đến từ mempool công khai
• 16.28% các giao dịch blob công khai không bao giờ được đưa vào payload block beacon tiếp theo
• 81.91% các giao dịch blob được đề xuất đã được nhìn thấy tại mempool công khai trước khi bắt đầu slot mà chúng được đưa vào và chỉ 4.12% xuất hiện sau đó (phần còn lại là riêng tư)

hình ảnh700×500 39.8 KB

LƯU Ý: (*) bởi vì chúng tôi cần xác định ngày của dữ liệu mà chúng tôi đang yêu cầu, một số giao dịch mà chúng tôi coi là "riêng tư" có thể đã được nhìn thấy trước đó bởi mempool nhưng chúng tôi không thể tìm nạp được vì chúng rơi vào trước thời gian được yêu cầu (đây là những gì tốt nhất chúng tôi có thể có dựa trên các tham số truy vấn của Xatu). Điều này có thể cuối cùng tạo ra các kết quả dương giả khi xác định "các giao dịch riêng tư".

hình ảnh446×228 32.4 KB

LƯU Ý: Tỷ lệ phần trăm của các giao dịch được hiển thị trong hình tham chiếu đến tổng biểu diễn của nhóm "cha mẹ" của chúng.

Các câu hỏi thường gặp

Chuyện gì xảy ra với các giao dịch "Void" đó?

Các giao dịch trong Ethereum có thể được hoàn nguyên hoặc thay thế miễn là chúng vẫn còn trong mempool và chưa được đưa on-chain. Một giao dịch có thể được ghi đè bằng cách gửi một giao dịch mới với cùng một nonce và phí cao hơn. Điều này cũng áp dụng cho các giao dịch blob - chúng có thể được cập nhật miễn là nonce vẫn giữ nguyên.

Chúng tôi tin rằng các giao dịch được đánh dấu là "void" trong đồ thị thuộc loại này, thay vì là kết quả của bất kỳ hình thức kiểm duyệt nào.

Chuyện gì xảy ra với các "Giao dịch Riêng tư" đó?

(Cảm ơn lớn @pop vì ý kiến của anh ấy về vấn đề này.) Việc sử dụng các mempool riêng là phổ biến trong Ethereum - như một biện pháp chống lại việc trích xuất MEV của bên thứ ba, để đạt được việc đưa vào nhanh hơn, hoặc đơn giản là để giữ một giao dịch riêng tư cho đến khi nó được đưa vào.

Tuy nhiên, bản chất của các giao dịch blob khá khác so với các giao dịch đa mục đích. Chúng chủ yếu được các L2 sử dụng để gửi các bằng chứng hoặc khối dữ liệu blob cho các hoạt động của họ - mà đối với hầu hết mạng, chỉ là các byte tùy ý. Điều này làm giảm động cơ giữ chúng riêng tư hoặc che chắn khỏi MEV.

Nghiên cứu của chúng tôi cho thấy, về tổng thể, mạng dựa vào mempool công khai để phát sóng các giao dịch này, ít nhất là trong hầu hết các trường hợp. Tuy nhiên, khoảng 15% các giao dịch blob dường như xuất phát từ các mempool riêng, với Taiko (ZK-rollup) là nhà đóng góp chính.

Kết luận

• Nghiên cứu cho thấy mạng hiện tại xử lý các giao dịch blob công khai, mà các nút biết trước khi block mà chúng được đưa vào đến.
• Với tốc độ giao dịch blob công khai hiện tại và thời gian đến của chúng vào mempool, các giải pháp như Distributed Block Building có thể giúp xử lý và lan truyền các blob với số lượng lớn hơn một cách nhanh chóng.
• Điều này cũng có nghĩa là mạng đang phân bổ tài nguyên để lan truyền thông tin trùng lặp, vì hầu hết các giao dịch blob được đề xuất được lan truyền qua mempool EL trước và sau đó được phát lại qua các chủ đề gossipsub của CL.
• Không thể tránh khỏi, điều này có thể dẫn đến việc cắt giảm tài nguyên cho những người tiêu thụ blob lớn, vì họ có thể chỉ gửi blob của mình một lần vào một mempool hoặc trình tạo khối riêng, ủy quyền cho chúng việc lan truyền các blob chỉ xảy ra tại thời điểm xuất bản khối.
• Mặc dù điều này có lợi cho mạng, vì nó có nghĩa là có nhiều băng thông hơn (các nút không phải tải xuống và lan truyền cùng một thông tin hai lần), nhưng điều này có thể tạo ra một số rủi ro tập trung hóa cho các trình tạo MEV.