Lộ trình giải pháp lưu trữ Ethereum: thách thức và cơ hội cùng tồn tại

Nguồn: GeekWeb3

Tóm tắt:

· Dữ liệu mạng Ethereum kể từ EIP-4844 Áp lực thông lượng và lưu trữ đang tăng lên ngày qua ngày và yêu cầu lưu trữ ngày càng tăng đã mang đến những thách thức lớn cho các nút Ethereum. Để giảm áp lực lưu trữ, một số khách hàng Ethereum xóa dữ liệu lịch sử Ethereum được lưu trữ cục bộ và tính nhất quán trong hành vi lưu trữ của các nút đầy đủ khác nhau dần dần bị phá vỡ.

· Để đảm bảo rằng tất cả khách hàng Ethereum có thể đạt được hành vi nhất quán, EIP-4444 và EIP-4844 sẽ xóa dữ liệu lịch sử. hành vi đượcchuẩn hóavà sẽ trở thành tiêu chuẩn cho các nút Ethereum trong tương lai.

· Do đó, nếu bạn muốn phát lại dữ liệu lịch sử để khôi phục trạng thái Lớp 1 hoặc Lớp 2 mới nhất, bạn phải dựa vào các cơ sở dịch vụ tập trung bên ngoài giao thức Ethereum, điều này nhắc nhở mọi người Khám phá các giải pháp lưu trữ phi tập trung, phù hợp với Ethereum hơn

· Mạng Cổng thông tin Ethereum là mạng P2P phi tập trung, nhẹ dành cho Tất cả các loại dữ liệu Ethereum bao gồm cả dữ liệu lịch sử. Nó được thiết kế cho các thiết bị có nguồn tài nguyên hạn chế và cung cấp các dịch vụ Ethereum JSON-RPC. Mạng Lịch sử và Mạng Chuỗi Beacon gần như đã sẵn sàng.

· EthStorage là mạng lưu trữ mô-đun được khuyến khích dành cho dữ liệu BLOB EIP-4844. Để lưu trữ BLOB, người dùng có thể gọi hợp đồng lưu trữ trên L1, sử dụng ETH làm phí lưu trữ và ghi lại giá trị băm của BLOB trên chuỗi. Theo thời gian, phí lưu trữ sẽ được phân bổ dần dần cho các nhà cung cấp dịch vụ lưu trữ cung cấp bằng chứng về việc lưu trữ BLOB ngoài chuỗi.

·  Mạng thử nghiệm EthStorage hiện đang chạy trên mạng thử nghiệm Ethereum Sepolia và nhiều người tham gia cộng đồng đã chứng minh thành công trạng thái lưu trữ cục bộ của họ. Các kế hoạch trong tương lai bao gồm phát triển mạng trạng thái Ethereum phi tập trung, cho phép bằng chứng lưu trữ cho dữ liệu có kích thước linh hoạt và cho phép truy cập phi tập trung vào mạng EthStorage trực tiếp từ trình duyệt.

Lời cảm ơn: Cảm ơn Piper Merriam từ Ethereum Foundation, Karthik Raju từ Polychain và Qiang Zhu từ EthStorage vì đã cung cấp phản hồi cho bài viết này.

Nền tảng:

Vào ngày 22 tháng 10 năm 2023, Péter Szilágyi, trưởng nhóm phát triển Go-Ethereum (Geth) nổi tiếng trên Twitter đã bày tỏ mối quan ngại của mình về giải pháp lưu trữ dữ liệu của Ethereum. Ông chỉ ra rằng trong khi ứng dụng khách Geth giữ lại tất cả dữ liệu lịch sử, thì các loại ứng dụng khách Ethereum khác, chẳng hạn như Nethermind và Besu, có thể được cấu hình để xóa một số dữ liệu lịch sử Ethereum nhất định (chẳng hạn như các khối lịch sử). Điều này sẽ khiến một số nút máy khách hoạt động không nhất quán với các máy khách khác, điều này không công bằng đối với người vận hành máy khách Geth. Chủ đề trên ngay lập tức gây ra một cuộc thảo luận sôi nổi về giải pháp lưu trữ trong lộ trình Ethereum.

Thách thức về lưu trữ

Tại sao Nethermind và Besu cho phép các nhà khai thác khách hàng xóa dữ liệu lịch sử cục bộ? Quyết định này phản ánh những vấn đề gì?

Theo quan điểm của chúng tôi, có hai lý do chính:

• Yêu cầu về bộ nhớ số lượng khách hàng Ethereum ngày càng cao hơn.

• Không có ưu đãi hay hình phạt nào trong giao thức đối với việc lưu trữ dữ liệu lịch sử Ethereum.

Lý do đầu tiên bắt nguồn từ nhu cầu lưu trữ ngày càng tăng của khách hàng Ethereum. Biểu đồ hình tròn bên dưới hiển thị mức phân bổ dung lượng lưu trữ của nút Geth mới tính đến ngày 13 tháng 12 năm 2023, với chiều cao khối là 18.779.761.

Như trong hình:

• Tổng dung lượng lưu trữ: 925,39 GB

• Dữ liệu lịch sử (khối/biên nhận giao dịch): khoảng 628,69 GB< /p>

• Dữ liệu trạng thái trong Merkle Patricia Trie (MPT): khoảng 269,74 GB

Lý do thứ hai là các Nút Ethereum thiếu -giao thức khuyến khích hoặc hình phạt để lưu trữ các khối lịch sử. Mặc dù giao thức khuyến khích các nút lưu trữ tất cả dữ liệu lịch sử nhưng nó không cung cấp bất kỳ cơ chế nào để khuyến khích lưu trữ hoặc trừng phạt các hành vi vi phạm. Các nút sẵn sàng lưu trữ và cung cấp quyền truy cập bên ngoài vào dữ liệu lịch sử vì lòng vị tha hơn là vì động lực.

Tất nhiên, các nhà khai thác khách hàng có quyền tự do xóa hoặc sửa đổi tất cả dữ liệu lịch sử mà không bị phạt. Ngược lại, các nút Trình xác thực phải duy trì và cập nhật trạng thái hoàn chỉnh cục bộ để tránh bị cắt giảm do đề xuất/bỏ phiếu cho các khối không hợp lệ.

Do đó, khi chi phí lưu trữ trở thành gánh nặng đáng kể cho các nút, không có gì ngạc nhiên khi một số nhà khai thác nút chọn xóa dữ liệu lịch sử. Trong trường hợp không có dữ liệu lịch sử, máy khách nút có thể giảm đáng kể chi phí lưu trữ, giảm dung lượng lưu trữ bị chiếm dụng từ khoảng 1TB xuống còn khoảng 300GB.

Minh họa: Cấu hình Nethermined chạy một nút không có khối lịch sử - hiện đang tiết kiệm khoảng 460GB chi phí lưu trữ

Với khả năng cung cấp dữ liệu Ethereum As (DA) sắp tới leo thang, thách thức lưu trữ sẽ tăng cường. Con đường mở rộng quy mô hoàn toàn Ethereum DA bắt đầu với EIP-4844 trong bản nâng cấp DenCun, bản nâng cấp này giới thiệu một đối tượng lớn nhị phân có kích thước cố định (BLOB) và một mô hình phí độc lập được gọi là blobGasprice. Mỗi BLOB được đặt thành 128KB Sau khi triển khai EIP-4844, mỗi khối chứa tối đa 6 BLOB. Để mở rộng thông lượng dữ liệu, Ethereum có kế hoạch sử dụng mã hóa xóa 1D Reed-Solomon, ban đầu cho phép 32 BLOB trên mỗi khối và đạt mức 256 BLOB trên mỗi khối khi được mở rộng hoàn toàn.

Nếu Ethereum DA chạy hết công suất (256 BLOB mỗi khối), mạng Ethereum DA dự kiến ​​sẽ nhận được khoảng 80 TB dữ liệu DA mỗi năm, một con số vượt xa hầu hết khả năng lưu trữ của Node .

Lộ trình lưu trữ Ethereum và hậu quả của nó< /h2 >

Tweet về lộ trình Ethereum do Vitalik đăng đã đề cập rằng Purge chủ yếu liên quan đến việc lưu trữ.

Chi phí lưu trữ tăng cao đã thu hút sự chú ý của các nhà nghiên cứu sinh thái Ethereum. Để giải quyết vấn đề này và đảm bảo tính nhất quán trên tất cả các máy khách,các nhà nghiên cứu đang nghiên cứu các đề xuất xóa rõ ràng dữ liệu lịch sử cho các máy khách Ethereum. Hai đề xuất chính là:

· EIP-4444: Giới hạn dữ liệu lịch sử trong quá trình thực thi của khách hàng: Đề xuất này cho phép khách hàng xóa các khu vực cũ hơn một năm trước đó. Giả sử kích thước khối trung bình là 100K, giới hạn dữ liệu khối lịch sử là khoảng 250 GB (100K * (3600 * 24 * 365)/12, giả sử thời gian khối = 12 giây).

· EIP-4844: Giao dịch BLOB được phân chia: loại bỏ dữ liệu BLOB cũ hơn 18 ngày. So với EIP-4444, đây là một cách tiếp cận tích cực 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ả sử thời gian chặn = 12 giây).

Hậu quả của việc xóa tất cả dữ liệu lịch sử của khách hàng là gì? Vấn đề chính là các nút mới không thể đồng bộ hóa về trạng thái mới nhất thông qua chế độ "đồng bộ hóa hoàn toàn". "Đồng bộ hóa hoàn toàn" là phương pháp phát lại dữ liệu lịch sử và đồng bộ hóa dữ liệu từ khối gốc sang khối mới nhất. . Theo đó, chúng ta phải thực hiện "đồng bộ hóa nhanh" hoặc "đồng bộ hóa trạng thái" để đồng bộ hóa trực tiếp trạng thái mới nhất của nút Ethereum. Cách tiếp cận này đã được triển khai trong Geth như một cách mặc định để chạy đồng bộ.

Việc xóa dữ liệu lịch sử của mạng chính Ethereum theo một nút cũng sẽ gây ra sự cố trong Ethereum L2, tức là các nút Layer2 mới được thêm vào không thể phát lại tất cả dữ liệu lịch sử của Layer2. Đồng bộ hóa với trạng thái mới nhất hiện tại. Ngoài ra, do các nút L1 không duy trì trạng thái L2 nên phương pháp "đồng bộ hóa nhanh" của L2 không thể lấy trực tiếp trạng thái Layer2 mới nhất dựa trên các khối Layer1, điều này vi phạm một giả định quan trọng cần thiết để Layer2 kế thừa bảo mật Ethereum.

Giải pháp dự kiến ​​sẽ dựa vào các dịch vụ của bên thứ ba của chính dự án Infura/Etherscan/L2 để lưu trữ dữ liệu lịch sử Lớp 2 hoặc các bản sao trạng thái, đây là một giải pháp tập trung đạt được thông qua các biện pháp khuyến khích gián tiếp, ngoài giao thức .

Vấn đề cốt lõi mà chúng tôi muốn thảo luận là:

• Chúng ta có thể cải thiện khả năng lưu trữ và quyền truy cập không? Tìm một giải pháp phi tập trung tốt hơn?

• Có thể tìm ra giải pháp mang lại động lực trực tiếp cho các nút và được đảm bảo bởi chính mạng Ethereum (ví dụ: được thực hiện bởi các hợp đồng L1) không?

• Với tất cả những điều này, liệu chúng ta có thể cung cấp một giải pháp phi tập trung hoàn toàn, được khuyến khích trực tiếp trong giao thức cho tuyến lưu trữ Ethereum không?

Giải pháp

Giải pháp 1: Mạng cổng thông tin Ethereum

Mạng Cổng thông tin Ethereum là một mạng lưới phi tập trung, gọn nhẹ để kết nối với giao thức Ethereum. Nó cung cấp các giao diện Ethereum JSON-RPC như eth_call, eth_getBlockByNumber, v.v., giúp chuyển đổi các yêu cầu JSON-RPC thành các yêu cầu P2P cho các bảng băm phân tán (DHT), tương tự như mạng IPFS. Không giống như IPFS, cho phép lưu trữ bất kỳ loại dữ liệu nào và dễ bị dữ liệu rác, mạng Portal P2P lưu trữ độc quyền dữ liệu Ethereum, chẳng hạn như tiêu đề khối lịch sử và dữ liệu giao dịch, thông qua công nghệ xác minh ứng dụng khách nhẹ được tích hợp trong mạng Portal.

Một tính năng quan trọng của mạng Portal là. Thiết kế vận hành gọn nhẹ và khả năng tương thích với các thiết bị có hạn chế về tài nguyên. Nó có thể chạy trên các nút có dung lượng lưu trữ vài MB và bộ nhớ thấp, do đó thúc đẩy quá trình phân cấp. Ngay cả điện thoại di động hoặc thiết bị Raspberry Pi cũng có khả năng tham gia mạng và góp phần giải quyết vấn đề Ethereum DA.

Mạng Portal đã được phát triển phù hợp với triết lý về sự đa dạng của ứng dụng khách Ethereum, với các ứng dụng khách được viết bằng Rust, JavaScript và Nim. Mạng Beacon và Mạng Lịch sử đã có sẵn, trong khi Mạng Nhà nước đang được phát triển tích cực. Điều đáng chú ý là mạng Portal không cung cấp các ưu đãi trực tiếp cho việc lưu trữ dữ liệu.

Minh họa: Mạng cổng thông tin Rust client (Trin) với giới hạn lưu trữ 100 MB đang hoạt động

Giải pháp 2: Mạng EthStorage

Mạng EthStorage là mạng lưu trữ được khuyến khích phi tập trung dành riêng cho việc lưu trữ BLOB EIP-4844 và được tài trợ bởi dự án ESP.

· Độ tin cậy tối thiểu: Không giống như các giải pháp hiện có yêu cầu cầu nối 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 EthStorage không cần cấp phép để lưu trữ điểm giao. Quá trình lưu trữ BLOB như sau: người dùng ký một giao dịch mang BLOB và gọi phương thức put(key, blob_idx) của hợp đồng lưu trữ. Hợp đồng lưu trữ sau đó sẽ ghi lại hàm băm BLOB trên chuỗi. Sau đó, nhà cung cấp lưu trữ sẽ tải xuống và lưu trữ BLOB trực tiếp từ mạng Ethereum DA, do đó bỏ qua vấn đề cầu nối dữ liệu.

· Chi phí lưu trữ phù hợp với các ưu đãi: Khi phương thức put() được gọi, giao dịch phải gửi phí lưu trữ (qua tin nhắn .value) và ký gửi vào hợp đồng. Sau khi nút lưu trữ ngoài chuỗi thành công gửi và xác minh bằng chứng lưu trữ, phí lưu trữ này sẽ được phân bổ dần cho nút lưu trữ theo thời gian. So với mô hình phí lưu trữ Ethereum hiện tại là trả phí lưu trữ một lần cho nhà sản xuất khối (người đề xuất), phí lưu trữ được trả theo thời gian tuân theo mô hình dòng tiền chiết khấu - giả định rằng theo thời gian, chi phí lưu trữ sẽ giảm tương ứng với giá ETH. Sự đổi mới lớn này được EthStorage giới thiệu nhằm điều chỉnh phí và mức đóng góp lưu trữ của các nút lưu trữ.

· Bằng chứng về lưu trữ: Bằng chứng về lưu trữ được lấy cảm hứng từ việc lấy mẫu tính sẵn có của dữ liệu và việc lấy mẫu trong EthStorage là để lưu trữ trong khoảng thời gian thời gian BLOB. Để 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 hợp đồng thông minh và sự phát triển công nghệ SNARK mới nhất.

· Hoạt động không được phép: Bất kỳ nút lưu trữ nào trong EthStorage đều có thể được thanh toán miễn là nó lưu trữ dữ liệu và thường xuyên gửi chứng chỉ lưu trữ trên chuỗi. .

Từ góc độ blockchain mô-đun, EthStorage hoạt động như một bộ lưu trữ Ethereum L2, nhưng nó tính phí lưu trữ thay vì phí giao dịch. EthStorage là lớp lưu trữ mô-đun dành cho Ethereum giúp cải thiện khả năng mở rộng lưu trữ và giảm chi phí (nhắm mục tiêu ~ 1000 lần) bằng cách lập chỉ mục băm BLOB trên chuỗi.

Về mặt phát triển, EthStorage đã được tích hợp với EIP-4844 trên mạng thử nghiệm Ethereum Sepolia. Chúng tôi đã kiểm tra chặt chẽ EthStorage và mạng thử nghiệm Ethereum Sepolia, bao gồm cả việc ghi khoảng hàng trăm GB BLOB vào EthStorage. Hơn 100 người tham gia cộng đồng đã tham gia mạng lưới và chứng minh thành công bộ nhớ cục bộ của họ.

Ưu điểm chính của mạng EthStorage là cung cấp các ưu đãi trực tiếp phi tập trung trên Ethereum - một tính năng đột phá theo hiểu biết tốt nhất hiện tại của chúng tôi. Tuy nhiên, hạn chế của mạng này là nó được thiết kế dành riêng cho BLOB có kích thước cố định.

Bảng thử nghiệm Ethereum Sepolia trên EthStorage

Hướng tới tương lai

Mặc dù lưu trữ Ethereum Nó chưa nhận được sự quan tâm lớn nhưng nó có ý nghĩa quan trọng trong hệ sinh thái Ethereum. Khi mạng Ethereum phát triển nhanh chóng, việc lưu trữ và truy cập dữ liệu Ethereum trở thành những thách thức chính. Mạng Cổng thông tin và Mạng EthStorage vẫn đang ở giai đoạn đầu và có nhiều hướng phát triển dài hạn quan trọng cần chú ý:

Mạng dữ liệu trạng thái Ethereum phi tập trung với khả năng truy cập có độ trễ thấp: Truy cập trạng thái Ethereum theo cách phi tập trung và có thể xác minh là một nhiệm vụ quan trọng nhưng đầy thách thức. Sử dụng mô hình mạng DHT truyền thống, việc truy vấn thông tin tài khoản thường yêu cầu nhiều truy vấn tới bộ ba nút nội bộ được lưu trữ trong các nút P2P khác nhau. Điều này thường dẫn đến sự chậm trễ đáng kể. Làm thế nào để sử dụng cấu trúc của cây trạng thái để tăng tốc độ truy cập chính là chìa khóa. Mạng trạng thái sắp tới của mạng Cổng thông tin Ethereum nhằm giải quyết vấn đề này.

Tích hợp mạng Cổng thông tin với mạng EthStorage: Mạng Cổng thông tin có thể được mở rộng liền mạch để hỗ trợ dữ liệu BLOB. Nhóm EthStorage đã triển khai một phần chức năng này. Bước tiếp theo là hợp nhất các mạng này và cung cấp mạng JSON-RPC phi tập trung có thể cung cấp quyền truy cập có thể lập trình vào 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 bộ lưu trữ BLOB được mở rộng do EthStorage cung cấp, chúng tôi có thể kích hoạt các dApp mới trên Ethereum, chẳng hạn như các trang web phi tập trung động (chẳng hạn như Twitter/YouTube/Wikipedia phi tập trung, v.v.).

Quyền truy cập phi tập trung cho trình duyệt: Tương tự như giao thức ipfs:// để truy cập dữ liệu trong mạng IPFS, ngành web3 cần giao thức truy cập gốc Ethereum để hỗ trợ duyệt truy cập trực tiếp vào máy chủ để mở khóa tiềm năng to lớn của dữ liệu phong phú của Ethereum. Dữ liệu bao gồm nhiều lĩnh vực, từ quyền sở hữu token và 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ỗ trợ bởi khả năng của hợp đồng thông minh và lưu trữ Ethereum trong tương lai. Trong lĩnh vực này, giao thức web3:// được xác định bởi ERC-4804/6860 hiện đang được phát triển và quảng bá 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 có 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 cũng là điều bắt buộc để giải quyết dữ liệu có kích thước động (chẳng hạn như các khối lịch sử và thậm chí cả các đối tượng trạng thái, v.v.) Phải làm. Việc phát triển các thuật toán phức tạp có thể nâng cao khả năng thích ứng của các giải pháp lưu trữ.

Trong quá trình theo đuổi, chúng tôi hy vọng rằng thông qua những nỗ lực này, chúng ta có thể cùng đóng góp vào lộ trình Ethereum và đặt nền tảng cho các giải pháp lưu trữ phi tập trung trong tương lai cho hệ sinh thái Ethereum.