Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tokens destination #41

Open
irenegia opened this issue Jun 6, 2022 · 17 comments
Open

Tokens destination #41

irenegia opened this issue Jun 6, 2022 · 17 comments

Comments

@irenegia
Copy link
Collaborator

irenegia commented Jun 6, 2022

The payment goes from client's account to provider's account (if no appeal, otherwise goes back to provider);
The appeal fee goes from client's account to the referees accounts (split the fee, each part in an account);
The collateral goes from provider's account to the contract account (if there is slash, otherwise back to provider);

Are we fine with this policy?
Or should we use the collateral when there is slash to repay the provider/referees?

~The protocol currently burns the collateral from the provider account when a file is not retrieved.
Should we instead give the collateral to the client (all of it, only a fraction of it)? ~

@irenegia
Copy link
Collaborator Author

irenegia commented Jun 6, 2022

cc @lucaniz @Kubuxu @anorth

@anorth
Copy link

anorth commented Jun 7, 2022

Burning tokens except for protocol governance tokens makes no sense. In a competitive market of such protocols, one that paid some collateral to clients would be far preferred by them, one that paid auditors would be preferred by them, and one that retained collateral in treasury would be preferred by owner (and would be able to fund itself), and its better business prospects should make it preferred by clients and auditors. Probably the sweet spot is a mix of the above.

Lighting money on fire is no more rational for a decentralised entity than a real-world one.

(Gov tokens are an exception because that amounts to a share buyback).

Paying people for things introduces incentives, and we'll then need mechanisms to ensure those incentives don't lead to uncontrolled bad behaviour.

As an aside, the built-in storage market does burn collateral. (1) I don't think this is the best design, and (2) FIL is the equity token for Filecoin network, so for a network built-in actor, it's similar to the case of burning governance tokens, where the so-called protocol revenue accrues to FIL holders.

@irenegia irenegia changed the title Burnt tokens Tokens destination Jun 10, 2022
@irenegia
Copy link
Collaborator Author

@anorth thanks for your feedback!!

But let me explain what I mean with we burn (I think i used the wrong words there and indeed I just updated the fist message in this issue): the collateral goes into the smart contract account and the contract's owner can manage it (ie, withdraw the tokens).
So I believe we are in the scenario "protocol that retains collateral in treasury and that is preferred by owner".

The question now if this is the best approach for the market fit or when want to use part of the collateral to pay the referees (note that they can the the contract owner and they already get the appeal fee).

cc @nicola

@0xjona
Copy link
Collaborator

0xjona commented Jun 10, 2022

It is not very expensive (both in terms of @turinglabsorg effort and gas) to upgrade the dynamics of transfer of value

@anorth
Copy link

anorth commented Jun 12, 2022

the collateral goes into the smart contract account and the contract's owner can manage it

That sounds much better

@nicola
Copy link

nicola commented Jun 15, 2022

What are the risks in giving collateral money to the user?

@irenegia
Copy link
Collaborator Author

What are the risks in giving collateral money to the user?

It is an incentive to user to misbehave (eg, client appeals while a provider is down/dossed on porpuse)

@nicola
Copy link

nicola commented Jun 16, 2022

Well, invoking the committee has a cost (we can play with that)

Plus, if a single client can break/doss the storage provider for cheap, then it means that it's not a good storage provider.
Plus, there if user is an ETH token holder they already benefit from the slashed ETH collateral (in a very small way, but they do)

@irenegia
Copy link
Collaborator Author

irenegia commented Jun 16, 2022

Well, invoking the committee has a cost (we can play with that)

We already use this to say that is not rational for a malicious client to create false appeals in the current version of the protocol (ie, with no collateral given to client).
If we give the collateral (even just part of it to clients), then we have to increase the appeal and I believe this is (1) unfair for good clients, (2) not appealing for the product.

Moreover, in filecoin, when we slash for missing a windowPoSt, there is no payment for the clients, why do we want something different here?

@irenegia
Copy link
Collaborator Author

Plus, there if user is an ETH token holder they already benefit from the slashed ETH collateral (in a very small way, but they do)

what do you mean?

@irenegia irenegia moved this from 📫 to Backlog in retriev.org Jun 16, 2022
@0xjona
Copy link
Collaborator

0xjona commented Jun 16, 2022

While we are still on testnet this is not an issue related to development; but we must consider any relevant change to be included in the smart contract before audition! I’ll ping everybody in a couple of weeks

@nicola
Copy link

nicola commented Jun 16, 2022

@irenegia if you are an ETH holdler, and you know that there is a protocol, where there are miners that could loose data and when they do, they loose ETH, what you do, you attack them, so that they loose ETH, so that the number of ETH around decreases (hence the value of your ETH increases).

In other words, if we end up having $B of ETH locked, we will be a worse target than some users earning the miner collateral.

@nicola
Copy link

nicola commented Jun 16, 2022

Moreover, in filecoin, when we slash for missing a windowPoSt, there is no payment for the clients, why do we want something different here?

When people make mistakes, the network "earns" for the same reason that I described above.

@irenegia
Copy link
Collaborator Author

For the alpha version, we can leave things are they are (see description in the first message), and we can discuss this again in the future for a future upgrade.

@irenegia
Copy link
Collaborator Author

Closing this issue for now, but adding the label "future" since we may want to re-open this for an upgrade after launch

Repository owner moved this from Backlog to Validation in retriev.org Jun 21, 2022
@nicola
Copy link

nicola commented Jun 27, 2022

hey @irenegia I think it's ok to mark it as a future, but if you close it it will be very tricky to find it. I suggest we re-open it but we take it off the board.

@0xjona 0xjona reopened this Jun 28, 2022
@0xjona 0xjona moved this from Validation to 📫 in retriev.org Jun 28, 2022
@0xjona
Copy link
Collaborator

0xjona commented Aug 8, 2022

at the moment we have

  • total refund policy if provider is slashed
  • whole collateral goes into smartcontract vault if provider is slashed
  • referees network get payed 0.2*deal_value per appeal, and max appeal number is 5

these are parameters that each referee networks can set once joining the protocol, playing with terms of agreement
we are exploring multi-referee networks in next release (can't quote an issue now) @irenegia

@irenegia irenegia moved this from 📫 to Paused in retriev.org Nov 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants