https://github.com/ethereum/EIPs/blob/master/EIPS/eip-191.md

eip	title	author	status	type	category	created
191	Signed Data Standard	Martin Holst Swende (@holiman), Nick Johnson <arachnid@notdot.net>	Draft	Standards Track	ERC	2016-01-20

 

摘要

这个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, B和C有2/3-钱包X

   ii. 用户A, B和D有2/3-钱包Y

   iii. 用户A和B提交了一个presigned交易给X

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

说明

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

0x19 <1 byte version> 
     
     .
    

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

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

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

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

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

额外地，之所以用0x19是因为自从，下面的一行文字会在personal_sign方法中预添加在要签名的hash数据之前：

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

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

版本字节登记

Version byte	EIP	Description
0x00		Data with intended validator
0x01		Structured data
0x45		personal_sign messages

就是如果版本为0x00，那么后面还会跟着intened validator（address），然后才是data

如果是0x01,那么后面后面跟着的就是结构化数据，什么是结构化数据，看EIP-721

如果是0x45,那么后面后面跟着的就是进行personal_sign后的信息