Tóm tắt

• Những yêu cầu lưu trữ ngày càng tăng đặt ra những thách thức đáng kể cho các nút Ethereum.
• Một số khách hàng đã bắt đầu cắt tỉa dữ liệu lịch sử do hạn chế lưu trữ, dẫn đến hành vi lưu trữ không nhất quán giữa các nút đầy đủ trong mạng lưới.
• Để đảm bảo sự căn chỉnh trên tất cả các khách hàng, việc cắt tỉa dữ liệu lịch sử đang được tiêu chuẩn hóa trong EIP-4444 và EIP-4844
• Do đó, việc khôi phục trạng thái L1 hoặc L2 mới nhất bằng cách phát lại dữ liệu lịch sử phụ thuộc vào các dịch vụ tập trung ngoài giao thức, thúc đẩy việc khám phá các giải pháp Ethereum phân cấp hơn
• Mạng cổng Ethereum là một mạng P2P nhẹ, phi tập trung cho tất cả các loại dữ liệu Ethereum bao gồm dữ liệu lịch sử. Nó được thiết kế cho các thiết bị có tài nguyên hạn chế và cung cấp dịch vụ Ethereum JSON-RPC. Mạng lịch sử và mạng đèn hiệu gần như đã sẵn sàng để sử dụng.
• Mạng lưu trữ EthStorage là mạng lưu trữ modul được khuyến khích cho EIP-4844 BLOBs. Để lưu trữ một BLOB, người dùng gọi hợp đồng lưu trữ L1 put()phương pháp với BLOB hash và một phí trong ETH. Phí sẽ được phân phối dần dần cho các nhà cung cấp lưu trữ sau khi nộp chứng minh hợp lệ về việc lưu trữ off-chain BLOBs theo thời gian. Testnet EthStorage đang chạy trên Ethereum Sepolia testnet với nhiều cộng đồng tham gia thành công chứng minh lưu trữ địa phương của họ.
• Các dự án tương lai bao gồm việc phát triển một mạng lưới trạng thái phi tập trung, triển khai chứng minh lưu trữ cho dữ liệu có kích thước động, và truy cập phi tập trung trực tiếp từ trình duyệt.

Xác nhận: Rất cảm ơn Piper Merriam từ EF, Karthik Raju từ Polychain, Qiang từ EthStorage đã cung cấp phản hồi về bài viết.

Nền tảng

Vào ngày 22 tháng 10 năm 2023, Péter Szilágyi, nhà phát triển hàng đầu của Go-Ethereum (Geth), đã bày tỏ sự lo lắng sâu sắc của mình trên Twitter. Anh ấy chỉ ra rằng trong khi các máy khách Geth lưu giữ tất cả dữ liệu lịch sử, các máy khách Ethereum khác như Nethermind và Besu có thể được cấu hình để hoạt động mà không có một số dữ liệu lịch sử Ethereum, chẳng hạn như các khối và tiêu đề khối lịch sử. Điều này khiến tất cả các máy khách không nhất quán và không công bằng với Geth. Điều này đã kích thích các cuộc thảo luận sôi nổi và tranh luận xoay quanh vấn đề Lưu trữ Ethereum trong lộ trình Ethereum.

Thách thức lưu trữ

Tại sao Nethermind và Besu chọn ngừng lưu trữ dữ liệu lịch sử? Những vấn đề nào nằm dưới quyết định này? Từ quan điểm của tôi, có hai nguyên nhân gốc chính:

• Yêu cầu lưu trữ cho một máy khách Ethereum đang trở nên ngày càng đòi hỏi.
• Không có sự khích lệ hoặc hình phạt trong giao thức để lưu trữ dữ liệu lịch sử của Ethereum.

Lý do đầu tiên xuất phát từ nhu cầu lưu trữ leo thang của việc chạy một Ethereum client. Để đi sâu vào các yêu cầu cụ thể, biểu đồ tròn sau minh họa phân phối chi phí lưu trữ cho một nút Geth mới, tính đến khối 18.779.761 vào ngày 13 tháng 12 năm 2023.

Như hình ảnh cho thấy:

• Yêu cầu lưu trữ tổng cộng: 925.39 GB
• Dữ liệu lịch sử (khối/phí): Khoảng 628,69 GB
• Trạng thái trong Merkle Patricia Trie (MPT): Khoảng 269,74 GB

Lý do thứ hai là sự vắng mặt của các động lực hoặc hình phạt trong giao thức để lưu trữ các khối lịch sử. Trong khi giao thức yêu cầu các nút lưu trữ tất cả dữ liệu lịch sử, nhưng không cung cấp bất kỳ cơ chế nào để khuyến khích việc lưu trữ hoặc trừng phạt việc không tuân thủ. Việc lưu trữ và chia sẻ dữ liệu lịch sử bởi các nút trở nên hoàn toàn lòng nhân ái, và một nút có thể cắt bỏ tất cả dữ liệu lịch sử mà không phải đối mặt với bất kỳ hậu quả tiêu cực nào. Ngược lại, các nhà xác minh, ví dụ, phải duy trì trạng thái đầy đủ mới nhất để tránh đề xuất/bỏ phiếu cho một khối không hợp lệ, rủi ro mất các động lực trong cả hai trường hợp.

Do đó, khi chi phí lưu trữ trở thành gánh nặng đáng kể đối với một nút, không ngạc nhiên khi một số nhà điều hành nút chọn cắt bỏ dữ liệu lịch sử. Việc chọn chạy mà không có dữ liệu lịch sử có thể dẫn đến tiết kiệm chi phí lưu trữ đáng kể, giảm 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 mà không cần lưu trữ các khối lịch sử - tiết kiệm chi phí lưu trữ khoảng ~460GB vào thời điểm hiện tại.

Thách thức về lưu trữ dự kiến sẽ trở nên gay gắt hơn với bản nâng cấp Khả năng Truy Cập Dữ Liệu Ethereum (DA) sắp tới. đườngHướng đến việc mở rộng hoàn toàn Ethereum DA bắt đầu với EIP-4844 tại DenCun, giới thiệu một đối tượng lớn nhị phân cố định (BLOB) đi kèm với một mô hình phí độc lập được biết đến là blobGasPrice. Mỗi BLOB được đặt ở 128KB, và EIP-4844 cho phép mỗi khối chứa tối đa 6 BLOB. Để tăng cường khả năng mở rộng dữ liệu, kế hoạch bao gồm việc triển khai mã Reed-Solomon 1D, cho phép 32 BLOB mỗi khối ban đầu và cuối cùng đạt 256 BLOB mỗi khối khi hoàn toàn mở rộng.

Với Ethereum DA hoạt động ở dung lượng dữ liệu đầy đủ với 256 BLOB mỗi khối, dự kiến mạng Ethereum DA trong một năm sẽ chấp nhận khoảng 80 TB dữ liệu, vượt qua khả năng lưu trữ của hầu hết các nút Ethereum.

Lộ trình lưu trữ Ethereum và Hậu quả

Vitalik’stweetvề lộ trình Ethereum, trong đó Phục dọn chủ yếu xử lý vấn đề lưu trữ.

Chi phí lưu trữ gia tăng đã thu hút sự chú ý từ 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 sự phối hợp trên tất cả các client, hiện đang có một số đề xuất đang được phát triển để cắt giảm lưu trữ một cách rõ ràng. Hai đề xuất chính là:

1. EIP-4444: Dữ liệu Lịch sử Ràng Buộc trong Các Client Thực thi: Đề xuất này cho phép một client cắt tỉa các block lịch sử cũ hơn một năm. Giả sử kích thước trung bình của mỗi block là 100K, dữ liệu block lịch sử sẽ được giới hạn khoảng 250 GB (100K (3600 24 * 365) / 12, given the block time = 12s).
2. EIP-4844: Giao dịch Shard BLOB: EIP-4844 loại bỏ BLOB cũ hơn 18 ngày. Đây là một cách tiếp cận quyết liệt hơn so với EIP-4444, giới hạn kích thước BLOB lịch sử ở khoảng 100 GB ((18360024)128K 6 / 12, cho thời gian khối = 12s).

Hậu quả của việc cắt tỉa dữ liệu lịch sử từ tất cả các khách hàng là gì? Hậu quả chính là một nút mới không thể đồng bộ hóa với trạng thái mới nhất thông qua “đồng bộ hóa đầy đủ” - một đồng bộ hóa để phát lại các giao dịch từ khối khởi tạo đến khối mới nhất. Thay vào đó, chúng ta phải chuyển sang “đồng bộ hóa nhanh” hoặc “đồng bộ hóa trạng thái” để đồng bộ hóa trạng thái mới nhất từ các đồng nghiệp Ethereum. Phương pháp này đã được triển khai trong Geth và chạy như đồng bộ mặc định.

Tương tự, hậu quả này cũng áp dụng cho tất cả các L2, tức là, một nút mới của L2 không thể hoàn toàn phát lại trạng thái mới nhất từ L2 genesis từ Ethereum bằng cách phát lại các khối L2 từ L2 genesis. Hơn nữa, vì các nút L1 không duy trì trạng thái L2, phương pháp “snap sync” cho L2 không thể tạo ra trạng thái L2 mới nhất từ L1 - phá vỡ một giả định quan trọng của L2 về việc kế thừa các cam kết bảo mật của Ethereum. Giải pháp dự kiến sẽ phụ thuộc vào các dịch vụ của bên thứ ba như Infura / Etherscan / các dự án L2 chính họ để lưu trữ một bản sao dữ liệu hoặc trạng thái L2 lịch sử, điều này tập trung với động lực gián tiếp ngoài giao thức.

Các câu hỏi cốt lõi mà chúng tôi đang đặt ra là

• Chúng ta có thể có một giải pháp phi tập trung tốt hơn, cả về lưu trữ và truy cập, cho vấn đề này không?
• Có thể xây dựng một giải pháp tối thiểu về niềm tin phù hợp với Ethereum (ví dụ, trên cơ sở của một hợp đồng L1) với một giải pháp khuyến khích trực tiếp không?
• Với tất cả những điều này, chúng ta có thể mở đường cho một giải pháp khuyến khích trực tiếp trong giao thức để lưu trữ Ethereum và truy cập chúng một cách hoàn toàn phi tập trung theo lộ trình Ethereum?

Giải pháp

Giải pháp 1: Mạng Cổng Ethereum

Mạng lưới Cổng Ethereum phục vụ như một mạng truy cập phân tán nhẹ đến giao thức Ethereum. Cung cấp giao diện JSON-RPC Ethereum như eth_call, eth_getBlockByNumber, nó dịch các yêu cầu JSON-RPC thành các yêu cầu P2P đến một bảng băm phân tán, tương tự như mạng IPFS. Khác với IPFS, cho phép lưu trữ bất kỳ loại dữ liệu nào và dễ bị spam, mạng P2P Cổng chỉ chứa dữ liệu Ethereum, như tiêu đề và thân của lịch sử. Điều này được thực hiện thông qua một kỹ thuật xác minh khách nhẹ tích hợp trong mạng lưới Cổng.

Một đặc điểm quan trọng của mạng Portal là thiết kế để hoạt động nhẹ và tương thích với các thiết bị có tài nguyên hạn chế. Nó có thể chạy trên một nút với vài megabyte bộ nhớ và bộ nhớ thấp, thúc đẩy sự phi tập trung. Ngay cả một điện thoại di động hoặc thiết bị Raspberry Pi cũng có thể tham gia vào mạng và đóng góp vào sự sẵn có của dữ liệu Ethereum.

Sự phát triển của mạng lưới Cổng phù hợp với triết lý đa dạng của khách hàng của Ethereum, với khách hàng được viết bằng Rust, JavaScript, Nim và Go. Mạng lưới đèn báo và mạng lịch sử đã sẵn sàng sử dụng, trong khi mạng lưới trạng thái đang được phát triển mạnh mẽ. Đáng chú ý, mạng lưới Cổng không cung cấp động lực trực tiếp cho việc lưu trữ dữ liệu - tất cả các nút trong mạng lưới hoạt động từ thiện.

Minh họa: Chạy một mạng lưới Cổng (Trin) với giới hạn lưu trữ 100MB.

Giải pháp 2: Mạng Lưu trữ EthStorage

Mạng lưu trữ EthStorage là một mạng lưu trữ khuyến khích phi tập trung, được thiết kế đặc biệt để lưu trữ BLOBs EIP-4844, được hỗ trợ bởi một học bổng từ chương trình ESP.

• Tin cậy tối thiểu: Không giống như những giải pháp hiện có cần một 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$ của các nhà cung cấp lưu trữ EthStorage không cần sự cho phép. Quy trình lưu trữ một BLOB như sau: người dùng ký một giao dịch mang theo BLOB gọi là _put(key, blob_idx)_ phương thức của hợp đồng lưu trữ. Hợp đồng lưu trữ sau đó sẽ ghi lại BLOB hash và thông báo cho các nhà cung cấp lưu trữ bằng sự kiện. Các nhà cung cấp lưu trữ, sau khi nhận được sự kiện, sau đó sẽ tải xuống và lưu trữ BLOB trực tiếp từ mạng Ethereum DA, vượt qua vấn đề cầu nối dữ liệu.
• Cân nhắc Chi phí Lưu trữ với Kích thích: Khi gọiput()phương thức, phí lưu trữ phải được gửi (thông quamsg.value) và được gửi vào hợp đồng. Phí lưu trữ này được phân phối dần dần cho các nhà cung cấp lưu trữ theo thời gian sau khi gửi và xác minh thành công một bằng chứng lưu trữ. So với mô hình phí lưu trữ hiện tại của Ethereum mà trả một lần phí lưu trữ cho 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 chi phí lưu trữ giảm so với ETH theo thời gian. Điều đổi mới đáng kể này do EthStorage giới thiệu làm phì phí mà người dùng trả và đóng góp của nhà cung cấp lưu trữ theo thời gian.
• Chứng minh lưu trữ: Chứng minh lưu trữ được lấy cảm hứng từ việc lấy mẫu dữ liệu có sẵn, trong khi việc lấy mẫu trong EthStorage được thực hiện đối với BLOB theo thời gian thay vì của một block đề xuất. Để xác minh mẫu một cách hiệu quả trên chuỗi, EthStorage sử dụng mạnh mẽ hợp đồng thông minh và các công nghệ SNARK mới nhất.
• Mạng không cần sự cho phép: Bất kỳ nút nào trong EthStorage đều có thể được thanh toán như một nhà cung cấp lưu trữ miễn là nó lưu trữ dữ liệu và định kỳ gửi bằng chứng về việc lưu trữ trên chuỗi.

Từ góc độ tinh chỉnh blockchain, EthStorage hoạt động như một Lớp 2 của Ethereum, nhưng thu các khoản phí lưu trữ thay vì phí giao dịch. Bằng cách lập chỉ mục các BLOB hashes trên chuỗi, EthStorage là một lớp lưu trữ modul Ethereum với khả năng mở rộng lưu trữ đáng kể và tiết kiệm chi phí - mục tiêu khoảng 1000 lần.

Về phát triển, EthStorage đã tích hợp với EIP-4844 trên Ethereum Sepolia testnet. Một bài kiểm tra căng thẳng trên EthStorage và Ethereum Sepolia testnet đã được tiến hành, liên quan đến việc ghi khoảng hàng trăm Gigabyte của BLOBs vào EthStorage. Hơn 50 cộng đồng thành viên đã tham gia vào mạng lưới và chứng minh thành công bộ nhớ lưu trữ cục bộ của họ.

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

Bảng điều khiển của EthStorage trên Ethereum Devnet

Dự đoán Tương lai

Lưu trữ Ethereum, mặc dù ít được chú ý, nhưng rất quan trọng trong hệ sinh thái Ethereum. Khi mạng Ethereum đang trải qua sự phát triển nhanh chóng, việc lưu trữ và truy cập dữ liệu Ethereum trở thành thách thức quan trọng. Trong khi mạng Lối vào và mạng EthStorage đang ở giai đoạn đầu, chúng tôi hình dung một số hướng thú vị cho dài hạn:

• Truy cập Phân quyền thấp đến Trạng thái Ethereum. Truy cập vào trạng thái Ethereum một cách phi tập trung và có thể xác minh là một nhiệm vụ quan trọng nhưng khó khăn. Với cài đặt DHT truyền thống, truy vấn một tài khoản thường đòi hỏi nhiều truy vấn của các nút trie 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 độ trễ lớn đáng kể. Cách sử dụng cấu trúc của cây trạng thái để tăng tốc truy cập là điều chính, như đang được đề cập bởi mạng trạng thái sắp tới của mạng Cổng Ethereum.
• Sự tích hợp giữa Mạng lưới Cổng thông tin và Mạng lưu trữ Eth: Mạng lưới Cổng thông tin có thể mở rộng sự hỗ trợ của mình để bao gồm các BLOB trong mạng lưới, một bước đã được EthStorage thực hiện một phần. Một sự tiến triển tự nhiên sẽ là hợp nhất các mạng lưới này để cung cấp một mạng lưới JSON-RPC phi tập trung có khả năng gọi các hợp đồng với quyền truy cập vào các BLOB. Kết hợp logic ứng dụng trong các hợp đồng và lưu trữ BLOB được mở rộng bởi EthStorage, chúng ta kích hoạt các ứng dụng phi tập trung mới trên Ethereum 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:// được sử dụng để truy cập dữ liệu trong mạng IPFS, có nhu cầu ngày càng tăng về một giao thức truy cập nguyên bản Ethereum từ trình duyệt để mở khóa tiềm năng lớn của dữ liệu phong phú của Ethereum. Dữ liệu này bao gồm một loạt các phổ, từ sở hữu và số dư token đến hình ảnh NFT và trang web phi tập trung động, tất cả đều được thực hiện nhờ vào khả năng của các 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://, như được xác định trong ERC-4804/6860, hiện đang trong quá trình phát triển tích cực để thực hiện mục đích này.
• Chứng thực lưu trữ tiên tiến cho Dữ liệu có Kích thước Động: Vượt qua các BLOB cố định, việc khám phá chứng thực lưu trữ tiên tiến trở nên cấp bách để 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ử hoặc ngay cả các đối tượng trạng thái. Việc phát triển các thuật toán phức tạp có thể nâng cao tính linh hoạt của các giải pháp lưu trữ.

Trong hành trình của chúng tôi, chúng tôi ước ao rằng những nỗ lực này sẽ cùng nhau đóng góp cho lộ trình Ethereum, đặt nền móng cho các giải pháp lưu trữ phi tập trung trong hệ sinh thái Ethereum trong tương lai.

tuyên bố:

1. Bài viết này được tái bản từ [ công nghệ dòng sâu triều]], tiêu đề gốc là “Ethereum Storage Roadmap: Thách thức và Cơ hội”, bản quyền thuộc về tác giả gốc [EthStorage], nếu bạn có bất kỳ ý kiến ​​nào về việc sao chép, vui lòng liên hệ Đội ngũ học tập của Gate , nhóm sẽ xử lý nó càng sớm càng tốt theo các thủ tục liên quan.

2. Chú ý: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân của tác giả và không hình thành bất kỳ lời khuyên đầu tư nào.

3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn, không được đề cập trong Gate.io, bài viết dịch có thể không được sao chép, phân phối hoặc đạo văn.