Monitoring Service

Overview

Monitoring services (MS) watch open payment channels when the user is not online. In case one channel partner closes a channel while the counterparty is offline or does not react itself, the Monitoring Service sends the latest balance proof to the TokenNetwork contract and thus ensures correct settlement of the channel.

To do this a Monitoring Service listens to Monitor Requests in a public Matrix room. An MR is accompanied by a reward for acting on it. Based on this reward, the MS can decide to monitor a channel and store the corresponding MRs.

Whenever a channel is closed by calling closeChannel and if the client did not react itself, the MS will call MonitoringServiceContract.monitor(...) with the submitted MR on behalf of its client. For that action the MS can then claim the reward. For more information see the documentation of the Monitoring Service contract.

Information Flow

Monitoring Service - Flow Chart

Design of the Monitoring Service

Requirements

  • Sybil Attack resistance (i.e. no one should be able to announce an unlimited number of possibly faulty services)
  • Some degree of redundancy (ability to register a balance proof with multiple competing monitoring services)

In the current stage we opt for a simple design which is expected to help reach a working state faster. Therefore some user friendly features are currently out of scope.

Monitoring Service Payment

The MS can claim its reward after successfully submitting its client’s balance proof update. Sending this update is only allowed when the MS is registered in the Service Registry. Therefore, only registered MS can receive payments. For more information see the ServiceRegistry contract specification.

The payment is paid out from a deposit in the UserDeposit Contract (UDC). Ideally, only one MS submits the latest BP to the contract to avoid wasting gas. For more information see the description of the Monitoring Service contract.

MS Reliability

The Monitoring Service itself is split into two components to increase reliability and lower the attack surface.

  • The request collector is a simple component that connects to the Matrix network and listens only for Monitor Requests, which are written to a database.
  • The monitoring service itself just reads these MRs from the database and otherwise listens to blockchain events and updates the respective smart contracts by sending transactions.

Privacy

The recipient and the actual transferred amounts are hidden by providing a hashed balance proof. This provides some sort of privacy even if it can potentially be recalculated. For reference see this issue.

Message Format

Monitoring Services use the JSON format to exchange the data. For description of the envelope format and required fields of the message please see Transport specification.

Monitor Request

Monitor Requests are messages that the Raiden client broadcasts to Monitoring Services in order to request monitoring for a channel.

A Monitor Request consists of a the following fields:

Field Name Field Type Description
balance_proof object Latest Blinded Balance Proof to be used by the monitor service
non_closing_signature string Signature of the on-chain balance proof by the client
reward_amount uint256 Offered reward in RDN
reward_proof_signature string Signature of the reward proof data.

All of this fields are required. Monitoring Service must perform verification of these data, namely channel existence. Monitoring service should accept the message if and only if the sender of the message is same as the sender address recovered from the signature.

Example Monitor Request

{
  "balance_proof": {
      "token_network_address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
      "chain_id": 1,
      "channel_identifier": 76,
      "balance_hash": "0x1c3a34a22ab087808ba772f40779b04e719080e86289c7a4ad1bd2098a3c751d",
      "nonce": 5,
      "additional_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
      "signature": "0xd38c435654373983d5bdee589980853b5e7da2714d7bdcba5282ccb88ffd29210c3b1d07313aab05f7d2a514561b6796191093a9ce5726da8f1eb89bc575bc7e1b"
  },
  "non_closing_signature": "0x77857e08793165163380d50ea780cf3798d2132a61b1d43395fc6e4a766f3c1918f8365d3bef173e0f8bb32c1f373be76369f54fb0ac7fdf91dd559e6e5865431b",
  "reward_amount": 1234,
  "reward_proof_signature": "0x12345e08793165163380d50ea780cf3798d2132a61b1d43395fc6e4a766f3c1918f8365d3bef173e0f8bb32c1f373be76369f54fb0ac7fdf91dd559e6e5864444a"
}

Reward Proof

ecdsa_recoverable(privkey, sha3_keccak("\x19Ethereum Signed Message:\n221"
    || monitoring_service_contract_address || chain_id || MessageTypeId.MSReward
    || token_network_address || non_closing_participant || non_closing_signature || reward_amount ))

Fields

Field Name Field Type Description
signature_prefix string \x19Ethereum Signed Message:\n
message_length string 221 = length of message = 20 + 32 + 32 + 65 + 20 + 20 + 32
monitoring_service _contract_address address Address of the monitoring service contract in which the reward can be claimed
chain_id uint256 Chain identifier as defined in EIP155
MessageTypeId.MSReward uint256 A constant with the value of 6 used to make sure that no other messages accidentally share the same signature.
token_network_address address Address of TokenNetwork that the request is about
non_closing_address address Address of the client that signed non_closing_signature
non_closing_signature bytes Signature of the on-chain balance proof by the client
reward_amount uint256 Rewards received for updating the channel
signature bytes Elliptic Curve 256k1 signature on the above data from participant paying the reward

Security Analysis

This is inspired by the security analysis in the PISA paper.

State Privacy

Blinded BPs are published to the MS as part of the Monitor Request in the matrix room and then submitted to the smart contract.

Fair Exchange

Clients 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 client 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 client’s request, the client 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 client’s channel deposit at risk by ignoring all client requests. But since a MS can’t force other MSs to ignore client 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 client’s deposit. In the short run, this is an acceptable outcome for the client. 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 client 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 client 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. A client 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 client 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 client, 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.