EIP-999: Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4


Metadata
Status: WithdrawnStandards Track: CoreCreated: 2018-04-04
Authors
Afri Schoedon (@5chdn)

Simple Summary


This document proposes to restore the contract code of the WalletLibrary contract at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 with a patched version. The contract was accidentally self-destructed and renders a significant amount of Ether inaccessible.

Abstract


The WalletLibrary contract was used by the Parity Wallet to reduce gas costs for users deploying multi-signature wallets on the Ethereum blockchain. It contained basic functionality such as confirming or revoking multi-signature transactions for any wallet deployed that depends on this library. The accidental self-destruction of the library contract caused significant amounts of Ether and other assets owned by many different parties to be inaccessible. This proposal suggests restoring the WalletLibrary by a patched version to allow the owners of the dependent multi-signature wallets regain access to their assets.

Motivation


This proposal is necessary because the Ethereum protocol does not allow the restoration of self-destructed contracts and there is no other simple way to enable the affected users and companies regaining access to their tokens and Ether. In opposite to previously discussed proposals, this will not change any EVM semantics and tries to achieve the goal of unfreezing the funds by a single state transition as specified in the next section.

Specification


The self-destructed contract code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 shall be replaced with a patched version of the walletLibrary.sol as reviewed, tested, and approved in parity-contracts/0x863df6bfa4:


To verify the byte-code above, a patched version is deployed at 0x21C9E434c669c4d73f55215A6F2130A185E127AC to be reviewed. The compiler settings used can be extracted from the following meta-data:


The differences to the originally deployed contract code can be reviewed at:

The following sections propose two equivalent specifications, 999a and 999b, which technically achieve the same results. To implement this proposal only one of them has to be applied.

Direct State Transition via Bytecode (999a)

At CNSTNTNPL_FORK_BLKNUM, directly recreate the account 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 with the following parameters:

  • Nonce: 0x1
  • Code:

  • Storage:
    • 0x0000000000000000000000000000000000000000000000000000000000000000: 0x0000000000000000000000000000000000000000000000000000000000000001
    • 0x0000000000000000000000000000000000000000000000000000000000000001: 0x0000000000000000000000000000000000000000000000000000000000000001
    • 0x0000000000000000000000000000000000000000000000000000000000000004: 0x00000000000000000000000000000000000000000000000000000000000044e1
    • 0xa5baec7d73105a3c7298203bb205bbc41b63fa384ae73a6016b890a7ca29ae2d: 0x0000000000000000000000000000000000000000000000000000000000000001

The balance of the account shall be left unchanged.

Alternate Specification via Codehash (999b)

At CNSTNTNPL_FORK_BLKNUM, directly recreate the account 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 with the following parameters:

  • Nonce: 0x1
  • Storage:
    • 0x0000000000000000000000000000000000000000000000000000000000000000: 0x0000000000000000000000000000000000000000000000000000000000000001
    • 0x0000000000000000000000000000000000000000000000000000000000000001: 0x0000000000000000000000000000000000000000000000000000000000000001
    • 0x0000000000000000000000000000000000000000000000000000000000000004: 0x00000000000000000000000000000000000000000000000000000000000044e1
    • 0xa5baec7d73105a3c7298203bb205bbc41b63fa384ae73a6016b890a7ca29ae2d: 0x0000000000000000000000000000000000000000000000000000000000000001

In addition, the codehash at that address shall be replaced by the codehash at address 0x21C9E434c669c4d73f55215A6F2130A185E127AC. The codehash is 0x6209d55547da7b035d54ef8d73275e863d3072b91da6ace1614fa6381f4e2c09. The balance of the account shall be left unchanged.

Rationale


The design decision to restore the WalletLibrary contract code in a single state transition was made after lengthy discussions of alternate proposals that explored different ways to improve the Ethereum protocol to allow contract revivals by adding different built-in contracts. It was eventually concluded that all of these proposals changing the EVM semantics around self-destructed contracts were introducing unwanted side-effects and potential risks to the existing smart-contract ecosystem on the Ethereum platform.

The total supply of Ether is neither changed nor does this proposal require the transfer of any tokens or assets including Ether. It is assumed that this change is aligned with the interests both of (A) Parity Technologies that intended to provide a smart-contracts library for multi-signature wallets to last forever for its users and (B) the users of the multi-signature wallets that meant to safely store their assets in a contract accessible any time they desire. Lastly, the client-side implementation cost of this proposal is estimated to be low. A sample implementation will be attached and linked in the following sections.

Backwards Compatibility


This proposal introduces backwards incompatibilities in the state of the contract at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4. The Ethereum protocol does not allow the restoration of self-destructed contracts. To implement this on the Ethereum blockchain, it is recommended to add the necessary state transition in a future hard-fork at a well-defined block number, e.g., CNSTNTNPL_FORK_BLKNUM for the Constantinople milestone which is supposed to be the next scheduled hard-fork on the Ethereum road-map.

Implementation


A proof-of-concept implementation is available for the Parity client on branch a5-eip999-poc (#8406). A sample chain configuration for Parity can be found at the same branch in multisig_test.json describing the state change as specified above.

Copyright


Copyright and related rights waived via CC0.