Marketplace requests and bids on-chain or off-chain?

[markspanbroek]

This is a write-up of a discussion that we had around marketplace requests and bids.

Context: this interaction diagram.

Main point of discussion: should interactions (1) and (2) be done off-chain or on-chain?

Scenario for abuse

The current implementation in the smart contracts centers around an off-chain exchange of requests and bids. As pointed out by @dryajov, this can be abused for spamming. Scenario:

1. client sends requests
2. host sends bids
3. client never responds

This is a problem, because the host has to pre-allocate storage to be able to fulfill the bid if it gets accepted. There are however no consequences for the client to send as many requests as it likes. It does not seem possible to punish the client* for this behavior on-chain without also storing the bids on-chain, and having a stake on-chain for the client. At which point you might as well do the entire marketplace interaction on-chain.

(*) We have looked at a scenario where the client puts up stake on-chain, and is punished if it does not start a contract after a timeout. However, a smart contract would then have to decide whether or not there were valid bids for the client to choose from, and this appears impossible to determine without having the bids on-chain.

Costs

One benefit of doing marketplace interactions off-chain would be that they can be done quicker and cheaper. So the question came up whether the proof of concept is usable when we move the marketplace interactions on-chain. A very rough calculation seems to confirm that we should have enough capacity to move these interactions on-chain:

Assumptions:

• There are going to be ~10 nodes running the PoC code
• Of these, ~5 nodes are going to be offering storage to others
• Each nodes stores ~10 files on the network
• Storage proofs are required roughly once every hour

This leads to the following requirements for the underlying chain:

• Marketplace interactions (requests and bids):
  • per storage contract: 1 request + 5 bids = 6 transactions
  • we have 10 nodes, with 10 files each, so this takes 10 x 10 x 6 = 600 transactions
• Storage contract handling:
  • per storage contract: 1 contract creation, 1 contract start, 1 contract finish = 3 transactions
  • we have 10 nodes, with 10 files each, so this takes 10 x 10 x 3 = 300 transactions
• Proof submissions:
  • per storage contract: 1 proof every hour = 1 transaction every hour
  • we have 10 nodes, with 10 files each, so this takes 10 x 10 x 1 = 100 transactions per hour

Ethereum L1 does roughly 15 transactions per second, 900 per minute.
Ethereum L1 + zkSync L2 does roughly 2000 transactions per second.

Conclusion

We'll change the smart contracts to perform marketplace requests and bids on-chain. For the PoC we do not expect to run into performance issues with the transactions. After the PoC we'll look into further scaling and privacy options in the consensus layer.

CC @dryajov @Menduist @cskiraly @michaelsbradleyjr @emizzle

[Menduist]

However, a smart contract would then have to decide whether or not there were valid bids for the client to choose from, and this appears impossible to determine without having the bids on-chain.

No you don't, you can punish the guy even if he didn't received any bids. That's his fault for asking an unreasonable price or storage amount. And the punishment doesn't have to be high, it can be what the gas would have been if the transaction was on-chain, or something like that.
There are anti-spam solutions, both ad-hoc like the one described here, or generic ones like the RLN nullifiers from waku.

If the only argument for doing it on-chain is to limit spam, that's using a bazooka to shoot a fly.

Imo, the simple fact that storers have to pay gas to make a bid make the on-chain version non-viable, after the PoC.

By the way, the locking-storage-for-nothing will be present no matter what, if you have 30 nodes bidding on each request, 29 will have allocated their storage for nothing.

But you know what, for the PoC, let's make the fastest to make one. Is the on-chain one the simplest one?

[cskiraly]

RLN nullifiers from waku

@Menduist you mean this, right? https://rfc.vac.dev/spec/17/

[Menduist]

Yes, I guess RLN nullifiers is a bit of a recursive acronym, should have said Rate Limiting Nullifiers :)

[markspanbroek]

But you know what, for the PoC, let's make the fastest to make one. Is the on-chain one the simplest one?

Yes, I think that doing the first interactions on-chain is at least as simple as introducing the libp2p interactions.