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

loredanacirstea commented 6 years ago

Notes from the 24 August planning meeting regarding this:

MSC - Monitoring Service Contract - https://github.com/raiden-network/spec/issues/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 commented 6 years ago

User Deposit Contract

pros:

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)
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:

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 commented 6 years ago

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.

pirapira commented 5 years ago

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

karlb commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/raiden-network/raiden-services/issues/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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Yes, I did. Fixed.

karlb commented 5 years ago

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

raiden-network / spec