Blockchain 5 — Blockchain doanh nghiệp & CBDC

Bốn bài trước tập trung vào blockchain public — Bitcoin, Ethereum, smart contract, DeFi — nơi bất kỳ ai cũng tham gia được, danh tính ẩn danh, và đồng thuận dựa trên kinh tế (PoW/PoS). Nhưng ngân hàng và doanh nghiệp lớn gần như không dùng blockchain public làm hạ tầng lõi. Lý do đơn giản: một ngân hàng không thể để dữ liệu giao dịch khách hàng công khai cho cả thế giới, không thể chấp nhận đối tác vô danh, và không thể chạy hệ thống tuân thủ trên một mạng mình không kiểm soát.

Vì thế xuất hiện một họ công nghệ khác: blockchain có cấp phép (permissioned / private DLT) — vẫn là sổ cái phân tán, vẫn bất biến và có mật mã, nhưng đóng: chỉ các thành viên được cho phép mới tham gia, danh tính đã biết, dữ liệu riêng tư. Bài này giải thích họ công nghệ đó, ba nền tảng chính (Hyperledger Fabric, R3 Corda, Quorum), rồi bước sang CBDC — tiền kỹ thuật số của ngân hàng trung ương, ứng dụng đình đám nhất của DLT trong ngành ngân hàng.

Nền tảng lý thuyết (băm, chữ ký số, đồng thuận BFT) đã có ở bài mật mã & đồng thuận; nếu chưa nắm khái niệm public vs private ở mức tổng quan, xem bài tổng quan.

1. Permissioned / private DLT — sổ cái có cấp phép

1.1. Đặc điểm cốt lõi

DLT = Distributed Ledger Technology (công nghệ sổ cái phân tán) — khái niệm rộng hơn "blockchain". Một sổ cái có cấp phép (permissioned) khác blockchain public ở những điểm nền tảng sau:

• Thành viên được cấp phép (permissioned). Không phải ai cũng chạy node hay ghi giao dịch. Có một cơ chế cấp phép — chỉ tổ chức được phê duyệt (ngân hàng, cơ quan, doanh nghiệp trong liên minh) mới gia nhập. Public thì ngược lại: mở cho tất cả (permissionless).
• Danh tính đã biết (known identity). Mỗi thành viên có định danh số (chứng thư số / certificate). Đây là điều kiện bắt buộc cho ngân hàng: mọi hành động đều truy được về một pháp nhân cụ thể — nền tảng cho KYC, kiểm toán, tuân thủ.
• Đồng thuận BFT nhanh. Vì số node ít và đã định danh, không cần PoW tốn điện hay PoS. Dùng các thuật toán BFT (Byzantine Fault Tolerant — chịu lỗi Byzantine) như PBFT, Raft, IBFT: đạt tính chung cuộc tức thời (instant finality) — giao dịch được xác nhận là chắc chắn ngay, không cần chờ nhiều confirmation như Bitcoin.
• Riêng tư dữ liệu (privacy). Không "broadcast" mọi thứ cho cả mạng. Dữ liệu chỉ chia sẻ với bên liên quan — điều kiện sống còn cho bí mật ngân hàng và bảo vệ dữ liệu khách hàng.
• Thông lượng cao (high throughput). Vì không tốn công chứng minh và số node nhỏ, đạt hàng nghìn giao dịch/giây — so với ~7 tx/s của Bitcoin hay ~15–30 của Ethereum.

Đánh đổi: giảm phi tập trung (decentralization). Mạng có cấp phép do một liên minh kiểm soát, nên bớt "trustless" (không cần tin ai) hơn public. Nhưng với ngân hàng, tính kiểm soát và tuân thủ quan trọng hơn tính phi tập trung tuyệt đối.

1.2. Public vs permissioned — sơ đồ so sánh

2. Các nền tảng chính

2.1. Hyperledger Fabric

Hyperledger Fabric là nền tảng DLT có cấp phép do Linux Foundation (dự án Hyperledger) dẫn dắt, phổ biến nhất trong doanh nghiệp. Các khái niệm cần nhớ chính xác:

• Channel (kênh). Một mạng Fabric có thể chia thành nhiều channel — mỗi channel là một "sổ cái con" riêng, chỉ các thành viên trong channel đó thấy dữ liệu. Ví dụ: ngân hàng A và B giao dịch trên một channel riêng, C và D trên channel khác — không ai thấy dữ liệu của nhau. Đây là cơ chế riêng tư chủ đạo của Fabric.
• Chaincode. Fabric gọi smart contract là chaincode — chương trình chạy trên sổ cái, viết bằng Go, Java hoặc Node.js (không phải Solidity/EVM).
• MSP (Membership Service Provider — nhà cung cấp dịch vụ thành viên). Thành phần quản lý danh tính: cấp và xác thực chứng thư số cho từng tổ chức và người dùng. MSP chính là thứ biến mạng thành "có cấp phép".
• Endorsement policy (chính sách xác nhận). Quy tắc ai phải ký duyệt một giao dịch trước khi nó được ghi. Ví dụ policy "cần chữ ký của cả ngân hàng A và ngân hàng B" — giao dịch chỉ hợp lệ khi đủ các bên bảo chứng. Đây là điểm khác biệt kiến trúc: Fabric theo mô hình execute–order–validate (thực thi & bảo chứng trước, sắp thứ tự sau), khác với "order–execute" của blockchain thường.

2.2. R3 Corda

R3 Corda được thiết kế riêng cho thị trường tài chính (do liên minh R3 với nhiều ngân hàng lớn xây dựng). Corda không phải blockchain theo nghĩa "chuỗi block broadcast" — đó là khác biệt quan trọng nhất:

• Mô hình UTXO / states. Corda mô hình hoá dữ liệu bằng các state (trạng thái) theo tư duy UTXO (giống Bitcoin): mỗi giao dịch tiêu các state cũ và tạo state mới. Không có "số dư tài khoản" toàn cục.
• Chỉ chia sẻ với bên liên quan — KHÔNG broadcast toàn mạng. Đây là triết lý lõi của Corda: dữ liệu một giao dịch chỉ truyền cho các bên trực tiếp liên quan (và bên cần biết), không phát tán cho toàn mạng như blockchain thường. Riêng tư ở mức tối đa — rất hợp bí mật ngân hàng.
• Notary (công chứng viên). Vì không broadcast, làm sao chống tiêu hai lần (double-spend)? Corda dùng dịch vụ notary: một (nhóm) node được tin cậy để xác nhận rằng các input state chưa bị tiêu, đảm bảo tính duy nhất mà không cần cả mạng đồng thuận.
• Smart contract của Corda gọi là CorDapp, viết bằng Kotlin/Java.

Nói ngắn: Corda hy sinh sự "công khai" để đổi lấy riêng tư tối đa và mô hình pháp lý gần với hợp đồng tài chính thật.

2.3. Quorum / ConsenSys

Quorum (nay thuộc ConsenSys, gọi là ConsenSys Quorum / GoQuorum) là một phiên bản Ethereum có cấp phép (do JPMorgan khởi tạo). Ý tưởng: giữ nguyên hệ sinh thái Ethereum quen thuộc — EVM, Solidity, công cụ — nhưng biến nó thành mạng đóng:

• Chạy EVM và smart contract Solidity như Ethereum → tận dụng lại kỹ năng và thư viện sẵn có.
• Thay PoW/PoS bằng đồng thuận BFT (IBFT/Raft) cho finality nhanh và không tốn điện.
• Thêm cơ chế giao dịch riêng tư (private transactions): dữ liệu chỉ hiển thị với các bên được chỉ định, phần còn lại của mạng chỉ thấy dấu băm.

Quorum là lựa chọn cho tổ chức muốn Ethereum permissioned — quen thuộc, nhiều lập trình viên, dễ tuyển dụng.

2.4. So sánh nhanh ba nền tảng

2.5. Vì sao ngân hàng chọn permissioned

Tổng hợp lại, ngân hàng chọn DLT có cấp phép vì bốn lý do khớp thẳng với yêu cầu ngành:

1. Tuân thủ (compliance). Danh tính đã biết → làm được KYC/AML, kiểm toán, truy vết pháp lý. Public ẩn danh không đáp ứng nổi.
2. Riêng tư (privacy). Channel (Fabric), chia sẻ chọn lọc (Corda), private tx (Quorum) → giữ bí mật ngân hàng và dữ liệu khách hàng — điều public không cho.
3. Kiểm soát (control / governance). Liên minh tự quản trị mạng: quyết định thành viên, nâng cấp, quy tắc — không phụ thuộc một mạng công khai ngoài tầm với.
4. Hiệu năng (performance). Đồng thuận BFT cho finality tức thời và thông lượng cao, đủ cho khối lượng giao dịch liên ngân hàng thực tế.

3. CBDC — tiền kỹ thuật số của ngân hàng trung ương

3.1. Định nghĩa

CBDC = Central Bank Digital Currency — tiền kỹ thuật số của ngân hàng trung ương. Định nghĩa chuẩn: một dạng số hoá của tiền pháp định (fiat), là nghĩa vụ nợ trực tiếp của ngân hàng trung ương (a direct liability of the central bank), tồn tại dưới dạng số.

Phân biệt rạch ròi với những thứ hay bị nhầm:

• Khác tiền mã hoá (crypto như Bitcoin). Bitcoin không do ai phát hành, không ai bảo chứng, giá trị thả nổi, phi tập trung. CBDC do nhà nước phát hành, là tiền pháp định, giá trị ổn định như tiền mặt (1 đồng CBDC = 1 đồng nội tệ).
• Khác stablecoin tư nhân (như USDT, USDC). Stablecoin do công ty tư nhân phát hành, "neo" vào fiat bằng tài sản dự trữ mà họ nắm giữ — rủi ro nằm ở uy tín và dự trữ của công ty đó. CBDC là tiền của chính ngân hàng trung ương — không có rủi ro phát hành tư nhân, là "an toàn nhất" trong các dạng tiền số.

Nói cách khác: tiền mặt là nợ của NHTW ở dạng giấy; CBDC là chính khoản nợ đó ở dạng số.

3.2. Bán buôn (wholesale) vs bán lẻ (retail)

Có hai loại CBDC theo đối tượng dùng:

• Bán buôn: chỉ lưu hành trong hệ thống ngân hàng để quyết toán liên ngân hàng và thanh toán xuyên biên giới — ít gây xáo trộn, nhiều thí điểm tập trung ở đây (xem mBridge, Ubin bên dưới). Liên quan trực tiếp tới thanh toán xuyên biên giới truyền thống qua SWIFT.
• Bán lẻ: dân dùng trực tiếp — tham vọng lớn hơn nhưng cũng nhiều rủi ro chính sách hơn.

3.3. Mô hình hai tầng (two-tier)

Hầu hết thiết kế CBDC bán lẻ theo mô hình hai tầng: ngân hàng trung ương không phục vụ trực tiếp hàng chục triệu người dân (không thể và không nên), mà phát hành CBDC rồi để ngân hàng thương mại phân phối cho công chúng — giữ nguyên vai trò trung gian của ngân hàng thương mại (quan hệ khách hàng, KYC, ví).

Tầng 1 (NHTW ↔ ngân hàng thương mại): phát hành và phân phối. Tầng 2 (ngân hàng thương mại ↔ dân): mở ví, định danh, dịch vụ. Mô hình này giữ ngân hàng thương mại "trong cuộc", giảm rủi ro làm sụp vai trò trung gian.

3.4. Lợi ích & rủi ro

Lợi ích:

• Thanh toán tức thời, 24/7, chi phí thấp — kể cả xuyên biên giới (mạnh nhất ở bản wholesale).
• Tài chính toàn diện (financial inclusion): đưa dịch vụ tiền số tới nhóm chưa có tài khoản ngân hàng.
• Giảm phụ thuộc tiền mặt: hạ chi phí in ấn/vận chuyển/bảo quản tiền mặt; tăng minh bạch dòng tiền, chống trốn thuế/rửa tiền.
• Kênh truyền dẫn chính sách tiền tệ trực tiếp và linh hoạt hơn cho NHTW.

Rủi ro:

• Disintermediation ngân hàng (mất vai trò trung gian). Nếu dân rút tiền gửi khỏi ngân hàng thương mại để giữ CBDC "an toàn tuyệt đối" của NHTW, ngân hàng mất nguồn vốn huy động → giảm khả năng cho vay; nguy cơ bank run khi khủng hoảng. Đây là rủi ro số một, và là lý do có mô hình hai tầng + hạn mức nắm giữ.
• Riêng tư (privacy). CBDC bán lẻ có thể cho nhà nước thấy mọi giao dịch của dân → lo ngại giám sát. Thiết kế phải cân bằng chống rửa tiền với quyền riêng tư.
• Vận hành & an ninh mạng. Hạ tầng tập trung quan trọng → là mục tiêu tấn công; sự cố hệ thống có thể tê liệt thanh toán quốc gia. Đòi hỏi độ tin cậy cực cao.

4. Ví dụ thực tế trên thế giới & Việt Nam

• e-CNY (Trung Quốc) — CBDC bán lẻ lớn nhất đang vận hành, do Ngân hàng Nhân dân Trung Quốc (PBoC) triển khai theo mô hình hai tầng (PBoC phát hành, ngân hàng thương mại phân phối). Đã thí điểm rộng ở nhiều thành phố, tích hợp ví điện tử.
• Project mBridge — dự án CBDC bán buôn xuyên biên giới đa phương, hợp tác giữa các NHTW (gồm Trung Quốc đại lục, Hồng Kông, Thái Lan, UAE...) và BIS Innovation Hub, cho phép quyết toán liên ngân hàng nhiều loại CBDC trên một nền tảng chung — nhắm thẳng vào việc thay thế chuỗi ngân hàng đại lý chậm và đắt của SWIFT.
• Project Ubin (Singapore) — chuỗi thí điểm nhiều giai đoạn của MAS (Singapore) về CBDC bán buôn và quyết toán, dùng cả Corda và Quorum ở các pha khác nhau.
• Project Dunbar — dự án do BIS phối hợp (Singapore, Úc, Malaysia, Nam Phi) thử nền tảng đa CBDC dùng chung cho quyết toán xuyên biên giới — cùng hướng với mBridge.

Bối cảnh Việt Nam: Chính phủ đã giao Ngân hàng Nhà nước (NHNN) nghiên cứu, thí điểm tiền kỹ thuật số dựa trên công nghệ blockchain (theo các quyết định về phát triển kinh tế số / Chính phủ số). Đây mới ở giai đoạn nghiên cứu — thí điểm, chưa phát hành chính thức; song đủ để các ngân hàng thương mại như NCB cần theo dõi và chuẩn bị năng lực.

5. Tokenized deposit & stablecoin ngân hàng

Bên cạnh CBDC còn hai dạng "tiền số của ngân hàng" đáng biết:

• Tokenized deposit (tiền gửi được token hoá). Là tiền gửi ngân hàng thương mại được biểu diễn dưới dạng token trên một sổ cái phân tán. Khác CBDC ở chỗ nó vẫn là nợ của ngân hàng thương mại (không phải của NHTW) — chỉ là hình thức số hoá mới của tiền gửi hiện hữu, cho phép chuyển tức thời và lập trình được, mà không đổi bản chất pháp lý của khoản tiền gửi. Được nhiều ngân hàng xem là bước đi thực tế, ít gây xáo trộn hơn CBDC bán lẻ.
• Stablecoin ngân hàng — JPM Coin. JPM Coin (nay trong nền tảng Kinexys/Onyx của JPMorgan) là token đại diện tiền gửi tại JPMorgan, dùng cho quyết toán bán buôn tức thời giữa các khách hàng tổ chức của ngân hàng — chạy trên nền Quorum (Ethereum permissioned). Về bản chất nó là một dạng tokenized deposit khép trong hệ thống một ngân hàng, không phải stablecoin công cộng như USDT/USDC.

Ba khái niệm — CBDC, tokenized deposit, stablecoin — dễ nhầm; điểm phân biệt then chốt là ai là bên phát hành / chịu nghĩa vụ nợ: NHTW (CBDC), ngân hàng thương mại (tokenized deposit / JPM Coin), hay công ty tư nhân (USDT/USDC).

6. Hàm ý cho ngân hàng thương mại như NCB

• CBDC bán lẻ hai tầng: nếu NHNN phát hành, NCB nhiều khả năng đóng vai nhà phân phối tầng 2 — cung cấp ví, KYC, dịch vụ khách hàng trên nền CBDC. Cần chuẩn bị năng lực tích hợp core banking với sổ cái CBDC.
• Rủi ro disintermediation: theo dõi thiết kế hạn mức nắm giữ CBDC — vì nó ảnh hưởng trực tiếp tới nguồn tiền gửi huy động của NCB.
• DLT liên ngân hàng: các nền tảng permissioned (Fabric/Corda/Quorum) có thể xuất hiện trong quyết toán, tài trợ thương mại, KYC dùng chung — NCB nên hiểu kiến trúc để tham gia liên minh khi có.
• Vai trò cán bộ dữ liệu: hiểu mô hình dữ liệu của DLT (state/UTXO của Corda, world state của Fabric, account của Quorum) để về sau kết nối, đối soát và giám sát dữ liệu giao dịch trên các sổ cái này với dữ liệu core banking.

Các use case ngân hàng cụ thể (thanh toán, tài trợ thương mại, KYC dùng chung) và khung rủi ro — pháp lý sẽ được đào sâu ở các bài tiếp theo của series.

Use case thực tế

Bối cảnh: NCB muốn đánh giá mức độ sẵn sàng cho kịch bản NHNN thí điểm CBDC bán lẻ hai tầng, trong đó NCB là nhà phân phối tầng 2. Đội dữ liệu cần một bức tranh nội bộ: nếu một phần tiền gửi khách hàng chuyển sang CBDC, quy mô ảnh hưởng tới huy động là bao nhiêu.

Bước 1 — Ước lượng tiền gửi có thể dịch chuyển. Trên sandbox nội bộ, ước tính tổng số dư tiền gửi thanh toán (nhóm dễ chuyển sang "tiền mặt số" nhất) theo thành phố, để hình dung mức phơi nhiễm disintermediation:

-- ▶ Chạy được
SELECT c.city,
       COUNT(DISTINCT c.id) AS so_khach,
       SUM(a.balance)       AS tong_so_du
FROM customers c
JOIN accounts a ON a.customer_id = c.id
WHERE a.currency = 'VND'
GROUP BY c.city
ORDER BY tong_so_du DESC;

Bước 2 — Mô hình hoá kịch bản dịch chuyển. Giả sử một tỷ lệ tiền gửi thanh toán chuyển sang ví CBDC (ví dụ khách giữ CBDC như "tiền mặt số"). Đây là ước lượng phân tích, không phải giao dịch CBDC thật (Việt Nam mới ở giai đoạn nghiên cứu):

Giả định kịch bản (minh hoạ, KHÔNG phải số liệu thật):
  Tổng tiền gửi thanh toán:      100 tỷ VND
  Tỷ lệ dịch sang CBDC (est.):   15%
  → Huy động sụt giảm ước tính:  15 tỷ VND
  → Tác động: giảm nguồn cho vay tương ứng
Hàm ý: cần theo dõi hạn mức nắm giữ CBDC do NHTW đặt
       (công cụ chính để hạn chế disintermediation).

Bước 3 — Kết luận. Kết hợp số dư nội bộ (bước 1) với giả định chính sách (bước 2), đội dữ liệu cung cấp cho quản lý rủi ro một ước tính về phơi nhiễm huy động, và khuyến nghị bám sát thiết kế hai tầng + hạn mức nắm giữ — hai cơ chế chính giảm rủi ro disintermediation.

Lưu ý: khối SQL trên chạy được vì chỉ đọc 2 bảng chuẩn; khối text mô hình kịch bản chỉ để minh hoạ, không phải SQL và không chạy được.

Ghi nhớ

• Ngân hàng dùng DLT có cấp phép (permissioned), không phải public: thành viên được duyệt, danh tính đã biết, đồng thuận BFT (finality tức thời), dữ liệu riêng tư, thông lượng cao — đánh đổi bằng giảm phi tập trung.
• Hyperledger Fabric: channel (riêng tư), chaincode, MSP (danh tính), endorsement policy (ai phải ký duyệt).
• R3 Corda: mô hình UTXO/state, notary chống double-spend, chỉ chia sẻ với bên liên quan — không broadcast toàn mạng (riêng tư tối đa, cho tài chính).
• Quorum/ConsenSys: Ethereum permissioned — giữ EVM + Solidity, thêm BFT và private transactions.
• Ngân hàng chọn permissioned vì: tuân thủ, riêng tư, kiểm soát, hiệu năng.
• CBDC = tiền số của NHTW, là nợ của NHTW — khác crypto (không ai phát hành) và khác stablecoin tư nhân (do công ty phát hành).
• Bán buôn (wholesale) = liên ngân hàng/quyết toán; bán lẻ (retail) = dân dùng. Bán lẻ theo mô hình hai tầng: NHTW phát hành, ngân hàng thương mại phân phối.
• Lợi ích CBDC: thanh toán tức thời, tài chính toàn diện, giảm tiền mặt. Rủi ro: disintermediation ngân hàng, riêng tư, vận hành.
• Ví dụ: e-CNY (Trung Quốc, bán lẻ), mBridge & Dunbar (bán buôn xuyên biên giới), Project Ubin (Singapore). Việt Nam: NHNN nghiên cứu — thí điểm tiền kỹ thuật số.
• Tokenized deposit & JPM Coin là nợ của ngân hàng thương mại (không phải NHTW) — phân biệt theo bên phát hành.
• Với NCB: nhiều khả năng là nhà phân phối tầng 2; cần theo dõi hạn mức nắm giữ CBDC vì nó ảnh hưởng huy động vốn.