2.3 KiB
Replication-validation Transaction Fees
Subject to change.
As previously mentioned, validator-clients will also be responsible for validating PoReps submitted into the PoH stream by archiver-clients. In this case, validators are providing compute CPU/GPU and light storage resources to confirm that these replication proofs could only be generated by a client that is storing the referenced PoH leger block.
While replication-clients are incentivize and rewarded through protocol-based rewards schedule see [Replication-client Economics](../ed_replication_client_economics/README.md), validator-clients will be incentivized to include and validate PoReps in PoH through collection of transaction fees associated with the submitted PoReps and distribution of protocol rewards proportional to the validated PoReps. As will be described in detail in the Section 3.1, replication-client rewards are protocol-based and designed to reward based on a global data redundancy factor. I.e. the protocol will incentivize replication-client participation through rewards based on a target ledger redundancy e.g. 10x data redundancy.
The validation of PoReps by validation-clients is computationally more expensive than state-validation detailed in the [Economic Sustainability](../ed_economic_sustainability.md) section, thus the transaction fees are expected to be proportionally higher.
There are various attack vectors available for colluding validation and replication clients, also described in detail in Economic Sustainability. To protect against various collusion attack vectors, for a given epoch, validator rewards are distributed across participating validation-clients in proportion to the number of validated PoReps in the epoch less the number of PoReps that mismatch the archivers challenge. The PoRep challenge game is described in Ledger Replication. This design rewards validators proportional to the number of PoReps they process and validate, while providing negative pressure for validation-clients to submit lazy or malicious invalid votes on submitted PoReps note that it is computationally prohibitive to determine whether a validator-client has marked a valid PoRep as invalid.