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

Overview of Raiden Network RSB (non-core) smart contracts #120

Closed
loredanacirstea opened this issue Sep 3, 2018 · 11 comments
Closed

Overview of Raiden Network RSB (non-core) smart contracts #120

loredanacirstea opened this issue Sep 3, 2018 · 11 comments

Comments

@loredanacirstea
Copy link
Contributor

@loredanacirstea loredanacirstea commented Sep 3, 2018

Notes from the 24 August planning meeting regarding this:

MSC - Monitoring Service Contract - #46
UDC - User Deposit Contract
PFSC - PathFinding Service Contract
RSBC - RaidenServiceBundle Contract
HC - Hub Contract

User Deposit Contract

  • global deposit in RDN for all services
  • MSC will transfer the user’s tokens from here, when it has to pay a reward for the MS
  • this will mark the MSC, PFSC, RSBC as trusted contracts
  • if the user wants to withdraw part/all of his deposit, this must be timed out (e.g. he can apply for a withdrawal and then finalized it only after 1 week); the reasoning is: the services must make sure they withdraw their payments first. PFS will specifically be targeted here, if we implement off-chain payments.
  • the contract will make sure the 3rd parties withdrawing from it are registered in RSBC
  • PFS, MS will be paid from this contract

RaidenServiceBundle Contract

  • global deposit in RDN for 3rd party services (MS, PFS, Matrix HS); each 3rd party will deposit/bound tokens here.
  • no slashing was discussed

PFSC

  • it can act as a unidirectional payment channel between the users and PFS, using the user's global deposit from UDC

Hub Contract

Ideally, the user must have enough RDN to use the system. The onboarding process must use this RDN to set the user up.

The onboarding transactions are:

  • RDN deposit to UDC
  • token of choice channel with a Hub

This is why we introduce a Hub Contract, that will implement 1 onboarding transaction in the Raiden Network between User -> HC. This transaction will:

  • approve deposit token amount to be sent to TokenNetwork; token will be whatever the user chooses, as long as the Hub also supports it
  • create User - Hub channel (TokenNetwork) (! Hub currently needs an Ethereum address with which to sign messages)
  • User deposit (TokenNetwork)
  • Hub’s deposit (TokenNetwork)

Note: the HC can be the one that sends the tokens for both his & the user's deposit. He can take RDN out from the UDC for the user deposit + some fee that he requests. So, he also does some exchange calculations (RDN - token_of_choice).

@hackaugusto

This comment has been minimized.

Copy link
Contributor

@hackaugusto hackaugusto commented Sep 25, 2018

User Deposit Contract

pros:

  1. This will require only one transaction from the user to pay for the third party services (the funding transaction, additional transactions may be done to top up or withdraw, but are not required)
  2. This fixes the problem of bootstrapping the PFS (To find a route for a transfer the user needs the PFS, to use the PFS the user needs to make a transfer)

cons:

  1. This will not have guarantees to the third party services about funds availability. This is assumed to be okay since the amount a user is paying to a third party is expected to be low enough that cheating would not make sense (vide notes below).

this will mark the MSC, PFSC, RSBC as trusted contracts

pros:

  • This limits the number of parties which have a "stake" in the UDC, allowing them to cooperate and make sure the funds are available (fixing the availability problem describe above)

cons:

  • Changes to configuration will require interaction to the blockchain
  • To increase safety, it may be necessary to add a timeout before the new configuration is in effect

global deposit in RDN for 3rd party services (MS, PFS, Matrix HS)

just to clarify, my understanding is: this deposit is done by the third party itself in the smart contract, not from a user to pay for a third party (this would be the UDC)

@loredanacirstea

This comment has been minimized.

Copy link
Contributor Author

@loredanacirstea loredanacirstea commented Sep 25, 2018

this deposit is done by the third party itself in the smart contract, not from a user to pay for a third party (this would be the UDC)

Correct. By the 3rd party itself. Clarified the issue description.

@loredanacirstea loredanacirstea changed the title Overview of Raiden Network non-core smart contracts Overview of Raiden Network RSB (non-core) smart contracts Jan 9, 2019
@loredanacirstea loredanacirstea mentioned this issue Jan 21, 2019
6 of 6 tasks complete
@pirapira

This comment has been minimized.

Copy link
Contributor

@pirapira pirapira commented Jan 21, 2019

I think we can close this issue after we turn this overview into the master branch.

@karlb

This comment has been minimized.

Copy link
Contributor

@karlb karlb commented Jan 22, 2019

the contract will make sure the 3rd parties withdrawing from it are registered in RSBC

I would have expected the following:

  • Each user can withdraw from his own balance (after the time out)
  • Trusted contracts can transfer tokens between users
  • The trusted contracts must verify registration in the RSBC themselves

If we want prevent unregistered services from using the MSC, we need to do that check anyway and can avoid the redundant check in the UDC.
Do we want to block unregistered services as far as possible, or do we just want to deprive them from getting paid?

@loredanacirstea

This comment has been minimized.

Copy link
Contributor Author

@loredanacirstea loredanacirstea commented Jan 22, 2019

Each user can withdraw from his own balance (after the time out)

Correct. It is mentioned: if the user wants to withdraw part/all of his deposit...

Trusted contracts can transfer tokens between users

First time I hear about this. I assume this was discussed/decided in the last meetings, where I was not present.

The trusted contracts must verify registration in the RSBC themselves

Yes, this seems like a better approach.

Do we want to block unregistered services as far as possible, or do we just want to deprive them from getting paid?

I cannot answer this myself. I see it as: unregistered services should be allowed to function, but they will not use the official setup that we have here (RSBC, UDC etc.). They can deploy their own.

@karlb

This comment has been minimized.

Copy link
Contributor

@karlb karlb commented Jan 22, 2019

Trusted contracts can transfer tokens between users

First time I hear about this. I assume this was discussed/decided in the last meetings, where I was not present.

We can either immediately withdraw tokens whenever a service claims a reward, or we can update balances. If we use raiden-network/raiden-services#38 for PFS payments, the latter looks like a better fit, since to my understanding transferring the tokens incurs additional gas cost. Please correct me if I'm wrong!

@loredanacirstea

This comment has been minimized.

Copy link
Contributor Author

@loredanacirstea loredanacirstea commented Jan 22, 2019

Trusted contracts can transfer tokens between users

So when you say users, you mean transferring tokens between a user and a service (e.g. a PFS), through the OTNC. So a service can be a user in the UDC contract?

Terminology might need clarification.
If a service can be a user in the UDC contract, then other rules might apply to it, as it would not have a deposit requirement. This may lead to some (code) confusion, but I'm not sure I understood it correctly.

@karlb

This comment has been minimized.

Copy link
Contributor

@karlb karlb commented Jan 22, 2019

So when you say users, you mean transferring tokens between a user and a service (e.g. a PFS), through the OTNC. So a service can be a user in the UDC contract?

Yes, I don't see a necessity to explicitly split end users from services. What would be a better term? "(balance) owner", "address", "participant", "party"? I'm not sure any of them is much clearer. If we don't find a good term, I'll at least add a clarification.

If a service can be a user in the UDC contract, then other rules might apply to it, as it would not have a deposit requirement. This may lead to some (code) confusion, but I'm not sure I understood it correctly.

Your plan was to do a token.transfer on both MSC.claimReward and when PFS payments are claimed and not keep any balance for services? The MSC currently keeps balances for both end users and services, so I expected that was the plan for the UDC. Has there been any discussion on these two approaches or have they been assumed the way to go by different people without each other noticing?

@loredanacirstea

This comment has been minimized.

Copy link
Contributor Author

@loredanacirstea loredanacirstea commented Jan 22, 2019

Yes, I don't see a necessity to explicitly split end users from services

This is fine. We have UserDepositContract and RaidenServiceBundle, so I was expecting to only see end users in UDC. Not saying it is wrong, but maybe worth a clarification in the UDC description.

Your plan was to do a token_network.transfer on both MSC.claimReward and when PFS payments are claimed

Not sure what the token_network would transfer here. You probably meant token.transfer.

I imagined something like:

  • withdrawing from UDC as a last step
  • MSC / PFSC can keep their internal balances or choose to withdraw on each request (MSC was built initially to withdraw on request, PFSC now has off-chain payments, so it can also withdraw on request without too much gas cost loss)

But again, we never specced this out in detail and it is also a matter of preference.

@karlb

This comment has been minimized.

Copy link
Contributor

@karlb karlb commented Jan 22, 2019

Not sure what the token_network would transfer here. You probably meant token.transfer.

Yes, I did. Fixed.

karlb added a commit to karlb/spec that referenced this issue Jan 25, 2019
Goals of this commit:
* Provide basis for more detailed service contract docs
* Incorporate raiden-network#120
* Incorporate raiden-network/raiden-contracts#447
* Allow automatic generation of docs from solidity docstrings
karlb added a commit that referenced this issue Jan 28, 2019
Goals of this commit:
* Provide basis for more detailed service contract docs
* Incorporate #120
* Incorporate raiden-network/raiden-contracts#447
* Allow automatic generation of docs from solidity docstrings
@karlb

This comment has been minimized.

Copy link
Contributor

@karlb karlb commented Apr 26, 2019

Overview of non-core contracts is available at https://raiden-network-specification.readthedocs.io/en/latest/service_contracts.html

@karlb karlb closed this Apr 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.