Skip to content

Latest commit

 

History

History
117 lines (74 loc) · 11.2 KB

cip-0035.md

File metadata and controls

117 lines (74 loc) · 11.2 KB
cip title author discussions-to status type category created license
35
Support for Ethereum-compatible transactions
Or Neeman (@oneeman)
Final
Standards
Ring 0
2021-02-17
Apache 2.0

Terminology

The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119.

Abstract

This CIP adds support for an Ethereum-compatible transactions, which don't include the three fields which are unique to Celo transactions: feecurrency, gatewayfeerecipient, and gatewayfee. This would enable Celo to accept transactions generated and signed by Ethereum wallets and other Ethereum tooling, which would let Celo users and developers choose from a among wider range of tools, and reduce the initial friction for new users coming from the Ethereum ecosystem.

It also makes the existing replay-protection used by Ethereum and Celo (see EIP-155) mandatory, ensuring that a transaction intended for one blockchain cannot be replayed on another blockchain.

Motivation

  • As the older and more mature platform, Ethereum has a much wider range of wallets and tooling compared to Celo. Support for Ethereum-compatible transactions would allow much of this software to work with Celo.
  • Many users coming from Ethereum are already familiar with wallets such as Metamask, and would likely prefer transacting on Celo using these wallets rather than having to install Celo-specific forks or completely new software such as celocli.
  • Users of cross-chain bridges, in particular, will need to interact with both the Celo blockchain and other blockchains (usually Ethereum). The ability to use a single wallet to interact with both Celo and Ethereum would reduce the friction in doing this.
  • Compatibility with Ethereum signers such as Metamask would enable dapp developers to make use of Web3Modal, easing the process of porting Ethereum dapps to Celo.

Specification

This change requires activation as part of a hard fork. As of FORK_BLOCK_NUMBER clients MUST accept transactions in either of two formats:

  1. Normal Celo transactions
  2. Ethereum-compatible transactions

Further, as of FORK_BLOCK_NUMBER, clients MUST reject transactions without EIP-155 replay protection (see below regarding transaction signing and signature verification).

Note that the Normal Celo transactions format simply represents Celo transactions as they currently exist. The only changes to them are:

  1. There is an additional field when represented as JSON (see below).
  2. Replay protection, which was ubiquitous but optional, becomes mandatory.

RLP transaction format

When RLP-encoded, the two transaction formats consist of the following RLP lists:

  1. Normal Celo transactions: (nonce, gasprice, gaslimit, feecurrency, gatewayfeerecipient, gatewayfee, recipient, amount, data, v, r, s)
  2. Ethereum-compatible transactions: (nonce, gasprice, gaslimit, recipient, amount, data, v, r, s)

Transaction signing and signature verification

For the purpose of transaction signing and of validating transaction signatures, clients MUST use the following as the "signing data" (which is RLP-encoded and hashed, and the result of that is then signed):

  1. For normal Celo transactions: (nonce, gasprice, gaslimit, feecurrency, gatewayfeerecipient, gatewayfee, recipient, amount, data, chainid, 0, 0)
  2. For Ethereum-compatible transactions: (nonce, gasprice, gaslimit, recipient, amount, data, chainid, 0, 0)

Note that this includes replay protection using the chainid, in accordance with EIP-155, which becomes required rather than recommended.

Transaction validation and processing

When validating and processing transactions, clients MUST treat Ethereum-compatible transactions as equivalent to normal Celo transactions with the following values filled in for the missing fields:

feecurrency: nil
gatewayfeerecipient: nil
gatewayfee: 0

JSON representation and RPC methods

A new boolean field, ethCompatible, is to be added to transactions' representation in JSON format. Note that this addition represents a change from how Celo transactions are currently represented as JSON:

  1. When representing a transactions in JSON format (e.g. in RPC methods such as eth_getTransaction, eth_getBlock, etc.), clients SHOULD include a boolean field called ethCompatible, which indicates whether the transaction is an Ethereum-compatible transaction (true) or a normal Celo transaction (false). This is necessary in order to know what should be used as the transaction's "signing data" (as described above).
  2. When parsing a transaction from JSON format, clients SHOULD respect the ethCompatible value if one is supplied, and should treat the transaction as if ethCompatible were false if a value isn't specified.
  3. When processing RPC requests which take a transaction object as an argument (namely: eth_sendTransaction, eth_signTransaction, eth_call, and eth_estimateGas), clients SHOULD give an error if ethCompatible: true is specified but non-trivial values are present for the Celo-only fields (i.e. if feeCurrency isn't nil, gatewayFeeRecipient isn't nil, or gatewayFee is specified and isn't zero).

Rationale

As Celo's blockchain client is a fork of Go Ethereum, Celo transactions are closely related to Ethereum transactions. The key difference is the three new fields added in Celo (feecurrency, gatewayfeerecipient, and gatewayfee). While these fields are currently required in Celo transactions, they are not essential: feecurrency is set to nil if one wishes to pay the transaction fees in CELO, while gatewayfeerecipient and gatewayfee are generally set to nil and 0 respectively, since a system for full node incentives is not yet in place. This naturally suggests the possibility of supporting transactions where these three fields are omitted entirely, resulting in a transaction format identical to Ethereum's. When decoding transactions from RLP, clients can identify the transaction format by the number of fields (12 for normal Celo transactions, 9 for Ethereum-compatible transactions).

The rest of the specification follows from that:

  1. To be compatible with transactions signed by Ethereum wallets, the "signing data" for Ethereum-compatible transactions must match the "signing data" used in Ethereum (see EIP-155)
  2. To eliminate ambiguity as to how a transaction represented in JSON should be encoded to RLP and what the "signing data" for it should be, a new field is added to indicate whether it is a normal Celo transaction or an Ethereum-compatible transaction. Alternatively, it would have been possibly to make this implicit, relying on the presence or absence of the three fields. However, adding the ethCompatible field seemed preferable because (a) it results in a single set of fields in the JSON representation of both transaction types, (b) it is more explicit. Both of these are advantageous in the context of JSON being generated and parsed in different programming languages which may also vary as to whether they use static or dynamic typing.
  3. To maintain backwards compatibility regarding JSON, ethCompatible: false can be inferred if the field is absent in a transaction's JSON.

Implementation

Backwards Compatibility

  • Requires activation as part of a hard fork, since it introduces a new transaction format which is not currently valid in Celo.
  • Normal Celo transactions with replay protection will continue to function as they do currently. As a result, no change will be required in software which generates and signs replay-protected transactions (which includes all known Celo wallets). Any custom software which generates transactions without replay protection will have to be updated to use replay protection.
  • Software which parses RLP-encoded transactions will need to add support for parsing Ethereum-compatible transactions, and for signing them or verifying their signatures using the right "signed data" (if signing transactions and verifying signatures is part of its functionality).
  • Software which parses transactions from JSON will need to ensure that it doesn't stop working due to the presence of the new ethCompatible field. Depending on the software's functionality, it may need to be updated to make correct use of this new field (e.g. if verifying transaction signatures is part of the software's functionality, it will need to be updated to use the correct "signing data" for the transaction's transaction type).
  • Software which serializes transaction to JSON format should be updated to include the ethCompatible field.

Security Considerations

It should be noted that both Ethereum and Celo have long incorporated support for EIP-155, which provides replay protection by including the network's chain id in a transaction's "signing data", so that the transaction is valid only on the specific network it is intended for (e.g. Ethereum or Celo). As an example of how this plays out at the level of user experience: in order to use Metamask with the Celo network, Celo has to be added to Metamask as a custom network, a process which includes specifying the chain id (which is 42220 for Celo's mainnet). Because of the signing data including the chain id, when Metamask then generates and signs transactions for Celo, they are valid for the Celo network but not valid for the Ethereum network. Likewise, when it generates and signs transactions for Ethereum, they are not valid for the Celo network.

While Ethereum and Celo, prior to this CIP, also support transactions without replay protection, this CIP makes replay protection mandatory, rendering transaction replay between Ethereum and Celo impossible.

This proposal would not create new security issues, aside from the possibility (inherent in any change) of vulnerabilities resulting from bugs.

Other Considerations

Another important consideration is that if we adopt this CIP, by adding support for transactions in Ethereum format, we are implicitly making a soft commitment to also support future transaction formats adopted by Ethereum, such as EIP-2718.

The reason is that if users start transacting on Celo using tooling written for Ethereum, if and when these tools are updated to generate transactions in new formats, they will no longer work fully with Celo unless we have also added support for the new format (which would need to be included in a hard fork). This possibility creates implicit pressure for us to add support for new Ethereum transaction formats and to do so in a timely manner. However, adoption of this CIP should not be seen as a hard commitment to do so, and decisions as to the adoption of any new formats would proceed on a case-by-case basis.

License

This work is licensed under the Apache License, Version 2.0.