Sử dụng băng thông sau khi chức năng rút Ethereum được kích hoạt

Tiêu đề gốc: "Sử dụng băng thông sau khi rút Ethereum"

Tác giả gốc: Alex Miller 

Bản tổng hợp gốc: Kxp, BlockBeats

Vào ngày 12 tháng 4, Ethereum đã trải qua quá trình nâng cấp Shapella. Trên thực tế, đây là sự kết hợp của hai bản nâng cấp khác nhau: bản nâng cấp Capella của lớp đồng thuận và bản nâng cấp Thượng Hải của lớp thực thi. Nâng cấp chung này bao gồm nhiều chức năng khác nhau, nhưng chức năng được mong đợi nhất là việc rút các trình xác nhận, điều này phá vỡ vòng khép kín đặt cược. Sau khi quá trình nâng cấp bắt đầu hoạt động, tất cả người xác thực có thông tin xác thực loại 0x01 có thể rút cổ phần của họ theo một trong hai cách:

1. Người dùng có thể hướng dẫn khách hàng đồng thuận của họ hoàn toàn thoát khỏi trình xác nhận. Điều này sẽ đặt trình xác thực vào hàng đợi, sau đó toàn bộ số dư của trình xác thực đó sẽ được phân tán đến địa chỉ rút tiền của lớp thực thi.

2. Những người xác thực không thoát sẽ tự động "xóa" số dư của họ vượt quá 32ETH cứ sau 4 ngày hoặc lâu hơn. Vấn đề là việc thực thi tự động - người dùng không cần hướng dẫn khách hàng đồng thuận của họ thực hiện việc này, ngay cả khi họ muốn giữ lại số dư của trình xác thực, họ cũng không thể.

Tùy chọn đầu tiên là mở khóa đặt cược và đặt giới hạn rủi ro đặt cược của người dùng - cụ thể, những người xác thực rút tiền vẫn phải chứng minh/ Đề xuất được đưa ra cho đến khi nó vượt qua hàng đợi, độ dài của nó xác định hình phạt dự kiến đối với trình xác nhận không thể tiếp tục hoạt động (ví dụ: 4 ngày trong hàng đợi = 4 ngày hình phạt ngoại tuyến).

Tuy nhiên, từ góc độ mạng, tùy chọn thứ hai thú vị hơn, vì những tin nhắn này sẽ được gửi bởi tất cả những người xác thực trong hàng đợi rút tiền (không giống như hàng đợi thoát) phát sóng liên tục.

Shapella đã thêm hai loại tin nhắn phát liên tục mới: rút tiền đồng thuận và EIP4895 có thể thực thi được. Điều này có nghĩa là tất cả các nút trên mạng đều có hai chủ đề tin đồn mới và chúng ta có thể mong đợi mức tiêu thụ băng thông sẽ tăng lên. Nhưng câu hỏi đặt ra là băng thông đã tăng bao nhiêu?

Capella trước và sau khi chụp nhanh dữ liệu

Tôi đang tự mình chạy hộp đặt cược và thực hiện Hệ thống theo dõi, vì vậy tôi đã kiểm tra xem liệu có bất kỳ thay đổi đáng kể nào về mức tiêu thụ băng thông sau Shapella hay không. Tôi có dữ liệu khoảng một tuần trước và sau khi nâng cấp và kết quả khá rõ ràng. Mỗi loại dữ liệu được theo dõi trước khi nâng cấp từ ngày 3 tháng 4 đến ngày 12 tháng 4 và sau nâng cấp từ ngày 12 tháng 4 đến ngày 18 tháng 4. Xin lưu ý rằng phần sau đây không phải là bản phân tích đầy đủ mà chỉ là phần trình bày đơn giản về dữ liệu.

Lưu ý: Đầu tiên, khi Capella trực tuyến, bộ đệm của thông báo BLSToExecutionChange—một loại thông báo đồng thuận khác chuyển đổi chứng từ rút tiền loại 0x00 thành loại 0x01—đã được bỏ chặn, dẫn đến sự gia tăng bùng nổ lưu lượng tin đồn ở lớp đồng thuận. Vì thông tin xác thực chỉ có thể được thay đổi một lần cho mỗi trình xác thực nên đây là trạng thái tồn tại trong thời gian ngắn. Thứ hai, một số lượng lớn trình xác thực đã thoát - chủ yếu là từ Kraken do các nhiệm vụ thoát do quyết toán của SEC gây ra - cũng được đưa vào mạng, nhưng tôi không nghĩ yếu tố này rất quan trọng xét về mặt lưu lượng truy cập tăng đột biến.

Băng thông tổng thể của hệ thống

Chỉ số quan trọng nhất là băng thông tổng thể được sử dụng bởi danh mục đặt cược của tôi . Đây là phép đo cấp độ Linux để theo dõi số bit truyền qua giao diện mạng, trong trường hợp của tôi là Ethernet.

· Lưu lượng truy cập đi: 8,5 Mb/s -- 10,41 Mb/s (+22%)

· Lưu lượng truy cập vào: 7,19 Mb/ s -- 8,48 Mb/giây (+18%)

Việc sử dụng ứng dụng khách

Tiếp theo, tôi xem xét các ứng dụng khách cá nhân (thực thi và đồng thuận). Tôi đang sử dụng geth làm ứng dụng khách thực thi và ngọn hải đăng làm ứng dụng khách đồng thuận. Lưu ý rằng biểu đồ bên dưới sử dụng kB/s, nhưng tôi đã chuyển đổi các giá trị thành Mb/s để phù hợp với mức sử dụng băng thông tổng thể của hệ thống được hiển thị ở trên.

Lưu ý: Việc sử dụng băng thông của hai máy khách không bằng mức sử dụng của toàn bộ mạng, vì vậy rõ ràng có những nguồn lưu lượng truy cập khác không xuất hiện trong các nguồn này quan điểm giám sát. Tuy nhiên, thật thú vị khi xem xét sự khác biệt tương đối của từng khách hàng.

Geth

Những thay đổi về băng thông máy khách đồng thuận hơi lạ vì chúng hiển thị rất lớn tăng trưởng trung bình, nhưng điều này chủ yếu là do một số mức tăng đột biến cực lớn. Tôi không chắc chắn những mức tăng đột biến này là gì vì chúng dường như tập trung xung quanh bản nâng cấp (cuối ngày 12/4 - đầu ngày 13/4) và trở nên rải rác hơn kể từ đó. Nếu bạn biết nguyên nhân gây ra những đột biến này, vui lòng cung cấp nó trong phần bình luận.

· Lưu lượng truy cập vào: 0,404 Mb/s -- 0,614 Mb/s (+52%)

· Lưu lượng truy cập đi: 0,888 Mb/ s -- 1,448 Mb/giây (+63%)

Lưu ý của biên tập viên: Sau khi bài viết được xuất bản, tôi muốn hãy kiểm tra khoản phí Ethereum này theo khung thời gian để xem liệu nó có thể có mối tương quan chặt chẽ với lưu lượng truy cập geth tăng đột biến nói trên hay không. Phí trung bình đã cao hơn kể từ khi nâng cấp, điều này tôi nghĩ là nguyên nhân giải thích một số mức tăng đột biến, nhưng không phải là điều duy nhất giải thích sự khác biệt lớn về mức tăng đột biến lưu lượng truy cập.

Phạm vi dữ liệu được quan sát Mạng Ethereum phí bên trong (Nguồn: siêu âm.money) 

Lighthouse

Không giống như các trang tổng quan khác , màn hình ngọn hải đăng của tôi kết hợp lưu lượng truy cập vào và ra vào một chế độ xem. Kết quả rất đáng chú ý, nhưng nhỏ hơn nhiều so với geth. Tuy nhiên, giống như geth, sự khác biệt về băng thông tăng lên đáng kể sau khi quá trình nâng cấp đi vào hoạt động.

Lưu ý: Trang tổng quan này không cung cấp số liệu trung bình nên tôi phải ước tính những con số này dựa trên biểu đồ bên dưới.

· Lưu lượng kết hợp: ~9,6 Mb/s -- ~11,2 Mb/s (+ ~ 16,6%)

Kết luận

Còn quá sớm để rút ra quá nhiều suy luận từ những dữ liệu này, nhưng đây là một số phát hiện mà tôi nghĩ đáng chú ý:

· Lưu lượng truy cập mạng tổng thể đã tăng đáng kể : khoảng 20%. Điều này chủ yếu được mong đợi, nhưng cao hơn tôi mong đợi. Việc thêm các loại tin nhắn mới vào giao thức tin đồn sẽ luôn có một số tác động đến lưu lượng truy cập.

· Lưu lượng truy cập trung bình được tiêu thụ bởi mức tiêu thụ băng thông của cả lớp đồng thuận và lớp thực thi đều tăng đáng kể (lớp thực thi thay đổi nhiều hơn), nhưng phương sai thậm chí còn tăng lên hơn. Phương sai này dường như không giảm sau 6 ngày đo.

· Việc nâng cấp Thượng Hải (thực hiện nâng cấp) khiến lưu lượng truy cập mạng geth tăng đáng kể. Tôi không chắc nguyên nhân gây ra hành vi này là gì, nhưng nó đáng được chú ý. Lưu ý rằng cho đến nay đã khoảng 48 giờ trôi qua và không có gai nào quá lớn nên có lẽ mật độ dày đặc của những gai này chỉ là một hiện tượng ngắn ngủi.

Chúng ta cũng có thể quan sát các giá trị đo lưu lượng này trong thời gian dài và có thể tìm thấy nhiều hiện tượng thú vị.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia