Tiêu đề gốc: "Sử dụng biểu đồ để bảo toàn dữ liệu lịch sử và kích hoạt EIP-4444"

Tác giả gốc: Phần 2, Eray 4, Phòng thí nghiệm ký hiệu học 2 trong số Lichu 3 và Tatu 3, nhà phát triển cốt lõi của The Graph

Bản biên soạn gốc: Luccy, BlockBeats

Ghi chú của biên tập viên:

EIP-4444 đã đề xuất đặt HISTORY_PRUNE_EPOCHS thành 82125 kỷ nguyên (tức là 1 năm trên chuỗi đèn hiệu), để các máy khách lớp Thực thi Ethereum PoS không còn cung cấp tiêu đề khối, nội dung khối và dữ liệu biên nhận cũ hơn một năm trên mạng p2p và khách hàng có thể cắt bớt dữ liệu lịch sử này cục bộ.

Bài đọc liên quan: "Giới thiệu EIP-4444: Giới hạn dữ liệu lịch sử trên các máy khách lớp thực thi》

Biểu đồ là một giao thức lập chỉ mục để truy vấn trên các mạng như Fangfang và IPFS. Bất kỳ ai cũng có thể xây dựng và xuất bản các API mở được gọi là biểu đồ con để làm cho dữ liệu dễ truy cập hơn, thành phần cốt lõi của nó là trình lập chỉ mục.

Người lập chỉ mục cần truy cập vào dữ liệu lịch sử của chuỗi khối để hoàn thành nhiệm vụ của mình và Firehose là một công cụ nguồn mở để trích xuất dữ liệu từ chuỗi khối. Hiện tại, dữ liệu chuỗi khối được nhập từ các nút đầy đủ hỗ trợ Firehose bằng cách thực hiện đồng bộ hóa toàn bộ kho lưu trữ, nhưng sau khi triển khai EIP-4444, trình lập chỉ mục của The Graph sẽ cần điều chỉnh quy trình nhập dữ liệu chuỗi khối của nó.

Trong bài viết này, Semiotic Labs chia sẻ cách họ tận dụng sự phát triển công nghệ trên giao thức The Graph để giải quyết các vấn đề cho cộng đồng rộng lớn hơn. Ban đầu, Semiotic Labs đã phát triển Firehose và Substreams để cải thiện hiệu suất và khả năng xác minh của giao thức The Graph. Công cụ và công nghệ này tình cờ có thể giải quyết được vấn đề EIP-4444 và dựa trên đó, một bộ chỉ mục chuyên dụng sử dụng công nghệ này đã được thành lập. đã được tạo. Đường dẫn chỉ mục mới.

Trong quy trình này, trước tiên Firehose trích xuất dữ liệu từ chuỗi khối và lưu trữ dữ liệu đó trong một tệp phẳng, đồng thời cung cấp giao diện gRPC cho khối. Truyền phát, luồng này có thể được sử dụng bởi nhiều điểm cuối trong Biểu đồ. Trong số đó, các tệp phẳng đóng vai trò là kho lưu trữ Ethereum có thể chia sẻ và chúng chứa tất cả dữ liệu lịch sử cần thiết. Những tài liệu này có thể chia sẻ và kiểm chứng được.

Ngoài ra, bài viết này so sánh các sắc thái cấu trúc và trường hợp sử dụng của định dạng tệp phẳng và định dạng era1/era và lưu ý rằng trong Biểu đồ, định dạng mới người lập chỉ mục Đồng bộ hóa nút lưu trữ đầy đủ phải được thực hiện khi chạy Firehose để trích xuất dữ liệu chuỗi khối lịch sử cần thiết để lập chỉ mục và giải thích cách giải quyết những vấn đề này thông qua các tệp phẳng được chia sẻ, có thể xác minh được với thị trường được khuyến khích của The Graph.

Semiotic Labs là một trong những nhà phát triển cốt lõi của giao thức The Graph. Các tác giả của bài viết này là thành viên của một nhóm đang nỗ lực phát triển và triển khai các cơ chế để xác thực dữ liệu do The Graph cung cấp từ các chuỗi khối chỉ mục khác nhau. Công việc được mô tả trong bài viết này là kết quả của những nỗ lực không ngừng nghỉ của Semiotic Labs. Severiano Sisneros đã xuất bản bài viết này trên Diễn đàn nghiên cứu Ethereum và BlockBeats đã biên soạn văn bản gốc như sau:

Giới thiệu về Biểu đồ

Biểu đồ là một giao thức truy vấn và lập chỉ mục dữ liệu blockchain phi tập trung. Người lập chỉ mục là trung tâm của The Graph, lập chỉ mục lịch sử của blockchain cho các sự kiện cụ thể và làm cho người tiêu dùng có thể truy vấn dữ liệu. Người lập chỉ mục cần quyền truy cập vào dữ liệu lịch sử của blockchain để thực hiện công việc của họ. Trong tương lai, trình lập chỉ mục của The Graph sẽ trích xuất dữ liệu từ chuỗi khối bằng cách sử dụng các nút đầy đủ của chuỗi khối chuỗi khối được thiết kế đặc biệt như một phần của quy trình trích xuất dữ liệu Firehose.

Firehose là một công cụ nguồn mở được tạo bởi StreamingFast, nhà phát triển cốt lõi của The Graph. Firehose cung cấp cách tiếp cận dựa trên tệp phẳng và phát trực tuyến đầu tiên để xử lý dữ liệu blockchain. Semiotic Labs là một nhóm phát triển cốt lõi khác của The Graph, tập trung vào nghiên cứu và phát triển trong lĩnh vực trí tuệ nhân tạo và mật mã.

Hiện tại, dữ liệu chuỗi khối được lấy từ các nút đầy đủ hỗ trợ Firehose bằng cách thực hiện đồng bộ hóa lưu trữ đầy đủ, dựa trên mạng P2P của chuỗi khối. Mạng ngang hàng cung cấp dữ liệu lịch sử hoàn chỉnh. Tuy nhiên, sau khi triển khai EIP-4444, do các nút đầy đủ sẽ không còn cung cấp dữ liệu lịch sử cũ hơn một năm nữa nên những người lập chỉ mục của The Graph sẽ cần điều chỉnh quy trình trích xuất dữ liệu blockchain của họ để đảm bảo họ tiếp tục thu được dữ liệu cần thiết.

Bài viết này sẽ giới thiệu cách The Graph indexer sử dụng Firehose để trích xuất dữ liệu từ blockchain và lưu trữ dữ liệu đó trong các đối tượng được tuần tự hóa protobuf của Google gọi là tệp phẳng trong bộ lưu trữ. Khi Firehose đồng bộ hóa từ khối gốc, các tệp phẳng này sẽ lưu trữ tất cả thông tin cần thiết để lưu trữ lịch sử đầy đủ của dữ liệu trong chuỗi khối (cụ thể là nội dung khối và biên lai). Chúng tôi đề xuất các tệp phẳng này dưới dạng định dạng dữ liệu lưu trữ, tương tự như tệp era và era1, đồng thời trình bày cách xác minh rằng dữ liệu được lưu trữ trong các tệp phẳng thuộc về chuỗi khối có thẩm quyền.

Đối với The Graph, sau khi quá trình triển khai EIP-4444 có hiệu lực, người lập chỉ mục có thể chia sẻ các tệp phẳng này để lấy dữ liệu lịch sử cần thiết cho việc lập chỉ mục và truy vấn. Trong trường hợp của Ethereum, mạng lập chỉ mục được khuyến khích của The Graph cùng nhau đảm bảo việc lưu giữ và sẵn có của dữ liệu lịch sử, cung cấp giải pháp độc lập, phi tập trung và có thể kiểm chứng cho EIP-4444.

Thật thú vị, mục tiêu ban đầu của chúng tôi không phải là thiết kế giải pháp cho EIP-4444. Các công cụ và kỹ thuật được thảo luận ở đây được phát triển để cải thiện hiệu suất và khả năng xác minh của giao thức The Graph. Tuy nhiên, trong quá trình đó, chúng tôi bất ngờ phát hiện ra giải pháp cho EIP-4444. Tầm nhìn của chúng tôi là làm cho giải pháp này cùng tồn tại với các giải pháp EIP-4444 khác, giống như việc triển khai nhiều ứng dụng khách thực thi Ethereum mà không dẫn đến sự phân phối dữ liệu khối không đồng nhất.

Tổng quan về quy trình Graph Firehose

Graph là một giao thức động, đang phát triển được thiết kế để truy cập nhanh các nhu cầu dữ liệu Blockchain . Với mục đích này, một công nghệ mới có tên Firehose và Substreams đã được phát triển và một quy trình lập chỉ mục mới sử dụng công nghệ này đã được tạo riêng cho người lập chỉ mục.

Trong quy trình này, Firehose là bước đầu tiên trong quy trình. Nó trích xuất dữ liệu từ blockchain và lưu trữ nó trong các tệp phẳng (thông tin thêm về điều này trong phần tiếp theo). Tiếp theo, Firehose cung cấp giao diện gRPC để truyền phát các đoạn được lưu trữ trong các tệp phẳng. Trong Biểu đồ, luồng này có thể được sử dụng bởi nhiều điểm cuối. Ví dụ: dịch vụ Dòng con có thể lọc các sự kiện quan tâm cụ thể và thực hiện bất kỳ chuyển đổi được chỉ định nào trên dữ liệu được lọc. Các kết quả được xử lý sẽ được chuyển đến điểm hẹn cuối và cung cấp cho người tiêu dùng.

Hình 1 cung cấp cái nhìn tổng quan về quy trình Firehose và Substreams, minh họa cách dữ liệu được trích xuất từ chuỗi khối, xử lý và cung cấp thông qua các điểm cuối khác nhau. .

Hình 1: Firehose + Dòng con

Trong bối cảnh EIP-4444, chúng tôi đặc biệt tập trung vào việc trích xuất và lưu trữ dữ liệu blockchain thành các tệp phẳng. Chúng tôi quan sát thấy rằng tệp phẳng chứa tất cả dữ liệu cần thiết để lưu giữ lịch sử của chuỗi khối, đồng thời có thể xác minh thông qua các phương tiện kỹ thuật đơn giản xem những dữ liệu này có thực sự được đưa vào lịch sử chuẩn của chuỗi khối hay không. Là một giao thức truy vấn và lập chỉ mục dữ liệu blockchain phi tập trung, The Graph có lợi thế tự nhiên là đảm bảo tính sẵn có trong lịch sử của toàn bộ blockchain.

Các tệp phẳng dưới dạng kho lưu trữ Ethereum có thể chia sẻ

Firehose bằng cách sử dụng các nút đầy đủ chuyên dụng 2 Trích xuất dữ liệu từ chuỗi khối. Ethereum Firehose sử dụng phiên bản cụ thể của quá trình triển khai Geth 1. Cần lưu ý rằng Firehose hỗ trợ nhiều chuỗi, bao gồm cả chuỗi không phải EVM và các nút hoàn chỉnh được sử dụng sẽ khác nhau tùy theo chuỗi. Cụ thể, Firehose đọc dữ liệu từ API theo dõi của nút đầy đủ khi thực hiện đồng bộ hóa toàn bộ kho lưu trữ. Xem Hình 2 để biết mô tả chi tiết về các bước này.

Hình 2: Trích xuất dữ liệu Firehose

Đầu ra của API theo dõi được lưu trữ trong một tệp phẳng. Điều quan trọng cần lưu ý là API theo dõi có thể được định cấu hình khi cần để cung cấp các mức độ xem xét nội bộ thực thi EVM khác nhau. Ví dụ: nó có thể được định cấu hình làm callTracer để theo dõi các khung cuộc gọi được thực hiện trong quá trình giao dịch (bao gồm các cuộc gọi giao dịch cấp cao nhất và các cuộc gọi trong giao dịch) hoặc API theo dõi có thể được định cấu hình làm trình ghi cấu trúc/mã opcode để theo dõi từng bước của việc thực hiện giao dịch. Mã opcode và ngữ cảnh thực thi được xuất ra ở định dạng . Để xác thực khả năng tồn tại của các tệp phẳng Firehose dưới dạng kho lưu trữ lịch sử Ethereum, chúng tôi đã tập trung vào việc giữ lại các cuộc gọi và biên nhận giao dịch cấp cao nhất, vì đây là những dữ liệu được cam kết và có thể được xác minh trong chuỗi khối. Trong trường hợp này, Firehose lưu trữ tất cả dữ liệu giao dịch (thân khối) và biên lai liên quan đến việc thực hiện giao dịch trong chuỗi khối.

Mặc dù các tệp phẳng Firehose không được thiết kế đặc biệt để xuất dữ liệu lưu trữ Ethereum lịch sử nhưng chúng chứa tất cả dữ liệu lịch sử cần thiết. Những tệp này có thể chia sẻ được và có thể kiểm chứng được, như chúng ta đã thấy, điều này khiến chúng trở thành ứng cử viên sáng giá cho các định dạng lưu trữ.

Tệp phẳng có thể xác minh

Tệp phẳng lưu trữ tất cả dữ liệu giao dịch cấp cao nhất (nội dung khối) và các khoản thu liên quan đến việc thực hiện giao dịch. Ví dụ: Hình 3 cho thấy một tệp phẳng 15 triệu khối (ở định dạng JSON) được giải mã bằng bộ giải mã tệp phẳng của Semiotic. Chúng ta có thể thấy thông tin tiêu đề khối được lưu trữ cũng như dấu vết giao dịch của giao dịch cấp cao nhất, như được hiển thị bên dưới trong giao dịch 0x7ecdee...e3222. Dữ liệu chuỗi khối Ethereum được trích xuất qua Firehose được lưu trữ trong các tệp phẳng theo lược đồ này.

Hình 3: Từ mặt phẳng Dữ liệu blockchain được giải mã cho khối 15.000.000 của tệp

Tệp phẳng lưu trữ tất cả thông tin cần thiết để xây dựng lại cây giao dịch và biên nhận Merkle. Những cây Merkle này được dành riêng cho mọi khối của chuỗi khối chuẩn. Để xác minh rằng dữ liệu này thuộc về chuỗi khối chuẩn, chúng tôi chỉ cần đảm bảo rằng gốc của cây Merkle được xây dựng lại khớp với gốc được lưu trữ trong tiêu đề khối chuẩn. Sau khi hợp nhất, chúng tôi có thể tận dụng thông tin được cung cấp bởi lớp đồng thuận. Ví dụ: Ethereum cung cấp một giao thức con của ủy ban đồng bộ hóa để xác thực các tiêu đề khối từ các chuỗi khối chuẩn. Để xác minh rằng dữ liệu được lưu trữ trong tệp phẳng được hợp nhất là chính xác, chúng tôi chỉ cần xây dựng lại cây Merkle nhận và giao dịch cho các khối trong tệp phẳng, sau đó so sánh các gốc này với các tiêu đề khối hợp lệ được ủy ban đồng bộ hóa ký. Chúng tôi có thể nhận được các tiêu đề khối hợp lệ từ ứng dụng khách đồng thuận.

Để biết ví dụ về cách triển khai điều này, hãy xem mã chứng minh khái niệm của chúng tôi. Theo điểm chuẩn của chúng tôi, quá trình nhập dữ liệu và xây dựng cây Merkle của một khối mất khoảng 5 mili giây trên máy Mac M1.

Chúng tôi cần hoàn thành nhiều công việc hơn trước khi sáp nhập. May mắn thay, chúng tôi không đơn độc. Cộng đồng Ethereum đang tìm kiếm giải pháp cho vấn đề này. Cụ thể, mạng cổng thông tin sử dụng Bộ tích lũy tiêu đề để xác minh rằng các tiêu đề khối được bao gồm trong chuỗi chuẩn. Điều đáng chú ý là các bộ tích lũy này độc lập với định dạng lưu trữ dữ liệu lưu trữ, vì vậy chúng ta có thể nhất quán với phương pháp này và tính toán các giá trị Bộ tích lũy Tiêu đề giống nhau từ dữ liệu được lưu trữ trong các tệp phẳng. Khi người lập chỉ mục chia sẻ các tệp phẳng chứa các khối hợp nhất trước, họ cũng cần cung cấp chứng thực cho các tiêu đề khối chứa biên lai và gốc của cây Merkle giao dịch.

Tệp phẳng, tệp Era

Dữ liệu lưu trữ được đề xuất cho tệp phẳng Firehose của The Graph Định dạng và cơ chế xác thực tương thích với các phương pháp định dạng dữ liệu hiện có, chẳng hạn như định dạng dữ liệu era/era1 được mô tả ở đây. Điểm khác biệt chính là dữ liệu blockchain được lưu trữ. Cụ thể, định dạng tệp thời đại yêu cầu mỗi tệp thời đại chứa ảnh chụp nhanh trạng thái chuỗi Beacon để có thể lấy dữ liệu trạng thái khi quá trình xử lý chuỗi bắt đầu từ tệp đó. Tuy nhiên, các tệp phẳng Firehose cố tình không chứa bất kỳ dữ liệu trạng thái chuỗi Beacon nào, vì mục đích của chúng chỉ đơn giản là lưu trữ tập trung dữ liệu giao dịch lịch sử và biên lai cho lớp thực thi.

Vì các tệp phẳng Firehose không được thiết kế để khởi động các nút Ethereum thực tế nên việc giữ lại dữ liệu trạng thái nằm ngoài phạm vi của nó. Sản phẩm Graph chủ yếu tập trung vào việc lập chỉ mục dữ liệu sự kiện để truy vấn, thay vì thực thi trạng thái các nút Ethereum.

Bảng 1 so sánh các sắc thái cấu trúc và trường hợp sử dụng của định dạng tệp phẳng và định dạng era1/era.

Bảng 1: Tệp phẳng So sánh với các thuộc tính Era1

Thúc đẩy khả năng tìm kiếm của các tệp phẳng

Như chúng ta có thể thấy Có, trong Với Graph, những người lập chỉ mục mới phải thực hiện đồng bộ hóa nút lưu trữ đầy đủ khi chạy Firehose để trích xuất dữ liệu chuỗi khối lịch sử cần thiết cho việc lập chỉ mục. Quá trình này đưa ra hai thách thức mà chúng tôi sẽ giải thích cách giải quyết thông qua các tệp phẳng được chia sẻ, có thể xác minh được với thị trường được khuyến khích của The Graph.

Thử thách 1: Việc thực hiện đồng bộ hóa toàn bộ kho lưu trữ có thể mất nhiều thời gian tùy thuộc vào hệ thống tệp và phần cứng của bộ chỉ mục. Tại Semiotic Labs, việc đồng bộ hóa nút Firehose (Geth + Firehose) mất khoảng hai tháng.

Giải pháp 1: Nếu tệp phẳng bị hỏng trong quá trình đồng bộ hóa (như chúng tôi đã gặp phải hai tháng sau đó), bạn có thể giải quyết bằng cách tải xuống từ một tệp phẳng của người lập chỉ mục khác và hướng dẫn Firehose sử dụng chúng để hoàn tất việc đồng bộ hóa Firehose. Bằng cách sử dụng các công cụ được đề cập ở trên, người lập chỉ mục có thể xác minh rằng các tệp phẳng được tải xuống từ các đồng nghiệp thuộc về chuỗi khối chuẩn. Thay vì thực hiện đồng bộ hóa toàn bộ kho lưu trữ, người lập chỉ mục sẽ khởi tạo Firehose bằng cách sử dụng một tệp phẳng được tải xuống từ thiết bị ngang hàng và được xác minh dựa trên chuỗi khối chuẩn. Nút thắt trở thành tốc độ tải xuống, chẳng hạn như việc tải xuống toàn bộ kho lưu trữ ~ 2TB từ Genesis mất nhiều ngày thay vì hàng tháng cần thiết để đồng bộ hóa toàn bộ kho lưu trữ.

Thử thách 2: Sau khi EIP-4444 có hiệu lực, cần có cơ chế để lưu giữ dữ liệu lịch sử.

Giải pháp 2: Chúng tôi lưu ý rằng các tệp phẳng có thể được chia sẻ và xác minh, vì vậy những người lập chỉ mục có thể tạo ra một thị trường được khuyến khích để chia sẻ các tệp phẳng. Người tiêu dùng của The Graph chỉ định các sự kiện và phạm vi lịch sử mong muốn mà không cần biết trước phạm vi lịch sử này. Người ta hy vọng rằng những người lập chỉ mục trong tương lai sẽ đảm bảo rằng họ có dữ liệu cho toàn bộ lịch sử blockchain. Hiện có những nỗ lực đang được tiến hành trong hệ sinh thái The Graph nhằm thiết lập thị trường này dưới dạng dịch vụ dữ liệu, một "dịch vụ dữ liệu chia sẻ tệp phẳng" do The Graph cung cấp. Về EIP-4444, chúng tôi đã trả lời hai câu hỏi: "Ai sẽ lưu trữ dữ liệu?" và "Dữ liệu sẽ được cung cấp như thế nào?". Trình lập chỉ mục của Đồ thị sẽ lưu trữ dữ liệu lịch sử dưới dạng tệp phẳng và dữ liệu sẽ được cung cấp thông qua đồ thị con/dòng con trong giao thức Đồ thị và dịch vụ dữ liệu chia sẻ tệp phẳng hiện đang được phát triển.

Kết luận

Định dạng tệp phẳng được tạo bởi Firehose của The Graph là sau khi triển khai EIP- 4444 Bảo tồn dữ liệu lịch sử Ethereum cung cấp giải pháp phi tập trung và có thể kiểm chứng. Chúng tôi đã chứng minh rằng tệp phẳng này chứa tất cả dữ liệu blockchain cần thiết và có thể được xác minh dựa trên chuỗi chuẩn.

Chúng tôi đang nỗ lực cải thiện mã xác thực tệp phẳng nguồn mở của mình để mã này có thể được sử dụng để xác thực các tệp phẳng đã tải xuống. Chúng tôi dự đoán rằng những người lập chỉ mục trong giao thức The Graph sẽ tận dụng mã này để phân phối và kiếm tiền từ các tệp phẳng trên thị trường dịch vụ dữ liệu, thay vì đồng bộ hóa các nút đầy đủ thông qua mạng p2p của Ethereum.

Mạng Graph hỗ trợ và khuyến khích giải pháp EIP-4444 độc đáo một cách tự nhiên. Đặc biệt, các tệp phẳng được người lập chỉ mục tạo và sử dụng cũng đóng vai trò là định dạng lưu trữ có thể chia sẻ và có thể kiểm chứng. Chúng tôi đã chứng minh rằng tệp phẳng này chứa tất cả dữ liệu blockchain cần thiết và có thể được xác minh, đồng thời cung cấp mã chứng minh khái niệm. Cách tiếp cận được đề xuất của chúng tôi phù hợp với những nỗ lực hiện có như bộ tích lũy tiêu đề của Portal Network và định dạng tệp era/era1, cung cấp giải pháp bổ sung tập trung vào dữ liệu lớp thực thi có thể cùng tồn tại với các giải pháp EIP-4444 khác mà không gây ra sự phân phối dữ liệu khối không đồng nhất . Chúng tôi đang nỗ lực cải thiện các công cụ xác minh nguồn mở của mình để những người lập chỉ mục có thể dễ dàng xác minh các tệp phẳng đã tải xuống. Trong tương lai gần, The Graph sẽ ra mắt dịch vụ dữ liệu chia sẻ tệp p2p phẳng cung cấp phương pháp thay thế để lấy dữ liệu lịch sử.

Giải pháp tệp phẳng phi tập trung, có thể kiểm chứng này không yêu cầu thay đổi cấp độ giao thức và có thể giúp các giao thức như The Graph tồn tại trong EIP-4444. Sau đó, hoạt động bình thường vẫn tiếp tục. Chúng tôi cung cấp phương pháp này như một cách hữu hiệu để bảo tồn lịch sử của Ethereum vì lợi ích của toàn bộ hệ sinh thái.

Kêu gọi hành động

Phản hồi: Trong bài viết này, chúng tôi sẽ chia sẻ cách tận dụng The Công nghệ giao thức đồ thị được phát triển để giải quyết các vấn đề cho cộng đồng rộng lớn hơn. Chúng tôi rất muốn nghe phản hồi của bạn, vì vậy nếu bạn có bất kỳ câu hỏi, đề xuất nào, v.v., vui lòng liên hệ với chúng tôi.

Khả năng truy cập và phân phối tệp phẳng: Đối với các tệp phẳng do Firehose tạo (được tạo từ các nút hỗ trợ Firehose được đồng bộ hóa từ Genesis), chúng tôi bao gồm việc lưu giữ toàn bộ khu vực. Tự tin xác nhận tất cả thông tin bạn cần biết về lịch sử của blockchain. Dữ liệu trong các tệp phẳng này có thể được xác minh thông qua cơ chế được mô tả ở trên. Vậy làm thế nào để bạn quản lý việc phân phối các tệp phẳng và đảm bảo rằng dữ liệu lịch sử có thể được truy xuất dễ dàng? Chúng tôi đã đưa ra hai lập luận để thúc đẩy việc phân phối và truy xuất: một là người lập chỉ mục sẽ duy trì dữ liệu lịch sử hoàn chỉnh để cung cấp hỗ trợ tối đa cho các đồ thị con/dòng con trong tương lai. Giao thức Graph; Dịch vụ chia sẻ dữ liệu tệp sẽ đảm bảo một thị trường khuyến khích người lập chỉ mục bán thứ này dữ liệu.

Tích hợp chức năng Firehose vào các nút đầy đủ: Một trong những dự án chúng tôi hiện đang thực hiện là tích hợp Firehose vào các nút đầy đủ. Như đã trình bày trong trường hợp sử dụng tính năng lập chỉ mục hiệu suất cao trong The Graph, Firehose cung cấp một cách mới để tương tác với dữ liệu chuỗi khối. Như bài viết này cho thấy, các tệp phẳng do Firehose xuất ra cũng có thể đóng vai trò là định dạng lưu trữ có thể chia sẻ và kiểm chứng được đối với dữ liệu chuỗi khối lịch sử. Đây là sự xác nhận thêm rằng việc có Firehose làm tính năng nút đầy đủ sẽ mở ra các khía cạnh tiện ích mới cho các nhà khai thác nút đầy đủ. Điều đáng chú ý là Firehose hỗ trợ nhiều chuỗi và danh sách này ngày càng tăng lên, cung cấp giao diện chung cho mỗi chuỗi.

Đọc tài liệu tham khảo:

1.EIP-4444: Dữ liệu lịch sử bị ràng buộc trong các ứng dụng khách thực thi 1;

2.Ví dụ về tệp phẳng;

3.Các tệp thời đại mẫu;

4.Truyền dữ liệu nhanh Firehose lưu trữ;

5.Đặc tả tệp kỷ nguyên ;

6.Đăng nhập ERA - tệp lưu trữ dữ liệu khối và dữ liệu đồng thuận；

7.Mạng đồ thị ở độ sâu 2;

8.https://ethereum-magicians.org/t/ eip-7542-eth-69-available-blocks-extends-protocol/;

9.https://substreams.streamingfast.io/;

　Liên kết gốc"

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia