Closed gligneul closed 11 months ago
endersonmaia
commented
1 year ago First of all, nice redesign, I really believe things are going to be much simpler that way, and we'll move faster.
One thing I'm missing on the diagram, is where is the box that represents the machine-snapshots?
How are you planning to deal with them on the [machine-executor] box.
gligneul
commented
1 year ago Good point, @endersonmaia; I still have to think about this. The MachienExecutor will likely load the snapshots from a filesystem, similar to what we do today. Unlike the current node, the new one should add the reference to the snapshots in the database so the scheduler knows which one it should load. We should avoid adding semantics to the snapshot file name.
gligneul
commented
11 months ago The design evolved a lot, so I will create another issue to reflect that.
📚 Context
We are at a point where it is hard to evolve the current Rollups Node because the architecture got too complicated. I wish to rewrite the Node in a simpler monolithic architecture where all the state is centralized into an SQL database. This rewrite will be done in Golang further to improve the maintainability of the next Node version.
Below is the proposed package diagram for the new Rollups Node. All the blue boxes are Go packages that run in the same process. The new architecture is open for discussion and improvements.
Main components
The Repository should be the only way to read or write the node state. It is a layer on top of the SQL database. We can replace the SQL database with a more straightforward in-memory database when developing and testing the Node.
The inputter reads the DApp inputs from the blockchain and stores them in the Repository.
The scheduler gets the inputs from the SQL database, sends them to the Machine Executor, and stores the outputs in the Repository.
The Executor will be a high-level interface to execute the inputs. This interface will have two implementations, the Machine and the Dev one. These are analogous to the server manager and the host-server manager, respectively.
The Validator decides when to close an epoch, computes the output proofs, stores the proofs in the Repository, and sends the claim to the blockchain.
These have the same behavior as the inspect-server and graphql-server.
Advantages
The new architecture will scale inspect requests by design. It will be possible to run multiple inspect requests by forking the Cartesi machine. In the future, we may provide an inspect-only mode to scale the requests horizontally.
The new architecture should consider the multi-DApp node. We can start by adding the DApp as an entity in the node model; later, we can evolve the Node to support multiple DApps.
The new architecture will make it easier to modify the node to support the streamline proofs and the lambda machine.
Integration Branch
We should merge the PRs of this epic to the
go-nodebranch.📈 Subtasks
The epic will be divided into the subtasks below. These tasks can be broken down into smaller tasks if necessary. Notice that the SQL repository is one of the last tasks in the list because we might want to change the model during the development of the Node. So, to avoid reworking the SQL schema, we can leave it for later.