Skip to content
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

Closed
2 of 5 tasks
torives opened this issue Mar 22, 2024 · 3 comments
Closed
2 of 5 tasks

Create the new Validator component #359

torives opened this issue Mar 22, 2024 · 3 comments
Assignees
Labels
epic A issue with several steps #feat:output-unification Feature: Output Unification

Comments

@torives
Copy link
Contributor

torives commented Mar 22, 2024

📚 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 transferring server-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 called validator with three sequential tasks: finalize epochs, generate proofs, and create claims.

  1. Finalize epochs
    Epochs will be simplified:
    • Epoch length will now be determined in terms of blocks instead of seconds, thus changing the node's 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.
    • If there were no inputs within this block interval, the epoch will be finished but no claim will be generated as there's nothing to prove.
  2. Generate proofs
    After an epoch is finished, it must generate the output proofs and update the outputs Merkle tree in the database accordingly.
  3. Create claims
    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 the authority-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 the authority-claimer we will only need to delete this smaller component instead of altering the validator's code.

📈 Subtasks

  • Define the models and interactions with the database
  • Create Mocked Validator #369
  • Write the proof-generating code in Go
  • Implement the final Validator
  • Implement the "claim-relay"
@torives torives added the epic A issue with several steps label Mar 22, 2024
@torives torives added this to the 2.0.0 milestone Mar 22, 2024
@torives torives self-assigned this Mar 22, 2024
@torives torives moved this to 🏗 In progress in Node Unit Mar 22, 2024
@torives torives added the #feat:output-unification Feature: Output Unification label Mar 22, 2024
@torives
Copy link
Contributor Author

torives commented Apr 4, 2024

After an initial discussion with the @cartesi/node-unit, we reached a consensus around the following database schema:
Rollups Node 2 0 - Database2
This might still change though, so it might be a good idea to check the original and more up-to-date diagram here.

@torives
Copy link
Contributor Author

torives commented Apr 4, 2024

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
}

@torives torives moved this from 🏗 In progress to 📋 Backlog in Node Unit Apr 4, 2024
@torives
Copy link
Contributor Author

torives commented Apr 11, 2024

The Validator tasks will now be tracked by #375

@torives torives closed this as not planned Won't fix, can't repro, duplicate, stale Apr 11, 2024
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Node Unit Apr 11, 2024
@marcelstanley marcelstanley removed this from the 2.0.0 milestone Apr 11, 2024
@torives torives mentioned this issue Jun 21, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic A issue with several steps #feat:output-unification Feature: Output Unification
Projects
Archived in project
Development

No branches or pull requests

2 participants