Solidity

什么是 Solidity？

Solidity 是一种高级编程语言，用于编写在 Ethereum 和其他支持 Ethereum Virtual Machine 的区块链网络上运行的智能合约。

官方Solidity 网站将 Solidity 描述为一种静态类型、使用花括号的编程语言，旨在开发运行于 Ethereum 的智能合约。

智能合约是存储在区块链上的程序，无需传统服务器即可持有资产、执行规则、运行逻辑并响应交易。

官方Ethereum 智能合约文档说明，智能合约是在 Ethereum 区块链上运行的程序。

在加密货币领域，Solidity 可用于构建代币、DeFi 协议、NFT 集合、DAO、质押系统、借贷市场、跨链桥、托管系统、治理合约和许多其他链上应用。

人类用户不会直接运行 Solidity 代码。

开发者编写 Solidity 源代码，然后将其编译为 Ethereum Virtual Machine 可执行的字节码。

官方Solidity 文档说明，Solidity 是一种面向对象的高级语言，用于实现智能合约。

简而言之，Solidity 是许多开发者在基于 EVM 的区块链上创建可编程加密货币应用的主要编程语言。

为什么 Solidity 在加密货币领域很重要

Solidity 很重要，因为它支持加密货币生态系统中用户交互的许多智能合约。

当用户兑换代币、铸造 NFT、参与 DAO 投票、存入抵押品、领取奖励或使用 DeFi 应用时，Solidity 智能合约可能正在处理其中部分操作。

Solidity 使可编程数字资产变得可行，因为开发者可以编写可复用的所有权、转账、权限、手续费、流动性和治理规则。

同质化资产和 NFT 等代币通常依赖于常以 Solidity 实现的智能合约标准。

官方ERC-20 代币标准定义了智能合约中同质化代币的通用接口。

官方ERC-721 代币标准定义了非同质化代币的通用接口。

官方ERC-1155 代币标准定义了多代币标准，可在一个合约系统中支持同质化和非同质化资产。

这些标准很重要，因为钱包、浏览器、应用和协议可以更容易支持通用代币行为。

Solidity 同样重要，因为智能合约错误可能影响真实用户资金。

Solidity 代码中的小错误可能导致代币损失、权限失效、错误记账、升级失败或可被利用的 DeFi 逻辑。

Solidity 如何运作

Solidity 允许开发者使用人类可读的源代码描述智能合约规则。

代码随后通过通常称为 solc 的 Solidity 编译器编译为 EVM 字节码。

官方Solidity 编译器文档说明，编译器可生成二进制文件、ABI 数据、汇编代码、Gas 估算和抽象语法树等输出。

编译后，部署字节码会在区块链交易中发送，以创建合约账户。

部署完成后，合约会拥有一个可供用户和其他合约调用的地址。

用户通常不会通过编写原始字节码调用智能合约。

他们通常通过钱包、应用、脚本或界面交互；这些工具使用合约 ABI 对函数调用进行编码。

合约接收交易数据，按照 EVM 规则执行，在允许时更新存储，若代码规定则发出事件，并返回数据或错误。

每项更改状态的操作都需要区块链交易，并由交易发送方支付手续费。

因此，Solidity 开发必须同时考虑正确性和 Gas 成本。

Solidity 与 Ethereum Virtual Machine

Ethereum Virtual Machine（EVM）是执行已编译智能合约字节码的运行时环境。

官方Solidity 智能合约简介说明，EVM 是 Ethereum 智能合约的运行时环境，并与周围系统隔离。

Solidity 旨在以 EVM 为目标，这意味着 Solidity 代码会编译为 EVM 能理解的指令。

这种设计使智能合约能在众多节点间以确定性方式执行。

确定性执行意味着，每个诚实节点在相同链状态下处理相同交易时，都应得出相同结果。

这至关重要，因为区块链需要就余额、所有权、合约存储和交易结果达成一致。

EVM 还创建了一个沙盒环境，限制合约可以执行的操作。

Solidity 合约无法直接调用任意网站、读取私有服务器数据或访问链下信息，除非这些信息通过交易或预言机系统被带到链上。

这一限制提高了确定性，但也要求开发者围绕外部数据需求谨慎设计。

因此，Solidity 不只是普通 Web 编程语言，因为它运行在具有严格规则的区块链执行模型中。

Solidity 与智能合约

Solidity 智能合约是部署后位于某个区块链地址上的代码和存储集合。

代码定义可调用哪些函数，以及这些函数执行什么操作。

存储保存长期状态，例如余额、所有者地址、配置值、映射、投票、债务、储备和代币元数据。

合约可以接收由用户控制的外部账户发送的交易。

合约还可调用其他合约，从而形成可组合的链上系统。

可组合性是 Solidity 最重要的加密货币特性之一，因为一个协议可建立在另一个协议的合约接口之上。

代币合约可被借贷协议、兑换协议、质押合约和治理系统使用。

这使 Solidity 非常强大，但也会带来风险，因为一个合约的漏洞可能影响许多相连应用。

智能合约在验证后通常具有透明性，但透明性并不自动代表安全。

用户应将每次合约交互视为带有技术和金融风险的交易。

Solidity 语法

Solidity 使用花括号、函数声明、变量、类型、结构体、映射、事件、修饰器和继承模式；熟悉 JavaScript、C++、Java 或类似语言的开发者可能会感到熟悉。

官方 Solidity 文档指出，该语言受 C++、Python 和 JavaScript 影响。

Solidity 文件通常以许可证标识符和 pragma 语句开始。

pragma 语句告知工具源文件预期使用哪些编译器版本。

合约定义随后包含状态变量、事件、错误、构造函数、函数、修饰器，有时还包括嵌套类型。

Solidity 是静态类型语言，这意味着变量和函数参数都具有声明类型。

常见类型包括 bool、uint256、int256、address、bytes、string、数组、结构体、枚举和映射。

开发者必须谨慎考虑存储、内存、calldata、可见性、可变性和访问控制。

这些细节很重要，因为 Solidity 代码控制资产，并且在部署后可能很难更改。

看似简单的语法仍可能产生复杂的链上行为。

合约

合约是 Solidity 的主要构建单元。

合约可存储数据、定义函数、发出事件、继承其他合约，并与其他合约交互。

代币合约可能存储余额和授权额度。

借贷合约可能存储抵押品、债务、利息指数和强制平仓设置。

治理合约可能存储提案、投票、法定人数规则和执行延迟。

质押合约可能存储存入资产、奖励率、提现规则和领取数据。

每个部署的合约都会在区块链上获得独立地址。

用户调用该地址以与合约函数交互。

合约代码仅在交易或调用触发时运行。

合约不像普通服务器应用那样持续运行。

状态变量

状态变量是永久存储在合约存储中的变量。

它们用于必须在多笔交易之间持续可用的数据。

例如代币余额、所有者地址、总供应量、手续费设置、协议储备、投票数和用户仓位。

存储成本高昂，因为区块链节点必须保存并验证这些数据。

开发者应避免在链上存储不必要的数据。

还应谨慎设计存储布局，尤其是可升级合约。

存储布局错误可能在升级时损坏重要合约状态。

Solidity 可通过编译器输出存储布局信息，帮助开发者和审计人员审查升级风险。

除非合约已验证或区块链浏览器提供可读调用，用户很少能直接看到状态变量。

但这些变量通常决定用户资金和权限如何被处理。

函数

函数定义 Solidity 合约可执行的操作。

函数可以读取数据、更新存储、转移代币、调用其他合约、发出事件，或在不满足条件时回退。

函数可见性控制谁能调用函数以及如何访问函数。

常见可见性关键字包括 public、external、internal 和 private。

函数可变性说明函数是读取状态还是修改状态。

常见可变性关键字包括 view、pure 和 payable。

view 函数可读取状态而不改变状态。

pure 函数不应读取或更改合约状态。

payable 函数在调用时附带 value 的情况下可以接收该链的原生资产。

函数设计很重要，因为许多智能合约漏洞源于缺失检查、错误权限、不安全外部调用或错误记账。

事件

事件是 Solidity 合约在执行期间发出的日志。

它们帮助钱包、浏览器、索引器和应用跟踪交易中发生的事情。

根据常见代币标准实现时，代币转移通常会发出 Transfer 事件。

DeFi 协议可能为充值、提现、借入、偿还、强制平仓、兑换、投票或配置变更发出事件。

事件十分有用，因为其存储成本低于完整合约存储，且易于被链下系统索引。

不过，事件不等同于合约状态。

合约只有在其代码要求时才会发出事件。

应用不应在不了解合约逻辑的情况下盲目信任事件日志。

事件非常适合透明度和数据分析，但必须结合底层代码进行解读。

对于用户，事件通常为钱包和浏览器显示的可读交易历史提供支持。

修饰器

修饰器是可改变或限制函数行为的可复用 Solidity 逻辑片段。

常见修饰器会在允许函数运行前，检查调用者是否为所有者、管理员、治理者或获授权角色。

修饰器可减少重复代码，并使访问控制更容易阅读。

但如果过度使用或编写不清晰，修饰器也可能隐藏重要逻辑。

函数表面上可能很简单，但修饰器可能在后台执行重大检查或状态变更。

开发者应保持修饰器清晰且专注。

审计人员应仔细审查修饰器，因为它们经常保护敏感函数。

审查已验证代码的用户不应只根据函数可见主体判断函数。

还应检查继承的修饰器和访问控制条件。

缺失或失效的修饰器可能造成严重安全风险。

映射

映射是一种 Solidity 合约中常用的键值数据结构。

代币余额通常存储在从地址到金额的映射中。

授权额度可存储在从所有者到被授权方再到金额的嵌套映射中。

治理系统可能使用映射跟踪某一地址是否已投票。

借贷系统可能使用映射跟踪每位用户的抵押品和债务。

映射可高效地按键查找值。

但是，映射不易直接在链上进行迭代。

当链下系统需要列出映射条目时，开发者通常使用事件或额外数据结构。

映射功能强大，但需要谨慎记账。

错误的映射更新可能导致余额错误、权限失效或资金损失。

接口

接口定义其他合约可调用的函数签名。

接口很重要，因为智能合约经常需要与其他智能合约交互。

代币接口可告知 DeFi 合约如何调用 transfer、transferFrom、approve、balanceOf 或 allowance。

预言机接口可告知借贷协议如何读取价格数据。

治理接口可让另一合约检查提案状态或投票权。

接口通过让合约依赖通用函数形式来提高可组合性。

但接口只描述预期调用和返回值。

它无法证明某个地址背后的合约行为诚实或安全。

开发者应在集成外部合约前验证相关假设。

用户应记住，合约可组合性可能将风险扩散到相连系统。

库

库是可复用的 Solidity 代码单元，可帮助开发者避免重写常见逻辑。

库可提供数学函数、地址工具、安全转移辅助函数、数组工具、字符串工具或数据结构操作。

部分库会在编译时嵌入合约字节码。

其他库可单独部署并通过地址链接。

如果库经过充分测试和广泛审查，使用库可提高代码质量。

如果库已过时、具有恶意、链接错误或使用不当，使用库也可能增加风险。

开发者应固定依赖版本并审查导入代码。

审计人员应将库作为完整代码库的一部分进行审查。

用户应理解，已验证合约可能依赖导入库和继承代码。

合约的安全性取决于影响其行为的整套代码。

继承

继承允许 Solidity 合约复用和扩展其他合约的代码。

这有利于共享所有权逻辑、代币行为、访问控制、暂停控制、升级模式和可复用模块。

谨慎使用时，继承可使代码更易组织。

当多个继承合约以复杂方式交互时，继承也可能使代码更难审查。

子合约可以重写父合约函数。

多重继承可能产生细微的顺序和重写问题。

开发者应尽可能保持继承结构简单。

审计人员应审查完整继承树，而不仅是最终合约。

阅读已验证代码的用户应检查导入的父合约，而非只看页面上显示的合约名称。

继承功能强大，但忽视隐藏的继承逻辑可能很危险。

ABI

ABI 是 Application Binary Interface 的缩写。

官方Solidity ABI 规范说明，ABI 是 Ethereum 生态系统中与合约交互的标准方式。

ABI 告知软件如何编码函数调用并解码返回值。

钱包、脚本、应用和区块链浏览器使用 ABI 显示可读的函数名称和参数字段。

没有 ABI，用户就需要处理原始 calldata，而这会更难理解。

ABI 可包含函数、事件、错误、输入、输出和类型信息。

ABI 不能证明合约安全。

它只描述如何调用合约暴露的接口。

恶意合约仍可能拥有看似干净的 ABI。

用户应将 ABI 数据视为可用性层，而非信任保证。

Solidity 编译器

Solidity 编译器，即 solc，会将 Solidity 源代码转换为 EVM 字节码和辅助构件。

Solc 还可生成 ABI 数据、元数据、Gas 估算、存储布局、警告、错误和中间输出。

精确的编译器版本和设置很重要，因为它们会影响最终字节码。

官方Solidity 0.8.35 发布公告称，0.8.35 版本引入了 erc7201 内置函数、顶级实验性标志和实验性 SSA CFG 代码生成器。

编译器版本很重要，因为 Solidity 会随着新功能、错误修复、警告和 EVM 目标变更而演进。

使用一个版本编译的合约可能无法与使用另一版本编译的相同源代码匹配。

优化器状态、优化器 runs、EVM 版本、via-IR 和库地址等编译器设置也会影响输出。

这就是已验证合约通常会显示用于匹配部署字节码的编译器版本和设置的原因。

开发者应为生产部署固定编译器版本。

用户应理解，已验证源代码依赖于编译设置匹配，而不仅是文本匹配。

字节码

字节码是 Solidity 合约编译和部署后由 EVM 执行的底层代码。

部署字节码用于创建合约。

运行时字节码是在部署后保留于合约地址上的代码。

区块链执行字节码，而不是原始 Solidity 源代码文本。

这正是源代码验证很重要的原因。

验证表明可见源代码和编译器设置能够复现已部署字节码。

官方Ethereum 智能合约验证文档说明，验证会比较源代码和编译字节码。

大多数用户难以直接阅读字节码。

已验证源代码使字节码更容易理解。

但即使字节码已验证，用户在将资金托付给合约前仍需要进行安全审查。

Gas

Gas 是衡量执行交易和智能合约操作所需计算工作量的单位。

Solidity 开发者必须关注 Gas，因为昂贵代码可能使合约使用成本高昂或不切实际。

写入存储的成本通常高于读取内存或 calldata。

遍历大型数据集的循环若需要过多 Gas，可能变得危险。

外部调用可能增加成本和安全风险。

合约部署也需要 Gas，因为字节码必须存储在链上。

Solidity 优化器有时可降低 Gas 成本或字节码大小，但必须谨慎配置和测试。

Gas 优化不应以逻辑不清晰或不安全为代价。

在加密货币领域，使用成本过高的合约可能在网络拥堵期间令用户无法操作。

良好的 Solidity 开发应平衡安全性、清晰度和效率。

Solidity 与代币

Solidity 被广泛用于创建和管理代币合约。

同质化代币合约可跟踪余额、授权额度、总供应量、转移、授权、铸造、销毁和访问控制。

NFT 合约可跟踪唯一代币 ID、所有者、授权、元数据链接和转移规则。

多代币合约可在一个合约系统中管理多种代币类型。

代币标准很重要，因为它们使钱包、浏览器和应用更容易支持代币。

ERC-20、ERC-721 和 ERC-1155 标准是 Ethereum 生态系统中最重要的应用层代币标准之一。

但是，使用 Solidity 编写或遵循标准的代币并不代表安全或有价值。

代币合约可能包含铸造权限、黑名单逻辑、手续费、暂停控制、可升级性或危险的管理员权限。

用户在信任代币前，应审查代币权限、持有者分布、流动性、供应规则和已验证源代码。

Solidity 使代币创建成为可能，但代币质量取决于设计和治理。

Solidity 与 DeFi

Solidity 是许多去中心化金融应用的核心。

DeFi 合约可管理兑换、流动性池、借贷市场、金库、衍生品、质押、收益策略和治理系统。

这些系统通常持有大量用户资产，因此 Solidity 安全性极其重要。

DeFi 协议可能因代码漏洞、预言机问题、不良记账模型、错误强制平仓规则、不安全升级或治理攻击而失败。

Solidity 允许合约相互调用，使 DeFi 具有高度可组合性。

可组合性可以创建有用的金融构建模块。

当一个协议依赖另一协议的行为时，可组合性也会带来依赖风险。

开发者应在多种市场条件和故障情景下测试集成。

用户应理解，DeFi 智能合约可以同时透明且有风险。

高收益率或高交易量不能证明 Solidity 代码安全。

Solidity 与 NFT

Solidity 常用于创建 NFT 合约，为独特数字资产定义所有权和转移规则。

NFT 智能合约可分配代币 ID、存储所有权记录、管理授权并链接元数据。

NFT 元数据通常指向图像、属性、描述或外部文件。

智能合约可能不会将所有媒体直接存储在链上，因为在链上存储大量数据的成本可能很高。

用户应检查 NFT 元数据是否在链上、是否去中心化、是否可更改，以及是否受项目方控制。

已验证的 Solidity NFT 合约可展示铸造规则、供应上限、版税行为、转移限制和管理员权限。

但许多 NFT 风险并不仅是代码风险。

NFT 风险还包括假冒集合、抄袭艺术品、流动性不足、元数据损坏、误导性承诺和市场操纵。

Solidity 提供所有权逻辑，但不保证文化价值或未来需求。

NFT 买家应结合合约审查、集合验证和流动性分析。

Solidity 与 DAO

Solidity 常用于构建 DAO 治理合约。

DAO 合约可管理提案、投票权、委托、时间锁、金库执行和角色权限。

治理合约可让代币持有者或成员对协议变更进行投票。

它们还可控制升级、金库转账、参数变更和紧急暂停等敏感操作。

DAO 合约需要谨慎设计，因为治理攻击可能影响真实资产。

设计不佳的投票系统可能容易受到低投票率、买票、闪电贷投票、巨鲸控制或仓促执行的影响。

时间锁可让用户在获批变更生效前有时间作出反应。

紧急控制可减少损害，但也会引入中心化权力。

Solidity 为 DAO 提供可编程治理工具，但治理安全取决于代码和人类协作。

用户应审查谁可以更改协议，以及变更可能以多快速度发生。

Solidity 安全风险

Solidity 安全性是加密货币开发中最重要的话题之一。

官方Solidity 安全注意事项文档涵盖重入、Gas 限制、发送和接收 ether、tx.origin、细节问题和编译器相关问题等风险。

当合约在安全更新自身状态前调用外部合约时，可能发生重入。

访问控制漏洞可能让未授权用户调用敏感函数。

整数和记账错误可能产生错误余额或失效手续费逻辑。

预言机错误可能导致错误价格和不公平的强制平仓。

升级错误可能以不安全逻辑取代安全逻辑。

未检查的外部调用可能创建意外执行路径。

签名验证错误可能允许重放攻击或伪造授权。

智能合约安全需要威胁建模、测试、审查、审计、监控和保守设计。

重入

重入是一种知名智能合约漏洞：外部调用允许另一合约在第一个合约完成状态更新前回调。

这可能允许重复提现、破坏记账或产生意外控制流。

Solidity 安全文档建议使用 Checks-Effects-Interactions 模式，作为降低重入风险的方法之一。

该模式是指合约应先检查条件，然后更新内部状态，最后才与外部合约交互。

重入保护还可包括锁、拉取付款设计和谨慎的外部调用审查。

开发者不应认为发送资产毫无风险。

外部调用可执行代码并改变控制流。

用户应谨慎对待具有未经审计提现逻辑或复杂回调路径的协议。

重入并非唯一的 Solidity 风险，但它是说明智能合约逻辑为何不同于普通软件的最重要示例之一。

如果状态更新顺序错误，看似安全的转移也可能变得危险。

访问控制

访问控制决定谁可以调用敏感的 Solidity 函数。

重要函数可能包括铸造代币、暂停转移、升级合约、更改手续费、设置预言机、提取金库资金或授予角色。

访问控制可基于所有者地址、角色、多重签名钱包、治理合约、时间锁或自定义权限系统。

薄弱的访问控制可能让攻击者或内部人员改变合约行为。

过度中心化的访问控制同样可能为用户带来信任风险。

即使合约在技术上正常运行，如果一把私钥就能抽走资金或即时修改规则，合约仍可能不安全。

开发者应遵循最小权限原则、清晰的角色分离和恢复计划来设计权限。

用户在向协议存入资金前应审查管理员权力。

在源代码可用时，已验证 Solidity 代码可披露权限逻辑。

即使不存在代码漏洞，管理员风险也是智能合约风险。

整数安全

整数运算在 Solidity 中很重要，因为合约经常处理余额、份额、价格、手续费、利息和奖励。

较早的 Solidity 版本需要开发者更谨慎地手动处理整数溢出和下溢。

Solidity 0.8.x 默认引入了检查算术，除非使用 unchecked 区块，否则大多数溢出和下溢情况都会回退。

这种安全性改进并不能消除所有数学风险。

开发者仍可能在舍入、精度、缩放因子、小数位差异、手续费顺序和份额记账方面出错。

unchecked 区块可在特定情况下提高 Gas 效率，但必须谨慎使用。

DeFi 合约常使用定点数学和代币小数位，这可能产生细微错误。

审计人员应审查数学假设和边界情况。

用户应理解，安全算术不自动代表经济机制安全。

正确公式与溢出保护同样重要。

预言机和外部数据

Solidity 合约无法自行直接访问链下数据。

官方Ethereum 预言机文档说明，预言机向智能合约提供来自外部世界的数据。

预言机可提供价格、随机性、证明数据、天气数据、体育数据、身份信息或其他链下输入。

在 DeFi 中，价格预言机尤其重要，因为它们可决定抵押品价值、强制平仓、铸造、赎回和结算。

即使 Solidity 代码编写正确，不良预言机设计也可能造成重大损失。

开发者应避免依赖流动性较弱市场中容易被操纵的现货价格。

还应考虑更新频率、备用行为、数据延迟和熔断机制。

用户在存入抵押品或借入资产前，应检查协议使用哪个预言机来源。

Solidity 可执行基于预言机的规则，但无法让不良数据变得可靠。

外部数据是许多智能合约系统中最大的信任假设之一。

可升级性

Solidity 合约常被描述为不可变，但许多项目使用升级模式在部署后更改逻辑。

可升级合约通常将代理合约与实现合约分开。

代理保留地址和存储，实现合约则包含可通过升级函数替换的逻辑。

可升级性可以修复漏洞和增加功能。

它也可能带来信任风险，因为管理员或治理方可能在用户存入资金后更改规则。

必须谨慎处理存储布局，因为错误升级可能损坏状态。

用户应检查合约是否可升级、谁控制升级、是否存在时间锁，以及升级是否会公开公告。

开发者应清晰记录升级权限。

审计人员应同时审查当前实现和升级控制机制。

可升级性很有用，但会改变 Solidity 合约的信任模型。

源代码验证

源代码验证可帮助用户确认已发布的 Solidity 源代码是否与已部署的字节码一致。

Ethereum 验证文档说明，验证会将合约源代码与合约创建期间使用的已编译字节码进行比对。

验证通常需要精确的源文件、编译器版本、编译器设置、构造函数参数、库地址和元数据配置。

已验证的源代码可提升透明度，因为用户能够阅读合约背后的逻辑。

它还可帮助钱包和区块链浏览器解码函数调用和事件。

但是，源代码验证并不等同于审计。

已验证的合约仍可能包含漏洞、不安全的管理员控制机制、升级风险或不良的经济模型设计。

未验证的合约更难获得信任，因为用户无法轻易将人类可读的代码与已部署字节码进行比较。

当网站要求用户对未验证合约进行授权或充值时，用户应保持谨慎。

验证是尽职调查的起点，而非终点。

Solidity 版本

Solidity 版本很重要，因为该语言会随时间演进。

新版本可能引入新功能、改进警告、变更默认设置、修复编译器漏洞，并支持新的 EVM 行为。

官方 Solidity 发布公告会公布编译器版本和语言变更的详细信息。

根据截至 2026 年可获取的官方发布信息，Solidity 0.8.35 是一个较新的编译器版本，包含新功能和实验性编译器特性。

生产环境项目不应随意升级编译器版本。

每次编译器升级都应进行测试，因为字节码、Gas 行为、警告和构建输出可能发生变化。

开发者在更改编译器版本前应阅读发布说明。

审计人员应审查审计构建中使用的编译器版本。

审查已验证合约的用户应检查区块链浏览器显示的编译器版本。

Solidity 版本选择是智能合约安全性和可复现性的一部分。

Solidity 编译器漏洞

编译器漏洞较为罕见，但十分重要，因为编译器会将源代码转换为实际上在链上运行的字节码。

官方 Solidity 已知漏洞文档会跟踪已知编译器漏洞及其影响的版本。

即使源代码看起来正确，合约仍可能受到编译器问题的影响。

开发者在部署生产环境合约前应检查已知编译器漏洞。

审计人员应在流程中纳入编译器版本审查。

当合约在没有明确理由的情况下使用非常旧的编译器版本时，用户应保持谨慎。

并非每个旧编译器版本都会自动变得不安全，但旧版本可能缺少较新的检查和修复。

智能合约团队应将编译器视为其可信软件供应链的一部分。

可复现构建和已记录的编译器设置有助于识别已知漏洞是否可能适用。

编译器风险也是应保留部署产物的另一个原因。

Solidity 开发工具

Solidity 开发者通常会使用工具编写、编译、测试、部署、验证和监控合约。

官方 Remix IDE 是一个基于浏览器的环境，常用于学习、编写、编译和测试 Solidity 合约。

命令行框架和本地开发环境可以自动执行编译、测试、部署、分叉测试和验证。

静态分析工具可以扫描 Solidity 代码中的常见漏洞和高风险模式。

模糊测试工具可以生成大量输入，以发现意外行为。

形式化验证工具可以在既定假设下证明特定属性。

没有任何单一工具能够保证安全。

专业 Solidity 开发通常会结合单元测试、集成测试、模糊测试、代码审查、审计、部署脚本、监控和事件响应规划。

初学者应从小型合约和测试网络开始，再接触真实资金。

高级团队应使用可复现的构建流水线和严格的发布控制。

测试 Solidity 合约

测试至关重要，因为已部署的智能合约可能控制高价值资产。

单元测试用于检查单个函数和预期行为。

集成测试用于检查多个合约如何协同工作。

分叉测试会基于复制到本地环境的真实链上状态模拟合约行为。

模糊测试会尝试大量随机或结构化输入，以发现边界情况。

不变量测试会检查重要规则能否在多种操作下始终成立。

测试应涵盖正常流程、失败流程、权限检查、边界情况和恶意用户场景。

开发者应测试真实的代币小数位、异常代币行为、高数值、零值和边界条件。

测试无法证明所有可能行为都安全，但能大幅减少可避免的错误。

未经测试的 Solidity 代码不应被托付以大量资金。

审计

智能合约审计是由专家进行的安全审查，涵盖 Solidity 代码、架构、权限、测试和风险假设。

审计可以发现漏洞、设计缺陷、访问控制问题、经济风险、升级问题和文档缺口。

审计并不保证合约安全。

它是一项降低风险的流程，而非完美的防护盾。

审计质量取决于审计范围、时间、审计人员技能、测试覆盖率、文档质量以及团队如何修复发现的问题。

用户应查看审计发现的问题是否已解决或被接受。

用户还应检查已部署合约是否与经审计的提交版本和编译器设置一致。

项目即使已接受审计，之后仍可能部署未经审计的升级。

审计与公开验证、漏洞赏金、监控和保守的上线限额结合使用时最有价值。

管理大量价值的 Solidity 合约应在主网上线前接受严肃审查。

Solidity 与钱包交互

钱包可帮助用户签署调用 Solidity 合约的交易。

钱包可能显示合约地址、函数名称、参数、资产授权、Gas 费和警告信息。

钱包并不总能判断合约是否安全。

一些恶意网站可能诱导用户签署危险交易，以有害方式调用真实 Solidity 函数。

代币授权尤其重要，因为授权可能允许合约从钱包中支出指定额度以内的代币。

用户在签署前应审查授权额度和合约地址。

用户应避免签署自己不了解的交易。

当界面隐藏 calldata 或要求无限授权时，用户应保持谨慎。

Solidity 支持可编程交互，但用户仍通过钱包控制签名。

交易签名可能永久转移资金或授予权限。

Solidity 与代币授权

代币授权是一种常见的 Solidity 模式，允许一个地址代表另一个地址支出代币。

在 ERC-20 风格代币中，approve 用于设置额度，transferFrom 则使用该额度。

这种设计使 DeFi 兑换、充值、支付和自动化操作成为可能。

但它也会带来风险，因为恶意或已被攻破的支出方可以在获批额度内转移代币。

无限授权虽然方便，但会扩大风险敞口。

在可行情况下，用户应仅授权所需额度。

用户应通过可信的钱包或安全工具撤销未使用的授权。

开发者应设计能够清晰说明授权内容的界面。

审计人员应检查额度处理中的竞态条件、缺失检查和不安全假设。

授权是普通用户接触 Solidity 风险的最常见方式之一。

Solidity 与形式化验证

形式化验证使用数学方法证明所选合约属性在既定假设下成立。

这对于高价值系统、金融协议、跨链桥、治理模块和核心记账逻辑可能很有用。

某项属性可能规定总供应量永远不超过某一上限，或用户无法提取超过其余额的资金。

形式化验证不能取代测试和审计。

它只能证明实际被指定的属性。

如果规范不完整或有误，证明可能遗漏真实世界的风险。

形式化方法可能成本较高，并需要专业知识。

当其应用于规则明确的关键逻辑时，效果最为强大。

对于 Solidity 而言，形式化验证是成熟安全流程的一部分。

当合约故障可能造成重大损失时，它尤其有用。

Solidity 的优势

Solidity 的第一项优势是生态采用度。

许多智能合约工具、教程、审计、标准、库和开发者社区都支持 Solidity。

第二项优势是 EVM 兼容性。

当网络规则和部署设置兼容时，Solidity 合约可面向 Ethereum 及其他支持 EVM 的环境。

第三项优势是可组合性。

Solidity 合约可以调用其他合约，并基于现有代币标准和协议接口构建。

第四项优势是表达能力。

开发者可以构建代币、DeFi 系统、DAO、游戏、NFT 和自动化金融逻辑。

第五项优势是透明度，因为用户和审计人员可以阅读和审查已验证的 Solidity 源代码。

这些优势解释了 Solidity 为何仍是加密货币领域最重要的智能合约语言之一。

Solidity 的风险与局限性

第一项风险是，漏洞在部署后可能代价高昂且难以修复。

第二项风险是，任何发现弱点的用户都可能利用智能合约逻辑。

第三项风险是，Solidity 合约经常与其他合约交互，从而产生依赖风险。

第四项风险是，Gas 成本可能使某些设计不具实用性。

第五项风险是，可升级性可能带来管理员或治理信任风险。

第六项风险是，已验证的源代码仍可能具有恶意性或设计不佳。

第七项风险是，开发者可能误解 EVM 行为、存储布局、重入或外部调用。

第八项风险是，用户可能在不了解 Solidity 合约将如何执行的情况下签署有害交易。

第九项风险是，即使语法正确，预言机和经济模型设计问题仍可能导致协议失效。

第十项风险是，编译器设置和依赖版本可能改变最终部署的字节码。

Solidity 中的常见错误

一个常见错误是编写无法保护敏感函数的访问控制。

另一个错误是在安全更新内部状态之前进行外部调用。

第三个错误是信任 tx.origin 进行授权，而 Solidity 安全文档对此提出警告。

第四个错误是在计算中忽略代币小数位和精度问题。

第五个错误是假设每种 ERC-20 风格代币的行为都完全相同。

第六个错误是在未保留存储布局的情况下使用可升级合约。

第七个错误是使用与审计构建不同的编译器设置进行部署。

第八个错误是忽略编译器警告。

第九个错误是赋予一个管理员密钥过大的权限。

第十个错误是在测试边界情况和失败场景前就上线合约。

如何评估 Solidity 合约

首先检查合约源代码是否已经验证。

然后检查编译器版本、优化器设置、构造函数参数和已链接库。

审查合约是否可升级，以及谁控制升级。

检查管理员角色、所有者权限、多重签名控制、时间锁和紧急功能。

评估代币合约时，应审查代币铸造、销毁、暂停、黑名单、手续费和转账限制。

评估 DeFi 合约时，应审查预言机来源、抵押品规则、强制平仓逻辑和记账机制。

检查是否存在审计，以及审计发现的问题是否已经修复。

将已部署合约地址与项目官方来源进行比对。

审查近期交易和事件，了解合约的使用方式。

应从代码、基础设施、治理和经济模型设计等方面综合评估 Solidity 合约。

开发者最佳实践

在阅读发布说明并测试行为后，使用较新的稳定 Solidity 编译器版本。

为生产构建固定编译器版本和依赖版本。

将编译器警告视为需要审查的事项，而非无害噪音。

使用清晰的访问控制和最小权限原则。

在适用情况下，遵循 Checks-Effects-Interactions 等安全外部调用模式。

为正常路径、失败路径、边界情况和恶意用户行为编写测试。

对于管理大量价值的合约，使用静态分析、模糊测试和审计。

记录管理员权限、升级权限、预言机假设和紧急控制机制。

部署后使用精确的编译器设置验证源代码。

监控已部署合约，并在上线前准备事件响应计划。

用户最佳实践

与合约交互前，检查合约是否已经验证。

应将合约地址与项目官方来源进行比较，而不是信任随机消息中的链接。

签署交易前审查代币授权。

对无限授权保持谨慎，并在可行时撤销未使用权限。

检查合约是否可升级，以及谁控制升级。

不要认为已验证合约就一定经过审计或安全。

不要向自己无法理解或无法独立信任的合约存入资金。

对于高价值交互，使用硬件钱包或强大的钱包安全措施。

对新的、未经审计的、高收益或匿名的 Solidity 合约保持谨慎。

请记住，区块链交易一经确认，通常不可逆转。

常见问题

Solidity 用于什么？

Solidity 用于为 Ethereum 及其他兼容 EVM 的区块链环境编写智能合约。

Solidity 是一种加密货币吗？

不是，Solidity 是一种编程语言，不是加密货币或代币。

Solidity 仅用于 Ethereum 吗？

Solidity 为 Ethereum 设计，但也用于支持 Ethereum Virtual Machine 或兼容执行环境的其他区块链网络。

什么是 Solidity 智能合约？

Solidity 智能合约是定义数据存储、交易处理、资产管理以及与用户或其他合约交互规则的区块链代码。

什么是 Solidity 编译器？

Solidity 编译器称为 solc，可将 Solidity 源代码转换为 EVM 字节码、ABI 数据、元数据和其他构建输出。

Solidity 中的 ABI 是什么？

ABI 是应用二进制接口（Application Binary Interface），用于告知钱包、应用和脚本如何调用合约函数并解码其响应。

Solidity 安全吗？

Solidity 可以被安全地使用，但智能合约安全性取决于安全设计、测试、审计、编译器设置、访问控制和谨慎部署。

Solidity 合约部署后可以更改吗？

基础已部署合约通常不可变，但如果存在升级权限，可升级代理模式可以允许合约逻辑发生变化。

为什么 Solidity 合约需要审计？

Solidity 合约通常控制高价值资产，因此审计有助于在部署前或部署后发现漏洞、权限问题、经济模型缺陷和不安全假设。

用户如何检查 Solidity 合约？

用户可以检查源代码验证、编译器设置、合约地址、审计、管理员权限、可升级性、代币授权、交易历史和项目官方文档。

结论

Solidity 是加密货币生态中最重要的编程语言之一，因为它支持为代币、DeFi、NFT、DAO、质押系统及许多其他链上应用构建智能合约。

它允许开发者编写人类可读的规则，并将其编译为由区块链节点执行的 EVM 字节码。

Solidity 的优势来自其庞大生态、智能合约标准、可组合性、工具链和广泛的 EVM 支持。

其风险在于已部署代码可以控制真实资产，且在部署后可能难以修复。

良好的 Solidity 开发需要谨慎的编译器设置、测试、审计、访问控制、升级规划、Gas 意识和安全审查。

良好的 Solidity 使用习惯要求用户验证合约地址、阅读权限内容、管理授权、检查审计情况，并避免未知或未验证的合约。

对于初学者，Solidity 最适合被理解为开发者用来编写区块链程序的语言。

对于高级用户，Solidity 是一种智能合约语言，其安全性取决于代码质量、EVM 行为、编译器配置、外部依赖、治理和经济模型设计。

在加密货币术语表语境中，Solidity 是指用于构建和部署在 Ethereum 风格区块链环境中执行的智能合约的主要高级语言。

核心要点是，Solidity 使可编程加密货币成为可能，但每个 Solidity 合约都应被视为需要验证、安全审查和用户谨慎判断的高风险软件。