ethereum/EIPs-1271 smart contract

https://github.com/PhABC/EIPs/blob/is-valid-signature/EIPS/eip-1271.md

Standard Signature Validation Method for Contracts

eip	title	author	discussions-to	status	type	category	created
1271	Standard Signature Validation Method for Contracts	Francisco Giordano (@frangio), Matt Condon (@shrugs), Philippe Castonguay (@PhABC)	https://github.com/ethereum/EIPs/issues/1271	Draft	Standards Track	ERC	2018-07-25

 

原因：

Many blockchain based applications allow users to sign off-chain messages instead of directly requesting users to do an on-chain transaction. This is the case for decentralized exchanges with off-chain orderbooks like 0x and etherdelta. These applications usually assume that the message will be signed by the same address that owns the assets. However, one can hold assets directly in their regular account (controlled by a private key) or in a smart contract that acts as a wallet (e.g. a multisig contract). The current design of many smart contracts prevent contract based accounts from interacting with them, since contracts do not possess private keys and therefore can not directly sign messages. The proposal here outlines a standard way for contracts to verify if a provided signature is valid when the account is a contract.

现在很多基于区块链的应用都允许用户在链下签署信息，而不是直接在线上交易的时候进行签署。这个使用链下订单簿进行去中心化交易的例子就像0x (去中心化交易协议)and etherdelta（EtherDelta（以德交易平台）是基于以太坊区块链的以太坊与ERC20代币互换的开源去中心交易平台（智能合约github地址））。这些应用一般都假设这些信息都会被拥有这个资产的相同账户签署。但是，现在的问题是我们即能够直接用自己日常的账户去拥有资产（用私钥来管控），但是我们也可以设计智能合约作为一个钱包来管控资产。目前的关于很多智能合约的设计都防止这些基于账户的合约与账户进行交互，所以这些合约是没有私钥的，那么他们就不能直接签署信息。这个EIP建议就是阐述了一个标准的方法来让合约去核查当一个账户是合约的时候，它提供的签名是否有效。

 

Abstract

Externally Owned Accounts (EOA) can sign messages with their associated private keys, but currently contracts cannot. This is a problem for many applications that implement signature based off-chain methods, since contracts can't easily interact with them as they do not possess a private key. Here, we propose a standard way for any contracts to verify whether a signature on a behalf of a given contract is valid.

EOA就是外部账号（链上的账号分为合约账号和外部账号）能够用他们的私钥来签署信息，但是目前合约是不能做到的，这对于很多实现了基于签名的链下方法的应用是一个问题，因为它没法轻松与账户交互来得到私钥。所以这里我们建议了一种标准的方法去让任何的合约核查代表了一个合约的签名是否是有效的。

 

Motivation

In the future, it is likely that many users will hold their assets in a smart contract instead of holding them in their externally owned account directly since contracts can improve user experience significantly while providing extra security. This means that contracts using signature based functions should not assume that a given address can provide ECDSA signatures. Otherwise, identity based contracts and contracts holding assets may not be able to interact with functions requiring ECDSA signatures directly.

在未来，用户可能更多地将使用智能合约来管控他们的资产而不是使用EOA外部账户，因为智能合约可能能够通过提供额外的安全性，以此提高了用户的使用体验。这就意味着使用基于签名的函数的合约不应该假设一个给定的账户能够提供ECDSA签名。否则基于身份的合约与拥有资产的合约将不能够与需要ECDSA签名的函数直接交互。

 

Here, we use the term smart account to refer to any contract that act as an account, which can include identity based methods (e.g. ERC-725 & ERC-1078), asset ownership (e.g. Multisigs, proxy contracts) and/or executable signed messages methods (e.g. ERC-1077). This terminology is important for the reader to better distinguish a contract that acts as an account (e.g. a multisig, wallet or Gnosis Safe contract) and a contract that does not act as an account but requires signatures.

在这里我们使用智能账户指的是用做账户的合约，他们包括了基于身份的方法(e.g. ERC-725 & ERC-1078)，资产拥有和可执行的签署信息 (e.g. ERC-1077)的方法。这个术语能够很好地帮助用户去区分需要用做账户的合约(e.g. a multisig, wallet or Gnosis Safe contract) 以及那些不需要用做账户但是需要签名的合约。

One example of an application that requires addresses to provide signatures would be decentralized exchanges with off-chain orderbook, where buy/sell orders are signed messages (see 0x and etherdelta for examples). In these applications, EOAs sign orders, signaling their desire to buy/sell a given asset and giving explicit permissions to the exchange smart contracts to conclude a trade via an ECDSA signature. When it comes to contracts however, ECDSA signature is not possible since contracts do not possess a private key. In the first version of the 0x protocol, smart contracts could not generate buy/sell orders for this very reason, as the maker needed to both own the assets and sign the order via ECDSA method. This was revised in their protocol version 2 (see below).

一个应用的例子就是需要账户地址去提供应该随着链下订单簿进行去中心化交换的签名，订单簿上的买卖订单就是签名信息。在这些应用中，EOAs的签名订单表明了他们买卖给出的资产的意愿并且通过ECDSA签名给出了明显的允诺去交换智能合约来订立该交易。但是当从EOA账户变成了合约后，因为合约不拥有私钥，所以ECDSA签名是不可能实现的。在0x协议（去中心化交易协议https://baike.baidu.com/item/Ox协议/22453818?fr=aladdin）的初版中，智能合约能够生成买卖订单并同时需要创建订单的人拥有资产并能够使用ECDSA方法对订单进行签名。但是这个在版本2中已经进行了修订，具体如下：

Specification

/**
* @dev Should return whether the signature provided is valid for the provided data
* @param _data Arbitrary length data signed on the behalf of address(this)
* @param _signature Signature byte array associated with _data
*
* MUST return a bool upon valid or invalid signature with corresponding _data
* MUST take (bytes, bytes) as arguments
*/ 
//就是如果这个签名是有效的，那么我就确定你是该账户的拥有者
function isValidSignature(
    bytes _data, //任意长度代表了账户地址的签名后的数据，比如一个hash数据
    bytes _signature)//签名
    public
    view 
    returns (bool isValid);

isValidSignature can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependant (e.g. signers authorization level within smart account), signature scheme Dependant (e.g. ECDSA, multisig, BLS), etc.

isValidSignature可以使用任何方法来核查给出的签名是否有效，可以自己写

 

contracts/access/SignatureBouncer.sol

这里面实现了一个类似的功能，但是这个是EOA账户的，而不是智能账户的：

/**
   * @dev is the signature of `this + sender` from a bouncer?
   * @return bool
   */
  function _isValidSignature(address _address, bytes _signature)
    internal
    view
    returns (bool)
  {
    return _isValidDataHash(
      keccak256(abi.encodePacked(address(this), _address)),//将所给的参数打包再一起进行ABI编码，然后进行hash
      _signature //该_signature是对`this + sender`内容的签名，所以上面的hash是那样的
    );
  }

  /**
   * @dev internal function to convert a hash to an eth signed message
   * and then recover the signature and check it against the bouncer role
   * @return bool
   */
  function _isValidDataHash(bytes32 _hash, bytes _signature)
    internal
    view
    returns (bool)
  {
    address signer = _hash //这两个都是ECDSA.sol里的函数
      .toEthSignedMessageHash()//convert a hash to an eth signed message
      .recover(_signature);//调用库的recover函数，得到签名的公钥，即地址signer
    return isBouncer(signer);
  }
}

但是这个不同的是，上面是证明这个签名是不是有给出的address签的

但是这里是证明提供的签名对于给出的数据data是不是有效的，

 

Rationale

Such a function is important because it allows other contracts to validate signed messages on the behalf of the smart account. This is necessary because not all signed messages will first pass by the smart account as in ERC-1077, since signatures can be requested by independent contracts. Action based signed messages do not require this method for external contracts since the action is Smart Account A -> Contract C (e.g. owner of smart account A wants to transfer tokens T to contract C), but when the action is in the opposite direction (Contract A -> SmartAccount) this external function is necessary (e.g. contract A requires smart account A to transfer tokens T when event E is triggered).

这个函数是很重要的，因为它允许了其他合约去核查代表了智能账户的签名信息是不是有效的。它是很必须的，因为在ERC-1077中，当签名可能被其他独立的合约要求查看时，不是所有的签名信息都会被智能账户传递。当基于签名信息的操作是从智能账户A -> 合约C时（即智能账户的拥有者想要传递token T给合约C时），那么外部合约是不需要这个方法来查看签名的有效性的。但是如果操作是反过来的（即合约C -> 智能账户A），那么这个外部函数肯定是必须的，我必须要确认智能账户的身份的有效性才会给他传token

 

We believe the name of the proposed function to be appropriate considering that an authorized signers providing proper signatures for a given data would see their signature as "valid" by the smart account. Hence, an signed action message is only valid when the signer is authorized to perform a given action on the behalf of a smart account.

我们相信该函数的名称是适当考虑到当一个授权签署者提供了适当的签名给一个给定的数据后将会看到他们的签名对于一个智能账户是“有效”的。因此,一个行动签署消息只有在签名者有权代表一个智能账户去做一个操作时才是有效的。

Two arguments are provided for simplicity of separating the data from the signature, but both could be concatenated in a single byte array if community prefers this.

提供两个参数是为了分离签名数据的简单性，但是如果社区喜欢，能够将他们串联成一个字节数组

 

Implementation

Existing implementations :

• The 0x project implemented this method in their protocol version 2.

• Zeppelin is in the process of implementing this method.还没实现

 

什么是smart account，它实现了什么功能

One example would be to have a "smart account" be an owner. A smart account is a contract that would hold all the assets of a user to facilitate a bunch of stuff and where different private key can perform different action. Some PV key could transfer assets and set permissions while others could simply play games or interact on social media on the behalf of this smart account. Smart accounts increase security and can add a bunch of critical functionalities to regular accounts in order to improve UX.

一个例子就是拥有一个“智能账户”作为所有者。智能帐户是一种合约，它持有用户的所有资产，以方便处理一堆东西，并且不同的私钥可以执行不同的操作。一些private key可以转移资产和设置权限，而另一些密钥则可以代表这个智能帐户玩游戏或在社交媒体上进行交互。智能帐户可以提高安全性，并可以向常规帐户添加一些关键功能，以改善用户体验。

Now, if this smart account, which would actually be my main account, is owner of a contract, or has a given role is some bouncer protected contract, it will need to have this kind of method.

现在，如果这个智能帐户，也就是我的主帐户，是一个合约的所有者，或者有一个给定的角色是某个受bouncer保护的合约，它就需要这种方法。

I have a strong feeling that most users will not use their regular account in the future, which offers very low security and poor UX and will most likely use a smart contract (that is, until account abstraction).

我有一种强烈的感觉，大多数用户在未来将不会使用他们的常规帐户，这提供了非常低的安全性和糟糕的UX，并且很可能会使用一个智能合约

For more info about the future of accounts and the concept of smart accounts, check out Alex van de Sande's 15 mins presentation and then mine at the EDCON Ux unconference.

想要了解更多关于账户未来和智能账户概念的信息，请查看Alex van de Sande的15分钟演讲，然后在EDCON Ux unconference上进行我的演讲。

https://www.youtube.com/watch?v=qF2lhJzngto

 

就是说智能账户其实是一个管控用户所有资产去做一堆事情的合约，在这里有着不同的私钥，每个私钥可以去做不同的操作

https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1005

Whereas classical accounts are driven by ECDSA signed transactions, smart accounts are driven by the arbitrary logic of a smart contract. This is where it relates to the generalization of SignatureBouncer. SignatureBouncer validates ECDSA signatures, but smart accounts are not backed by a key and can never produce such signatures. Thus, a smart account can never be a bouncer, unless we generalize to other authentication schemes.

传统的帐户是由ECDSA签名交易驱动的，而智能帐户是由智能合约的任意逻辑驱动的。这与签名约束的泛化有关。

SignatureBouncer验证ECDSA签名，但智能帐户没有密钥支持，永远无法生成此类签名。因此，除非我们推广到其他身份验证方案，否则智能帐户永远不可能是一个保镖。

 

智能账户：通过智能合约加强以太坊传统账户以改善用户使用体验