Nếu chúng ta chỉ giữ lại dữ liệu trạng thái hoạt động trong 1 năm thì sao?

Xin chân thành cảm ơn Gary Rong, Gabriel Rocheleau và Guillaume Ballet đã xem xét bài viết này.

Chúng ta đã thảo luận rất nhiều về việc hết hạn trạng thái như một giải pháp lâu dài cho sự gia tăng trạng thái của Ethereum, nhưng lại có rất ít dữ liệu về việc nó sẽ ảnh hưởng như thế nào đến hoạt động hàng ngày của các node.

Để làm cho cuộc thảo luận cụ thể hơn, chúng tôi đã thực hiện một thí nghiệm đơn giản sử dụng khối lượng công việc thực tế của mainnet : thực hiện ~1 năm khối trên (1) một nút có trạng thái đầy đủ và (2) một nút chỉ giữ trạng thái hoạt động trong 1 năm (dựa trên những gì thực sự được chạm vào trong quá trình thực thi Block ).

Lưu ý: Đây không phải là bản triển khai giao thức đầy đủ về việc hết hạn trạng thái (không có chứng thực khôi phục, không có truy xuất mạng). Đây là một thử nghiệm hiệu năng "giả định": điều gì sẽ xảy ra với hiệu năng thực thi nếu cơ sở dữ liệu chỉ chứa trạng thái mà bạn thực sự truy cập trong khoảng thời gian đó?

Tóm lại

• Quy mô các bang giảm khoảng 78% .
• Thời gian thực thi lại Block đã được cải thiện khoảng 15% so với cùng kỳ năm trước đối với các khối trên mạng chính.
• Hiệu suất đọc chiếm phần lớn mức tăng, đặc biệt là các thao tác đọc dữ liệu lưu trữ ( P50 -46% , P99 -36% ).
• Độ trễ đuôi được cải thiện, điều này rất quan trọng để duy trì độ trễ gần đầu khi chịu tải ( chèn Block P99 -21% )

Thiết lập tiêu chuẩn

Trong thí nghiệm này, chúng tôi so sánh một nút có toàn bộ trạng thái với một nút chỉ lưu trữ trạng thái hoạt động trong 1 năm .

• Ứng dụng khách: go-ethereum v1.16.5
• Máy móc: tuân theo thông số kỹ thuật trong Đề xuất cải tiến Ethereum (EIP)-7870
• Khối lượng công việc: thực thi các khối từ 19.999.256 đến 22.627.956 (~1 năm)
• Số lần chạy: 3 lần, báo cáo giá trị trung bình.

Cách xây dựng cơ sở dữ liệu trạng thái hoạt động 1 năm:

1. Đồng bộ một nút từ Block 19.999.256 → 22.627.956 (nút “theo dõi”).
2. Mỗi khi một phần trạng thái (tài khoản, khe lưu trữ, nút trie) được truy cập trong quá trình xử lý Block , hãy đánh dấu nó là đã được chạm đến.
3. Bắt đầu từ cơ sở dữ liệu tại Block 19.999.256, sau đó xóa trạng thái chưa được đánh dấu bằng cách sử dụng các đánh dấu từ nút theo dõi. Đây sẽ trở thành cơ sở dữ liệu đã được cắt tỉa.
4. Cơ sở dữ liệu đã được cắt tỉa sẽ không được nén thủ công sau khi xóa trạng thái.

Lưu ý: Các giao dịch thất bại vẫn kích hoạt việc đánh dấu (vì chúng vẫn tác động đến trạng thái trong quá trình thực thi). Trong các triển khai hết hạn thực tế, việc đánh dấu có thể không được xem xét đối với các giao dịch thất bại, điều này làm tăng tập hợp các trạng thái không hoạt động.

Kết quả

1. Quy mô tiểu bang

1538×1244 57.7 KB

Bảng phân tích chi tiết (đơn vị GB):

Kết quả: Giảm đáng kể dung lượng ổ đĩa.

• Dung lượng tối đa: 359,03 GB
• Trạng thái sau khi cắt tỉa: 80,86 GB ( -77,5% )

Phần lớn sự giảm thiểu dung lượng bộ nhớ đến từ các nút cây trie lưu trữ. Điều này phản ánh thực tế là dung lượng lưu trữ lớn hơn nhiều so với cây trie tài khoản ngay từ đầu, vì vậy có nhiều thứ cần được cắt tỉa hơn. Cây trie tài khoản, do nhỏ hơn, có mật độ truy cập cao hơn: mỗi lần truy cập tài khoản giữ cho một phần lớn hơn của cây trie hoạt động. Kết quả cũng phù hợp với phân tích trạng thái trước đó của chúng tôi.

"Snapshot" trong Geth có nghĩa là gì?
Trong geth, snapshot là dạng biểu diễn phẳng của các nút lá trong cây trie (tài khoản và bộ nhớ) để tăng tốc độ đọc mà không cần phải duyệt qua các đường dẫn trong cây trie. Chúng chủ yếu là một cấu trúc tối ưu hóa việc đọc.

2. Thời gian thực thi từ đầu đến cuối

1516×758 30 KB

Kết quả: nút đã được cắt tỉa hoàn thành nhanh hơn khoảng 15% so với nút chưa được cắt tỉa.

• Thời gian hoàn thành toàn bộ: 75,13 giờ
• Trạng thái sau khi cắt tỉa: 63,75 giờ ( -15% )

3. Chèn Block và tải trước

2390×1046 143 KB

Kết quả: cả thao tác chèn Block và tìm nạp trước đều nhanh hơn với cơ sở dữ liệu đã được cắt tỉa, đặc biệt là ở P99.

• Chèn Block (đường dẫn thực thi):
  • P50: 86,10ms → 78,17ms ( -9 )
  • P99: 565,33ms → 445,00ms ( -21% )
• Tải trước Block :
  • P50: 44,40ms → 33,83ms ( -24% )
  • P99: 419,00ms → 281,00ms ( -33% )

“Prefetch” trong geth là gì?
Geth chạy một bộ nạp trước song song thực hiện các giao dịch để tìm hiểu trạng thái nào sẽ cần thiết, kéo các đối tượng đó vào bộ nhớ, và sau đó loại bỏ các thay đổi. Mục tiêu là làm nóng bộ nhớ đệm để quá trình thực thi thực tế (bao gồm cả tính toán gốc trạng thái) truy cập bộ nhớ thường xuyên hơn và thực hiện ít thao tác đọc/ghi ổ đĩa hơn.

Trên thực tế, hiệu suất của prefetch đặc biệt quan trọng trong geth. Bộ prefetcher thực thi các giao dịch đồng thời và thường xuyên cần phải phân giải trạng thái từ cơ sở dữ liệu bên dưới, điều này tương tự như mô hình truy cập mà chúng ta mong đợi từ danh sách truy cập cấp khối (BAL). Ngược lại, trong quá trình thực thi Block , người ta kỳ vọng rằng hầu hết các truy cập trạng thái sẽ truy cập vào bộ nhớ cache, khiến cho việc quan sát những cải tiến nhỏ trở nên khó khăn hơn.

Nhìn chung, những cải tiến trong việc tải trước dữ liệu cho thấy lợi ích của việc loại bỏ trạng thái không hoạt động khỏi cơ sở dữ liệu.

4. Tiểu bang đọc và cập nhật

1596×1372 136 KB

Kết quả: Tốc độ đọc thông tin tài khoản và bộ nhớ được cải thiện đáng kể.

• Tài khoản đã đọc:
  • P50: 3,08ms → 2,56ms ( -17% )
  • P99: 102,00ms → 73,50ms ( -28% )
• Cập nhật tài khoản:
  • P50: 1,84ms → 1,62ms ( -12% )
  • P99: 33,57ms → 32,23ms ( -4% )
• Đọc dữ liệu lưu trữ:
  • P50: 10,50ms → 5,65ms ( -46% )
  • P99: 285,67ms → 183,67ms ( -36% )
• Cập nhật bộ nhớ:
  • P50: 6,70ms → 6,68ms (~ổn định)
  • P99: 106,00ms → 100,60ms ( -5% )

Điều này phù hợp với kết quả chèn/tải trước Block . Các bản cập nhật cho thấy sự cải thiện hạn chế vì geth đã tải trước các nút trie cần thiết trong quá trình thực thi giao dịch và chặn cho đến khi quá trình tải trước hoàn tất. Do đó, các bản cập nhật trie được thực hiện hoàn toàn trong bộ nhớ, chỉ đơn giản là đặt các thay đổi trạng thái vào các vị trí thích hợp trong trie.

Những phát hiện và hàm ý chính

1. Quy mô quốc gia giảm mạnh

Trạng thái được tinh chỉnh nhỏ hơn khoảng 4,4 lần, giảm từ 359 GB xuống còn 81 GB. Việc giảm dung lượng như vậy giúp giảm đáng kể gánh nặng lưu trữ và I/O cho các nhà điều hành nút, và đẩy ranh giới "phần cứng hợp lý" theo hướng dễ tiếp cận hơn.

Việc giảm thiểu tập trung ở các node trie lưu trữ và ảnh chụp nhanh lưu trữ, điều này cho thấy phần lớn trạng thái của Ethereum là lưu trữ hợp đồng không hoạt động. Nếu phần lớn sự tiết kiệm đến từ việc lưu trữ, thì một hướng đi tiềm năng cho việc hết hạn trạng thái là tập trung vào các giải pháp ưu tiên lưu trữ hợp đồng hết hạn. Hướng đi này không ảnh hưởng đến tài khoản, tránh được một số rủi ro về trải nghiệm người dùng dễ thấy hơn (ví dụ: tài khoản đột ngột cần được khôi phục), đồng thời nắm bắt được phần lớn lợi ích của việc hết hạn. Nhược điểm là chúng ta có thể hướng người dùng sử dụng tài khoản như một hình thức lưu trữ hợp đồng để tránh hết hạn, điều này có thể dẫn đến việc chúng ta phải thực hiện cả việc hết hạn ở cấp độ tài khoản và cấp độ slot.

1. Giảm kích thước trạng thái = thực thi nhanh hơn.

Việc thu nhỏ trạng thái giúp cải thiện quá trình xử lý Block chủ yếu bằng cách giảm chi phí truy xuất trạng thái từ đĩa. Trong cùng một năm xử lý các khối trên mạng chính, thời gian thực thi từ đầu đến cuối được cải thiện khoảng 15%. Các chỉ số vi mô cũng nhất quán với điều này: những cải thiện lớn nhất thể hiện ở các thao tác đọc, đặc biệt là đọc dữ liệu lưu trữ.

Điều này phù hợp với những gì bạn mong đợi từ các cơ sở dữ liệu dựa trên LSM: tập dữ liệu nhỏ hơn có xu hướng cải thiện tính cục bộ. Trên thực tế, điều này tạo ra dư địa theo hai hướng. Chúng ta có thể tăng giới hạn gas và giảm chi phí vận hành của các tiểu bang nếu quy mô của tiểu bang được kiểm soát.

1. Cải thiện độ trễ đuôi

Ngoài việc tăng tốc độ trung bình, kết quả quan trọng hơn về mặt vận hành là sự cải thiện hiệu suất ở phần đuôi chuỗi. Cơ sở dữ liệu được tinh chỉnh giúp giảm đáng kể độ trễ P99 đối với việc chèn Block và tìm nạp trước, điều này có nghĩa là sẽ ít xảy ra tình trạng tắc nghẽn kéo dài trong quá trình xác thực. Những sự tắc nghẽn này thường là nguyên nhân khiến các nút thỉnh thoảng bị tụt lại phía sau đầu chuỗi khi xử lý khối lượng công việc đột biến.

Điều đó có ý nghĩa gì đối với sự phát triển của tiểu bang?

Thí nghiệm của chúng tôi cho thấy rằng nếu Ethereum có thể giới hạn một cách an toàn trạng thái được lưu trữ cục bộ trong một cửa sổ trượt của dữ liệu được truy cập gần đây, thì các máy khách sẽ được hưởng lợi từ:

• Yêu cầu phần cứng thấp hơn .
• Có thêm dư địa để tăng Xuất lượng , vì các thao tác trên toàn hệ thống hiện đang là nút thắt cổ chai lớn.
• Khả năng phục hồi tốt hơn khi chịu tải , nhờ cải thiện độ trễ đuôi.

Tuy nhiên, phần còn thiếu chính là việc triển khai thời hạn hết hạn trạng thái thực tế. Cho dù là trong giao thức hay ngoài giao thức, sẽ luôn có độ trễ bổ sung do cần phải đánh dấu, xóa và khôi phục trạng thái đã hết hạn. Thử nghiệm của chúng tôi ở đây sử dụng khối lượng công việc trên mạng chính cho thấy kết quả tích cực, nhưng những sự đánh đổi này cần được đánh giá toàn diện đối với bất kỳ đề xuất thời hạn hết hạn cụ thể nào.

Công việc trong tương lai

• Đánh giá xem việc loại bỏ các trạng thái không hoạt động có hiệu quả (hoặc không hiệu quả) như thế nào trong các trường hợp xấu nhất.
• Lặp lại quy trình so sánh với các khách hàng khác của EL và so sánh kết quả.
• Khám phá các biến thể của quy tắc hết hạn (ví dụ: thời hạn hết hạn 6 tháng, chỉ xóa dữ liệu lưu trữ hợp đồng, chỉ xóa dữ liệu tài khoản) và xem kết quả so sánh khác nhau như thế nào.