本文我们来尝试进行 RareSkills Gas 优化的一个挑战，完成这个挑战可以学习到更多 Gas 技巧。
以下是 Distribute 合约，合约的作用是向 4 个贡献者平均分配 1 ETH， 代码如下

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.15;

contract Distribute {
    address[4] public contributors;
    uint256 public createTime;

    constructor(address[4] memory _contributors) payable {
        contributors = _contributors;
        createTime = block.timestamp;
    }

    function distribute() external {
        require(
            block.timestamp > createTime + 1 weeks,
            "cannot distribute yet"
        );

        uint256 amount = address(this).balance / 4;
        payable(contributors[0]).transfer(amount);
        payable(contributors[1]).transfer(amount);
        payable(contributors[2]).transfer(amount);
        payable(contributors[3]).transfer(amount);
    }
}

合约代码：https://github.com/RareSkills/gas-puzzles/blob/main/contracts/Distribute.sol

这个合约默认情况下，所需 GAS 是 71953， 需要优化到 57044， 以便通过测试用例，测试用例代码在这里。
这是默认运行的截图：

在原始合约上运行测试结果

挑战的要求是仅修改合约Solidity代码来使 distribute 下降到57044， 因此不可以修改优化器或solidity版本、不可以修改测试文件，也不使用huff/yul/bytecode 层面的优化，也不变更函数属性（不能使函数为 "payable"）。
在进一步阅读之前，请确保你自己先尝试解决这个难题，它真的很有趣，而且能让你学到东西。

让我们来优化吧!

让我们先做一些明显的事情。

• 变更变量为不可变（immutable）变量，而不是存储变量（节省 10710Gas--因为不可变变量是作为常量嵌入合约字节码的，而不是从存储中读取）。
• 用 send 取代 transfer（节省108 Gas--因为send没有检查转账是否成功）。
• 用endTime代替currentTime (节省了69个Gas - 在构造函数中进行时间计算)

以下是修改后的合约：

这样我们就可以让Gas 节约到61066，已经比原来的好了10887，但仍比目标值高出 4千， 需继续努力。

那么，还有什么诀窍呢？

这个挑战有一个特别的技巧，应该教给你。而这是一种通过SELFDESTRUCT向地址发送ETH的老方法：

通过Selfdestruct 解谜, 仅仅这一招就为你节省了4066*的Gas，并且达到了目标!

但如果继续深入呢？

每一个理智的优化总是有其疯狂的邪恶兄弟（作弊）......让我们看看我们能把这个推到什么程度!
让合约自毁（selfdestruct）感觉像是在作弊 -- 为什么你会有一个这样的合约，在第一次调用分发后就不存在了呢？不过测试通过，所以我想这是允许的......？

让我们看看还有什么（真正的作弊）能让测试通过，但又能优化更多Gas。

• 让contributors成为常数，而不是不可变（immutable）（节省24个Gas - 因为Hardhat地址总是相同的，所以可以这样做，对吧？
• 使金额恒定为0.25ETH，而不是从余额中计算（节省了106个Gas -- 因为在测试中金额总是相同的，所以为什么不这样做呢？）
• 使用Assembly来做call，而不是通常的solidityaddress.send（节省9 0 Gas）。

到目前为止使用的 Gas 是 56780

还可以更进一步吗？

把地址作为字节32的数字直接放在调用中，可以为我们多节省9个Gas!

在调用中的手动用零填充地址， 可以节约到 56771 Gas

我们继续走下去如何？

既然我们已经针对测试上做优化，那我们就进一步
为什么我们不直接返回，如果测试是 "Gas目标"？
知道Hardhat总是在相同的区块链中运行测试，我们可以把这个代码放在 distribute()函数的开头：

if (block.number == 5) return;

这样在测试中，测量 gas 时，直接返回，而不会消耗很多Gas，但仍将在 "逻辑检查" 测试中完成了的功能检查:)
不明白的同学可以回顾这里的测试用例代码，测试用例会先检查 Gas 是否达标再检查是否"逻辑"满足。

这给了我们一个惊人的21207Gas! 令人难以置信吧，不过你明白这里发生了什么......

但，这就是作弊!

是的，但谨记，这样的作弊经常在链上发生，MEV，漏洞，代码即法律，以及所有其他的东西。

还记得最近的Gas挑战比赛吗，最佳优化者获得了NFT？在那里，没有人在解决原来的问题--一切都在 "欺骗 "智能合约，以接受所需的值，并通过所需的测试，以最低的字节码和最低的Gas--你就能得到NFT。

这也给我们了一些启示，更好的测试和更好的条件可以规避这些作弊，同时让程序更安全。
对于开发我们更应该注重有效的程序，而不仅仅是巧妙地入侵系统。

转载自：https://learnblockchain.cn/article/5515

1. ETH1.0和2.0的对比

1.1 共识机制

• eth1.0：工作量证明
• eth2.0：股权证明

共识改进

• 节能，比pow消耗更少能源
• 低门槛，硬件相对较低
• 降低中心化，pos更易节点参与
• 增加攻击成本，违规惩罚

1.2 节点组成

• eth1.0：一个执行客户端组成完整以太坊节点
• eth2.0：执行客户端 + 共识客户端
  • 执行客户端
    • Besu
    • Erigon
    • Geth
    • Nethermind
  • 共识客户端
    • Lighthouse
    • Lodestar
    • Nimbus
    • Prysm
    • Teku

2. ETH 2.0 方案组成

2.1 节点架构

• 执行层->P2P1

  • 维护交易池，交易处理，gossip广播
  • 状态管理
  • 创建执行负载
  • 用户网关->提供对外RPC

• 共识层->P2P2

  • 共享广播块和证明
  • 运行分叉选择算法
  • 跟踪链的头部
  • 管理信标状态（包含共识和执行信息）
  • 跟踪 RANDAO 中累积的随机性
  • 跟踪justification和finalization
  • 验证器
    • 提议区块
    • 创建证明
    • 累积奖励/惩罚

  

2.2 执行与共识层通信

共识和执行层之间通过“Engine-API”的API发送指令。

共享一个 ENR（以太坊节点记录），其中包含（eth1 密钥和 eth2 密钥）。

层内广播协议：gossip

共识层非区块生产者：

共识层-->接收区块->预先验证块（有效sender）->区块中的交易->执行层->执行交易并验证块头中的状态（哈希匹配）->共识层->添加本地链头部->创建证明->广播证明

共识层为区块生产者时：

共识层->收到通知（下一个区块当选生产者）->调用执行层（create block）->交易内存池->打包区块->执行交易生成区块哈希<-共识层抓取交易和区块哈希->添加到信标块->广播区块

3. 环境测试

3.1 测试方案选配

根据客户端多样性分布
https://clientdiversity.org/

测试方案：Prysm棱镜 + Geth

部署参考文档（prylabs）

3.2 测试环境

• 系统: Ubuntu 20.04
  • CPU：4+ 核 @ 2.8+ GHz
  • 内存：16GB+
  • 存储：2TB+ SSD
  • 网络：8 MBit/秒
• 测试网络: Goerli-Prater
• 执行客户端: Geth 1.11.3
• EN-BN 连接: HTTP-JWT

eth2.0测试网

• Sepolia
  • 封闭验证器集
  • 验证者集受到限制，主要由客户和测试团队监督
  • 较小的区块链状态和历史
  • 同步速度快，需要更少的存储承诺
• Goerli
  • 开放验证者集
  • 携带大状态并需要高存储承诺
  • 需要更长的时间才能与网络的当前状态同步

如果测试合约选Sepolia， 如果想测试参与节点治理选Goerli

3.3 测试环境部署

设置工作目录

export workdir=/mnt/d/eth2.0/ethereum

3.3.1 安装 Prysm

cd $workdir
mkdir consensus
mkdir execution
cd consensus
mkdir prysm && cd prysm
curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh --output prysm.sh && chmod +x prysm.sh

3.3.2 生成 JWT Secret

./prysm.sh beacon-chain generate-auth-secret

3.3.3 下载和运行执行客户端

下载

cd $workdir/execution
wget https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.11.3-5ed08c47.tar.gz
tar -zxvf ./geth-linux-amd64-1.11.3-5ed08c47.tar.gz
mv ./geth-linux-amd64-1.11.3-5ed08c47/geth ./
rm ./geth-linux-amd64-1.11.3-5ed08c47.tar.gz
rm -rf ./geth-linux-amd64-1.11.3-5ed08c47

运行

nohup ./geth --goerli --http --http.api eth,net,engine,admin --authrpc.jwtsecret $workdir/consensus/prysm/jwt.hex 2>> ./geth.log &

3.3.4 Prysm 运行信标节点

cd $workdir/consensus/prysm/

nohup ./prysm.sh beacon-chain --execution-endpoint=http://localhost:8551 --prater --jwt-secret=./jwt.hex --suggested-fee-recipient=0x10210572d6b4924Af7Ef946136295e9b209E1FA0 --accept-terms-of-use --checkpoint-sync-url=https://sync-goerli.beaconcha.in --genesis-beacon-api-url=https://sync-goerli.beaconcha.in 2>> ./prysm.log &

• --suggested-fee-recipient 矿工交易费接收地址
• 设置初始化配置
  • 可以使用genesis文件进行初始化
    • 文件获取：wget https://github.com/eth-clients/eth2-networks/raw/master/shared/prater/genesis.ssz
    • 启动参数：--genesis-state=genesis.ssz
  • 为了加速启动，可以使用现有的信标链检查点同步端点
    • --checkpoint-sync-url
    • --genesis-beacon-api-url

3.3.5 Prysm 运行验证器

cd $workdir/
git clone -b master --single-branch https://github.com/ethereum/staking-deposit-cli.git
cd staking-deposit-cli/
./deposit.sh new-mnemonic

按照提示，依次输入参数

Please choose your language ['1. العربية', '2. ελληνικά', '3. English', '4. Français', '5. Bahasa melayu', '6. Italiano', '7. 日本語', '8. 한국어', '9. Português do Brasil', '10. român', '11. Türkçe', '12. 简
体中文']:  [English]: 12
请选择您的助记符语言 ['1. 简体中文', '2. 繁體中文', '3. čeština', '4. English', '5. Italiano', '6. 한국어', '7. Português', '8. Español']:  [简体中文]: 4
请选择您想要运行多少验证者: 1
请选择（主网或测试网）网络名/链名 ['mainnet', 'ropsten', 'goerli', 'sepolia', 'zhejiang']:  [mainnet]: goerli
用来保护您密钥库的密码。您在设置您的 Ethereum PoS 验证者时需要重新输入密码以便解密它们。:
重复输入以确认:

最后生成助记词，保存并输入确认

cool disorder brand vast jaguar sponsor bamboo ...

您的密钥可以在这里找到： /mnt/d/eth2.0/ethereum/staking-deposit-cli/validator_keys

执行完将生成

1. 新的助记词
2. validator_keys文件夹
   1. deposit_data-*.json // 上传到以太坊启动板的存款数据
   2. keystore-m_*.json // 公钥和加密的私钥

复制validator_keys到consensus文件夹中

cp -r $workdir/staking-deposit-cli/validator_keys $workdir/consensus

导入密钥库

cd $workdir/consensus/prysm
./prysm.sh validator accounts import --keys-dir=$workdir/consensus/validator_keys --prater

出现以下提示代表成功

INFO accounts: Successfully created new wallet wallet-path=/home/surou/.eth2validators/prysm-wallet-v2
Successfully imported 1 accounts, view all of them by running `accounts list`

导入后钱包位置：$HOME/.eth2validators/prysm-wallet-v2

上传存款数据

转到Goerli-Prater Launchpad 的存款数据上传页面，将上面的deposit_data-*.json 上传，会提示您连接钱包。

此时会存入 32 GETH Prater 测试网的存款合约。

避免重复抵押

提交dapp已经做了的判断

查看发起的抵押交易

goerli.etherscan.io

查看链上合约

goerli.etherscan.io

/// @notice Submit a Phase 0 DepositData object.
    /// @param pubkey A BLS12-381 public key.
    /// @param withdrawal_credentials Commitment to a public key for withdrawals.
    /// @param signature A BLS12-381 signature.
    /// @param deposit_data_root The SHA-256 hash of the SSZ-encoded DepositData object.
    /// Used as a protection against malformed input.
    function deposit(
        bytes calldata pubkey,
        bytes calldata withdrawal_credentials,
        bytes calldata signature,
        bytes32 deposit_data_root
    ) override external payable {
        // Extended ABI length checks since dynamic types are used.
        require(pubkey.length == 48, "DepositContract: invalid pubkey length");
        require(withdrawal_credentials.length == 32, "DepositContract: invalid withdrawal_credentials length");
        require(signature.length == 96, "DepositContract: invalid signature length");

        // Check deposit amount
        require(msg.value >= 1 ether, "DepositContract: deposit value too low");
        require(msg.value % GWEI == 0, "DepositContract: deposit value not multiple of gwei");
        uint deposit_amount = msg.value / GWEI;
        require(deposit_amount <= type(uint64).max, "DepositContract: deposit value too high");

        // Emit `DepositEvent` log
        bytes memory amount = to_little_endian_64(uint64(deposit_amount));
        emit DepositEvent(
            pubkey,
            withdrawal_credentials,
            amount,
            signature,
            to_little_endian_64(uint64(deposit_count))
        );

        // Compute deposit data root (`DepositData` hash tree root)
        bytes32 pubkey_root = sha256(abi.encodePacked(pubkey, bytes16(0)));
        bytes32 signature_root = sha256(abi.encodePacked(
            sha256(abi.encodePacked(signature[:64])),
            sha256(abi.encodePacked(signature[64:], bytes32(0)))
        ));
        bytes32 node = sha256(abi.encodePacked(
            sha256(abi.encodePacked(pubkey_root, withdrawal_credentials)),
            sha256(abi.encodePacked(amount, bytes24(0), signature_root))
        ));

        // Verify computed and expected deposit data roots match
        require(node == deposit_data_root, "DepositContract: reconstructed DepositData does not match supplied deposit_data_root");

        // Avoid overflowing the Merkle tree (and prevent edge case in computing `branch`)
        require(deposit_count < MAX_DEPOSIT_COUNT, "DepositContract: merkle tree full");

        // Add deposit data root to Merkle tree (update a single `branch` node)
        deposit_count += 1;
        uint size = deposit_count;
        for (uint height = 0; height < DEPOSIT_CONTRACT_TREE_DEPTH; height++) {
            if ((size & 1) == 1) {
                branch[height] = node;
                return;
            }
            node = sha256(abi.encodePacked(branch[height], node));
            size /= 2;
        }
        // As the loop should always end prematurely with the `return` statement,
        // this code should be unreachable. We assert `false` just to be safe.
        assert(false);
    }

合约内没有限定质押地址，可以代为质押

交易参数如下

0   pubkey  bytes   0xb23fca698e5b57c2dd09f16e10b97d532a18b574a46e6539bd9d83e79c5922230bc8990def676e3e78534a3fd8cbe58d
1   withdrawal_credentials  bytes   0x004734640dd34942fc621f643910f86e52b4e5f03db42d9cf6e14863b1148529
2   signature   bytes   0xb46ac23ab45b798331d706b91a635f59b00019cff96462493fae91877dc18d2c6d30e2684197547cd48c079ad94265ff07f36ab48b61b94ef90e3e7e3eeaf96d52dbb012690113c4fe3bc42274a9eb72d82dbdcbea8aa08e2e00e88978c0de3e
3   deposit_data_root   bytes32 0x0c4b49597ef312f110596b87e333e4c76ef8381216dd52ca63f2c84ea2c152d8

信标链处理您的存款大约需要 16-24 小时。 一旦存入金额总计达到 32 ETH，该验证器就有资格被激活。

查看已抵押信息

beaconcha.in

当前测试抵押节点信息

beaconscan.com
质押生效后才能看到信息

运行验证器

nohup ./prysm.sh validator --wallet-dir=$HOME/.eth2validators/prysm-wallet-v2 --wallet-password-file ./password --prater 2>> ./validator.log &

检查节点和验证器状态

节点日志

追块过程中

• Geth常规日志

INFO [03-11|16:46:14.726] Syncing: chain download in progress      synced=44.90% ...
INFO [03-11|16:46:15.318] Forkchoice requested sync to new head    number=8,633,606 hash=522f76..69cb70 finalized=8,633,551
INFO [03-11|16:46:15.859] Syncing: state download in progress      synced=10.27% s

• prysm常规日志

[2023-03-11 16:47:40]  INFO blockchain: Called new payload with optimistic block payloadBlockHash=0xb7864552d082 slot=5166177

• validator日志

[2023-03-11 16:48:55]  INFO validator: Waiting for beacon node to sync to latest chain head

追齐高度后

生效之前

validator日志显示

INFO validator: Waiting for deposit to be observed by beacon node pubKey=0xb23fca698e5b status=UNKNOWN_STATUS

prysm日志显示

 WARN rpc/validator: Not connected to ETH1. Cannot determine validator ETH1 deposit block number

生效之后

// 待补充

怠工惩罚

如果当前节点质押生效后，未能及时提议区块和证明，将被惩罚 -10680 GWei/epoch

4. 附加配置

开放必要端口

配置时间同步

timedatectl // 检查是否NTP服务是积极的.
sudo timedatectl set-ntp on // 如果NTP服务不是积极的

5. 在线文档

节点设置

• 执行层
  • Besu | Geth | Nethermind | Erigon
• 共识层
  • Nimbus | Prysm | Lighthouse | Teku

费用收件人

Lighthouse | Nimbus | Prysm | Teku

Discord

• 执行层
  • Besu | Geth | Nethermind | Erigon
• 共识层
  • Nimbus | Prysm | Lighthouse | Teku

JWT认证

• 执行层
  • Besu | Erigon | Geth | Nethermind
• 共识层
  • Lighthouse | Nimbus | Prysm | Teku

最新公告

Goerli-Prater、Mainnet

监控

Lighthouse | Nimbus | Prysm | Teku

安全最佳实践

https://docs.prylabs.network/docs/security-best-practices

Prysm社区

邮件列表、Prysm Discord 服务器、r/ethstaker和EthStaker Discord 服务器

6. 节点运行架构

公共检查点

https://notes.ethereum.org/@launchpad/checkpoint-sync

节点统计

https://www.ethernodes.org/

节点质押

goerli: https://goerli.launchpad.ethereum.org/zh

mainnet: https://launchpad.ethereum.org/zh

生产服务器配置

最低要求

• 2 核以上的 CPU
• 8 GB 内存
• 700GB 可用磁盘空间
• 10+ MBit/s 带宽

推荐规格

• 具有 4 个以上内核的快速 CPU
• 16 GB+ 内存
• 1+TB 的快速 SSD
• 25+ MBit/s 带宽

测试网

• Goerli

  https://goerli.etherscan.io/
  水龙头
  https://goerlifaucet.com/

• Sepolia

  https://sepolia.etherscan.io/

  水龙头

  https://sepoliafaucet.com/

即插即用解决方案

https://docs.dappnode.io/user/quick-start/first-steps/

https://github.com/NiceNode/nice-node

https://eth-docker.net/

https://docs.sedge.nethermind.io/docs/intro

https://www.4byte.directory/

Goerli 和 Sepolia 是以太坊开发人员用来测试其应用程序的两个权益证明测试网。web3 开发人员在选择测试网之前应考虑多种原因，包括测试 ETH 的可用性、RPC 节点提供商支持、智能合约可用性等。

在本文中，我们将介绍每个测试网是什么，它们的技术差异，强调三个注意事项，并帮助您为您的项目选择最佳的以太坊测试网。

Goerli 测试网介绍

Goerli 于 2018 年在 ETH-Berlin 开始作为黑客马拉松项目，然后于 2019 年正式启动。它是第一个成功与 Geth、Nethermind、Besu 等客户端同步的权威证明 (PoA) 跨客户端测试网。

Goerli测试网络是一个公开开放的权益证明 (PoS) 测试网，由一个开放的验证器集维护，这意味着任何希望运行自己的测试网验证器的人都可以参与。但是，由于网络的状态很大，需要更长的同步时间和更多的存储来运行一个节点。

与 Sepolia 相比的主要区别

• 开放验证者集
• 无需许可即可获得共识
• 支持跨客户端功能
• 携带大状态并需要高存储承诺
• 需要更长的时间才能与网络的当前状态同步

Goerli 测试网络配置

如果您要将 Goerli 区块链添加到您的钱包，这是要包括的网络信息：

• 网络名称-Goerli Test Network
• RPC URL - https://eth-goerli.g.alchemy.com/v2/[YOUR-API-KEY]
• 链号- 5
• 货币符号- GoerliETH
• 区块浏览器 URL - https://goerli.etherscan.io/

Sepolia 测试网

Sepolia于 2021 年推出，是一个经过许可的权益证明测试网络，由主要由客户和测试团队控制的封闭验证器集维护。虽然开发人员可以公开使用测试网来测试和部署他们的去中心化应用程序 dDapps），但并不是每个人都可以选择运行验证节点，使其成为一个许可网络

由于 Sepolia 是一个较年轻的测试网，与 Goerli 等更成熟的测试网相比，部署的应用程序较少。它具有更小的状态和历史记录，允许更快的同步并需要最少的磁盘空间来运行节点。

与Goerli相比的主要区别

• 封闭验证器集（权威证明配置）
• 获得共识是允许的
• 验证者集受到限制，主要由客户和测试团队监督
• 支持跨客户端兼容性
• 较小的区块链状态和历史
• 同步速度快，需要更少的存储承诺

Sepolia链信息

如果您要将 Sepolia 区块链添加到您的钱包，这是要包括的网络信息：

• 网络名称-Sepolia Test Netwok
• RPC URL - https://eth-sepolia.g.alchemy.com/v2/[YOUR-API-KEY]
• 链号- 11155111
• 货币符号- SepoliaETH
• 区块浏览器 URL - https://sepolia.etherscan.io/

要开始在 Sepolia 上构建，请注册一个免费的 Alchemy 帐户，并从 Alchemy 的公共水龙头获取免费的 SepoliaETH 代币。

选择在 Sepolia 或 Goerli 上开发之前需要考虑的事项

在选择 Sepolia 测试网络或 Goerli 之前要考虑的三件事是：

1. 测试 ETH 的可用性和成本
2. RPC 和 API 支持
3. 智能合约的可用性

1. 测试ETH的可用性

在 Goerli 和 Sepolia 之间进行选择时的主要考虑因素是可用性、可访问性和获取测试 ETH 代币的成本。测试 ETH 代币用于支付测试网上的 gas，web3 开发人员需要在与以太坊主网环境非常相似的环境中部署和测试他们的智能合约。

Goerli ETH是免费的吗？

从历史上看，开发人员在 Goerli 测试网上使用的测试 ETH goETH 一直是免费的，但是由于 goETH 的稀缺性，已经创建了流动性市场，开发人员可以在其中买卖 goETH 以换取真实的 ETH。

Web3 开发者仍然可以通过 Goerli Faucet 获取免费的 Goerli ETH，但是由于 goETH 的总量有硬性上限，所以每天可以领取的 goETH 数量是有限制的。

与积累 Goerli ETH 相关的稀缺性和成本是许多以太坊开发人员从 Goerli 转向 Sepolia 的原因之一。

Sepolia ETH 是免费的吗？

是的，Sepolia ETH 是免费的，可以从Sepolia ETH 水龙头领取。由于市场上可用的 sepETH 总数没有上限，因此每次从 Sepolia 水龙头请求测试 ETH 时，像 Alchemy 这样的水龙头供应商都能够为开发人员提供更多的 sepETH。

2. RPC 和 API 支持

在决定在 Sepolia 或 Goerli 上构建之前，了解支持每个测试网的 RPC 节点提供商以及它们支持的 API 端点非常重要。例如，Alchemy 等一些 RPC 提供商支持 Sepolia 测试网，而其他提供商可能不支持。此外，某些 RPC 提供程序可能缺乏对重要 API 端点的支持，例如需要 Erigon 节点的跟踪 API。

Alchemy 支持 Sepolia 上的所有核心 JSON-RPC 方法以及存档节点支持和跟踪 API 端点。未来，Alchemy 还将支持在 Sepolia 上增强的 API 方法。

3. 智能合约可用性

如果你的智能合约依赖于其他智能合约，那么你决定构建 Goerli 还是 Sepolia 将取决于依赖智能合约的部署位置。

例如，如果您的智能合约需要访问 Uniswap v3 合约，而 Uniswap 只在 Goerli 测试网上部署了他们的合约，那么您将需要在 Goerli 上部署您的智能合约，直到 Uniswap 将他们的测试网迁移到 Sepolia。

4. 其他注意事项

在 Goerli 和 Sepolia 测试网络之间进行选择时，除了智能合约的可用性和节点提供商的支持外，还应考虑网络稳定性、验证者集和以太坊基金会的长期支持等因素。

Goerli 或 Sepolia：我应该选择哪个测试网？

选择正确的测试网络是一个重要的决定，它会影响 dapp 开发的成功。每个测试网络都有自己的技术规范、功能和权衡，选择正确的网络可以节省您的时间和资源。

在部署和测试应用程序和智能合约方面，Ethereum.org 推荐 Sepolia 作为测试应用程序和智能合约的首选，因为它具有受限的验证器集和更高的稳定性保证。

另一方面，如果你想测试你的信标链验证器、节点设置、客户端版本，或者想在部署到主网络之前尝试协议升级，Goerli 是一个不错的选择。它是最接近以太坊主网的测试网，也可用于测试复杂的智能合约交互。

英文原文：https://www.alchemy.com/overviews/goerli-vs-sepolia
翻译：谷歌

介绍：

在本文中，我将解释如何使用一些智能合约安全工具（Mythril、MythX、Slither、Manticore、Security、SmartCheck）来查找和利用以太坊智能合约中的安全漏洞。文章将涵盖基本原理和高级技术，例如测试安全属性、比较这些安全工具。我们将以Capture of the Ether挑战中名为Fifty years的智能合约为例子用上面的工具测试。Letsgo！

漏洞合约代码

下面我们将这个漏洞合约作为例子测试：

pragma solidity ^0.4.21;

contract FiftyYearsChallenge {
    struct Contribution {
        uint256 amount;
        uint256 unlockTimestamp;
    }
    Contribution[] queue;
    uint256 head;

    address owner;
    function FiftyYearsChallenge(address player) public payable {
        require(msg.value == 1 ether);

        owner = player;
        queue.push(Contribution(msg.value, now + 50 years));
    }

    function isComplete() public view returns (bool) {
        return address(this).balance == 0;
    }

    function upsert(uint256 index, uint256 timestamp) public payable {
        require(msg.sender == owner);

        if (index >= head && index < queue.length) {
            // Update existing contribution amount without updating timestamp.
            Contribution storage contribution = queue[index];
            contribution.amount += msg.value;
        } else {
            // Append a new contribution. Require that each contribution unlock
            // at least 1 day after the previous one.
            require(timestamp >= queue[queue.length - 1].unlockTimestamp + 1 days);

            contribution.amount = msg.value;
            contribution.unlockTimestamp = timestamp;
            queue.push(contribution);
        }
    }

    function withdraw(uint256 index) public {
        require(msg.sender == owner);
        require(now >= queue[index].unlockTimestamp);

        // Withdraw this and any earlier contributions.
        uint256 total = 0;
        for (uint256 i = head; i <= index; i++) {
            total += queue[i].amount;

            // Reclaim storage.
            delete queue[i];
        }

        // Move the head of the queue forward so we don't have to loop over
        // already-withdrawn contributions.
        head = index + 1;

        msg.sender.transfer(total);
    }
}

开始

MythX:

MythX 是以太坊智能合约的首要安全分析服务工具，MythX 的使命是确保开发团队避免代价高昂的错误，并使以太坊成为更安全、更值得信赖的平台。
这是使用 MythX for Remix IDE 的结果演示：

1. HIGHSWC-101 | 整数上溢和下溢
   加法运算的操作数没有得到充分的约束。因此，添加可能会导致整数溢出。通过检查输入来防止溢出或确保溢出被断言捕获。
2. HIGHSWC-105 | 不受保护的 ETH 取款
   合约创建者以外的任意发送者可以从合约账户中取款 ETH。这很可能是一个漏洞。
3. MEDIUMSWC-134 | 带有硬编码气体量
   的消息调用突出显示的函数调用转发固定量的气体。这是不鼓励的，因为 EVM 指令的 gas 成本在未来可能会发生变化，这可能会破坏该合约的假设。如果这样做是为了防止重入攻击，请考虑替代方法，例如检查-效果-交互模式或重入锁。

Mythril:

Mythril 是 EVM 字节码的安全分析工具。它检测为 Ethereum、Hedera、Quorum、Vechain、Roostock、Tron 和其他 EVM 兼容区块链构建的智能合约中的安全漏洞。
它使用符号执行、SMT 求解和污点分析来检测各种安全漏洞。它还用于MythX安全分析平台结合使用。

安装：

pip3 install mythril

扫描合约

myth analyze contract.sol

结果

重点是三个漏洞：

1. 整数溢出
2. 对可预测环境变量的依赖性
3. 未受保护的 ETH 取款

详细细节可以看下面：

==== Integer Overflow ====
SWC ID: 101
Severity: High
Contract: FiftyYearsChallenge
Function name: constructor
PC address: 179
Estimated Gas Usage: 23146 - 109214
The binary addition can overflow.
The operands of the addition operation are not sufficiently constrained. The addition could therefore result in an integer overflow. Prevent the overflow by checking inputs or ensure sure that the overflow is caught by an assertion.
--------------------
In file: fifrthyyear.sol:16
now + 50 years
--------------------
Initial State:
Account: [CREATOR], balance: 0x21c10c0542040001, nonce:0, storage:{}
Account: [ATTACKER], balance: 0x0, nonce:0, storage:{}
Account: [SOMEGUY], balance: 0x0, nonce:0, storage:{}
Transaction Sequence:
Caller: [CREATOR], calldata: , value: 0xde0b6b3a7640000
==== Dependence on predictable environment variable ====
SWC ID: 116
Severity: Low
Contract: FiftyYearsChallenge
Function name: withdraw(uint256)
PC address: 342
Estimated Gas Usage: 22161 - 117057
A control flow decision is made based on a predictable variable.
The block.timestamp environment variable is used in to determine a control flow decision. Note that the values of variables like coinbase, gaslimit, block number and timestamp are predictable and can be manipulated by a malicious miner. Also keep in mind that attackers know hashes of earlier blocks. Don't use any of those environment variables for random number generation or to make critical control flow decisions.
--------------------
In file: fifrthyyear.sol:43
require(now >= queue[index].unlockTimestamp)
--------------------
Initial State:
Account: [CREATOR], balance: 0x1000000000000001, nonce:0, storage:{}
Account: [ATTACKER], balance: 0x0, nonce:0, storage:{}
Account: [SOMEGUY], balance: 0x0, nonce:0, storage:{}
Transaction Sequence:
Caller: [CREATOR], calldata: fefefefefefefefefefefefeaffeaffeaffeaffeaffeaffeaffeaffeaffeaffe, value: 0xde0b6b3a7640000
Caller: [CREATOR], function: withdraw(uint256), txdata: 0x2e1a7d4d, value: 0x0
==== Unprotected Ether Withdrawal ====
SWC ID: 105
Severity: High
Contract: FiftyYearsChallenge
Function name: withdraw(uint256)
PC address: 522
Estimated Gas Usage: 22161 - 117057
Anyone can withdraw ETH from the contract account.
Arbitrary senders other than the contract creator can withdraw ETH from the contract account. This is likely to be a vulnerability.
--------------------
In file: fifrthyyear.sol:58
msg.sender.transfer(total)
--------------------
Initial State:
Account: [CREATOR], balance: 0x2181000142640001, nonce:0, storage:{}
Account: [ATTACKER], balance: 0x42101040440090000, nonce:0, storage:
Account: [SOMEGUY], balance: 0x0, nonce:0, storage:{}
Transaction Sequence:
Caller: [CREATOR], calldata: efefefefefefefefefefefefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef, value: 0xde0b6b3a7640000
Caller: [ATTACKER], function: withdraw(uint256), txdata: 0x2e1a7d4d, value: 0x0

Slither

Slither 是一个用 Python 3 编写的 Solidity 静态分析框架。它运行一套漏洞检测器，打印有关合约细节的视觉信息，并提供一个 API 来轻松编写自定义分析。Slither 使开发人员能够发现漏洞，增强他们的代码理解力，并快速构建自定义分析原型。

安装：

使用pip

pip3 install slither-analyzer

使用git

git clone https://github.com/crytic/slither.git && cd slither
python3 setup.py install

Scan 命令

slither contract.sol

下面是扫描结果：

INFO:Detectors:
FiftyYearsChallenge.isComplete() (fifrthyyear.sol#19-21) uses a dangerous strict equality:
        - address(this).balance == 0 (fifrthyyear.sol#20)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#dangerous-strict-equalities
INFO:Detectors:
Pragma version^0.4.21 (fifrthyyear.sol#1) allows old versions
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-versions-of-solidity
INFO:Detectors:
isComplete() should be declared external:
        - FiftyYearsChallenge.isComplete() (fifrthyyear.sol#19-21)
upsert(uint256,uint256) should be declared external:
        - FiftyYearsChallenge.upsert(uint256,uint256) (fifrthyyear.sol#23-39)
withdraw(uint256) should be declared external:
        - FiftyYearsChallenge.withdraw(uint256) (fifrthyyear.sol#41-59)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-as-external

Securify:

Securify 2.0 是以太坊基金会和ChainSecurity支持的以太坊智能合约安全扫描器。Securify 背后的核心研究是在苏黎世联邦理工学院的安全、可靠和智能系统实验室进行的。
有两种使用 Securify 的方法。在你的计算机安装它或使用网络应用程序，如果你想在“这里”安装它，你可以查看本指南。如果您想使用网络应用程序，
这里是链接：https ://securify.chainsecurity.com/

SmartCheck:

SmartCheck 是一种可扩展的静态分析工具，用于发现以 Solidity 编程语言编写的以太坊智能合约中的漏洞和其他代码问题。作为 Securify，您可以将 SmartCheck 作为 Web 应用程序使用或将其安装在您的电脑中。

确保你的机器上安装了 nodejs 和 npm

npm install @smartdec/smartcheck -g

扫描

smartcheck -p contract.sol

这是在网站上扫描的示例：

Manticore:

Manticore 是一个用于分析智能合约和二进制文件的符号执行工具。

安装系统依赖

sudo apt-get update && sudo apt-get install python3 python3-dev python3-pip -y

安装 Manticore 及其依赖

sudo pip3 install manticore[native]

结果分析：

我认为比较这些工具的最佳方法是扫描多个不同的合同并分析每次扫描的结果。这是我使用工具（MythX、Mythril、Securify、SmartCheck、Slither）选择 3 个随机智能合约进行的扫描。结果如下表所示：

结论：

结果显示，Mythx 总共发现了 18 个不同的错误，这明显高于其他对中等错误具有高识别度的工具。另一方面，Securify 在关键错误检测方面得分最高。
最后，每个工具都有特定的方法来检查智能合约的漏洞（静态分析、符号分析、正式合约验证器……），我们的实验只关注 3 个智能合约，为了得到更合理的比较，最好是分析更多合同（例如 1000S-C）

转载自：https://learnblockchain.cn/article/5289