EIP-191(关于如何在以太坊合约中处理签名数据的详细说明)

本文翻译了官网EIP-191的相关内容。改标准试图拓展以太坊的签名规则,为签名内容的可读化提供的重要的基础。

摘要

这个ERC提议了一个关于如何在以太坊合约中处理签名数据的详细说明。

动机

一些接受presigned交易的多签名钱包应用已经出现了。一笔presigned交易就是一堆二进制的signed_data,同时包含签名(r, s, v)。因为对signed_data的解释并不具体,导致了一些问题:

  1. 标准的以太坊交易可以作为signed_data提交。一笔以太坊交易可以拆解成这几个组件:RLP<nonce, gasPrice, startGas, to, value, data>(这里被称为RLPdata),r,s,v。如果对signed_data没有句法约束,这就意味着RLPdata可以用作句法有效的presigned交易。
  2. 多签名钱包同样也有问题:presigned交易并不和一个特定的validator绑定在一起,举一个特定钱包的例子:

    i. 用户A, BC2/3-钱包X

    ii. 用户A, BD2/3-钱包Y

    iii. 用户AB提交了一个presigned交易给X

    iv. 攻击者可以复用他们的给X的presigned交易,然后提交给Y

说明

我们为signed_data提议了以下格式:

0x19 <1 byte version> <version specific data> <data to sign>.

版本0对于版本特定数据有<20字节地址>,这个地址就是预期的验证者。在多签名钱包的例子中,就是钱包自己的地址。

最初的0x19字节用来确保signed_data不是有效的RLP

对于单个值为[0x00, 0x7f]的字节,字节的RLP编码就是它本身

这意味着任何signed_data不能是一个RLP结构,而是1个字节的RLP,后面再加上一些别的内容。

因此,任何ERC-191 signed_data永远不会是一笔以太坊交易。

额外地,之所以用0x19是因为自从ethereum/go-ethereum#2940,下面的一行文字会在personal_sign方法中预添加在要签名的hash数据之前:

"\x19Ethereum Signed Message:\n" + len(message).

因此,使用0x19是为了可以扩展这个模式,通过定义一个版本 0x45E)来处理这种类型的签名。

版本字节登记

Version byteEIPDescription
0x00191Data with intended validator
0x01712Structured data
0x45191 personal_sign messages

举例

function submitTransactionPreSigned(address destination, uint value, bytes data, uint nonce, uint8 v, bytes32 r, bytes32 s)
    public
    returns (bytes32 transactionHash)
{
    // Arguments when calculating hash to validate
    // 1: byte(0x19) - the initial 0x19 byte
    // 2: byte(0) - the version byte
    // 3: this - the validator address
    // 4-7 : Application specific data
    transactionHash = keccak256(byte(0x19),byte(0),this,destination, value, data, nonce);
    sender = ecrecover(transactionHash, v, r, s);
    // ...
}

}

    原文作者:王铁塔
    原文地址: https://segmentfault.com/a/1190000015647423
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞