Contest dates
- Submission period: 2 months after approving this proposal in the governance interface
- Judging period: 2 weeks after the submission period
Motivation
An oracle service in Free TON is needed to implement different services, such as stable coin, but not only.
The goal is to implement a distributed Oracle Validator as described in “NOT a TON binary system” paper.
General requirements
- Implement NOT the VALIDATOR module that submits price feeds into the smart contracts
- Implement a “NOT the Elector” smart contract
- Provide a testing system that takes TON/USD price stream from an external source, submit it into NOT the ELECTOR smart contract, agrees on price via NOT the ELECTOR logic, emits the event with the agreed price, and slash malicious NOT a VALIDATOR
NOT a VALIDATOR module
NOT a Validator must transmit the TON/USD Price Feed into NOT the Elector Smart contract via an internal or external message (participants are free to choose the implementation). As well as participate in the commit-reveal mechanism described in NOT the Elector contract specifications below.
“Let’s imagine NOT also having validators. Let’s call them “NOT the Validators”. Instead of blocks NOT the Validators will create, submit and come to a consensus about prices of the TON/USD pair in the outer world. Let’s call them “NOT the blocks”. They will transfer their stake in TON DePools to the Issuer smart contract (let’s call it NOT the Elector, of course) for the duration of their stake in TON. Once submitted those stakes will participate in elections to become NOT a Validator in NOT the Elector smart contract. Much like the Elector smart contract, the stake they transfer to NOT the Elector can be “slashed” if the validator is providing wrong data to NOT the blocks. More on that later.
It is worth mentioning that while transferred to NOT the Elector smart contract TON stakes will continue earning rewards in the TON blockchain. The motivation to become NOT the Validator is that on top of these rewards NOT the Validators will earn a commission on all NOTs that will be issued. Thus the Validator of the TON blockchain can now effortlessly become NOT the Validator and earn additional rewards. Of course, technically it means connecting their node to a data feed from some exchanges and supplying the correct data to NOT the Elector. In fact, we can not care less how the prices ending up in NOT the Blocks, as long as this data is correct.”
NOT The Elector smart contract
The described algorithms that should be implemented in NOT the Elector contract may be amended to accommodate for a particular method of commit reveal scheme the participant may choose to implement within the boundaries of what is possible in TVM.
NOT the Elector contract may be implemented as a system of contracts rather than one contract as long as it provides all the functionality described below.
The agreed-upon price event should be sent into a proxy smart contract that other smart contracts could subscribe to.
“NOT the Elector contract is designed to collect the external TON/USD pricing value and is permanently running and therefore collects the data in an instant way. But the collecting is made in an encrypted way. The revealing mechanism is not performed on each data collection.
A quotation is made based on a decentralized and blind (sealed bidding) scheme by NOT the Validators. This ensures no one of the validators is aware of the quotes made by others in the commit-reveal scheme as discussed below. More sophisticated ZKP algorithms could also be implemented to raise the non-disclosure properties.
At a computationally unpredicted (cryptographically random) moment, the check of the given prices is performed. That is, all the data is to be revealed by submitters, and then checked with the given hash (commit) and analyzed. The correct in just mentioned sense values are considered as the initial price set. Those participants who cannot correctly reveal the data are considered pre-malicious.
Those participants whose values lie between the 25th and 75th quartile are considered honest and are rewarded. Those participants who feed the outlying data are considered as pre-malicious with some cumulative rank and they lose the current reward which goes to the honest participants with respect to this rank.
So let rank r be a number in [0,1] real-valued interval. We set that r = 0 corresponds to the honest participant and r = 1 to a malicious one. Initially, all participants have rank = 0. With the given rank the reward is calculated as (r-0.5)*r0 where r0 is the reward for an honest participant.
The rank is updated as follows: new rank is r’ = r*(1-a) + a*rc, where r is old rank, a - some constant in [0,1] and rc - the rank of the currently analyzed feed. rc is calculated based on the difference between the median value which is assumed as consensus value (see also explanations below) and given by the current participant.
{ rc = 0, for v25 < v < v75 ;
rc = 1-P (vi < v), for v ≤ v25 ;
rc = 1-P (vi > v), for v ≥ v75
where P (v ⋳ V) is the empirical probability that some random vi from the current price set lies in the interval V. So 1 - P (vi > v) ⟶ 1 with v → “max given number” and the same way 1 - P (vi < v) ⟶ 1 with v ⟶ “min given number”. v25 and v75 correspond to the edges of the honesty interval defined above. The iterative relation r’ = r*(1-a) + a*rc accumulate “errorness” of the feed with some rate a. The rate can be understood if we suggest the constant values i.e.
{ r0 = 0
rn+1 = rn*(1-a) + rc*a
rn ⟶ rc if n ⟶ ∞
Besides this, the validator is banned forever (excluded from the validators’ set) if it has undecreased rank > 0.5 during a certain number of checks. Note that if the validator would give the correct answers its rank will be instantly decreasing as a < 1 and therefore before it gets the total ban it could potentially clear the cumulative malicious rank.
Refusing to feed the price value is considered the same as feeding data with some constant rank which is a subject to determine based on convergence experiments on the pre-implementation (PoC) phase.
We realize that the quotation can be performed in an automatic or semiautomatic way, e.g. by feeding the contract with the real deal prices from any exchange they trust. That, in particular, means that they cannot verify each fed value on each step and therefore permanently punish them for the “incorrect” price would be unfair. And that is why we give them the pre-malicious status as a kind of warning to check their systems. On the warning, they can stop all feeding processes and fix them.
In the case when the Schelling mechanism cannot provide a single price (e.g. multimodal distribution) or when the normality check fails the quoting contract can
- provide a series of values (activating a correspondent number of auctions);
- refuse to provide any value, adjusted all participants with a certain rank (is a subject to investigate during the PoC);
- in the case of multiple values, the winner auction ranks the losing modes with a certain rank of suspiciousness.
Incentivization to make a quote should take the following aspects into account:
- Quote makers are to be incentivized to make a quote - that is to feed the protocol with some information (the price value in our case).
- They are to be incentivized to feed a correct quote - that is the given price value should be close to real market price as much as possible.
We assume that quote makers are incentivized to do their job for the following reasons:
- To stabilize network common consensus
- To make the NOT issuing justified and reasonable
- To bring the correct economic characteristics in the system
- Not to lose the validators reward
- Not to lose their stake at all
- To gain rewards from stakes made with TONs from NOT the Auction
- To gain extra reward when suspicious participants slashed
To perform consensus on the given data the Schelling point mechanism is proposed. It had been originally introduced in 1960 by Thomas Schelling in his book “The Strategy of Conflict” and basically is used to represent the method to acquire the common knowledge which is based on unbiased human behavior in an informationally symmetric world (which we assume as the working case).
We use the same notions and ideas which originally come from Vitalik Buterin and roughly repeat the main steps of the quoting protocol (based on the commit-reveal scheme):
- During each block, all participants can submit a salted hash of the TON/USD price together with their TON address (commit).
- During the quoting phase (as well as the check phase, see above), users can submit the value and salt whose hash they provided at the previous stage (reveal).
- Define the “correctly submitted values” as all values N, where Hash (N+ADDR+Salt) was submitted in the first block and N, was submitted in the second block, both messages were signed/sent by the account with address ADDR, and ADDR is one of the allowed participants in the system.
- Sort the correctly submitted values.
- Every user who submitted a correct value between the 25th and 75th percentile gains a reward of a certain amount of TON which is collected from the suspicious participants.
- The quoting phase makes the same procedure for suspicious and malicious accounts as at the check phase.
As mentioned in the same paper, “the protocol does not include a specific mechanism for preventing Sybil attacks; it is assumed that proof of work, proof of stake or some other similar solution will be used” (Proof Of Stake in the Free TON case).
The current final price estimation is basically calculated as the median value of the correct dataset. It is later used in auction contracts (the consensus value is a subject to adjust if anomalies have been observed in distribution shapes and parameters).”
Evaluation criteria and winning conditions
- Solidity or C++ languages for smart contracts should be used
- Contest code must be submitted to Free TON · GitHub for evaluation and the following support
- Distributed smart contracts are always preferable, the participants should avoid operations on large data sets as much as possible
- System software languages are not limited, but Rust is always preferred
Fair play
As per Procedural remarks on contests.
Procedural remarks to jurors
As per Procedural remarks on contests.
External jurors
This contest involves external jurors from DevEx subgovernance in addition to DeFi Jury to assess the quality of smart contracts as per the remarks On external jurors involvement.
| Name | Telegram | Public key | Wallet address |
|---|---|---|---|
| Sergey Tyurin | @Custler | 2c0ec55a109eb466d9db5ee7c3adb075e77627ade83ae17cea847671ab8f0a85 | 0:77772d4f5ecefb9e7ce02bca4a13cf81b65b4903ead16671e935850075fc6b4c |
| Alexander Khramtsov | @aleksandr_h | 3bdb99452a6ed9138af385d035e0967250d0e2da6f58b90245f285daf250915c | 0:625e7dda96d7b916d8779b1a44af8aa1e16e5cf6d029151207b0e359327ec7b9 |
| Boris Ivanovsky | @bivanovsky | 1a99622e54b4e87d603dd87c9cc936b388b2a0e1979bb56d4039cfad0fbadc8c | 0:d2cd1ff399d441ca84c1585f634b60a16b65b46c27209fbd9cf928f97465bed2 |
| Pavel Khachatrian | @get_username | d89e20f2e164f4e64a3637cc6926baf66482bf8c875e4e7eebedd6f28024998c | 0:32b2ab6941e3e08e98d1cb483f22bce8360643762405adf548d0fc785ae9879c |
| Nikita Monakhov | @keshoid | 816747e3c1e0c3be11797a76ffd5f823a1c933586cac2f170bc1395f1f25e15b | 0:66e01d6df5a8d7677d9ab2daf7f258f1e2a7fe73da5320300395f99e01dc3b5f |
| Evgeniy Shishkin | @unboxedtype | 6ff61c1a7bb09795f7b5d5514dd710efb72e9557654d362ef208fde545ba7a33 | 0:612410a54714de99c56eead2d1a4c2a3afdf2edcc392c9d7120f1505b666770d |
| Dmitry Senitsky | @senitsky | 2937d687e7b39d2ffd3fe8f33476ded49b6aec6ec5b57fac88407b8181ca8fd1 | 0:f9a5517af619a16d1615d0e24ec3fb4ee8f9944cfd67610ce6a355090680fa94 |
| Yaroslav Anishchenko | @yanmsk | c696f383a2d839b9fc7c036ab145982e644a3f14d2a57cd9429729f8bcb79eab | 0:fff3ff48a6f00c5eda84bbac4781735ab0e7994950f55493a85c967f295760e7 |
| Paul Mikhailov | @pafaul | 7657b6b62ec6846e6341315ba3b8d611afe2ef79e8ee3214d45cc4ede3c50972 | 0:b68e4c06f8d547d12a08af03975e5130c2bd7dd1171fd0407a2875956ea7588d |
| Andrey Nedobylsky | @lailune | fb2fe560bfbdda910798e1365d9419ff6e0a75ed5262410b714f162434a88af6 | 0:c1f2b2941fe3ed16960c484db49186363ed4bbb7c825a8128f46d787f973ff2b |
Jury rewards
As per Procedural remarks on contests.
Governance rewards
As per Procedural remarks on contests.
