智能合约开辟中13种最常见的毛病

发表于 2025-10-11 23:06:12

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要登录才可以下载或查看，没有账号？立即注册

×

在智能合约开辟过程中，确实存在多种范例的毛病，这些毛病大概导致资金丧失、合约功能失效或被恶意利用。以下是智能合约开辟中常见的毛病范例：

1.重入攻击
2.整数溢出和下溢
3.未授权访问
4.不妥的继续次序
5.短地点攻击
6.断言失败
7.署理模式中的初始化毛病
8.时间依赖性毛病
9.Gas限定和DoS攻击
10.权限管理不妥
11.外部调用
12.随机数天生
13.存储和盘算服从

1. 重入攻击：

攻击者利用合约在实行过程中的未锁定状态，通过递归调用合约中的函数，重复提取资金或资源。
示例

我们将利用以太坊的智能合约语言 Solidity 来创建一个简单的捐赠合约，然后展示一个潜伏的重入攻击合约。起首，我们创建一个吸收捐赠的合约，这个合约有一个余额，而且允许用户提款。这个合约的代码大概看起来像如许

pragma solidity ^0.8.0;
contract VulnerableDonation {
mapping (address => uint) public balances;
address payable public owner;
constructor() {
owner = payable(msg.sender);
}
function donate() public payable {
// 接收捐赠
balances[msg.sender] += msg.value;
}
function withdraw(uint _amount) public {
require(balances[msg.sender] >= _amount, "Insufficient balance");
// 这里应该先减少余额，再转账，但是顺序颠倒了
msg.sender.transfer(_amount);
balances[msg.sender] -= _amount;
}
}

复制代码

留意这里的题目是在 withdraw 函数中，我们起首实验向用户转账，然后才镌汰他们的余额。这是不安全的，由于转账利用会触发吸收方的 receive 或 fallback 函数，这给攻击者提供了时机来调用 withdraw 函数再次提款。
现在让我们创建一个攻击者合约，它可以利用这个毛病：

pragma solidity ^0.8.0;
contract Attacker {
VulnerableDonation donationContract;
constructor(address _donationAddress) {
donationContract = VulnerableDonation(_donationAddress);
}
fallback() external payable {
if (address(this).balance > 0) {
// 递归调用 withdraw 函数，只要还有余额就继续提款
donationContract.withdraw(address(this).balance);
}
}
function attack() public payable {
// 第一次调用 donate 函数向捐赠合约存入资金
donationContract.donate{value: msg.value}();
// 然后立即调用 withdraw 函数开始重入攻击
donationContract.withdraw(address(this).balance);
}
}

复制代码

在攻击者合约中，fallback 函数会在吸收到资金时自动触发，假如合约中尚有余额，它会递归地调用捐赠合约的 withdraw 函数，试图尽大概多地提款，直到没有剩余的资金可以转移为止。
为了确保合约的安全，准确的做法是在转账前镌汰用户的余额，这可以通过简单地调解 withdraw 函数的次序来实现：

function withdraw(uint _amount) public {
require(balances[msg.sender] >= _amount, "Insufficient balance");
balances[msg.sender] -= _amount;
// 转账应该在更新状态变量之后
msg.sender.transfer(_amount);
}

复制代码

如许，纵然攻击者实验在转账之前再次调用withdraw 函数，他们也会发现自己的余额已经被更新，从而无法再次提款。
2. 整数溢出和下溢：

当数学运算的效果超出整数范例所能表现的范围时，会导致数值错误地回绕，这可以被攻击者利用来获取额外的代币或资源。
溢出示例

假设我们有一个智能合约，它吸收用户存款并存储在一个变量中。假如用户实验存入的金额加上现有的余额超出了整数的最大值（在Solidity中，uint256范例的最大值是2^256-1），就会发生溢出。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract OverflowExample {
uint256 public balance;
function deposit(uint256 amount) public {
balance += amount;
}
function getBalance() public view returns (uint256) {
return balance;
}
}

复制代码

测试溢出

为了测试溢出，我们假设balance已经是uint256范例的最大值，再实验存入任何正数，都将导致溢出，即效果将从最大值回绕到0。

// 假设balance已经是uint256的最大值
uint256 maxUint256 = type(uint256).max;
balance = maxUint256;
// 尝试存入任何正数都会导致溢出
deposit(1);
// 此时，balance将变为0

复制代码

下溢示例

下溢通常发生在减法利用中，假如从一个较小的数中减去一个较大的数，效果将低于最小整数值（对于无符号整数，最小值是0），从而导致下溢。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract UnderflowExample {
uint256 public balance;
function withdraw(uint256 amount) public {
balance -= amount;
}
function getBalance() public view returns (uint256) {
return balance;
}
}

复制代码

测试下溢

在无符号整数中，下溢现实上会导致值从0回绕到最大值，但这通常不是预期的活动，因此仍然被视为错误。

// 假设balance为0
balance = 0;
// 尝试取出任何正数都会导致下溢
withdraw(1);
// 此时，balance将变成uint256的最大值

复制代码

办理方案

为了制止整数溢出和下溢，Solidity提供了安全数学库SafeMath，它包罗了查抄溢出和下溢的整数运算函数。自Solidity 0.8.0起，安全数学利用符checkedAdd, checkedSub, checkedMul, 和 checkedDiv被引入，可以自动检测并抛出非常。

using SafeMath for uint256;
function deposit(uint256 amount) public {
balance = balance.checkedAdd(amount);
}
function withdraw(uint256 amount) public {
balance = balance.checkedSub(amount);
}

复制代码

如许，假如检测到溢出或下溢，Solidity将自动抛出非常，克制交易业务实行，从而掩护合约免受此类错误的影响。
3. 未授权访问：

假如智能合约对关键函数的访问控制不敷，攻击者大概实行不应允许的利用，如修改合约状态或提取资金。
未授权访问示例

假设我们有一个智能合约，用于管理用户的存款和提款。在这个例子中，合约没有准确地限定谁可以调用withdraw函数。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract SimpleBank {
mapping(address => uint256) public balances;
function deposit() public payable {
balances[msg.sender] += msg.value;
}
// 缺乏访问控制，任何人都可以调用这个函数
function withdraw(uint256 amount) public {
require(balances[msg.sender] >= amount, "Insufficient balance");
payable(msg.sender).transfer(amount);
balances[msg.sender] -= amount;
}
}

复制代码

在这个合约中，withdraw函数可以直接被任何地点调用，只要该地点有充足余额即可。但是，假如合约中存在一些逻辑错误大概状态紊乱，这大概导致资金被非法提取。
攻击者活动

攻击者可以通过调用withdraw函数，纵然他们没有充足的余额，也大概由于某些合约状态的错误而乐成提取资金。比如，假如合约中的某个地方错误地增长了攻击者的余额，攻击者就可以利用这一点来提取不属于他们的资金。
办理方案

为相识决未授权访问的题目，我们必要在函数前添加访问修饰符，确保只有特定的脚色或地点可以调用withdraw函数。这里我们利用一个简单的onlyOwner修饰符来限定对合约全部者的调用。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract SecureBank {
address private owner;
mapping(address => uint256) public balances;
constructor() {
owner = msg.sender;
}
modifier onlyOwner() {
require(msg.sender == owner, "Only the contract owner can call this function");
_;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
// 使用onlyOwner修饰符限制对所有者的调用
function withdraw(uint256 amount) public onlyOwner {
require(balances[msg.sender] >= amount, "Insufficient balance");
payable(msg.sender).transfer(amount);
balances[msg.sender] -= amount;
}
}

复制代码

现在，只有合约的创建者（即owner）可以调用withdraw函数。这防止了未授权的用户直接提取资金，进步了合约的安全性。
留意，这种简单的访问控制机制大概不敷以应对复杂的场景，你大概必要更复杂的脚色和权限体系，比如利用OpenZeppelin的Ownable和AccessControl库来提供更细粒度的访问控制。
4. 不妥的继续次序：

在智能合约开辟中，不妥的继续次序大概会导致料想之外的活动，尤其是在处置处罚权限控制和函数覆盖时。当一个合约从多个父合约继续时，构造函数的实行次序和函数的覆盖规则变得尤为紧张。
不妥继续次序示例

假设我们有两个合约ParentA和ParentB，以及一个从这两个合约继续的子合约Child。ParentA合约包罗了一个构造函数和一个函数setOwner，而ParentB也界说了一个setOwner函数，但其功能差别。我们的目的是让Child合约可以或许调用ParentA的setOwner函数，但不妥的继续次序会导致调用的是ParentB的版本

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract ParentA {
address public owner;
constructor() {
owner = msg.sender;
}
function setOwner(address newOwner) public {
owner = newOwner;
}
}
contract ParentB {
function setOwner(address newOwner) public {
// 这里的实现与ParentA不同，但我们不关心具体细节
}
}
// 不当的继承顺序
contract Child is ParentB, ParentA {
// ...
}

复制代码

在上述代码中，Child合约继续了ParentB和ParentA。然而，在Solidity中，假如两个父合约界说了同名函数，则继续的次序决定了哪个函数会被优先覆盖。因此，在Child合约中，setOwner函数现实上是ParentB的版本，而不是我们渴望的ParentA的版本。
办理方案

要办理这个题目，我们必要调解继续次序，确保Child合约可以或许调用准确的setOwner函数。同时，为了明确指出我们想要调用哪个父合约的函数，我们可以利用Solidity提供的super关键字。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract ParentA {
address public owner;
constructor() {
owner = msg.sender;
}
function setOwnerA(address newOwner) public {
owner = newOwner;
}
}
contract ParentB {
function setOwnerB(address newOwner) public {
// 这里的实现与ParentA不同
}
}
// 正确的继承顺序
contract Child is ParentA, ParentB {
// 调用ParentA的setOwner函数
function setOwner(address newOwner) public {
ParentA.setOwnerA(newOwner); // 明确调用ParentA的setOwnerA
}
}

复制代码

在这个修改后的版本中，Child合约起首继续自ParentA，这意味着ParentA的函数和状态变量会先于ParentB的被初始化。别的，我们重定名了ParentA和ParentB中的setOwner函数以制止定名辩论，并在Child合约中界说了一个新的setOwner函数，它明确调用了ParentA中的setOwnerA函数。
通过这种方式，我们确保了Child合约中的setOwner函数调用的是ParentA的版本，制止了因继续次序不妥导致的函数覆盖题目。
5. 短地点攻击（Short Address Attack）：

短地点攻击（Short Address Attack）在以太坊中是挑拨用以太坊地点的十六进制格式（40个字符，即20字节）和某些智能合约对地点参数处置处罚不妥的毛病，来实行恶意利用的一种攻击本事。这种攻击重要出现在智能合约没有准确验证地点参数长度的情况下，只管现实的以太坊地点长度固定，但攻击者大概实验转达较短的地点字符串，试图诱骗合约实行非预期的功能。
在Solidity中，address范例的变量总是占用20字节，因此直接转达短地点不会导致题目，由于Solidity会自动将其添补至20字节。然而，某些合约大概从外部调用吸收数据，假如这些数据被错误地表明为地点，且合约没有准确处置处罚或验证这些数据，就大概发生短地点攻击。
示例，展示了短地点攻击的潜伏风险：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract VulnerableContract {
address public owner;
constructor() {
owner = msg.sender;
}
// 错误地尝试将任意数据解析为地址
function setAddress(bytes data) public {
// 注意：这里使用了一个不安全的方法将数据解析为地址
// 实际上，如果data的长度小于20字节，这将产生一个无效的地址
assembly {
owner := mload(add(data, 0x14)) // 加载20字节的数据并赋值给owner
}
}
function getOwner() public view returns (address) {
return owner;
}
}

复制代码

在这个示例中，VulnerableContract有一个公开的setAddress函数，它担当一个bytes范例的参数data，并实验在低级别汇编中将其分析为一个地点，然后设置为合约的owner。假如攻击者转达的数据长度不敷20字节，Solidity会自动添补剩余的字节为0，这大概会导致一个无效的地点被设置为owner。
攻击过程

假设攻击者构造了长度小于20字节的数据（比方，仅包罗10字节的有用负载），并调用setAddress函数。固然Solidity会自动将不敷的部门添补为0，但假如合约没有准确地验证和处置处罚这种情况，那么owner大概会被设置为一个非预期的地点，大概是一个无效的地点或一个由攻击者控制的地点。
防御步伐

为了防御短地点攻击，智能合约开辟应当：

1、验证数据长度：确保全部吸收的地点数据都是完备的20字节。
2、利用范例安全的函数：制止直接利用低级汇编语句处置处罚数据，而是利用范例安全的Solidity函数。
3、单元测试：举行细致的单元测试，包罗边界条件和非常情况，确保合约在各种输入下都能正常工作。
4、在现实开辟中，应制止直接在低级汇编中利用地点，而是利用Solidity提供的安全函数和范例查抄来处置处罚地点数据。

6. 断言失败：

断言（assert）在智能合约中用于确保内部逻辑的同等性和准确性，但假如利用不妥，确实大概导致不测的合约停止或资金锁定。这是由于assert重要用于检测步调内部的错误，比方算法错误或逻辑错误，它假定这些错误在正常运行时不会发生。一旦assert失败，交易业务将被立即回滚，且不退还gas费用，这对于合约的用户来说大概是劫难性的，特别是假如这导致了合约的关键功能无法利用。
下面是一个不妥利用assert的例子，这大概导致资金锁定：
不妥利用assert的示例

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract WithdrawalContract {
address payable public owner;
uint256 public balance;
constructor() {
owner = payable(msg.sender);
balance = 0;
}
receive() external payable {
balance += msg.value;
}
function withdraw(uint256 amount) public {
assert(msg.sender == owner); // 确保只有合约所有者可以提取资金
require(balance >= amount, "Insufficient funds"); // 确保有足够的余额
balance -= amount;
owner.transfer(amount); // 向所有者转移资金
}
}

复制代码

在这个合约中，assert(msg.sender == owner)用于确保只有合约全部者才气调用withdraw函数。然而，假如在合约摆设后owner地点被不测地设置为一个无效地点（比方，一个没有私钥的地点），那么assert将永世失败，资金将永世锁定在合约中，由于没有人可以调用withdraw函数来提取资金。
办理方案

为了制止资金锁定的风险，可以思量以下几种改进计谋：

1、利用require代替assert：对于用户输入或预条件查抄，利用require更为符合，由于它明确表现这是对外部条件的查抄，而非内部逻辑错误。
2、添加告急撤资功能：筹划一个允许在告急情况下提取资金的机制，比方，假如owner地点被锁定，可以有一个多重署名的“董事会”来决定怎样解锁资金。
3、确保合约全部者的可变动性：允许合约全部者更改，以防原始全部者丢失私钥或地点被锁定。

办理方案示例：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract ImprovedWithdrawalContract {
address payable public owner;
uint256 public balance;
constructor() {
owner = payable(msg.sender);
}
receive() external payable {
balance += msg.value;
}
modifier onlyOwner() {
require(msg.sender == owner, "Only the contract owner can call this function");
_;
}
function withdraw(uint256 amount) public onlyOwner {
require(balance >= amount, "Insufficient funds");
balance -= amount;
owner.transfer(amount);
}
// 添加一个功能，允许更改所有者
function changeOwner(address payable newOwner) public onlyOwner {
owner = newOwner;
}
}

复制代码

在这个改进后的合约中，我们利用了require来查抄条件，并添加了一个changeOwner函数，允许当前全部者在须要时更改全部者地点，从而制止资金永世锁定的风险。
7. 合约署理毛病

署理模式在智能合约开辟中非常常见，尤其是在升级和模块化筹划中。署理合约（Proxy Contract）通常用于分离逻辑实现与合约的外部接口，允许在不改变接口的情况下升级或更换底层实现。然而，假如署理合约的初始化过程没有得到妥善处置处罚，就大概成为攻击的入口。
示例：署理合约初始化毛病

假设我们有如下的署理合约模板，此中implementation变量指向现实实行逻辑的合约地点：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Proxy {
address private implementation;
constructor (address _implementation) {
implementation = _implementation;
}
fallback() external payable {
address impl = implementation;
assembly {
let ptr := mload(0x40)
calldatacopy(ptr, 0, calldatasize())
let result := delegatecall(gas(), impl, ptr, calldatasize(), 0, 0)
assembly {
let free := mload(0x40)
mstore(free, ptr)
mstore(0x40, add(free, 0x20))
}
switch result
case 0 {
revert(0, returndatasize())
}
default {
return(0, returndatasize())
}
}
}
}

复制代码

这个署理合约通过构造函数担当一个实现合约地点并将其存储在implementation变量中。之后，任何发送到署理合约的交易业务都会被转发到该实现合约。
攻击方向

题目在于，假如构造函数对谁可以设置implementation地点没有得当的限定，攻击者大概会利用这一点，通过发送一笔交易业务直接调用署理合约的构造函数，从而改变implementation地点，指向他们自己的恶意合约。如许，全部后续调用都将被重定向到恶意合约，导致合约功能被篡改或资金被盗。
办理方案

为了防止这种范例的攻击，我们必要确保署理合约的初始化过程是安全的。以下是一种大概的办理方案：

1、利用Initializer Pattern：引入一个初始化状态，确保署理合约只能被初始化一次，而且初始化过程受到严酷控制。可以利用一个initializer修饰符来标志那些只应在初始化过程中调用的方法。
2、引入全部权验证：确保只有合约的全部者或预界说的地点可以或许设置implementation。

办理方案示例：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
abstract contract Initializable {
bool initialized = false;
modifier initializer() {
require(!initialized, "Already initialized");
initialized = true;
_;
}
}
contract SecureProxy is Initializable {
address private implementation;
address private admin;
constructor(address _implementation, address _admin) initializer {
implementation = _implementation;
admin = _admin;
}
function setImplementation(address _newImplementation) public {
require(msg.sender == admin, "Only admin can set the implementation");
implementation = _newImplementation;
}
fallback() external payable {
// ... (same as before)
}
}

复制代码

在这个改进版本中，我们引入了Initializable抽象合约来管理初始化状态，并在构造函数上应用了initializer修饰符。别的，我们添加了一个setImplementation方法，允许通过合约全部者（admin）来更新implementation地点，进一步加强了安全性。
8. 时间依赖毛病

时间依赖毛病是智能合约中一个常见的安全题目，特别是在以太坊等区块链情况中。这是由于区块链的区块时间戳可以被矿工在肯定水平上利用，这使得依赖于时间戳的智能合约容易受到攻击。攻击者可以通过控制区块时间戳来触发合约中的某些条件，从而得到不公平的上风或造成丧失。
示例：贷款合约中的时间依赖毛病

假设我们有一个基于时间的贷款合约，乞贷人必须在特定的时间窗口内归还贷款，否则将面对高额罚息或失去抵押品。合约大概如下所示：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract LoanContract {
address public borrower;
uint256 public loanAmount;
uint256 public deadline;
constructor(address _borrower, uint256 _loanAmount, uint256 _deadline) {
borrower = _borrower;
loanAmount = _loanAmount;
deadline = block.timestamp + _deadline; // 设置还款截止日期
}
function repayLoan() public {
require(msg.sender == borrower, "Only borrower can repay");
require(block.timestamp <= deadline, "Deadline passed");
// 偿还贷款的逻辑...
}
function claimCollateral() public {
require(block.timestamp > deadline, "Deadline not yet passed");
// 没有偿还贷款，没收抵押品的逻辑...
}
}

复制代码

在这个合约中，deadline是基于当前区块时间戳盘算的，乞贷人在deadline之前必须归还贷款。然而，假如攻击者控制了挖矿过程，他们可以延后提交新区块，人为延伸区块时间戳，使deadline看起来还未到达，从而克制抵押品的充公，大概相反，提条件交新区块，使deadline提前到达，迫使乞贷人付出罚息。
办理方案

为相识决时间依赖毛病，可以接纳以下几种计谋：

1、利用Oracle服务：引入一个可信的Oracle服务来提供不可篡改的时间戳，如允许以镌汰矿工利用区块时间戳的影响。
2、利用链上变乱作为时间基准：比方，可以利用特定的区块高度作为时间基准，由于区块高度不能被矿工容易利用。
3、增长时间缓冲区：在时间相干的逻辑中到场肯定的缓冲时间，镌汰对准确时间戳的依赖。
4、利用中位数时间协议（Median Time Protocol，MTP）：雷同于比特币网络中的中位数时间协议，可以利用迩来多个区块时间戳的中位数来盘算一个更稳固的时间参考点。

比方，我们可以修改上面的贷款合约，利用区块高度作为时间基准：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract LoanContract {
address public borrower;
uint256 public loanAmount;
uint256 public deadlineBlock;
constructor(address _borrower, uint256 _loanAmount, uint256 _deadlineBlocks) {
borrower = _borrower;
loanAmount = _loanAmount;
deadlineBlock = block.number + _deadlineBlocks; // 设置还款截止区块
}
function repayLoan() public {
require(msg.sender == borrower, "Only borrower can repay");
require(block.number <= deadlineBlock, "Deadline block passed");
// 偿还贷款的逻辑...
}
function claimCollateral() public {
require(block.number > deadlineBlock, "Deadline block not yet passed");
// 没有偿还贷款，没收抵押品的逻辑...
}
}

复制代码

通过将时间依赖改为区块高度依赖，我们镌汰了矿工利用时间戳的本事，从而加强了合约的公平性和安全性。然而，每种办理方案都有其衡量，比方利用区块高度大概会引入与区块天生时间相干的不确定性，因此在现实应用中必要过细评估和选择最得当的方案。
9. Gas限定和DoS攻击

Gas限定和DoS（Denial of Service，拒绝服务）攻击是在区块链和智能合约情况下常见的安全威胁，尤其是对于像以太坊如许的平台，此中Gas是一种用于衡量实行智能合约资本的单元。Gas机制筹划的初志是为了防止无穷循环和资源滥用，但同时也为攻击者提供了可利用的空间。
Gas限定机制

在以太坊中，每一笔交易业务都会携带肯定命量的Gas，这是为了确保任何实行的利用都不会斲丧过多的盘算资源，从而制止网络拥堵或资源耗尽。当一笔交易业务开始实行时，它会从交易业务者提供的Gas总量中扣除费用，直到合约实行完成或Gas耗尽。假如在实行过程中Gas耗尽，那么交易业务将被回滚，且已经斲丧的Gas不会退还给用户。
DoS攻击方式

耗尽Gas

攻击者可以通过构造高复杂度的交易业务或智能合约来故意斲丧大量的Gas，从而使正常交易业务无法被包罗在区块中。比方，攻击者可以创建一个合约，该合约在吸收到消息时实行大量盘算或存储利用，斲丧靠近最大Gas限额的Gas量。当许多如许的交易业务被同时发送到网络时，它们会占据大部门以致全部的Gas容量，导致其他用户的正常交易业务无法被确认，从而到达拒绝服务的效果。
无穷循环

另一种DoS攻击的方式是通过使智能合约进入无穷循环，这将导致Gas立即耗尽，交易业务失败并回滚。这种攻击通常发生在合约逻辑中存在错误的情况下，比方没有准确处置处罚循环退出条件，或在递归调用中缺少停止条件。当合约进入无穷循环时，它会实验斲丧全部可用的Gas，终极导致交易业务失败，并大概使合约处于不可用状态。
防御步伐

为了防御这类DoS攻击，开辟者在编写智能合约时必要接纳一些防备步伐：

限定循环次数：确保任何循环都有明确的停止条件，制止无穷循环的大概性。
优化代码服从：只管镌汰不须要的盘算和存储利用，制止高复杂度的算法。
利用安全框架和库：利用如OpenZeppelin等智能合约安全库，它们通常包罗了颠末严酷审计的安全模式和函数，可以资助制止常见的安全陷阱。
代码检察和测试：定期举行代码检察和安全审计，利用情势化验证工具查抄潜伏的毛病。
设置Gas上限：在智能合约调用中设置公道的Gas上限，制止恶意调用斲丧过多资源。
动态Gas订价：思量实办法态的Gas订价机制，根据网络负载自动调解Gas代价，以鼓励优先处置处罚紧张交易业务。

通过以上这些步伐，可以显着低沉智能合约遭受DoS攻击的风险，保障网络的稳固性和用户的资产安全。然而，由于区块链情况的复杂性，连续的安全意识和最新的安全实践是必不可少的。
毛病合约示例

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract InfiniteLoopVulnerable {
function loopUntilZero(uint256 startValue) public payable {
uint256 currentValue = startValue;
while (currentValue > 0) {
currentValue--;
}
// 正常操作...
}
}

复制代码

在这个合约中，loopUntilZero函数将进入一个无穷循环，假如startValue设置得充足大，那么这个循环会斲丧全部可用的Gas，导致交易业务失败并回滚。
攻击演示

攻击者可以调用loopUntilZero函数，传入一个极大的数值，比方2^256-1，这将使循环险些不大概竣事，因此斲丧全部的Gas。

InfiniteLoopVulnerable contract = new InfiniteLoopVulnerable();
contract.loopUntilZero(2**256-1);

复制代码

防御步伐

为了防止这种无穷循环的DoS攻击，我们必要在合约筹划中到场一些限定和优化：

1、限定循环次数：可以设定一个最大循环次数的上限，以制止无穷循环的发生。
2、查抄和修复逻辑：确保循环中有准确的退出条件。
3、Gas服从优化：尽大概镌汰每次循环中的利用，以低沉Gas斲丧。

下面是一个修复后的合约示例：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract SafeInfiniteLoop {
function safeLoopUntilZero(uint256 startValue) public payable {
require(startValue <= 10000, "Value too large"); // 设定最大循环次数
uint256 currentValue = startValue;
while (currentValue > 0) {
currentValue--;
}
// 正常操作...
}
}

复制代码

10. 权限管理不妥：

权限管理不妥是智能合约中常见的安全题目之一，尤其是在管理员或特定账户被过分赋予权限的情况下。假如合约中的关键功能，如转移资产、修改合约状态或升级合约逻辑，可以被未经授权的实体随意利用，这将构成严肃的安全风险。下面我将给出一个示例，展示权限管理不妥大概导致的效果，以及怎样通过公道筹划来缓解这种风险。
毛病合约示例

假设我们有一个智能合约，用于管理一个数字资产的发行和转账。在这个合约中，管理员账户被赋予了无穷的权利，可以无穷定地铸造新资产并将其转移到恣意账户。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract MismanagedPermissions {
mapping(address => uint256) public balances;
address public admin;
constructor() {
admin = msg.sender;
}
function mint(address to, uint256 amount) public {
require(msg.sender == admin, "Only admin can mint");
balances[to] += amount;
}
function transfer(address from, address to, uint256 amount) public {
require(balances[from] >= amount, "Insufficient balance");
balances[from] -= amount;
balances[to] += amount;
}
}

复制代码

在这个合约中，mint函数允许管理员账户无穷定地创建新资产。固然这看起来像是一个公道的权限，但假如管理员账户的安全性受损，大概合约开辟者错误地将一个不受信托的地点设置为管理员，这将为攻击者打开大门。
攻击演示

攻击者大概通过各种本事获取管理员账户的私钥，大概合约开辟者大概不鉴戒将一个恶意地点设置为管理员。一旦攻击者控制了管理员账户，他们就可以随意调用mint函数，无穷定地创建资产并将其转移到自己的账户，从而非法赢利。

MismanagedPermissions contract = new MismanagedPermissions();
contract.mint(msg.sender, 1000000); // 攻击者铸造大量资产

复制代码

办理方案

为了防止权限管理不妥导致的安全题目，我们可以接纳以下步伐：

1、最小权限原则：只授予实行特定使命所需的最小权限。比方，管理员可以被授予- - 2、铸造资产的权限，但这种权限应该是有限的，比方每天只能铸造肯定命量的资产。
3、多因素认证：引入多签机制或多因素认证，纵然一个管理员账户被攻破，也必要多个独立的允许才气实行关键利用。
4、权限审计日志：纪录全部权限利用情况，以便于监控和审计。
5、权限时效性：设定权限的有用期，逾期后必要重新授权。

下面是一个改进后的合约示例，此中增长了权限限定和多签机制：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract SafePermissions {
mapping(address => uint256) public balances;
mapping(address => bool) public admins;
uint256 public dailyMintLimit;
uint256 public dailyMinted;
constructor(uint256 _dailyMintLimit) {
dailyMintLimit = _dailyMintLimit;
admins[msg.sender] = true; // 初始管理员
}
modifier onlyAdmin() {
require(admins[msg.sender], "Only admin can perform this action");
_;
}
function mint(address to, uint256 amount) public onlyAdmin {
require(dailyMinted + amount <= dailyMintLimit, "Daily mint limit exceeded");
balances[to] += amount;
dailyMinted += amount;
}
function addAdmin(address newAdmin) public onlyAdmin {
admins[newAdmin] = true;
}
function removeAdmin(address adminToRemove) public onlyAdmin {
delete admins[adminToRemove];
}
}

复制代码

在这个改进后的合约中，我们引入了多个管理员的概念，并设置了逐日铸造资产的上限，以防止无穷量的资产创造。同时，我们还提供了添加和移除管理员的功能，这必要现有管理员的权限。
通过这些改进，我们可以大大加强合约的安全性，镌汰权限管理不妥的风险。在现实应用中，还必要联合详细的业务场景和安全需求，进一步细化权限管理和安全控制机制。
11. 外部调用：

在智能合约开辟中，调用不受信托的外部合约是一个常见的安全风险点。这是由于，当你调用另一个合约的函数时，你现实上是在实行谁人合约的代码，而这大概会引入你未曾预料的活动，包罗恶意活动。下面我将通过一个示例来分析这一风险，并提出相应的缓解计谋。
毛病合约示例

假设我们有一个智能合约，它允许用户通过调用一个外部合约来完成某种使命，比如兑换代币。这里，我们假设外部合约提供了一个transferFrom函数，用于从一个账户向另一个账户转移代币。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract ExternalCallVulnerable {
address public externalTokenContract;
constructor(address _externalTokenContract) {
externalTokenContract = _externalTokenContract;
}
function exchangeTokens(uint256 amount) public {
IERC20(externalTokenContract).transferFrom(msg.sender, address(this), amount);
}
}

复制代码

在这个合约中，exchangeTokens函数调用了外部合约的transferFrom函数。然而，这里存在一个潜伏的题目：外部合约大概包罗恶意代码，大概其逻辑大概与预期不符，导致资金丧失或其他不良效果。
攻击演示

攻击者可以通过摆设一个恶意的ERC20代币合约，并将这个合约地点转达给我们的合约。恶意合约大概在transferFrom函数中包罗额外的逻辑，比如在转移代币的同时，调用我们的合约中的其他函数，大概实行一些未授权的利用。

// 恶意合约示例
contract MaliciousToken is IERC20 {
function transferFrom(address, address, uint256) public override returns (bool) {
// 正常转移代币逻辑...
// 执行额外的恶意操作，例如调用合约中的其他函数
ExternalCallVulnerable(0x...).someUnsafeFunction();
return true;
}
}

复制代码

当用户实验通过我们的合约互换恶意合约中的代币时，恶意合约的transferFrom函数会被调用，实行恶意利用。
办理方案

为了减轻外部调用带来的风险，我们可以接纳以下步伐：

1、代码检察：在允许调用外部合约之前，对其举行彻底的代码检察，确保其逻辑符合预期，没有包罗恶意代码。
2、白名单机制：只允许调用颠末验证的、可信托的合约列表。如许，纵然出现新的恶意合约，也无法通过我们的合约举行调用。
3、利用安全库：利用如OpenZeppelin等安全库中的尺度化接口，这些接口通常已经思量到了安全性和兼容性题目。
4、限定调用深度：制止在调用外部合约时再次调用其他外部合约，以防止递归调用导致的攻击。
5、变乱监听与非常处置处罚：在调用外部合约时，监听返回值和非常，确保调用乐成而且没有发生非常活动。

下面是一个改进后的合约示例，此中实现了白名单机制：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
interface IERC20 {
function transferFrom(address, address, uint256) external returns (bool);
}
contract SafeExternalCall {
mapping(address => bool) public approvedContracts;
address public externalTokenContract;
constructor(address _externalTokenContract) {
approveContract(_externalTokenContract);
externalTokenContract = _externalTokenContract;
}
function exchangeTokens(uint256 amount) public {
require(approvedContracts[externalTokenContract], "Contract not approved");
IERC20(externalTokenContract).transferFrom(msg.sender, address(this), amount);
}
function approveContract(address contractAddress) public {
approvedContracts[contractAddress] = true;
}
}

复制代码

在智能合约开辟中，调用不受信托的外部合约是一个常见的安全风险点。这是由于，当你调用另一个合约的函数时，你现实上是在实行谁人合约的代码，而这大概会引入你未曾预料的活动，包罗恶意活动。下面我将通过一个示例来分析这一风险，并提出相应的缓解计谋。
毛病合约示例

假设我们有一个智能合约，它允许用户通过调用一个外部合约来完成某种使命，比如兑换代币。这里，我们假设外部合约提供了一个transferFrom函数，用于从一个账户向另一个账户转移代币。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract ExternalCallVulnerable {
address public externalTokenContract;
constructor(address _externalTokenContract) {
externalTokenContract = _externalTokenContract;
}
function exchangeTokens(uint256 amount) public {
IERC20(externalTokenContract).transferFrom(msg.sender, address(this), amount);
}
}

复制代码

在这个合约中，exchangeTokens函数调用了外部合约的transferFrom函数。然而，这里存在一个潜伏的题目：外部合约大概包罗恶意代码，大概其逻辑大概与预期不符，导致资金丧失或其他不良效果。
攻击演示

攻击者可以通过摆设一个恶意的ERC20代币合约，并将这个合约地点转达给我们的合约。恶意合约大概在transferFrom函数中包罗额外的逻辑，比如在转移代币的同时，调用我们的合约中的其他函数，大概实行一些未授权的利用。

// 恶意合约示例
contract MaliciousToken is IERC20 {
function transferFrom(address, address, uint256) public override returns (bool) {
// 正常转移代币逻辑...
// 执行额外的恶意操作，例如调用合约中的其他函数
ExternalCallVulnerable(0x...).someUnsafeFunction();
return true;
}
}

复制代码

当用户实验通过我们的合约互换恶意合约中的代币时，恶意合约的transferFrom函数会被调用，实行恶意利用。
安全改进

为了减轻外部调用带来的风险，我们可以接纳以下步伐：

代码检察：在允许调用外部合约之前，对其举行彻底的代码检察，确保其逻辑符合预期，没有包罗恶意代码。
白名单机制：只允许调用颠末验证的、可信托的合约列表。如许，纵然出现新的恶意合约，也无法通过我们的合约举行调用。
利用安全库：利用如OpenZeppelin等安全库中的尺度化接口，这些接口通常已经思量到了安全性和兼容性题目。
限定调用深度：制止在调用外部合约时再次调用其他外部合约，以防止递归调用导致的攻击。
变乱监听与非常处置处罚：在调用外部合约时，监听返回值和非常，确保调用乐成而且没有发生非常活动。

下面是一个改进后的合约示例，此中实现了白名单机制：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
interface IERC20 {
function transferFrom(address, address, uint256) external returns (bool);
}
contract SafeExternalCall {
mapping(address => bool) public approvedContracts;
address public externalTokenContract;
constructor(address _externalTokenContract) {
approveContract(_externalTokenContract);
externalTokenContract = _externalTokenContract;
}
function exchangeTokens(uint256 amount) public {
require(approvedContracts[externalTokenContract], "Contract not approved");
IERC20(externalTokenContract).transferFrom(msg.sender, address(this), amount);
}
function approveContract(address contractAddress) public {
approvedContracts[contractAddress] = true;
}
}

复制代码

在这个改进后的合约中，我们添加了一个approvedContracts映射，用于存储颠末审批的外部合约地点。只有当外部合约地点被列入白名单时，才气通过我们的合约举行调用。
通过这些改进，我们可以大大低沉因调用不受信托的外部合约而引入的安全风险。然而，在现实应用中，还必要连续关注新的安全威胁和最佳实践，以维护合约的安全性。
12. 随机数天生

一样平常在区块链上的随机数天生通常难以实现，依赖于区块哈希等可猜测因素，这大概导致攻击者可以或许猜测效果、以下是一些比力常见的场景。
1. 猜测随机数

contract GuessTheNumber {
function guess(bool isHigher) public {
uint256 randomNumber = block.timestamp % 100; // 这里使用时间戳作为随机数来源
if ((randomNumber > 50) == isHigher) {
// 玩家猜对了，分配奖励
}
}
}

复制代码

攻击者可以通过监控

区块链上的交易业务和时间戳来猜测将来交易业务的时间戳，从而猜测随机数并始终做出准确的推测。
2. 交互式随机数天生

contract Auction {
function endAuction() public {
uint256 random = ExternalRandomService.getLastBlockHash() % bidders.length;
// 假设bidders是一个数组，random用来选择获胜的投标人
}
}

复制代码

攻击者可以观察到合约即将竣事拍卖的交易业务，然后在合约调用getLastBlockHash()之条件交一个自己的交易业务，影响区块哈希，从而影响终极的随机数。
3. 依赖预言机

contract Game {
function play() public {
uint256 random = OracleService.getRandomNumber();
// 使用预言机提供的随机数
}
}

复制代码

假如预言机服务被攻击者控制，他们可以提供卖弄的随机数，影响游戏效果。
发起方案

要办理上述题目，可以接纳以下几种计谋：

1、利用可信预言机：选择信誉良好的预言机服务提供商，最好是颠末审计且有良好汗青纪录的服务。
2、多因素随机数天生：联合多个难以猜测的因子来天生随机数，如区块难度、区块头信息以及链下提供的熵。
3、时间延伸：在天生随机数和利用随机数之间到场延伸，使得攻击者难以及时猜测效果。
4、链下随机数天生：利用链下随机数天生服务，然后通过预言机将效果提交到链上。
5、加密技能：利用暗码学技能，犹如态加密或零知识证明，来确保随机数天生过程的隐私性和安全性。

13.存储和盘算服从

不当的存储结构或计算密集型操作可能导致高Gas费用和性能瓶颈。

复制代码

示例场景：频仍读取和写入大数组

假设你正在构建一个投票体系，此中每个提案都有一个独立的计票器。为了实现这一点，你大概最初会思量利用一个映射（map），此中键是提案ID，值是一个数组，存储全部投给该提案的选民地点。

// 不当的存储结构
contract VotingSystem {
mapping(uint => address[]) public voters;
function vote(uint proposalId, address voter) public {
voters[proposalId].push(voter);
}
function getVotesCount(uint proposalId) public view returns (uint) {
return voters[proposalId].length;
}
}

复制代码

存在的题目

1、Gas费用高昂：每当有人投票时，数组必要重新分配内存空间来容纳新元素，这会斲丧大量Gas。
2、性能瓶颈：读取和写入大数组会变得非常痴钝，由于每次读取或写入利用都必要遍历整个数组。

办理方案：优化存储结构

优化发起
为了镌汰Gas费用并进步性能，我们可以重新筹划数据结构，利用映射来追踪每个选民是否已经投票给某个提案，而不是维护一个选民数组。

// 优化后的存储结构
contract OptimizedVotingSystem {
mapping(uint => mapping(address => bool)) public hasVoted;
function vote(uint proposalId, address voter) public {
require(!hasVoted[proposalId][voter], "Already voted");
hasVoted[proposalId][voter] = true;
}
function getVotesCount(uint proposalId) public view returns (uint) {
uint count;
for (address voter = address(1); voter != address(0); voter = address(uint(voter) + 1)) {
if (hasVoted[proposalId][voter]) {
count++;
}
}
return count;
}
}

复制代码

改进分析

1、镌汰Gas费用：利用映射追踪投票状态比维护数组更高效，由于映射的利用（如插入和查找）通常更快，斲丧的Gas更少。
2、提升性能：映射利用险些恒定时间复杂度O(1)，不会随数据量增长而变慢。

留意事项

只管利用映射可以显着进步服从，但在getVotesCount函数中遍历全部地点来盘算投票数仍然是低效的。现实应用中，你可以引入额外的映射或变量来追踪每个提案的投票总数，以制止全地点空间的遍历。

// 进一步优化
contract FurtherOptimizedVotingSystem {
mapping(uint => mapping(address => bool)) public hasVoted;
mapping(uint => uint) public votesCount;
function vote(uint proposalId, address voter) public {
require(!hasVoted[proposalId][voter], "Already voted");
hasVoted[proposalId][voter] = true;
votesCount[proposalId]++;
}
function getVotesCount(uint proposalId) public view returns (uint) {
return votesCount[proposalId];
}
}

复制代码

如许，每次投票时只需更新投票计数器，大大低沉了Gas费用和进步了查询速率。在智能合约开辟中，公道的筹划和优化存储结构对于低竣工本和提升性能至关紧张。

智能合约开辟中13种最常见的毛病

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

浏览过的版块