Node Consensus Networks on Solana
Introduction
Jito (Re)staking is a staking protocol built on Solana. The protocol has two major components:
- the restaking_program acts as an onchain registry that coordinates (re)stake delegations and rewards distributions between node consensus networks (NCNs), vaults, and operators, and
- the vault_program enables permissionless vault (vault receipt token, “VRT”) creation and various administrative authorities for managing the vault’s assets and parameters.
Both programs have a menu of built-in instructions and admin authorities. This design unlocks extreme flexibility and customizability. E.g. Custom vault logic can enforce KYC, minimum deposit thresholds, and/or tailored inflation schedules.
Altogether, Jito (Re)staking is a platform to deploy and coordinate custom proof of stake protocol, directly on Solana. In other words, developers can use the Solana runtime for custom proof of stake mechanisms, such as implementing proof of authority for distributing rewards given some deterministic input.
This article outlines a technical overview of the various components involved in building NCNs–the core participants of the restaking protocol–and some devex modules we’ve adapted from TipRouter to accelerate NCN development.
For a complete walkthrough of constructing a basic NCN that goes through all the code and achieves consensus on the weather status in Solana Beach, refer to the NCN Implementation Guide (or the Github repo). It features code from TipRouter that can serve key functions for any NCN. This article briefly introduces some of the modules and their key concepts.
Overview: The Offchain and Onchain Components of an NCN
At a high level, NCN developers must build both offchain and onchain components. The offchain components are primarily an offchain client and an operator module. The offchain pieces are the core business logic and operations for the underlying network.
(Note: These are the offchain essentials. The complexity of the offchain pieces may vary depending on the use case of the network, and we are actively R&Ding solutions.)
Offchain client
The offchain client is custom software that NCN operators run (usually in a binary, docker container, etc.) to perform network operations and achieve consensus on an output. This system is the backbone that may enable various functions such as network communications between core personas of the underlying protocol, maintaining an offchain ledger, computing results, or all the above.
E.g. For a typical DePIN construction, typically an “orchestrator” or “coordinator” role sends “requests” to workers, receives “responses” from workers, and maintains a ledger that contains each workload’s request-response pair. This ledger can then be used to calculate rewards for the network. A v0 (Figure 1) can involve one node operator performing this task, constructing a merkle tree of accounts and rewards, and uploading the merkle root to an onchain account that invokes the distribution according to the result.
Furthermore, subsequent versions (Figure 2, for example) can involve distributing this role to a network of nodes. For a distributed construction, a set of orchestrator nodes would send, receive, and gossip requests and responses, maintain a ledger of the activity, calculate rewards, construct a merkle tree of accounts and rewards, and vote on the correct distribution of rewards by submitting their respective merkle roots (ballot) to an onchain program (ballot box). Designs may vary based on the complexity of the underlying network, however, the crucial component for distributing the “orchestrator’s” role is having the ability to deterministically generate the same result. Contact hayden (at) jito (dot) network to explore various options.
In a simple example, TipRouter operators are running a client that takes a snapshot of the last slot of the previous epoch and generates a merkle tree that maps all stake accounts and the amount of Jito tips and block rewards each account can claim. The merkle root is then used as a Ballot and submitted to an onchain program (BallotBox) during the voting (consensus) phase. Once a Ballot receives >66% stake-weighted quorum, it is set as the winning merkle root and uploaded to the jito-tip-distribution program and jito-priority-fee-distribution program (linked here and here, respectively) to distribute SOL.
Operator module
The operator module automates the onchain tasks for registered operators, primarily casting votes, handling post-vote logic, and reporting metrics. The guide explains how to configure and run the operator for the Solana Beach Weather NCN. It breaks down the operator loop, details how votes are cast using real-world weather data, and walks through the behavior during different epoch states.
Permissionless Keeper (“cranker”) module
The permissionless keeper module is an offchain script that performs various onchain functions for advancing state such as initiating snapshots and updating operator stake-weights. The keeper command automates key tasks for each epoch, including creating epoch state accounts, performing stake snapshots, and handling the voting process. The guide walks through the various tasks the keeper cranks, upon which more can be built.
Even though the keeper is offchain, actions take place onchain. Anyone can call this program to advance the NCN’s state. By monitoring network state and calling the NCN program’s instructions at certain times, keepers make sure the NCN progresses correctly and remains in sync with Solana’s epoch.
Using TipRouter as an example, the keeper maintains all essential addresses and state information, as shown below. This is core functionality to keep track of the voting process and stake delegations until quorum (>66%) is reached.
(Note: there is an opportunity to create an NCN to run permissionless crankers e.g. TukTuk.)
The Onchain Components
The onchain component is a set of onchain programs that include maintaining and tracking the state of the NCN, verifying the results of the offchain service, calculating rewards, and routing rewards (or enforcing penalties). Consensus (or quorum) can be achieved onchain (e.g. TipRouter) or offchain. If you would like to achieve offchain consensus, please reach out to hayden@jito.network.
See the NCN Implementation Guide for a more thorough review of the program and various instructions. All core data struct definitions for onchain operations, such as tallying operator votes and storing NCN state, used in the NCN program can be found here.
Snapshot module
The snapshot module is an onchain instruction that takes a snapshot of vault assets. This is used for calculating operator stake-weights. Furthermore, the operator stake-weight calculation is an onchain instruction that calculates the amount of stake each operator is delegated. This step is crucial for subsequent NCN operations, such as achieving quorum, monitoring stake across operators, and distributing pro-rata rewards to participants.
E.g. At the start of each consensus cycle, TipRouter takes a snapshot of vaults to calculate stake-weights used for (1) updating BallotBox until >66% quorum is reached and (2) rewarding vaults and operators on a pro-rata basis.
Rewards distributions module
The rewards distribution module is a set of onchain instructions that routes rewards to NCN participants (including but not limited to the NCN, NCN operators, NCN vaults, and restaking protocol) and stores the mapping between NCN participants and their allocated reward amount. You can view these instructions in the Core Struct section of the guide.
For example, TipRouter distributes 2.7% of all Jito tips and block rewards to the Jito DAO, and 0.30% are routed to NCN participants, split between JTO stake and JitoSOL (re)stake. Rewards are routed to node operators, then routed to vaults who share proceeds with stakers according to fees set by admin authorities.
Final thoughts
We built the Jito (Re)staking protocol because there are aspects of Jito Network that can benefit from incremental decentralization. It’s a framework to leverage stake and accelerate decentralization, in the expectation that, as Solana’s ecosystem continues to mature, developers will eventually transition to prioritizing resiliency over product iteration speed and seek to build custom decentralized solutions that fits the needs of their protocol. And it is designed to be highly flexible and customizable.
If you are interested in building an NCN or have questions about how to customize certain functions for particular use cases or constraints, please get in touch (hayden (at) jito (dot) network).