Giới thiệu
Hard-fork là những khoảnh khắc then chốt định nghĩa lại khả năng và hiệu quả của mạng lưới. Vào ngày 7 tháng 5, Ethereum Mainnet đã nâng cấp từ Deneb lên Electra fork, bao gồm một số thay đổi và cải tiến quan trọng đối với các lớp đồng thuận và mạng lưới của giao thức. Trong bài đăng này, chúng tôi sẽ xem xét cụ thể cách mạng lưới đã chuẩn bị cho fork bằng cách phân tích cấu trúc mạng lưới trong những tuần dẫn đến sự kiện, cách thời gian đến của tin nhắn đã thay đổi và liệu bản nâng cấp có cho phép một số yêu cầu về băng thông được nới lỏng hay không.
Để làm được điều này, chúng tôi đã tiến hành phân tích chuyên sâu dữ liệu mà một số công cụ đo lường của chúng tôi như Nebula và Hermes đã thu thập trước, trong và sau sự kiện hard fork. Phân tích này bổ sung cho các bản cập nhật hàng tuần của chúng tôi về cấu trúc mạng , thời gian đến của khối , mức sử dụng băng thông , v.v. Chúng tôi đã thực hiện A Deep Dive into the P2P Layer of the Dencun Hardfork một năm trước, cung cấp thông tin cho một số lĩnh vực trọng tâm của chúng tôi trong nghiên cứu này.
tl;dr
Đây là những điều chính chúng tôi rút ra
- Hai ngày trước khi hard fork, 53% mạng đã sẵn sàng để nâng cấp
- 70% mạng được nâng cấp ngay lập tức và thêm khoảng 18% được nâng cấp trong vòng năm ngày sau khi phân nhánh
- Độ trễ phát sóng theo khối nhìn chung không bị ảnh hưởng:
- Nhìn chung, chúng tôi thấy độ trễ đến của khối giảm nhẹ, gần 200ms ở mức trung bình.
- Tuy nhiên, một số nút nằm ở Châu Phi, Úc và Nam Mỹ, vốn có vị trí địa lý bất lợi hơn do độ trễ cao hơn so với EU và Hoa Kỳ (nơi triển khai hầu hết các nút) nên thời gian đến khối chậm hơn so với trước khi nâng cấp.
- Nhìn chung, khoảng 5% khối không đến đúng thời hạn trong khung thời gian 4 giây, ngụ ý rằng có khả năng sẽ có ít phần thưởng hơn cho người xác thực do bỏ lỡ các đầu xác thực.
Mục lục
- Giới thiệu
- Phương pháp luận
- Thay đổi cấu trúc mạng
- Tác động của hardfork đến thời gian đến của khối
- Thông lượng băng thông mạng
- Phần kết luận
Phương pháp luận
Công cụ sử dụng
Đối với công việc được trình bày trong bài đăng này, nhóm ProbeLab đã sử dụng các công cụ sau
- Nebula - một trình thu thập dữ liệu mạng tương thích với libp2p và discv5.
- Hermes - một trình theo dõi và lắng nghe GossipSub nhẹ, đăng ký tất cả các chủ đề pubsub có liên quan và theo dõi mọi tương tác giao thức.
- Xatu - Nền tảng giám sát mạng của EF EthPandaOps.
Bộ dữ liệu
Kết quả trình bày trong nghiên cứu này kéo dài trong khoảng thời gian hai tuần: một tuần trước khi nâng cấp Pectra (tức là ngày: 2025-04-28 đến 2025-05-07 ) và một tuần sau đó (tức là ngày 2025-05-07 đến 2025-05-14 ).
Trong phần sau của báo cáo “Tác động của Hardfork đến thời gian đến của khối”, chúng tôi tham khảo cơ sở dữ liệu công khai của Xatu, nơi tổng hợp các mẫu dữ liệu từ nhiều tác nhân và nút khác nhau tham gia vào Nỗ lực thu thập dữ liệu cộng đồng . Điều này bao gồm:
- Các nút điều khiển của Ethereum Foundation (EF), còn được gọi là nút canh gác , được triển khai trên nhiều máy khách và vị trí địa lý khác nhau.
- Các nút do cộng đồng điều hành, đóng góp dữ liệu một cách vị tha vào cơ sở dữ liệu công cộng.
Dữ liệu cho các phần còn lại đến từ quá trình triển khai trình thu thập dữ liệu Nebula liên tục của chúng tôi, cùng với các tập lệnh tùy chỉnh ở bất cứ nơi nào cần.
Thay đổi cấu trúc mạng
Bản tóm tắt Fork
Biểu đồ trên cho thấy các bản tóm tắt fork được quảng cáo trong discv5 DHT vào khoảng thời gian hard fork. Người ta có thể thấy rõ sự sụt giảm mạnh của các bản tóm tắt Deneb được quảng cáo tại thời điểm hard fork: 2 giờ sau hard fork, 70% các nút đã theo fork mới. Trong những ngày sau hard fork, có một đoạn dài các nút cập nhật lên fork mới. Tuy nhiên, năm ngày sau fork, vẫn còn khoảng 12% các nút theo fork lỗi thời. Chúng ta có thể yên tâm cho rằng các nút này không chạy trình xác thực, nếu không, chúng không thể theo dõi với người đứng đầu chuỗi, điều này cuối cùng khiến trình xác thực không thể thực hiện nhiệm vụ của mình.
Người ta có thể cho rằng các nút không nâng cấp đúng hạn là các triển khai tại nhà/sở thích. Tuy nhiên, nếu chúng ta chia các nút trực tuyến năm ngày sau khi phân nhánh thành hai loại 1) tuân theo electra 2) không tuân theo electra, chúng ta có thể thấy rằng các nút không tuân theo electra chủ yếu chạy trên cơ sở hạ tầng đám mây - hủy bỏ giả thuyết về các triển khai tại nhà.
Khi xem xét các phiên bản fork tiếp theo mà các nút thông báo, chúng ta có thể thấy rằng một số khách hàng đã quảng cáo fork Fulu tiếp theo.
Điều thú vị là hầu như chỉ có Prysm công bố Fulu ở đây. Các triển khai máy khách khác vẫn chỉ công bố Electra.
Nâng cấp máy khách
Khi xem xét những ngày dẫn đến đợt hard fork, chúng tôi tập trung vào cách người dùng triển khai Prysm, Lighthouse và Teku điều chỉnh các phiên bản máy khách tương thích.
Các biểu đồ sau đây cho thấy số lượng nút chạy một phiên bản nhất định của một trong các triển khai máy khách đã đề cập theo thời gian cho đến một vài ngày sau hard fork. Cả ba biểu đồ đều biểu thị thời điểm hard fork xảy ra cũng như thời điểm phiên bản tương thích đầu tiên cho fork mới được phát hành trên GitHub.
Như dự kiến, trong cả ba trường hợp, chúng ta có thể thấy rằng ngay sau khi phát hành chính thức phiên bản máy khách tương ứng, các nhà điều hành nút đã bắt đầu nâng cấp. Hai ngày trước khi hard fork, khoảng 53% các nút trong mạng đang chạy triển khai máy khách tương thích với Electra - 60% một ngày trước đó, 67% một giờ trước đó. Các con số không tính đến máy khách Nimbus vì chúng không quảng cáo thông tin phiên bản. Nimbus là triển khai thứ tư có thị phần đáng kể trong các triển khai mạng, do đó, số lượng nút sẵn sàng cho Electra có thể cao hơn một vài phần trăm điểm một chữ số.
Chúng ta cũng có thể nói một cách an toàn rằng các nhà điều hành nút không sử dụng hard fork như một cơ hội để chuyển đổi các triển khai máy khách như biểu đồ sau đây cho thấy. Sự phân bổ các triển khai máy khách hầu như không thay đổi trong quá trình fork.
Những điều cần biết
- Khoảng 70% các nút trực tuyến đã tuân theo nhánh mới ngay lập tức.
- Một cái đuôi dài khoảng 20% khác theo sau nhánh mới một tuần sau sự kiện
- Thật khó để nói liệu các nút còn lại có phải là các nút triển khai tại nhà/sở thích hay không, vì chúng tôi thấy rằng chúng chạy trên cơ sở hạ tầng đám mây, tức là ít có khả năng có một nút được tạo ra mà không chạy trình xác thực.
- Các bản phát hành tương thích cho máy khách đã được chọn dần dần trong những ngày trước khi phân nhánh.
Tác động của hardfork đến thời gian đến của khối
Một trong những bổ sung cốt lõi của bản nâng cấp Pectra là tăng mục tiêu blob và giá trị tối đa thêm ba blob cho mỗi khối (xem bài đăng EthPandaOps , bài đăng ProbeLab ). Mặc dù thực tế là mạng được hưởng lợi từ 50% không gian tạm thời đó, nhưng việc tăng số lượng blob này cũng có nghĩa là mạng cần truyền thêm tới 348KB dữ liệu trong mỗi khe. Cuối cùng, điều này có thể ảnh hưởng đến khả năng phát sóng tin nhắn tổng thể của mạng, nếu các nút không thể phân bổ thêm băng thông ở giai đoạn đầu của khe, khi khối được truyền đi.
Các biểu đồ sau đây được tổng hợp bằng cách lấy tất cả thời gian đến của khối được gửi đến phiên bản Xatu công khai EthPandaOps. Lưu ý rằng biểu đồ đầu tiên thuộc về các phép đo trước khi nâng cấp Pectra và biểu đồ thứ hai thuộc về sau khi nâng cấp. Dữ liệu này không chỉ bao gồm các điểm dữ liệu từ các nút sentry của Ethereum Foundation mà còn từ một số cộng tác viên bên ngoài tham gia vào chương trình thu thập dữ liệu cộng đồng . Để rõ ràng hơn, các biểu đồ mô tả trạng thái trước Pectra trải dài từ ngày 2025-04-28 đến 2025-05-07 , trong khi các biểu đồ sau Pectra trải dài từ ngày 2025-05-07 đến 2025-05-14 . Hơn nữa, vì mục đích phân phối sạch hơn, chúng tôi đã loại bỏ tất cả các khối đến vượt quá 12 giây kể từ khi bắt đầu khe thời gian mà chúng được đề xuất. Chúng tôi cho rằng việc khối đến vượt quá mốc 12 giây có thể liên quan đến việc tổ chức lại chứ không phải là tin nhắn quảng cáo gossipsub mà chúng tôi đang cố gắng hình dung.
Sự khác biệt giữa các châu lục
Biểu đồ sau đây hiển thị thời gian đến của khối bằng cách sử dụng điểm bắt đầu của khe, hoặc t=0, làm tham chiếu. Biểu đồ đầu tiên tập trung vào dữ liệu trước khi nâng cấp Pectra. Biểu đồ hiển thị các phân phối tương tự trên các quốc gia khác nhau, với tổng giá trị trung bình của khối đến ở mốc 2,386 giây trước khi Pectra. Tuy nhiên, điều đáng nói là chúng tôi đo được sự chênh lệch 500ms giữa giá trị trung bình của lục địa tiếp nhận nhanh nhất (Châu Âu với 2,278 giây) và giá trị trung bình chậm nhất (Nam Mỹ với 2,725). Hơn nữa, biểu đồ cũng cho thấy 95% điểm dữ liệu được nhận trong vòng 3,84 giây của khe, tôn trọng cửa sổ thông số kỹ thuật là 4 giây để truyền khối. Tuy nhiên, điều này không đúng với tất cả các quốc gia; các nút được đặt ở Châu Phi và Nam Mỹ có phần trăm thứ 95 về số khối đến vượt quá mốc 4 giây: lần lượt là ở mốc 4,327 và 4238 giây.
Trước khi nâng cấp Pectra:
Sau khi nâng cấp Pectra:
Biểu đồ thứ hai cho thấy sự phân bố của các khối đến sau khi nâng cấp Pectra. Chúng tôi quan sát thấy rằng phân bố trung bình tổng hợp (không phải phân chia theo châu lục) đã cải thiện 56ms tại mốc 2,33. Điều thú vị là chúng ta cũng có thể thấy đuôi của phân bố đã tăng 22ms tại phần trăm thứ 95 với mốc đến là 3,917 giây kể từ khi bắt đầu khe. Sự gia tăng thời gian lan truyền khối có thể được quy cho các điểm dữ liệu đến từ Nam Mỹ, nơi có sự phân bố đuôi bị chậm lại gần 220ms. Phù hợp với kỳ vọng ban đầu của chúng tôi, các quốc gia có quyền truy cập hạn chế hơn vào tài nguyên phần cứng hoặc băng thông internet (Nam Mỹ và Châu Phi) dường như là những quốc gia chịu ảnh hưởng lớn nhất về nhận thức về khối đến.
Sự khác biệt giữa các khách hàng
Các biểu đồ sau đây cho thấy CDF của các khối đến được tổng hợp theo loại máy khách đã gửi các điểm dữ liệu. Các biểu đồ hầu như không cho thấy bất kỳ sự khác biệt nào giữa bản nâng cấp Pectra trước và sau. Máy khách duy nhất có sự khác biệt tối thiểu là Prysm, báo cáo thời gian đến khối trung bình sớm hơn 120ms so với trước khi nâng cấp và cùng với Teku, có vẻ như nhận biết được các khối trước các máy khách còn lại. Mặc dù chúng ta cần phải xem xét kỹ lưỡng, chúng ta nên coi các biểu đồ này như một phép so sánh hiệu suất giữa các máy khách CL (hãy xem lưu ý miễn trừ trách nhiệm bên dưới biểu đồ).
Trước khi nâng cấp Pectra:
Sau khi nâng cấp Pectra:
Tuyên bố miễn trừ trách nhiệm
Có một số lý do khiến chúng ta không nên lấy số liệu của các máy khách CL này để so sánh hiệu suất:
- Xatu đã nhận được các điểm dữ liệu từ điểm cuối luồng sự kiện API Beacon, mặc dù là một tiêu chuẩn, nhưng mỗi máy khách quyết định cách triển khai nội bộ. Điều này có nghĩa là mỗi nhóm phát triển quyết định ở bước nào của nội bộ sẽ đóng dấu thời gian khối đến. Một số có thể đóng dấu thời gian ngay khi tin nhắn vượt qua xác thực gossipsub, những người khác có thể đóng dấu thời gian sau khi lớp ứng dụng đã xác thực.
- Sự phân bố của các nút này không đồng đều hoặc đồng nhất trên các vị trí địa lý khác nhau. Điều đó có nghĩa là các điểm dữ liệu được gửi cho các máy khách này phụ thuộc rất nhiều vào các tài nguyên mà chúng đang chạy. Ví dụ giả định: nếu một nút duy nhất báo cáo từ Nam Mỹ và đó là nút nimbus (có mức độ biểu diễn thấp hơn trong mạng), thì các số liệu bị cô lập của nimbus có khả năng sẽ trông tệ hơn các số liệu khác.
Sự xuất hiện trong suốt thời gian kỷ nguyên
Các số liệu trên cung cấp cho chúng ta cái nhìn tổng quan về trạng thái mạng trước và sau hardfork. Tuy nhiên, chúng có thể ẩn chứa những đột biến đột ngột hoặc giảm hiệu suất trong các thời kỳ cụ thể, tức là quá trình chuyển đổi hardfork. Để giải quyết vấn đề này, các biểu đồ sau đây hiển thị cùng thời gian đến của khối và tổng hợp, nhưng theo định dạng chuỗi thời gian.
Biểu đồ sau đây cho thấy bốn điểm dữ liệu mà chúng tôi cho là có liên quan nhất theo thời gian: giá trị tối thiểu, giá trị trung bình, giá trị trung vị và phần trăm thứ 95 của thời gian đến của khối được báo cáo. Biểu đồ cho thấy sự lan truyền khối ổn định trên toàn mạng, chỉ có một điểm đột biến đột ngột của đường phần trăm thứ 95 đạt đến mốc 4,6 giây 12 giờ trước khi hard fork vào ngày 7 tháng 5 lúc 00 AM UTC (hardfork diễn ra lúc 10 AM UTC ngày 7 tháng 5). Điểm đột biến kéo dài trong vài giờ trước khi phục hồi và cuối cùng làm giảm thời gian đến trung bình và trung vị xuống còn ~2,2 giây từ mức trung bình trước đó là 2,38 giây.
Chúng tôi cho rằng sự gia tăng đột biến về số lượng khối đến vào thời điểm hardfork là do một số nút cập nhật muộn, điều này thực sự có thể ảnh hưởng đến tính ổn định của lưới.
Một lần nữa, chúng tôi nhận thấy vẫn còn 5% khối lượng xe đến gần hoặc thậm chí vượt quá mốc 4 giây, điều này đáng báo động đối với các nhà xây dựng MEV, cũng như các nhà xây dựng riêng lẻ liên quan đến giá thầu mà họ chấp nhận.
Biểu đồ tiếp theo tổng hợp thời gian đến khối trung bình theo lục địa , tại đây chúng ta có thể thấy khá nhiều điểm đột biến khác nhau:
- Đợt tăng đột biến đáng chú ý đầu tiên xuất hiện vào ngày 28 tháng 4 lúc 11 giờ sáng tại khu vực Châu Phi, với thời gian đến trung bình là 3,6 giây trước khi giảm xuống mức bình thường (~2,6 giây sau 10 giờ).
- Đợt tăng đột biến thứ hai tương ứng với ngày 30 tháng 4 lúc 3 giờ sáng, khi các điểm dữ liệu từ các nút ở Châu Á báo cáo thời gian đến trung bình lên tới 3,36 giây trong khoảng 8 giờ.
- Đợt tăng đột biến cuối cùng có thể nhìn thấy là đợt tăng đột biến lớn nhất, với tổng thời gian là 19 giờ bắt đầu vào ngày 6 tháng 5 lúc 3 giờ chiều và kết thúc ngay tại hardfork. Đợt tăng đột biến này đến từ các nút ở Nam Mỹ, nơi báo cáo thời gian đến trung bình là gần 3,8 giây.
Biểu đồ tiếp theo cho thấy cùng một phân phối thời gian nhưng tổng hợp các khối đến theo giá trị trung bình trên mỗi khách hàng . Biểu đồ cho thấy các khối đến tương tự như thời kỳ trước Pectra, mặc dù hầu hết trong số chúng cho thấy sự cải thiện hiệu suất:
- Chúng tôi vẫn thấy rằng tất cả khách hàng đều gặp phải những sự cố đột biến được thảo luận ở trên, trong và sau quá trình hard fork.
- Prysm và Teku vẫn là những người đầu tiên nhận được tin nhắn với khoảng cách khoảng 300ms.
Tuyên bố miễn trừ trách nhiệm :
Kiểm tra tuyên bố từ chối trách nhiệm trước đó về các bản phân phối tổng hợp cho các máy khách CL khác nhau tại đây .
Những điều cần biết
- Theo cơ sở dữ liệu Xatu, 5% khối không đến đúng thời hạn tại các nút được kiểm soát nơi chúng tôi thu thập dữ liệu.
- Sự gia tăng của blob, như dự đoán, không ảnh hưởng đến lõi của mạng. Ít nhất là về khả năng phát và nhận khối beacon tại các khung thời gian dự kiến.
- Các phép đo của chúng tôi cho thấy, ở mức trung bình, hiệu suất tổng thể của mạng, xét về thời gian đến của khối, đã tăng nhẹ (tức là các khối đến sớm hơn khoảng 200ms).
- Chỉ có phần đuôi, nơi có thể bị hạn chế hơn về mặt tài nguyên, cho thấy hiệu suất thấp hơn.
Thông lượng băng thông mạng
Một trong những mối quan tâm chính của bản nâng cấp Pectra là mạng sẽ phản ứng như thế nào với mức tăng 50% trong mục tiêu blob và giá trị tối đa. Chính xác hơn là liệu nó có chống lại được mức tăng thông lượng băng thông đó hay không và liệu nó có vẫn sẵn sàng để tiếp tục đẩy giới hạn hay không ( bài đăng EthPandaOps , bài đăng ProbeLab ). Chương cuối cùng của nghiên cứu này trình bày kết quả từ các phép đo thông lượng băng thông tải lên mà ProbeLab đã thực hiện trong quá trình hardfork.
Các biểu đồ sau đây hiển thị CDF của thông lượng tải lên được đo lường cho các nút trong mạng lưới Ethereum mainnet khi được yêu cầu cung cấp danh sách 20 khối mới nhất từ bốn vị trí địa lý khác nhau. Biểu đồ đầu tiên hiển thị phân phối được đo lường trước khi nâng cấp Pectra và biểu đồ bên dưới các phép đo sau khi nâng cấp Pectra.
Điều thú vị là khi so sánh cả hai biểu đồ, chúng ta thấy rằng mạng không gặp bất kỳ thay đổi đáng báo động nào trong phân phối thông lượng băng thông. Tuy nhiên, chúng ta thấy có một sự giảm nhỏ trong thông lượng khả dụng cho nửa dưới của phân phối (phần trăm thứ 1 đến thứ 50).
Nhìn chung, chúng tôi đã quan sát thấy mức giảm 1 Mbps cho cả phần trăm thứ 10 và phần trăm thứ 50, chuyển từ mức trung bình là 9,94 và 24,78 Mbps sang 8,84 và 23,53 Mbps cho triển khai tại nhà và đám mây. Mức giảm này có vẻ rõ rệt hơn ở khu vực Tây Á và Đông Nam Á của Hoa Kỳ.
Tuy nhiên, vẫn còn một số tin tốt. Các phần trăm trên của phân phối cho thấy thông lượng lớn hơn mức trung bình, tăng phần trăm thứ 75 và thứ 90 từ 37,22 và 61,46 Mbps lên 40,26 và 82,12 Mbps, tương ứng cho triển khai tại nhà và đám mây.
Trước khi nâng cấp Pectra:
Sau khi nâng cấp Pectra:
Băng thông theo lục địa
Nếu chúng ta hiển thị phân phối dựa trên vị trí của nút từ xa, chúng ta sẽ nhận được biểu đồ sau.
- Các phép đo của chúng tôi từ các nút nằm ở Châu Phi cho thấy mốc 20 Mbps đã dịch chuyển từ 20% các nút ngang hàng được đo xuống chỉ còn 12% trong số chúng. Tuy nhiên, phần đuôi của bản phân phối báo cáo giới hạn băng thông cao hơn so với trước khi hard fork.
- Xu hướng có thông lượng lớn hơn ở các phần trăm cao hơn cũng áp dụng cho các phân phối được tổng hợp theo châu lục. Trong trường hợp này, các nút ở Hoa Kỳ và Châu Âu là những nút báo cáo thông lượng cao nhất. Các phép đo của chúng tôi cho thấy hơn 20% các nút ở các khu vực đó vượt quá thông lượng 40Mbps.
Trước khi nâng cấp Pectra:
Sau khi nâng cấp Pectra:
Băng thông cho mỗi loại lưu trữ
Nhờ dữ liệu thu thập được từ Nebula, chúng tôi có thể xác định loại máy chủ của các nút được thăm dò, tổng hợp các phép đo của các nút được lưu trữ trên máy chủ đám mây và các nút mà chúng tôi không thể liên hệ với bất kỳ trung tâm dữ liệu lớn nào.
Biểu đồ sau đây cho thấy rằng các phân phối không thay đổi nhiều trong cả hai trường hợp. Sự thay đổi duy nhất được nhận thấy tương ứng với sự thay đổi độ dốc của phần trăm thứ 30 của các nút được lưu trữ tại các dịch vụ đám mây, đã bị suy giảm nhẹ 1 Mbps. Dù bằng cách nào, trong cả hai trường hợp, phần đuôi của phân phối cho thấy sự gia tăng thông lượng vượt quá mức trung bình, cho thấy các nút có thể trả lời sớm hơn với toàn bộ tập hợp các khối được yêu cầu.
Trước khi nâng cấp Pectra:
Sau khi nâng cấp Pectra:
Thông lượng thuần túy không phải là thứ duy nhất chúng ta đang tìm kiếm; ít nhất là trong Ethereum, thời gian là có liên quan. Vì mạng có các cửa sổ thời gian cụ thể, nên điều quan trọng là phải xem thông lượng đó khả dụng khi nào trong khe. Các biểu đồ sau đây hiển thị thông lượng đo được trung bình được tổng hợp theo loại máy chủ và thời gian khe mà các khối beacon được yêu cầu.
Mẫu hình rất rõ ràng, có một sự sụt giảm ở cả các nút lưu trữ trên đám mây và không lưu trữ trên đám mây giữa giây đầu tiên và giây thứ tư của khe. Đây là cửa sổ khi mạng phát các khối beacon và các sidecar blob qua gossipsub.
Khi so sánh các bản phân phối trước và sau khi nâng cấp Pectra, chúng ta thấy rằng cả hai đều tuân theo cùng một mẫu chính xác trên khe cắm. Sự khác biệt duy nhất, trong trường hợp này, là giá trị trung bình đã tăng 5-6Mbps đối với các nút đám mây và 2Mbps đối với các nút không phải đám mây.
Trước khi nâng cấp Pectra:
Sau khi nâng cấp Pectra:
Những điều cần biết
- Nhìn chung, mạng vẫn hoạt động bình thường mặc dù có thêm 3 blob.
- Các nút ở đầu phân phối khả dụng của tài nguyên dường như có nhiều băng thông khả dụng hơn so với trước khi nâng cấp.
- Ở phía bên kia của quang phổ, các đối tác bị hạn chế hơn trong mạng đã nhận thấy sự sụt giảm nhỏ trong thông lượng tải lên, tuy nhiên, điều này được coi là không đáng kể hoặc nghiêm trọng.
- Theo như bài đăng trên ethresear.ch [ liên kết ], số lượng tin nhắn trùng lặp đã giảm rõ rệt do bổ sung nguyên hàm tin nhắn
IDONTWANT, nhưng ảnh hưởng của nó về mặt tính khả dụng của băng thông vẫn chưa rõ ràng trên toàn bộ phổ tính khả dụng của tài nguyên nút.
Phần kết luận
Sự kiện fork làm nổi bật xu hướng của các nhà điều hành nút là chờ đến phút cuối mới nâng cấp. Trong khi phần lớn các nút tuân theo fork mới đúng thời hạn, một phần đáng kể đã chậm tới một tuần. Các bản phát hành máy khách tương thích chỉ được áp dụng dần dần trước khi fork, cho thấy tính cấp thiết của việc nâng cấp vẫn còn thiếu ở một số phần của mạng.
Về mặt truyền bá, việc phân phối khối kịp thời vẫn chưa được đảm bảo. Khoảng 5% khối đến muộn tại các nút điều khiển và trong khi thời gian trung bình được cải thiện, phần đuôi vẫn tiếp tục gặp khó khăn—chỉ ra những khoảng cách dai dẳng về tính khả dụng của tài nguyên hoặc hiệu suất mạng.
Tuy nhiên, mạng lưới nhìn chung vẫn ở trạng thái ổn định và lành mạnh sau khi phân nhánh. Việc bổ sung thêm các blob không gây ra sự gián đoạn lớn và việc giới thiệu IDONTWANTs đã cải thiện tình hình, nhưng không đáng kể. Một số nút dường như có nhiều băng thông khả dụng hơn, có thể là do việc bổ sung IDONTWANT hoặc cung cấp thêm tài nguyên băng thông, trong khi các nút yếu hơn (có thể là home staker) có sự giảm nhẹ về thông lượng tải lên.
