Back to Details

algo-blockchain-smart-contract

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Smart Contracts

智能合约

Overview

概述

Smart contracts are self-executing programs stored on a blockchain that automatically enforce agreement terms when conditions are met. Primarily written in Solidity (Ethereum/EVM) or Rust (Solana). Once deployed, code is immutable — bugs cannot be patched without migration. Security is critical as exploits are irreversible.
智能合约是存储在区块链上的自动执行程序，当满足预设条件时会自动执行协议条款。主要使用Solidity（以太坊/EVM兼容链）或Rust（Solana）编写。一旦部署，代码将不可变——除非进行迁移，否则无法修复漏洞。安全性至关重要，因为漏洞利用是不可逆的。

When to Use

适用场景

Trigger conditions:
  • Automating multi-party agreements that execute without intermediaries
  • Building token-based systems (NFTs, DeFi, governance)
  • Creating transparent, auditable business logic on-chain
When NOT to use:
  • For simple CRUD operations (use a database)
  • When business logic changes frequently (immutability makes updates costly)
  • When off-chain data is the primary input (oracle dependency is risky)
触发条件：
  • 自动化无需中介参与的多方协议执行
  • 构建基于代币的系统（NFT、DeFi、治理机制）
  • 在链上创建透明、可审计的业务逻辑
不适用场景：
  • 简单的CRUD操作（使用数据库即可）
  • 业务逻辑需要频繁变更的场景（不可变性会导致更新成本极高）
  • 主要依赖链下数据作为输入的场景（预言机依赖存在风险）

Algorithm

算法

IRON LAW: Deployed Smart Contracts Are IMMUTABLE — Bugs Are Permanent
Once deployed, contract code cannot be changed. A bug that loses funds
is IRREVERSIBLE. There is no "hotfix" or "rollback" (unless the
contract includes an upgrade proxy pattern). Security audit BEFORE
deployment is not optional — it is the only protection.
铁律：已部署的智能合约具有不可变性——漏洞将永久存在
一旦部署，合约代码无法修改。导致资金损失的漏洞是不可逆的。不存在“热修复”或“回滚”操作（除非合约包含升级代理模式）。部署前的安全审计不是可选步骤——这是唯一的防护手段。

Phase 1: Input Validation

阶段1：输入验证

Define: contract purpose, participants, conditions, state variables, access controls. Determine: which logic MUST be on-chain vs which can be off-chain. Gate: Business logic specified, on-chain necessity justified.
定义：合约用途、参与方、触发条件、状态变量、访问控制规则。确定：哪些逻辑必须部署在链上，哪些可以放在链下。 准入门槛： 明确业务逻辑，证明链上部署的必要性。

Phase 2: Core Algorithm

阶段2：核心算法设计

Design:
  1. Define state variables (stored on-chain, costs gas)
  2. Define functions: external (callable by users), internal (helper logic)
  3. Implement access control (onlyOwner, role-based, multisig)
  4. Handle edge cases: reentrancy guards, integer overflow checks, gas limits
Security patterns:
  • Checks-Effects-Interactions (prevent reentrancy)
  • Pull over push (for payments)
  • Minimal on-chain data (store hashes, not full data)
  • Upgradeable proxy pattern (if mutability needed)
设计步骤：
  1. 定义状态变量（存储在链上，会消耗Gas）
  2. 定义函数：外部函数（可由用户调用）、内部函数（辅助逻辑）
  3. 实现访问控制（仅所有者、基于角色、多签机制）
  4. 处理边缘情况：重入防护、整数溢出检查、Gas限制
安全模式：
  • 检查-效应-交互模式（防止重入攻击）
  • 拉取式支付替代推送式支付
  • 最小化链上数据存储（存储哈希而非完整数据）
  • 可升级代理模式（若需要可变性）

Phase 3: Verification

阶段3：验证

Test: unit tests covering all paths, edge cases, access control violations. Security audit: automated (Slither, Mythril) + manual review. Deploy to testnet first. Gate: All tests pass, automated security scan clean, testnet deployment successful.
测试：覆盖所有路径、边缘情况、访问控制违规场景的单元测试。安全审计：自动化工具（Slither、Mythril）+ 人工审核。先部署到测试网。 准入门槛： 所有测试通过、自动化安全扫描无问题、测试网部署成功。

Phase 4: Output

阶段4：输出

Return contract design with security analysis.
返回包含安全分析的合约设计方案。

Output Format

输出格式

json
{
  "contract": {"name": "Escrow", "functions": 5, "state_variables": 4, "access_roles": ["buyer", "seller", "arbiter"]},
  "security": {"audit_status": "passed", "patterns_used": ["checks_effects_interactions", "pull_payment"], "known_risks": ["oracle_dependency"]},
  "metadata": {"platform": "ethereum", "language": "solidity", "estimated_gas": 250000}
}
json
{
  "contract": {"name": "Escrow", "functions": 5, "state_variables": 4, "access_roles": ["buyer", "seller", "arbiter"]},
  "security": {"audit_status": "passed", "patterns_used": ["checks_effects_interactions", "pull_payment"], "known_risks": ["oracle_dependency"]},
  "metadata": {"platform": "ethereum", "language": "solidity", "estimated_gas": 250000}
}

Examples

示例

Sample I/O

输入输出样例

Input: Escrow contract: buyer deposits, seller delivers, arbiter resolves disputes Expected: Contract with: deposit(), confirmDelivery(), dispute(), withdraw() functions. Funds held until conditions met.
输入： 托管合约：买家存入资金，卖家交付商品，仲裁员解决纠纷 预期输出： 包含deposit()、confirmDelivery()、dispute()、withdraw()函数的合约。资金将被托管直至满足条件。

Edge Cases

边缘情况

InputExpectedWhy
Gas price spikeTransaction may fail or cost moreAlways set gas limits and handle failures
Reentrant callMust be blockedReentrancy is the #1 smart contract vulnerability
Contract upgrade neededUse proxy pattern or migrateImmutability by default
输入预期处理原因
Gas价格飙升交易可能失败或成本增加始终设置Gas限制并处理失败场景
重入调用必须被阻止重入是智能合约排名第一的漏洞
需要升级合约使用代理模式或进行迁移默认情况下合约具有不可变性

Gotchas

注意事项

  • Reentrancy attacks: The DAO hack ($60M) exploited reentrancy. Always use the Checks-Effects-Interactions pattern and/or ReentrancyGuard.
  • Integer overflow/underflow: Solidity 0.8+ has built-in overflow checks. Earlier versions require SafeMath library. Never assume arithmetic is safe.
  • Front-running: Miners/validators can see pending transactions and insert their own first (MEV). Sensitive operations need commit-reveal schemes.
  • Gas optimization: Every operation costs gas. Minimize storage writes (most expensive), use events for data that doesn't need on-chain querying, pack variables.
  • Upgradeability vs immutability: Proxy patterns allow upgrades but add complexity and trust assumptions (who can upgrade?). Choose based on trust model.
  • Oracle dependency: Smart contracts can't access off-chain data directly. Oracles (Chainlink, etc.) introduce trust assumptions. A compromised oracle compromises the contract.
  • 重入攻击： The DAO黑客事件（损失6000万美元）就是利用了重入漏洞。始终使用检查-效应-交互模式和/或ReentrancyGuard。
  • 整数溢出/下溢： Solidity 0.8及以上版本内置了溢出检查。早期版本需要使用SafeMath库。永远不要假设算术运算都是安全的。
  • 抢先交易（Front-running）： 矿工/验证者可以看到待处理交易，并插入自己的交易抢先执行（MEV）。敏感操作需要使用提交-揭示方案。
  • Gas优化： 每一项操作都会消耗Gas。尽量减少存储写入（成本最高），使用事件存储无需链上查询的数据，对变量进行打包存储。
  • 可升级性vs不可变性： 代理模式允许合约升级，但会增加复杂度和信任假设（谁拥有升级权限？）。需根据信任模型进行选择。
  • 预言机依赖： 智能合约无法直接访问链下数据。预言机（如Chainlink等）会引入信任假设。一旦预言机被攻破，合约也会受到影响。

References

参考资料

  • For common vulnerability patterns, see 
    references/vulnerability-patterns.md
  • For gas optimization techniques, see 
    references/gas-optimization.md
  • 常见漏洞模式，请参阅
    references/vulnerability-patterns.md
  • Gas优化技巧，请参阅
    references/gas-optimization.md