Monitoring Service: Current Proposal
Summary
- Monitoring Services (MS) listen to blinded Balance Proofs (BP) and proposed service fees in a public Matrix Room
- MSs can decide to monitor a channel and store corresponding BPs
- Then, whenever a channel is closed by calling
closeChannel the MS will call updateNonClosingBalanceProof with the submitted BP by its client
- Service fees are paid in RDN, no free tier
- In the short term we favor this proposal over a PISA approach, because of its simpler design which will allow us to reach the Ithaca milestone earlier. In the long-term we see the PISA approach as more economically viable and user friendly, but this design requires additional features and can be developed independently after Ithaca.
Service Registration
RSB slots, the set of Raiden Service Bundle Providers, will be auctioned, and that the MS being part of RSB would register as part of the RSB auction.
If chosen in the auction then they will become part of the list of MSes and must deposit some tokens.
Resources: (Old) MS specification
This proposal describes our current plan to implement and required changes (if any) to reach Ithaca.
Service Payment
The service is paid after successfully submitting its client’s balance proof update. The payment is paid out from a deposit in the User Deposit Contract (UDC).
Change to current implementation: Ideally, only one MS submits the latest BP to the SC to avoid unnecessary gas usage. This can be made more likely by choosing the rewarded MS based on a function of the MS’s address and the current block number. MSs which have a low f(address, block_num) would be incentivized to wait for a block number which yields a higher f for them, since they would probably lose out to another MS if they submitted the BP during the current block. Incentivizing MSs to wait in some cases greatly reduces the number of MSs submitting BPs simultaneously.
Ensuring MS Reliability
The MS has an incentive to intervene in case of a dispute, since it is only paid in that case. There are no incentives for a high level of reliability and the user knows neither how many MSs are monitoring his channel nor how reliable they are. These tradeoffs are made to favor simplicity of implementation.
Onboarding
The user has to deposit an amount of RDN into the UDC in order to provide rewards to the MS. This happens during the general Raiden onboarding process, so that no additional preparation is necessary when use of a MS is desired.
Service Discovery
All MS listen in a Matrix room. BPs are broadcast and no specific MSs are appointed. The MSs can also publish their expected rewards in this room, which does not provide any guarantees, but increases the chance of reliable monitoring if both parties cooperate.
Privacy
The Recipient and the actual transferred amounts amount are hidden by providing a hashed balance proof (or state). This provides some sort of privacy even if it can potentially be recalculated.
Milestones
Security Analysis (compared to PISA)
State Privacy
Blinded BPs are published to the MS in the matrix room and then submitted to the smart contract .
Fair Exchange
The user can freely choose the reward for the MS, so it is easy for him to choose the amount in a way that makes the exchange attractive for himself. The user can’t know if a MS started monitoring his payment channel, so he can’t use such feedback to arrive at a reward where he knows that the deal is attractive for both him and the MS. Neither can he recognize if there is no such possible reward.
The MS on the other hand can freely choose to ignore requests when the reward is too low, so he will only choose requests that he deems fairly rewarded. If the MS ignores the user’s request, the user keeps his deposit and it can be used by other MSs or for later BPs.
In summary, the exchange is fair for both parties, but there is a high likelihood that no exchange will happen at all.
Non-frameability
MSs can put the users channel deposit at risk by ignoring all user requests. But since a MS can’t force other MSs to ignore user requests, this can not be considered as framing.
When only a single MS is monitoring the channel, the MS’s dispute intervention and the reward payment happen atomically inside the SC. In this case, no party can frame the other.
When multiple MSs try to settle the same dispute, only the first one doing so receives a reward, but all of them have to invest resources to monitor the channel and spend gas to interact with the SC. If you find a way to continuously front run other MSs, you can drain their resources and block their only income. However, while doing so you fulfilled the MS’s duty to settle the payment channel correctly and protect the user’s deposit.
In the short run, this is an acceptable outcome for the user. In the long run, this will drive other MSs out of business and thus reduce redundancy and reliability of the overall MS ecosystem. Since all MSs try to be the first to submit a BP, it is unlikely that a single MS will continuously be the fastest, but slightly slower MSs will still not get any rewards even if they are well behaved and reliable.
If a user wants to waste the resources of MSs, he can first broadcast a BP with a high reward and keep more recent BPs to himself. When a dispute happens, he can wait for the MSs to act before submitting his latest BPs, which prevents the MSs from receiving a reward. Doing this at a large scale is expensive, since the user needs to open and close a payment channel for this at his own cost.
Recourse as a financial deterrent
There is no possibility of recourse which lets MSs operate without any incentive of high reliability. User must expect MSs to ignore their requests and have no means to force a highly reliable monitoring.
Efficiency Requirements
For each channel, only the latest (as indicated by the nonce) BP has to be saved. Unless an extremely high amount of channels is being monitored, this efficiency should not be a concern for the MS.
A user can use a single deposit to request an MS to monitor all his payment channels. If this causes the MS to monitor a problematically high amount of channels, he can start to ignore requests made by this user, or even drop old requests. Since there is no punishment for failing to monitor a channel, stopping to monitor is a simple way to reduce resource usage when desired, although it should not be necessary under normal circumstances.
Monitoring Service: Current Proposal
Summary
closeChannelthe MS will callupdateNonClosingBalanceProofwith the submitted BP by its clientService Registration
RSB slots, the set of Raiden Service Bundle Providers, will be auctioned, and that the MS being part of RSB would register as part of the RSB auction.
If chosen in the auction then they will become part of the list of MSes and must deposit some tokens.
Resources: (Old) MS specification
This proposal describes our current plan to implement and required changes (if any) to reach Ithaca.
Service Payment
The service is paid after successfully submitting its client’s balance proof update. The payment is paid out from a deposit in the User Deposit Contract (UDC).
Change to current implementation: Ideally, only one MS submits the latest BP to the SC to avoid unnecessary gas usage. This can be made more likely by choosing the rewarded MS based on a function of the MS’s address and the current block number. MSs which have a low f(address, block_num) would be incentivized to wait for a block number which yields a higher f for them, since they would probably lose out to another MS if they submitted the BP during the current block. Incentivizing MSs to wait in some cases greatly reduces the number of MSs submitting BPs simultaneously.
Ensuring MS Reliability
The MS has an incentive to intervene in case of a dispute, since it is only paid in that case. There are no incentives for a high level of reliability and the user knows neither how many MSs are monitoring his channel nor how reliable they are. These tradeoffs are made to favor simplicity of implementation.
Onboarding
The user has to deposit an amount of RDN into the UDC in order to provide rewards to the MS. This happens during the general Raiden onboarding process, so that no additional preparation is necessary when use of a MS is desired.
Service Discovery
All MS listen in a Matrix room. BPs are broadcast and no specific MSs are appointed. The MSs can also publish their expected rewards in this room, which does not provide any guarantees, but increases the chance of reliable monitoring if both parties cooperate.
Privacy
The Recipient and the actual transferred amounts amount are hidden by providing a hashed balance proof (or state). This provides some sort of privacy even if it can potentially be recalculated.
Milestones
Security Analysis (compared to PISA)
State Privacy
Blinded BPs are published to the MS in the matrix room and then submitted to the smart contract .
Fair Exchange
The user can freely choose the reward for the MS, so it is easy for him to choose the amount in a way that makes the exchange attractive for himself. The user can’t know if a MS started monitoring his payment channel, so he can’t use such feedback to arrive at a reward where he knows that the deal is attractive for both him and the MS. Neither can he recognize if there is no such possible reward.
The MS on the other hand can freely choose to ignore requests when the reward is too low, so he will only choose requests that he deems fairly rewarded. If the MS ignores the user’s request, the user keeps his deposit and it can be used by other MSs or for later BPs.
In summary, the exchange is fair for both parties, but there is a high likelihood that no exchange will happen at all.
Non-frameability
MSs can put the users channel deposit at risk by ignoring all user requests. But since a MS can’t force other MSs to ignore user requests, this can not be considered as framing.
When only a single MS is monitoring the channel, the MS’s dispute intervention and the reward payment happen atomically inside the SC. In this case, no party can frame the other.
When multiple MSs try to settle the same dispute, only the first one doing so receives a reward, but all of them have to invest resources to monitor the channel and spend gas to interact with the SC. If you find a way to continuously front run other MSs, you can drain their resources and block their only income. However, while doing so you fulfilled the MS’s duty to settle the payment channel correctly and protect the user’s deposit.
In the short run, this is an acceptable outcome for the user. In the long run, this will drive other MSs out of business and thus reduce redundancy and reliability of the overall MS ecosystem. Since all MSs try to be the first to submit a BP, it is unlikely that a single MS will continuously be the fastest, but slightly slower MSs will still not get any rewards even if they are well behaved and reliable.
If a user wants to waste the resources of MSs, he can first broadcast a BP with a high reward and keep more recent BPs to himself. When a dispute happens, he can wait for the MSs to act before submitting his latest BPs, which prevents the MSs from receiving a reward. Doing this at a large scale is expensive, since the user needs to open and close a payment channel for this at his own cost.
Recourse as a financial deterrent
There is no possibility of recourse which lets MSs operate without any incentive of high reliability. User must expect MSs to ignore their requests and have no means to force a highly reliable monitoring.
Efficiency Requirements
For each channel, only the latest (as indicated by the nonce) BP has to be saved. Unless an extremely high amount of channels is being monitored, this efficiency should not be a concern for the MS.
A user can use a single deposit to request an MS to monitor all his payment channels. If this causes the MS to monitor a problematically high amount of channels, he can start to ignore requests made by this user, or even drop old requests. Since there is no punishment for failing to monitor a channel, stopping to monitor is a simple way to reduce resource usage when desired, although it should not be necessary under normal circumstances.