🔁Service
Last updated
Last updated
Service in Viper Network plays a crucial role in facilitating the relay of RPC requests between clients and blockchains. Servicers, which are nodes operating within the network, are responsible for servicing these relays. They ensure the efficient and reliable transmission of data, providing a seamless connection between clients and the underlying blockchain infrastructure. Servicers are staked and incentivized to perform their tasks diligently, as their performance directly impacts their rewards. By maintaining a robust network of servicers, Viper Network ensures the availability, reliability, and responsiveness required for smooth and uninterrupted interactions between clients and blockchains.
Relays in Viper Network serve as the fundamental means of interaction between clients and blockchains. A relay is essentially an API request made by a client to a specific blockchain, seeking to read or write data. This request is transmitted through the network to the designated servicers. The servicers then process the request, interacting with the blockchain on behalf of the client. Once the blockchain responds, the servicers relay the response back to the client, completing the cycle of request and response. This relay mechanism enables clients to seamlessly access and interact with blockchains in a trustless and decentralized manner through the Viper Network’s infrastructure.
Request Initiation: The relay lifecycle begins when a requestor initiates a session by specifying essential information such as the blockchain it intends to interact with, the desired geographic zone (geozone), and the number of servicers required for the session.
Session Generation: Upon receiving the request, a session is generated based on the provided information. This session contains details essential for the subsequent relay process, including the servicers paired and the fisherman.
Relay Request Submission: With the session information at hand, the requestor submits relay requests to the servicers. These requests include pertinent details regarding the payload to be relayed and information about the session itself.
Request Validation and Proof Storage: Upon receiving relay requests, the servicers validate the requests to ensure their authenticity and integrity. Subsequently, they store relevant proof of the request's receipt and authenticity
Relay Execution: Following successful validation, the servicers execute the relay requests as specified. This may involve interacting with the designated blockchain, processing transactions, or executing smart contract functions, among other actions.
Response Generation: Upon completing the relay task, the servicers generate responses corresponding to the relayed actions.
Response Signing and Return: Before returning the response to the requestor, the servicers sign the response to ensure its authenticity and integrity. Once signed, the response is returned to the requestor, completing the relay lifecycle for the specific request.
In Viper Network, ensuring a high Quality of Service (QoS) for relay services is paramount. To uphold this standard, the network leans heavily on the unique role of the Fisherman. This actor is instrumental in continuously evaluating and overseeing the performance of servicers throughout each session.
A distinct feature of the Viper Network is its dynamic 'report card' system for every servicer. Post each session, the Fisherman updates these report cards which not only influence a servicer's chances of being chosen for subsequent sessions but also define the proportion of rewards they garner. This system effectively motivates servicers to consistently deliver top-notch performance, fully aware that their excellence directly correlates with their earning potential.
In these report cards, a servicer's performance is evaluated based on the following metrics:
Availability: Acting as a shadow client, the Fisherman sends sample relays simultaneously to all servicers within the session. By closely monitoring their responsiveness and ability to provide timely responses, the Fisherman determines the availability of each servicer.
The downtime percentage is calculated as the ratio of unanswered relays to the total relays sent.
The scaled availability score is derived by subtracting the downtime percentage from 1.
Formula: scaledAvailabilityScore = 1 - (unansweredRelays / totalRelays)
Latency: The Fisherman also evaluates the latency of the servicers. This is done by measuring the Round Trip Time (RTT), which represents the duration it takes for the Fisherman to receive a signed response from a servicer.
Scores are calculated based on the ratio of the lowest average latency (fastest servicer of the lot in a session) to the average latency of each servicer.
The score is clamped to be at most 1 to ensure consistency.
Formula: score = lowestAverageLatency / averageLatency (clamped to 1 )
Reliability: Reliability isn't just about uptime but also about ensuring consistent and error-free service. The Fisherman benchmarks the accuracy of servicer responses by executing sample requests locally and comparing the outcomes with the servicer's responses. Discrepancies indicate errors or inconsistencies on the servicer's part. Over time, a servicer with repeated discrepancies sees a decline in its reliability score. This meticulous validation ensures that only the most consistent servicers thrive in the Viper Network, further solidifying the network's commitment to providing dependable relay services.
The reliability score is calculated as the ratio of matched samples to total samples sent.
Formula: reliabilityScore = matchedSamples / totalSample
** The weights assigned to performance metrics are parameterized and can be adjusted in the future through the DAO governance.
The Viper Network's global report card system tracks the performance of validators over time, using three key metrics: Latency Score, Availability Score, and Reliability Score.
When a validator submits a QoS report, the network updates the corresponding report card as follows:
Updating Scores: The Latency, Availability, and Reliability scores are updated using a decaying average formula:
The decaying average formula applies a 0.98 decay factor to the current score, reducing the impact of older sessions. This is done to ensure that the report card reflects the validator's recent performance more accurately.
Averaging the Scores: The updated score is calculated by averaging the decayed current score and the new score. This is done to strike a balance between the historical performance and the latest session's performance.
As the total number of sessions increases, the impact of a single new session on the overall score becomes less significant. Averaging the scores, rather than simply adding the new score to the total, helps maintain the report card's sensitivity to the validator's current performance.
This approach allows the network to track the validator's performance on a per-session basis, without the scores becoming overwhelmed by the cumulative effect of many older sessions.
Total Score Calculation: The individual scores (Latency, Availability, and Reliability) are multiplied by their respective weights and then added together to calculate the total score. The total score is then divided by 1,000,000,000,000 to reduce the power and maintain a manageable range.
The report card system incentivizes validators to maintain consistent, high-quality service to the network and its users.
| Metric | Score Weightage |
|---|---|
Availability
30%
Latency
40%
Reliability
30%
