Phân tích Blob sau khi cập nhật Fusaka và BPO

Nghiên cứu này được thực hiện bởi MigaLabs .

Tóm tắt

Báo cáo này trình bày phân tích thực nghiệm về Xuất lượng blob và độ ổn định mạng của Ethereum sau Hard fork Fusaka và các bản cập nhật Blob-Parameter-Only (BPO) tiếp theo. Nghiên cứu xem xét các mô hình phân phối blob, mối tương quan giữa các slot bị bỏ lỡ và sức khỏe tổng thể của mạng trong khoảng thời gian quan sát nhiều tháng.

Những phát hiện chính đặt ra những mối lo ngại đáng kể:

• Sử dụng công suất dưới mức tối ưu : Mạng không đạt được số lượng blob mục tiêu (14). Giá trị trung bình thực tế đã giảm kể từ BPO1 và số lượng blob cao (16+) vẫn cực kỳ hiếm.
• Tỷ lệ bỏ sót cao ở số lượng blob lớn : Tỷ lệ bỏ sót ở 16+ blob dao động từ 0,77% đến 1,79%, cao hơn gấp đôi so với tỷ lệ cơ bản ở 0-14 blob (~0,50%).
• Khuyến nghị : Không nên xem xét thêm bất kỳ bản cập nhật BPO nào cho đến khi tỷ lệ lỗi ở mức xử lý dữ liệu lớn ổn định và có nhu cầu rõ ràng đối với năng lực hiện tại.

Dòng thời gian các sự kiện

Phân tích

Phân bổ Blob trên mỗi Slot

Sự biến đổi theo thời gian của số lượng đốm trên mỗi khe thời gian được ghi lại trong suốt giai đoạn quan sát, cùng với dữ liệu về các khe thời gian bị bỏ sót tương ứng. Hình 1 trình bày phân bố hàng ngày của số lượng đốm trên mỗi khe thời gian dưới dạng biểu đồ hộp, với số lượng khe thời gian bị bỏ sót được chồng lên trục phụ (90 ngày).

Biểu đồ hộp blobs_per_day 2100×900 85.9 KB

Hình 1: Biểu đồ hộp thể hiện sự phân bố hàng ngày của các khối dữ liệu trên mỗi khe (trục bên trái) và số lượng khe bị bỏ lỡ mỗi ngày (trục bên phải). Các đường chấm dọc biểu thị các sự kiện nâng cấp giao thức.

Dữ liệu cho thấy một số quan sát đáng chú ý:

1. Dung lượng mục tiêu chưa đạt được : Mặc dù giới hạn blob đã được tăng lên, mạng lưới vẫn chưa đạt đến dung lượng mục tiêu mới. Số lượng blob trung bình thực tế đã giảm kể từ BPO1, từ 6 blob mỗi slot xuống còn 4 blob mỗi slot. Số lượng blob cao (trên 16) cực kỳ hiếm, chỉ xuất hiện từ 165 đến 259 lần, trong tổng số hơn 750.000 slot được quan sát.

2. Mở rộng năng lực mà không có nhu cầu : Các bản cập nhật BPO liên tiếp đã mở rộng năng lực lý thuyết, nhưng mức độ sử dụng thực tế lại không theo kịp. Điều này đặt ra câu hỏi về sự cần thiết của việc tăng thêm năng lực khi các giới hạn hiện tại còn lâu mới đạt tới.

Phân tích tương quan khe thời gian bị bỏ lỡ

Để điều tra mối tương quan tiềm năng giữa số lượng blob và các slot bị bỏ lỡ sau đó, chúng tôi đã phân tích tần suất các khối bị bỏ lỡ sau các slot có số lượng blob khác nhau kể từ khi phân nhánh Fusaka (40 ngày). Chúng tôi bỏ qua hai ngày đầu tiên sau Fusaka, vì có số lượng slot bị bỏ lỡ bất thường trong hai ngày đó.

blobs_before_missed 1500×900 34.5 KB

Dữ liệu thô trong Hình 2 cho thấy tỷ lệ bỏ sót khối cao hơn sau các khe có số lượng blob bằng không hoặc rất ít. Tuy nhiên, quan sát này cần được chuẩn hóa để tính đến sự phân bố không đồng đều của số lượng blob trên toàn mạng.

Phân phối blob 1500×900 34,8 KB

Hình 3: Phân bố số lượng đốm trên tất cả các khe quan sát, thể hiện tần suất không đồng đều của các số lượng đốm khác nhau.

Để đánh giá chính xác xác suất bỏ sót, chúng tôi đã tính toán tỷ lệ bỏ sót chuẩn hóa bằng công thức sau:

 Missed blocks after slots with X blobsMiss Rate ( X ) = ——————————————————————————————————————————— × 100 Total slots with X blobs

miss_rate_by_blobs 1500×900 36.2 KB

Hình 4: Xác suất bỏ sót một Block sau một vị trí có số lượng đốm nhất định.

Phân tích chuẩn hóa cho thấy những xu hướng đáng báo động:

• Tỷ lệ lỗi cơ bản (0-15 khối) : Dao động từ 0,32% đến 1,03% tùy thuộc vào số lượng khối, với mức trung bình khoảng ~0,5%.
• Tỷ lệ lỗi tăng cao đáng kể khi xử lý từ 16 blob trở lên : Tỷ lệ lỗi tăng mạnh, dao động từ 0,77% đến 1,79%. Ở mức 21 blob, tỷ lệ lỗi đạt 1,79%—cao hơn gấp ba lần so với tỷ lệ trung bình ~0,5% được quan sát ở số lượng blob thấp hơn. Điều này cho thấy sự suy giảm đáng lo ngại về độ tin cậy của mạng khi xử lý số lượng blob cao.

Số lần bỏ lỡ liên tiếp theo số lượng blob (đối với 10+ blob)

Các cân nhắc về thống kê

Bộ dữ liệu cho số lượng blob cao (16+) vẫn còn hạn chế, với kích thước mẫu dao động từ 165 đến 259 vị trí trên mỗi số lượng blob, so với hàng chục nghìn vị trí đối với số lượng thấp hơn. Tuy nhiên, mô hình nhất quán về tỷ lệ lỗi cao trên tất cả các số lượng blob cao (16-21) là đáng lo ngại. Ngay cả với số mẫu hạn chế, xu hướng vẫn rõ ràng: số lượng blob càng cao thì tỷ lệ lỗi càng cao. Nếu tỷ lệ lỗi cao này tiếp tục duy trì hoặc trở nên tồi tệ hơn khi nhu cầu tăng lên, sự ổn định của mạng có thể bị ảnh hưởng nghiêm trọng.

Kết luận

1. Dung lượng không được sử dụng tối đa : Mạng lưới không đạt được dung lượng mục tiêu mới. Số lượng blob trung bình đã giảm kể từ BPO1, và số lượng blob cao (trên 16) vẫn cực kỳ hiếm. Không có bằng chứng về áp lực nhu cầu đủ để biện minh cho việc tăng dung lượng hơn nữa.

2. Tỷ lệ lỗi đáng báo động ở số lượng blob cao : Các khe chứa từ 16 blob trở lên cho thấy tỷ lệ lỗi từ 0,77-1,79%, tăng đáng kể so với mức cơ bản 0,32-0,47% quan sát được ở 12-14 blob. Mô hình này cho thấy cơ sở hạ tầng mạng đang gặp khó khăn trong việc xử lý số lượng blob cao một cách đáng tin cậy.

3. Nguy cơ mất ổn định mạng : Nếu nhu cầu tăng lên và số lượng dữ liệu lớn trở nên phổ biến hơn, tỷ lệ lỗi truy cập hiện tại có thể gia tăng và đe dọa sự ổn định của mạng. Dữ liệu cho thấy mạng chưa sẵn sàng cho hoạt động liên tục ở mức số lượng dữ liệu lớn.

4. Không cập nhật thêm BPO cho đến khi ổn định : Không nên xem xét tăng thêm dung lượng blob cho đến khi:

   • Tỷ lệ bỏ sót ở số lượng đốm lớn (16+) trở lại mức cơ bản (~0,5% hoặc thấp hơn).
   • Hiện đã có bằng chứng cho thấy nhu cầu thực tế đang sử dụng hết công suất hiện có.

5. Cần tiếp tục giám sát : Mạng lưới cần được quan sát hoạt động ở giới hạn hiện tại trước khi thực hiện bất kỳ thay đổi nào. Việc tăng dung lượng quá sớm làm tăng nguy cơ sập mạng nếu các giao thức L2 bắt đầu sử dụng các giới hạn mở rộng trong khi cơ sở hạ tầng bên dưới không thể hỗ trợ chúng một cách đáng tin cậy.

Phương pháp luận

Nghiên cứu này được thực hiện bởi MigaLabs sử dụng mã nguồn này.