Gardens will still function on xDai, itās just 1Hiveās DAO structure thatās moving.
1 Like
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.
2 Likes
But if we want to migrate, will it be easy?
Weāre committed to making it as easy as possible for community members to move their HNY over
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).
3 Likes
@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.
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.
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.
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.
3 Likes
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.
3 Likes
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.
2 Likes
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.
6 Likes
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.
this is great news. any reason why youāre not starting with a modified Nimbus implementation too?
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ā¦
ā 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
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?
2 Likes
32 ETH equal to 111,568 USD which is definitely something most of the world canāt afford on a single household.
32 META (where 1 STAKE = 1 META) is 327 USD which should cover expenses to run a node on a cloud hosting like DO and should attract small peopleās validators.
META is required to swap STAKE to another token in the future or allow other tokens to be staked in the beacon chain.
But it isnāt clear to me how you plan on preventing a similar problem from happening on xdai.
Social signaling via delegation is a common way in delegated proof of stake consensuses like POSDAO. In a pure POS the best way will be enabling withdrawals via āthe mergeā as soon as possible to minimize impact of staking pools. Discouraging listings on centralized exchanges is another way of making āstaking as a serviceā less attractive to exchanges.
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?
Based on the information from https://www.xdaichain.com/for-validators/consensus/stake-beacon-chain-r-and-d
Security Goal Prior to Merge
20K+ validators
640K+ STAKE
letās see how distributed withdrawals keys will be
Have you considered using something like BrightID to try to limit the amount of validators any one individual or entity can run?
xDai partnered with Dappnode to make staking on physical nodes more attractive to individual hardware owners thus to make staking more decentralized.
Btw the SBC contracts are audited and we can expect launching of the network quite soon POA Network ā āStake Beacon Chain (SBC) depositā ā Chainsecurity
2 Likes
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
letās see how distributed withdrawals keys will be
Are you open to using BrightID to try to limit the amount of keys per individual?
1 Like
I like the idea to encourage using Proof of KYC to get subsidy/ extra reward but not for limiting access for non-KYCed validators
Itās not KYC. Just proof of uniqueness. You can still be pseudonymous
2 Likes
@igorbarinov I think with such an approach you could make a credible argument as to why you might end up being more decentralised than mainnet (without it, I donāt believe there will be much difference).
2 Likes