The scope of beacon chain MVP

[hwwhww]

Beacon chain MVP testnet

Motivation

To have a basic runnable beacon chain client as the base for farther iterations.

Scope

1. Serialization: RLP
   1. Hashing will be inefficient because no tree but the number of validators will be small in testnet so probably okay.
   2. SSZ is nice to have but RLP is okay stub as long as SSZ will eventually use same Serializable interface.
2. Network layer: devp2p
3. Validator Client -> new repo
   1. Minimal RPC interface to trinity
   2. Block proposal and Attestations [stub shard_block_root]
   3. Simple key management
4. Local attestation aggregation
   • The beacon block proposer will aggregate the attestations.
5. Fork Choice [slot number or longest chain]
6. State transition (ordered by importance)
   1. Shuffling (required)
   2. FFG Finality (required)
   3. Crosslinks (required)
   4. RANDAO [could use stub: hash(slot_number)]
   5. Reward/Penalty
   6. Slashing
   7. Registration/Logout

[cburgdorf]

@pipermerriam @carver what is your stance on where to put the validator client? Since this will be a separate program it could live in a separate repository. I would however, prefer to keep that in the same repository for the time being pretty much for the same reasons why Trinity is still in this repo.

I believe a separate repository (especially at this early phase) will just complicate the development and review process (e.g. "Please checkout PR4711 in <second-repo> which builds on PR4712 in <first-repo>".)

I will bring up again that, for the same reasons, I still prefer keeping Trinity-Validator / Trinity / ETH in one repo forever (mono repository) but even if we don't do that I'd prefer we at least keep it in the same repository for phase zero.

[hwwhww]

one repo

Ah, I think our intention was preventing Py-EVM from poisoned by some experimental validator client design in the early stage. And to be clear we definitely love, need, and appreciate Python team's reviews, so if you guys feel it's okay to let the validator client module stay in py-evm repo, I'm totally fine with that. :)

[cburgdorf]

@hwwhww There's a high chance that @pipermerriam and @carver will prefer to have it in a separate repository. I think I'm a little alone here with my preference for mono repositories. I still think it's worth bringing it up again though.

Especially for the birth of the software. If we move it out eventually, so be it, but I believe in the beginning it will just make development harder.

1. I guess the validator software will be a consumer of the eth module so having it separate will cause a lot of PRs that need to be reviewed in tandem

2. I guess that there are also primitives in the trinity module that the validator might want to use which means there would be another reason for more difficult PRs where a PR in validator client builts on another PR in Trinity

3. Trinity is moving in a direction where the core is getting smaller and more functionality is provided through plugins. We'll probably have the entire syncing as a plugin eventually. In that vision, the validator client can very well just sit directly in the Trinity code base. The beacon chain node and the validator node would still be two different programs in the sense that they are started with their individual commands and each spawn completely independent OS processes, but they would share a lot of common infrastructure code wise.

Food for thought.

[carver]

I still prefer keeping Trinity-Validator / Trinity / ETH in one repo forever (mono repository) but even if we don't do that I'd prefer we at least keep it in the same repository for phase zero. ... I think I'm a little alone here with my preference for mono repositories.

Heh, in the long run, yes, I think there is broad-ish agreement about smaller, focused repos. It's already been valuable in a number of cases, even though it comes with some costs. But there is not much urgency to separate them all out in the short run. (In fact, the opposite: there is value in evolving them together until we understand the problem space)

Trinity and py-evm, though, are already getting to a place soon where they could be separated without much pain, I think. It would be interesting to do a review of the 10-20 most-recently merged PRs, to see which ones touch both eth/ and (p2p/ or trinity/).

Ah, I think our intention was preventing Py-EVM from poisoned by some experimental validator client design in the early stage.

I'm not worried about this, we can handle volatile code that comes and goes, as long as it's isolated from the more stable bits that trinity depends on now. So I'm actually in favor of putting it in the same repo while it evolves, but with the architecture and intention of separating it out at some point.

[cburgdorf]

Thanks for your input @carver Then, I'd say we start with a new top level module in this repo and probably move it together with Trinity when the time comes. Any naming suggestions? I'd vote for gloria which is an actor from the matrix so it has some Trinity connection ;)

[carver]

Especially when there are so many supporting packages, I feel that the names should be descriptive (making very rare exceptions for end-user projects like trinity). I don't want to burden others or myself with memorizing a bunch of names, even if they're tied together with a theme.

Maybe something like: eth_validator?

[pipermerriam]

I'm 👍 on whatever you all decide.

[cburgdorf]

Sure, I'm good with a more traditional name. What about trinity-validator similar to trinity-beacon? I also think that I may actually be in favor of not creating a new top level module and just create a main_validator.py entry point similar to the main_beacon.py and see how far that will take us.

[carver]

I also think that I may actually be in favor of not creating a new top level module and just create a main_validator.py entry point similar to the main_beacon.py and see how far that will take us.

The nice thing about creating it as a top-level module is that it's a reminder to not import utils across modules. It also helps make it straightforward to eventually pull into it's own project. Not hard requirements, and some of these suggestions will likely be broken in the earliest experimentation days, but heading that direction eventually (a top-level module) seems like a good idea.

[ralexstokes]

shall we close this issue? it seems like we have incorporated the decisions to make here so we can move on