Gladios opens third round of node public testing | Theory Section
Dear Aresians, Gladios’ phase 3 node test is officially going to open to the public. In order to facilitate nodes to better link to the latest version of the test network, this article will introduce you in detail to the test network function upgrade and related mechanisms.
The test network will mainly focus on three major upgrades:
- Open the on-chain data request function, allowing users to obtain prices in real-time according to demand;
- Replace Aura consensus with babe consensus, add validator online detection and punishment mechanism;
- The validator conducts quotation verification to reduce quotation deviation on the chain.
Gladios test web address:
Currently, Gladios has upgraded to a test network based on babe consensus in order to give random quotes. When you successfully pass the verification from the validator on the latest version of Gladios and successfully run the Validator node, you will have a chance to win the rewards from third round.
Data Request Function on Gladios Chain Is Open
Normal & Prepaid Request
Gladios, the testing site, only supported general inquiries for 77 assets in its previous on-chain pricing. This round of node testing will open Gladios’ on-chain data request function for the first time, that is, the price can be obtained in real time by submitting prepayment.
General Inquiry is a free query on the ARES chain for supported transactions on aggregate average prices. First of all, you are able to inquire which 77 trading pairs are supported on the ARES chain. And then, you can acquire data of certain transaction pair from the saved location, aresOracle,aisAvePrice, such as you can search for average pricing from eth-USDT. Finally, you will get the aggregation average price of eth- USDT. For detailed query operations, you can see the following WIKI documents:
How do I query the transaction pairs supported on the ARES chain
How to use ARES predictor general inquiry in the test net
How is the acquisition price on the advance payment chain implemented? First the user submits the query request, enters the specific transaction pair and inquiry group number, then the user needs to pay the advance payment (the advance payment will be returned if the aggregation fails), please note that this operation requires the corresponding account to have sufficient balance to pay the query fee. After submitting the advance payment, obtain the corresponding order ID from the Event.
After that, the validator nodes (all/part) will participate in the inquiry response and give the quotation result, which is derived from the collective quotation aggregation of online validators. Meanwhile, the number of participating nodes should not be less than 60%, or it will be invalid. Users can query the overall price data according to the order ID. For detailed query operations, you can see the following WIKI documents:
How to use ARES predictor to advance inquiry in the test network
Finally, after the validator node participates in the inquiry response, it will calculate the number of tokens corresponding to the inquiry, which will be converted into reward points and recorded in the corresponding financial cycle for subsequent reward allocation.
Rules of Rewards Generating
Points are generated only after the validator has participated in the paid quotation, and the ARES-Oracle module records the generated points into the module through the IForReporter interface provided by the Ares-Finance module.
The rule of point generation is that, after the validator node participates in the inquiry response, it will calculate the number of tokens corresponding to the inquiry, which will be converted into points and recorded in the corresponding financial cycle for later award allocation. Maximum number of points generated in a single inquiry =(number of tokens * Number of validators).
* For example: a set of inquiry requests paid 1000 ARES, and we assume that is 10 points. If A, B, C, D validator have all made a quotation, then A, B, C, D validator will each get 10 points, the maximum points generated by this inquiry =40 points; If only A validator makes a quotation, then A gets 10 points, and the maximum points generated by this inquiry =10 points.
Reward allocation involves reward cycles that are multiples of sessions on the chain. At present, Gladios test network is configured with 6 sessions equal to one reward cycle (about 6 hours). Each payment inquiry will correspond to a specific reward cycle. The reward needs to be claimed by the validator himself after the cycle is over. The reward calculation rule is that the total amount paid in the cycle/all points generated in the cycle * the points of the recipient.
Single point rewards = total amount paid in the cycle/total points generated in the cycle
Validator Reward = Total amount paid in the cycle/all points generated in the cycle * Validator points
Currently, the test network rewards are reserved for 28 depths (i.e. 28 ERA, 7 days). Rewards beyond this depth that are not claimed will go to the finance module.
Gladios Added A Validator Penalty Mechanism
In the third round of node testing, the Aura consensus was changed to babe Consensus, which introduced randomness in the block producing order to make the next block-generating validator as unpredictable as possible, thus avoiding malicious bid attacks as much as possible. Currently, Gladios has added Imonline module detection, so it is necessary to submit the validator application again and reset the sessionkey, which improves Gladios node quality and accuracy by monitoring node presence in real time and adding penalties.
Imonline Module Detection
The validator checks whether the validator is online through the Imonline module, which requires the user to configure a private key of the IMON type into the session. The module will check the online status of each Session validator by first checking whether the validator has generated blocks in the corresponding session. If there is no block generated, the module would ask for a heartbeat request (the validator program will submit it automatically) to prove their online status. At the end of the session period, the node that did not generate blocks and did not send a heartbeat node will be reported.
The reported validators will be punished. First, they will be kicked out of the validator collection at the beginning of the next ERA, and then a slash score will be calculated to punish the validators. This score is calculated by Imonline module. There is a penalty for more than 10%, which increases linearly based on the number of validators offline, deducting up to 7% of the pledge.
Imonline penalty formula:
// basically, 10% can be offline with no slash, but after that, it linearly climbs up to 7%
// when 13/30 are offline (around 5% when 1/3 are offline).
Validator Node Check
Upgrade Ares-Authority Session Key
The Ares predictor requires the ARES-Authority account to sign quotation requests on chain. This key extends the implementation structure of the SessionKey in the Session module. Specific implementation in the ares-Oracle-provider-support module (sr25519 module needs to be implemented)
Currently gladios requires babe, Grandpa, ARES, and IM_online session keys. Ares corresponds to an SR25519 key pair, which can be generated by rotateKeys() of rpc-author and is bound to a validator along with other public keys of the session module.
Validator Quotation Check
For ares-oracle, in addition to meeting the requirement of stake and configuring session-key, the application to become a validator also needs to go through the check of the validator’s quotation function. The main function of the validator is to ensure that the node where the validator belongs to can normally use offchain to obtain quotation data from the outside and submit it to the chain.
After applying to be a validator, the system will submit a “preliminary examination” task on the chain in the era before the second session of the cycle for validators, as the nodes where the validator is at will submit a trading price on the chain, if this price is normally submitted and price deviation is not way too big, the application will be approved, otherwise the application will be terminated.
If the validator application of the previous round is not canceled, the pre-check task will be resubmitted for re-examination in the second session before the era of the next round. That is to say, the validator can modify the node configuration during this period until the verification is approved.
If the validator fails to pass the quotation check, you need to check whether the database is available. Set the database parameters in time and carry out the operation and maintenance query of validator quotation continuously. For detailed query operations, you can see the following WIKI documents:
Quote node RPC tool
This article has provided you with a detailed introduction to the functional upgrades and related mechanisms of the test network. Many functions have been automatically written to the Gladios test network. How do you join the test as a node? What about this reward mechanism? We will reveal this in the next chapter!
Ares Protocol is a decentralized cross-chain oracle platform that introduces a truly new generation of cross-chain oracle service protocols with on-chain data verification and is the first to open a compensation channel for data users in case they suffer business losses due to the use of data provided by the oracle.
Ares Protocol is an oracle solution with security using VRF, developed on the Substrate framework, and it supports hybrid Babe and off-chain workers. It integrates Polkadot’s latest on-chain governance, brings the Optimistic Rollup challenge model into the oracle field, supports the Ink contract ecosystem, and brings better oracle services to DeFi Developers.
🌐 Ares Protocol Social Media
Telegram Group: https://t.me/aresprotocollab
Telegram Channel: https://t.me/AresProtocolAnnouncements