你可以前往我的博客获得更好的阅读体验。
本文主要介绍在以太坊中的签名问题，主要涵盖以下内容:
为了方便读者理解和实战本文中的内容，本文将结合一个可以使用Typescript编写用于生产环境的noble-secp256k1库作为实战案例解析。你可以在这里找到源代码。当然，为了节省篇幅，本文不会对此库中的所有代码进行解析。
以下内容部分参考了比特币 P2TR 交易详解。
在椭圆密码学中，许多不同种类的曲线都可以用于生成公钥。以太坊选择了与比特币相同的曲线类型，形式为y² = x³ + 7，被称为secp256k1。具体的图像如下图:
在此图像上，我们可以选择一个点作为生成点G，使用陷门函数计算获得公钥。陷门函数特点是正向计算简单，我们可以快速从私钥求出公钥，而逆向计算难度巨大。
比特币与以太坊均选择了一种被称为点倍增的陷门函数。如下图为我们选择的生成点G：
我们画出过点G的切线与曲线交与一点，我们选择此点关于x轴的对称点作为2G点。下图展示了进行第一次点倍增后的结果2G:
连结G与2G与曲线交与一点，我们选择与此点关于x轴对称的点作为3G。如下图:
依次类推，我们可以得到4G的图像如下:
显然上述操作是直觉上是无法逆向的，关于严格的数学证明，读者可以自行查阅相关论文。以上过程可以进行算法上的优化，读者可以自行阅读noble-secp256k1的开发者的写的关于加速secp256k1计算的博客。
在此给出比特币规定的secp256k1的G的数值:
G.x = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
G.y = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
综上所述，当我们生成一个私钥d后，我可以通过计算P=dG获得公钥P，而以太坊账户就是选择公钥最后20 Bytes进行keccak-256计算得到的。
在noble-secp256k1实现如下:
static fromPrivateKey(privateKey: PrivKey) {return Point.BASE.multiply(normalizePrivateKey(privateKey));
}
当然，上述代码中的multiply是经过优化的。Point.BASE即上文给出的G点。在代码中使用了bigint表示，定义如下:
Gx: BigInt('55066263022277343669578718895168534326250603453777594175500187360389116729240')
Gy: BigInt('32670510020758816978083085130507043184471273380659243275938904335757337482424')
当然，secp256k1也存在定义域，其最大值被记为n，任何有效的点都应在n之内。具体定义如下:
n: BigInt('0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141')
我们也可以在go-ethereum找到以下定义:
var (secp256k1N, _ = new(big.Int).SetString("fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141", 16)secp256k1halfN = new(big.Int).Div(secp256k1N, big.NewInt(2))
)
为了方便读者阅读，给出变量说明:
| 变量缩写 | 含义 |
|---|---|
| d | 私钥 |
| G | 生成点 |
| n | 曲线最大值 |
标准的ECDSA签名由两个整数r和s构成，签名流程如下:
mk，并使用k与G相乘获得点Rr = R.x mod n。如果r = 0则需要重新生产随机数ks = (1/k * (m + dr) mod n。如果s = 0则需要重新生产随机数k上述过程中进行mod n是为了确保计算出的数值在我们所规定的定义域内。
在以太坊中，为了避免签名字段被其他应用使用，对哈希值m计算进行特别规定，即使用Keccak256("x19Ethereum Signed Message:n32" + Keccak256(message))进行哈希计算，使用go实现如下:
func signHash(data []byte) []byte {msg := fmt.Sprintf("x19Ethereum Signed Message:n%d%s", len(data), data)return crypto.Keccak256([]byte(msg))
}
对其签名的具体的代码实现方式如下:
function kmdToSig(kBytes: Uint8Array, m: bigint, d: bigint): RecoveredSig | undefined {const k = bytesToNumber(kBytes);if (!isWithinCurveOrder(k)) return;// Important: all mod() calls in the function must be done over `n`const { n } = CURVE;const q = Point.BASE.multiply(k);// r = x mod nconst r = mod(q.x, n);if (r === _0n) return;// s = (1/k * (m + dr) mod nconst s = mod(invert(k, n) * mod(m + d * r, n), n);if (s === _0n) return;const sig = new Signature(r, s);const recovery = (q.x === sig.r ? 0 : 2) | Number(q.y & _1n);return { sig, recovery };
}
上述代码给出了签名必要的两个元素r和s，通过这两个元素我们就可以得到一个完整的比特币签名。根据BIP66规定，比特币的签名组成如下:
0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
我们可以通过上述代码给出的sig变量中的信息填充上述签名。
但在以太坊中，以太坊要求的签名格式如下:
[R][S][V]
其中增加了变量v，此值已在上文的代码中给出，为recovery值。但与尚未给出的通用recover不同，以太坊交易签名中的v为CHAIN_ID * 2 + 35或CHAIN_ID * 2 + 36，分别对应v=0和v=1。此过程由EIP155规定，目的是为了防止签名层面的重放攻击。
CHAIN_ID即每一条区块链的专属ID，具体可参考ChianList
验证签名需要对签名者的公钥进行恢复，具体的流程如下:
mR = (x, y)。其中，当v=0时，x=r; 当v=1时，x=r+nu1 = hs^-1 mod n，其中h为经过调整的哈希值，调整算法参考truncateHashu2 = sr^-1 mod nQ = u1 * G + u2 * R，Q即签名者的公钥。我们在此给出对应的实现代码:
static fromSignature(msgHash: Hex, signature: Sig, recovery: number): Point {msgHash = ensureBytes(msgHash);const h = truncateHash(msgHash);const { r, s } = normalizeSignature(signature);if (recovery !== 0 && recovery !== 1) {throw new Error('Cannot recover signature: invalid recovery bit');}if (h === _0n) throw new Error('Cannot recover signature: msgHash cannot be 0');const prefix = recovery & 1 ? '03' : '02';const R = Point.fromHex(prefix + numTo32bStr(r));const { n } = CURVE;const rinv = invert(r, n);// Q = u1⋅G + u2⋅Rconst u1 = mod(-h * rinv, n);const u2 = mod(s * rinv, n);const Q = Point.BASE.multiplyAndAddUnsafe(R, u1, u2);if (!Q) throw new Error('Cannot recover signature: point at infinify');Q.assertValidity();return Q;
}
对于上述代码，基本逻辑与我们介绍的流程是相同的。但开发者为了优化代码使用了许多函数，这些函数大多包含位移、算法优化和增强安全性的内容，我们不在此深入研究。开发者将所有的代码都放在了index.ts中，读者可以仅下载index.ts，然后自行使用vscode阅读代码，请善用函数定义跳转功能F12。
通过上述流程，我们可以获得信息签名者的公钥，进一步可以获得签名者的以太坊地址。
在go-ethereum中，我们可以查到以下关于交易签名的源代码：
// SignTx signs the transaction using the given signer and private key.
func SignTx(tx *Transaction, s Signer, prv *ecdsa.PrivateKey) (*Transaction, error) {h := s.Hash(tx)sig, err := crypto.Sign(h[:], prv)if err != nil {return nil, err}return tx.WithSignature(s, sig)
}
代码中最为关键的部分是s.Hash(tx)。从函数的参数中，我们可以得到s为Signer类型。跳转定义，我们发现Signer为接口类型，具体代码如下:
type Signer interface {// Sender returns the sender address of the transaction.Sender(tx *Transaction) (common.Address, error)// SignatureValues returns the raw R, S, V values corresponding to the// given signature.SignatureValues(tx *Transaction, sig []byte) (r, s, v *big.Int, err error)ChainID() *big.Int// Hash returns 'signature hash', i.e. the transaction hash that is signed by the// private key. This hash does not uniquely identify the transaction.Hash(tx *Transaction) common.Hash// Equal returns true if the given signer is the same as the receiver.Equal(Signer) bool
}
出现Signer接口的原因是为了适配以太坊的升级，在以太坊升级过程中，开发者升级过多次签名流程中的tx交易数据结构。为了保证代码的简洁性，引入了接口类型。在代码中，对此接口的实现是根据区块高度决定的:
// MakeSigner returns a Signer based on the given chain config and block number.
func MakeSigner(config *params.ChainConfig, blockNumber *big.Int) Signer {var signer Signerswitch {case config.IsLondon(blockNumber):signer = NewLondonSigner(config.ChainID)case config.IsBerlin(blockNumber):signer = NewEIP2930Signer(config.ChainID)case config.IsEIP155(blockNumber):signer = NewEIP155Signer(config.ChainID)case config.IsHomestead(blockNumber):signer = HomesteadSigner{}default:signer = FrontierSigner{}}return signer
}
London、BerLin都是以太坊的阶段代号，具体可以参考The history of Ethereum
由于我们没有必要使用以前Signer，在此处我们仅介绍最新的实现londonSigner。此签名器满足以下标准:
accessList参数，预支付存储费用CHAIN_ID参数，防止重放攻击我们所需要研究的函数如下:
func (s londonSigner) Hash(tx *Transaction) common.Hash {if tx.Type() != DynamicFeeTxType {return s.eip2930Signer.Hash(tx)}return prefixedRlpHash(tx.Type(),[]interface{}{s.chainId,tx.Nonce(),tx.GasTipCap(),tx.GasFeeCap(),tx.Gas(),tx.To(),tx.Value(),tx.Data(),tx.AccessList(),})
}
其中，tx.Type()有以下几种情况:
const (LegacyTxType = iotaAccessListTxTypeDynamicFeeTxType
)
为了降低复杂度，我们自此不再讨论tx.Type() != DynamicFeeTxType的情况，这种情况并不符合EIP-1599。从代码中可以看出核心函数为prefixedRlpHash，其定义如下:
func prefixedRlpHash(prefix byte, x interface{}) (h common.Hash) {sha := hasherPool.Get().(crypto.KeccakState)defer hasherPool.Put(sha)sha.Reset()sha.Write([]byte{prefix})rlp.Encode(sha, x)sha.Read(h[:])return h
}
简化来说，此代码首先完成了在sha变量内写入0x02标识符，此标识符表示该交易符合EIP1599。
然后，继续在sha变量内写入交易数据的rlp编码，如下:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list])
最后进行哈希计算。
rlp编码相对复杂，此处不再解释。读者可以阅读我个人写的对于RLP 编码的解释文章。当然，读者也可以直接阅读它的源代码
获得符合要求的哈希值后，我们只需要对此哈希值按照上述方法进行签名即可，注意我们需要V、R、S依次进行编码加入交易数据即可。
所有流程可以用下图表示:
验证签名只需要将上述过程反过来进行，较为简单，此处不再赘述。
请读者阅读以下代码:
function recoverSignerFromSignature(uint8 v, bytes32 r, bytes32 s, bytes32 hash) external {address signer = ecrecover(hash, v, r, s);require(signer != address(0), "ECDSA: invalid signature");
}
这是使用ecrecover的一个代码示例，基本展示了我们使用ecrecover的基本方法，但在实际中，我们需要更多的代码确保安全。不要将此代码用于生产环境。我们会在本文的最后给出生产环境中应使用的代码。
通过上文学习，相信读者很快就能判断出ecrecover的作用，该指令接受hash、v、r和s用于恢复签名者公钥。
特殊的一点是ecrecover是一个预编译的EVM指令。预编译意味着智能合约的通用功能已被EVM底层实现，运行EVM的节点可以更加有效地运行含有此类代码的智能合约，而且与自己实现的代码相比，性能更高且消耗的gas费更少。
你可以在EVM Codes查询到此指令。
ecrecover适合所用使用标准secp256k1曲线签名的数据，但我们建议使用以太坊目前最常用的签名API进行签名:
以上API均在metamask中进行了实现，具体使用方法可以参考文档。
其中EIP712属于一种较新的签名标准，在metamask中的实现为signTypedData_v4。我们会在后文详细讨论此标准及其应用。
eth_sign用于对任何数据进行签名，但不建议开发者使用它完成非交易数据签名。这会导致严重的安全问题。
personal_sign也可以对任一数据进行签名，但使用此API会自动在代签数据前加入前缀x19Ethereum Signed Message:n，以防止此签名被用于交易。目前常用于网站的登录。
目前，metamask推荐开发者使用EIP712进行数据签名，而且metamask还对这种方法进行特殊支持，如UI显示等。另一方面，EIP712在复杂数据交互方面具有先天优势，索引开发者应尽可能使用EIP712。
对于DApp签名相关问题，以太坊标准已经有EIP712进行了相关规范。我们之前在MetaMask一键登录设计已经讨论过链下EIP712。但其实EIP712主要解决了链上智能合约签名与验证的相关问题。
EIP712的核心内容是结构化数据的哈希计算，与一般的交易数据不同，EIP712主要面向DApp等相关产品，如果采用与交易数据相同的签名模式，可能导致在不同DApp之间签名被盗用。比如A产品使用一组数据进行哈希签名，而B产品也选择了与A产品相同的数据结构，这意味着你在A产品内进行的非交易签名可以在B产品内使用。这极有可能造成严重的财产问题。
为了解决此问题，EIP712对结构化数据的哈希使用了以下公式:
hashStruct(s : 𝕊) = keccak256(typeHash ‖ encodeData(s))
typeHash = keccak256(encodeType(typeOf(s)))
上述公式中𝕊代表结构化类型数据集中的所有实例
为了方便读者理解EIP712进行结构化数据的流程，我们在此给出一个结构化数据:
struct Mail {address from;address to;string contents;
}
下述给出的‖代表字节拼接。
encodeType要求数据被编码为type ‖ " " ‖ name。上述示例应被编码为Mail(address from,address to,string contents)，与我们在使用多种方式编写可升级的智能合约(下)中讨论的函数选择器字符串编码的规则类似。此处应该注意type必须是solidity规定的数据类型。
上述对
type的描述较为简陋，但一般情况下可以理解为就是solidity中的数据类型，实际上，不是所有的数据类型都可以编码在EIP712中，具体情况可以参考标准定义
encodeData定义为enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ)。enc代表编码函数，要求数据编码成32 bytes，编码要求大致如下:
uint256表示，0代表false， 1代表trueaddress编码为uint160uint统一编码为uint256，并使用大端顺序排序bytes1到bytes32数据类型使用0填充为bytes32bytes和string均进行keccak256后编码array类型数据进行keccak256后编码struct类型数据递归调用hashStruct函数上述规则与abi编码规则是基本一致的，但在string等类型上存在区别，请注意对比。
注意
bytes1,bytes2,…,bytes32等数据类型属于不可变的长度固定静态类型，而bytes则属于长度可变的动态类型，注意区分。
经过上述步骤我们其实仍没有解决签名盗用问题，为了解决这一问题，EIP712要求最终的需要待签数据应该为以下形式:
encode(domainSeparator : 𝔹²⁵⁶, message : 𝕊) = "x19x01" ‖ domainSeparator ‖ hashStruct(message)
在此处，EIP712引入了一个重要的待签字段domainSeparator，它的定义如下:
domainSeparator = hashStruct(eip712Domain)
eip712Domain规定由以下字段构成:
string name，具有可读性的合约名称等string version，当前交互的dapp或合约的版本，不同版本之间的签名不能混用uint256 chainId，区块链链ID，参考此网站address verifyingContract，验证签名的合约，可以保证签名仅被单一合约使用，选填bytes32 salt，加盐，可选填注意不应更改或删除上述字段，如果你有新的建议，请提出
EIP请求。
我们在此处列出一个简单的流程图解释上述过程:
在上图中，我们省略了encodeData的详细情况。
标准中也给出了与对应接口eth_signTypedData交互时应使用的json-schema:
{type: 'object',properties: {types: {type: 'object',properties: {EIP712Domain: {type: 'array'},},additionalProperties: {type: 'array',items: {type: 'object',properties: {name: {type: 'string'},type: {type: 'string'}},required: ['name', 'type']}},required: ['EIP712Domain']},primaryType: {type: 'string'},domain: {type: 'object'},message: {type: 'object'}},required: ['types', 'primaryType', 'domain', 'message']
}
我们在此给出一个完整的示例:
{domain: {// Defining the chain aka Rinkeby testnet or Ethereum Main NetchainId: 1,// Give a user friendly name to the specific contract you are signing for.name: 'Ether Mail',// If name isn't enough add verifying contract to make sure you are establishing contracts with the proper entityverifyingContract: '0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC',// Just let's you know the latest version. Definitely make sure the field name is correct.version: '1',},// Defining the message signing ssage: {/*- Anything you want. Just a JSON Blob that encodes the data you want to send- No required fields- This is DApp Specific- Be as explicit as possible when building out the message schema.*/contents: 'Hello, Bob!',attachedMoneyInEth: 4.2,from: {name: 'Cow',wallets: ['0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826','0xDeaDbeefdEAdbeefdEadbEEFdeadbeEFdEaDbeeF',],},to: [{name: 'Bob',wallets: ['0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB','0xB0BdaBea57B0BDABeA57b0bdABEA57b0BDabEa57','0xB0B0b0b0b0b0B000000000000000000000000000',],},],},// Refers to the keys of the *types* object below.primaryType: 'Mail',types: {// TODO: Clarify if EIP712Domain refers to the domain the contract is hosted onEIP712Domain: [{ name: 'name', type: 'string' },{ name: 'version', type: 'string' },{ name: 'chainId', type: 'uint256' },{ name: 'verifyingContract', type: 'address' },],// Not an EIP712Domain definitionGroup: [{ name: 'name', type: 'string' },{ name: 'members', type: 'Person[]' },],// Refer to PrimaryTypeMail: [{ name: 'from', type: 'Person' },{ name: 'to', type: 'Person[]' },{ name: 'contents', type: 'string' },],// Not an EIP712Domain definitionPerson: [{ name: 'name', type: 'string' },{ name: 'wallets', type: 'address[]' },],},
}
另一个示例可以参考我之前的博客MetaMask一键登录设计。此博客使用了EIP712开发了一个链下登陆系统。
对于EIP712标准，大多数钱包都进行了实现，此处我们主要介绍MetaMask钱包。该钱包提供了signTypedData_v4方法以支持EIP712，读者可自行阅读(文档)[.html#sign-typed-data-v4]
通过上文，我们得到了EIP712签名的基本形式:
"x19x01" ‖ domainSeparator ‖ hashStruct(message)
一般情况下，智能合约接收到的并不是完整的签名而是签名后的v, r, s数据和发送的结构体。故而我们需要先进行签名重建，一个简单的例子如下，你可以在这里找到完整代码:
function verify(Mail mail, uint8 v, bytes32 r, bytes32 s) internal view returns (bool) {// Note: we need to use `encodePacked` here instead of `encode`.bytes32 digest = dePacked("x19x01",DOMAIN_SEPARATOR,hash(mail)));return ecrecover(digest, v, r, s) == mail.from.wallet;
}
用户将Mail结构体和v, r, s数据发送给智能合约，智能合约使用以上数据调用verify进行验证。在验证时，首先进行签名重建，在检验签名者是否为mail的发送者。
关于hash函数读者可自行查阅源代码，注意此文中给出的hash函数均符合以下公式:
hashStruct(s : 𝕊) = keccak256(typeHash ‖ encodeData(s))
typeHash = keccak256(encodeType(typeOf(s)))
在此举出一个例子:
struct Person {string name;address wallet;
}
bytes32 constant PERSON_TYPEHASH = keccak256( "Person(string name,address wallet)"
);
function hash(Person memory person) internal pure returns (bytes32) {return de(PERSON_TYPEHASH,keccak256(bytes(person.name)),person.wallet));
}
在进行hash时，首先使用PERSON_TYPEHASH完成typeHash定义。然后再结构化各个数据。比如对string类型的person.name进行keccak转换。 读者可能发现似乎没有对person.wallet进行转换，这是因为
