Tóm tắt

Chào mừng quý độc giả đến với chuỗi “Bi kịch chung của tiền mã hóa” do GCC Research thực hiện.

Chuỗi bài viết này tập trung phân tích các tài sản công blockchain thiết yếu—những nền tảng cốt lõi của hệ sinh thái crypto đang dần rời xa nguyên lý phi tập trung ban đầu. Các tài sản này tạo dựng Web3, nhưng thường phải đối mặt với vấn đề thiếu động lực duy trì, thách thức quản trị và nguy cơ tập trung hóa. Đặc biệt, khoảng cách giữa lý tưởng phi tập trung và năng lực dự phòng vững chắc cần thiết cho sự ổn định thực tế đang ngày càng bị thử thách gay gắt.

Bài viết này nhấn mạnh một ứng dụng nổi bật trong hệ sinh thái Ethereum: Polymarket và các công cụ lập chỉ mục dữ liệu của nền tảng này. Từ đầu năm nay, những tranh cãi liên quan đến thao túng oracle trong dự đoán kết quả bầu cử Trump, cá cược đất hiếm ở Ukraine, hay đặt cược màu áo vest của Zelensky đã nhiều lần đưa Polymarket lên tâm điểm dư luận. Quy mô và sức ảnh hưởng tài chính quá lớn khiến các tranh chấp này không thể làm ngơ.

Vậy liệu thị trường dự đoán phi tập trung hàng đầu này đã thực sự đạt được phi tập trung ở tầng dữ liệu—vốn là yếu tố then chốt? Vì sao hạ tầng phi tập trung như The Graph lại chưa thể đáp ứng kỳ vọng? Một giải pháp lập chỉ mục dữ liệu công cộng hữu dụng và bền vững cần có những đặc điểm nào?

I. Hiệu ứng domino từ sự cố hạ tầng dữ liệu tập trung

Tháng 7/2024, Goldsky—nền tảng dữ liệu blockchain thời gian thực phục vụ các nhà phát triển Web3, cung cấp giải pháp lập chỉ mục, Subgraph và truyền phát dữ liệu—đã bị gián đoạn dịch vụ trong sáu giờ. Sự cố này đã “hạ gục” một phần lớn hệ sinh thái Ethereum: các giao diện DeFi không thể hiện vị thế và số dư của người dùng, những thị trường dự đoán như Polymarket không truy xuất được dữ liệu chính xác, còn từ góc độ người dùng, vô số giao diện dự án bỗng trở nên vô dụng hoàn toàn.

Đây chính là điều mà các ứng dụng phi tập trung hướng tới phòng tránh. Bản chất của blockchain là loại bỏ các điểm thất bại đơn lẻ. Sự cố của Goldsky đã phô bày một thực tế đáng lo ngại: blockchain được thiết kế hướng đến phi tập trung, nhưng phần lớn hạ tầng hỗ trợ ứng dụng on-chain vẫn bị kiểm soát tập trung hóa mạnh.

Gốc rễ vấn đề là lập chỉ mục và truy vấn dữ liệu blockchain vốn là hàng hóa công kỹ thuật số—không loại trừ, không cạnh tranh—người dùng kỳ vọng được sử dụng miễn phí hoặc với chi phí rất thấp. Nhưng duy trì hạ tầng này đòi hỏi đầu tư liên tục vào phần cứng, lưu trữ, băng thông và nguồn lực kỹ thuật. Thiếu mô hình doanh thu bền vững, lĩnh vực này sẽ rơi vào “cuộc chơi một người thắng”: chỉ cần một nhà cung cấp vượt trội về tốc độ và nguồn lực, toàn bộ nhà phát triển sẽ chuyển truy vấn về cho họ, tạo ra một điểm phụ thuộc tập trung mới. Gitcoin cùng nhiều tổ chức phi lợi nhuận đã chỉ ra rằng “hạ tầng nguồn mở mang lại giá trị hàng tỷ đô la, nhưng người sáng tạo lại không thể trả nổi tiền mua nhà.”

Thông điệp rút ra rất rõ: cộng đồng phi tập trung cần hành động quyết liệt—thông qua tài trợ hàng hóa công, tái phân bổ động lực hoặc mô hình do cộng đồng dẫn dắt—để đa dạng hóa hạ tầng Web3 và tránh hình thức tập trung hóa mới. Chúng tôi kêu gọi các nhà phát triển DApp ưu tiên phương pháp “local-first”, đồng thời cộng đồng kỹ thuật nên thiết kế ứng dụng đủ linh hoạt để xử lý lỗi truy xuất dữ liệu—đảm bảo người dùng vẫn sử dụng được kể cả khi hệ thống lập chỉ mục gặp sự cố.

II. Dữ liệu của DApp thực sự có nguồn gốc từ đâu?

Để hiểu những sự kiện như sự cố Goldsky, cần đi sâu vào cơ chế vận hành của DApp. Đa phần người dùng chỉ nhận diện hai thành phần: hợp đồng on-chain và giao diện frontend. Họ quen kiểm tra trạng thái giao dịch qua Etherscan, xem thông tin trên frontend, và thực hiện thao tác với hợp đồng qua UI. Nhưng thực tế, frontend lấy dữ liệu từ đâu?

Vai trò trọng yếu của dịch vụ truy xuất dữ liệu

Giả sử bạn xây dựng một giao thức cho vay cần hiển thị vị thế, biên độ, khoản nợ của người dùng. Nếu frontend truy vấn dữ liệu trực tiếp từ blockchain, hầu hết hợp đồng không hỗ trợ lấy đầy đủ vị thế theo địa chỉ—chỉ có thể truy vấn theo ID vị thế. Muốn hiển thị vị thế của người dùng, phải quét toàn bộ vị thế đang mở rồi lọc ra thông tin cần thiết—cách làm này tương tự mò tìm hàng triệu dòng ghi sổ cái. Kỹ thuật này khả thi nhưng chậm và cực kỳ thiếu hiệu quả. Ngay cả khi thực thi trên máy chủ backend, những dự án DeFi lớn cũng mất hàng giờ để lấy dữ liệu từ node local.

Lúc này, hạ tầng chuyên dụng trở thành yếu tố sống còn. Các nhà cung cấp dịch vụ như Goldsky mang lại giải pháp lập chỉ mục dữ liệu, giúp truy cập cực nhanh. Sơ đồ dưới minh họa các loại dữ liệu mà các dịch vụ này tạo điều kiện cho ứng dụng khai thác.

Nhiều độc giả đặt câu hỏi: Chẳng phải The Graph đã cung cấp truy xuất dữ liệu phi tập trung cho Ethereum? The Graph khác gì Goldsky, và vì sao nhiều dự án DeFi lại chọn Goldsky thay vì The Graph?

Mối quan hệ giữa The Graph, Goldsky và SubGraph

Để làm rõ, cùng điểm lại các khái niệm kỹ thuật cốt lõi:

• SubGraph là framework cho lập trình viên, giúp nhóm kỹ thuật phát triển mã để đọc, tổng hợp dữ liệu on-chain phục vụ frontend.
• The Graph là nền tảng truy xuất dữ liệu phi tập trung hàng đầu, khởi tạo framework SubGraph dùng AssemblyScript. Developer dùng SubGraph để lấy event từ hợp đồng và ghi vào cơ sở dữ liệu, từ đó truy vấn bằng GraphQL hoặc SQL.
• Các nhà cung cấp dịch vụ chạy SubGraph gọi là operator. The Graph và Goldsky đều là đơn vị lưu trữ SubGraph cho dự án, vì code SubGraph buộc phải vận hành trên server. Dẫn chứng từ tài liệu Goldsky:

Tại sao có nhiều operator SubGraph?

Bởi framework chỉ quy định cách trích xuất dữ liệu từ block, ghi vào database—hoàn toàn không xác định cơ chế vận hành hay đầu ra. Mỗi operator tự chủ về thiết kế chi tiết.

Các operator có thể tùy biến node, tối ưu hiệu năng riêng biệt. The Graph hiện tích hợp Firehouse để đẩy nhanh tốc độ lập chỉ mục; runtime SubGraph của Goldsky vẫn chưa mở mã nguồn.

Thực chất, The Graph là một trung tâm phi tập trung cho các operator SubGraph. Chẳng hạn, subgraph Uniswap v3 do nhiều operator cùng duy trì, biến The Graph thành marketplace chung, nơi người dùng gửi code SubGraph để nhiều operator xử lý truy xuất.

Mô hình định giá của Goldsky

Goldsky vận hành theo mô hình SaaS tập trung, tính phí trực tiếp theo tài nguyên sử dụng. Đây là cách mà phần lớn kỹ sư đã quen thuộc. Dưới đây là bảng công cụ tính giá của Goldsky:

Mô hình định giá của The Graph

The Graph sở hữu cơ chế định giá độc đáo: phí truy vấn và các khoản thưởng được tích hợp vào tokenomics GRT. Cấu trúc tổng quan như sau:

• Mỗi truy vấn SubGraph phân bổ phí như sau: 1% GRT bị đốt; 10% về pool curator (thường là developer); khoảng 89% được phân phối cho Indexer và Delegator theo thuật toán.
• Indexer phải stake tối thiểu 100.000 GRT để tham gia, đồng thời bị phạt nếu trả kết quả sai. Delegator stake GRT cùng Indexer để chia sẻ phần thưởng trong pool 89%.
• Curator (thường là developer) signal bằng cách stake GRT trên bonding curve cho SubGraph. Stake nhiều GRT càng thu hút tài nguyên Indexer. Khuyến nghị cộng đồng: cần 5.000–10.000 GRT mới đảm bảo khả năng index ổn định cho SubGraph.

Phí truy vấn:

Để truy vấn The Graph, developer đăng ký API key và nạp trước GRT, phí sẽ tính trên số lần truy vấn.

Phí staking signal:

Để SubGraph được lập chỉ mục, developer cần stake GRT để “signal” giá trị, thu hút operator. Only khi đủ lượng GRT (ví dụ 10.000), Indexer mới nhận SubGraph vào sản xuất thực tế.

Khi thử nghiệm, SubGraph có thể triển khai miễn phí với staging operator của The Graph, nhưng chỉ dùng để test. Khi vận hành chính thức, SubGraph phải được publish lên mạng lưới và Indexer tự lựa chọn index dựa trên signal đã stake.

Vì sao lập trình viên (và kế toán) ngại mô hình trả phí bằng token

Với đại đa số dự án, quy trình của The Graph khá rườm rà. Việc mua GRT với nhóm Web3 rất dễ, nhưng curator lại mất nhiều thời gian và thiếu minh bạch. Cốt lõi vấn đề:

• Sự bất định: Developer không rõ cần stake bao nhiêu GRT và bao lâu thì Indexer nhận SubGraph.
• Khó khăn kế toán: Mô hình trả phí bằng tokenomics gây khó trong kiểm soát chi phí, khiến doanh nghiệp và bộ phận kế toán lúng túng ghi nhận khoản chi.

"Tập trung hóa dễ dàng hơn?"

Với phần lớn developer, Goldsky đơn giản hơn: giá rõ ràng, dịch vụ được cấp ngay khi thanh toán, gần như không có sự bất định. Hậu quả là cộng đồng Web3 ngày càng dựa dẫm quá mức vào một nhà cung cấp lập chỉ mục duy nhất.

Cơ chế tokenomics GRT của The Graph có chủ ý tốt, nhưng mức độ phức tạp khiến developer e ngại và không nên áp đặt lên người dùng cuối—đặc biệt, staking curator nên ẩn sau giao diện thanh toán đơn giản.

Đây không phải chỉ là quan điểm cá nhân: Paul Razvan Berg, kỹ sư hợp đồng thông minh kỳ cựu và nhà sáng lập Sablier, công khai chỉ trích trải nghiệm xuất bản SubGraph và thanh toán GRT là quá tệ.

III. Các giải pháp hiện tại cho sự cố Data Indexer

Hệ sinh thái nên làm gì với điểm thất bại đơn lẻ ở khâu lập chỉ mục dữ liệu? Đúng như đã nêu, developer có thể dùng The Graph nhưng phải chấp nhận stake GRT và curator để trả cho API.

Hệ sinh thái EVM có rất nhiều công cụ lập chỉ mục dữ liệu thay thế. Tham khảo: The State of EVM Indexing (Dune), Tổng quan công cụ Indexing EVM (rindexer), cùng luồng thảo luận gần đây.

Bài viết không đi sâu nguyên nhân kỹ thuật sự cố Goldsky; theo báo cáo sự cố, Goldsky chỉ chia sẻ chi tiết cho khách hàng doanh nghiệp. Báo cáo cho thấy lỗi xảy ra khi ghi dữ liệu đã index vào database, việc truy cập dữ liệu chỉ khôi phục sau khi phối hợp với AWS.

Một số hướng tiếp cận khác:

• ponder: công cụ lập chỉ mục dữ liệu đơn giản, thân thiện, dễ triển khai. Developer có thể tự host trên hạ tầng thuê ngoài.
• local-first: triết lý phát triển đề xuất DApp duy trì khả năng sử dụng ngay cả khi mất kết nối mạng. Với blockchain, nghĩa là người dùng vẫn trải nghiệm trọn vẹn miễn là kết nối được với chain—bất kể indexer có hoạt động hay không.

Ponder: Giải pháp DIY lập chỉ mục dữ liệu

Lý do nên chọn ponder?

• Không bị khóa nhà cung cấp: ban đầu do một developer độc lập xây dựng, ponder chỉ cần endpoint RPC Ethereum và database Postgres—không phụ thuộc dịch vụ quản lý.
• Trải nghiệm developer xuất sắc: được phát triển bằng TypeScript, dùng thư viện Viem, ponder dễ sử dụng (tác giả đã trải nghiệm nhiều).
• Hiệu năng rất tốt.

Hạn chế: ponder cập nhật nhanh, có thể tạo thay đổi lớn làm gián đoạn deployment cũ. Tham khảo chi tiết kỹ thuật và best practice ở tài liệu chính thức.

Đáng chú ý, gần đây ponder bắt đầu thương mại hóa theo lý thuyết “phân tách” đã đề cập ở bài trước.

Tóm tắt: Hàng hóa công phục vụ tất cả, nhưng thu phí sẽ loại trừ nhóm người dùng biên, giảm phúc lợi xã hội (không tối ưu Pareto). Giá phân biệt có thể tối đa hóa thặng dư, nhưng rất khó và tốn chi phí. Lý thuyết phân tách đề xuất chia nhóm đồng nhất, chỉ thu phí nhóm này, còn số đông vẫn miễn phí.

Ứng dụng lý thuyết này vào ponder:

• Triển khai đòi hỏi kỹ năng kỹ thuật—developer cần tự cấu hình endpoint RPC, database.
• Bảo trì thường xuyên (ví dụ: proxy cân bằng tải, đảm bảo truy xuất dữ liệu nội bộ). Có thể là thách thức với vài developer.
• Ponder đã có bản beta tự động hóa triển khai qua Marble: chỉ cần gửi code lên nền tảng để triển khai một lần nhấp.

Cách làm này “phân tách” nhóm khách hàng muốn tiện lợi—họ trả phí để sử dụng giải pháp host của Marble—còn những người tự host vẫn dùng ponder miễn phí.

So sánh ponder và Goldsky:

• Các dự án nhỏ chuộng tool tự host như ponder vì linh hoạt, tự chủ.
• Dự án lớn cần hiệu năng cao lại ưu tiên dịch vụ quản lý như Goldsky vì độ tin cậy và dự phòng tốt.

Cả hai mô hình đều tiềm ẩn rủi ro. Sự cố Goldsky cho thấy mọi developer nên duy trì indexer ponder tự quản lý như phương án dự phòng. Khi dùng ponder, cần xem xét tính xác thực phản hồi RPC—gần đây, safe báo cáo một sự cố do dữ liệu RPC không hợp lệ khiến indexer crash. Chưa có bằng chứng sự cố Goldsky do lỗi RPC, nhưng đó là nguyên nhân tiềm ẩn cần lưu ý.

Paradigm phát triển local-first

Local-first thu hút nhiều tranh luận trong cộng đồng kỹ thuật những năm gần đây. Về bản chất, nó yêu cầu:

• Khả năng sử dụng offline
• Hợp tác đa nền tảng

Phần lớn bàn luận kỹ thuật local-first đều đề cập CRDT (Conflict-free Replicated Data Types)—cấu trúc tự động giải quyết xung đột dữ liệu phân tán. Thực chất, CRDT là giao thức đồng thuận nhẹ giúp duy trì dữ liệu nhất quán trên nhiều thiết bị.

Với phát triển blockchain, ta có thể làm đơn giản hơn: mục tiêu là đảm bảo người dùng duy trì được chức năng tối thiểu khi backend indexer bị gián đoạn, bởi bản thân blockchain đã cung cấp sự đồng nhất đa nền tảng.

DApp local-first thực tế có thể:

• Lưu cache thông tin quan trọng—số dư, vị thế—giúp người dùng luôn thấy trạng thái cuối, ngay cả khi indexer sập.
• Đảm bảo degrade graceful—truy xuất dữ liệu thiết yếu trực tiếp từ RPC khi indexer bị lỗi để người dùng vẫn xem được một phần dữ liệu on-chain thời gian thực.

Cách tiếp cận này giúp ứng dụng tăng khả năng phục hồi vượt trội. Lý tưởng nhất, DApp local-first “chuẩn” sẽ yêu cầu người dùng chạy node local và truy vấn dữ liệu qua công cụ như TrueBlocks. Đọc thêm về các giải pháp lập chỉ mục phi tập trung và local tại Không ai thật sự quan tâm đến frontend và indexer phi tập trung.

IV. Kết luận

Sự cố Goldsky kéo dài sáu giờ đã gióng hồi chuông cảnh báo cho toàn bộ hệ sinh thái Web3. Dù blockchain được thiết kế phi tập trung và khả năng chống chịu cao, tầng ứng dụng của đa số dự án vẫn dựa dẫm vào hạ tầng dữ liệu tập trung—đẩy hệ sinh thái vào nguy cơ rủi ro hệ thống mới.

Bài viết đã phân tích lý do The Graph, dù được đánh giá cao, lại khó mở rộng ứng dụng do cơ chế tokenomics GRT phức tạp và gây khó khăn cho developer. Chúng tôi cũng đưa ra các chiến lược xây dựng lập chỉ mục dữ liệu bền vững hơn—khuyến nghị sử dụng framework tự host như ponder làm phương án dự phòng, cũng như giới thiệu hướng thương mại hóa mới của ponder. Cuối bài, chúng tôi đề cập paradigm local-first, khuyến khích developer đảm bảo DApp vẫn vận hành khi hệ thống indexer gặp sự cố.

Cộng đồng developer Web3 ngày càng ý thức sâu sắc về nguy cơ điểm thất bại đơn lẻ ở tầng lập chỉ mục dữ liệu, coi đó là lỗ hổng nghiêm trọng. GCC khuyến nghị cộng đồng tập trung giải quyết vấn đề hạ tầng cốt lõi này, chủ động thử nghiệm các giải pháp data indexer phi tập trung hoặc thiết kế framework giúp frontend DApp duy trì hoạt động kể cả khi indexer bị gián đoạn.

Khuyến nghị:

1. Bài viết được đăng lại từ TechFlow. Bản quyền thuộc về tác giả shew. Nếu có thắc mắc về việc đăng lại, vui lòng liên hệ đội ngũ Gate Learn để được hỗ trợ.
2. Lưu ý: Quan điểm và ý kiến trong bài viết hoàn toàn là ý kiến cá nhân, không phải khuyến nghị đầu tư.
3. Bản dịch của đội ngũ Gate Learn không được sao chép, phân phối hoặc sử dụng lại nếu không ghi nguồn dẫn rõ ràng Gate.com.