Blockchain 1 — Tổng quan & định vị trong ngân hàng

Ít công nghệ nào bị thổi phồng và cũng bị hiểu sai nhiều như blockchain. Trong ba năm, nó đi từ "sẽ thay thế toàn bộ ngân hàng" tới "chỉ là trò lừa của giới crypto", rồi lặng lẽ quay lại các phòng thí nghiệm đổi mới của chính các ngân hàng lớn dưới cái tên trung tính hơn: DLT — Distributed Ledger Technology (công nghệ sổ cái phân tán). Với một team dữ liệu ngân hàng, việc hiểu blockchain thực chất là gì — không phải qua tiếp thị, cũng không phải qua định kiến — là điều kiện cần để đánh giá đúng: khi nào nên dùng, khi nào một cơ sở dữ liệu (CSDL) thông thường rẻ và tốt hơn nhiều.

Đây là bài mở đầu series Blockchain & Tài sản số cho ngân hàng. Mục tiêu của bài không phải dạy bạn đầu tư crypto, mà xây một nền trực giác vững: sổ cái phân tán vận hành ra sao, vì sao nó "bất biến", nó đánh đổi những gì, và nó nằm ở đâu trong bức tranh nghiệp vụ ngân hàng. Các bài sau đào sâu mật mã học, đồng thuận, Bitcoin/Ethereum, hợp đồng thông minh, CBDC và phân tích dữ liệu on-chain.

Lưu ý phạm vi & tránh hype: Bài trình bày ở mức nguyên lý. Blockchain KHÔNG phải giải pháp cho mọi bài toán — phần lớn nhu cầu dữ liệu ngân hàng vẫn được phục vụ tốt nhất bởi CSDL quan hệ như PostgreSQL. Mọi ví dụ số trong bài là minh hoạ, không phải cam kết kỹ thuật.

Trực giác: một cuốn sổ được sao chép và đồng bộ

Hãy bắt đầu từ thứ quen thuộc nhất với dân ngân hàng: sổ cái (ledger). Sổ cái là bản ghi tuần tự các giao dịch — ai chuyển cho ai bao nhiêu, khi nào. Toàn bộ ngành ngân hàng dựng trên sổ cái (xem bút toán kép & GL). Trong mô hình truyền thống, mỗi ngân hàng giữ một sổ cái riêng, do chính mình kiểm soát. Khi hai ngân hàng giao dịch với nhau, mỗi bên ghi vào sổ của mình, rồi phải đối soát (reconciliation) để chắc hai sổ khớp nhau — một quy trình tốn kém, chậm, đầy tranh chấp (xem đối soát thanh toán).

Blockchain lật ngược ý tưởng này. Thay vì mỗi bên giữ một sổ riêng rồi đối soát, tất cả các bên cùng chia sẻ MỘT cuốn sổ duy nhất — nhưng cuốn sổ đó không nằm ở một máy chủ trung tâm nào cả. Nó được sao chép (replicated) trên nhiều máy tính độc lập (gọi là node — nút mạng), và có một cơ chế để mọi bản sao luôn nhất trí với nhau về nội dung. Không ai "sở hữu" cuốn sổ. Không ai có thể âm thầm sửa nó. Đó là ý nghĩa cốt lõi của từ distributed ledger: một sổ cái chung, phân tán, đồng bộ.

Sự khác biệt then chốt: ở mô hình tập trung, ai kiểm soát máy chủ thì kiểm soát sự thật — họ có thể sửa, xoá, chèn bản ghi. Ở mô hình phân tán, "sự thật" là thứ mà đa số các nút cùng đồng ý, và để đổi được nó bạn phải thuyết phục (hoặc chiếm quyền) đa số mạng — điều rất khó nếu mạng đủ lớn và phi tập trung.

Cấu trúc: từ block tới chain, và vì sao "bất biến"

Cái tên blockchain mô tả đúng cấu trúc dữ liệu bên trong: một chuỗi (chain) các khối (block) nối tiếp nhau.

Mỗi block gói một tập giao dịch được xác nhận trong một khoảng thời gian, kèm:

• Danh sách giao dịch (transactions) — nội dung chính.
• Timestamp — mốc thời gian tạo khối.
• Hash của chính khối này — một "dấu vân tay" số học, tính từ toàn bộ nội dung khối.
• Hash của khối liền trước (previous hash) — chính chi tiết này biến các khối rời rạc thành một chuỗi liên kết.

Hash là khái niệm mấu chốt phải nắm ngay từ đây (bài Mật mã & đồng thuận sẽ đào sâu). Hàm băm (hash function) nhận vào dữ liệu bất kỳ và trả ra một chuỗi ký tự độ dài cố định. Nó có hai tính chất quyết định: (1) tất định — cùng đầu vào luôn ra cùng kết quả; (2) nhạy cảm tuyệt đối — đổi một bit trong đầu vào thì hash đầu ra đổi hoàn toàn, không thể đoán trước.

Bây giờ đến chỗ đẹp nhất — tính bất biến (immutability). Giả sử kẻ xấu muốn sửa một giao dịch trong Block 1 (chẳng hạn tăng số tiền nhận về). Ngay khi nội dung Block 1 đổi, hash của Block 1 đổi (từ C3D4 thành thứ khác). Nhưng Block 2 đang lưu prevHash = C3D4. Giờ nó không còn khớp — chuỗi bị gãy. Muốn che giấu, kẻ xấu phải tính lại hash Block 2, rồi việc đó lại làm hash Block 2 đổi, buộc phải sửa Block 3, và cứ thế lan tới tận khối cuối cùng. Trong các blockchain có cơ chế đồng thuận tốn kém (như Bitcoin), tính lại toàn bộ chuỗi nhanh hơn phần còn lại của mạng là điều thực tế bất khả thi. Vì vậy sửa lịch sử = phá vỡ chuỗi = bị mạng từ chối.

Đây là điểm phải nhấn mạnh để tránh hiểu lầm: bất biến không có nghĩa "vật lý không thể ghi đè byte". Nó có nghĩa "không thể sửa mà không bị phát hiện và bị mạng bác bỏ". Sổ cái là append-only (chỉ được thêm vào cuối), không sửa, không xoá — và bất kỳ mưu toan sửa nào cũng để lại dấu vết toán học.

Bốn đặc tính cốt lõi và ý nghĩa

Từ cấu trúc trên, blockchain phái sinh ra bốn tính chất thường được nhắc — nhưng phải hiểu đúng sắc thái của từng cái.

Đặc tính	Nghĩa	Ý nghĩa thực tế / cảnh báo
Phi tập trung (decentralized)	Không một bên đơn lẻ kiểm soát sổ cái; dữ liệu và quyền ghi phân tán trên nhiều nút	Loại bỏ điểm lỗi/điểm kiểm soát duy nhất. Nhưng "phi tập trung" là mức độ — mạng riêng của một ngân hàng gần như tập trung
Bất biến (immutable)	Lịch sử append-only, sửa quá khứ sẽ phá chuỗi	Tuyệt cho audit trail, chống chối bỏ. Nhưng nghĩa là sai thì không sửa được — phải ghi giao dịch đảo chiều
Minh bạch (transparent)	Mọi nút thấy cùng một sổ; ai cũng kiểm chứng được	Giảm tranh chấp, đối soát tức thời. Nhưng minh bạch xung đột với bảo mật dữ liệu — vấn đề lớn với ngân hàng
Không cần trung gian tin cậy (trustless)	Các bên không tin nhau vẫn giao dịch được nhờ đồng thuận thay cho bên thứ ba	Bỏ được trung gian (clearing house). Nhưng niềm tin không biến mất — nó dịch sang niềm tin vào giao thức và mã nguồn

Cụm từ đắt giá nhất là trustless. Trong tài chính truyền thống, khi A trả cho B mà hai bên không tin nhau, họ nhờ một trung gian tin cậy đứng giữa: ngân hàng, trung tâm bù trừ (clearing house), SWIFT. Blockchain thay trung gian đó bằng một cơ chế đồng thuận (consensus) — một tập quy tắc toán học và kinh tế để mạng lưới tự thống nhất giao dịch nào hợp lệ, mà không cần ai bảo lãnh. Đây chính là đổi mới sâu nhất, và là chủ đề của bài đồng thuận.

Phân loại: public vs permissioned vs consortium

Đây là phân biệt quan trọng nhất với người làm ngân hàng, vì gần như tất cả ứng dụng ngân hàng nằm ở nhóm permissioned, chứ không phải public.

Public blockchain (mạng công khai) — ví dụ Bitcoin, Ethereum. Bất kỳ ai cũng có thể tải phần mềm, chạy một nút, đọc toàn bộ sổ, gửi giao dịch, và tham gia đồng thuận. Không có người gác cổng. Ưu điểm: phi tập trung thật, chống kiểm duyệt, minh bạch tối đa. Nhược điểm với ngân hàng: chậm (thông lượng thấp), phí biến động, không riêng tư (mọi giao dịch công khai), và không có ai "chịu trách nhiệm pháp lý".

Private / permissioned blockchain (mạng có kiểm soát quyền) — ví dụ Hyperledger Fabric, R3 Corda. Chỉ các bên được cấp phép mới được tham gia (đọc/ghi/đồng thuận). Một tổ chức hoặc một nhóm tổ chức kiểm soát danh sách thành viên. Ưu điểm phù hợp ngân hàng: nhanh hơn nhiều, riêng tư (kiểm soát ai thấy gì), tuân thủ được (biết danh tính các bên → làm KYC/AML được). Nhược điểm: kém phi tập trung — về bản chất gần với một CSDL chia sẻ có kiểm soát chặt.

Consortium blockchain (mạng liên minh) — một biến thể của permissioned, trong đó một nhóm tổ chức ngang hàng (ví dụ nhiều ngân hàng) cùng vận hành mạng, không bên nào độc quyền kiểm soát. Đây là mô hình thực tế nhất cho các bài toán liên ngân hàng: tài trợ thương mại, thanh toán liên hàng, chia sẻ định danh.

Tiêu chí	Public	Permissioned (private)	Consortium
Ai được tham gia	Bất kỳ ai	Được cấp phép, thường 1 tổ chức	Nhóm tổ chức ngang hàng
Mức phi tập trung	Cao	Thấp	Trung bình
Thông lượng / tốc độ	Thấp	Cao	Cao
Riêng tư	Không	Có	Có (kiểm soát theo bên)
Ví dụ	Bitcoin, Ethereum	Hyperledger Fabric	R3 Corda, mạng liên hàng
Phù hợp ngân hàng	Hiếm	Nội bộ	Liên ngân hàng

Khi nào blockchain thực sự hữu ích — và khi nào CSDL thường tốt hơn

Đây là mục quan trọng nhất bài, và là thứ phân biệt người hiểu công nghệ với người chạy theo hype. Câu hỏi không phải "blockchain có xịn không" mà "bài toán này có thực sự cần blockchain không".

Blockchain trả giá đắt: chậm hơn, phức tạp hơn, tốn tài nguyên hơn CSDL quan hệ nhiều lần, vì mọi nút phải lưu và xác minh cùng một dữ liệu. Bạn chỉ nên trả cái giá đó khi đổi lại được thứ CSDL thường không làm được. Hãy dùng bộ câu hỏi lọc sau:

Nói ngắn gọn, blockchain sáng giá khi hội đủ: (1) nhiều bên cùng cần ghi vào một sổ chung; (2) các bên không hoàn toàn tin nhau; (3) không có hoặc không muốn một trung gian trung tâm bảo lãnh; (4) cần một lịch sử chung, bất biến, ai cũng kiểm chứng được. Bài toán liên ngân hàng, đa quốc gia, đa đối tác thường trúng cả bốn.

Ngược lại — và đây là phần hype hay lờ đi — nếu dữ liệu do một tổ chức kiểm soát, các bên tin nhau hoặc đã có trung gian ổn định, hay bạn chỉ cần lưu trữ và truy vấn nhanh, thì CSDL quan hệ gần như luôn thắng: rẻ hơn, nhanh hơn hàng nghìn lần, dễ vận hành, dễ tuyển người, dễ backup/sửa lỗi. Rất nhiều dự án "blockchain hoá" thất bại vì bản chất bài toán chỉ cần một database dùng chung, không cần phi tập trung. Với data team, đây là câu hỏi phản biện đầu tiên khi ai đó đề xuất blockchain: "Vì sao Postgres không đủ?"

Tài sản số & tiền mã hoá — giới thiệu ngắn

Trên nền sổ cái, người ta ghi được nhiều loại "giá trị số":

• Cryptocurrency (tiền mã hoá) — như Bitcoin, Ether: tài sản gốc (native) của một public blockchain, không đại diện cho tài sản ngoài đời, giá do cung cầu.
• Stablecoin — token neo giá vào tài sản ổn định (thường là USD), nhằm giảm biến động; là cầu nối giữa crypto và tiền pháp định.
• CBDC (Central Bank Digital Currency) — tiền pháp định dạng số do ngân hàng trung ương phát hành. Khác hẳn crypto: có chủ quyền, do nhà nước kiểm soát. Chủ đề của bài CBDC & DLT doanh nghiệp.
• Tokenization (token hoá tài sản) — biểu diễn tài sản thật (trái phiếu, bất động sản, vàng, khoản phải thu) dưới dạng token trên sổ cái để giao dịch, chia nhỏ và chuyển nhượng dễ hơn.

Loạt khái niệm này được đào sâu ở bài Bitcoin & Ethereum và bài Smart contract & DeFi.

Định vị trong ngân hàng: sáu mảnh ghép

Với ngân hàng, blockchain không phải "thay thế core banking", mà là công cụ cho một tập bài toán liên tổ chức rất cụ thể. Đây cũng là bản đồ dẫn đường cho phần sau của series:

1. Thanh toán xuyên biên (cross-border payments) — hiện đi qua chuỗi ngân hàng đại lý và SWIFT, chậm (T+1 tới T+3) và tốn phí. DLT hứa hẹn quyết toán gần tức thời giữa các bên. Xem bài thanh toán chuyển tiền.
2. Tài trợ thương mại (trade finance) — L/C, vận đơn, chứng từ vẫn nặng giấy tờ và đối soát thủ công. Sổ cái chung giữa các ngân hàng và bên logistics giảm gian lận, tăng tốc. Xem bài tài trợ thương mại.
3. Đối soát & thanh quyết toán (reconciliation & settlement) — sổ cái chung xoá nhu cầu đối soát hai chiều, vì các bên đã dùng cùng một sổ.
4. CBDC — hạ tầng tiền số của ngân hàng trung ương, nơi ngân hàng thương mại là bên phân phối.
5. Tokenization tài sản — token hoá trái phiếu, tiền gửi, tài sản đảm bảo để giao dịch số.
6. Định danh số (digital identity / KYC dùng chung) — chia sẻ kết quả KYC đã xác thực giữa các định chế, giảm lặp lại (liên quan chặt tới AML/KYC).

Bối cảnh Việt Nam: thận trọng và thí điểm

Ở Việt Nam, hướng tiếp cận của cơ quan quản lý và ngành ngân hàng với blockchain là thận trọng, có kiểm soát, ưu tiên thí điểm (pilot/sandbox) hơn là triển khai đại trà. Một vài nét định hướng để đọc series này đúng ngữ cảnh:

• Tiền mã hoá phi tập trung (Bitcoin...) không phải phương tiện thanh toán hợp pháp — dùng để thanh toán bị cấm. Đây là ranh giới pháp lý cần khắc cốt.
• Nhà nước quan tâm tới cơ chế thử nghiệm có kiểm soát (regulatory sandbox) cho fintech, và nghiên cứu tiền kỹ thuật số của ngân hàng trung ương (CBDC) — nhưng ở giai đoạn nghiên cứu/thí điểm.
• Ứng dụng thực tế đang tập trung vào permissioned/consortium cho tài trợ thương mại, đối soát liên hàng, định danh — chứ không phải mở giao dịch crypto.
• Với data team NCB, hàm ý là: đầu tư vào hiểu bản chất và đánh giá use case, theo dõi khung pháp lý (bài rủi ro & pháp lý), và sẵn sàng tham gia pilot — không chạy theo sản phẩm crypto bán lẻ.

Toàn bộ khung pháp lý ở đây thay đổi nhanh; bài không trích số hiệu văn bản cụ thể — hãy tra cứu quy định hiện hành khi triển khai.

Lộ trình series

Bài	Nội dung
bc-01 (bài này)	Tổng quan, cấu trúc, đặc tính, khi nào nên dùng
bc-02	Mật mã học & cơ chế đồng thuận (PoW/PoS)
bc-03	Bitcoin & Ethereum — hai mô hình nền tảng
bc-04	Hợp đồng thông minh & DeFi
bc-05	DLT doanh nghiệp & CBDC
bc-06	Use case ngân hàng chi tiết
bc-07	Phân tích dữ liệu on-chain
bc-08	Rủi ro & pháp lý

Use case thực tế

Bối cảnh. Một ngân hàng Việt (gọi là Bank V) tham gia một mạng consortium tài trợ thương mại cùng 4 ngân hàng khu vực để số hoá quy trình phát hành L/C (thư tín dụng) cho khách hàng xuất nhập khẩu. Vấn đề trước đó: một chu trình L/C giấy đi qua 4-5 định chế mất trung bình 5-10 ngày, mỗi bên giữ bản sao chứng từ riêng, nhân viên đối soát thủ công, và rủi ro gian lận trùng lặp tài trợ (cùng một lô hàng được đem cầm cố ở hai ngân hàng) khó phát hiện vì mỗi ngân hàng chỉ thấy dữ liệu của mình.

Giải pháp DLT (permissioned/consortium). Năm ngân hàng dùng một sổ cái chung: mỗi bước — mở L/C, xuất trình vận đơn, chấp nhận chứng từ, thanh toán — được ghi thành giao dịch append-only mà cả 5 bên cùng thấy. Vì tất cả dùng một sổ, không còn đối soát hai chiều; vì sổ bất biến, mỗi lô hàng chỉ được tài trợ một lần và mọi bên đều kiểm chứng được.

Kết quả (minh hoạ, không phải cam kết). Chu trình rút xuống còn khoảng 1-2 ngày; số vụ tài trợ trùng lặp về gần 0 do lô hàng được token hoá và không thể cầm cố lần hai mà không để lại dấu vết; chi phí đối soát của bộ phận trade finance giảm rõ rệt.

Vai trò data team. (1) Xây pipeline đẩy sự kiện L/C từ core banking lên node của ngân hàng và ngược lại; (2) đối chiếu dữ liệu on-chain với sổ cái nội bộ để đảm bảo nhất quán; (3) trích dữ liệu on-chain phục vụ báo cáo & giám sát gian lận. Đáng chú ý: dữ liệu on-chain vẫn cần được đưa về data warehouse quan hệ để phân tích — blockchain giỏi ghi tin cậy chung, còn phân tích/BI vẫn là sân của SQL. Đây chính là cầu nối tới bài phân tích on-chain.

Để tương phản: nếu chỉ một ngân hàng số hoá L/C nội bộ của mình, thì không cần blockchain — một database quan hệ với audit log là đủ, rẻ và nhanh hơn. Blockchain chỉ đáng giá vì ở đây có năm bên không hoàn toàn tin nhau cùng ghi chung.

Ghi nhớ

• Blockchain / DLT về bản chất là một cuốn sổ cái được sao chép và đồng bộ trên nhiều nút độc lập, không do một bên duy nhất kiểm soát; "sự thật" là thứ đa số nút đồng ý.
• Cấu trúc: mỗi block chứa giao dịch + timestamp + hash khối này + hash khối trước; chính liên kết hash tạo nên tính bất biến — sửa một khối làm gãy toàn bộ chuỗi phía sau.
• Bất biến nghĩa là không sửa được mà không bị phát hiện, không phải "byte không thể ghi đè". Sổ là append-only: sai thì ghi giao dịch đảo chiều, không xoá.
• Bốn đặc tính: phi tập trung, bất biến, minh bạch, trustless — mỗi cái đều có đánh đổi (minh bạch xung đột bảo mật; trustless không xoá niềm tin mà dời nó sang giao thức).
• Phân loại: public (mở, phi tập trung, chậm, không riêng tư) vs permissioned/private (kiểm soát, nhanh, riêng tư) vs consortium (nhóm tổ chức ngang hàng). Ngân hàng gần như luôn dùng permissioned/consortium.
• Câu hỏi lọc cốt lõi: chỉ dùng blockchain khi nhiều bên không tin nhau cùng cần ghi chung, không có trung gian, cần lịch sử bất biến kiểm chứng được. Còn lại, CSDL thường rẻ và nhanh hơn — luôn hỏi "vì sao Postgres không đủ?".
• Tài sản số: crypto (Bitcoin/Ether), stablecoin, CBDC (do ngân hàng trung ương phát hành, khác hẳn crypto), và tokenization tài sản thật.
• Định vị ngân hàng: thanh toán xuyên biên, tài trợ thương mại, đối soát, CBDC, tokenization, định danh dùng chung. Việt Nam: thận trọng, thí điểm; tiền mã hoá không phải phương tiện thanh toán hợp pháp.