3194278525
* switch to eipv * fix * fix * 1153 remove trailing whitespace * remove file name checks * 615 remo whitespace before comma * 884 remove extra single-quotes * 1337 remove whitespace before comma * 1057 remove extra spaces after comma * 2470 update created date to Y/M/D format * 1078 update required eips to be in ascending order * 2477 update required eips to be in ascending order * 1271 remove extra whitespace * 2767 required eipupdated to be in ascending order * 2525 update created date to Y/M/D format * 2458 remove trailing whitespace * 1884 remove trailing whitespace * 712 authors should be on a single line * 601 remove extra whitespace * 1485 remove unneeded parentheses * 634 remove trailing whitespace * 2657 update discussions-to to correct spelling * 2009 remove trailing whitespace * 998 required eips updated to be in ascending order * 1186 remove trailing whitespace * 1470 remove extra whitespace * 1895 update created date to Y/M/D format * 2747 remove extra whitespace * 1613 remove leading whitespace * 1571 can'have both handle and email in author field * 1191 remove trailing whitespace * 1973 remove trailing whitespace * 196 don't wrap title field * 1679 required eips must be in ascending order * 1620 author can't have both handle and email * 197 don't line wrap title field * 2378 remove extra newline * 1355 author can't have both handle and email * 698 update created date to Y/M/D format * 2193 required eips must be in ascending order * 214 remove extra info after author email * use v0.0.3 of eipv * 1 remove malformed field * bump eipv to v0.0.4 * cache eipv build * 1485 remove extra author info * 2771 removing extra whitespaces
9.8 KiB
| 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), Amir Bandeali (@abandeali1), Jorge Izquierdo (@izqui), Bertrand Masius (@catageek) | https://github.com/ethereum/EIPs/issues/1271 | Draft | Standards Track | ERC | 2018-07-25 |
Simple Summary
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.
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.
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.
Here, we use the term smart account to refer to any contract that acts 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.
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).
Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
pragma solidity ^0.5.0;
contract ERC1271 {
// bytes4(keccak256("isValidSignature(bytes32,bytes)")
bytes4 constant internal MAGICVALUE = 0x1626ba7e;
/**
* @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 the bytes4 magic value 0x1626ba7e when function passes.
* MUST NOT modify state (using STATICCALL for solc < 0.5, view modifier for solc > 0.5)
* MUST allow external calls
*/
function isValidSignature(
bytes32 _hash,
bytes memory _signature)
public
view
returns (bytes4 magicValue);
}
isValidSignature can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc.
Rationale
Such a function is important because it allows other contracts to validate signed messages on the behalf of the smart wallet. This is necessary because not all signed messages will first pass by the smart wallet 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 wallet A -> Contract C (e.g. owner of smart wallet 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 wallet A to transfer tokens T when event E is triggered).
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 wallet. Hence, an signed action message is only valid when the signer is authorized to perform a given action on the behalf of a smart wallet.
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.
isValidSignature() should not be able to modify states in order to prevent GasToken minting or similar attack vectors. A gas limit being passed is being considered, but could prevent some interesting use cases like large multisignatures or more costly validation and cryptographic schemes.
Backwards Compatibility
This EIP is backward compatible with previous work on signature validation since this method is specific to contract based signatures and not EOA signatures.
Implementation
Existing implementations :
- ERC725 implemented in the ERC725Account.
- The 0x project implemented this method in their protocol version 2.
- Zeppelin is in the process of implementing this method.
Copyright
Copyright and related rights waived via CC0.