Title: Finality_gadget_for_Ethereum1x_Working_Group
Category: Working_Groups

Author: AlexeyAkhunov
Date: 2019-04-23T19:14:34.634Z

This is to discuss the idea of launching this working group, and also for people who are interested in working on this to check in.
Note that the group has not formed yet, but I expect it to happen fairly soon.
Now the videos are up, here is my short kick-off presentation
And here are the slides: https://drive.google.com/file/d/16KLZKAutK79NxMh8L7B6hpNKuoOaAPZT/view

Author: fubuloubu
Date: 2019-04-23T20:36:59.718Z

Very cool! I think this would go a long way towards demonstrating the power and robustness of the PoS mechanism.
It may or may not be obvious, but it seems this comes in two stages:

Beacon chain does sufficiently well finalizing “ETH 1x data” for a given amount of time (how much time? 3 mos? 6 mos?)
Beacon chain’s block finalizations are integrated somehow into consensus of ETH 1x chain (hard or soft fork? maybe in the mining software to reduce uncles? can we revert/reduce the effects if it doesn’t work?)

I think it’s important here to gradually incorporate this mechanism over time as it proves itself to work. We have to de-risk this combination enough in practice that it doesn’t get abused when vulnerabilities are discovered that we didn’t know about (“when” not “if”)
Also, is step 1. needed to process deposits?

Edit: I guess I’m saying I would like to be involved haha

Author: terence
Date: 2019-04-23T20:49:55.552Z

I’d love to be involved. A little back ground for myself, I’ve been working and researching ETH2 just over a year. Here’s something I’m looking to implement in my spare time: https://github.com/ethereum/eth2.0-specs/tree/dev/specs/light_client (Besides working on beacon chain  )

Author: poemm
Date: 2019-04-23T21:16:54.158Z

First a summary, then feedback.
A summary in my own words: Originally, it was proposed that a PoS-based gadget would finalize the PoW chain. In June 2018, this plan was abandoned in favor of Eth2. In December 2018, it was proposed to salvage the original finality gadget plans – Eth2 clients must be aware of recent Eth1 block hashes to decide on Eth1 to Eth2 validator deposits, but deciding on validator deposits may be interpreted as Casper votes, which may finalize the Eth1 chain. For this to work, Eth1 clients would have to change their fork-choice rule to monitor the beacon chain, perhaps as an Eth2 light client, so that they can honor the finalization of blocks.
Feedback: I believe that an earlier plan was to replace PoW with full PoS, not just finality. Of course, finalization alone brings great value and should be considered alone. But perhaps it would be wise to also consider further steps to replace PoW with PoS. This would solve the ASIC miner centralization problem, and allow reducing block rewards significantly.

Author: boris
Date: 2019-04-23T21:18:55.465Z

poemm:

Feedback: I believe that an earlier plan was to replace PoW with full PoS, not just finality. Of course, finalization alone brings great value and should be considered alone. But perhaps it would be wise to also consider further steps to replace PoW with PoS. This would solve the ASIC miner centralization problem, and allow reducing block rewards significantly.


This is a way to make use of the ETH2 beacon chain on ETH1. The plan for ETH2 is still full PoS.

Author: poemm
Date: 2019-04-23T21:36:02.412Z

boris:

This is a way to make use of the ETH2 beacon chain on ETH1. The plan for ETH2 is still full PoS.


I proposed that we also consider full PoS on Eth1.

Author: AlexeyAkhunov
Date: 2019-04-23T21:37:19.261Z

Thanks to people who already checked in and started the discussion. To make it more interesting, I would like someone to answer the first open questions (by studying the beacon chain specification and confirming or refuting my own answers) that I mentioned in the presentation:

Is it possible for Beacon Chain block proposers to never agree on the eth1 block (i.e. to never produce at least 513 out of 1024 “votes”)? My answer is YES

Do Beacon Chain block proposers have an incentive to never agree on the eth1 block? My answer is YES


Change my mind

Author: terence
Date: 2019-04-23T21:48:34.009Z

1.) Yes
2.) Yes, but I was under the impression by doing so beacon chain won’t reach finality and the proposers and validators will lose out on reward and even more $$ when quadratic leaks kick in.
I raised a concern a while back about there’s an incentive for proposer to stall on eth1 deposit: https://github.com/ethereum/eth2.0-specs/issues/539
then it was addressed here: https://github.com/ethereum/eth2.0-specs/pull/758

Author: poemm
Date: 2019-04-23T22:13:02.243Z

AlexeyAkhunov:


Is it possible for Beacon Chain block proposers to never agree on the eth1 block (i.e. to never produce at least 513 out of 1024 “votes”)? My answer is YES
Do Beacon Chain block proposers have an incentive to never agree on the eth1 block? My answer is YES




It is unclear what “agree on the eth1 block” means. If you consider that a vote on a block is also a vote on all earlier blocks, then a random sample from a population which includes a 2/3rds honest majority (which Eth2 assumes) will “agree” on at least the genesis block with high probability.
Sure, as you explained in your linked talk, beacon chain block proposers may have incentive to prevent new validators. Your and @terence 's proposed economic incentives are a reasonable solution to this problem.

Author: fubuloubu
Date: 2019-04-24T02:57:24.419Z

AlexeyAkhunov:


Is it possible for Beacon Chain block proposers to never agree on the eth1 block (i.e. to never produce at least 513 out of 1024 “votes”)? My answer is YES
Do Beacon Chain block proposers have an incentive to never agree on the eth1 block? My answer is YES



Spot on. There must be some built-in incentive to ensure this bridge connection is strongly maintained in both directions (ETH 1->2 deposits, and ETH 2->1 finality). It’s essentially a bit of an oracle problem unless we graft an ETH 1 light client into the ETH 2 protocol (which will not be sustainable long-term), and a ETH 2 light client into the ETH 1 protocol. I’m more in favor of a “lighter” approach in this regard, perhaps something like the bonding for ETH 2 Validators is “temporary” (i.e. set from ETH 1 deposit contract, but not used to run what will later be the ETH 2 “main net”), and have that feed back as an extension to miners to have reduced uncle rates or something else beneficial without grafting it to the ETH 1 protocol directly.

Author: terence
Date: 2019-04-24T04:51:42.730Z

fubuloubu:

There must be some built-in incentive to ensure this bridge connection is strongly maintained in both directions


Do you think the current beacon chain spec has this built-in incentive in place?

Author: fubuloubu
Date: 2019-04-24T05:28:09.347Z

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.

Author: AlexeyAkhunov
Date: 2019-04-24T08:14:19.501Z

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.

Author: djrtwo
Date: 2019-04-26T00:18:47.309Z

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

Author: MadeofTin
Date: 2019-04-27T00:59:07.517Z

fubuloubu:

Spot on. There must be some built-in incentive to ensure this bridge connection is strongly maintained in both directions (ETH 1->2 deposits, and ETH 2->1 finality). It’s essentially a bit of an oracle problem unless we graft an ETH 1 light client into the ETH 2 protocol (which will not be sustainable long-term), and a ETH 2 light client into the ETH 1 protocol.


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.

Author: fubuloubu
Date: 2019-04-27T02:45:30.398Z

MadeofTin:

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?


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.



 MadeofTin:

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.


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.

Author: cyberbono3
Date: 2019-04-29T18:25:09.268Z

Hi. I am excited to contribute to this project part time.

Author: ralexstokes
Date: 2019-04-30T01:20:20.071Z

@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

Author: AlexeyAkhunov
Date: 2019-04-30T05:54:25.391Z

ralexstokes:

i’ll message you directly to discuss further


Please do, and thank you for checking in!

Author: lrettig
Date: 2019-05-01T14:00:28.408Z

fubuloubu:

we can’t change the fact that they’re two separate chains with two separate (but interrelated!) tokens


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.

Author: fubuloubu
Date: 2019-05-01T14:25:41.972Z

lrettig:

If they can be moved bidirectionally


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.



 lrettig:

further, the two chains have similar security guarantees


I’m not sure how this follows, but I suppose in the hybrid case where both are securing each other, this might be true.



 lrettig:

Depends how you define “different tokens”… they should be fungible and function like a single logical token.


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).

Author: markkat
Date: 2019-05-01T17:01:10.073Z

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.

Author: fubuloubu
Date: 2019-05-01T18:33:27.391Z

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!

Author: markkat
Date: 2019-05-01T19:01:45.669Z

fubuloubu:

Is your intent to create a differed deposit, that will only really be active when ETH 2.0 sees a real deployment?


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.

Author: fubuloubu
Date: 2019-05-07T21:54:06.235Z

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

Author: terence
Date: 2019-05-09T04:03:20.271Z

fubuloubu:

Prysmatic Labs has released a Testnet for the Phase 0 Beacon chain that includes a deposit contract on Goerli


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

Author: fubuloubu
Date: 2019-05-14T22:33:07.556Z

@ralexstokes has a great primer on the Finality Gadget, laying out the benefits and concerns of the approach.
Check it out here:
https://medium.com/@ralexstokes/the-finality-gadget-2bf608529e50

Author: fubuloubu
Date: 2019-05-14T22:46:20.064Z

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):



 fubuloubu:

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 eve


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!

Author: fubuloubu
Date: 2019-05-23T00:52:32.678Z

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.

Author: timbeiko
Date: 2019-05-23T17:59:25.511Z

fubuloubu:

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.


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.

Author: fubuloubu
Date: 2019-05-23T18:21:27.056Z

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.

Author: timbeiko
Date: 2019-05-24T14:00:18.859Z

fubuloubu:

That is a potential option, although that sounds a bit too short of a timeline for my taste.


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.

Author: fubuloubu
Date: 2019-05-24T14:23:38.336Z

timbeiko:

Finality Gadget live at the same time as the beacon chain launches .


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.

Author: timbeiko
Date: 2019-05-24T14:42:51.089Z

Got it, will wait for your post, then!

Author: fubuloubu
Date: 2019-05-28T01:21:41.887Z

Link to Tweet (linking to Medium, for free access!)
https://twitter.com/fubuloubu/status/1133181265870544899

Author: boris
Date: 2019-05-28T01:23:19.991Z

Just turn off the check mark that makes it part of the paywall.

Author: fubuloubu
Date: 2019-05-28T01:35:40.533Z

Oh, well I did do that, so it should be all set anyways!

Author: timbeiko
Date: 2019-07-10T18:15:36.500Z

@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!

Author: AlexeyAkhunov
Date: 2019-07-11T14:36:32.448Z

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

Author: fubuloubu
Date: 2019-07-12T12:54:14.940Z

He’s doing a workshop on this topic next Friday at this event: https://www.buildeth.io/

Author: ralexstokes
Date: 2019-07-12T17:48:17.125Z

@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.

Author: ralexstokes
Date: 2019-07-12T17:50:48.824Z

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!

Author: timbeiko
Date: 2019-07-12T18:02:03.931Z

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.

Author: ralexstokes
Date: 2019-07-12T18:27:53.122Z

totally – will update you once we start finding a time

Author: tvanepps
Date: 2019-07-22T14:32:24.991Z

Would love to be on this call, let me know when anything materialises!

Author: ralexstokes
Date: 2019-08-02T02:21:02.890Z

Hi everyone,
I would like to suggest we do a working group call on 8/15 at 20:00 UTC on zoom. If anyone very much wants to join then and can’t, let me know and we can try to reschedule. If you can confirm in DM across some channel, that is also very appreciated 
I’ve started work on an agenda/working group organizing doc which I’ll share ahead of time. I’d imagine the first call will mainly be discussing the scope of the group and the first steps on the project.
I also imagine it will be recorded to share after the fact.
Cheers!

Author: timbeiko
Date: 2019-08-02T17:47:06.097Z

I won’t be able to make it on that date. It would be great if there are notes or a recording made available

Author: tvanepps
Date: 2019-08-12T00:55:57.367Z

Alex is it still the plan that we will have a call on the 15th?

Author: ralexstokes
Date: 2019-08-12T01:33:32.205Z

Yes, lets do the above time, I’ll follow up w/ a zoom link beforehand and should be able to record the conversation for anyone who wants to follow along asynchronously.

Author: fubuloubu
Date: 2019-08-12T19:32:50.230Z

Added it to my calendar

Author: ralexstokes
Date: 2019-08-12T20:03:35.670Z

Hey all, here’s a Telegram group for those who want to coordinate that way.
I’ll do my best to ensure important data is posted both there and here.



Telegram



Telegram: Contact @eth1x_finality_gadget

Author: ralexstokes
Date: 2019-08-15T02:42:28.129Z

Topic: Finality gadget working group - call #0
Time: Aug 15, 2019 01:00 PM Pacific Time (US and Canada)
Join Zoom Meeting


Zoom



Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise cloud communications.





^^^ call details for our first meeting in ~17hrs.
This first call is mainly organizational to see who is interested and in what capacity they can help.
I should be able to record it to share after the fact and should be able to take some rough notes as a transcript.
edit: here is some agenda: Finality gadget (FG) working group - call #0 - HackMD (happy to take suggestions)

Author: ralexstokes
Date: 2019-08-15T19:51:13.482Z

^ Our kickoff call is in 10 mins!

Author: wesgraham
Date: 2019-08-23T10:24:54.581Z

Count me in @ralexstokes