Blockchain 7 — Phân tích dữ liệu on-chain

Sáu bài trước của series nhìn blockchain từ góc công nghệ và sản phẩm: tổng quan, mật mã & đồng thuận, Bitcoin & Ethereum, smart contract & DeFi, enterprise & CBDC, use case ngân hàng. Bài này đổi hẳn góc nhìn: xem blockchain như một nguồn dữ liệu (data source) — cụ thể là một cơ sở dữ liệu công khai, bất biến, khổng lồ mà bất kỳ ai cũng đọc được.

Đây là bài dành cho data engineer / data analyst. Câu hỏi trọng tâm không phải "blockchain hoạt động thế nào" mà là: dữ liệu on-chain gồm những gì, lấy nó ra sao, mô hình hoá và phân tích thế nào, và tại sao một ngân hàng như NCB cần quan tâm — nhất là khi khách hàng của ngân hàng ngày càng dính líu tới tài sản số và ta phải giám sát dòng tiền để tuân thủ AML.

Dữ liệu on-chain gồm những gì

"On-chain" là mọi dữ liệu được ghi vĩnh viễn vào sổ cái (đã đào sâu ở bài Bitcoin & Ethereum). Với Ethereum và các chuỗi tương thích EVM (mô hình phổ biến nhất cho phân tích), dữ liệu phân thành mấy tầng:

Mấy điểm cần nắm:

• Transaction có from/to là địa chỉ 20 byte (không phải tên người), value tính bằng wei (1 ETH = 10¹⁸ wei), và trường input chứa lời gọi hàm đã mã hoá.
• Token transfer (ERC-20 / ERC-721) không phải là transaction riêng. Chúng là event Transfer do smart contract token phát ra. Muốn dựng "ai chuyển bao nhiêu USDT cho ai", bạn phải đọc log và giải mã, chứ không nhìn trường value của transaction (trường đó chỉ là ETH gốc).
• State khác với transaction: transaction là dòng sự kiện (flow), state là ảnh chụp số dư tại một thời điểm (stock). Muốn số dư lịch sử tại block cũ, cần archive node.

Bốn đặc thù khiến dữ liệu on-chain "khó nhằn"

1. Công khai (public): ai cũng đọc được toàn bộ lịch sử, miễn phí. Đây vừa là mỏ vàng dữ liệu, vừa là lý do vấn đề quyền riêng tư (privacy & compliance) rất khác với dữ liệu nội bộ ngân hàng.
2. Bất biến (immutable): dữ liệu chỉ append, không sửa/xoá. Không có "UPDATE", không có soft-delete. Rất tốt cho audit, nhưng nghĩa là mọi sai sót trong hợp đồng đều nằm đó vĩnh viễn.
3. Bút danh (pseudonymous), KHÔNG ẩn danh: địa chỉ không gắn tên thật, nhưng mọi giao dịch của một địa chỉ đều công khai và liên kết được. Chỉ cần một điểm neo (nạp/rút qua sàn có KYC, địa chỉ công bố công khai) là có thể lần ra danh tính. Đây là nền tảng của toàn bộ forensics on-chain.
4. Phi cấu trúc, cần giải mã (decode): log và trường input là hex thô. Muốn hiểu, phải có ABI (Application Binary Interface — bản mô tả hàm & event của hợp đồng) để decode. Ví dụ, event Transfer được nhận diện bằng topics[0] = hash của chữ ký Transfer(address,address,uint256); topics[1]/topics[2] là địa chỉ from/to đã đệm 32 byte; data chứa số lượng. Không có ABI → chỉ thấy hex vô nghĩa.

Cách lấy dữ liệu on-chain

Có một phổ lựa chọn, từ "tự vận hành hạ tầng" tới "truy vấn SQL trên dữ liệu đã dọn sẵn". Chọn cái nào tuỳ vào độ trễ, độ sâu lịch sử, chi phí và năng lực đội ngũ.

Tầng thấp: JSON-RPC

Node phơi ra JSON-RPC — giao thức chuẩn để query blockchain. Vài phương thức cốt lõi mà data engineer sẽ gọi nhiều:

• eth_getBlockByNumber — lấy block và các transaction trong đó.
• eth_getTransactionReceipt — lấy status + logs của một transaction.
• eth_getLogs — quan trọng nhất cho analytics: lọc log theo address (hợp đồng), topics (loại event) và khoảng block. Đây là cách chuẩn để thu mọi Transfer của một token.
• eth_getBalance, eth_call — đọc state (số dư, kết quả gọi hàm view).

Một pipeline ingest điển hình sẽ lặp theo block, gọi các phương thức trên, rồi decode bằng ABI. Vì eth_getLogs có giới hạn khoảng block, thực tế phải chia nhỏ và xử lý reorg (block cuối chuỗi có thể bị thay thế) — thường bằng cách chỉ coi block là "final" sau vài chục xác nhận.

Tầng cao: dữ liệu đã dọn sẵn

Với đa số bài toán analytics, không nên tự chạy node. Hai lựa chọn rất mạnh:

• Google BigQuery public crypto datasets: Google duy trì bộ dữ liệu công khai đã decode cho Bitcoin, Ethereum và nhiều chuỗi (bảng blocks, transactions, logs, token_transfers...). Bạn viết SQL chuẩn để phân tích ngay, không phải vận hành hạ tầng — cực hợp với đội đã quen BigQuery (xem BigQuery — tổng quan). Chỉ trả tiền theo lượng dữ liệu quét.
• Dune Analytics: nền tảng cho phép viết SQL trên dữ liệu on-chain đã được index và chia sẻ dashboard công khai. Rất nhanh để thăm dò và làm báo cáo, nhưng bạn không kiểm soát pipeline gốc.

Lưu ý sandbox: Các câu SQL BigQuery/Dune dưới đây là minh hoạ phương ngữ khác và bảng khác (không phải Postgres sandbox của Knowledge Base), nên không được đánh dấu ▶ Chạy được.

Ví dụ minh hoạ — đếm số lần chuyển của một token trên BigQuery (chỉ minh hoạ, không chạy trong sandbox):

-- Minh hoạ BigQuery public dataset — KHÔNG chạy trong sandbox
SELECT
  DATE(block_timestamp) AS day,
  COUNT(*)              AS transfers,
  COUNT(DISTINCT from_address) AS senders
FROM `bigquery-public-data.crypto_ethereum.token_transfers`
WHERE token_address = LOWER('0x...usdt_contract...')
  AND block_timestamp >= TIMESTAMP('2026-01-01')
GROUP BY day
ORDER BY day;

• The Graph / subgraph: khi bạn quan tâm dữ liệu của một giao thức cụ thể (một DEX, một lending protocol), viết một subgraph để index các event thành entity, rồi query bằng GraphQL. Đây là "ORM cho on-chain" theo domain hợp đồng.

Mô hình hoá & phân tích

Sau khi có dữ liệu, ba nhóm bài toán phân tích phổ biến:

1. Đồ thị giao dịch (address graph)

Mô hình tự nhiên nhất cho on-chain là đồ thị có hướng: node là địa chỉ, cạnh là transfer (có trọng số = value, thời gian = timestamp). Từ đồ thị này:

• Gán nhãn ví (labeling): đánh dấu địa chỉ đã biết — ví nạp/rút của sàn (Binance, ...), hợp đồng DeFi, ví mixer (dịch vụ trộn coin che vết như Tornado Cash), ví thuộc danh sách sanction. Nhãn biến hex vô danh thành thực thể có nghĩa.
• Truy vết dòng tiền (transaction tracing / flow tracing): từ một địa chỉ nghi vấn, lần theo cạnh ra/vào để trả lời "tiền này từ đâu tới, chảy đi đâu, qua bao nhiêu hop trước khi tới một sàn có KYC". Đây là kỹ thuật lõi của điều tra.

2. Phân cụm địa chỉ (clustering)

Một thực thể (một người/sàn) thường dùng nhiều địa chỉ. Các heuristic giúp gom chúng lại:

• Common-input heuristic (Bitcoin): nếu nhiều địa chỉ cùng làm input cho một transaction, chúng thường do một chủ thể kiểm soát (vì cần chữ ký của tất cả).
• Change-address heuristic, tái sử dụng địa chỉ, mẫu thời gian, quan hệ nạp/rút với sàn... Đây là heuristic có xác suất, không tuyệt đối, nên phải cẩn trọng khi ra kết luận pháp lý.

3. Chỉ số on-chain & DeFi analytics

Ở tầng tổng hợp, on-chain cho ra các metric không có ở dữ liệu truyền thống:

• Active addresses: số địa chỉ hoạt động theo ngày — proxy cho mức sử dụng thực.
• TVL (Total Value Locked): tổng tài sản khoá trong một giao thức DeFi — thước đo quy mô.
• Volume, giá, thanh khoản trên các DEX/AMM (đã bàn ở smart contract & DeFi).

Việc thiết kế và trình bày các metric này theo nguyên tắc metric/KPI không khác gì analytics thường — điểm khác nằm ở nguồn và cách decode.

AML & forensics on-chain — vì sao ngân hàng phải quan tâm

Đây là phần quan trọng nhất với NCB. Ngân hàng không kinh doanh crypto, nhưng khách hàng của ngân hàng thì có giao dịch tài sản số. Khi một khoản tiền pháp định (VND/USD) chảy vào tài khoản ngân hàng từ việc bán crypto, nghĩa vụ AML (tổng quan AML, giám sát giao dịch) buộc ngân hàng phải hiểu nguồn gốc của dòng tiền đó — mà nguồn gốc nằm on-chain.

Bút danh không chống được điều tra. Vì mọi lịch sử là công khai và bất biến, một khi neo được địa chỉ vào danh tính (qua sàn KYC), toàn bộ hành vi quá khứ lộ ra. Đây là lý do forensics on-chain hiệu quả một cách đáng ngạc nhiên.

Công cụ chuyên dụng

Ngân hàng hầu như không tự dựng toàn bộ; họ mua năng lực gán nhãn & chấm điểm rủi ro từ các hãng chuyên biệt:

• Chainalysis, Elliptic, TRM Labs — cung cấp cơ sở dữ liệu nhãn khổng lồ (ví sàn, mixer, darknet, scam, sanction) và API screening: đưa vào một địa chỉ, trả về điểm rủi ro và exposure (địa chỉ này có bao nhiêu % liên hệ với nguồn bất hợp pháp).

Sàng lọc ví rủi ro

Khi khách khai địa chỉ ví hoặc khi phát hiện qua đối tác, ngân hàng sàng lọc ví đó tương tự sàng lọc sanction với tên người:

• Ví có nằm trong danh sách sanction (ví dụ OFAC công bố cả địa chỉ ví)?
• Ví có exposure trực tiếp/gián tiếp tới mixer, darknet market, sàn không tuân thủ?
• Mức độ "cách" mấy hop tới nguồn bẩn.

Travel Rule

Travel Rule (khuyến nghị của FATF) yêu cầu các VASP (Virtual Asset Service Provider — sàn, ví lưu ký) khi chuyển tài sản số vượt ngưỡng phải truyền kèm thông tin định danh người gửi/nhận, giống nguyên tắc trong chuyển tiền quốc tế SWIFT. Ngân hàng có mảng dịch vụ tài sản số phải hiểu và tích hợp yêu cầu này.

Kiến trúc pipeline dữ liệu on-chain

Về mặt data engineering, pipeline on-chain giống một pipeline ETL warehouse thông thường, chỉ khác ở tầng nguồn và bước decode:

So với dữ liệu ngân hàng truyền thống (core banking, sổ giao dịch):

Off-chain gap là hạn chế cốt lõi: rất nhiều hoạt động không ghi on-chain — giao dịch nội bộ trên sổ của sàn tập trung, thoả thuận OTC, chuyển đổi fiat. On-chain chỉ thấy phần "nổi"; khi tiền vào sàn tập trung, dấu vết on-chain thường đứt (vì sàn gộp tài khoản khách vào ví chung). Vì vậy forensics on-chain mạnh nhất khi kết hợp dữ liệu off-chain (yêu cầu KYC từ sàn, dữ liệu ngân hàng).

Use case thực tế

Bối cảnh: Bộ phận tuân thủ NCB nhận cảnh báo: khách hàng X nhận 3 khoản chuyển vào tài khoản trong 10 ngày, tổng 1,8 tỷ VND, ghi chú "bán tài sản số". Khách khai đây là tiền bán crypto qua một sàn, và cung cấp địa chỉ ví nạp sàn. Nhiệm vụ: đánh giá rủi ro nguồn tiền trước khi giải phóng cảnh báo.

Các bước xử lý:

1. Sàng lọc ví: đưa địa chỉ ví khách khai vào API screening (Chainalysis/Elliptic). Kết quả: exposure direct 0% tới nguồn bẩn, nhưng indirect 18% qua 2 hop tới một mixer — đủ để nâng mức rà soát.
2. Truy vết dòng tiền: dựng đồ thị 3 hop từ ví khách. Phát hiện phần lớn số dư đến từ một ví trung gian nhận tiền từ mixer — khớp mẫu ở sơ đồ truy vết phía trên.
3. Đối chiếu on-chain ↔ off-chain: thời điểm & số lượng token khớp với 3 lần rút từ sàn; quy đổi ra VND (theo tỷ giá tại thời điểm giao dịch) khớp 1,8 tỷ nhận trên tài khoản ngân hàng.
4. Giám sát nội bộ: song song, chạy giám sát trên sổ giao dịch của ngân hàng để phát hiện mẫu structuring (chia nhỏ). Ví dụ truy vấn tổng hợp trên sandbox — đúng vai trò "phân tích sổ giao dịch" nội bộ:

-- ▶ Chạy được
SELECT kind,
       COUNT(*)                    AS so_giao_dich,
       ROUND(SUM(amount)::numeric, 2) AS tong_tien,
       ROUND(AVG(amount)::numeric, 2) AS trung_binh
FROM transactions
GROUP BY kind
ORDER BY tong_tien DESC;

5. Kết luận: có exposure gián tiếp tới mixer → nâng khách lên EDD (Enhanced Due Diligence), yêu cầu chứng từ nguồn tiền bổ sung, và cân nhắc lập báo cáo giao dịch đáng ngờ. On-chain cho bằng chứng bất biến; sổ ngân hàng cho định danh; kết hợp hai bên mới ra kết luận.

Giá trị: on-chain analytics biến câu trả lời "khách nói vậy" thành bằng chứng kiểm chứng được — điều đặc biệt quan trọng khi ngân hàng ngày càng phục vụ khách có tài sản số.

Ghi nhớ

• Blockchain là một data source công khai, bất biến, khổng lồ. Dữ liệu on-chain gồm: block, transaction (from/to/value/gas), event/log của smart contract, token transfer (ERC-20/721 — đọc từ log, không phải trường value), và state (số dư tại block).
• Bốn đặc thù: công khai, bất biến, bút danh (không ẩn danh), và phi cấu trúc cần decode bằng ABI (log/input là hex thô).
• Phổ cách lấy dữ liệu: full/archive node + JSON-RPC (eth_getLogs...) → node-as-a-service (Infura/Alchemy) → explorer API (Etherscan) → datasets sẵn (BigQuery public crypto, Dune SQL) → indexer (The Graph/subgraph). Đa số analytics nên dùng dữ liệu đã dọn sẵn.
• Phân tích lõi: đồ thị giao dịch + gán nhãn ví → truy vết dòng tiền → phân cụm địa chỉ (heuristic, có xác suất) → chỉ số on-chain (active address, TVL, volume).
• AML/forensics on-chain rất quan trọng với ngân hàng: dùng Chainalysis/Elliptic/TRM để screening ví (sanction/mixer/darknet), tuân thủ Travel Rule (FATF, VASP). Ngân hàng phục vụ khách crypto phải giám sát nguồn tiền.
• Pipeline on-chain ≈ ETL warehouse thông thường, thêm bước decode ABI và enrich nhãn/điểm rủi ro. So với dữ liệu ngân hàng: công khai vs nội bộ, bút danh vs có tên, bất biến vs sửa được.
• Hạn chế: bút danh không phải ẩn danh (neo được là lộ) và off-chain gap (nhiều hoạt động không lên chuỗi; dấu vết đứt tại sàn tập trung) — mạnh nhất khi kết hợp on-chain và off-chain.
• Các câu SQL BigQuery/Dune là minh hoạ (phương ngữ & bảng khác) → không chạy trong sandbox; chỉ truy vấn Postgres trên transactions mới là ▶ Chạy được.