Prysmatic Labs has released a Testnet for the Phase 0 Beacon chain that includes a deposit contract on Goerli
“Ethereum 2.0 Phase 0 Testnet Release” by Preston Van Loon https://link.medium.com/VUVRShUrvW
4 Likes
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
1 Like
@ralexstokes has a great primer on the Finality Gadget, laying out the benefits and concerns of the approach.
Check it out here:
1 Like
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).
Hard questions!
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
Got it, will wait for your post, then!
Link to Tweet (linking to Medium, for free access!)
1 Like
Just turn off the check mark that makes it part of the paywall.
1 Like
Oh, well I did do that, so it should be all set anyways!
@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.
Thanks!
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
1 Like
@timbeiko @AlexeyAkhunov @fubuloubu hey team! things are far from dormant 
there hasn’t been a ton of activity on this thread but i spoke a bit to @fubuloubu and @cyberbono3 about how we will move forward. i think this is an important initiative for today’s community to get value out of eth2.0 right out of the gate in phase 0. like bryant mentioned i will be speaking about the finality gagdget (and some of the other ways eth2.0 can help eth1.x at each phase) next week and also in berlin at dappcon/ethberlin. so will definitely want to catch up w/ any of you there!
in terms of status, it sounds like we may need a few more conversations to all get on the same page about what the FG will do and what place it has in eth1.x. there hasn’t been too much value in having these conversations to date as the eth2.0 spec was still undergoing revision; with the phase 0 spec freeze, we have something quite tangible to work off of it appears to me that the concrete functionality is clear, what is less clear is the timeline and how the two systems will interact. i feel pretty strongly that we need to first and foremost have a stable beacon chain network before we think about any sort of eth1.x HF. that is not to say the prototyping/EIP-drafting phase can’t happen in parallel (in fact now is the time to start!) but i don’t think it wise to try to target launching the eth1.x FG without having seen a stable beacon chain mainnet for some time – I would think months but this is part of the conversation we need to have.
given the importance of getting this initiative correct (we will be directly modifying the consensus protocol) I think the HF timeline should be supply driven, rather than demand driven; i.e. we will ship when its ready and not worry about fitting into the existing HF timeline. if that means we have to wait some months for the next upgrade to roll around then i would personally be ok w/ that.
i can’t think of anything in particular the cat herders could help w/ but perhaps i don’t fully understand the scope of their abilities so if there is any way you think they can be helpful plz let me know! i think having more process/coordination help will be more useful the closer we get to a final EIP and will want to move towards deployment.
3 Likes
at this point, it sounds like we should have a call to discuss what this initiative will look like and how it will play out, timeline wise. i can put together a strawman document for timeline, etc. and then can organize a call w/ whoever is interested. ping me here or on telegram (same handle @ralexstokes) and i’ll keep you in the loop. i’ve heard of interest from @fubuloubu @cyberbono3 @terence and @atoulme – if @timbeiko or @AlexeyAkhunov want to join, that would be great – and if anyone is reading this and wants to join the fun, let me know!
4 Likes
Thanks for sharing, @ralexstokes!
Happy to hear about the progress and I agree that this is something we want to do right over doing fast.
I’d love to be part of a call about the initiative if you set one up. The Cat Herders don’t really have a fixed mandate, so having more context would help me think about if and how they could add value.
1 Like
totally – will update you once we start finding a time
1 Like