Skip to main content

2.Metadata

当 Solidity 为要部署的智能合约生成字节码时,它会在字节码末尾附加有关编译的元数据。我们将检查该字节码中包含的数据。

Simple Example

//SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

contract Empty {
constructor() payable {}
}

该合约什么都没有,但是当我们编译一下,我们可以看到:

6080604052603e80600f5f395ff3fe60806040525f80fdfea26469706673582212203082dbb4f4db7e5d53b235f44d3e38f839dc82075e2cda9df05b88e6585bca8164736f6c63430008140033

默认情况下,solidity 编译器会在“实际”initcode 的末尾附加元数据,当构造函数完成执行时,这些元数据会存储到区块链中。这是下面的“额外”代码:

fea26469706673582212203082dbb4f4db7e5d53b235f44d3e38f839dc82075e2cda9df05b88e6585bca8164736f6c63430008140033

最后两个字节0033的意思是“向后看0x33字节,那就是元数据”。这是指前导 fe(无效操作码)和结尾 0033 之间的所有代码。我们可以检查这确实是 0x33 字节。

Metadata为了什么

此元数据额外增加了 53 个字节的部署成本,这意味着额外的 10,600 个 Gas(每个字节码 200 个 Gas)+ 调用数据成本(每个非零字节 16 个 Gas,每个零字节 4 个 Gas)。这意味着 calldata 成本增加了 848 额外的 Gas。

So why include it? 那么为什么要包括它呢?

这使得智能合约代码能够得到严格验证。编译器输出的元数据 JSON 包括源代码的哈希值。因此,如果源代码发生一点变化,元数据 JSON 文件就会发生变化,其 IPFS 哈希也会发生变化。