xDai to Mainnet/Arbitrum migration (wip)

# xDai to Mainnet/Arbitrum migration (wip) Honey is currently native to xDai and the bottlekneck for security of Honey is the xDai bridge validators. Since xDai is dragging it's heels it seems wise to construct an exit strategy as L2 solutions become available. Arbitrum seems to be the most promising solution, atleast in the short term. Arbitrum also allows for arbitrary L1/L2 bridging transactions out of the box. Note Arbitrum L2 -> L1 transactions will currently take one week (plus batch submission delay, 8 hours on Rinkeby) due to the need to wait for the chains dispute period to pass. L1 -> L2 transactions seem to take ~5 minutes on Rinkeby, presumably some batch submission period. I expect mainnet to be similar. Using this bridging feature the initial plan for migration to an L2 is to migrate the Honey token to the Ethereum mainnet and issuance, voting, conviction voting, celeste etc to Arbitrum. With HoneyV2 on L1 if in future we decide Arbitrum isn't the right home for 1Hive's governance infrastructure, we can vote to move the ability to mint/burn HoneyV2 to a different L2 without having to migrate to a new token. ## HoneyV2 Since there will be no governance actions on Ethereum/L1, HoneyV2 could be a standard ERC20 with the permit pattern eg [Aragon's Govern Token](https://github.com/aragon/govern/blob/develop/packages/govern-token/contracts/GovernToken.sol) instead of a MiniMeToken which is quite inefficient and only necessary for doing on chain governance decisions using Aragon infrastructure. The bridged HoneyV2 on Arbitrum/L2 will be a MiniMeToken, the total supply of which must mirror the total supply of HoneyV2 on Ethereum so it can be used within the 1Hive protocol to enable issuance and voting as it currently is. This means that instead of minting and burning new HoneyV2 during bridging, some of the total supply of the Arbitrum HoneyV2 will be granted and locked. HoneyV2 could be rebased so the max supply is closer to 30million or 30billion. I'm convinced there are psychological benefits to doing this. The multiplier used can be discussed. Before HoneyV2 is deployed, issuance of Honey must be stopped, and the common pool Honey burnt. The initial deployment of HoneyV2 will mint the current total supply of Honey and send it to the xDai migration contract. ### Honey to HoneyV2 Migration A migration contract will allow Honey holders to convert their Honey to HoneyV2 on xDai with one transaction. They can then bridge to whatever chain they like using standard bridging methods or hopefully connext. ## Bridging Governance Most governance decisions will occur and only result in changes to contracts on L2. However, updating the minter/burner of the HoneyV2 token on L1 will require an L2 -> L1 transaction. This should be straight forward as the caller of a cross chain function is recorded by ArbOs on L2 and can be checked when it's equivalant function is called on L1, this will ensure only the 1Hive decision/vote app is able to update the HoneyV2 minter/burner. ## Bridging Issuance Since HoneyV2 will live on Ethereum (L1) and issuance will live on Arbitrum (L2), we will need to modify the issuance contract to make an L1 transaction that mints or burns HoneyV2 on Ethereum. Provided the MiniMeToken that represents HoneyV2 on Arbitrum accurately mirrors the total supply of HoneyV2 on Ethereum, and issuance on Arbitrum is the only entity able to modify the total supply of HoneyV2 on Ethereum (via mint/burn functions through the bridge) then we can use the MiniMeToken on Arbitrum to accurately calculate issuance. Issuance will then update the Arbitrum HoneyV2 (call this HoneyL2) and make a L1 call to update Ethereum HoneyV2 (call this HoneyL1). Each of issuance burn and mint will have a slightly different process. To execute an issuance burn we will do one L2 -> L1 transaction signalling to burn some amount of HoneyL1 from the L1 bridge contract. Upon submission we would burn the same amount of HoneyL2 from the common pool on L2. To execute an issuance mint, we will do an L2 -> L1 transaction signalling we want to mint some tokens which will mint HoneyL1 to the bridge contract. Upon submission we would mint the necessary HoneyL2 for the common pool on L2. Note both processes assume that the L1 operation is guaranteed to eventually happen. And they will take roughly one week on mainnet Arbitrum to execute the L2 -> L1 transaction. This means that the total supply of HoneyL1 will always be roughly one week behind HoneyL2, which is available through conviction voting. This shouldn't be a problem as long as there isn't more Honey accessible outside of the common pool than is available on the L1 bridge. ## Hella Techs (mainly for my own understanding but might be interesting...) #### L1 -> L2 retry transaction. Get maxSubmissionCost from ArbRetryableTx.getSubmissionPrice. Get maxGas and gasPriceBid from NodeInterface.estimateRetryableTicket (requires correct maxSubmissionCost) Note that the L2 gas payment for the L2 transaction will come from the L2 account that submitted the retryTicket on L1, unless it is sent with the retryTicket as msg.value, in which case it will effectively be deposited into the L2 address and used to pay for submission, the left over sent where specified. Can get the sender from msg.sender on L2 #### L2 -> L1 Need to submit proof with detail to Outbox.executeTransaction(). Get proof etc from NodeInterface.lookupMessageBatchProof(). Check l2 block of random batch and index to triangulate. Get outbox from rollup contract. Can get the sender from Outbox.l2tol1Sender(). Note the outbox referenced in the bridge can be updated by the bridge owner which ultimately could fake the outbox to allow a different address to successfully submit the L1 transaction. Must check who has ability to update/add to the outboxes in the bridge if we use the Inbox.bridge.outbox path to get the outbox. #### To deploy token Deploy L2CustomGateway, deploy L1CustomGateway with address of L2CustomGateway. Call registerTokenToL2 from ERC20 or forceRegisterTokenToL2 from EOA on the L1CustomGateway. Register the gateway to the L1GatewayRouter, requires calling from the token contract itself. Stops anyone from registering incorrect/fraudulent addresses with an L1 token. Can only move L1 -> L2 by calling the L1GatewayRouter. Moving L2 -> L1 can call the L2Gateway directly. Afaik, attempting to move ERC20's from L2 -> L1 using the L2GatewayRouter will revert (unless the L2Gateway has the same address as the L1Gateway). #### To use AMB Execute `requireToConfirmMessage` here: https://blockscout.com/xdai/mainnet/address/0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59/write-proxy then put the transaction hash into here: https://alm-xdai.herokuapp.com/100/0x5c37b036d20d62398283347b229419dc98f787a1d6389f778eccae25754715a8 (replace the current one in the URL). Once validators have confirmed we can call `execute` at the bottom of the UI to call the function (which calls `executeSignatures` here: https://etherscan.io/address/0x4C36d2919e407f0Cc2Ee3c993ccF8ac26d9CE64e#writeProxyContract). The gas estimation is a lot higher than necessary, see transaction: https://etherscan.io/tx/0x7c8928c0e9a15549d5dbe8e0a11cafa509c99b387a9e1f085aad7190bee5e28a but this should allow us to burn and mint Honey at the behest of the xdai bridge validators. #### Contract work - L2 MiniMeToken implementing IArbToken interface that holds available Honey and grants/locks upon Arbitrum bridge calls. The grant/lock functionality could be a separate contract although it wouldn't explicitly conform to the IArbToken interface. Implementation: https://github.com/1Hive/minime/pull/3/files - L2 Issuance as specified above. Implementation: https://github.com/1Hive/issuance/pull/1/files - L1 ERC20 with permit etc and functions to register itself with the gateway. Implementation: https://github.com/1Hive/honey-token/pull/1/files - L1 Minter/burner callable from L2 Issuance, including function to update owner of L1 ERC20 callable from L2 voting on L2. Note no tests yet. Implementation same repo as above: https://github.com/1Hive/honey-token/pull/1/files - xDai burn contract to allow burning HoneyV1 for HoneyV2. See the XdaiHoneyMigrator.sol contract (other migration contracts in PR are likely unused). Implementation same repo as above: https://github.com/1Hive/honey-token/pull/1/files