mGNO (bridged with OmniBridge to the Ethereum Network)
Upcoming variants of Gnosis governance token:
GNO (bridged from Ethereum with zkSNARK - Succinct to Gnosis Beacon Chain)
GNO - prev. OmniBridge (bridged from Gnosis Beacon Chain with zkSNARK - Succinct to Ethereum Network)
mGNO (bridged from Gnosis Beacon Chain with zkSNARK - Succinct to Ethereum Network)
To prevent confusion, there should be only one governance token which is native on the Gnosis Beacon Chain imo. I guess the best way would be to exchange all GNO (on the Ethereum Network and Gnosis Beacon Chain) for mGNO and rebrand mGNO to GNO in a final step. So mGNO would only exist during the transition period towards the GBC and a few month afterwards.
I think this is an important step forward in maintaining investors and customers confidence in the Gnosis ecosystem. The simplicity could also attract new people and prevent low liquidity hassles on DEXes with the tokens. To keep the diversity of token variants (legit ones) as low as possible should always be the goal because it reduces complexity and costs.
There is no point in merging GNO to mGNO, since mGNO is a derivative of GNO.
Seems that the simplest to do would be to convert all mGNO back to GNO, have Validators stake GNO directly and eliminate mGNO.
Staking GNO directly will dramatically simplify staking process, running Validator nodes, and reduce by a factor of 32 (ratio of mGNO to GNO) the number of āvalidatorā instances that need to be pointlessly run for the pure sake of staking.
Removing these thousands of superfluous Validator instances with the remaining instances staking at 32X the current amount simplifies participation, increases urgency and importance of properly maintaining oneās Validator Node and will dramatically improve Gnosis Chain Network performance by eliminating network chatter and bandwidth consumption by a minimum factor of 32.
It would not be a merge of GNO and mGNO. GNO would just being swapped into mGNO.
Sticking to the Becon Chain model of Ethereum would have a lot of benefits because because GnosisDAO would not have to maintain a complet new variant of the Beacon Chain framework. Variant diversity is quite costly (we experience this rn if we look at the xDai/GC PoS ā GBC PoS merge compared to the PoW ā PoS Ethereum merge).
We should always have in mind that the ability to adopt Ethereum Beacon Chain updates in the future (maybe with small changes) gives Gnosis a huge advantage over competitors who have to develop their entire base infrastructure themselves.
@m3rlin5ky
Generally you are right at pointing our unnecessary complexity. I also agree that GNO should be primarily on GnoisisChain. A good point in time for this is when we allow withdrawals from the GBC.
@1proof A quick note why we set the amount of to 1 GNO instead of 32 GNO was to emulate Ethereum. There are 120m ETH which means the maximum theoretical number of validators is: 3.75m. After the decision of the DAO to burn 7m GNO, GNO has a supply of only 3m. If we had required 32 GNO is would not even be possible to reach 100k validators. Even by requiring 1 GNO we have a lower max validator count than Ethereum.
The step on the other hand to introduce mGNO was done to make the modification for CL (consensus clients) as small as possible and scale up to the number 32 which is hard coded in most clients.
GNO (bridged from Ethereum with zkSNARK - Succinct to Gnosis Beacon Chain)
One more comment - this is not our intention. The intention is instead to upgrade the existing Omni bridge to the zkSNARK-based model to increase its security without creating disruption on the chain by introducing 2 versions of every token. A first step will likely be a hybrid solution that still uses the current validator (aka multisig) approach but combines it with the zkSNARK approach. Only if both āagreeā tokens are bridges - if they disagree (a bug or the validators being compromised) the bridge is halted and escalated to governance. Eventually, once ZK-SNARK-based approaches are battle-tested it can fully be migrated to those.
