lý lịch

lý lịch

Sự phát triển mạnh mẽ của các ứng dụng phi tập trung như DeFi và GameFi đã làm tăng đáng kể nhu cầu về các chuỗi khối hiệu suất cao với phí giao dịch thấp. Tuy nhiên, một thách thức chính trong việc xây dựng các chuỗi khối hiệu suất cao là sự bùng nổ lưu trữ. Hình ảnh bên dưới là biểu đồ được lấy từ Etherscan minh họa kích thước dữ liệu chuỗi khối của một nút đầy đủ Ethereum (kho lưu trữ).

tiêu đề phụ

Chia nhỏ chi phí lưu trữ

Nếu chúng tôi phân tích sâu hơn về việc sử dụng bộ nhớ, chúng tôi có thể thấy rằng dữ liệu khối chỉ chiếm khoảng 300 GB dữ liệu (từ chiều cao khối 0 đến 13,6M), ít hơn nhiều so với 9TB. Vậy 8,7TB dữ liệu còn lại đến từ đâu?

khối

• khối

• tình trạng

• Biên nhận giao dịch

Trong số đó, trạng thái là thành phần chính của 8,7TB. Vì vậy, đôi khi, chúng tôi gọi bùng nổ lưu trữ là "vụ nổ trạng thái". Nhưng tại sao nhà nước lại lớn như vậy?

Trạng thái Ethereum là gì?

Trạng thái Ethereum là một cây Merkle Patrica (MPT) trong đó

• Nút lá là ánh xạ các địa chỉ (0x...) => tài khoản, trong đó các tài khoản lưu trữ số dư, nonce, v.v. được liên kết với địa chỉ

• Các nút bên trong duy trì cấu trúc cây sao cho gốc băm của toàn bộ cây có thể được tính toán nhanh chóng

tiêu đề phụ

Geth nút đầy đủ

Để giải quyết vấn đề bùng nổ trạng thái nút lưu trữ, các kỹ sư thiên tài tại Geth đã tạo ra một chế độ mới gọi là chế độ "prune", chế độ này chỉ lưu trữ định kỳ MPT. Ở đây chúng tôi đưa ra một ví dụ đơn giản trong đó các nút chỉ lưu MPT cho mỗi 3 khối. (Lưu ý rằng để đạt được trạng thái không chứa bất kỳ khối trạng thái nào, một nút phải đạt được trạng thái gần đây nhất trước khối đó và thực hiện lại các giao dịch tiếp theo).

tiêu đề phụ

Nút đầy đủ có thể đồng bộ hóa nhanh cho Geth

Một vấn đề với việc chạy một nút bằng cách phát lại tất cả các giao dịch từ khối gốc là việc phát lại tất cả các giao dịch có thể mất nhiều thời gian. Nói chung, phải mất vài tuần để thiết lập một nút như vậy để bắt kịp trạng thái mới nhất của mạng từ khối gốc. Để tăng tốc quá trình khởi động của nút, Geth còn cung cấp chế độ đồng bộ hóa nhanh, có thể tải xuống MPT của khối ổn định mới nhất mà không cần phát lại và duy trì MPT lịch sử trước khối. Sau khi tải xuống MPT, nó sẽ phát lại các khối mới (với lưu trữ trạng thái định kỳ) giống như một nút đầy đủ.

câu hỏi

câu hỏi

Với kích thước lưu trữ Ethereum hiện tại là 447GB và 15 TPS, chúng tôi hy vọng rằng một máy tính cấu hình chung với ổ SSD 1TB sẽ có thể chạy một nút Ethereum trong một khoảng thời gian đáng kể (chẳng hạn như nhiều năm). Vì vậy, có thực sự là một vụ nổ lưu trữ hoặc một vụ nổ nhà nước? Có thể Ethereum sẽ không còn trong vài năm tới, nhưng điều gì sẽ xảy ra nếu chúng ta có thể mở rộng quy mô máy ảo của Ethereum (EVM) lên hàng trăm hoặc hàng nghìn TPS?

Hãy chuyển sự chú ý của chúng ta sang một chuỗi dựa trên EVM khác, Chuỗi thông minh Binance (BSC). Kể từ ngày 8 tháng 12 năm 2021, BSC có:

• Khoảng 984 GB dữ liệu trên chuỗi, trong đó khối chiếm khoảng 550 GB và trạng thái chiếm khoảng 400 GB.

• 2,06623 tỷ giao dịch, 100 TPS

Nếu chúng tôi dự đoán thêm kích thước dữ liệu theo số lượng giao dịch, chúng tôi có thể nhận được:

Nếu TPS là 100, tức là ~3.153 triệu TPY

• 1 năm sau, tổng TX ~5.219M, khối ~1.375 TB, trạng thái ~1.085TB

• 3 năm sau, tổng TX ~11.525M, khối ~3.025TB, trạng thái ~2.387 TB

Nếu TPS là 150 (TPS cao nhất quan sát được), thì đó là ~4.730 M TPY

• 1 năm sau, tổng TX ~6.796M, khối ~1.809 TB, trạng thái ~1.427 TB

• 3 năm sau, tổng TX ~16.256M, khối ~4.327 TB, trạng thái ~3.414TB

Tóm lại, đối với BSC, nếu tốc độ hiện tại được duy trì hoặc thậm chí cao hơn, thì nó sẽ sớm đạt đến cùng kích thước lưu trữ của nút lưu trữ Ethereum, điều mà các máy tính thông thường gần như không thể chạy được.

Sự cố bùng nổ lưu trữ đối với các chuỗi khối có TPS cực cao

Nếu chúng ta đưa ra một giả định táo bạo hơn về một blockchain có TPS rất cao (chẳng hạn như QuarkChain có thể làm được), con số này sẽ trở thành bao nhiêu? Hãy xem xét một chuỗi khối có 1000 TPS và phân tích kích thước khối và trạng thái của nó, sẽ là:

• Giả sử rằng kích thước tx là khoảng 100 byte, dung lượng lưu trữ cần thiết cho mỗi khối là 1000 (TPS) * 100 (byte trên mỗi tx) * 365 * 24 * 3600 = 2,86 TB

• Giả sử MPT có 10 tỷ tài khoản (nhiều hơn dân số thế giới!), chúng tôi hy vọng kích thước trạng thái sẽ là 150G (kích thước trạng thái Ethereum) / 0,18B (địa chỉ Ethereum duy nhất) * 10B = 8,3 TB

Tổng hợp những con số này lại với nhau, dễ dàng đi đến kết luận rằng đây là yêu cầu mà hầu hết các máy tính có cấu hình bình thường sẽ không đáp ứng được!

tối ưu hóa

tiêu đề phụ

tối ưu hóa lưu trữ trạng thái

Tối ưu hóa đầu tiên chúng tôi đề xuất là sử dụng KV đơn giản thay vì MPT. Khi MPT lớn, tất cả các nút bên trong MPT có thể rất tốn kém. Và tối ưu hóa của chúng tôi sẽ loại bỏ tất cả các nút bên trong MPT. Giả sử rằng dữ liệu của mỗi tài khoản là khoảng 50 byte (20 địa chỉ + 2 nonce + 12 tài khoản + các tài khoản khác), chúng ta có thể lưu dữ liệu của 10 tỷ tài khoản tiếp theo dưới dạng:

• ~10B * 50 + 100GB (mã) = 600 GB, bằng khoảng 1/10 so với bản MPT!

Mặc dù có những lợi ích to lớn khi sử dụng KV đơn giản, nhưng một vấn đề lớn là chúng tôi không thể tính toán trạng thái sau băm của mỗi khối trong một khoảng thời gian khối ngắn như vậy, điều đó có nghĩa là chúng tôi mất đi những lợi ích sau của Ethereum:

• Đồng bộ hóa nhanh: Tải xuống trạng thái của bất kỳ khối nào và nhanh chóng đồng bộ hóa mạng bằng cách phát lại các khối còn lại

• Phát hiện rẽ nhánh (hoặc phát hiện Byzantine): Liệu một khối mới được tạo từ một ngang hàng có dẫn đến trạng thái khác với khối được thực thi cục bộ hay không.

Để kích hoạt tính năng đồng bộ hóa nhanh, chúng tôi có khối chụp nhanh định kỳ (khoảng thời gian chụp nhanh = epoch = ví dụ: 14 tuần). Một khối ảnh chụp nhanh chứa thông tin bổ sung của hàm băm trước trạng thái, là hàm băm sau trạng thái của khối ảnh chụp nhanh trước đó (băm trạng thái sau khi thực hiện giao dịch):

• Một khối không phải ảnh chụp nhanh không duy trì hàm băm trạng thái mà thay vào đó có hàm băm gia tăng, hàm băm này chứa hàm băm của các hoạt động cơ sở dữ liệu ban đầu (xóa, cập nhật) của tất cả các giao dịch cho khối đó. Điều này làm cho khả năng phát hiện fork!

• Chúng tôi sử dụng hàm băm trạng thái trước giao dịch thay vì hàm băm trạng thái sau giao dịch cho các khối trong Ethereum. Lý do là các nút không thể ngay lập tức tính toán hàm băm trạng thái sau giao dịch, nhưng bằng cách sử dụng hàm băm trạng thái trước giao dịch, nút có thể sử dụng toàn bộ khoảng thời gian kỷ nguyên để tính toán hàm băm. Ví dụ: giả sử quá trình tính toán hàm băm trạng thái xử lý 10 triệu dữ liệu trạng thái mỗi giây, thì việc tính toán toàn bộ trạng thái 600 GB sẽ mất 600 GB / 10 triệu ~ 16,67 giờ (so với epoch = 14 tuần)

Quá trình tính toán hàm băm trước trạng thái như sau:

1. Khi một khối chụp nhanh được nhận và hoàn tất, trạng thái KV của nó sẽ được chụp nhanh và một chuỗi nền được tạo để lặp lại trên tất cả các mục nhập KV (địa chỉ => tài khoản) và tính toán hàm băm.

2. Khi khối ảnh chụp nhanh tiếp theo được tạo, giá trị băm trước trạng thái được tính toán sẽ được lưu trữ trong khối đó. Tương tự như vậy, nút sẽ tạo một ảnh chụp nhanh khác của KV và tính toán hàm băm của nó trong nền.

3. Khi khối chụp nhanh tiếp theo được tạo, ngoài việc lưu trữ hàm băm trước trạng thái, nút hiện có thể giải phóng ảnh chụp nhanh KV của khối chụp nhanh, điều đó có nghĩa là tất cả dữ liệu đã xóa/cập nhật từ khối chụp nhanh sẽ tự động được thu gom rác (ví dụ nén trong levelDB)

tiêu đề phụ

Khối tối ưu hóa lưu trữ

Sử dụng các khối ảnh chụp nhanh, chúng tôi có thể giảm thêm dữ liệu khối cần thiết trong nút bằng cách chỉ lưu trữ:

• Ảnh chụp nhanh trạng thái trước khi thực hiện giao dịch của khối chụp nhanh mới nhất, nghĩa là trạng thái (mới nhất — 1) sau khi thực hiện giao dịch của khối chụp nhanh

• (mới nhất — 1) khối đầy đủ sau khối ảnh chụp nhanh

Chúng ta có thể làm một phép toán đơn giản về chi phí lưu trữ: giả sử thời lượng kỷ nguyên là 2 tuần, kích thước khối thay đổi là

• 2 * 14 (ngày) * 24 (giờ) * 3600 (giây) * 100 * 1000 (TPS) = 224 GB!

tóm tắt

tóm tắt

Chúng tôi đã phân tích việc sử dụng bộ nhớ hiện tại của Ethereum:

• Không chỉ các khối, lưu trữ trạng thái tiêu tốn rất nhiều dung lượng

• Khi TPS > 1000, mức sử dụng bộ nhớ quá cao

Chúng tôi đề xuất tối ưu hóa các khối và nêu rõ:

• Kích thước khối giảm từ 2,86 TB xuống 224 GB mỗi năm

• Kích thước trạng thái (~10 tỷ tài khoản) giảm từ 8,3 TB xuống 600 GB

• Một máy tính cấu hình bình thường 2TB sẽ đủ cho các nút chạy trong thời gian dài

• Cảm ơn

Cảm ơn

Cảm ơn dapp-learning đã tổ chức sự kiện này.