Bản đồ đường đi lưu trữ Ethereum: Thách thức và Cơ hội
Tuyển chọn TechFlowTuyển chọn TechFlow
Bản đồ đường đi lưu trữ Ethereum: Thách thức và Cơ hội
Nhu cầu lưu trữ ngày càng tăng đang đặt ra thách thức lớn cho các nút Ethereum.
Chuyên sâu báo cáo Web3Tác giả: EthStorage
Tóm tắt
-
Nhu cầu lưu trữ ngày càng tăng đang đặt ra thách thức lớn cho các nút Ethereum.
-
Do giới hạn về dung lượng lưu trữ, một số client đã bắt đầu xóa bớt dữ liệu lịch sử, dẫn đến sự thiếu nhất quán trong hành vi lưu trữ giữa các nút đầy đủ (full node) trên mạng.
-
Để đảm bảo tính nhất quán giữa tất cả các client, việc xóa bớt dữ liệu lịch sử đang được chuẩn hóa thông qua EIP-4444 và EIP-4844.
-
Do đó, việc khôi phục trạng thái mới nhất của L1 hoặc L2 bằng cách phát lại dữ liệu lịch sử sẽ cần tới các dịch vụ tập trung nằm ngoài giao thức, thúc đẩy nhu cầu tìm kiếm các giải pháp phi tập trung, đồng bộ với Ethereum hơn.
-
Mạng Portal Ethereum là một mạng ngang hàng (P2P) nhẹ, phi tập trung, dành cho mọi loại dữ liệu Ethereum, kể cả dữ liệu lịch sử. Mạng này được thiết kế đặc biệt cho các thiết bị có tài nguyên hạn chế và cung cấp dịch vụ JSON-RPC của Ethereum. Mạng lịch sử và mạng chuỗi beacon gần như đã sẵn sàng hoạt động.
-
Mạng EthStorage là một mạng lưu trữ mô-đun có cơ chế khuyến khích, chuyên dùng để lưu trữ dữ liệu BLOB theo EIP-4844. Để lưu BLOB, người dùng gọi phương thức put() trên hợp đồng lưu trữ L1, gửi ETH làm phí lưu trữ và ghi lại hash BLOB trên chuỗi. Theo thời gian, phí lưu trữ sẽ dần được phân phối cho các nhà cung cấp lưu trữ đã nộp bằng chứng lưu trữ BLOB ngoài chuỗi. Mạng thử nghiệm EthStorage hiện đang hoạt động trên mạng thử nghiệm Sepolia của Ethereum, nhiều thành viên cộng đồng đã thành công trong việc chứng minh khả năng lưu trữ cục bộ của họ.
-
Kế hoạch tương lai bao gồm phát triển một mạng trạng thái Ethereum phi tập trung, thực hiện bằng chứng lưu trữ cho dữ liệu kích thước động, và truy cập phi tập trung trực tiếp từ trình duyệt.
Lời cảm ơn: Cảm ơn Piper Merriam từ EF, Karthik Raju từ Polychain và Qiang từ EthStorage đã đóng góp phản hồi cho bài viết này.
Bối cảnh
Ngày 22 tháng 10 năm 2023, Peter Szilagyi – trưởng nhóm phát triển Go-Ethereum (Geth) nổi tiếng – đã bày tỏ lo ngại sâu sắc trên Twitter. Ông chỉ ra rằng mặc dù client Geth vẫn giữ lại toàn bộ dữ liệu lịch sử, nhưng các client Ethereum khác như Nethermind và Besu có thể được cấu hình để xóa một phần dữ liệu lịch sử Ethereum (ví dụ như khối lịch sử và tiêu đề khối). Điều này khiến hành vi của các client không còn thống nhất và gây bất lợi cho Geth. Sự kiện này đã khơi mào cho những tranh luận sôi nổi và gay gắt xung quanh vấn đề lưu trữ trong lộ trình phát triển Ethereum.
Thách thức về lưu trữ
Tại sao Nethermind và Besu lại chọn ngừng lưu trữ dữ liệu lịch sử? Động lực đằng sau quyết định này là gì? Theo quan điểm của chúng tôi, có hai lý do chính:
-
Yêu cầu lưu trữ của các client Ethereum đang trở nên ngày càng cao.
-
Việc lưu trữ dữ liệu lịch sử Ethereum không có cơ chế khuyến khích hay trừng phạt nào trong giao thức.
Lý do đầu tiên xuất phát từ nhu cầu lưu trữ ngày càng tăng khi vận hành các client Ethereum. Để hiểu rõ hơn về mức độ cụ thể, biểu đồ hình tròn dưới đây cho thấy phân bổ dung lượng lưu trữ của một nút Geth mới tại khối số 18.779.761 vào ngày 13 tháng 12 năm 2023.
Như hình vẽ:
-
Tổng dung lượng lưu trữ: 925,39 GB
-
Dữ liệu lịch sử (khối/giao dịch): khoảng 628,69 GB
-
Dữ liệu trạng thái trong Merkle Patricia Trie (MPT): khoảng 269,74 GB
Lý do thứ hai là thiếu cơ chế khuyến khích hoặc trừng phạt bên trong giao thức đối với việc lưu trữ các khối lịch sử. Mặc dù giao thức yêu cầu các nút phải lưu trữ toàn bộ dữ liệu lịch sử, nhưng lại không cung cấp bất kỳ cơ chế nào để khuyến khích hay trừng phạt việc tuân thủ. Việc lưu trữ và chia sẻ dữ liệu lịch sử vì vậy trở thành hành động mang tính vị tha thuần túy, và người vận hành client hoàn toàn có thể tự do xóa hoặc sửa đổi dữ liệu mà không bị trừng phạt. Trái lại, các nút Validator buộc phải duy trì và cập nhật trạng thái đầy đủ tại chỗ để tránh bị phạt Slash do đề xuất hoặc bỏ phiếu cho khối không hợp lệ.
Vì vậy, khi chi phí lưu trữ trở thành gánh nặng lớn đối với các nút, việc một số nhà vận hành nút lựa chọn xóa dữ liệu lịch sử là điều dễ hiểu. Khi không có dữ liệu lịch sử, dung lượng lưu trữ của client nút có thể giảm đáng kể, từ khoảng 1TB xuống còn khoảng 300GB.
Hình minh họa: Cấu hình Nethermind chạy nút không có khối lịch sử — hiện tại tiết kiệm khoảng 460GB dung lượng lưu trữ
Cùng với việc nâng cấp khả năng sẵn sàng dữ liệu (DA) sắp tới của Ethereum, thách thức về lưu trữ sẽ gia tăng mạnh mẽ. Con đường mở rộng khả năng sẵn sàng dữ liệu Ethereum bắt đầu từ nâng cấp DenCun với EIP-4844, giới thiệu một đối tượng nhị phân lớn (BLOB) kích thước cố định và mô hình phí riêng biệt gọi là blobGasPrice. Mỗi BLOB được đặt ở mức 128KB, EIP-4844 cho phép mỗi khối chứa tối đa 6 BLOB. Để mở rộng thông lượng dữ liệu, Ethereum dự kiến áp dụng mã Reed-Solomon 1 chiều, ban đầu cho phép 32 BLOB mỗi khối và khi mở rộng đầy đủ sẽ đạt tới 256 BLOB mỗi khối.
Nếu mạng DA Ethereum hoạt động ở công suất tối đa (256 BLOB mỗi khối), mạng DA Ethereum dự kiến sẽ nhận khoảng 80 TB dữ liệu DA mỗi năm — con số này vượt xa khả năng lưu trữ của phần lớn các nút.
Lộ trình lưu trữ Ethereum và hệ quả
Lộ trình Ethereum do Vitalik đăng tải trên Twitter, đề cập Purge chủ yếu liên quan đến lĩnh vực lưu trữ
Chi phí lưu trữ ngày càng tăng đã thu hút sự chú ý của các nhà nghiên cứu trong hệ sinh thái Ethereum. Để giải quyết vấn đề này và đảm bảo tính nhất quán giữa tất cả các client, các nhà nghiên cứu đang xây dựng một số đề xuất nhằm quy định rõ ràng việc xóa dữ liệu lịch sử. Hai đề xuất chính là:
-
EIP-4444: Giới hạn dữ liệu lịch sử trong client thực thi: Đề xuất này cho phép client xóa các khối lịch sử cũ hơn một năm. Giả sử kích thước khối trung bình là 100KB, giới hạn dữ liệu khối lịch sử sẽ vào khoảng 250 GB (100K * (3600 * 24 * 365) / 12, giả định thời gian khối = 12 giây).
-
EIP-4844: Giao dịch phân mảnh BLOB: EIP-4844 loại bỏ các BLOB sau 18 ngày. So với EIP-4444, đây là phương pháp quyết liệt hơn, giới hạn kích thước BLOB lịch sử ở khoảng 100 GB ((18 * 3600 * 24) * 128K * 6 / 12, giả định thời gian khối = 12 giây).
Việc xóa dữ liệu lịch sử khỏi tất cả các client sẽ dẫn đến hậu quả gì? Vấn đề chính là các nút mới sẽ không thể đồng bộ trạng thái mới nhất thông qua chế độ «full sync», tức là thực thi từng giao dịch từ khối khởi nguyên đến khối mới nhất. Thay vào đó, ta phải sử dụng «snap sync» hoặc «state sync» để đồng bộ trực tiếp trạng thái mới nhất từ các nút Ethereum. Phương pháp này đã được triển khai trong Geth và hiện là chế độ đồng bộ mặc định.
Tương tự, hậu quả này cũng ảnh hưởng đến tất cả các L2, nghĩa là các nút mới của L2 sẽ không thể hoàn toàn đồng bộ trạng thái mới nhất của khởi nguyên L2 Ethereum bằng cách phát lại các khối L2 từ khởi nguyên đến hiện tại. Hơn nữa, do các nút L1 không duy trì trạng thái L2, phương pháp «snap sync» của L2 không thể suy ra trạng thái L2 mới nhất từ L1, vi phạm giả định quan trọng về việc kế thừa đảm bảo an toàn của Ethereum. Giải pháp dự kiến sẽ phụ thuộc vào các dịch vụ bên thứ ba như Infura / Etherscan / hoặc chính dự án L2 để lưu trữ dữ liệu lịch sử hoặc bản sao trạng thái L2. Đây là giải pháp tập trung, đạt được thông qua các cơ chế khuyến khích gián tiếp nằm ngoài giao thức.
Vấn đề cốt lõi mà chúng tôi muốn khám phá là:
-
Liệu chúng ta có thể tìm được giải pháp phi tập trung tốt hơn trong việc lưu trữ và truy cập?
-
Liệu có thể có giải pháp đồng bộ với Ethereum thông qua cơ chế khuyến khích trực tiếp (ví dụ: trên hợp đồng L1)?
-
Trên nền tảng đó, liệu chúng ta có thể cung cấp một giải pháp hoàn toàn phi tập trung, có cơ chế khuyến khích trực tiếp trong giao thức cho lộ trình lưu trữ Ethereum?
Giải pháp
Giải pháp 1: Mạng Portal Ethereum
Mạng Portal Ethereum là một mạng truy cập nhẹ, phi tập trung, dùng để kết nối với giao thức Ethereum. Nó cung cấp các giao diện JSON-RPC Ethereum như eth_call, eth_getBlockByNumber, chuyển đổi các yêu cầu JSON-RPC thành các yêu cầu P2P tới bảng băm phân tán (DHT), tương tự như mạng IPFS. Khác với IPFS cho phép lưu trữ mọi loại dữ liệu và dễ bị tấn công dữ liệu rác, mạng P2P Portal chuyên lưu trữ dữ liệu Ethereum như tiêu đề khối lịch sử và dữ liệu giao dịch khối. Điều này được thực hiện nhờ công nghệ xác minh client nhẹ tích hợp sẵn trong mạng Portal.
Một đặc điểm quan trọng của mạng Portal là thiết kế nhẹ và khả năng tương thích với các thiết bị có tài nguyên hạn chế. Nó có thể hoạt động trên các nút có vài megabyte dung lượng lưu trữ và bộ nhớ thấp, từ đó thúc đẩy tính phi tập trung. Ngay cả điện thoại di động hay thiết bị Raspberry Pi cũng có thể tham gia mạng và đóng góp vào tính sẵn có dữ liệu Ethereum.
Việc phát triển mạng Portal phù hợp với triết lý đa dạng hóa client Ethereum, với các client được viết bằng Rust, JavaScript và Nim. Mạng beacon và mạng lịch sử hiện đã sẵn sàng sử dụng, trong khi mạng trạng thái đang được phát triển tích cực. Cần lưu ý rằng mạng Portal không cung cấp cơ chế khuyến khích trực tiếp cho việc lưu trữ dữ liệu — tất cả các nút trong mạng đều hoạt động theo tinh thần vị tha.
Hình minh họa: Client Rust của mạng Portal (Trin) với giới hạn lưu trữ 100MB đang hoạt động
Giải pháp 2: Mạng EthStorage
Mạng EthStorage là một mạng lưu trữ phi tập trung có cơ chế khuyến khích, chuyên dùng để lưu trữ BLOB theo EIP-4844, và được tài trợ bởi dự án ESP.
-
Tin cậy tối thiểu: Khác với các giải pháp hiện tại cần cầu dữ liệu tập trung, EthStorage dựa vào sự đồng thuận của Ethereum và mô hình tin cậy 1/m từ các nút lưu trữ EthStorage phi giấy phép. Quá trình lưu BLOB diễn ra như sau: Người dùng ký một giao dịch mang theo BLOB, gọi phương thức put(key, blob_idx) trên hợp đồng lưu trữ. Sau đó, hợp đồng lưu trữ sẽ ghi hash BLOB lên chuỗi. Các nhà cung cấp lưu trữ sau đó sẽ tải và lưu BLOB trực tiếp từ mạng DA Ethereum, từ đó tránh được vấn đề cầu dữ liệu.
-
Chi phí lưu trữ phù hợp với cơ chế khuyến khích: Khi gọi phương thức put(), giao dịch phải gửi phí lưu trữ (qua msg.value) và gửi vào hợp đồng. Sau khi các nút lưu trữ ngoài chuỗi thành công nộp và xác minh bằng chứng lưu trữ, khoản phí này sẽ dần được phân phối cho các nút lưu trữ theo thời gian. So với mô hình phí lưu trữ Ethereum hiện tại trả một lần cho người đề xuất khối, việc thanh toán phí lưu trữ theo thời gian tuân theo mô hình dòng tiền chiết khấu — giả định rằng chi phí lưu trữ sẽ giảm tương đối so với giá ETH theo thời gian. Sáng kiến quan trọng này của EthStorage làm cho phí và đóng góp lưu trữ của các nút được đồng bộ hóa.
-
Bằng chứng lưu trữ: Bằng chứng lưu trữ được lấy cảm hứng từ việc lấy mẫu khả năng sẵn có dữ liệu, trong khi việc lấy mẫu của EthStorage tập trung vào các BLOB đã lưu trong một khoảng thời gian. Để xác minh hiệu quả việc lấy mẫu trên chuỗi, EthStorage tận dụng tối đa các phát triển mới nhất về hợp đồng thông minh và công nghệ SNARK.
-
Hoạt động không cần giấy phép: Bất kỳ nút lưu trữ nào trong EthStorage chỉ cần lưu trữ dữ liệu và nộp bằng chứng lưu trữ định kỳ trên chuỗi đều có thể nhận được thù lao.
Xét từ góc độ blockchain mô-đun, EthStorage đóng vai trò là lớp lưu trữ L2 của Ethereum, nhưng thu phí lưu trữ thay vì phí giao dịch. Bằng cách lập chỉ mục hash BLOB trên chuỗi, EthStorage là một lớp lưu trữ mô-đun của Ethereum, nâng cao khả năng mở rộng và giảm chi phí lưu trữ (mục tiêu khoảng 1000 lần).
Về phát triển, EthStorage đã được tích hợp với EIP-4844 trên mạng thử nghiệm Sepolia của Ethereum. Chúng tôi đã thực hiện kiểm tra tải với EthStorage và mạng thử nghiệm Sepolia của Ethereum, bao gồm việc ghi hàng trăm GB BLOB vào EthStorage. Hơn 100 thành viên cộng đồng đã tham gia mạng và thành công trong việc chứng minh khả năng lưu trữ cục bộ của họ.
Ưu điểm chính của mạng EthStorage là cung cấp cơ chế khuyến khích trực tiếp, phi tập trung trên nền tảng Ethereum — theo hiểu biết hiện tại của chúng tôi, đây là một tính năng tiên phong. Tuy nhiên, hạn chế của mạng là nó được thiết kế riêng cho BLOB kích thước cố định.
Bảng điều khiển EthStorage trên mạng thử nghiệm Sepolia của Ethereum
Triển vọng tương lai
Mặc dù lưu trữ Ethereum chưa nhận được sự chú ý lớn, nhưng nó có tầm quan trọng đáng kể trong hệ sinh thái Ethereum. Cùng với sự phát triển nhanh chóng của mạng Ethereum, việc lưu trữ và truy cập dữ liệu Ethereum đang trở thành thách thức then chốt. Mạng Portal và mạng EthStorage vẫn còn ở giai đoạn sơ khai, và còn nhiều hướng phát triển dài hạn quan trọng cần theo dõi:
-
Mạng dữ liệu trạng thái Ethereum cho phép truy cập phi tập trung, độ trễ thấp. Việc truy cập dữ liệu trạng thái Ethereum theo cách phi tập trung và có thể xác minh là nhiệm vụ then chốt nhưng đầy thách thức. Với mô hình mạng DHT truyền thống, việc truy vấn thông tin tài khoản thường đòi hỏi nhiều lần truy vấn tới các nút trie nội bộ được lưu trữ trên các nút P2P khác nhau. Điều này thường dẫn đến độ trễ khá lớn. Làm thế nào để tận dụng cấu trúc cây trạng thái nhằm tăng tốc độ truy cập là chìa khóa. Mạng trạng thái sắp ra mắt của mạng Portal Ethereum được thiết kế nhằm giải quyết vấn đề này.
-
Tích hợp mạng Portal và mạng EthStorage: Mạng Portal có thể được mở rộng liền mạch để hỗ trợ dữ liệu BLOB. Nhóm EthStorage đã phần nào triển khai chức năng này. Bước tiến tiếp theo là thống nhất các mạng này, cung cấp một mạng JSON-RPC phi tập trung có thể truy cập lập trình các BLOB thông qua hợp đồng. Bằng cách kết hợp logic ứng dụng trong hợp đồng với khả năng lưu trữ BLOB quy mô lớn từ EthStorage, chúng ta có thể bật các dApp mới trên Ethereum, ví dụ như các trang web phi tập trung động (ví dụ: Twitter/YouTube/Wikipedia phi tập trung).
-
Truy cập phi tập trung từ trình duyệt: Tương tự như giao thức ipfs:// để truy cập dữ liệu trong mạng IPFS, ngành công nghiệp web3 cần một giao thức truy cập gốc Ethereum để hỗ trợ truy cập trực tiếp từ trình duyệt, nhằm giải phóng tiềm năng khổng lồ của dữ liệu phong phú trên Ethereum. Dữ liệu này bao trùm nhiều lĩnh vực, từ quyền sở hữu token, số dư tài khoản đến hình ảnh NFT và các trang web phi tập trung động, tất cả đều được hưởng lợi từ các hợp đồng thông minh và chức năng lưu trữ Ethereum trong tương lai. Trong lĩnh vực này, giao thức web3:// được định nghĩa bởi ERC-4804/6860 hiện đang được phát triển và phổ biến tích cực để đạt được mục tiêu này.
-
Bằng chứng lưu trữ nâng cao cho dữ liệu kích thước động: Ngoài BLOB cố định, việc khám phá bằng chứng lưu trữ nâng cao là cần thiết để xử lý dữ liệu kích thước động (ví dụ như khối lịch sử hay thậm chí là các đối tượng trạng thái). Phát triển các thuật toán phức tạp sẽ tăng tính thích nghi cho các giải pháp lưu trữ.
Trong hành trình theo đuổi này, chúng tôi hy vọng rằng qua những nỗ lực trên, chúng ta cùng nhau đóng góp vào lộ trình Ethereum và đặt nền mó
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
