Tại sao Web3 lại không thể đọc được — ForkLog

# Tại sao Web3 không đọc được

Vài năm trước, ngành này tranh luận về cách tăng thông lượng của các blockchain. Ngày nay, nhiều mạng lưới đã có thể xử lý hàng chục nghìn giao dịch, và một số dự án còn tuyên bố con số lên tới hàng trăm nghìn. Tuy nhiên, hóa ra việc ghi dữ liệu vào blockchain mới chỉ là một nửa nhiệm vụ. Phần còn lại là phải tìm, lập chỉ mục, kiểm tra và chuyển dữ liệu đến cho các ứng dụng.

Vì tốc độ tạo dữ liệu ở nhiều nơi đã vượt quá năng lực xử lý của hạ tầng, nên blockchain sẽ thay đổi ra sao — ForkLog đã phân tích.

Càng nhanh thì càng lâu

Khoảng mười năm trước, sự phát triển của các blockchain được mô tả thông qua cái gọi là bộ ba bất khả thi (trilemma) về khả năng mở rộng. Theo khái niệm này, các mạng buộc phải thỏa hiệp giữa bảo mật, phi tập trung và hiệu suất. Nhưng đến năm 2026, điều trở nên rõ ràng là ngay cả khi vấn đề về thông lượng được giải quyết một phần, lại xuất hiện một thách thức mới.

Bản thân blockchain không có giao diện người dùng. Các ứng dụng sẽ đảm nhiệm vai trò đó. Và chúng đến lượt mình cần liên tục nhận dữ liệu:

• số dư của các địa chỉ;
• lịch sử giao dịch;
• trạng thái của các smart contract;
• sự kiện và log;
• phân tích thị trường;
• dữ liệu cho quản lý rủi ro;
• tin nhắn liên chuỗi.

Mạng hoạt động càng nhanh thì càng cần xử lý nhiều dữ liệu như vậy.

Trong cộng đồng người dùng tồn tại một quan niệm sai lầm phổ biến: nếu thông tin được ghi vào blockchain thì nghĩa là chỉ cần lấy ra là xong. Trên thực tế thì ngược lại hoàn toàn. Việc đọc trực tiếp “dữ liệu thô” từ blockchain theo thời gian thực là một quá trình chậm, tốn kém và phức tạp về mặt kỹ thuật. Trong hệ sinh thái Web3, một lớp hạ tầng trung gian kết nối ví với các ứng dụng dapp đã trở nên phổ biến.

Ví dụ, để ứng dụng ví hiển thị số dư của người dùng chỉ trong một phần giây, ứng dụng sẽ truy vấn tới các nhà cung cấp RPC, các trình lập chỉ mục (indexers), các nền tảng phân tích, máy chủ cache, các cơ sở dữ liệu chuyên biệt, v.v.

Quy trình được vận hành như sau:

1. Thu thập dữ liệu: Các chương trình đặc biệt liên tục “đọc” blockchain khi các block mới xuất hiện.
2. Lập chỉ mục (cấu trúc hóa): Chúng phân tích (parser) dữ liệu này và sắp xếp vào các cơ sở dữ liệu truyền thống, hoạt động rất nhanh (ví dụ PostgreSQL hoặc ClickHouse). Ở đó dữ liệu được cấu trúc theo dạng dễ dùng: “Địa chỉ — Danh sách tất cả token của nó”.
3. Phản hồi tức thì: Ví nhận được câu trả lời đã sẵn sàng và đã được lọc từ cache chỉ trong vài mili giây.

Trên thực tế, phần lớn các ứng dụng Web3 phổ biến đều hoạt động thông qua một lớp xử lý dữ liệu bổ sung. Hãy hình dung nếu blockchain xử lý 50 000 giao dịch mỗi giây và hàng triệu ví đồng thời gửi các yêu cầu RPC để cập nhật màn hình. Các máy chủ của nhà cung cấp không chịu nổi tải đó. Việc đọc, lập chỉ mục và sắp xếp dữ liệu cho người dùng là một bài toán tính toán phức tạp bậc nhất. Các indexer và dịch vụ truy cập dữ liệu thường bị tụt lại so với trạng thái hiện tại của mạng vài block, vì việc xử lý, cấu trúc và chuyển giao dữ liệu cần thêm thời gian. Và vấn đề không chỉ ở “hạ tầng lỗi thời” — dù điều đó cũng có. Mà là ở xung đột sâu sắc giữa kiến trúc Web2 và Web3.

Người dùng và ứng dụng tương tác với blockchain với mức độ thường xuyên và chủ động giống như cách họ lướt web quen thuộc với thời gian phản hồi tức thì. Khi bạn cuộn bảng tin mạng xã hội, ứng dụng thực hiện hàng nghìn yêu cầu mỗi giây tới máy chủ để cập nhật lượt thích, bình luận và hình ảnh. Các bot giao dịch trong Web2 có thể thăm dò máy chủ sàn giao dịch hàng triệu lần mỗi phút. Máy chủ của Google hoặc Amazon dễ dàng chịu được điều đó vì chúng tập trung: dữ liệu được “đặt” trong một cơ sở dữ liệu khổng lồ, từ đó có thể sao chép gần như tức thì sang hàng nghìn máy chủ dạng mirror ở khắp nơi trên thế giới.

Blockchain hoạt động khác đi, và về mặt phần cứng nó không “sẵn sàng” cho điều tương tự. Trước đây, trở ngại chính đối với tốc độ trong blockchain là toán học và mật mã. Cần khiến hàng nghìn máy tính trên khắp thế giới nhanh chóng đạt được sự đồng thuận (consensus) rằng một giao dịch là đúng. Các nhà phát triển đã giải quyết vấn đề bằng cách “dạy” máy thực thi song song và tách biệt consensus và execution. Ví dụ Solana, Monad và Aptos hỗ trợ thực thi song song các giao dịch độc lập, khác với mô hình tuần tự cổ điển của Ethereum. Với Monad, việc tách biệt giữa thống nhất thứ tự giao dịch và quá trình thực thi sau đó đặc biệt rõ ràng, trong khi ở Solana và Aptos, tính song song được hiện thực thông qua kiến trúc runtime và cơ chế quản lý xung đột theo trạng thái.

Kết quả là có thể chấp thuận hàng chục nghìn giao dịch mỗi giây (TPS). Nhưng “cái bẫy” nằm ở đây.

Về mặt lịch sử, blockchain thực hiện đồng thời bốn chức năng:

• thực thi giao dịch;
• đồng thuận (consensus);
• lưu trữ dữ liệu;
• cung cấp quyền truy cập dữ liệu.

Khi hiệu suất tăng lên, tải sẽ tăng đồng thời cho cả bốn chức năng này. Hệ thống bắt đầu tạo dữ liệu nhanh hơn hạ tầng có thể đọc chúng, hình thành cái gọi là indexer gap.

Trong tài liệu của Helius — một trong các nhà cung cấp hạ tầng lớn nhất của hệ sinh thái Solana — đã nêu thẳng rằng cấu trúc tuần tự của blockchain phù hợp tốt để đảm bảo toàn vẹn dữ liệu và thông lượng cao, nhưng lại khiến các truy vấn lịch sử trở nên chậm và kém hiệu quả. Vì vậy, phần lớn các công ty buộc phải xây indexer riêng và các cơ sở dữ liệu riêng nằm trên lớp blockchain.

Các nhà phân tích của ChainScore Labs gọi indexer gap là một trong những vấn đề then chốt của hệ sinh thái Solana. Theo đánh giá của họ, các cách tiếp cận lập chỉ mục truyền thống hoạt động không hiệu quả với kiến trúc mạng, nơi tần suất tạo block cao và việc thực thi giao dịch song song tạo ra một luồng dữ liệu khổng lồ.

Từ đó xuất hiện hiệu ứng như sau: mạng có thể xác nhận các thao tác gần như ngay lập tức, nhưng các ứng dụng lại cần nhiều thời gian hơn đáng kể để xử lý hậu quả của các thao tác đó.

Tốc độ Web3 vướng vào vật lý tầm thường (và không chỉ)

Nói chính xác hơn là vướng vào thông lượng của bộ xử lý, ổ đĩa cứng và cáp mạng. Hóa ra khả năng mở rộng của blockchain không đồng nghĩa với khả năng mở rộng của hạ tầng bao quanh nó. Và cần phải xử lý chuyện này càng sớm càng tốt.

Hãy tưởng tượng một mạng có 100 000 TPS. Không chỉ cần ghi giao dịch, mà còn phải:

• lưu giữ trạng thái;
• cập nhật các chỉ mục;
• trả lời các truy vấn của ví;
• phục vụ bot;
• phục vụ nhà phân tích;
• phục vụ công cụ tìm kiếm;
• phục vụ các tác nhân AI.

Do đó, thông lượng cao tạo ra sự cạnh tranh giành tài nguyên giữa lớp consensus, lớp thực thi giao dịch và các dịch vụ hạ tầng nằm trên mạng.

Việc một số công nghệ tham gia phát triển song song buộc phải giải quyết vấn đề này ngay bây giờ. Với con người, độ trễ tính bằng giây hoặc thậm chí là vài phút có thể chấp nhận được. Nhưng với các tác nhân AI, hệ thống giao dịch và các dịch vụ tự động thì không. Nếu một máy ra quyết định dựa trên dữ liệu on-chain, thì thông tin đã lỗi thời đồng nghĩa với sai lầm, mất cơ hội hoặc thua lỗ tài chính trực tiếp.

Trong khi đó, Ethereum Foundation trong tài liệu cập nhật năm 2026 chỉ ra rằng các node lưu trữ (archival nodes) cần từ 3 đến 12 TB dung lượng đĩa, và quá trình đồng bộ ban đầu có thể mất tới một tháng ngay cả trên thiết bị đủ mạnh. Các yếu tố giới hạn nằm ở tốc độ SSD, dung lượng bộ nhớ và hiệu năng bộ xử lý.

Hơn nữa, các nhà phát triển Geth cũng mô tả riêng mô hình lưu trữ cũ, trong đó kích thước cơ sở dữ liệu của Ethereum có thể vượt 20 TB và việc đồng bộ mất hàng tháng. Chính vì vậy mà cần tạo kiến trúc lưu trữ mới theo dạng path-based.

Nói cách khác, đúng là “phần cứng”, bộ xử lý, thông lượng mạng, CPU là những giới hạn vật lý thực sự trong cuộc đua tăng trưởng lượng thông tin. Nhưng đó chưa phải là tất cả. Các máy chủ hiện đại đã có thể xử lý khối lượng dữ liệu khổng lồ. Vấn đề còn lại là: hàng nghìn người tham gia độc lập phải trả bao nhiêu cho điều đó?

Ví dụ, nếu để tham gia đầy đủ vào hệ sinh thái cần hàng chục TB SSD, hàng trăm GB RAM, các kênh liên lạc đắt tiền thì số lượng nhà vận hành hạ tầng chắc chắn sẽ giảm. Và như vậy hình thành sự tập trung hóa mới.

Về mặt hình thức, có thể xử lý dữ liệu, nhưng không thể làm vừa rẻ vừa phi tập trung cùng một lúc. Chi phí xử lý dữ liệu bắt đầu tăng nhanh hơn chi phí bản thân các giao dịch.

Thị trường đã phản ứng ra sao

Những người tham gia cuộc đua đã hiểu rằng bên chiến thắng sẽ là các mạng có thể biến giao dịch thành thông tin truy cập được nhanh hơn, rẻ hơn và đáng tin cậy hơn. Và trong năm nay, thị trường một cách bất ngờ đã chuyển trọng tâm sang hướng đi tới các blockchain dạng mô-đun.

Nếu thế hệ mạng đầu tiên cố gắng thực hiện mọi nhiệm vụ cùng lúc, thì thế hệ mới phân chia trách nhiệm giữa các lớp chuyên biệt. Thay vì chỉ có một mạng, giờ xuất hiện các lớp riêng:

• execution layer — lớp thực thi (hoặc thực hiện);
• settlement layer — lớp thanh toán (xử lý quyết toán);
• consensus layer — lớp đồng thuận (consensus);
• data availability layer — lớp sẵn sàng dữ liệu.

Các nhà phát triển so sánh quá trình này với sự tiến hóa của các trung tâm dữ liệu. Trước đây, một máy chủ đảm nhiệm tất cả chức năng cùng lúc. Ngày nay, tính toán, lưu trữ dữ liệu và các dịch vụ mạng có thể được mở rộng độc lập với nhau.

Một trong những mảng tăng trưởng nhanh nhất trên thị trường là các mạng DA. Nhìn qua thì ý tưởng có vẻ kỳ lạ: tại sao lại tạo một blockchain riêng để lưu tạm dữ liệu của một blockchain khác? Nhưng chính xác là điều đó đang xảy ra. Trong kiến trúc mô-đun, việc thực thi giao dịch và lưu trữ dữ liệu có thể tồn tại tách biệt. Rollup đăng dữ liệu lên một lớp DA bên ngoài, thay vì lên mạng chính. Điều này giúp giảm đáng kể chi phí mở rộng và tăng thông lượng.

Vài năm trước, RPC từng được coi là một chi tiết kỹ thuật. Ngày nay, nó là một trong những thành phần quan trọng nhất của hạ tầng crypto. Tháng 5 năm 2026, Triton One cùng với Solana Foundation đã phát hành thông báo cập nhật về RPC 2.0 — một cách tiếp cận mới để xây dựng kiến trúc đọc dữ liệu trong mạng.

Ý tưởng cốt lõi của nó nằm ở việc tách biệt quyền truy cập vào trạng thái hiện tại của mạng và lịch sử của mạng. Để làm điều đó, người ta đưa vào hai mô-đun độc lập: một mô-đun lập chỉ mục trạng thái của tài khoản theo thời gian thực, mô-đun thứ hai tối ưu hóa cho việc làm việc với dữ liệu lịch sử. Thay vì quét toàn bộ blockchain, hệ thống tạo các index thích nghi cho từng loại truy vấn cụ thể của ứng dụng, nhờ đó giảm độ trễ và chi phí xử lý.

Như vậy Triton và Solana đang cố gắng loại bỏ một loạt giới hạn mang tính hệ thống: kiến trúc RPC nguyên khối vừa đắt đỏ vừa kém hiệu quả; tập tiêu chuẩn hẹp của các truy vấn JSON-RPC; và sự phụ thuộc của nhà phát triển vào các giải pháp do họ tự xây hoặc độc quyền để làm việc với dữ liệu. Trong mô hình mới, việc đọc được mở rộng độc lập với consensus, còn việc truy cập lịch sử trở nên nhanh hơn nhờ sử dụng kho lưu trữ dạng cột (columnar storage) và dữ liệu đã được sắp trước.

Dự án dựa trên các công cụ đã được triển khai trong hệ sinh thái — bao gồm stream dữ liệu từ các validator (Geyser, Yellowstone gRPC) và các giải pháp xử lý lịch sử. Toàn bộ hạ tầng được phát hành dưới mã nguồn mở, và quá trình phát triển được phối hợp với sự tham gia của Solana Foundation.

Kết quả là Solana thực chất đang cố gắng chuyển từ “RPC vạn năng” sang hạ tầng dữ liệu mô-đun và chuyên biệt, vốn được cho là sẽ giảm rào cản cho nhà phát triển và biến việc làm việc với dữ liệu blockchain trở nên thuận tiện tương đương với các cơ sở dữ liệu truyền thống.

Mô-đun có giải quyết được vấn đề không?

Nếu Solana có thể chuẩn hóa lớp đọc, điều này có thể củng cố vị thế của họ như một mạng có hạ tầng ứng dụng phát triển, chứ không chỉ có thông lượng cao. Nhưng đồng thời, nó lại làm tăng cạnh tranh với các nhà cung cấp RPC độc lập và các nền tảng hạ tầng, những bên này sẽ phải hoặc thích nghi theo tiêu chuẩn mới hoặc cung cấp thêm dịch vụ nằm trên tiêu chuẩn đó.

Kiến trúc mô-đun loại bỏ một phần các ràng buộc hạ tầng, nhưng lại chuyển các ràng buộc này sang các lớp khác trong hệ thống. Việc muốn giảm chi phí và đơn giản hóa việc truy cập dữ liệu — thứ không thể thiếu để vận hành DeFi, NFT, ví, phân tích và công cụ tuân thủ (compliance) — là điều dễ hiểu. Tuy nhiên, có vẻ như chính bản chất của Web3 đã “cài sẵn” hiệu ứng dây chuyền phức tạp dần: giải quyết một bài toán chắc chắn sẽ tạo ra các thách thức mới.

Sơ đồ mới chắc chắn sẽ cần một lớp hạ tầng “phụ trợ” phức tạp hơn: với indexer, kho lưu trữ, cache, các pipeline riêng và các điểm lỗi mới. Thay vì một lớp RPC đơn giản duy nhất, hệ sinh thái có thể nhận được nhiều triển khai song song, những tối ưu hóa không tương thích và sự phụ thuộc hơn nữa vào các nhà cung cấp hạ tầng. Trong trường hợp đó, theo hình thức, kiến trúc mở không nhất thiết đồng nghĩa với mô hình truy cập thực sự mở và thuận tiện cho tất cả mọi người.

Hiện tại, chúng ta đang ở giai đoạn mà thị trường chuyển từ cạnh tranh về ai lấy dữ liệu từ mạng tốt hơn sang cuộc đua ai là người đầu tiên tạo ra sản phẩm dựa trên những dữ liệu đó. Ai và trả bao nhiêu cho việc này — có lẽ chúng ta sẽ sớm biết trong thời gian gần đây