Integrity protocol
Integrity protocol verifies all nodes in order to prevent bad performance as well as bad data. It also calculates a score for each node to be used for distributing rewards. In the first version of the protocol, all nodes have the same score regardless of their individual performance, and rewards are distributed equally based on the amount of time each node stays in an Active state.
The onboarding process starts when someone creates an account to become a node provider and supplies the required information to register their node. The first step in the process is geolocation, in order to minimize the internet-transport cost, each node is assigned to the nearest cluster relative to the node’s location.
After the node is allocated to a cluster, the onboarding process continues by running an integrity and performance verification set. In this state, multiple requests are made to verify the correctness of the replied data as well as to check if the node matches the required SLA (detailed at the end of this section).
- In the best-case scenario, if all verifications are passed, the node enters the Active state. Active nodes allow the possibility to create a corresponding Staking Pool in order to start receiving rewards. All active node activity is continuously monitored to ensure performance and data integrity.
- However, if the required SLA is not matched or the node is not synced the node is moved into a Failed state
- When data returned by the node turns out to be invalid the node is immediately Failed. The correctness of the data is established by checking it against a source of truth.
All registered nodes in the Active state responding to customer requests within the Blast platform are continuously verified in terms of integrity and performance against a verification set similar to the one they need to pass during onboarding.
If a node does not match the platform’s SLA or is no longer synced it will be moved into a Jailed state. While jailed, the node will no longer respond to customer requests and will not receive staking rewards. However, the jail does not happen immediately, but only after giving the node a few extra chances, we call them Yellow flags. Thus, when a violation occurs the node receives a Yellow flag and a grace period of 20 seconds. After 3 Yellow flags, the node is taken out of load balancing and moved into a Jailed state. If another violation occurs after the grace period ended the process is repeated until all yellow flags are spent and ultimately the node is put in jail.
The Jailed state is only temporary. After some time the node may automatically be Onboarded again or be Deactivated. In this process, multiple verification sets are executed on the node 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 getting out of jail are as follows:
- 1st attempt after 15 minutes
- 2nd attempt after another 30 minutes
- 3rd attempt after another 60 minutes
After the third attempt, the node will be verified hourly for 72 hours at the end of each it will be permanently Deactivated and its slot will be made available for a new Node Provider to fill in.
The initial SLAs required from Node Providers are based on the current centralized performance of the Blast platform. They are subject to adaptation and update as the Houston Testnet unfolds and will be final only at the end of the testnet period.
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 - there is a zero-tolerance policy for data integrity - nodes failing to comply will automatically be Jailed without any retries.
Last modified 7mo ago