In the current issue, we summarize the potential performance and cost issues about the current implementation of rln-relay.
Overview
rln-relay consists of the following steps:
1- A membership smart contract must be deployed on the blockchain, the contract holds the list of current registered members (as well as deleted members) and has the API for member insertion, and deletion (slashing). Root of the tree and auth path of pubkeys are not available as part of the contract.
2- Each rln-relay enabled peer must register a public key through the smart contract. Peers need to persistently store their public and secret keys. Registered peer locks a certain amount of fund in the smart contract, which gets burned in case the peer misbehaves (spams the system).
3- Each rln-relay enabled peer must construct and maintain a Merkle Tree based on the list of current members )fetched from the membership contract). This is required for the spam protection. As scuh, peers must keep listening to the contract events (member insertion or deletion) and update their local Merkle tree accordingly. Having the Merkle tree, a peer is able to
calculate the tree root
its authentication path (membership proof)
4- By having access to the recent root and membership proof
Peers can anonymously publish messages with a certain rate and prove that they are not spammers (have not violated the designated rate)
Routing peers can authenticate the non-spam messages, and otherwise drop the message and slash the spammers (delete them from the membership contract and withdraw their deposit)
In the current issue, we summarize the potential performance and cost issues about the current implementation of rln-relay.
Overview
rln-relay consists of the following steps: 1- A membership smart contract must be deployed on the blockchain, the contract holds the list of current registered members (as well as deleted members) and has the API for member insertion, and deletion (slashing). Root of the tree and auth path of pubkeys are not available as part of the contract.
2- Each rln-relay enabled peer must register a public key through the smart contract. Peers need to persistently store their public and secret keys. Registered peer locks a certain amount of fund in the smart contract, which gets burned in case the peer misbehaves (spams the system). 3- Each rln-relay enabled peer must construct and maintain a Merkle Tree based on the list of current members )fetched from the membership contract). This is required for the spam protection. As scuh, peers must keep listening to the contract events (member insertion or deletion) and update their local Merkle tree accordingly. Having the Merkle tree, a peer is able to
4- By having access to the recent root and membership proof
Peers can anonymously publish messages with a certain rate and prove that they are not spammers (have not violated the designated rate)
Routing peers can authenticate the non-spam messages, and otherwise drop the message and slash the spammers (delete them from the membership contract and withdraw their deposit)