Monitoring Service: on-chain rewards proposal

@LefterisJP

As discussed with @LefterisJP and @heikoheiko the following is a proposal for on-chain payments to the MS.

Requirements

core protocol is unaffected
reduced number of channels that a user (Raiden node / Raiden Light Client) needs to open when onboarding
reduced gas cost
reduced development complexity

Assumptions

a normal user will probably not need to do a monitored updateTransfer too frequently
a user needs at least 2-3 MS to monitor his channel

Logic

MS makes a token deposit to the MS Contract (MSC)
a user (Raiden node) only needs to make 1 deposit in tokens to MSC that will be used to pay rewards to any MS that calls updateTransfer in his behalf
update balance on behalf of the user:

balance_proof = (channel_identifier, nonce, transferred_amount, locksroot, additional_hash, closing_signature, non_closing_signature)

MS -> MSC.monitor(balance_proof, reward_proof): MSC stores channel_identifier, MS_address, reward_amount, nonce
MSC -> TokenNetwork.updateTransfer(balance_proof)

any MS can call monitor, MSC will store the MS_address of the MS that provided the later balance_proof
after channel is settled, MS needs to claim his reward

MS -> MSC.claim: transfer(MS_address, reward_amount), delete stored data

Pros:

User only needs to do 1 deposit (1 on-chain transaction) for all Monitoring Services
Reduced implementation complexity

Cons:

MS needs to call 2 contract functions in order to get his reward
a user cannot control or make sure that a MS will update his balance unless we implement additional functionality for this (e.g. off-chain receipt, forfeiting part of the MS deposits etc.)

Note: off-chain rewards proposal: #25

Rough gas cost estimations:

above on-chain payout proposal:
MSC.deposit: token transfer + 1 SSTORE = ~40k
MSC.monitor: 65k + 25k = ~80k

updateTransfer
minimal storage of 25k gas:

// channel_identifier => Struct
mapping (uint256 => RewardStruct)
struct RewardStruct {
        uint192 reward;
        uint64 nonce;
        address ms_address;
    }

MSC.claim: token transfer - delete storage = 21k + 13.5k + 3 * 5k - 2 * 15k = ~15k

off-chain payout proposal:
uRaiden.openChannel: ~100k (open & deposit)
TokenNetwork.updateTransfer: ~65k

Additional Pros:

Reduced protocol and implementation complexity. In it's easiest variant, the client would only need to broadcast the to be monitored balance.
One deposit grants access to all MSs (i.e. no need to do multiple deposits, send in multiple txs).

Regarding the Cons:

MS needs to call 2 contract functions

Yes, it needs to send in two transactions. But this is bearable for this being the unhappy case.

a user cannot control or make sure that a MS will update his balance

The assumption here is, that a possible reward is sufficient to incentivise eligible monitoring services to updateTransfer. But this is also compatible with a panelization based approach as described in #22 (there payments and signed monitoring commitments are not atomic) and could be updated to it later. Same for the privacy feat, which can also be implemented within this approach.

On a general note: My assumption is, that a channel partner would always aim (and patiently wait) for a cooperative close, as this is cheaper. Therefore closing with the help of an MS is an edge case.

Reduced protocol and implementation complexity. In it's easiest variant, the client would only need to broadcast the to be monitored balance.

This is the biggest pro for this approach I think.

The assumption here is, that a possible reward is sufficient to incentivise eligible monitoring services to updateTransfer.

I understand that assumption but I am not really convinced it's sufficient.

On a general note: My assumption is, that a channel partner would always aim (and patiently wait) for a cooperative close, as this is cheaper. Therefore closing with the help of an MS is an edge case.

I don't agree with this assumption and I don't think this is how thing will happen in real life in the case a channel partner is offline. Main reason to close a channel is because you need your funds as soon as possible. Picture a market event that causes sudden drop of a token value and you want to move to an exchange asap.

You will not wait for your channel partner to come online in such a case.

Regardless as also discussed in the chat and in person the on-chain payment seems like the easiest way to go forward fast for now and we can swap the payment method at any time we have something better.

A more technical question for this proposal is how would the monitors figure out who can updateTransfer() first? Would it be an on-chain race for whomever manages to get the transaction mined first? What about miner front-running?

Another idea we had discussed was that the user would assign an order to the monitors he registers with so that only N blocks after closing would each monitor be able to perform the transaction.

Yes coordination is important.

If the user picks MSs
he could set an individual block number offset (from the block number, where the closing was triggered) for each MS from which on the MS contract would accept an updateTransfer.

If the user broadcasts
we could index the eligible MSs (e.g. 0-99) then we could divide the block timeout (e.g. 1000 blocks) by the number of MSs. Thereby every few blocks the number of MSs who are eligible to close could increase, based on their index and offset. We'd use some random value to derive an ordered list of MSs for a closing.

why MS doesn't provide service of Unlock？
In general, the MediatedTransfer 's expiration lock time is much less than the channel settle time, and the user is more likely to suffer losses.

why MS doesn't provide service of Unlock？

It avoids having to proof if the unlock did or did not happen. The user will still be safe because of the secret registry

@loredanacirstea

It is not entirely clear for me what the deposit made by the MS is for in your proposal is, @loredanacirstea . Can you elaborate a bit on the idea of this? Or is it for some kind of punishment scheme for bad behavior that we still need to specify?

@czepluch

@czepluch , the MS deposit is more of a bonding deposit - @heikoheiko knows more about this. We are not implementing punishments yet, though this deposit would make it possible. For the moment, we will be going with a rewards-based system.

Okay, will talk to Heiko or Lefteris.

Do we want to distinguish between the two kinds of deposit? MS_deposit and user_deposit. I guess if we have two different kinds we can use one of them to register Monitoring Services.

@nkbai

@nkbai , as Augusto said, the unlocked amount will stay safe and in the new (future) implementation, the user can call a batch unlock after settling the channel - see #35.
Note, that this is work in progress - this is why it is not added in the specs yet.

@hackaugusto

@hackaugusto
does secret registry have any relation with sprites and State Channels

@loredanacirstea

@loredanacirstea it seems that unlock have the same timeout expiration with updatetransfer. from the contract tokennetwork.sol. if updatetransfer is not safe ,a node needs a MS to udpatetransfer, it also means that unlock is not safe. we cannot call unlock after channel is settled.

Is the MSC being written? No related source code yet?

@loredanacirstea

@loredanacirstea Do you means that a new version of tokennetwork.sol is implementing which allow withdraw tokens after a channel is settled?

Yes coordination is important.

The coodination also could be done with an auction-based reward where the reward starts at x % of the amount user wants to pay and then the amount increases as the end of the settlement period is approaching. This can naturally reach an equilibrium state where actors wait until the reward reaches the cost for running the MS.

How do we assure that the deposit made by a raiden_node can cover all the potential rewards that will be paid out to MSs? If the reward_amounts are dynamic this will be very difficult to prevent.

@czepluch

@czepluch That's easy.

From The MS side, the MS will be checking the blockchain to see if there is enough deposit to cover his reward before calling updateTransfer()

From the raiden node which will go offline all that needs to be done is make sure it never promises a reward bigger than its deposit.

The MS can check it before calling updateTrasnfer(), yes, but if there are other channels with shorter settlement timeout, couldn't they beat this MS to claiming the reward?

I guess this can be solved by updating the remaining MSC balance of the raiden node when calling monitor instead of waiting until claim is called.

The MS can check it before calling updateTrasnfer(), yes, but if there are other channels with shorter settlement timeout, couldn't they beat this MS to claiming the reward?

I'd say it's definitely possible, but this requires all monitored channels to be closed all at once and the reward claimed immediately after.
Otherwise if the channels are closed sequentially, MS can probably check remaining balance and refuse update in that case.

the risk is still higher for Raiden node that fails to maintain sufficient deposit in MSC rather than for MS. If MS decides not to call update, it will lose nothing. For Raiden node failed channel update means possible loss of funds.

Notes from the 24 August planning meeting regarding the MS:

MSs need to receive all balance proofs from a transfer (LockedTransfer, Secret)
regarding the order in which the MSs will send the transaction that will update the user’s balance proof, this must be enforced by the MSC and can use block distance - allow an MS to send the transaction only between certain block values (e.g. MS1: closing_channel_block -> closing_channel_block + 5, MS2: closing_channel_block + 5 -> closing_channel_block + 10 etc.);

What is the next action with this issue?

@palango

This is the initial MS setup. A new issue has been created: #192, not sure what exactly has changed because I haven't looked in detail. @palango should clarify.

I think this issue can probably be closed.

@palango

@palango please confirm what @loredanacirstea said above.

Navigation Menu

Repository navigation

Monitoring Service: on-chain rewards proposal #46

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Monitoring Service: on-chain rewards proposal #46

Description

Activity

loredanacirstea commented on Mar 30, 2018

heikoheiko commented on Mar 31, 2018

LefterisJP commented on Mar 31, 2018

LefterisJP commented on Mar 31, 2018

heikoheiko commented on Apr 1, 2018

nkbai commented on Apr 4, 2018

hackaugusto commented on Apr 4, 2018

czepluch commented on Apr 4, 2018

loredanacirstea commented on Apr 4, 2018

czepluch commented on Apr 4, 2018

loredanacirstea commented on Apr 4, 2018

nkbai commented on Apr 4, 2018

nkbai commented on Apr 4, 2018

nkbai commented on Apr 4, 2018

nkbai commented on Apr 4, 2018

3 remaining items

pcppcp commented on Apr 5, 2018

czepluch commented on Apr 5, 2018

LefterisJP commented on Apr 5, 2018

czepluch commented on Apr 5, 2018

czepluch commented on Apr 5, 2018

pcppcp commented on Apr 5, 2018

pcppcp commented on Apr 5, 2018

loredanacirstea commented on Sep 3, 2018

pirapira commented on Jan 21, 2019

loredanacirstea commented on Jan 21, 2019

pirapira commented on Jan 21, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions