Kiểm tra các ứng dụng DeFi khác với kiểm tra phần mềm truyền thống ở nhiều điểm. Trong phát triển truyền thống, một lỗi có thể gây ra sự cố hoặc hư hỏng dữ liệu – điều gây phiền phức nhưng có thể được sửa chữa bằng cách gỡ lỗi. Trong DeFi, một lỗi có thể làm cạn kiệt hàng triệu đô la tiền của người dùng ngay lập tức, và do tính không thể thay đổi của blockchain, thường không có "gỡ lỗi" – chỉ có "báo cáo hậu quả". Sự thực này ảnh hưởng đến tất cả các phương pháp kiểm tra được đề cập trong hướng dẫn này.
Dù bạn đang xây dựng một DEX, một giao thức cho vay hoặc một công cụ tổng hợp lợi nhuận, các phương pháp thử nghiệm DeFi phải giải quyết các rủi ro liên quan đến khả năng kết hợp, môi trường đối kháng và khả năng không thể quay lại. Bài viết này sẽ hướng dẫn bạn qua toàn bộ thang độ thử nghiệm: từ các thử nghiệm đơn vị để phát hiện các lỗi logic, đến việc sử dụng công cụ fuzzing để phát hiện các trường hợp đặc biệt mà con người bỏ lỡ, cho đến việc xác minh chính thức để chứng minh toán học các tính chất không thay đổi quan trọng.
Tại sao thử nghiệm DeFi khác với thử nghiệm phần mềm truyền thống
Ba yếu tố làm cho thử nghiệm DeFi trở thành một lĩnh vực riêng biệt:
Không thể thay đổi & rủi ro tài chính — Sau khi triển khai, các hợp đồng thông minh không thể được nâng cấp dễ dàng. Một lỗi tràn số nguyên hoặc lỗ hổng tái nhập có thể dẫn đến mất mát tài sản vĩnh viễn. Sự tấn công DAO năm 2016 (3,6 triệu ETH), mạng Poly năm 2021 (611 triệu USD) và Wormhole năm 2022 (320 triệu USD) đều khai thác các lỗi mà các thử nghiệm nghiêm ngặt có thể phát hiện được.
Rủi ro liên quan đến khả năng kết hợp — Các giao thức DeFi không tồn tại độc lập. Giao thức cho vay của bạn được tích hợp với DEX để thực hiện thanh lý, và nó dựa vào một oracle để định giá, có thể sử dụng một nguồn dữ liệu Chainlink có thể có sự sai lệch. Kiểm tra phải bao gồm không chỉ mã của bạn, mà còn cách mã của bạn hoạt động khi kết hợp với các giao thức khác, bao gồm cả các kết hợp đối kháng.
Môi trường cạnh tranh — Mỗi giao dịch đều được công bố trước khi thực hiện. Máy móc MEV thực hiện các giao dịch có lợi trước, giữa và sau. Các nhà thanh lý cạnh tranh để thực hiện các quá trình thanh lý đầu tiên. Các thử nghiệm của bạn phải mô phỏng thực tế cạnh tranh này, không chỉ các trường hợp thuận lợi.
Chìa khóa quan trọng: Kiểm tra truyền thống hỏi "có hoạt động không?" Kiểm tra DeFi hỏi "nó thất bại như thế nào và bán kính nổ là bao nhiêu?"
Thử nghiệm hợp đồng thông minh: nền tảng
Kiểm tra đơn vị là nền tảng của tháp kiểm tra. Trong DeFi, các thử nghiệm đơn vị kiểm tra các chức năng riêng lẻ một cách độc lập – tạo ra, hủy bỏ, chuyển giao, tính toán phần thưởng, kiểm tra kiểm soát truy cập.
Khung cảnh chế tạo công cụ
| Khung | Ngôn ngữ | Tốc độ | Tốt nhất cho |
|---|---|---|---|
| Nhà nấu đồng (forge) | Solidity | ⚡⚡⚡ Nhanh nhất | Các nhóm Pure Solidity, tích hợp fuzzing |
| Mũ bảo hiểm | TypeScript/JavaScript | ⚡⚡ Tốt | Các nhóm TypeScript, các thiết bị phức tạp, các công cụ phổ biến |
| Truffle | JavaScript | ⚡ Chậm | Các dự án cũ, các quy trình làm việc nặng về di chuyển |
Tuyên bố khuyến nghị: Đối với các dự án DeFi mới trong năm 2024+, Foundry là lựa chọn mặc định. Các thử nghiệm Solidity bản địa loại bỏ việc chuyển đổi ngữ cảnh, tích hợp kiểm tra lựa chọn ngẫu nhiên/kiểm tra không thay đổi, và tốc độ nhanh chóng (gấp 10-100 lần so với Hardhat) giúp tạo ra các vòng phản hồi chặt chẽ.
Các mẫu kiểm tra đơn vị chính
Mô hình AAA (Arrange-Act-Assert): `solidity function testUserCanDepositAndWithdraw() public { // Arrange vm.deal(user, 1000 ether); vm.prank(user); vault.deposit(100 ether);
// Act vm.prank(user); vault.withdraw(50 ether);
// Assert assertEq(vault.balanceOf(user), 50 ether); } `
Mã cheat cho chế độ thực tế của Foundry: `solidity function testLiquidationWithRealisticPrices() public { // Arrange: fork mainnet state at block 19M vm.createFork("https://eth-mainnet.alchemyapi.io/v2/KEY", 19_000_000);
// Act: manipulate oracle price to trigger liquidation vm.prank(oracleAdmin); oracle.updatePrice(ETH_USD, 1500 * 1e8); // ETH drops to $1500
// Assert: position should be liquidatable assertTrue(vault.isLiquidatable(riskyPosition)); } `
Các trường hợp đặc biệt mà mỗi bài kiểm tra đơn vị DeFi phải bao gồm
- Reentrancy — Kiểm tra các biến đổi
nonReentrantvới các hợp đồng độc hại gọi lại
Flowchart - Unit testing flow for smart contracts
Thử nghiệm các giao thức DeFi: kiểm tra khả năng kết hợp
Các thử nghiệm đơn vị kiểm tra các thành phần; các thử nghiệm tích hợp kiểm tra hệ thống. Trong DeFi, điều này có nghĩa là kiểm tra các tương tác giữa nhiều hợp đồng, các cấu trúc từ hợp đồng này sang hợp đồng khác, và các chuyển đổi trạng thái qua các giới hạn của hợp đồng.
Kiến trúc kiểm thử tích hợp
Một bộ kiểm tra tích hợp thích hợp phản ánh việc triển khai sản xuất của bạn:
` ┌─────────────────────────────────────────────────────────────┐ │ INTEGRATION TEST SUITE │ ├─────────────────┬─────────────────┬─────────────────────────┤ │ CORE PROTOCOL │ EXTERNAL DEPS │ ADVERSARIAL │ │ (Your Contracts)│ (Mocked/Real) │ ACTORS │ ├─────────────────┼─────────────────┼─────────────────────────┤ │ • Vault │ • Oracle (Mock) │ • MEV Bot │ │ • Strategy │ • DEX (Real) │ • Liquidator │ │ • Rewards │ • ERC20 Tokens │ • Front-runner │ │ • Governance │ • Bridge │ • Sandwich Attacker │ └─────────────────┴─────────────────┴─────────────────────────┘ `
Diagram - Integration test architecture for DeFi protocols
Cấu trúc quy trình thử nghiệm: một ví dụ thực tế
Hãy xem xét một giao thức cho vay sử dụng Uniswap V3 cho việc thanh lý và Chainlink cho việc định giá:
`solidity // Integration test: full liquidation flow function testFullLiquidationFlow() public { // 1. Setup: deposit collateral, borrow against it vm.deal(borrower, 100 ether); vm.prank(borrower); weth.deposit{value: 50 ether}(borrower); weth.approve(address(lending), 50 ether); lending.depositCollateral(address(weth), 50 ether); lending.borrow(address(usdc), 20_000 * 1e6); // $20k USDC
// 2. Price drop: ETH falls from $2000 to $1500 vm.prank(chainlinkAdmin); mockChainlink.updateAnswer(address(weth), 1500 * 1e8);
// 3. Liquidator calls liquidate() vm.deal(liquidator, 25_000 1e6); // USDC to repay vm.prank(liquidator); usdc.approve(address(lending), 25_000 1e6); lending.liquidate(borrower, address(weth), address(usdc), 20_000 * 1e6);
// 4. Verify: liquidator receives discounted collateral // 5. Verify: borrower debt reduced, collateral seized // 6. Verify: Uniswap V3 swap executed for collateral → USDC } `
Các phương pháp kiểm tra tích hợp tốt nhất
- Sử dụng hợp đồng thực khi có thể — Tạo fork mainnet cho DEX, oracle, token. Chỉ mô phỏng những thứ bạn kiểm soát.
Fuzzing và kiểm tra dựa trên thuộc tính: Tìm trường hợp biên giới tự động
Các thử nghiệm đơn vị và tích hợp bao gồm các kịch bản đã biết. Fuzzing khám phá các trường hợp không biết – tạo ra hàng nghìn đầu vào ngẫu nhiên để tìm ra các trường hợp đặc biệt mà con người không thể tưởng tượng được.
Triết lý kiểm tra không thay đổi
Kiểm tra truyền thống: "Đối với đầu vào X, mong đợi kết quả Y" Kiểm tra dựa trên thuộc tính: "Đối với tất cả các đầu vào hợp lệ, thuộc tính P phải đúng"
Invariants là các thuộc tính phải luôn luôn đúng, bất kể trạng thái hay các đầu vào:
totalSupply == sumOfAllBalancescollateralRatio >= minimumCollateralRatio(cho các vị trí có đủ tài sản đảm bảo)rewardsDistributed <= rewardsAccruednoUserCanWithdrawMoreThanDeposited()
So sánh các công cụ
| Công cụ | Lối tiếp cận | Các điểm mạnh | Kênh học tập |
|---|---|---|---|
| Fuzz của Foundry | Được tích hợp, tương thích với Solidity | Không cần thiết lập, nhanh chóng, tích hợp với thử nghiệm forge | Thấp |
| Echidna | Tự lập, dựa trên Haskell | Tìm hiểu sâu hơn, duy trì bộ dữ liệu, thu nhỏ | Mức trung |
| Halmos | Điều hành biểu tượng + fuzzing | Tìm ra lỗi sâu hơn, chứng minh không thể truy cập | Cao |
Tuyên bố: Bắt đầu với Foundry fuzz (miễn phí và có sẵn). Tiến lên Echidna cho các giao thức quan trọng. Để dành Halmos cho mục tiêu có giá trị cao nhất.
Viết các biến số hiệu quả
`solidity // Foundry invariant test invariant("Total assets never exceed total shares pricePerShare") public { assertLe(vault.totalAssets(), vault.totalSupply() vault.pricePerShare()); }
invariant("No position can be undercollateralized") public { for (uint i = 0; i < vault.positionsLength(); i++) { Position memory pos = vault.positions(i); if (pos.collateral > 0) { assertGe(pos.collateralRatio(), vault.minCollateralRatio()); } } } `
Quản lý chiến dịch
- Thời gian: Chạy 4-8 giờ cho CI; 24-72 giờ cho các phiên bản thử nghiệm
Sequence - Fuzzing process and invariant discovery
Thử nghiệm Fork và mô phỏng Mainnet: Điều kiện thực tế
Khi chạy thử nghiệm, các thử nghiệm được thực hiện đối với trạng thái mainnet thực tế (hoặc gần đây nhất). Điều này giúp phát hiện các lỗi chỉ xuất hiện khi có địa chỉ hợp đồng thực tế, số dư token thực tế, giá oracle thực tế và tương tác của quy trình thực tế.
Các công cụ kiểm tra cù
| Công cụ | Nguồn của Fork | Tốt nhất cho |
|---|---|---|
| Anvil (nhà đúc) | URL RPC (Alchemy, Infura, QuickNode) | Phát triển địa phương, CI, lặp lại nhanh |
| Hardhat Fork | URL RPC | Các nhóm TypeScript, các thiết bị phức tạp |
| Mô phỏng nhẹ nhàng | Trình duyệt Tenderly | Debugging trực quan, phân tích gas, chia sẻ |
| Cây vạc của nhà nấu đồng | RPC + số khối | Tái diễn lịch sử, kiểm tra khối cụ thể |
Khi nào nên sử dụng thử nghiệm Fork
- Thử nghiệm chống lại các giao thức thực tế — Giao thức của bạn tích hợp với Aave V3, Uniswap V3, Curve. Các mô phỏng không thể tái tạo hành vi chính xác của chúng.
Chuỗi làm việc kiểm tra Fork
`bash
anvil --fork-url $MAINNET_RPC --fork-block-number 19500000
forge test --fork-url http://localhost:8545 -vvvv
vm.createSelectFork("https://eth-mainnet.alchemyapi.io/v2/KEY", 19500000); `
Bối cảnh nhà phát triển Việt Nam
Nhiều nhà phát triển Việt Nam thường phải đối mặt với độ trễ RPC đến các nút ở Mỹ/EU. Các nhà cung cấp RPC địa phương (NodeReal Việt Nam, BlockPi Á Châu, Chainstack SG) giảm độ trễ fork từ 300ms+ xuống 50-80ms, giúp việc thử nghiệm fork trở nên thực tế trong CI/CD.
Flowchart - Fork testing workflow with mainnet simulation
Xác minh chính thức: Bảo đảm toán học cho các tính chất không thay đổi quan trọng
Xác minh chính thức sử dụng các chứng minh toán học để đảm bảo rằng một số thuộc tính đúng cho tất cả các trường hợp thực thi có thể. Mặt khác với kiểm tra (mà chỉ lấy mẫu), xác minh là chứng minh.
Khi nào nên sử dụng xác minh chính thức
Sử dụng nó cho các điều kiện không thay đổi trong kế toán cơ bản (totalAssets == sum(balances)), các điều kiện không thay đổi trong kiểm soát truy cập (các hàm onlyOwner chỉ thực sự có thể được gọi bởi chủ sở hữu), nâng cao độ an toàn (hợp nhất bố cục lưu trữ), các công thức toán học (các đường cong AMM, các mô hình lãi suất)
Thoát khỏi các trường hợp sau:
- Lógica giao diện người dùng, tích hợp phần trước (frontend)
- Các tương tác giao thức bên ngoài phức tạp (có quá nhiều giả định)
- Mã nguồn thay đổi nhanh chóng (cần duy trì các tiêu chuẩn xác nhận)
Công cụ Landscape
| Công cụ | Lối tiếp cận | Chi phí | Kỹ năng cần thiết |
|---|---|---|---|
| Certora Prover | Thông số CVL, phân tích tĩnh | $$$ (doanh nghiệp) | Cao (ngôn ngữ CVL) |
| Vẽ vẽ | Xác minh thời gian chạy thông qua công cụ | Miễn phí | Thấp (một số ghi chú về tính chất của mã) |
| KeVM | Semantik của khung K | Miễn phí | Rất cao |
| Solidity SMTChecker | Đã tích hợp (thử nghiệm) | Miễn phí | Mức trung |
Tuyên bố khuyến nghị: Scribble cho việc áp dụng (ghi chú vào mã hiện có, chạy trong CI). Certora cho các quy trình sản xuất có TVL > 10 triệu USD – ngân sách cho hợp tác với công ty kiểm toán.
Ví dụ về Scribble: Điền chú thích cho các yếu tố không thay đổi
`solidity /// @notice Vault invariant: total assets always >= total shares /// #invariant "totalAssets() >= totalSupply()" contract Vault { function totalAssets() public view returns (uint) { ... } function totalSupply() public view returns (uint) { ... } } `
Chạy: scribble contracts/Vault.sol --output instrumented/ && forge test --instrumented
Ví dụ về Certora CVL
`cvl // Vault.spec rule totalAssetsGeTotalSupply() { mathint totalAssets = vault.totalAssets(); mathint totalSupply = vault.totalSupply(); assert totalAssets >= totalSupply, "Total assets < total supply"; } `
Chạy: certoraRun certora/Vault.spec --verify Vault:Vault
So sánh các công cụ thử nghiệm: Chọn bộ công cụ phù hợp
Dạng thử nghiệm của bạn nên phù hợp với đội ngũ, mức độ phức tạp của giao thức và khả năng chịu rủi ro.
Cơ chế quyết định
| Tiểu sử dự án | Danh sách khuyến nghị |
|---|---|
| Đội ngũ nhỏ, quy trình mới, mục tiêu TVL <$1 triệu | Foundry (unit + fuzz) + Scribble |
| Đội ngũ đang phát triển, nhiều tích hợp, TVL từ 1-50 triệu USD | Công ty sản xuất + Echidna + Kiểm tra Fork (Anvil) + Scribble |
| Quy trình sản xuất, > 50 triệu TVL, người dùng tổ chức | Stack đầy đủ: Foundry + Echidna + Certora + Tenderly + Fork CI |
| Protokol cắt ngang / đa VM | Thêm: Hardhat (cho các thiết bị không sử dụng EVM), các công cụ chuyên dụng |
Sự tích hợp CI/CD: Dòng kiểm tra tự động
Một chuỗi sản xuất sẵn sàng của DeFi CI chạy các lớp kiểm tra khác nhau với tần suất khác nhau:
`yaml
name: DeFi Test Suite
on: push: branches: [main, develop] pull_request: schedule:
- cron: '0 2 *' # Nightly fuzz campaigns
jobs: unit-tests: runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- uses: foundry-rs/foundry-toolchain@v1
- run: forge test --match-contract UnitTest
integration-tests: runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- uses: foundry-rs/foundry-toolchain@v1
- run: forge test --match-contract IntegrationTest --fork-url ${{ secrets.MAINNET_RPC }}
fuzz-campaign: if: github.event_name == 'schedule' || github.event_name == 'pull_request' runs-on: ubuntu-latest timeout-minutes: 480 # 8 hours steps:
- uses: actions/checkout@v4
- uses: foundry-rs/foundry-toolchain@v1
- run: forge test --match-contract FuzzTest --fuzz-runs 100000
formal-verification: if: github.event_name == 'pull_request' && github.base_ref == 'main' runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run: scribble contracts/*/.sol --output instrumented/
- run: forge test --instrumented
`
Khu vực phủ sóng và chất lượng
`bash
forge coverage --report lcov
`
Các mẫu kiểm tra phổ biến và các mẫu chống lại
Các mẫu có hiệu quả (hãy làm điều này)
1. Thiết kế thử nghiệm dựa trên đặc điểm của tài sản `solidity // Good: Test the property, not the implementation function invariant_NoFreeMoney() public { uint256 initialTotalValue = vault.totalAssets(); // ... arbitrary operations ... assertGe(vault.totalAssets(), initialTotalValue); } `
2. Bộ kiểm tra đối kháng `solidity function testSandwichAttackResistance() public { ... } function testFlashLoanAttack() public { ... } function testOracleManipulation() public { ... } `
3. Fuzzing trạng thái với thiết lập `solidity function setUp() public { // Deploy full protocol // Seed with realistic liquidity } `
4. Thử nghiệm tách (fork) để kiểm tra sự lặp lại Khi xảy ra sự cố trên mainnet, hãy thêm một thử nghiệm tách ở khối đó để ngăn chặn sự lặp lại.
Các mô hình chống lại thất bại (tránh những điều này)
❌ Kiểm tra thực hiện, không phải hành vi `solidity // Bad: Tightly coupled to internal implementation function testInternalMappingUpdated() public { assertEq(vault.userDeposits[user], 100 ether); // Breaks on refactor } `
❌ Không quan tâm đến khả năng kết hợp `solidity // Bad: Tests in isolation, misses integration bugs function testDeposit() public { vault.deposit(100 ether); } // No DEX, oracle, etc. `
❌ Chỉ kiểm tra các đường đi thuận lợi `solidity // Bad: No error conditions tested function testWithdraw() public { vault.withdraw(50 ether); // What if paused? What if insolvent? } `
❌ Đóng gói thử nghiệm Chạy thử nghiệm để đảm bảo 100% cài đặt đường dẫn nhưng lại không có ý nghĩa gì. Một thử nghiệm không thay đổi có ý nghĩa > 100 thử nghiệm đơn giản.
❌ Không tích hợp CI Các thử nghiệm chỉ chạy trên máy tính. Nếu nó không nằm trong CI, nó không tồn tại.
Bối cảnh DeFi Việt Nam: Các yếu tố cần xem xét thực tiễn
Việt Nam có một cộng đồng nhà phát triển DeFi đang phát triển (Kyber Network, Coin98, TomoChain alumni). Các thực tế địa phương:
RPC Infrastructure: Sử dụng các điểm kết thúc NodeReal, BlockPi hoặc Chainstack Vietnam để kiểm tra fork với độ trễ thấp.
Khung cảnh kiểm toán: Văn phòng Verichains, PeckShield Việt Nam và CertiK Việt Nam hiểu rõ các dự án địa phương. Đề xuất 2-3 cuộc kiểm toán cho việc phát hành mainnet.
Chuỗi tài năng: Các trường đại học Việt Nam (HUST, UEH, FPT) hiện cung cấp các môn học lựa chọn về blockchain. Các thực tập sinh thường biết Solidity nhưng thiếu sự nghiêm ngặt trong quá trình kiểm tra – nên đầu tư vào đào tạo nội bộ.
Khu vực pháp lý không rõ ràng: Chưa có quy định rõ ràng về DeFi. Các báo cáo kiểm tra và kiểm toán nghiêm ngặt là biện pháp phòng vệ tốt nhất cho việc tuân thủ trong tương lai.
Kết luận
Kiểm tra DeFi không phải là một tùy chọn chọn – nó là một quy tắc liên tục. Hệ thống kiểm tra hình dạng tháp vẫn áp dụng, nhưng với các lớp đặc thù của DeFi:
- Test đơn vị (Foundry/Hardhat) — Đánh giá nhanh, phát hiện lỗi logic
Bắt đầu với các thử nghiệm đơn vị của Foundry ngay hôm nay. Thêm fuzzing trong tuần này. Thử nghiệm fork trước testnet. Xác minh chính thức trước mainnet với TVL đáng kể.
Chi phí của quá trình kiểm tra được đo bằng số giờ của các nhà phát triển. Chi phí của việc không kiểm tra được đo bằng số tiền của người dùng bị mất – và trong DeFi, đó là một giá mà không một quy trình nào có thể chịu đựng.
Hỏi đáp
Câu hỏi: Bao nhiêu lần fuzzing là đủ? A: Chạy 100k+ lần trong CI cho mỗi PR; 1 triệu+ cho các bản phát hành. Tỷ lệ lợi nhuận giảm dần khoảng 4-8 giờ cho hầu hết các giao thức.
Q: Tôi có thể bỏ qua xác minh chính thức cho một giao thức nhỏ không? A: Có, nhưng hãy sử dụng Scribble (miễn phí, ít công sức) cho các biến không đổi kế toán quan trọng. Để lại Certora cho các TVL > 10 triệu USD.
Q: Tôi nên tạo mock cho các giao thức bên ngoài hay fork chúng? A: Fork cho các thử nghiệm tích hợp (tính năng thực tế). Mock cho các thử nghiệm đơn vị (tốc độ, cách biệt). Sử dụng cả hai.
Câu hỏi: Kẽ hở thử nghiệm lớn nhất trong hầu hết các dự án DeFi là gì?
Câu hỏi: Tôi làm thế nào để kiểm tra các hợp đồng có thể nâng cấp? A: Kiểm tra proxy + thực hiện riêng biệt, sau đó kiểm tra quá trình nâng cấp (chuẩn bố trí bộ nhớ, khởi tạo, di chuyển).
Câu hỏi: Có các nguồn tài nguyên kiểm tra dành riêng cho Việt Nam không? A: Verichains phát hành các hướng dẫn kiểm tra bằng tiếng Việt. Coin98 dev Discord có các kênh kiểm tra. Hãy tham gia cộng đồng.
Các nguồn tài liệu khác
- Foundry Book: book.getfoundry.sh (thử nghiệm, phá lỗ hổng, chia sẻ các chương)
- Echidna GitHub: github.com/crytic/echidna
- Certora Docs: docs.certora.com
- Scribble: github.com/ConsenSys/scribble
- Trail of Bits Publications: blog.trailofbits.com (tìm kiếm "thử nghiệm", "thử nghiệm")