Contract start analysis

[dryajov]

Contract start analysis

Background

During contract creation, there are several scenarios and interactions that can lead to suboptimal results - leading to bad UX; vulnerabilities for clients and providers; or both. This writeup attempts to explore this scenarios in more detail and provide some potential solutions.

High level requirements

The initial interaction has to present overall good UX and avoid potential attack vectors on the client and the providers. The overall constraints are as follows:

• Client should be able to fill it's requests quickly provided that prices are set accordingly
• Hosts should have minimal guarantees that rational behaviour will yield good outcomes
• Neither the client nor the hosts should have the ability to incur the other party into significant loss in opportunity, expended resources, or direct and indirect financial loss.

In other words, the starting a contract should have good UX and prevent either party from incurring the other in any sort of loss.

High level contract start flow

At a high level, the request for storage and contract start flow looks roughly as follows:

• Client locks up the full amount for the duration of the contract and submits a request for storage
• Providers listen for requests and bid on those that they deem interesting
  • Providers store slots of data that the client need to make available for download
• The request for storage has a future expiry date as to prevent the client from locking up the payout amount "forever"
  • If the contract didn't start, the client's funds are unlocked and it can resubmit the request

Actors and adversarial behaviors

There are two actors in this particular interaction, the client and the hosts. Both can present adversarial or lazy behaviour.

• A malicious host can prevent the contract from starting
  • For example, by squatting slots and never submitting a proof, thus forcing the entire contract to expire before starting
• A malicious client will not release all the data to all the hosts, thus making the hosts do unnecessary work or worst, compromise their stake

Thus, the two most obvious scenarios are that both the client and the hosts can prevent the contract from starting. There could be other potential attacks, but we're focusing on these two in this analysis.

Bellow are a list of approaches, the problems they address and what potential issues they present.

Approach 1

• Precondition:

  • No upfront collateral put down by providers
  • No assigned slots (providers "race" to download slots randomly)

• Mechanism:

  • All providers download one or several random slots
    • This is further restricted by the expanding window mechanism

• Issues:

  • DDoS on client and starvation of other nodes
  • Time based, expanding window is moot¹
  • Price increase due to harder/decreased participation
  • Bad UX for both the client and providers

• Avoids/Fixes:

  • No problem with locking collateral
  • No squatting problem
  • If node doesn't release all data, there is minimal damage to the hosts, only the work done to download the clients data

Approach 2

• Precondition:

  • No upfront collateral put down by providers
  • Slots are assigned to a host before download

• Mechanism:

  • Node calls contract to get a slot assigned before download

• Issues:

  • Squatting slots is still possible
  • No way to relax starting criteria because
    • No funds locked for recovery once a contract has been started

• Avoids/Fixes:

  • DDoS issues
  • Reasonable UX for both client and providers
  • Minimal damage from malicious/lazy clients
    • If a client doesn't release all the data on time to all the hosts, the loss from the host is only the fee for contract interaction and the downloaded data

Approach 3

• Precondition:

  • Collateral is required for providers, in order to get slot assigned
  • Slots are assigned only once collateral has been posted by a provider

• Mechanism:

  • Provider needs to put the entirety of the collateral upfront, before being assigned a slot

• Issues:

  • If slots aren't occupied on time, contract doesn't start
    • Providers suffer from opportunity loss due to locked collateral
    • Client isn't able to store data and needs to resubmit
    • Overall bad UX
  • Lazy/malicious clients can abuse hosts/providers
    • The dammage is significant, since collaterals tend to be high, in contrast with the earnings/payouts

• Avoids/Fixes:

  • DDoS of client
  • Potentially solves squating, because allows relaxing startup criteria is possible
    • If startup criteria is relaxed, we can start the contract even if not all the slots have been filled, this allows using the collateral from the squating nodes to reassign the remaining slots

Discussion

Approach 1

This approach has significant UX drawbacks, for both the client and the providers, but avoids most of the issues that would lead to significant loss. Even through there is some resource related loss and potential opportunity loss for both the providers and the client, it avoids most of the serious drawbacks of approach 3.

This is the currently implemented approach.

Approach 2

This approach fixes some of the UX related issues of approach 1 and largely avoids the potential large collateral losses incurrend by the provider in approach 3. However, it still suffer from the same drawback that both approach 1 and 3, which is a host's ability of stalling the entire contract by squating a slot.

However, it's shortcomings can be potentially aleviated by extending the contract start time and shortening the deadline occupy a slot, thus giving the ability to other providers to step in, before the request deadline expires.

Approach 3

This approach addresses some of the UX issues from 1 and 2, as well as the issue of slot squatting. However, it shifts too much power to the client and exposes providers not only to malicious, but also to lazy behavior.

Summary

Approach 2 with some adjustments, such as extending the contract deadline to at least twice the required time to download the slot can both fix the previous UX issues as well as prevent the squatting attack vectors. Overall, this seems to be the simplest to reason about and most flexible approach.

A high level flow can look something like the following:

1. A host identifies a request for storage that it wants to participate in
2. Calls the contract, which assigns a random unoccupied slot to it, in the process paying the fees for the transaction
3. Hosts can check how many slots are available, before participating
4. Host begins to download the contents of the slot
5. Once the data has been downloaded and a proof submitted, the slot is moved from assigned to occupied
6. If the deadline to fill the slot has expired, but the contract hasn't yet expired, the host is evicted and the slot becomes available again, at which point another host can occupy it
   1. An alternative could be to allow several parallel downloads, for example 3 hosts can be allowed to race to occupy a slot, thus increasing the likelyhood of the contract succeeding.

Footnotes

1. The expanding window mechanism aims to randomize participation and prevent powerfull actors from monopolizing the entirety of the network. It relies on initially limiting participation to a subset of the network and gradually expanding the limit to allow more participants. However, this is in direct conflict with the first come first serve mechanism, which implies that the longer the contract has been open the less chances there are to occupy a slot. ↩

[emizzle]

Just to be clear, in approach 1 and 2, no upfront collateral is required to be submitted by the provider before getting a slot index assigned, but collateral will still need to be submitted along with a proof to fill the slot, correct? Otherwise, we don't have a way of keeping the providers honest.

In approach 2, the race will no longer be who provides data and proof fastest, but will instead be won by whoever calls the contract and gets assigned a slot the fastest. The expanding window mechanism is mentioned, but it's not clear if this will be used in approach 2, which would reduce the number of providers that can enter the race. Adding the expanding window mechanism to the contract start (it was originally intended to be used in repair situations only) would have the potential side effect of reducing the speed in which contracts could start (bad UX point 1).

[markspanbroek]

Adding the expanding window mechanism to the contract start (it was originally intended to be used in repair situations only) would have the potential side effect of reducing the speed in which contracts could start (bad UX point 1).

The expanding window mechanism was originally intended for contract start 😄 It is an explicit tradeoff between speed and widely spreading the content (https://github.com/codex-storage/codex-research/blob/c79280db68405a4fbace0b83503c49ce3e57ee40/design/marketplace.md?plain=1#LL226-L231)

[AuHau]

I am not so convinced about approach 2. Having the possibility to make "free" reservations really invites squatting. And @markspanbroek 's two deterrents mentioned on the PR (gas-fees and expanding window) are not strong enough IMHO.

Firstly, gas fees, if we are talking about going to L2 then they might be small enough for somebody with "$100 credit" to do quite some damage (of course, I don't have it quantified, but that is my gut feeling). Especially since I expect the reservation contract call to be quite cheap.

Secondly, the expanding window mechanism. From what I understood, it is still unclear if we gonna use this mechanism, right? If so, then I would not base any reasoning on it as it might be rejected later on, and we will have to go back to the "drawing board". But let's say we will use it. IMHO, It solves only one type of an attack - trying to squat specific Request/Slot. If the attacker just wants to disrupt the Codex network as a whole, then he can have a few accounts that are "spread" enough to cover the most space and voila no slots will be filled...

[AuHau]

We could discourage this by only allowing hosts to fill a slot that have had some funds on their address for the last hour/day/whatever

To my knowledge, you can't enforce this on smart-contract level. You can assert the account's balance at the time of smart contract execution, but then if we are again talking about L2s then it would be very cheap to move funding around the network in order to circumstance this protection.

[markspanbroek]

To my knowledge, you can't enforce this on smart-contract level.

A host could move funds to a contract that keeps track of how long these funds have been there.

[AuHau]

Alright, I thought of this, but I considered it to be already "too high complexity" 😅 Not sure how it would really plugin into the system though. Would it be something like "network-wide collateral"?

[dryajov]

I am not so convinced about approach 2. Having the possibility to make "free" reservations really invites squatting. And @markspanbroek 's two deterrents mentioned on the PR (gas-fees and expanding window) are not strong enough IMHO.

Firstly, gas fees, if we are talking about going to L2 then they might be small enough for somebody with "$100 credit" to do quite some damage (of course, I don't have it quantified, but that is my gut feeling). Especially since I expect the reservation contract call to be quite cheap.

Secondly, the expanding window mechanism. From what I understood, it is still unclear if we gonna use this mechanism, right? If so, then I would not base any reasoning on it as it might be rejected later on, and we will have to go back to the "drawing board". But let's say we will use it. IMHO, It solves only one type of an attack - trying to squat specific Request/Slot. If the attacker just wants to disrupt the Codex network as a whole, then he can have a few accounts that are "spread" enough to cover the most space and voila no slots will be filled...

There are a number of way to alleviate this further.

1. We can extend the contract deadline and have a slot expiration be at least half of the deadline of the contract start. This is most likely something we want to do either way for a better overall UX
   1.1. A node might want to drop from a slot midway, however there is currently no way of doing that cleanly.
   1.2 Overall, without this provisions, the mechanism is brittle and prone to squatting due to all sorts of eventualities on the provider's end...
2. We can allow more than one reservation per slot, say 3 (tho the number can be larger). The main idea is to allow a limited number of nodes to race to occupy the slot without overwhelming the client.
3. Finally, we can combine the two techniques from above.

I think these covers most of the malicious or lazy squatting behavior without introducing large penalties and faulty UX for both the client and providers.

[AuHau]

I am still not convinced about how this solves the slot squatting, more here: https://www.loom.com/share/84368b8f8b7b4a17b3922832dd9005fc?sid=61ed9680-da55-48e3-8cfb-d15087262014

[emizzle]

We could disincentivise client withholding attacks by forcing them to provide proofs of the data between the time they request storage and contract start. After that, they don't need to "seed" the data to the network anymore, and repairers can download the data from the other providers. The client would need to provide some extra collateral at the start of the contract, which can be withdrawn once the contract has started. The validators would check that clients are providing proofs and slash some of their collateral if they missed proofs (same as providers).

By disincentivising client withholding attacks, providers could be required to submit collateral before being assigned a slot (approach 3) without the worry of clients being able to do damage to the providers for squatting. Approach 3 becomes more attractive here.

[AuHau]

Unfortunately, "providing proofs" (eq. submitting proofs to smart-contract) does not really guarantee that they will provide the data for incoming p2p requests 😕

[emizzle]

Yes, good point.

We could penalise clients for posting storage requests that eventually expire (without starting). This could be due to withholding, but also for posting requests outside of market conditions. It would encourage clients to choose their parameters very carefully.

[fredericosteixeira]

Does it make sense to create a secondary market for the client's data?
I mean, if at least one host already downloaded the client's data and posted proof of it (i.e. occupied a slot), then other hosts can purchase this data from occupied slots in case it can't be accessed for free from the client anymore. The cost has to be low enough to make it worthwhile but already incentivizes the firstcomers with an extra income.
We can even consider penalizing the client if we think it's safe to assume that hosts will prefer getting the data for free directly from the client instead of paying for it from other hosts. This assumes the client paid for the storage up front.

[markspanbroek]

Here's my attempt at mapping out the design space for slot reservations.

Design parameters

These are the choices that we can make in designing slot reservations, as far as I can tell:

• Host funds:
  • none; only gas fees are required for a reservation
  • locking; host funds are locked during reservation, always returned afterwards
  • burning; host funds are locked during reservation, can be burned
• Reservation collateral:
  • equal; reservation collateral is equal to the slot collateral
  • less; reservation collateral is significantly less than the slot collateral
• Client funds:
  • locking; client funds are merely locked while hosts are filling slots
  • burning; client funds can be burned when slots do not get filled

Attacks

These are the possible attacks around slot reservations, as far as I can tell:

• 🤔 clever host; host drops reservation when a better opportunity presents itself
• 🥱 lazy host; host reserves a slot, but doesn't fill it
• 😴 lazy client; client doesn't release content on the network
• 🤬 censoring host; acts like a lazy host for specific CIDs that it tries to censor
• 🪓 hooligan host; acts like a lazy host for many request to damage to the network

User experience with accidents

Accidents happen, nodes can go offline before all slots are filled. This either leads to:

• 🙂 funds that are returned (excluding gas fees)
• 🙁 a large portion of the funds are lost
• 😐 a small portion of the funds are lost

Design options

Putting this all together in a table yields:

	Host funds			Reservation Collateral		Client funds		Damaging Attacks	Accident UX
	none	locking	burning	equal	less	locking	burning		host	client
A	X							🤔 🥱 🤬 🪓	🙂	🙂
B		X		X		X		😴 (🤔 🤬 🪓)	🙂	🙂
C		X		X			X	(🤔 🤬 🪓)	🙂	🙁
D		X			X	X		(😴 🤔 🤬 🪓)	🙂	🙂
E		X			X		X	(🤔 🤬 🪓)	🙂	😐
F			X	X		X		😴	🙁	🙂
G			X	X			X		🙁	🙁
H			X		X	X		(😴 )	😐	🙂
I			X		X		X		😐	😐

Note: attacks between braces () are somewhat mitigated

[fredericosteixeira]

Is there any problem with approach D? It seems to solve all attacks.