Lan truyền Block và cục bộ với PeerDAS

Bài viết này cũng được đăng trên blog Block & Blob Propagation with PeerDAS | Chainbound Blog.

Được viết bởi Pierre-Louis và mempirate từ Chainbound

Tóm tắt: Bài viết này phân tích nhiều chỉ số quan trọng của mạng Ethereum để đo lường tác động của PeerDAS và số lượng blob ngày càng tăng. Các chỉ số này bao gồm độ trễ xác thực khối + blob, tỷ lệ chứng thực và tỷ lệ blob mồ côi. Chúng tôi nhận thấy mối tương quan rõ ràng giữa số lượng blob cao hơn khi sử dụng PeerDAS và sự thay đổi tiêu cực trong các chỉ số nói trên ( liên kết đến tóm tắt kết quả ), và lập luận rằng, đặc biệt với động lực cạnh tranh và nhạy cảm về độ trễ của PBS, điều này có thể tạo ra các giới hạn blob nhân tạo thấp hơn bất kỳ giới hạn nào được định nghĩa trong giao thức. Để giải quyết những vấn đề này, chúng tôi phác thảo thiết kế cho một mạng lưới các siêu nút mà chúng tôi muốn xây dựng để giúp giảm bớt một số vấn đề đó.

Giới thiệu

PeerDAS . Ethereum gần đây đã triển khai Fusaka, một cột mốc quan trọng trong lộ trình tập trung vào rollup của mình, giới thiệu PeerDAS như là tập hợp các tính năng đầu tiên cho phép lấy mẫu dữ liệu khả dụng (DAS). Mục tiêu cụ thể của PeerDAS là giúp mạng lưới duy trì số lượng blob trên mỗi khối cao hơn nhiều. Mạng lưới hỗ trợ blob (mục tiêu, tối đa) là (6, 9) trước khi triển khai Fusaka và dự kiến sẽ hỗ trợ lên đến (48, 72) trong vòng năm 2026. PeerDAS sửa đổi mạnh mẽ cơ chế blob; nó thay đổi cách blob được tạo, tham chiếu, phân phối/lưu giữ và xác minh. Do đó, PeerDAS đương nhiên đặt ra những sự đánh đổi.

Những hạn chế của DAS . Mặc dù các trình xác thực không còn phải tải xuống và xác minh toàn bộ blob nhờ PeerDAS, nhưng người đề xuất lại phải thực hiện nhiều phép tính hơn và tải lên nhiều dữ liệu hơn. Với PeerDAS, các blob hiện được mã hóa bằng thuật toán Reed-Solomon, dẫn đến các blob được mã hóa có kích thước gấp đôi so với các blob trước PeerDAS (128 kB → 256 kB). Người đề xuất khối sắp xếp các blob được mã hóa của một khối thành ma trận 2D, trong đó mỗi blob là một hàng của ma trận. Ma trận được chia thành 128 cột bởi người đề xuất, người này tính toán cam kết KZG cho mỗi cột và phân phối riêng từng cột cho mỗi trong số 128 mạng con của các trình xác thực. Người đề xuất phải tính toán và tải lên nhiều dữ liệu hơn cho mỗi khối so với trước PeerDAS, chủ yếu là do mã hóa Reed-Solomon. Vấn đề này sẽ trở nên trầm trọng hơn khi có thêm nhiều blob được thêm vào mỗi khối với việc triển khai BPO. Một số đề xuất đáng chú ý cho tương lai của DAS, bao gồm FullDAS và FullDASv2 , đang hướng tới mã hóa 2D, điều này làm tăng gấp đôi chi phí do mã hóa, do đó làm trầm trọng thêm chi phí băng thông cho người xây dựng, người đề xuất và các trạm chuyển tiếp, cũng như ảnh hưởng đến độ trễ phân phối cho tất cả các trình xác thực.

Phân tích thực nghiệm . Tài liệu này chủ yếu bao gồm phân tích tác động của số lượng blob trên mỗi khối đối với Ethereum nhờ các quan sát được ghi lại trong cơ sở dữ liệu Xatu của ethPandaOps. Cụ thể, phân tích nghiên cứu tác động của số lượng blob lên (1) độ trễ nhận khối và blob đối với các trình xác thực , (2) tỷ lệ chứng thực thành công của các trình xác thực , và (3) xác suất một khối không được hoàn tất và thay vào đó bị bỏ rơi . Các phép đo được thực hiện trên

1. Triển khai Mainnet trước PeerDAS để làm cơ sở với số lượng blob là (6, 9)
2. Mainnet sau PeerDAS và BPO1 do đó có số lượng blob là (10, 15)
3. Hoodi sau PeerDAS và BPO2 với số lượng blob là (14, 21)

Kết quả [ bảng tóm tắt ] . Việc tăng số lượng blob dẫn đến sự suy giảm rõ rệt cả độ trễ khối và tỷ lệ xác thực trên hầu hết các mạng được quan sát, cả trước và sau khi áp dụng PeerDAS. Ngoài ra, chúng tôi nhận thấy độ trễ đuôi (tail latency) tệ hơn sau khi áp dụng PeerDAS so với trước đó, và độ trễ đuôi ngày càng tệ hơn khi số lượng blob tăng lên. Tuy nhiên, việc tăng số lượng blob không có tác động đáng kể đến tỷ lệ gói mồ côi; một số kết quả chưa rõ ràng và nhìn chung cần thêm dữ liệu để đưa ra kết luận có ý nghĩa về tỷ lệ gói mồ côi.

Đề xuất: Mạng lưới gieo hạt . Dựa trên kết quả phân tích, chúng tôi đề xuất bổ sung một mạng lưới các siêu nút chuyên dụng vào mạng Ethereum với mục tiêu tăng tốc độ lan truyền các khối, blob và cột blob từ những người đề xuất khối (các relay trong PBS) đến phần còn lại của mạng. Dịch vụ bổ sung này sẽ hoạt động như một mạng lưới hỗ trợ ban đầu, đảm bảo các tác nhân chuyên biệt trong chuỗi cung ứng PBS không bắt đầu giới hạn số lượng blob một cách giả tạo do rủi ro khi bao gồm chúng, như đã thảo luận trong bài thuyết trình này .

Phân tích thực nghiệm về số lượng đốm

Tác động của các blob lên một số chỉ số này đã có thể được quan sát thấy trên mạng Ethereum hiện nay. Phân tích sau đây nêu bật những quan sát chính của chúng tôi liên quan đến số lượng blob có trong mỗi khối và cho thấy vẫn còn chỗ để cải thiện sau khi triển khai PeerDAS.

Phạm vi phân tích

Phân tích này tập trung vào các câu hỏi sau: Việc tăng số lượng blob có ảnh hưởng gì đến:

1. Thời gian cần thiết để các trình xác thực nhận được các khối và các cột dữ liệu blob cần thiết là bao lâu?
2. Liệu các trình xác thực có khả năng chứng thực các khối trước thời hạn 4 giây không?
3. Xác suất để một khối dữ liệu bị bỏ rơi là bao nhiêu?

Cấu trúc phân tích

Chúng tôi nghiên cứu bốn sự kết hợp giữa mạng và các nhánh rẽ với bốn số lượng blob khác nhau:

1. Mainnet dưới nhánh Pectra với mạng ổn định gồm 20.000 nút và hỗ trợ (target, max) là (6, 9) blob. Tập dữ liệu này đóng vai trò là cơ sở dữ liệu trước PeerDAS.
2. Mainnet dưới nhánh Fusaka với PeerDAS và BPO1 được kích hoạt để hỗ trợ số lượng blob là (10, 15) . Chúng tôi nhận thấy sự giảm đáng kể về nhiễu sau khi kích hoạt BPO1 nên chúng tôi đã chọn không bao gồm dữ liệu trước đó, tức là dữ liệu tuần đầu tiên của Fusaka. Tập dữ liệu này đóng vai trò là nghiên cứu trường hợp ổn định sau PeerDAS.
3. Mạng thử nghiệm Hoodi thuộc nhánh Fusaka, với PeerDAS, được vận hành bởi 2.000 nút với BPO2 được kích hoạt để hỗ trợ số lượng blob là (14, 21) . Mạng này kém ổn định và nhỏ hơn Mainnet nhưng đã có BPO2 được kích hoạt. Là một mạng thử nghiệm, kiến trúc của Hoodi gần giống với Mainnet nhất, điều này khiến nó thích hợp hơn để nghiên cứu so với Sepolia. Tập dữ liệu này đóng vai trò là một nghiên cứu điển hình với PeerDAS và BPO2.

Cài đặt

Nguồn : Tất cả các kết quả được trích xuất từ cơ sở dữ liệu Xatu do ethPandaOps duy trì. Các truy vấn chính xác được sử dụng để thu được các biểu đồ được công khai để tái tạo trên GitHub - chainbound/blob-seeder-data: Dữ liệu liên quan đến phân tích PeerDAS thúc đẩy mạng lưới gieo hạt blob .

Biểu đồ : Một số biểu đồ sử dụng mô hình hộp và râu để mô tả sự phân bố kết quả. Các hộp được biểu diễn theo kiểu cổ điển: hai đầu của hộp biểu thị phân vị thứ 25 và thứ 75 (ký hiệu là p25 và p75) và thanh bên trong mỗi hộp biểu thị giá trị trung vị (p50). Các biểu đồ sau đây bao gồm hai cặp râu để mô tả rõ hơn hành vi độ trễ đuôi; râu biểu thị p1 và p5 ở một đầu và p95 và p99 ở đầu kia. Các giá trị ngoại lệ được biểu thị bằng các vòng tròn màu bán trong suốt nằm ngoài phạm vi của râu. Các tham số của mô hình hộp và râu được ghi chú ở góc trên bên phải của biểu đồ.

Tóm tắt kết quả

• Độ trễ: Ảnh hưởng rõ rệt của số lượng blob đến độ trễ.
  • Khi so sánh độ trễ trước và sau khi sử dụng PeerDAS đối với các khối có cùng số lượng blob, dữ liệu cho thấy rằng, ngay cả với số lượng blob thấp từ 3 đến 9, PeerDAS đã cải thiện độ trễ xác thực cho 95% người xác thực trên Mainnet so với Pectra nhưng lại làm trầm trọng thêm tình trạng này đối với số ít còn lại. Tuy nhiên, các khối được phân phối nhanh hơn với PeerDAS so với khi không sử dụng, điều này cho thấy việc phân phối dữ liệu blob cần thiết cho quá trình xác thực thực sự chậm hơn đối với 5% người xác thực còn lại khi sử dụng PeerDAS so với khi không sử dụng.
  • Mạng chính (Mainnet) không có PeerDAS: Độ trễ tăng tuyến tính với số lượng blob. Xu hướng này bao trùm toàn bộ phân bố và có thể thấy rõ từ giá trị p5 đến p99. Ngoài ra, p99 đạt hoặc vượt quá thời hạn 4 giây đối với tất cả số lượng blob; p99 với 9 blob thậm chí còn lớn hơn 5 giây.
  • Mạng chính với PeerDAS-BPO1: Xu hướng tăng tuyến tính vẫn tiếp tục với PeerDAS và có thể thấy rõ trên toàn bộ biểu đồ từ trên xuống dưới cho tất cả các giá trị từ p5 đến p99. Độ trễ được cải thiện nhẹ đối với hầu hết các node khi sử dụng PeerDAS so với khi không sử dụng, vì hầu hết các giá trị p50 và p75 đều được cải thiện từ 100-200 ms. Tuy nhiên, 1% số trình xác thực kém may mắn nhất gặp phải độ trễ khối tệ hơn với PeerDAS vì các giá trị p99 đều tệ hơn đối với số lượng blob ≥ 3. Các giá trị p99 đều lớn hơn 5 giây đối với số lượng blob ≥ 9, lớn hơn 6 giây đối với 14 blob, và thậm chí đạt đến 12,4 giây đối với số lượng blob tối đa là 15.
  • Hoodi với PeerDAS-BPO2: Có một xu hướng tăng rõ rệt đối với số lượng blob ≥ 9, hầu hết diễn ra tuyến tính đối với tất cả các giá trị p1 đến p99. Điều này cho thấy xu hướng này có thể sẽ tiếp tục tăng tuyến tính trên Mainnet sau khi BPO2 được triển khai.
• Tỷ lệ xác thực: Ảnh hưởng rõ rệt của số lượng blob đến tỷ lệ xác thực.
  • Mainnet không có PeerDAS: Số lượng blob càng cao thì tỷ lệ xác thực thất bại p99 càng tăng đối với số lượng blob ≥ 4. Trong các trường hợp khác, số lượng blob hầu như không ảnh hưởng đến tỷ lệ xác thực.
  • Mạng chính với PeerDAS-BPO1: Tỷ lệ xác thực thất bại nhìn chung tệ hơn đáng kể khi sử dụng PeerDAS so với khi không sử dụng. Tỷ lệ p75 trước khi sử dụng PeerDAS ổn định ở mức 0,6% trên tất cả các số lượng blob nhưng tăng từ 0,9% lên 1,8% khi số lượng blob tăng lên sau khi sử dụng PeerDAS. Tương tự, tỷ lệ p95 tăng từ 2,4% đối với 1 blob lên 7% đối với 15 blob.
  • Hoodi với PeerDAS-BPO2: Tỷ lệ xác thực thất bại tăng tuyến tính với số lượng blob khi số lượng blob ≥ 14. Tỷ lệ trung bình của các trình xác thực không xác thực các khối đã hoàn tất tăng từ 4% đối với 14 blob lên 5% đối với 21 blob, và p99 tăng từ 11% đối với 14 blob lên 37% đối với 21 blob.
• Tỷ lệ khối mồ côi: Số lượng blob hầu như không ảnh hưởng đến tỷ lệ khối mồ côi.
  • Mạng chính (Mainnet) không có PeerDAS: Kết quả không rõ ràng. Một biểu đồ tính toán tỷ lệ khối mồ côi dựa trên tổng số khe (tỷ lệ tuyệt đối) cho thấy các mô hình chỉ ra mối tương quan giữa sự gia tăng số lượng blob và sự gia tăng tỷ lệ khối mồ côi. Tuy nhiên, biểu đồ thứ hai tính toán tỷ lệ khối mồ côi dựa trên số lượng khối đã hoàn tất chứa cùng số lượng blob — tức là tỷ lệ tương đối — lại không cho thấy bất kỳ mô hình nào.
  • Mạng chính với PeerDAS-BPO1: Các thiết bị mồ côi rất hiếm và hiện chưa có đủ dữ liệu.
  • Hoodi với PeerDAS-BPO2: Dường như không có mối tương quan giữa số lượng blob và tỷ lệ khối mồ côi trên Hoodi. Biểu đồ hiển thị tỷ lệ tuyệt đối chủ yếu làm nổi bật hai giá trị ngoại lệ, trong khi biểu đồ hiển thị tỷ lệ tương đối chủ yếu làm nổi bật mô hình được thấy trên độ trễ khối giữa 6 và 13 blob.

So sánh độ trễ của Mainnet

Ảnh 793×343 107 KB

Mô tả . Biểu đồ này thể hiện sự tiến triển của tỷ lệ các trình xác thực đã nhận đủ dữ liệu để xác thực một khối trên Mainnet với quy tắc Pectra so với quy tắc Fusaka khi có 1, 5 và 9 blob trong một khối. Chính xác hơn, nó mô tả hàm phân phối tích lũy (CDF) cho độ trễ xác thực khối mà chúng ta định nghĩa là thời điểm sớm nhất mà một trình xác thực có thể xác thực một khối theo các quy tắc đồng thuận. Để xác thực một khối, một trình xác thực trong Pectra phải nhận được khối và tất cả các sidecar blob của nó, trong khi theo quy tắc Fusaka, nó chỉ cần nhận được khối và ít nhất 8 cột blob, bao gồm tất cả các cột blob mà nó phải nắm giữ. Chi tiết về tập dữ liệu Pectra và Fusaka — Mainnet trước PeerDAS và Mainnet với PeerDAS-BPO1, tương ứng — được giải thích thêm trong phần mô tả của các biểu đồ độ trễ tương ứng.

Tóm lại : Cả ba cặp đường, khi được ghép nối theo số lượng blob, đều thể hiện một mô hình tương tự: hầu hết các trình xác thực có thể xác minh các khối sớm hơn ở Fusaka so với Pectra, tức là đường nét đứt chủ yếu nằm trên đường nét liền. Ngoài ra, việc thêm blob vào một khối đương nhiên làm tăng độ trễ. Chúng tôi quan sát thấy sự sụt giảm nhẹ trong quá trình phân phối khoảng 2,3-2,5 giây, có thể là do độ trễ xuyên lục địa giữa các cụm trình xác thực dày đặc.

Ảnh 793×343 85.8 KB

Mô tả . Biểu đồ này là phiên bản phóng to của biểu đồ phía trên, với các đường kẻ cho 3 và 7 điểm được thêm vào, để làm nổi bật phần đầu của đuôi phân bố, sau trang 95.

Tóm lại . Hành vi của cặp đường thẳng đối với 1 blob vẫn nhất quán với biểu đồ trên: hơn 99% các trình xác thực có thể xác minh khối nhanh hơn dưới Fusaka so với Pectra khi số lượng blob thấp như vậy. Tuy nhiên, hành vi này đảo ngược đối với số lượng blob cao hơn : 4-5% trình xác thực kém may mắn nhất thực sự cần nhiều thời gian hơn để nhận dữ liệu xác thực với Fusaka so với Pectra. Xu hướng này càng trở nên tồi tệ hơn khi số lượng blob tăng lên, như được thể hiện bằng khoảng cách giữa các đường liền nét và đường chấm cùng màu. Hai biểu đồ này cho thấy PeerDAS đã cải thiện độ trễ cho 95% trình xác thực nhưng lại làm tăng độ trễ cho số ít còn lại.

Ảnh 793×343 58.6 KB

Ảnh 793×343 87.8 KB

Mô tả . Hai biểu đồ này mô phỏng các biểu đồ ở trên nhưng tập trung vào độ trễ để các trình xác thực nhận đủ dữ liệu blob để xác thực các khối, tức là tất cả các blob cho mỗi khối trong Pectra so với chỉ các cột blob cần thiết trong Fusaka. Các biểu đồ này không xem xét độ trễ của khối, mà chỉ xem xét độ trễ của cột blob.

Tóm lại . Hai biểu đồ này xác nhận kết luận trước đó rằng hầu hết các nút nhận dữ liệu blob nhanh hơn ở Fusaka so với Pectra, điều ngược lại xảy ra ở phần đuôi, đối với 5% nút kém may mắn nhất, và xu hướng này càng trở nên tồi tệ hơn khi số lượng blob tăng lên.

Trước PeerDAS

Ảnh 1211×428 133 KB

Mô tả . Biểu đồ này thể hiện sự phân bố độ trễ phát hiện và xác thực khối trên Mainnet dưới hệ thống PeerDAS (trước khi triển khai PeerDAS) tùy thuộc vào số lượng blob được tham chiếu trong mỗi khối. Như đã đề cập ở trên, PeerDAS yêu cầu các trình xác thực phải tải xuống tất cả các sidecar blob được tham chiếu trong một khối để xác thực khối đó. Độ trễ này được thể hiện rõ qua sự khác biệt giữa độ trễ phát hiện và độ trễ xác thực. Mỗi điểm dữ liệu trên biểu đồ là một bộ dữ liệu duy nhất: (nút nhận, khối đã hoàn tất). Độ trễ khối lớn hơn 30 giây đã được lọc bỏ để loại bỏ các giá trị ngoại lệ rõ ràng. Tập dữ liệu được tổng hợp trong suốt tháng 11 năm 2025. Đường thẳng đứng màu đen ở mốc 4 giây biểu thị thời hạn xác thực khối.

Tóm lại : Có một xu hướng tăng rõ rệt đối với tất cả các chỉ số từ p25 đến p99, cho thấy số lượng blob càng cao thì độ trễ xác thực khối càng lớn. Các máy p99 đã đạt đến thời hạn 4 giây đối với 0-1 blob và vượt quá thời hạn đó đối với tất cả các blob ≥ 2, tuy nhiên các trình xác thực không chỉ được kỳ vọng nhận mà còn phải xử lý khối và các blob liên quan của nó trước thời hạn đó.

Với PeerDAS-BPO1

Ảnh 1211×528 183 KB

Mô tả . Biểu đồ này mô phỏng lại biểu đồ độ trễ trước đó trên Mainnet nhưng sau khi PeerDAS và BPO1 đã được triển khai. Ngoài ra, nó hiển thị độ trễ phát hiện khối , là ô đầu tiên cho mỗi cấp độ. Điều này làm cho độ trễ phát sinh thêm do sự lan truyền cột blob trở nên rõ ràng hơn.

Như đã đề cập ở trên, các quy tắc xác thực cho Fusaka khác biệt và yêu cầu trình xác thực không tải xuống toàn bộ blob mà thay vào đó là ít nhất 8 cột blob, bao gồm tất cả các cột blob mà nó cần để lưu trữ. Khoảng thời gian lấy mẫu 11 ngày kéo dài từ 00:00 UTC ngày 10/12/2025, ngay sau khi kích hoạt BPO1, đến 23:59 UTC ngày 21/12/2025.

Tóm lại . Xu hướng có vẻ tương tự trước và sau khi triển khai PeerDAS từ p5 đến p99. Điều thú vị là, giá trị p50 nhìn chung được cải thiện từ 100-200ms sau khi triển khai PeerDAS, nhưng giá trị p99 lại tệ hơn đối với số lượng blob ≥ 3, cho thấy chất lượng dịch vụ thấp hơn đối với 1% người xác thực kém may mắn nhất. Giá trị p99 đều lớn hơn 5 giây đối với số lượng blob ≥ 9, đạt 6,1 giây đối với 14 blob và thậm chí 12,4 giây đối với số lượng blob tối đa là 15.

Độ trễ trên Hoodi với PeerDAS-BPO2

Ảnh 1211×727 107 KB

Mô tả . Biểu đồ này mô tả độ trễ xác thực khối trên Hoodi sau khi PeerDAS và BPO2 được triển khai. BPO2 đã được triển khai vào ngày 12/11/2025 trên Hoodi và tăng số lượng blob lên (mục tiêu, tối đa) là (14, 21) . Dữ liệu được sử dụng cho biểu đồ này được lấy mẫu trong 7 ngày, từ 00:00:00 UTC ngày 28/11/2025 đến 00:00:00 UTC ngày 04/12/2025, so với một tháng đối với Mainnet do sự biến động cao hơn nhiều được quan sát thấy trên mạng thử nghiệm Hoodi.

Tóm lại . Tác động của số lượng blob lên độ trễ khối không rõ ràng trên Hoodi như trên Mainnet. Có một xu hướng tăng rõ rệt, hầu hết là tuyến tính đối với số lượng blob ≥ 9 cho tất cả các giá trị p1 đến p99. Chúng tôi nhận thấy rằng nhiều node không nhận đủ cột blob để xác minh khối, do đó làm giảm độ trễ tổng thể một cách giả tạo vì chỉ những xác thực thành công mới được tính đến trong biểu đồ.

Tỷ lệ chứng thực

Mainnet trước khi có PeerDAS

Ảnh 793×260 105 KB

Mô tả . Biểu đồ này thể hiện tỷ lệ các trình xác thực chưa bao giờ xác nhận một khối tùy thuộc vào số lượng blob trong khối đó. Mỗi điểm dữ liệu tương ứng với một khối đã được hoàn tất. Ví dụ, p99 là 30% có nghĩa là 1% số khối được xác nhận bởi chỉ 70% số trình xác thực. Dữ liệu được tổng hợp trong suốt tháng 11 năm 2025 trên Mainnet. Trục x của biểu đồ được chia thành hai trục tuyến tính có tỷ lệ khác nhau để cải thiện khả năng đọc của cả hộp và râu.

Tóm lại : Có xu hướng tăng nhẹ ở giá trị trung vị và xu hướng rõ rệt hơn ở p99 đối với số lượng blob ≥ 4. Các giá trị p75 đều gần bằng hoặc thấp hơn 0,6% tỷ lệ xác thực thất bại, cho thấy mạng ổn định ngay cả với số lượng blob là 9.

Mạng chính với PeerDAS-BPO1

Ảnh 811×377 72 KB

Mô tả . Biểu đồ này mô phỏng tỷ lệ xác thực trên Mainnet nhưng sau khi PeerDAS được kích hoạt và cho đến khi BPO1 được kích hoạt. Biểu đồ cũng được chia làm hai phần để dễ đọc hơn.

Tóm lại , quan trọng nhất là tỷ lệ xác thực tổng thể trở nên tệ hơn: ở p75 trước khi kích hoạt PeerDAS, tỷ lệ xác thực thất bại dao động quanh mức 0,6%, trong khi đó, khi số lượng blob tăng lên sau khi PeerDAS được kích hoạt, tỷ lệ này tăng từ 0,9% lên 1,8%. Tất cả các phép đo từ p50 đến p99 đều cho thấy xu hướng tương tự: các khối có tỷ lệ xác thực kém hơn khi số lượng blob tăng lên. Tỷ lệ xác thực bị ảnh hưởng nhiều hơn bởi số lượng blob trong biểu đồ này, khi có PeerDAS, so với biểu đồ trước đó, khi không có PeerDAS.

Hoodi với PeerDAS-BPO2

Ảnh 793×507 109 KB

Mô tả . Biểu đồ này mô phỏng biểu đồ tỷ lệ xác thực ở trên nhưng trên mạng Hoodi với BPO2 được kích hoạt. Dữ liệu chỉ được lấy mẫu trong một tuần do sự biến động cao hơn nhiều được quan sát thấy trên Hoodi so với Mainnet; trong một số trường hợp, việc tăng kích thước mẫu sẽ làm tăng sự xuất hiện của các giá trị ngoại lệ.

Tóm lại : Có một xu hướng gia tăng rõ rệt bắt đầu từ 12 blob, trong đó tất cả các chỉ số trên p25 đều xấu đi rõ rệt khi số lượng blob tăng lên. Thêm vào đó, p99 cũng xấu đi trên diện rộng khi số lượng blob tăng lên. So với Mainnet trước khi triển khai PeerDAS và p75 dưới 1%, p75 trên Hoodi với PeerDAS tệ hơn nhiều và dao động từ 5% đến 7%.

Tỷ lệ khối mồ côi

Mainnet trước khi có PeerDAS

Tuyệt đối

Ảnh 793×261 71.4 KB

Mô tả . Biểu đồ này thể hiện tỷ lệ khối mồ côi được phân loại theo số lượng blob được tham chiếu trong các khối đó. Các khối mồ côi này được tạo bởi người đề xuất dự kiến của các vị trí tương ứng nhưng, vì những lý do không xác định, đã không được đưa vào chuỗi khối cuối cùng. Tỷ lệ này được tính toán tỷ lệ thuận với tổng số vị trí trong khoảng thời gian lấy mẫu: 216.000 vị trí vào tháng 11 năm 2025.

Tóm lại : Tỷ lệ hạt mồ côi tổng thể thấp ở mức 584 / 216000 = 0,27%, cho thấy “thời gian hoạt động” của Ethereum là 99,73%. Chúng ta quan sát thấy hai mô hình trong biểu đồ này. Thứ nhất, một mô hình dường như lặp lại sau mỗi 3 hàng, trong đó giá trị cao ở một hàng được theo sau bởi hai giá trị thấp hơn: 63 hạt mồ côi cho 0 blob, tiếp theo là 11 và 1 hạt mồ côi cho hai hàng tiếp theo; 71 hạt mồ côi cho 3 blob, tiếp theo là 30 và 22 hạt mồ côi cho các hàng tiếp theo; và tương tự đối với 6-9 blob. Mô hình thứ hai cho thấy việc tăng số lượng blob làm tăng tỷ lệ hạt mồ côi, nhưng chỉ khi chúng ta xem xét mô hình đầu tiên. Xu hướng tăng rõ ràng khi chỉ quan sát số lượng blob là 0, 3, 6 và 9. Độ tin cậy của cách giải thích thứ hai này giảm xuống do chúng ta không thể giải thích được mô hình đầu tiên.

Tỷ lệ thuận

Ảnh 793×261 71.5 KB

Mô tả . Biểu đồ này mô phỏng biểu đồ tỷ lệ khối mồ côi tuyệt đối ở trên nhưng thay đổi các số chia được sử dụng trong phép tính tỷ lệ. Biểu đồ này hiển thị tỷ lệ "tỷ lệ thuận" ở chỗ chúng dựa trên số lượng khối đã hoàn tất có cùng số lượng blob với các khối mồ côi.

Tóm lại , chúng ta chủ yếu quan sát thấy sự phân bố đa dạng về số lượng khối (blob) trong các khối đã hoàn thiện (các ước số trong phân số bên cạnh các thanh) và hai giá trị ngoại lệ ở mức 2 và 9 khối. Khi bỏ qua các giá trị ngoại lệ, số lượng khối dường như không ảnh hưởng đến tỷ lệ khối mồ côi, không giống như biểu đồ thể hiện tỷ lệ khối mồ côi tuyệt đối.

Mạng chính với PeerDAS-BPO1

Sẽ mất vài tuần để thu thập đủ dữ liệu để tạo biểu đồ cho Mainnet sau Fusaka. Để so sánh, biểu đồ phía trên hiển thị các khối mồ côi trên Mainnet trước PeerDAS cho thấy tỷ lệ khối mồ côi khá thấp mặc dù được tính toán trong suốt một tháng. Dữ liệu bên dưới cho thấy số lượng quan sát rất nhỏ đối với các khối có số lượng blob cao hơn, do đó không mang tính đại diện. 15 khối ngoại lệ có tỷ lệ mồ côi >5% thực sự nổi bật.

Ảnh 811×428, dung lượng 76,7 KB

Hoodi với PeerDAS-BPO2

Tuyệt đối

Ảnh 793×510 90.2 KB

Mô tả . Biểu đồ này thể hiện tỷ lệ các khối mồ côi trên Hoodi so với tổng số khe thời gian trong giai đoạn lấy mẫu: 50.400 khe thời gian trong 7 ngày.

Tóm lại : Tỷ lệ khối mồ côi tổng thể trong suốt thời gian lấy mẫu thấp, ở mức 319 / 50400 (khối mồ côi / tổng số vị trí) = 0,63%, cao hơn một chút so với mức 0,27% của Mainnet. Có hai giá trị ngoại lệ rõ ràng, với 0 blob và 21 blob, và dường như không có xu hướng rõ ràng nào cho thấy số lượng blob ảnh hưởng đến tỷ lệ khối mồ côi trong Hoodi.

Tỷ lệ thuận

Ảnh 793×510 102 KB

Mô tả . Biểu đồ này thể hiện tỷ lệ các khối mồ côi trên Hoodi trong một tuần so với số lượng các khối đã hoàn thiện có cùng số lượng blob.

Tóm lại : Có sự gia tăng đáng kể tỷ lệ khối mồ côi giữa 6 và 13 khối; chúng tôi không có lời giải thích nào cho hiện tượng này. Giá trị cho 0 khối là một ngoại lệ rõ ràng, và giá trị cho 21 khối cũng có thể được coi là ngoại lệ do hệ số chia rất cao, lớn hơn từ 4 đến 46 lần so với các số lượng khối khác. Sau khi loại bỏ hàng cuối cùng gồm 21 khối vì cho rằng đó là ngoại lệ, không có xu hướng rõ ràng nào cho thấy mối tương quan giữa số lượng khối và tỷ lệ khối mồ côi.

Các nghiên cứu liên quan

• 2024-11: Dữ liệu trước PeerDAS cho thấy xu hướng giữa kích thước khối + blob và độ trễ phân phối [bài đăng]
• 2025-09: Báo cáo BPO của Ethpandas về độ an toàn/giao hàng đúng hạn của các blob trên mạng phát triển Fusaka devnet 5 với tối đa 30-50 blob nhưng với tập dữ liệu nhỏ [bài đăng]
• 2025-09: Phân tích chi tiết về thời gian xác thực của EF trong bài đăng nghiên cứu tính khả thi của các khe thời gian 6 giây [bài đăng]
• 2025-10: Báo cáo của Ethpanda về mức tiêu thụ băng thông tải lên/tải xuống cho các loại nút khác nhau trên mạng phát triển Fusaka 5 [bài đăng]
• Rất nhiều báo cáo với các phân tích từ Sunnyside Labs [báo cáo]
  • 2025-10-10 [báo cáo] bổ sung cho báo cáo BPO của Ethpandas [bài đăng] : Số lượng các hạn chót xác thực bị bỏ lỡ (ngược lại với chỉ số “độ chính xác của phần đầu” trong các báo cáo) tăng lên hơn 50% đối với các node đầy đủ khi số lượng blob tăng từ 10 lên 40. Các super node nhìn chung hoạt động tốt. Độ trễ p75 đối với 50-60 blob mỗi khối đạt 3 giây, vì vậy phần đuôi cao hơn nhiều (không rõ ràng trong các báo cáo). Việc lấy mẫu cột rất khó khăn với hơn 60 blob mỗi khối, có thể do tranh chấp mạng: quá nhiều băng thông được yêu cầu cho máy khách thực thi và máy khách đồng thuận gặp khó khăn trong việc phản hồi các yêu cầu cột.
  • 30/09/2025 [báo cáo] : Mạng phát triển Fusaka 5 với 1.700 nút (1/8 mạng chính): Điểm nghẽn đối với số lượng blob lớn là đường truyền lên của toàn bộ nút do số lượng blob trong mempool (máy khách thực thi) quá lớn, trong khi băng thông cho các siêu nút chủ yếu nằm ở các cột được lấy mẫu (máy khách đồng thuận).
  • 14/07/2025 [báo cáo] : Phụ lục B liệt kê các bảng điều khiển Grafana, Phụ lục D tính toán băng thông trung bình + tối đa đơn giản trên các nút khi tăng số lượng blob.

Đề xuất: Mạng lưới gieo hạt

Như đã nêu bật trong phân tích, PeerDAS tác động tiêu cực đến một số chỉ số liên quan đến tính ổn định của cơ chế đồng thuận, đặc biệt là ở phần đuôi. Riêng đối với những biến động nhỏ về số lượng blob trong các BPO sắp tới, điều này không đáng lo ngại. Tuy nhiên, trong chuỗi cung ứng PBS, từng mili giây đều rất quan trọng. Các relay cung cấp dịch vụ cho các trình xác thực để trì hoãn việc cam kết vào một khối càng lâu càng tốt, nhằm tối đa hóa MEV (trò chơi thời gian). Điều này hoạt động hiệu quả vì hiện tại, mức phạt độ trễ khi bao gồm các blob là tương đối nhỏ. Tuy nhiên, như chúng ta đã thấy ở trên, điều đó đang thay đổi, có thể dẫn đến việc một số thực thể trong chuỗi cung ứng PBS áp đặt các giới hạn giả tạo về số lượng blob thấp hơn nhiều so với giới hạn thực tế . Điều này sẽ làm giảm lợi ích về khả năng mở rộng DA, vốn là lý do tồn tại chính của PeerDAS.

Vì lý do này, chúng tôi đề xuất xây dựng một mạng lưới siêu nút toàn cầu với nhiệm vụ duy nhất là tăng tốc độ lan truyền dữ liệu (các khối và blob) từ nguồn gốc khối (bộ chuyển tiếp trong PBS) đến phần còn lại của mạng. Chúng tôi kỳ vọng mạng lưới gieo hạt sẽ giảm thiểu và ổn định độ trễ mà các trình xác thực gặp phải bằng cách giảm và giới hạn số bước truyền thông cần thiết để phân phối dữ liệu đến hầu hết các trình xác thực. Ngoài ra, nó sẽ cải thiện hiệu quả sử dụng blob bằng cách đảm bảo rằng người xây dựng có thể bao gồm số lượng blob tối ưu về mặt kinh tế một cách đáng tin cậy mà không phải chịu thêm bất kỳ hình phạt độ trễ nào.

Khái niệm về mạng lưới gieo hạt (seeding network) phù hợp với khung staking Rainbow (mặc dù nằm ngoài giao thức) vì nó dựa vào các siêu nút mạnh hơn để đóng góp nhiều hơn cho mạng lưới so với các nút thông thường, cuối cùng cải thiện chất lượng dịch vụ cho tất cả mọi người. Các siêu nút này mở rộng ý tưởng về các nhà cung cấp DAS như đã được mô tả trong bài đăng PeerDAS gốc . Một vài thiết kế đã được đề xuất để các relay PBS trở thành nhà cung cấp DAS và cung cấp dịch vụ RPC mà các trình xác thực có thể truy vấn để lấy mẫu. Chúng tôi đề xuất mở rộng các thiết kế này với sự hỗ trợ bổ sung cho GossipSub để các siêu nút chủ động đẩy nhanh việc phổ biến dữ liệu thay vì chỉ là những tác nhân thụ động chờ đợi các truy vấn từ máy khách.

Cách thức hoạt động như sau: Mạng lưới gieo hạt này sẽ bao gồm các siêu nút hiệu năng cao và có khả năng kết nối mạnh mẽ, đóng vai trò là các trung tâm mạng để cung cấp càng nhiều dữ liệu đến càng nhiều nút càng tốt. Các siêu nút sẽ đóng góp vào việc phân phối các cột khối và blob bằng cách đăng ký các chủ đề GossipSub được sử dụng cho các khối ( beacon_block ) và cho 128 mạng con cột blob ( data_column_sidecar_[0-127] ). Ngoài ra, các siêu nút sẽ phản hồi các yêu cầu RPC có liên quan cho các khối, blob và cột blob, ví dụ: BeaconBlocksByRoot , BlobSidecarsByRoot , DataColumnSidecarsByRange .

Các kết nối giữa các siêu nút sẽ được triển khai bằng thư viện nhắn tin GitHub - chainbound/msg-rs: Messaging library for distributed systems được xây dựng bằng Rust, một thư viện đã được kiểm chứng và có hiệu năng cao, từng cung cấp sức mạnh cho dịch vụ mempool độ trễ thấp Fiber của chúng tôi. Vị trí địa lý của mỗi siêu nút và cấu trúc liên kết của mạng sẽ được thiết kế để giảm thiểu độ trễ tổng thể trong việc phân phối và yêu cầu cho các trình xác thực, đảm bảo phân phối phù hợp tại các điểm nóng như Virginia, Frankfurt và Tokyo.

Những cải tiến dự kiến về chỉ số

Chúng tôi kỳ vọng mạng lưới gieo hạt sẽ mang lại những cải tiến rõ rệt so với mạng Ethereum về các khía cạnh sau:

1. Độ trễ tiếp nhận khối và dữ liệu nhị phân : Một mạng lưới nhỏ gồm các siêu nút hiệu năng cao cho phép phân phối dữ liệu với ít bước nhảy hơn so với một mạng lưới lớn hơn và đa dạng hơn.
2. Tỷ lệ xác thực và tỷ lệ khối mồ côi : Nhờ việc phân phối nhanh hơn cả các khối và cột dữ liệu nhị phân, các trình xác thực sẽ có thể xác thực các khối nhanh hơn, do đó giảm xác suất các khối không được xác thực kịp thời và trở thành các khối mồ côi không hiệu quả thay vì được đưa vào chuỗi hoàn chỉnh.
3. Giảm thiểu việc giới hạn khối lượng chiến lược trong PBS : Do hai cải tiến nêu trên, lợi ích của việc đưa khối lượng chiến lược (thấp hơn) vào chuỗi cung ứng PBS đã bị vô hiệu hóa.

Lời cảm ơn

Chúng tôi xin cảm ơn nhóm ethPandaOps đã cho phép chúng tôi truy cập và hỗ trợ chúng tôi sử dụng cơ sở dữ liệu Xatu, cũng như các cộng tác viên của Xatu đã cung cấp dữ liệu để chúng tôi phân tích. Chúng tôi cũng xin cảm ơn các tác giả của bài phân tích mạng blockchain “Multiple Sides of 36 Coins” được công bố tại SIGMETRICS 2026 [phiên bản arXiv] , và đặc biệt là Lucianna Kiffer, vì đã chia sẻ các số liệu cập nhật về quy mô của các mạng Ethereum khác nhau.