Các nhà nghiên cứu Ethereum đã báo cáo thời gian truyền trung bình dưới một giây cho tải trọng thực thi 1 MiB được mô phỏng bằng cách sử dụng thiết kế phát sóng phân đoạn của EIP-8411, so với khoảng năm giây khi gửi tải trọng dưới dạng một tin nhắn duy nhất.
Ethereum Research đã công bố kết quả thử nghiệm mới nhất vào ngày 17 tháng 9, chi tiết một nguyên mẫu chia tải trọng thực thi thành các mảnh nhỏ hơn để các node có thể xác minh và chuyển tiếp từng phân đoạn trước khi nhận được toàn bộ tải trọng. Các phát hiện này đến từ các mô phỏng và mã client nguyên mẫu, không phải từ các phép đo trên mạng chính Ethereum.
Đề xuất này vẫn là một EIP mạng dạng Dự thảo trong kho lưu trữ EIPs của Ethereum. Thiết kế hiện tại của nó thay thế chủ đề gossip execution_payload duy nhất được giới thiệu qua EIP-7732 bằng một chủ đề execution_payload_chunks và cam kết các mảnh thông qua một gốc Merkle được đưa vào đề xuất thực thi của nhà xây dựng.
Mô hình gossip hiện có của Ethereum có thể yêu cầu một node nhận và xác thực một tin nhắn lớn trước khi chuyển tiếp nó cho các peer. Các nhà nghiên cứu đằng sau EIP-8411 mô tả sự chậm trễ này là một vấn đề lưu trữ và chuyển tiếp (store-and-forward) vì toàn bộ tải trọng phải đi qua một bước nhảy mạng trước khi bắt đầu bước tiếp theo.
Với truyền tải phân đoạn, một nhà xây dựng chia tải trọng thành các mảnh cố định. Mỗi phân đoạn mang một bằng chứng bao gồm Merkle được gắn với gốc đã cam kết trong đề xuất thực thi. Một node nhận có thể kiểm tra một phân đoạn và bắt đầu gửi nó đi trong khi các mảnh còn lại vẫn đang đến.
Hơn nữa, cuộc thảo luận EIP trên Ethereum Magicians mô tả sự thay đổi được lên kế hoạch là thay thế tin nhắn tải trọng đơn lẻ của EIP-7732 bằng các phân đoạn có thể xác minh độc lập. Dự thảo hiện đề xuất 64 phân đoạn và một cấu trúc bằng chứng Merkle ràng buộc mọi mảnh với cam kết tải trọng ban đầu. Các nhà nghiên cứu cho biết cam kết Merkle đại diện cho bổ sung cấp độ đồng thuận chính cần thiết cho việc phân đoạn cơ bản. Nguyên mẫu nghiên cứu mới nhất vẫn giữ nguyên định dạng wire gossipsub hiện có, xây dựng mạng lưới (mesh), hệ thống cấp độ và tính điểm peer trong khi thay đổi cách các mảnh tải trọng được xuất bản và chuyển tiếp.
Tài liệu của Ethereum hiện mô tả tải trọng thực thi là dữ liệu liên quan đến giao dịch và trạng thái được tạo bởi client thực thi và được chuyển qua quy trình đồng thuận. Các trình xác thực nhận các khối được đề xuất thông qua mạng gossip đồng thuận trước khi gửi dữ liệu thực thi đến các client thực thi của họ để xác thực.
Các số liệu hiệu suất mạnh mẽ nhất trong báo cáo ngày 17 tháng 9 đến từ một mô phỏng được kiểm soát. Các nhà nghiên cứu đã mô hình hóa 500 node sử dụng độ trễ mạng địa lý, dung lượng tải lên 50 Mbps và dung lượng tải xuống 100 Mbps, với tải trọng 1 MiB có nguồn gốc từ một nhà xây dựng tại nhà và không có các node trung tâm dữ liệu băng thông cao.
Theo thiết lập đó, việc gửi tải trọng dưới dạng một tin nhắn gossipsub hoàn chỉnh mất khoảng năm giây để đến một nửa số node nhận và gần sáu giây ở đuôi (tail). Một phiên bản phân đoạn đã được tinh chỉnh đạt thời gian trung bình gần 0.75 giây và đuôi gần một giây.
Các nhà nghiên cứu nhấn mạnh rằng các phép đo đến từ một bộ công cụ kiểm thử (harness) chạy mã Prysm và go-libp2p-pubsub thực tế chống lại một mạng mô phỏng và đồng hồ ảo. Mỗi phép đo sử dụng mười cấu hình mạng ngẫu nhiên. Điều kiện mạng chính (mainnet) có thể khác với cấu trúc liên kết, băng thông và giả định lưu lượng truy cập đã được mô hình hóa.
Thiết kế Bậc 1 cơ bản của họ kết hợp phân đoạn với xuất bản theo lô. Sử dụng các phân đoạn 16 KiB, báo cáo cho biết thời gian truyền trung bình cho tải trọng 1 MiB đã giảm từ năm giây xuống dưới một giây, trong khi độ trễ đuôi giảm từ khoảng sáu giây xuống chỉ hơn một giây.
Xuất bản theo lô thay đổi cách nguồn gửi các mảnh. Thay vì gửi mọi bản sao của một phân đoạn trước khi bắt đầu cái tiếp theo, nhà xây dựng phân phối các mảnh khác nhau cho các peer khác nhau sớm, cho phép một số phần của tải trọng bắt đầu di chuyển qua mạng cùng một lúc. Các nhà nghiên cứu cho biết Bậc 1 yêu cầu nhiều hơn khoảng một phần ba số byte đã nhận so với phương pháp tin nhắn toàn bộ hiện nay. Sự đánh đổi đến từ việc gửi nhiều mảnh được xác định độc lập và các tin nhắn điều khiển bổ sung cần thiết để thông báo chúng.
Một bậc thứ hai được đề xuất giải quyết dữ liệu trùng lặp. Thay vì đẩy mọi phân đoạn đến tất cả các peer đủ điều kiện trong mạng lưới, các node có thể đẩy các mảnh đến một nhóm hạn chế trong khi thông báo khả dụng cho những người khác. Các peer chỉ yêu cầu các phân đoạn bị thiếu khi cần.
Nguyên mẫu kết hợp hệ thống đó với cái mà các tác giả gọi là pull có kỷ luật. Một node ban đầu yêu cầu một phân đoạn từ một peer, đợi một thời gian chờ xác định và chuyển sang một nguồn khác nếu peer đầu tiên không cung cấp được.
Với kích thước tải trọng 1 MiB, nghiên cứu cho biết các pull có kỷ luật đã giảm lưu lượng nhận được xuống khoảng 1.5 bản sao tải trọng cho mỗi node, so với lưu lượng trùng lặp nhiều hơn đáng kể trong các biến thể ít được kiểm soát hơn. Các nhà nghiên cứu nhận thấy rằng việc giảm trùng lặp ngày càng hữu ích khi băng thông tải lên khả dụng bị hạn chế.
Cách tiếp cận này tạo ra một sự đánh đổi khác. Một peer độc hại hoặc quá tải có thể thông báo một phân đoạn và sau đó từ chối cung cấp nó. Các nhà nghiên cứu đã thử nghiệm một kịch bản giữ lại trong đó một số node quảng cáo các phân đoạn nhưng không trả lời yêu cầu. Ở các mức độ giữ lại cao hơn, thiết kế dựa trên pull đã được tinh chỉnh cho thấy độ trễ đuôi tăng lên. Các tác giả đã thử nghiệm thời gian chờ ngắn hơn và nhiều nguồn yêu cầu khả thi như các phương pháp để hạn chế rủi ro đó.
Bậc thứ ba của họ thêm mã hóa xóa Reed-Solomon. Một tải trọng được nén, mã hóa với các mảnh chẵn lẻ bổ sung và chia thành các phân đoạn. Các node có thể tái tạo lại tải trọng sau khi thu thập đủ các mảnh mà không cần đợi mọi phân đoạn gốc.
Các nhà nghiên cứu cho biết mô hình mã hóa có độ trễ đuôi thấp nhất trong các thử nghiệm của họ và vẫn hoạt động khi một số phân đoạn bị giữ lại. Chi phí là băng thông cao hơn tại nguồn xuất bản vì dữ liệu chẵn lẻ làm tăng lượng dữ liệu được gửi.
EIP-8411 hiện không phải là một tính năng Ethereum đã được kích hoạt. Đề xuất GitHub đã được mở vào ngày 4 tháng 9 và vẫn được dán nhãn là một EIP mạng dạng Dự thảo đang chờ xem xét. Đề xuất này yêu cầu EIP-7732, thiết kế tách biệt trình đề xuất-trình xây dựng (proposer-builder separation) được ghi nhận của Ethereum.
Các nhà phát triển Ethereum đã yêu cầu EIP-8411 nhận trạng thái PFI, hoặc Đề xuất để đưa vào (Proposed for Inclusion), cho Hegotá, bản nâng cấp mạng dự kiến sau Glamsterdam. Trong cuộc thảo luận của Các nhà phát triển cốt lõi về Thực thi vào ngày 10 tháng 9, các nhà phát triển cho biết đề xuất này nên được xem xét bởi cuộc gọi của nhà phát triển lớp đồng thuận vì sự thay đổi này chủ yếu ảnh hưởng đến mạng lưới đồng thuận.
Yêu cầu này được đưa ra sau thời hạn PFI Hegotá thông thường. Những người ủng hộ nó đã đề xuất EIP-8411 như một sự thay thế cho EIP-81442, vốn đã khám phá việc đặt các khối vào blobs nhưng gây ra lo ngại về bằng chứng KZG phía nhà xây dựng và việc tái sử dụng các mạng con cung cấp dữ liệu.
Chương trình nghị sự ACDC #187 lên lịch thảo luận PFI EIP-8411 vào ngày 17 tháng 9 lúc 14:00 UTC. Tại thời điểm báo cáo này, cuộc gọi vẫn chưa diễn ra, vì vậy chưa có quyết định nào về việc đưa EIP-8411 vào Hegotá được ghi nhận.
Các nhà phát triển đã thu hẹp bộ tính năng của Hegotá trong các lĩnh vực trừu tượng hóa tài khoản, mở rộng quy mô, chống kiểm duyệt và các công việc giao thức khác. EIP-8411 đã tham gia quy trình đó muộn hơn nhiều đề xuất và vẫn cần một quyết định đưa vào của nhà phát triển cốt lõi.
Đề xuất mạng này gắn liền với công việc của Ethereum về việc nâng cao dung lượng Lớp 1. Giới hạn gas lớn hơn có thể dẫn đến tải trọng thực thi lớn hơn, làm tăng lượng dữ liệu mà các trình xác thực phải nhận trong các thời hạn đồng thuận cố định. Giới hạn gas của Ethereum đã đạt 60 triệu vào cuối năm 2025 sau khi các trình xác thực báo hiệu ủng hộ việc tăng này.
Vitalik Buterin đã mô tả dung lượng Lớp 1 cao hơn, PeerDAS và công việc ZK-EVM trong tương lai là các phần của kế hoạch mở rộng quy mô của Ethereum. Việc phân phối tải trọng nhanh hơn đang được nghiên cứu song song với những thay đổi đó vì các tin nhắn mạng lớn hơn gây áp lực lớn hơn lên băng thông của node và thời hạn truyền tải.
Các nhà nghiên cứu đã công bố các triển khai nguyên mẫu cho Prysm và go-libp2p-pubsub. Biến thể được khuyến nghị – một nhánh Prysm chứa một loạt các thay đổi đằng sau cờ –enable-segmented-payload-gossip, trong khi nhánh libp2p đi kèm triển khai các chính sách chuyển tiếp và yêu cầu được sử dụng trong nghiên cứu.
Các tác giả mô tả rõ ràng nhánh nghiên cứu của họ là “một bộ công cụ kiểm thử (harness), không phải một đề xuất.” Một số tính năng được đo lường trong bài báo, bao gồm các cấu hình mã hóa xóa nâng cao, vẫn là các thành phần thử nghiệm của môi trường thử nghiệm và không nhất thiết là một phần của đặc tả EIP-8411 tối thiểu.
Các câu hỏi mở được các nhà nghiên cứu xác định bao gồm lưu lượng tin nhắn điều khiển tăng lên, chi phí CPU từ việc xử lý nhiều tin nhắn nhỏ hơn, ánh xạ phân đoạn thay thế, quản lý hàng đợi, điều chỉnh bộ đếm thời gian và liệu một ngăn xếp mạng tập trung vào QUIC mới hơn có thể tạo ra các kết quả khác nhau hay không.
Các tác giả có kế hoạch so sánh thêm giữa thiết kế một chủ đề được sử dụng bởi biến thể A, các phương pháp tin nhắn một phần và các mô hình gán các chủ đề gossip riêng biệt cho từng phân đoạn. Nguyên mẫu hiện tại vẫn giữ các mảnh 16 KiB làm đường cơ sở được khuyến nghị sau khi các mô phỏng cho thấy các mảnh 8 KiB nhỏ hơn không tạo ra thêm cải thiện độ trễ trong khi tăng lưu lượng điều khiển.
ETH