-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create the new Validator component #359
Labels
Comments
After an initial discussion with the @cartesi/node-unit, we reached a consensus around the following database schema: |
Here is also a draft of a to-be-implemented API for the Validator to interact with the node's database: type ValidatorRepository interface {
// GetMostRecentBlock returns the number of the last finalized block
// processed by InputReader
GetMostRecentBlock(ctx context.Context) (uint64, error)
// GetCurrentEpoch returns the current epoch
GetCurrentEpoch(ctx context.Context) (*Epoch, error)
// GetMachineStateHash returns the hash of the state of the Cartesi Machine after processing
// the input at `inputIndex`
GetMachineStateHash(ctx context.Context, inputIndex uint64) (hexutil.Bytes, error)
// GetAllOutputsFromProcessedInputs returns all outputs produced by inputs
// sent between `startBlock` and `endBlock` (inclusive).
// If one or more inputs are still unprocessed,
// it waits for its status to change until it times out
GetAllOutputsFromProcessedInputs(
ctx context.Context,
startBlock uint64,
endBlock uint64,
timeout time.Duration,
) ([]Output, error)
// InitConfigTransaction performs a database transaction
// containing two operations:
//
// 1. Inserts a new Epoch, starting at `inputBoxDeploymentBlock` and
// ending at `inputBoxDeploymentBlock` + `epochDuration`
//
// 2. Updates the current epoch to the newly created Epoch
//
// This should only be called once to set up the first Epoch in the database.
// All subsequent calls will do nothing or, if the parameters do not match
// the values already stored, it will return an `InvalidNodeState` error
SetupFirstEpochTransaction(
ctx context.Context,
inputBoxDeploymentBlock uint64,
epochDuration uint64,
) error
// FinishEmptyEpochTransaction performs a database transaction
// containing two operations:
//
// 1. Inserts a new Epoch starting at `nextEpochStartBlock` and ending at
// `nextEpochStartBlock` + `epochDuration`
//
// 2. Updates the current epoch to the newly inserted one
FinishEmptyEpochTransaction(ctx context.Context, nextEpochStartBlock uint64) error
// FinishEpochTransaction performs a database transaction
// containing three operations:
//
// 1. Inserts a new Epoch
//
// 2. Updates the current epoch to the newly inserted one
//
// 3. Inserts a new claim in a single transaction
FinishEpochTransaction(ctx context.Context, nextEpochStartBlock uint64, claim *Claim) error
} |
The Validator tasks will now be tracked by #375 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
📚 Context
The
server-manager
, developed by the Machine Unit, is a central component in the node design, as it's responsible for handling critical tasks such as interfacing with the Cartesi Machine. For a long time, there were talks of transferringserver-manager
's ownership to the Node Unit, and this shared vision finally came to be due to the output unification effort.Since
server-manager
is a huge C++ project, to better adapt it to the architecture envisioned for the 2.0 release, it will be rewritten as two separate components: Machine Runner (#258) and Validator. Machine Runner will be the new interface with the Cartesi Machine and the Validator will handle epochs, claims, and proofs.✔️ Solution
Create a new sub-package of
node
calledvalidator
with three sequential tasks: finalize epochs, generate proofs, and create claims.Epochs will be simplified:
CARTESI_EPOCH_DURATION
parameter. The new default value will be 7200 blocks, equivalent to a day in a chain that generates new blocks after 12s.After an epoch is finished, it must generate the output proofs and update the outputs Merkle tree in the database accordingly.
After the proofs are generated, it will create the epoch's claim, although it won't be responsible for sending it: that will still be the
authority-claimer
's job. Since it reads claims from Redis, it will be necessary to write the claims to Redis. And since we will eventually remove both Redis and theauthority-claimer
the goal is to create a second, temporary component with the single goal of watching the database for new claims and sending them to Redis. Then, when the time comes to remove theauthority-claimer
we will only need to delete this smaller component instead of altering thevalidator
's code.📈 Subtasks
The text was updated successfully, but these errors were encountered: