Blockchain 4 — Smart Contract, Token & DeFi

Ở bài Bitcoin & Ethereum ta đã thấy Ethereum là "máy tính thế giới" có thể chạy code tuỳ ý trên blockchain. Bài này đi sâu vào ba lớp xây dựng nên toàn bộ tài chính phi tập trung: smart contract (hợp đồng thông minh — logic tự chạy), token (tài sản phát hành trên chuỗi) và DeFi (các ứng dụng tài chính dựng từ smart contract và token).

Với cán bộ dữ liệu ngân hàng, mục tiêu không phải để dựng sản phẩm DeFi, mà để (1) hiểu bản chất công nghệ nhằm đánh giá rủi ro khi dòng tiền khách chạm tới hệ sinh thái này, và (2) nhìn ra cơ hội hợp pháp mà ngân hàng có thể khai thác — token hoá tài sản, tự động hoá quy trình như thư tín dụng L/C. Ta sẽ có xem vài đoạn code Solidity, nhưng chỉ để minh hoạ nguyên lý — không cần biết lập trình.

1. Smart contract — hợp đồng thông minh

1.1. Là gì

Smart contract là một chương trình được triển khai (deploy) lên blockchain, tự động thực thi khi các điều kiện định trước được thoả mãn — không cần trung gian đứng ra thi hành. Cụm từ hay dùng: "code là luật" (code is law) — thoả thuận giữa các bên được viết thành mã, và mã đó chạy đúng như đã viết, không thiên vị, không "linh động".

Ba đặc tính then chốt:

• Tự thực thi (self-executing): khi điều kiện đúng, contract tự động chuyển tiền / đổi trạng thái, không cần ai bấm nút phê duyệt.
• Bất biến (immutable): sau khi deploy, code không sửa được. Muốn thay đổi phải deploy contract mới (có mẫu thiết kế "proxy/upgradeable" nhưng bản thân bytecode đã ghi thì cố định).
• Minh bạch: bytecode nằm công khai trên chuỗi, ai cũng kiểm tra được. Trạng thái (state) cũng công khai.

So sánh trực giác với ngân hàng: một lệnh thanh toán định kỳ (standing order) do core banking thực thi cũng "tự động", nhưng ngân hàng có thể sửa, huỷ, đảo. Smart contract thì không ai — kể cả người viết — can thiệp được sau khi chạy, trừ khi chính code cho phép. Đây vừa là sức mạnh (không thể chối bỏ, không cần tin trung gian) vừa là rủi ro (lỗi thì không sửa được).

1.2. Solidity & EVM — ở mức nguyên lý

Contract trên Ethereum thường được viết bằng Solidity — một ngôn ngữ lập trình bậc cao, cú pháp giống JavaScript/C++. Solidity được biên dịch (compile) xuống EVM bytecode — tập lệnh cấp thấp mà EVM (Ethereum Virtual Machine, máy ảo Ethereum) hiểu được.

Điều cần nhớ về nguyên lý (không cần học lập trình):

• Mọi node trong mạng đều chạy cùng bytecode với cùng input → phải ra cùng kết quả → các node đồng thuận về trạng thái mới.
• Vì thế EVM phải xác định (deterministic): cùng đầu vào luôn cho cùng đầu ra trên mọi máy. Không được có yếu tố ngẫu nhiên thật, không được gọi ra Internet, không được đọc giờ hệ thống tuỳ tiện — nếu không các node sẽ ra kết quả khác nhau và mạng không đồng thuận được.
• Mỗi thao tác tính toán tốn gas (đã nói ở bài trước), trả bằng ETH — cơ chế chống lạm dụng tài nguyên.

1.3. Ví dụ minh hoạ — escrow (ký quỹ)

Dưới đây là một đoạn Solidity RÚT GỌN, CHỈ ĐỂ MINH HOẠ nguyên lý một hợp đồng ký quỹ (escrow): người mua nạp tiền vào contract, tiền chỉ được giải ngân cho người bán khi người mua xác nhận đã nhận hàng. Đây không phải code sản xuất và bỏ qua nhiều kiểm tra an toàn.

// MINH HOẠ — KHÔNG dùng cho sản xuất
contract Escrow {
    address public buyer;
    address public seller;
    uint public amount;
    bool public delivered;

    // Người mua tạo hợp đồng và nạp tiền (msg.value) vào chính contract
    constructor(address _seller) payable {
        buyer  = msg.sender;   // ai deploy là người mua
        seller = _seller;
        amount = msg.value;    // số ETH đã nạp, contract đang giữ
    }

    // Người mua xác nhận đã nhận hàng -> giải ngân cho người bán
    function confirmReceived() external {
        require(msg.sender == buyer, "chi nguoi mua duoc xac nhan");
        require(!delivered, "da giai ngan roi");
        delivered = true;
        payable(seller).transfer(amount);   // tu dong chuyen tien
    }
}

Đọc ý nghĩa (không cần hiểu cú pháp): contract tự giữ tiền như một bên trung gian phi con người; điều kiện msg.sender == buyer đảm bảo chỉ đúng người mua mới kích hoạt được; khi thoả điều kiện, tiền tự động chảy sang người bán. Không có ngân hàng ký quỹ, không có nhân viên duyệt — logic ký quỹ nằm hết trong mã.

1.4. Tính xác định & oracle

Vì EVM phải xác định, contract không thể tự lấy dữ liệu ngoài đời (tỷ giá USD/VND, giá vàng, kết quả trận đấu, thời tiết, dữ liệu ngân hàng...). Nhưng rất nhiều ứng dụng tài chính lại cần dữ liệu đó. Lời giải là oracle — cầu nối đưa dữ liệu ngoài chuỗi (off-chain) vào blockchain một cách đáng tin.

• Oracle là một (hoặc nhiều) dịch vụ ghi dữ liệu ngoài lên chuỗi để contract đọc được.
• Chainlink là mạng oracle phi tập trung phổ biến nhất: nhiều node độc lập cùng lấy dữ liệu rồi tổng hợp, giảm rủi ro một nguồn sai/gian lận.
• Rủi ro oracle: nếu dữ liệu oracle bị thao túng (ví dụ đẩy giá tài sản lệch trong tích tắc), contract sẽ hành động sai — đây là gốc của nhiều vụ tấn công DeFi ("oracle manipulation").

Trực giác: contract giống một cỗ máy niêm phong trong hộp kính, không nhìn ra ngoài được; oracle là cái khe duy nhất để tuồn thông tin bên ngoài vào — nên khe đó phải cực kỳ đáng tin.

1.5. Rủi ro lỗi hợp đồng & audit

Vì contract bất biến và thường giữ tiền thật, một lỗi lập trình = mất tiền không sửa được. Vài loại lỗi kinh điển:

• Reentrancy (gọi lại lồng nhau): contract chuyển tiền ra ngoài trước khi cập nhật sổ nội bộ; contract nhận có thể "gọi ngược lại" hàm rút và rút nhiều lần trước khi số dư bị trừ. Đây chính là lỗ hổng trong vụ DAO hack (2016) — kẻ tấn công rút ~60 triệu USD ETH khỏi quỹ The DAO, dẫn tới việc Ethereum hard fork để hoàn tiền (tách ra Ethereum và Ethereum Classic). Một sự kiện định hình cả ngành.
• Integer overflow/underflow, quyền truy cập lỏng lẻo (ai cũng gọi được hàm nhạy cảm), phụ thuộc oracle yếu, logic kinh tế sai...

Biện pháp: audit (kiểm toán mã) bởi bên thứ ba chuyên môn, kiểm thử tự động, phân tích hình thức (formal verification), thưởng săn lỗi (bug bounty), và các thư viện chuẩn đã được kiểm chứng (như OpenZeppelin). Dù vậy, audit không đảm bảo 100% — nhiều dự án đã audit vẫn bị hack. Đây là điểm ngân hàng phải cực kỳ lưu ý khi cân nhắc dùng smart contract cho tài sản thật.

2. Token — tài sản trên chuỗi

Token là tài sản được phát hành trên một blockchain sẵn có bằng smart contract (khác coin là tài sản gốc của chuỗi — xem bài trước). Chuẩn token quy định bộ hàm chuẩn mà mọi ví/sàn có thể tương tác — nhờ chuẩn hoá mà token "cắm vào đâu cũng chạy".

2.1. ERC-20 — token thay thế được (fungible)

ERC-20 là chuẩn cho token fungible (thay thế được): mỗi đơn vị giống hệt và hoán đổi ngang giá với đơn vị khác — như tiền. 1 token của bạn bằng đúng 1 token của tôi. Dùng cho: tiền tệ số, điểm/credit, cổ phần, tài sản chia nhỏ được.

Chuẩn ERC-20 định nghĩa các hàm/sự kiện cơ bản: totalSupply (tổng cung), balanceOf(addr) (số dư một địa chỉ), transfer (chuyển), approve/transferFrom (uỷ quyền cho bên thứ ba tiêu hộ — nền tảng để sàn/contract khác thao tác token của bạn).

// MINH HOẠ — khung interface ERC-20 rút gọn
interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address to, uint256 value) external returns (bool);
    function approve(address spender, uint256 value) external returns (bool);
    function transferFrom(address from, address to, uint256 value) external returns (bool);
}

Lưu ý quan trọng đã nêu ở bài trước: số dư token nằm trong biến của contract, không phải "trong ví". Chuyển token vẫn phải trả gas bằng ETH, không phải bằng token đó.

2.2. ERC-721 / ERC-1155 — NFT (không thay thế)

ERC-721 là chuẩn cho NFT (Non-Fungible Token, token không thay thế được): mỗi token là độc nhất, có ID riêng, không hoán đổi ngang giá. Đại diện cho tài sản duy nhất: một tác phẩm số, một sổ đỏ, một chứng chỉ, một số hợp đồng cụ thể. Token #1 khác token #2, không thể "đổi ngang".

ERC-1155 là chuẩn "đa token" (multi-token): một contract quản lý nhiều loại token cùng lúc, cả fungible lẫn non-fungible — hiệu quả hơn khi cần nhiều hạng mục (hay dùng trong game, bộ sưu tập, hoặc token hoá nhiều hạng tài sản trong một hợp đồng).

2.3. Token hoá tài sản (tokenization)

Tokenization là biểu diễn tài sản đời thực thành token trên blockchain: bất động sản, trái phiếu, vàng, cổ phần, hoá đơn... Mỗi token là một "chứng chỉ số" đại diện quyền sở hữu (toàn phần hoặc một phần) đối với tài sản.

Lợi ích kỳ vọng:

• Chia nhỏ (fractional ownership): một bất động sản 10 tỷ chia thành 10.000 token, nhà đầu tư mua từng phần nhỏ.
• Thanh khoản & giao dịch 24/7, dàn xếp gần tức thời (giảm T+2).
• Minh bạch & tự động hoá: quyền sở hữu, chia cổ tức/lãi trái phiếu có thể tự chạy bằng smart contract.

Điểm mấu chốt (rủi ro): token chỉ có giá trị nếu được ràng buộc pháp lý với tài sản thật ngoài đời và có bên đáng tin lưu ký/bảo chứng tài sản gốc. "Token vàng" chỉ đáng giá khi có vàng thật được giữ và có thể đòi lại. Đây là lằn ranh giữa cơ hội thật và rủi ro — và cũng là nơi ngân hàng có vai trò tự nhiên (bên lưu ký, phát hành đáng tin).

2.4. Stablecoin — token gắn giá trị fiat

Stablecoin là token ERC-20 được thiết kế để giữ giá ổn định, thường neo 1:1 với một tiền pháp định (fiat) như USD. Đây là "tiền mặt" của thế giới crypto — dùng để giao dịch, lưu trú giá trị mà không chịu biến động của BTC/ETH. Ví dụ phổ biến: USDT (Tether), USDC (Circle).

Cơ chế giữ giá (bảo chứng) — khác nhau về mức an toàn:

• Bảo chứng bằng fiat (fiat-backed): mỗi token phát hành được hậu thuẫn bằng 1 USD (hoặc tài sản tương đương như trái phiếu kho bạc) do tổ chức phát hành nắm giữ — USDT, USDC. Rủi ro: phụ thuộc uy tín & minh bạch dự trữ của bên phát hành (họ có thật sự giữ đủ tiền không?).
• Bảo chứng bằng crypto (over-collateralized): khoá crypto vượt mức làm tài sản đảm bảo (như DAI) — phi tập trung hơn nhưng phức tạp và chịu biến động tài sản thế chấp.
• Thuật toán (algorithmic): giữ giá bằng cơ chế cung/cầu tự động, không có tài sản bảo chứng đầy đủ — rủi ro rất cao; vụ sập UST/Terra (2022) làm bốc hơi hàng chục tỷ USD là bài học điển hình.

Với ngân hàng, stablecoin fiat-backed là dạng tài sản số gần gũi nhất với nghiệp vụ truyền thống (giống tiền gửi/tiền điện tử) và là ứng viên cho thanh toán xuyên biên giới — nhưng khung pháp lý Việt Nam hiện chưa công nhận làm phương tiện thanh toán.

3. DeFi — tài chính phi tập trung

DeFi (Decentralized Finance) là hệ sinh thái dịch vụ tài chính dựng hoàn toàn bằng smart contract trên blockchain public, thay trung gian (ngân hàng, sàn, môi giới) bằng code. Nguyên lý cốt lõi: những việc ngân hàng/sàn làm — giữ tiền, khớp lệnh, cho vay, tính lãi — được viết thành hợp đồng thông minh chạy tự động, không cần xin phép (permissionless), mở cho bất kỳ ai có ví.

Điểm hấp dẫn (và cũng nguy hiểm): không có bên trung gian nghĩa là không có phí trung gian, chạy 24/7, minh bạch — nhưng cũng không có ai chịu trách nhiệm, không có bảo hiểm tiền gửi, không có "gọi tổng đài".

3.1. DEX & AMM — sàn phi tập trung

DEX (Decentralized Exchange, sàn giao dịch phi tập trung) cho phép đổi token trực tiếp giữa ví với ví, không cần sàn tập trung giữ tiền. Đa số DEX dùng mô hình AMM (Automated Market Maker, nhà tạo lập thị trường tự động) thay cho sổ lệnh (order book):

• Thay vì khớp người mua với người bán, AMM dùng pool thanh khoản (liquidity pool) — một contract giữ hai token (ví dụ ETH và USDC) do các nhà cung cấp thanh khoản (LP) nạp vào.
• Giá được tính bằng công thức toán học trên tỷ lệ hai token trong pool. Công thức kinh điển của Uniswap là tích không đổi: x * y = k (số lượng token X nhân token Y luôn bằng hằng số k). Ai mua ETH thì rút ETH ra, nạp USDC vào → ETH trong pool ít đi → giá ETH tự tăng.
• LP nhận phí giao dịch làm phần thưởng, nhưng chịu rủi ro impermanent loss (tổn thất tạm thời khi tỷ giá hai token biến động).

3.2. Lending / borrowing — cho vay & đi vay

Các giao thức như Aave, Compound cho phép:

• Người gửi nạp token vào một pool cho vay → nhận lãi suất (tự động tính theo cung/cầu).
• Người vay thế chấp tài sản crypto để vay token khác ra.

Đặc điểm khác hẳn ngân hàng: thế chấp vượt mức (over-collateralization). Vì không có định danh/điểm tín dụng/khả năng đòi nợ pháp lý, người vay phải khoá tài sản đảm bảo lớn hơn khoản vay (ví dụ khoá 150 USD ETH để vay 100 USD USDC). Nếu giá tài sản thế chấp rớt dưới ngưỡng, contract tự động thanh lý (liquidation) — bán tài sản thế chấp để bảo vệ pool, dựa vào giá từ oracle. Không có "cơ cấu nợ" hay "thương lượng" như tín dụng ngân hàng.

3.3. Yield / staking

• Staking: khoá token để tham gia bảo mật mạng PoS (hoặc giao thức) và nhận thưởng — như "gửi tiết kiệm" nhưng bản chất là góp vốn bảo mật.
• Yield farming: di chuyển vốn qua các giao thức để tối ưu lợi suất (từ phí LP, lãi cho vay, token thưởng). Lợi suất công bố (APY) đôi khi rất cao — thường đi kèm rủi ro tương xứng, nhiều khi là bẫy.

3.4. Bridge — cầu nối chuỗi

Bridge (cầu nối) chuyển tài sản giữa các blockchain khác nhau (ví dụ đưa token từ Ethereum sang một chuỗi khác). Bridge thường khoá tài sản ở chuỗi nguồn và "đúc" bản sao ở chuỗi đích. Đây là một trong những điểm bị tấn công nhiều nhất trong DeFi — nhiều vụ hack lớn nhất lịch sử crypto (hàng trăm triệu USD) xảy ra ở bridge, vì chúng tập trung một lượng tài sản khổng lồ trong một contract.

4. Rủi ro đặc thù của DeFi

DeFi khuếch đại mọi rủi ro của smart contract, cộng thêm rủi ro tài chính:

• Rủi ro hợp đồng lỗi: bug trong contract → mất tiền không đảo được (reentrancy, logic sai...). Contract giữ càng nhiều tiền càng là "mồi ngon".
• Rủi ro thanh khoản: pool cạn thanh khoản → không rút/đổi được với giá hợp lý; trượt giá (slippage) lớn.
• Rủi ro oracle: thao túng giá oracle để lừa contract thanh lý sai hoặc vay vượt mức.
• Rug-pull (rút thảm): đội ngũ dự án (ẩn danh) rút sạch thanh khoản/quỹ rồi biến mất — lừa đảo có chủ đích.
• Biến động (volatility): giá tài sản thế chấp rơi mạnh → thanh lý hàng loạt, hiệu ứng dây chuyền.
• Không ai bảo vệ: không có bảo hiểm tiền gửi, không cơ quan quản lý bảo hộ, không hoàn tiền, không chargeback. Mất là mất. Đây là khác biệt căn bản so với gửi tiền ngân hàng.

Tóm lại: DeFi cung cấp dịch vụ giống ngân hàng nhưng không có lưới an toàn của ngân hàng. Người dùng gánh toàn bộ rủi ro.

5. Góc nhìn ngân hàng: cơ hội & thận trọng

Ngân hàng Việt Nam không tham gia DeFi mở (không phù hợp khung pháp lý và khẩu vị rủi ro). Nhưng công nghệ nền tảng — smart contract và tokenization — mở ra cơ hội có kiểm soát:

Cơ hội (thường trên chuỗi permissioned, không phải DeFi công khai):

• Token hoá tài sản: phát hành trái phiếu số, chứng chỉ tiền gửi, token hoá tài sản đảm bảo — với ngân hàng làm bên lưu ký/phát hành đáng tin (bù đúng điểm yếu của DeFi công khai).
• Hợp đồng tự động cho quy trình nhiều bên: điển hình là thư tín dụng (L/C) trong tài trợ thương mại — smart contract có thể tự giải ngân khi chứng từ được xác nhận, giảm thao tác thủ công và thời gian. Các use case ngân hàng cụ thể sẽ đào sâu ở bài use case.
• Thanh toán/dàn xếp trên sổ cái phân tán, kết nối với enterprise blockchain & CBDC.

Thận trọng bắt buộc:

• Rủi ro code: bất biến + giữ tiền thật = lỗi là thảm hoạ. Phải audit độc lập, kiểm thử kỹ, dùng thư viện đã kiểm chứng, có cơ chế tạm dừng/nâng cấp hợp lý.
• Rủi ro pháp lý & tuân thủ: hiệu lực pháp lý của "code là luật", xử lý tranh chấp, KYC/AML — đào sâu ở risk & regulation.
• Rủi ro oracle & phụ thuộc bên ngoài: dữ liệu đầu vào sai thì logic đúng vẫn ra kết quả sai.

Vai trò cán bộ dữ liệu: hiểu cơ chế để đánh giá rủi ro, thiết kế giám sát, và tư vấn cơ hội hợp pháp — chứ không phải để ngân hàng chơi DeFi.

Use case thực tế

Bối cảnh: NCB (giả định) khảo sát một pilot token hoá chứng chỉ tiền gửi (CD) trên chuỗi permissioned nội bộ. Đội dữ liệu cần (1) khoanh vùng khách hàng phù hợp mời tham gia và (2) hiểu một giao dịch token sẽ trông thế nào để thiết kế đối chiếu.

Bước 1 — Truy vấn nội bộ. Lọc khách hàng có số dư tiền gửi lớn, ổn định để mời thử nghiệm. Câu SELECT sau chạy trên sandbox core banking (không đụng dữ liệu on-chain):

-- ▶ Chạy được
SELECT c.id, c.full_name, c.city,
       COUNT(a.id)   AS so_tai_khoan,
       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.id, c.full_name, c.city
HAVING SUM(a.balance) > 1000000000
ORDER BY tong_so_du DESC;

Bước 2 — Hình dung giao dịch token. Nếu CD được phát hành thành token ERC-20 trên chuỗi permissioned, một lần "chuyển quyền sở hữu CD" sẽ là một giao dịch gọi hàm transfer. Ví dụ MINH HOẠ (KHÔNG phải giao dịch thật, KHÔNG phải SQL):

Contract:  0xCD01...a7F3   (token chung chi tien gui NCB)
Method:    transfer(to, value)
From:      0x1234...abcd   (vi khach hang A)
To:        0x5678...ef90   (vi khach hang B)
Value:     100  (= 100 token, moi token = 1 CD menh gia 10 trieu)
Event:     Transfer(A, B, 100)
Status:    Success  |  ghi vinh vien tren so cai permissioned

Từ event Transfer phát ra, hệ thống off-chain của ngân hàng đọc và đối chiếu với sổ đăng ký sở hữu nội bộ — đảm bảo mọi chuyển nhượng token khớp hồ sơ pháp lý của CD.

Bước 3 — Kết luận. Kết hợp danh sách khách (bước 1) và mô hình dữ liệu giao dịch token (bước 2), đội thiết kế được cơ chế đối chiếu on-chain ↔ sổ nội bộ trước khi mở rộng — đúng tinh thần thận trọng: tokenization có ngân hàng bảo chứng, không phải DeFi mở.

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

Ghi nhớ

• Smart contract = code tự thực thi trên blockchain, "code là luật", bất biến sau khi deploy. Sức mạnh (không cần trung gian tin cậy) đi kèm rủi ro (lỗi không sửa được).
• Contract viết bằng Solidity, chạy trên EVM; phải xác định (deterministic) — mọi node cùng input ra cùng kết quả. Muốn dữ liệu ngoài đời phải dùng oracle (Chainlink).
• Lỗi hợp đồng nguy hiểm: reentrancy (vụ DAO hack 2016 → hard fork). Cần audit, nhưng audit không đảm bảo tuyệt đối.
• Token: ERC-20 (fungible — thay thế được, dùng cho tiền/điểm/cổ phần); ERC-721/1155 (NFT — độc nhất, đại diện tài sản duy nhất). Số dư token nằm trong contract; chuyển token vẫn trả gas bằng ETH.
• Tokenization đưa tài sản thật (bất động sản/trái phiếu/vàng) lên chuỗi — chỉ có giá trị khi ràng buộc pháp lý & có bên bảo chứng. Stablecoin neo giá fiat (USDT/USDC fiat-backed); cảnh giác loại thuật toán (sập UST/Terra).
• DeFi thay trung gian bằng smart contract: DEX/AMM (pool thanh khoản, x·y=k), lending (Aave/Compound, thế chấp vượt mức, thanh lý tự động), staking/yield, bridge (điểm bị tấn công nhiều).
• Rủi ro DeFi: hợp đồng lỗi, thanh khoản, oracle, rug-pull, biến động — và không có ai bảo vệ (không bảo hiểm tiền gửi, không hoàn tiền).
• Ngân hàng: cơ hội ở tokenization có bảo chứng và tự động hoá L/C (dẫn tới use case ngân hàng); nhưng phải cực kỳ thận trọng về code, pháp lý, oracle. Hiểu để đánh giá & giám sát, không để chơi DeFi.