Blockchain 2 — Mật mã & Cơ chế đồng thuận

Bài tổng quan blockchain mô tả blockchain như một sổ cái phân tán, bất biến, không cần trung gian tin cậy. Nhưng "bất biến" và "không cần tin cậy" không phải phép màu — chúng đến từ hai trụ cột kỹ thuật cụ thể: mật mã học (cryptography) khoá dữ liệu lại bằng toán học, và cơ chế đồng thuận (consensus mechanism) giúp hàng nghìn nút không quen biết nhau thống nhất một trạng thái duy nhất. Bài này mổ xẻ hai trụ cột đó ở mức đủ sâu để một cán bộ dữ liệu ngân hàng hiểu vì sao một giao dịch on-chain không thể bị sửa, và vì sao một mạng blockchain doanh nghiệp lại chọn kiến trúc rất khác Bitcoin.

Nếu bạn đã đọc bài kiểm soát truy cập & mật mã ứng dụng, phần đầu sẽ quen thuộc: hash, khoá đối xứng/bất đối xứng, chữ ký số là những khối cơ bản dùng chung. Điểm mới ở đây là cách blockchain ghép chúng lại thành một cấu trúc không thể giả mạo tập thể.

1. Hàm băm — "dấu vân tay" của dữ liệu

Hàm băm (hash function) nhận đầu vào bất kỳ độ dài và trả về một chuỗi cố định (với SHA-256 là 256 bit ≈ 64 ký tự hex). Blockchain gần như luôn dùng SHA-256 (Bitcoin) hoặc Keccak-256 (Ethereum). Ba tính chất khiến nó trở thành nền tảng của bất biến:

• Một chiều (pre-image resistance): từ giá trị băm không thể suy ngược ra đầu vào. Băm là "cửa một chiều".
• Chống va chạm (collision resistance): cực kỳ khó tìm hai đầu vào khác nhau cho cùng một giá trị băm.
• Hiệu ứng thác (avalanche effect): đổi 1 bit đầu vào → giá trị băm thay đổi hoàn toàn, không đoán được.

Vì thế giá trị băm là "dấu vân tay" của dữ liệu: chỉ cần sửa một dấu phẩy trong giao dịch, dấu vân tay đổi ngay, và ai cũng phát hiện.

Băm tạo tính bất biến & liên kết khối

Mỗi khối chứa hash của khối trước (previous block hash). Đây chính là "chain" trong blockchain: các khối móc nối nhau bằng chuỗi hash. Nếu kẻ tấn công sửa một giao dịch ở khối #100, hash của khối #100 đổi → không còn khớp với trường "previous hash" lưu ở khối #101 → khối #101 vỡ → kéo theo #102, #103... Muốn giả mạo, kẻ tấn công phải tính lại hash của toàn bộ các khối sau đó, đồng thời vượt qua đồng thuận của cả mạng — điều bất khả thi về mặt chi phí.

Merkle tree — tổng hợp giao dịch

Một khối có thể chứa hàng nghìn giao dịch. Thay vì băm gộp tất cả thành một chuỗi khổng lồ, blockchain dùng cây Merkle (Merkle tree): băm từng giao dịch (lá), rồi băm từng cặp lá lên, cứ thế đến khi còn một giá trị duy nhất là Merkle root, lưu trong header của khối.

Lợi ích thực tế:

• Toàn vẹn tập thể: đổi bất kỳ giao dịch nào → Merkle root đổi → hash khối đổi.
• Chứng minh gọn (Merkle proof): muốn chứng minh giao dịch X nằm trong khối mà không cần tải cả khối, chỉ cần cung cấp đường path gồm log₂(n) hash. Với 1 triệu giao dịch, chỉ ~20 hash. Đây là nền tảng của ví nhẹ (SPV / light client) — quan trọng khi ngân hàng muốn kiểm chứng dữ liệu mà không chạy full node.

2. Mã hoá bất đối xứng & chữ ký số

Hash bảo vệ tính toàn vẹn của dữ liệu, nhưng chưa trả lời câu hỏi: ai được phép chi tiêu số dư này? Đó là việc của mã hoá bất đối xứng (asymmetric / public-key cryptography).

Mỗi người dùng có một cặp khoá liên kết toán học:

• Khoá riêng tư (private key): bí mật tuyệt đối, chỉ chủ sở hữu giữ. Mất là mất tiền; lộ là bị lấy tiền.
• Khoá công khai (public key): chia sẻ tự do, dùng để người khác xác minh chữ ký.

Blockchain dùng mã đường cong elliptic (ECDSA trên đường secp256k1 với Bitcoin/Ethereum, hoặc EdDSA/Ed25519 ở một số chuỗi mới) vì khoá ngắn nhưng độ an toàn cao. Địa chỉ ví (wallet address) được suy ra từ khoá công khai qua một chuỗi băm (ví dụ Ethereum lấy 20 byte cuối của Keccak-256(public key)). Địa chỉ là công khai; khoá riêng thì không.

Ký giao dịch — chứng minh sở hữu & không chối bỏ

Khi bạn chuyển tiền, ví thực hiện:

1. Tạo nội dung giao dịch (from, to, amount, nonce, phí...).
2. Băm nội dung đó (message digest).
3. Ký digest bằng khoá riêng → tạo chữ ký số (digital signature).
4. Phát giao dịch kèm chữ ký + khoá công khai lên mạng.

Bất kỳ nút nào cũng có thể xác minh (verify): dùng khoá công khai + chữ ký + digest để kiểm tra chữ ký hợp lệ. Nếu hợp lệ, điều đó chứng minh:

• Xác thực & sở hữu (authenticity): chỉ người giữ khoá riêng tương ứng mới tạo được chữ ký này → đúng chủ tài khoản ký.
• Toàn vẹn (integrity): nếu ai đó sửa dù một byte nội dung, digest đổi, chữ ký không còn khớp.
• Không chối bỏ (non-repudiation): người ký không thể phủ nhận đã ký, vì chỉ họ có khoá riêng.

Vì sao không giả mạo được giao dịch

Kẻ tấn công muốn giả mạo giao dịch "Alice chuyển 10 BTC cho tôi" sẽ vấp phải: hắn không có khoá riêng của Alice nên không tạo được chữ ký hợp lệ. Nếu hắn sửa một giao dịch đã ký, digest đổi, chữ ký cũ vô hiệu. Nếu hắn thử sửa lịch sử một khối, chuỗi hash và Merkle root vỡ. Ba lớp — băm, cây Merkle, chữ ký số — kết hợp khiến việc giả mạo một giao dịch riêng lẻ là bất khả thi về mặt toán học, độc lập với đồng thuận. Ví dụ minh hoạ (giả lập, KHÔNG phải SQL sandbox, chỉ để hình dung khái niệm):

# Minh hoạ khái niệm — không phải lệnh chạy được
digest    = SHA256("from=Alice; to=Bob; amount=10; nonce=42")
signature = ECDSA_Sign(private_key_Alice, digest)
ok        = ECDSA_Verify(public_key_Alice, digest, signature)  # -> true

# Sửa lén amount thành 1000:
digest2   = SHA256("from=Alice; to=Bob; amount=1000; nonce=42")
ok2       = ECDSA_Verify(public_key_Alice, digest2, signature) # -> false

3. Vấn đề cần đồng thuận: tướng Byzantine & double-spend

Chữ ký chứng minh ai ký, nhưng trong mạng phi tập trung không có máy chủ trung tâm, câu hỏi khó hơn là: các nút không tin nhau, một số có thể gian lận hoặc lỗi, làm sao tất cả thống nhất được một trạng thái duy nhất?

Đây là bài toán các tướng Byzantine (Byzantine Generals Problem): nhiều tướng bao vây một thành, phải cùng quyết định tấn công hay rút lui qua các sứ giả có thể bị chặn hoặc phản bội. Cần một giao thức để các tướng trung thành đạt thống nhất dù có kẻ phản bội. Một hệ thống chịu được thành phần gian lận/lỗi như vậy gọi là chịu lỗi Byzantine (Byzantine Fault Tolerant — BFT).

Trong tiền số, biểu hiện cụ thể là double-spend (tiêu hai lần): kẻ gian gửi cùng một đồng coin cho hai người khác nhau, hy vọng cả hai đều tin mình nhận được. Nếu không có đồng thuận, mỗi nút có thể thấy một phiên bản lịch sử khác nhau. Cơ chế đồng thuận chính là thứ quyết định thứ tự giao dịch và loại bỏ double-spend: chỉ giao dịch nào được đưa vào khối được chấp nhận mới có hiệu lực, phần còn lại bị bác.

4. Các cơ chế đồng thuận

Proof of Work (PoW)

Proof of Work — dùng bởi Bitcoin — buộc các nút "thợ đào (miner)" đua nhau giải một câu đố băm: tìm một số nonce sao cho hash của khối nhỏ hơn một ngưỡng mục tiêu (target). Vì hash không đoán được, cách duy nhất là thử ngẫu nhiên hàng tỷ lần/giây (brute force). Ai tìm ra trước được quyền tạo khối và nhận thưởng (block reward + phí).

• An toàn qua chi phí: để viết lại lịch sử, kẻ tấn công phải sở hữu > 50% sức mạnh tính toán toàn mạng (tấn công 51%) — cực kỳ tốn kém về điện và phần cứng. An ninh đến từ chi phí thực (proof of work).
• Nhược điểm: tốn năng lượng khổng lồ, thông lượng thấp (~7 giao dịch/giây với Bitcoin), độ trễ cao. Độ khó (difficulty) tự điều chỉnh để giữ thời gian tạo khối ổn định (~10 phút với Bitcoin).

Proof of Stake (PoS)

Proof of Stake — Ethereum chuyển sang PoS trong sự kiện The Merge (tháng 9/2022) — thay "đào bằng điện" bằng "đặt cọc bằng vốn". Người tham gia trở thành validator bằng cách khoá (stake) một lượng coin (Ethereum yêu cầu 32 ETH). Giao thức chọn ngẫu nhiên validator để đề xuất và chứng thực khối; ai gian lận sẽ bị cắt cọc (slashing) — mất phần coin đã đặt.

• Tiết kiệm năng lượng: The Merge giảm ~99,9% điện năng của Ethereum vì không còn đua băm.
• An toàn qua vốn: tấn công đòi hỏi kiểm soát phần lớn lượng stake, vừa đắt vừa tự huỷ (giá trị coin sụp đổ, cọc bị cắt).
• Nhược điểm/tranh luận: xu hướng tập trung vào bên nhiều vốn, rủi ro "nothing at stake", phức tạp hơn về mặt cơ chế phạt.

BFT / PBFT — cho mạng permissioned

Với mạng được cấp phép (permissioned) — nơi mọi nút đều được định danh và cấp quyền trước (đúng bối cảnh ngân hàng) — không cần đốt điện hay đặt cọc để chống Sybil, vì danh tính đã biết. Ở đây dùng họ giao thức BFT cổ điển, tiêu biểu là PBFT (Practical Byzantine Fault Tolerance) và các biến thể hiện đại (Tendermint/CometBFT, IBFT của Hyperledger Besu, Raft cho môi trường không đối kháng).

Nguyên lý: các nút bỏ phiếu nhiều vòng (pre-prepare → prepare → commit) và đạt đồng thuận khi có ≥ 2/3 nút trung thực đồng ý. Hệ chịu được tối đa f nút lỗi trên tổng 3f+1 nút.

• Nhanh & finality tức thì: một khi khối được commit, nó cuối cùng ngay lập tức, không có fork — rất quan trọng cho quyết toán ngân hàng.
• Hữu hạn nút: chi phí giao tiếp tăng theo bình phương số nút (O(n²)), nên BFT phù hợp mạng vài chục đến vài trăm nút định danh, không phù hợp mạng công cộng triệu nút.

Các biến thể khác

5. Finality, fork và blockchain trilemma

Finality & fork

Fork xảy ra khi hai nút tạo khối hợp lệ gần như đồng thời → mạng tạm thời có hai nhánh. Cách xử lý phụ thuộc cơ chế:

• PoW/PoS xác suất: chọn nhánh "dài nhất/nặng nhất". Fork ngắn tự biến mất khi một nhánh vượt lên. Finality mang tính xác suất (probabilistic finality): khối càng sâu (càng nhiều xác nhận), xác suất bị đảo ngược càng thấp. Bitcoin thường coi 6 xác nhận (~60 phút) là an toàn.
• BFT: finality tức thì & tuyệt đối (deterministic finality): khi 2/3 nút commit, khối không bao giờ bị đảo. Không có fork cạnh tranh trong điều kiện bình thường.

Với ngân hàng, khác biệt này là then chốt: quyết toán tài chính cần biết chắc khi nào một giao dịch là không thể đảo ngược. Finality xác suất buộc phải "chờ n xác nhận"; finality tuyệt đối cho phép ghi nhận ngay.

Blockchain trilemma

Không có cơ chế nào tối ưu cả ba cùng lúc — đây là bộ ba bất khả thi (blockchain trilemma) do Vitalik Buterin nêu:

• Bảo mật (Security): chống tấn công, giả mạo, đảo ngược.
• Phi tập trung (Decentralization): không điểm kiểm soát duy nhất, nhiều nút độc lập.
• Khả mở rộng (Scalability): thông lượng cao, độ trễ thấp, chi phí thấp.

Bitcoin ưu tiên bảo mật + phi tập trung, hy sinh khả mở rộng. Nhiều chuỗi doanh nghiệp ưu tiên bảo mật + khả mở rộng bằng cách giảm phi tập trung (nút định danh, hữu hạn). Không có lựa chọn "đúng tuyệt đối" — chỉ có lựa chọn phù hợp bài toán.

6. Chọn đồng thuận cho ngân hàng: permissioned + BFT

Ngân hàng không cần và không muốn mạng công cộng vô danh. Yêu cầu nghiệp vụ dẫn thẳng đến mạng permissioned + đồng thuận BFT:

Nói cách khác: mạng permissioned đã giải quyết vấn đề "ai được tham gia" ở tầng quản trị, nên không cần cơ chế tốn kém (PoW/PoS) để chống nút giả mạo (Sybil). Bài toán còn lại thuần tuý là chịu lỗi Byzantine giữa một nhóm nút định danh — chính xác là thứ BFT/PBFT giải quyết tối ưu: nhanh, finality tuyệt đối, không lãng phí năng lượng. Đây là lý do các nền tảng blockchain doanh nghiệp phổ biến (Hyperledger Fabric, R3 Corda, Enterprise Ethereum/Besu) đều dùng biến thể BFT/PoA thay vì PoW. Chi tiết kiến trúc doanh nghiệp và CBDC được bàn ở bài blockchain doanh nghiệp & CBDC.

Use case thực tế

Bối cảnh: NCB tham gia một mạng blockchain liên ngân hàng (consortium) gồm 10 ngân hàng để quyết toán chuyển tiền liên ngân hàng nội địa theo thời gian thực, thay cho quy trình đối soát cuối ngày qua trung gian bù trừ.

Thiết kế đồng thuận:

• Loại mạng: permissioned — mỗi ngân hàng vận hành 2 nút validator định danh (tổng 20 nút), có thoả thuận pháp lý ràng buộc.
• Cơ chế: IBFT (một biến thể PBFT). Chịu được f = ⌊(20−1)/3⌋ = 6 nút lỗi vẫn hoạt động đúng — tương đương 3 ngân hàng gặp sự cố đồng thời mà mạng vẫn quyết toán.
• Finality: tuyệt đối, ngay khi ≥ 14/20 nút commit (ngưỡng 2/3+1). Không có fork → không phải chờ "n xác nhận".

Luồng một giao dịch:

1. Ngân hàng A tạo lệnh chuyển 5 tỷ VND cho khách của ngân hàng B, ký bằng khoá riêng của nút A.
2. Giao dịch phát lên mạng; các validator verify chữ ký bằng khoá công khai của A → xác nhận đúng A phát lệnh, không thể chối bỏ.
3. Validator được chọn đóng gói giao dịch vào khối, tính Merkle root, chạy vòng bỏ phiếu pre-prepare/prepare/commit.
4. Khi 14/20 nút commit, khối finality tức thì — giao dịch không thể đảo ngược. Số dư liên ngân hàng cập nhật ngay.

Kết quả đo được (minh hoạ):

Điểm mấu chốt: chính finality tuyệt đối của BFT cho phép ghi nhận quyết toán tức thì mà không phải chờ xác nhận như PoW/PoS công cộng — thứ mà nghiệp vụ liên ngân hàng bắt buộc phải có.

Ghi nhớ

• Hàm băm (SHA-256) một chiều, chống va chạm, hiệu ứng thác → là "dấu vân tay" tạo bất biến và liên kết khối qua previous-hash; Merkle tree tổng hợp mọi giao dịch vào một root, cho phép chứng minh gọn (Merkle proof).
• Mã hoá bất đối xứng: khoá riêng bí mật, khoá công khai chia sẻ; địa chỉ ví suy ra từ khoá công khai. Ký bằng khoá riêng, verify bằng khoá công khai.
• Chữ ký số đảm bảo ba thứ: xác thực/sở hữu, toàn vẹn, không chối bỏ → không ai giả mạo được giao dịch của người khác vì không có khoá riêng của họ.
• Đồng thuận giải bài toán tướng Byzantine và double-spend: quyết định thứ tự giao dịch, loại bỏ chi tiêu hai lần trong mạng phi tập trung không tin cậy.
• PoW an toàn qua chi phí điện (Bitcoin) nhưng tốn năng lượng; PoS an toàn qua vốn đặt cọc (Ethereum sau The Merge, giảm ~99,9% điện); BFT/PBFT dùng bỏ phiếu 2/3, nhanh, finality tuyệt đối, hợp mạng hữu hạn nút định danh.
• Finality: PoW/PoS cho finality xác suất (chờ n xác nhận, có fork tạm); BFT cho finality tuyệt đối ngay khi commit — then chốt cho quyết toán ngân hàng.
• Blockchain trilemma: không tối ưu đồng thời bảo mật – phi tập trung – khả mở rộng; phải đánh đổi tuỳ bài toán.
• Ngân hàng chọn permissioned + BFT: danh tính nút đã biết nên không cần PoW/PoS chống Sybil; chỉ cần chịu lỗi Byzantine giữa nhóm nút định danh — nhanh, finality tức thì, tiết kiệm năng lượng, dễ kiểm toán và tuân thủ.