Beacon Node Refactorization

[terencechain]

With the finished replacement of active and crystallized state with single state, we can begin to refactor beacon node to adopt these changes. The updates will touch base across multiple packages including core, DB, casper, types and will open up many design questions. Let's use this as a mega issue to track the overall progress, discuss the design questions, and document the design decisions. Everyone please provide your inputs here

[terencechain]

I think there's excellent value for a pure beacon chain implementation with a solid APIs, no premade assumptions, excellent documentation. Whoever wants to use beacon-node-as-a-service can just launch that

[nisdas]

With the merging of the two states, we can simplify a lot of the things in our implementation. Now block processing only affects certain parts of the state, and with this would be a good time to also consider @rawfalafel proposal to merge in the casper package.

Although if we do go down that path, I would rather casper and state be in their own package, the types package is meant to be a wrapper for our proto objects. Do not know if it is the best idea to bring in all the casper logic into the package. The state object and the casper package, will be tightly interwined, so it might be the best idea to bring them together into one package.

Another thing this would simplify would be our blockchain service routine, instead of updating both active and crystallized we can just do it with one state, it simplifies state transitions also where we had transitions for both active and crystallized and now it can be done with one go.

Agree, on having a pure beacon-chain implementation without bringing in any other assumptions

[rauljordan]

This can be closed after now that we have our state transition function and have deleted deprecated code paths in our repo :)