Current Ethereum/Arbitrum Migration Plan

[willjgriff]

Due to the stagnant development of xDai necessary to improve its security it is being proposed that we migrate Honey from xDai to Ethereum, where the underlying security is magnitudes greater and there is a larger untapped market. At the same time it is also proposed that we redeploy the 1Hive governance infrastructure and common pool, currently everything accessible via 1hive.org and Celeste, including Gardens, to Arbitrum, which inherits the security of Ethereum, again magnitudes greater than xDai. However, we will continue with plans to deploy Gardens to xDai, this will require deploying a new instance of Celeste that uses the new Honey token and the use of probably an off-chain voting mechanism like Aragon Govern to govern it.

We are closely watching the development and adoption of Arbitrum since it’s launch to ensure it will be a secure and usable network and can still choose to use a different network for our governance infrastructure if necessary. However, migrating Honey to Ethereum is fairly essential at this point.

This plan isn’t set in stone and like everything here it is open to discussion so the below is subject to change.

Honey Migration to Ethereum:

The currently proposed process for migration will require users executing one transaction on xDai, via a migration website, which will permanently burn all the HoneyV1 in their address’s account and grant it HoneyV2 on xDai. This can then be bridged directly to Ethereum or to Arbitrum via Connext (if available) or the standard bridging processes via Ethereum. DAO’s with Agents currently holding HoneyV1 will also be able to execute a transaction via a vote to migrate to HoneyV2 on xDai.

Arbitrum Garden:

To take part in the governance of the 1Hive Common Pool or infrastructure decisions or stake to Celeste on Arbitrum, bridging Honey to Arbitrum will be necessary. The Arbitrum 1Hive Garden will be the one with issuance permissions for HoneyV2 (allowing it to mint to or burn from the common pool) and it will be the governor of Celeste on Arbitrum.

Community consensus:

Ultimately to approve the above migration of core infrastructure to Ethereum/Arbitrum, a decision vote will be required in the xDai 1Hive Garden at 1hive.org. This vote will disable Issuance of HoneyV1 on xDai and burn the HoneyV1 in the common pool. The amount of HoneyV1 burnt from the xDai common pool will be minted to the Arbitrum common pool as HoneyV2.

Further details:

For technical details please see this document, PR’s for the implementation are at the bottom: xDai to Mainnet/Arbitrum migration (wip) - HackMD

Previous discussion regarding the migration can be seen here:

• Signalling proposal: Honey Pot and associated forum post: Honey Migration to Ethereum (signalling/suggestion)
• Migration swarm funding: Migration Swarm Funding

[project_uwb]

Great to see these updates on the Arbitrum migration. I am really interested to see how all this pans out and how the user base of 1Hive takes this migration?
I have been following some other news on rollups based L2s and have realised people complaining about fees for basic contract interactions being around $10-15 which in ETH will start to be a pain, especially when moving from xDAI.
I understand the security benefits but makes me wonder if we may see participation in governance and staking into Celeste drop with this type of fees.

[eenti]

Fees on Arbitrum are expected to lower as usage increases, remember that Arbitrum pushes constant updates to L1, it’s just that those fees are distributed among those transacting on the L2 and now there’s not much people using it.

Also afaik usage on Arbitrum is throttled right now, and as the throttle diminishes, so will the fees.

Can recall someone saying that it’s likely that arbitrum fees are just a pinch more expensive than what we’re used around here, but nothing significant.

[project_uwb]

eenti, thanks for that information. Ah, so if I have got it right you are saying that the fee on Arbitrum is basically the cost of posting tx to the mainnet divided by the total tx on Arbitrum up to the point of posting it? Makes sense when i think about it but then I also wonder how they can afford it if ETH has a really high gas period when they want to post to main net? Anyways, I digress from the main topic… but if the fee will be comparable to xDAI, I think wgmi!! haha

[eenti]

@project_uwb

the cost of posting tx to the mainnet divided by the total tx on Arbitrum up to the point of posting it?

yes, at least as far as i understand it. i’m guessing that it puts an extra on it to give something to arbitrum nodes.

@project_uwb

I also wonder how they can afford it if ETH has a really high gas period when they want to post to main net?

this is honestly beyond my limited knowledge on the topic, but maybe they can be slightly delayed until it goes down? I’m also thinking that as critical movement starts to move to L2’s mainnet can probably deal better with demand fluctuations as its not happening directly on L1, thus making gas prices even more predictable.

Again, don’t take my word for granted, i don’t know much about it, this is just speculation.

[castall]

Is this the right place to ask what would be involved in migrating a “bring-your-own-token” gardens dao to arbitrum?

We have a token that was minted on mainnet and bridged with the omni bridge to provide the community pool. The original pool was meant to fund the first year of the DAO’s existence.

When gardens is migrated to arbitrum, will the xdai gardens dao be immediately defunct, or can an xdai and arbitrum gardens dao coexist for some months?

Should the community pool be drained (if necessary–see above) using conviction voting, or can Tao (dandelion) voting be used?

We already have mainnet and xdai chain gnosis safes with stewards delegated the task to move funds between chains as needed. Will other gardens daos need a similar setup to migrate, or will 1hive provide a simpler migration path for gardens daos?

[eenti]

Gardens will still function on xDai, it’s just 1Hive’s DAO structure that’s moving.

[sacha]

No need to migrate. Even if we do end up moving our home to Arbitrum, the Gardens infrastructure will still exist on xDAI and we will continue to support it.

We want to enable Gardens to launch on as many chains as possible.

[monomesa]

But if we want to migrate, will it be easy?

[sacha]

We’re committed to making it as easy as possible for community members to move their HNY over

[d10r]

Few comments:

Security:
Consider that Arbitrum to date doesn’t provide information for how to run a node. I’ve been waiting for that since June and as late as yesterday saw they’re still not providing that: Discord. Afaik there’s also no docs on how invalid state transition on the rollup chain can be challenged in practice. There’s high-level descriptions, but no actual instructions for how to do it afaik. Looks to me as if at the moment the increased security is somewhat theoretical, because only a small circle knows how enough details. Will hopefully change soon.

Cost:
As was mentioned before, the tx cost on L2s are still considerable. Current estimates are about 1 order of magnitude below Ethereum mainnet and about 4 orders of magnitude above xdai.
While it’s true that increased utilization should lead to some further reduction of Arbitrum fees due to larger batches (I suppose), that effect will be quite limited as far as I understand. Afaik most of the current Arbitrum fees stem from the tx data written to L1. Unfortunately I can’t give any numbers, but my understanding is that the expected gains from bigger tx batches are pretty limited.

I also observed that tx fees seem to be considerably lower on Optimism than on Arbitrum at the moment, but I don’t know why this is and if it’s to be expected to be like this longer term (I actually expected the opposite, bcs. afaik Arbitrum compresses L1 tx data).

[d10r]

@willjgriff I - representing lab10.coop - am running one of the xdai validator nodes for over 2 years now.
I’m genuinely interested in what specifically are your security concerns on xdai.
According to the linked document the bridge validators are the bottleneck.
Is it about the size of the validator set or about the nature of the bridge itself?

Btw. I just discovered that there’s now an Arbitrum deployment on xdai too, but that’ll likely not make a difference here.

[willjgriff]

@d10r

Looks to me as if at the moment the increased security is somewhat theoretical, because only a small circle knows how enough details.

I’m not concerned about this, 1Hive will run an Arbitrum validator once it becomes practical, securing all of our deployments there. And even without I’m still fairly comfortable deploying there considering the roughly $2b locked there already: https://l2beat.com/. However, we will wait until the bridge becomes permissionless (in about 6 weeks apparently) as currently the Arbitrum team have permissions over the bridge and could effectively capture funds held there.

@d10r

I also observed that tx fees seem to be considerably lower on Optimism than on Arbitrum at the moment

If this is accurate https://l2fees.info/ then as of 22/09/21 it looks like Arbitrum fees are about half of Optimism’s. We are yet to see whether they will come down further with increased capacity and usage. I have to admit I was expecting it to be cheaper considering the magnitudes increased throughput that was advertised. I think we’ll just have to wait and see.

@d10r

I’m genuinely interested in what specifically are your security concerns on xdai.

If the UI representing this recent cross bridge transaction I did is accurate, capturing the funds in the bridge only requires collusion of 4 individual bridge nodes:

This isn’t currently much of an issue as we’re in a fairly experimental phase, however if the Honey token is worth a significant amount more and is used to govern the development of and access some core decentralised organisational infrastructure it shouldn’t be at risk of capture/disruption from effectively a centralised set of bridge validators, however many there are.

[lkngtn]

@d10r

I’m genuinely interested in what specifically are your security concerns on xdai.

My biggest concern with xDai security (as well as Polygon, and any other sidechain style network where a large amount of value is being held in a multisig “bridge”) is related to the bridge security more than the consensus security provided by validators. Although I would generally still prefer the consensus security provided by Ethereum.

as @willjgriff mentioned, currently the xDai bridge requires 4 signers to take action on either the Ethereum side or the xDai side. Even if we are completely confident in the integrity of these signers on a personal level, its possible that their node/key is compromised. As I understand it these keys must be “hot” and generally all of the bridge validators are running the same toolchain maintained by the core team.

In contrast with a rollup style bridge, individuals can run validators and enforce the expected behavior for rollup operators on Ethereum, even if all of the rollup operators were to become compromised. This model inherent nearly all of the security properties of Ethereum.

I think for many users and use cases the tradeoff of lower transaction fees will be worthwhile, however, for any use cases that require large amounts of capital to be managed or moved (eg DeFi) this tradeoff will be a limiting factor. In the case of 1Hive, I think we want to enable high value use cases as well as the long tail of use cases that may not require as much security, but if we keep Honey as a native token on xDai and bridge it back to Ethereum/Arbitrum to support higher value use cases we won’t be able to isolate the risks of the xDai bridge itself would effectively be able to mint Honey.

By migrating Honey to Ethereum/Arbitrum, we can eliminate that issue, and while the Honey that remains or is bridged back to xDai will still depend on the xDai bridge security, the rest of the 1Hive ecosystem will be insulated from this risk.

[lkngtn]

It should be fairly easy, since we will also be supporting gardens on Arbitrum, if the token is native to Ethereum already it will be trivial. However, if the token is native to xDai (like Honey) a more involved migration process will be needed.

[igorbarinov]

There is a plan to launch Stake Beacon Chain (SBC) in two weeks or so. We are waiting for the audit from Chainsecurity. Stake Beacon Chain (R&D) - xDai
Security model of the new consensus will be very close to Eth2 with some tweaks in parameters and a different token. After that, there will be a work on “the merge” of xDai into SBC as a part of the xDai’s roadmap. Following the merge of Eth1 to Eth2 and xDai to SBC, current bridges very likely will be migrated into a permissionless bridge without relayers/validators since both chains will be able to natively validate blocks of each other. The level of permissionlessness will be comparable to cross shard communications in Eth2.

[willjgriff]

That’s great to hear since we intend to maintain our infrastructure on xDai.

It sounds like permissionless bridges introducing the necessary security will depend on the release of Eth2 (aswell as deployment of SBC and the xDai merge). Once it’s all set up we can re-evaluate the costs and security of remaining on Arbitrum, should we move there.

Note that once Honey is migrated to Ethereum it will only require a single vote from the community (with a 7 day cross-bridge delay on Arbitrum) in the Garden to move our governance infrastructure to another side chain/L2, eg xDai.

[sacha]

this is great news. any reason why you’re not starting with a modified Nimbus implementation too?

[d10r]

@willjgriff

If this is accurate https://l2fees.info/ then as of 22/09/21 it looks like Arbitrum fees are about half of Optimism’s.

Interesting, thx for the link.
When I clicked it, Optimism was cheaper. After a refresh a few hours later, it’s now the other way round.
Looks like they’re pretty similar on average though.

For me the race Arbitrum vs Optimism doesn’t have a winner as long as none can provide tooling for reliably running your own node and for enforcing the correct state on L1 in case of a dispute. If I need to rely on a 3rd party RPC, the whole point of inherited L1 security is moot. We’ll see…

[sacha]

‌ While the Eth 2.0 staking deposit contract has attracted an impressive number of validators (200K+), these validators must each contribute 32 ETH to participate. This amount is out of reach for many blockchain users centralized exchanges are pooling funds to create largely connected staking pools which may limit overall decentralization.

Agree with this analysis, It’s a concern which i share deeply

sacha🎗 (unixpi)

But it isn’t clear to me how you plan on preventing a similar problem from happening on xdai.

While it’s unlikely that large staking pools will choose to run SBC validators, what’s stopping a handful of individuals (or DAOs) from controlling a significant % of the keys?

Have you considered using something like BrightID to try to limit the amount of validators any one individual or entity can run?