In the Lima hard-fork the remaining (frozen) Aeternity tokens from the Ethereum
ERC20 contract are put into a contract and can be retreived by the entity
holding the correct Ethereum private key. This contract is added to chain as
part of the hard-fork, and the contract is also funded as part of the
hard-fork. Here we describe how we prepare the data (the contracts.json file)
that is used during the hard-fork. The .json-file has the following format
and constraints (apps/aecore/src/aec_fork_block_settings.erl):
%%% { <API encoded pubkey for contract> : { "amount" : <integer>,
%%% "vm_version" : <integer>,
%%% "abi_version" : <integer>,
%%% "nonce" : <integer>
%%% "code" : <API encoded contract byte array>
%%% "call_data" : <API encoded contract byte array>
%%% }
%%% ...
%%% }
%%%
%%% The locked token account will be the owner of the contracts.
%%% The nonces must correspond to the nonces of the owner account.
%%% The nonces must be consecutive (but not necessarity ordered)
%%% The pubkey of the contract must correspond to the computed pubkey
%%% (based on owner account and nonce). This is mostly a fail safe to ensure
%%% that the contract pubkey is visible in the file.
Since this is the first contract to be added by this mechanism, the nonce to be
used is 1 and we can compute the contract pubkey using Erlang:
Then we need to compute the total sum of tokens. The final list of accounts
that has not migrated their tokens is in test/json/contracts_accounts.json.
The sum of the tokens is:
We also need the root-hash of the Merkle tree (the tree contains all the
Ethereum accounts and their respective balances).
80> BigT = mtree:tree_from_json("../test/json/contracts_accounts.json"), ok.
ok
81> mtree:root_hash(BigT).
"E4DBC69BF2783B81B0423DA3F5B684C1D37CCFAE798474525C4001DB42C67669"
