Seems like spam prevention at the network layer is pretty difficult. Bitcoin, Ethereum of course attempt to do so by only relaying valid content and transactions with a minimum gas fee. PoW seems insufficient in networks which have a combination of mobiles, raspberry pis and high end servers. Stake or payment based approaches breach privacy. How does Marlin tackle these issues?
Hey Kladd. Great question. Though I would like to point out that the data that is currently transmitted in the network is public anyways due to the very nature of the public blockchains. As per Anonymity Trilemma, Marlin choose low latency and low bandwidth over privacy. So privacy might not be one of the goals of the system as of now. As we use erasure coding for increasing reliability while decreasing the overheads, the relayers will not be sure if the data they propagate is spam. Due to these issue, we have paid special attention to spam prevention in Marlin. Marlin uses a producer side payment mechanism which helps to ensure that the cost of the spam is paid by the producer. Inspite of this, the bandwidth of the receivers will be wasted if the message received is spam. So, we perform additional checks on the message reconstruction of the erasure coded message where fraud proofs can be provided if the message is not a valid block. Fraud proofs along with the attestation on message will help us slash the malicious producers who try to spam the network. Thus we are currently using a stake based approach where the actors who publish messages to Marlin network stake LIN. We also cap the number of messages that can be sent to Marlin network, based on the stake.
We are looking at ways to perform onchain verification of spam. One of the challenges we currently face is the arbitrary input size of the block. We are looking at ZK based approach to solve this where the inputs(erasure coded block) are private.
I have made a separate post to discuss the need for ZK based approach in spam prevention of erasure coded data. Check it out here.
@prateek This might be worth looking at https://ethresear.ch/t/semaphore-rln-rate-limiting-nullifier-for-spam-prevention-in-anonymous-p2p-setting/5009
Looks interesting. We are actually doing something similar for our stake capped payments mechanism to detect different messages referencing the same portion of stake, but I think in our case it is simpler as we are not working with an anonymous p2p setting.