Observer
Observer crediting
Observers must register themselves on the App Chain and credit a predefined amount of Synternet tokens. Within Synternet tokenomics v1, the main functionality of Observers is to oversee the correctness of proofs submitted by Brokers.
Observer rewards
There are two sources of rewards for Observers. The first is for acknowledging that a proof is correctly constructed (attestation). The second is for proving that an on-chain submitted proof is badly constructed (challenge).
Attestation
Each Proof of Delivery (PoD) submitted on-chain must be attested before it can become a basis for reward payments. Each PoD is assigned a randomly selected quorum of Observers. Observers receive a reward for each attestation they make. The attestation reward rate as a percentage of the network fee is a system parameter and can be changed through on-chain governance. The actual amount of tokens collected as a network fee is stated in PoD.
The amount of attestation reward is proportional to the work done and is a fraction of the network fee paid by the Subscriber. Since Brokers are performing a lion’s share of the work by relaying the data, the vast majority of network fee is claimed by Brokers, thus the attestation reward shared among attesting Observers is comparatively modest.
However, note that while each Broker node has to live out of the data it is delivering, each Observer processes a very significant share of all PoDs within the system. How big this share exactly depends on two parameters: (1) the total number of Observers in the system, and (2) the number of attestations required for each PoD or a quorum size. For example, if there are not many Observers in the early days of the Data Layer protocol, all of them might be attesting to 100% of PoDs.
If an Observer attests to the correctness of an invalid proof, its credited tokens are slashed.
Challenge
A robust Observer should check all PoDs in the system, even those that are not assigned to it to attest. When an honest Observer discovers a badly constructed PoD, it should challenge it by constructing a correct proof and submitting it to the chain.
The budget for a challenge reward is composed of (1) the network fee paid by the Subscriber and stated in the Proof of Delivery and (2) the credit of a Broker, who submitted the proof.
If the PoD is badly constructed, then it cannot be reliably used for rewarding any party. However, if an Observer submits a correct proof as a successful challenge, then it is entitled for an extended reward. In such a case, it claims the whole network fee, which cannot be paid to the malicious Broker and Observers who attested to that PoD. Challenger is also rewarded a fraction of slashed parts of that Broker’s and Observers’ credit.
Falsely submitted challenges, attestations, and proofs detected by other Observers or Subscribers will result in slashing the credit of the Observer who submitted them.
Future work
All future work is the research and development that is planned, however, this cannot be seen as a commitment to deliver certain features.
Zero-knowledge proofs
It is possible to design a leaner version of the decentralized accounting without having Observers check and attest every PoD, which aggregates Proofs of Consumption into Proofs of Delivery using Merkle trees. The same can be achieved by enabling Brokers to construct and submit zero-knowledge proofs. In such a case, the construction of the zero-knowledge proof will enforce the correctness of the submission and will make Observers redundant. This can be achieved through self-validating properties of zero-knowledge proofs.