Integrity protocol
The integrity protocol verifies that all nodes are functioning optimally and that data is not corrupted. It also assigns each node a score, which is used to determine the amount of rewards distributed. More details about performance score calculation can be found here.
Node providers can begin the onboarding process by supplying the necessary information to register their node for Provider App. The first step in this process is geolocation, which aims to minimize internet transport costs. To accomplish this, each node is assigned to the nearest cluster based on its location. More details about geolocaion can be found here.
After the node is allocated to a cluster, the onboarding process continues with an integrity and performance verification set. During this stage, multiple requests are made to verify the accuracy of the data returned and to ensure that the node meets the required Service Level Agreement (SLA), which is detailed at the end of this section.
- Assuming that all verifications pass successfully, the node will transition to the Active state. Active nodes have the option to create a corresponding Staking Pool, which enables them to start receiving rewards. Throughout their operation, active nodes are continuously monitored to ensure that they meet performance and data integrity requirements.
- If the node fails to meet the required SLA or is not synced, it will be moved to a Failed state. In this state, the node will be unable to participate in the network and will need to be reviewed and potentially reconfigured to resolve the issue. Similarly, if the data returned by the node is found to be invalid, the node will immediately be moved to a Failed state. The correctness of the data is verified by comparing it against a source of truth.
All registered nodes that are in the Active state and respond to customer requests within the Blast platform undergo continuous verification to ensure their integrity and performance. This verification process is similar to the one they needed to pass during onboarding. If a node does not meet the platform's SLA or is no longer synced, it will be moved to a Jailed state. In this state, the node will not respond to customer requests and will not receive rewards.
However, before a node is jailed, it will be given a few extra chances, which we call Yellow flags. If a violation occurs, the node will receive a Yellow flag and a grace period of 20 seconds. If the node receives 3 Yellow flags, it will be taken out of load balancing and moved into a Jailed state. If another violation occurs after the grace period has ended, the process is repeated until all Yellow flags are spent, and the node is ultimately put in jail.
The Jailed state is temporary, and after some time, the node may be automatically Onboarded again or Deactivated. During this process, the node undergoes multiple verification sets at different points in time until the verification passes, and the node moves back to the Active state.
The time intervals for a node to be automatically released from jail are as follows:
- 1st attempt after 15 minutes
- 2nd attempt after another 30 minutes
- 3rd attempt after another 60 minutes
After the 3rd attempt, the node will be verified hourly for 72 hours, and at the end of each verification, if it still fails to meet the SLA, it will be permanently Deactivated, and its slot will be opened for a new Node Provider to fill. While in this state, the node will be unable to participate in the network and will need to be reviewed and potentially reconfigured to resolve the issue.
Requirements:
- Latency:
- Light requests: <500ms
- Heavy requests (eth_getLogs): <5s - only applicable for EVM compatible chains
- Up-time
- 99.95%
- Sync state
- 99.99%
- Data integrity - the platform enforces a zero-tolerance policy for data integrity, and any node failing to comply will be automatically moved to the Jailed or even Deactivated state.
Last modified 1mo ago