-
Notifications
You must be signed in to change notification settings - Fork 145
The scope of beacon chain MVP #136
Comments
@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 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. |
Ah, I think our intention was preventing |
@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.
Food for thought. |
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
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. |
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 Maybe something like: |
I'm 👍 on whatever you all decide. |
Sure, I'm good with a more traditional name. What about |
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. |
shall we close this issue? it seems like we have incorporated the decisions to make here so we can move on |
Beacon chain MVP testnet
Motivation
To have a basic runnable beacon chain client as the base for farther iterations.
Scope
Serializable
interface.new reposhard_block_root
]hash(slot_number)
]The text was updated successfully, but these errors were encountered: