Do you think the current beacon chain spec has this built-in incentive in place?
I’m not sure it’s the proper place. It’s a little bit higher level than that (the “why”, not the “how” the spec provides us). I think it seems complete enough, basically we can place the ETH 1 light client code in the beacon chain and process deposits directly in the protocol. @AlexeyAkhunov is right though there may be a dis-incentive for ETH 2 Validators to process them, but it works at a small scale by optimistically assuming Validators won’t try to cheat. I think working through the incentive model a bit may definitely be called for.
Thanks everyone who joined the initial warm-up discussion. Now to the mechanics of the group formation. I do not create working groups for living, but my intuition and experience from other WGs in Ethereum 1x so far tell me that for a WG to be active and successful, it needs a leader who properly dedicates time to the work (ideally full-time, but at least 50% time I would say), and then perhaps some more dedicated people.
To preempt the questions about funding, I would say that if we found a suitable leader (not necessarily an expert in beacon chain) initially, and perhaps some more people to help out, a decent funding would be provided.
Other working groups would participate in work reviews (we will be regularly talking to each other and review each other’s work, as it is necessary to come up with consistent roadmaps), and if a group becomes inactive, we should fold the group (with funding going away obviously), and allow a new group to form.
If you want, please DM me (or post here if you are comfortable with it), how much of your time you would dedicate to the group (provided that this time will be paid), and how confident you are about becoming the leader.
4 Likes
Hi! Just wanted to let y’all know I’m glad to be involved with this working group but cannot take the “lead” at the moment. I am very pro this initiative, so excited to see it get some momentum 
4 Likes
I am going to ask the dumb question. Why does there need to be a bridge with separate tokens? Can’t miners receive a block reward and proposers receive a finalizing reward all using the same ETH?
I went back and rewatched the presentation and can see the beacon chain is happening separately to the PoW. It makes sense that the validators have their mechanism for reaching consensus between themselves outside of the main chain. It also makes sense if more is happening on the beacon chain (i.e., full proof of stake) that value is exchanged throughout those blocks. But, in the case where the beacon chain’s sole purpose is to finalize the main chain, can’t we reduce complexity under that assumption? Things like balances would not need to change. This simplification may also be an answer to Alexey’s proposed problem of encouraging agreement on an Eth1.X block if proposers are unable to get paid until they do so.
1 Like
Because we’re dealing with two separate chains. There are ways to mix the two together more deeply than what a bridge mechanism usually implies, since we may be able to make protocol changes at later stages, but we can’t change the fact that they’re two separate chains with two separate (but interrelated!) tokens.
There’s a fundamental question here of what the Beacon chain should do when we make this upgrade. Shall it live forever in this role, and later Phases end up with their own testnets as the ETH 2.0 roadmap moves forward? Is this the first “release” of the ETH 2.0 chain, that will be there forever and ever?
By integrating things too closely too early, we might bind our hands to future upgrades, which is something I don’t think we should do. I think we should identify the requirements and constraints we have, as well as the minimum goals we seek to achieve with this project.
1 Like
Hi. I am excited to contribute to this project part time.
1 Like
@AlexeyAkhunov i’m keen to lead the efforts here… i’m involved w/ eth2.0 and have enjoyed seeing this idea develop. been looking for a way to help out w/ eth1.x and this seems like a good point to jump in i’ll message you directly to discuss further
4 Likes
Please do, and thank you for checking in!
Depends how you define “different tokens.” If they can be moved bidirectionally, and further, the two chains have similar security guarantees, then in practice they should be fungible and function like a single logical token.
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.
1 Like
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. 
1 Like
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