Proposal: To avoid Sybil attacks on the anchoring contract(s) in a permissionless setting, there needs to be an open registration function for Operators (account address, public key, ether stake, possibly commitment hash) to limit the number of writers to a contract. The stake slashing condition serves as a rate limit per Operator and needs to be chosen such that each Node can only submit a limited number of transactions per contract per Block.
Preliminaries for a staking protocol which are important from a Game Theory point of view:
- The stake does not provide any monetary benefit for an Operator. This is important to avoid economic collusion scenarios.
- Operators can only monetize their service by charging a fee from the requesters. Either per transaction or a recurring flat fee.
Since Operators are independent of one another, and each has its own income stream, the competition for business is expected to keep transaction fees low. Of course, oligopolies could form. However, the fact that there is no barrier to entry for an Operator, except a stake, should keep the market sufficiently diverse. A small caveat is that if the protocol were to become compute-heavy, it could discourage broad participation as the cost of computing might be high.
The slashing conditions for the protocol are as follows:
- If an Operator submits more than 1 transaction per block the Operator’s stake is slashed and the public key of the Notary will be blacklisted. This is required not only as a rate limiter to avoid spamming but to also foster Operator diversity
- If an Operator submits a transaction that has no verification data in the CAS network and the lack of data is detected by another Operator and is reported by that Operator, the offending Operator’s entire stake will be slashed and the public key of the Operator will be blacklisted.
Any registered Notary can submit a “whistleblower” transaction to the registration contract that proves that the accused Operator submitted a transaction without associated verification data. If the submitting Operator is registered and its signature is validated, the contract creates an event signaling a malicious action and a challenge period -- a certain number of blocks, say 100 or a 1000 blocks depending. A “whistleblower” transaction has the following elements
- Account of Whistleblower Operator
- Public key of Whistleblower Operator
- Account of Malicious Operator
- Public key of Malicious Notary
- Malicious Entry: Roothash, URI, Generalized Timestamp
- Proof Material: Data object of the query that shows NULL returned data together with a generalized time stamp of that query from the CAS network
- Digital Signature of the Whistleblower Operator
In order to avoid malicious accusations of other Operators, there is a challenge period during which the accused Operatory or any other Operator can submit a counter proof with the same structure as the whistleblower transaction. The contract then randomly selects N registered Operators excluding the accused and the whistleblower as validators and creates an event to notify the registered Operators that they have been selected as validators and start the validation period, of for example another 100 or 1000 blocks. The selected validators have then until the end of the validation period to either agree or disagree with the challenge by submitting proof data in the same format as above. The contract counts the votes ensuring that the data content (hash of the data content) matches either the whistleblower or the accused submission and that the generalized timestamps are logically later than the original submissions. If M-of-N of the validators agree with the whistleblower, the accused Operator’s stake is slashed and the Operator is blacklisted. M can be any number such that the condition could be 2-of-3 or 2-of-5. If there are less than M validators agreeing with the whistleblower, then the whistleblower’s stake is slashed and its public key blacklisted.
The staking protocol works could work as follows:
- An Operator submits a registration transaction to the anchoring contract. The required permissioning contract validates that either the account or the public key has not already been registered or blacklisted. If they are, the registration is rejected. The contract then validates the signature, records the stake, and generates a success message as an event.
- Every time an Operator submits a transaction, the permissioning contract checks if the block number of this transaction is the same as the block number of the last recorded transaction from the Operator. If the block numbers match, the slashing condition is enforced and the stake of the Operator is "burned" by sending the Ether used as a stake to the zero address. The Operators's account is moved to the blacklist and removed from the registry of active Operators. If the block numbers do not match, the entry for the Operator is updated with the new block number in order to keep track of an Operators' submission.
If a Whistleblower, Challenge or Validation transaction is submitted, the permissioning contract checks if the submitting Operatory is registered, and if the digital signature is valid. If both checks are passed, the contract follows the Whistleblower process outlined above.
When an Operator wants to unbond/unregister, the permissioning contract unregisters the Operator's address. It then waits until the block containing the unbonding transaction and at least two subsequent blocks have been finalized, and then sends the stake back to the account of the original Operator registration.
One of the key Game Theoretic construction insights in the staking mechanism is that there is no economic gain in trying to game the protocol since the only economic gain for a Notary is from the fees extracted from customers such as Alice and Bob.
Proposal: To avoid Sybil attacks on the anchoring contract(s) in a permissionless setting, there needs to be an open registration function for Operators (account address, public key, ether stake, possibly commitment hash) to limit the number of writers to a contract. The stake slashing condition serves as a rate limit per Operator and needs to be chosen such that each Node can only submit a limited number of transactions per contract per Block.
Preliminaries for a staking protocol which are important from a Game Theory point of view:
Since Operators are independent of one another, and each has its own income stream, the competition for business is expected to keep transaction fees low. Of course, oligopolies could form. However, the fact that there is no barrier to entry for an Operator, except a stake, should keep the market sufficiently diverse. A small caveat is that if the protocol were to become compute-heavy, it could discourage broad participation as the cost of computing might be high.
The slashing conditions for the protocol are as follows:
Any registered Notary can submit a “whistleblower” transaction to the registration contract that proves that the accused Operator submitted a transaction without associated verification data. If the submitting Operator is registered and its signature is validated, the contract creates an event signaling a malicious action and a challenge period -- a certain number of blocks, say 100 or a 1000 blocks depending. A “whistleblower” transaction has the following elements
In order to avoid malicious accusations of other Operators, there is a challenge period during which the accused Operatory or any other Operator can submit a counter proof with the same structure as the whistleblower transaction. The contract then randomly selects N registered Operators excluding the accused and the whistleblower as validators and creates an event to notify the registered Operators that they have been selected as validators and start the validation period, of for example another 100 or 1000 blocks. The selected validators have then until the end of the validation period to either agree or disagree with the challenge by submitting proof data in the same format as above. The contract counts the votes ensuring that the data content (hash of the data content) matches either the whistleblower or the accused submission and that the generalized timestamps are logically later than the original submissions. If M-of-N of the validators agree with the whistleblower, the accused Operator’s stake is slashed and the Operator is blacklisted. M can be any number such that the condition could be 2-of-3 or 2-of-5. If there are less than M validators agreeing with the whistleblower, then the whistleblower’s stake is slashed and its public key blacklisted.
The staking protocol works could work as follows:
If a Whistleblower, Challenge or Validation transaction is submitted, the permissioning contract checks if the submitting Operatory is registered, and if the digital signature is valid. If both checks are passed, the contract follows the Whistleblower process outlined above.
When an Operator wants to unbond/unregister, the permissioning contract unregisters the Operator's address. It then waits until the block containing the unbonding transaction and at least two subsequent blocks have been finalized, and then sends the stake back to the account of the original Operator registration.
One of the key Game Theoretic construction insights in the staking mechanism is that there is no economic gain in trying to game the protocol since the only economic gain for a Notary is from the fees extracted from customers such as Alice and Bob.