We should discuss this as a requirement. My current understanding is that the bridge might only work uni-directionally, but there are benefits to allowing a bi-directional bridge.
I’m not sure how this follows, but I suppose in the hybrid case where both are securing each other, this might be true.
The crux of this being true depends on the bridge mechanism and issuance. I would say they are only “fungible” if 1 ETH = 1 bETH (sorry, but we need something to call the ETH 2.0 token). This probably means that there shouldn’t be any issuance on the Beacon chain until we decide the mechanism can support hybrid operation, and then we split the issuance between mining rewards and validator rewards. But, if we do that, it means there is no economic incentive to become a validator on the beacon chain (there’s probably social incentives). I think in practice, we have to have some economic incentive, but this should be artificially limited to our level of trust of the hybrid model.
It’s unfortunately much more complicated than “1 ETH = 1 bETH”. The closer we tie these tokens together, the more we have to legitimize our decision and ensure the issuance is moved from a legitimate source. If we create more issuance out of no where, that’s a problem.
The alternative is to just create a separate chain and supply of tokens, but have an in-protocol exchange mechanism that derives the price. This would be a much more fluid mechanism, and we wouldn’t have to be held to “1 ETH = 1 bETH”. This probably has its own complications as well. Think of it as a continuous ICO model where all the ETH is refundable at any time (like a DAICO).
This may be a very naive suggestion, but could ETH deposits for ETH2 validation not be reflected in bETH, but only generate bETH rewards which are frozen until a migration phase?
ETH could even be withdrawn from deposits, but in doing so, could wipe bETH earned by that deposit.
This would create a deposit incentive that grows as bETH rewards grow, but could make ETH deposit recovery effortless in the case of failures.
Not a bad suggestion! Yeah, there’s a lot we can do with a smart contract, but we have to play in the confines of the chain. Thankfully, we have a community with a lot of experience of bridge technologies, Plasma, etc. so it’s simply a matter of defining what requirements are and de-risking our implementation as you suggested.
Is your intent to create a differed deposit, that will only really be active when ETH 2.0 sees a real deployment? The problem there may be what constitutes a “real deployment”, and at which stage in the process do we make this decision (and how). I think you’re on a good track here, but this needs to be thought through pretty deeply because there’s a lot of moving parts!
Yes, that’s the intent. I suppose I see “real deployment” being the phase at which the reward bETH are unfrozen. Def not sure about the when and how; but until then, I envision an ETH2.0 that doesn’t promise persistence beyond the accumulation of the bETH rewards.
Just food for thought. I think I need to better understand the spec to offer much more than that.
To clarify this deposit contract is not the official one from the ETH2 repo. We used beta parameters (lower deposit amount and validator count) and we implemented a drain function to recycle testnet ETH
One question I do have is that there doesn’t seem to be a good understanding of what happens to the issuance if we do choose to do a reduction, specifically in relating to the incentivization of the ETH 2.0 Beacon chain. We have some great charts on the potential returns based on the number of ETH participating, but where does this ETH get it’s “legitimacy” from? This is not clear to me based on my current knowledge of the design.
I would claim that the legitimacy of this Ether must come from the current 1.0 chain. The way I would propose to do this would be to route the appropriate amount of issuance that the Validators would earn on the ETH 2.0 chain to the smart contract bridge that processes deposits, basically increasing the pool (and therefore individual’s proportional claims to that Ether) until the amount of rewards being generated from 1.0 issuance matches the expected returns generated by the 2.0 protocol. We can use this parameter to ratchet up the “importance” of the validator functionality over time; basically, as we grow more and more confident in the proper functioning of the mechanism (both economically and securely), we can involve it more and more into the actual issuance of the 1.0 chain. This might also be along another parameter that controls that amount of issuance given to existing 1.0 PoW miners, giving us two knobs to fiddle with and dial in the “right” amount of issuance as validation progresses.
The one thing I am not sure about with this approach is what this means for 2.0 protocol. Does it generate more 2.0 tokens than we have to cover it in the 1.0-2.0 bridge? Is there an economic disconnect there? I am not as familiar with the staking/rewards mechanism to know the answer to this question, but hopefully we can exert some measure of control over it to align it with what is occurring on the 1.0 chain.
This does lead me back to a previous question I asked (and I don’t think we have a good response yet):
If the Beacon chain fulfills this role temporarily (until Phase 1 is released), how do we manage that upgrade process? Conversely, if the Beacon chain is intended to have this connection forever, how do we ensure the transition from 1.0 → 2.0 at a later phase (either Phase 2 or Phase 3, based on my current understanding of the roadmap) is smooth, both in the operation of these chains, as well as the continued economic issuance that is occuring on both (since the “issuance origin” will need to switch from the 1.0 chain to the 2.0 chain at some point along the upgrade process).
Talking with @djrtwo this past week, the answer to my question is that indeed, when we first launch the Beacon Chain and connect it to the current Mainnet, that will permanently cement this upgrade into the history of both ETH 2.0/1.0. This means that this finality gadget (and corresponding bridge contract) is now on the critical path for what it means to do a release for Phase 0. Further Phases will build on top of this instead of releasing their own networks to move forward. At least, that is the intent.
Okay, so what does that mean? I think it means that the easiest way to ensure that issuance stays consistent is to process the issuance reduction to miners and the issuance redirection to 2.0 Validators at the same time: at the genesis block of the Beacon Chain mainnet. If both do not occur together, then we have to answer the question of what the Beacon Chain’s Ether is valued at without the underlying issuance changes in ETH 1.0 backing up the “new” issuance in ETH 2.0. The ETH 1.0 protocol should therefore match 1-to-1 the supply schedule that has been defined for ETH 2.0, and track that in the balance of the bridge contract, even though it is uni-directional. This gives the underlying Beacon Chain ETH value that is tied 1-to-1 to the current mainnet. Accounting for burning ETH on the Beacon Chain would be more required to maintain this peg, so that might complicate the bridge mechanism a bit.
The alternative is that if we do not do this, then there will always be a small gap in the issuance on both chains, and therefore the two Ethers are not considered 1-to-1 pegged. This doesn’t necessarily have to be a bad thing. Since Ether is also burned for a few different scenarios, perhaps as value gets ported over and starts to track issuance on both chains together, we can level set such that they eventually equalize. At the point of equalization, we can then say the upgrade is “complete”. Might be a weird mechanism to track in practice, but then we have a deadline that is driven by adoption and not artificially maintained by abandoning the current mainnet at date X.
So, practically speaking, if the Beacon Chain is to launch on Mainnet for 2020Q1, and we follow the 6 month cadence described in this thread, the issuance change on ETH1 would have to either be as part of a single-EIP hard fork or as part of an April 2020 one (meaning Q2).
This means the EIP would have to be ready for November 2019, at which point details about the beacon chain’s launch may be more fleshed out.
That is a potential option, although that sounds a bit too short of a timeline for my taste.
Another option might to target a later fork for this protocol modification. Prior to that, we would try an “economically incentivized” testnet by leveraging the same bridge contract and protocol version we want for a mainnet release, and have a grant that rewards the Validators at regular intervals (in the exact same way as the protocol modification would). We would do this for a few months leading up to the final protocol change, where issuance is being redirected.
This would allow us to “scale up” our risk before committing to the protocol modification, and prevent unleashing a torrent of issuance to a new, economically unproven mechanism. Something like 1%-5% of what the funds would be for a few months of this activity would be enough to see what sorts of behaviors arise. If there are bugs, we much rather see them with grants funds than the future of our chain’s security issuance, where it would be much harder to revert back.
This would probably be about 500-1000 Ether. I think about 1 YOLOs-worth of Ether would be enough for this. Deadline DevCon 2020?
Edit: If the Beacon chain testnet has the same problem as the Ropsten testnet (which is probably likely due to the lack of incentivization), then we’re going to need this sort of progressive approach to assure ourselves we’ve got the mechanism right. I would argue anything else is needlessly risky.
Ok, I think that’s where we misunderstood each other I thought you were implying that we should aim to get the Finality Gadget live at the same time as the beacon chain launches. To me that felt really quick, and I was proposing what I thought could be the quickest possible way to do it without breaking the ETH 1.0 HF process.
This actually is what I’m proposing, but not before an extensive verification process of the Beacon chain with some smaller scale incentivized validation occuring.
I have a post I’m working on that will make it clearer what I’m suggesting and why it’s important that they work together to ensure legitimacy of ETH as an asset.
@ralexstokes@AlexeyAkhunov@djrtwo, what is the status of this working group? This seems like a pretty crucial initiative for Ethereum and I’m wondering if there is anything that the Ethereum Cat Herders could help with, process-wise, to move it forward.
I am assuming it is dormant, unless @ralexstokes says otherwise. I have not been pushing thing in this direction, because of limited time and energy I have
I thought you were implying that we should aim to get the Finality Gadget live at the same time as the beacon chain launches. To me that felt really quick, and I was proposing what I thought could be the quickest possible way to do it without breaking the ETH 1.0 HF process.