[WIP] The Commitment Service, yet another Raiden Service?

[fredo]

Taking a closer look on the CS and its properties, similarities to other proposed raiden services like the PFS or MS come to surface. All three services have one big property in common - Providing a service to make the raiden network functioning better.

The following assumption for all three services is given: Raiden Nodes use these services to improve the functionality of the network or gain different abilities. It is in the raiden nodes’ best interests to improve the network and keep it alive. Therefore even sacrifices regarding privacy and decentralization are made. Is this true?

All services rely partly or fully on information about the current state and/or intervene in case of a dispute by interacting with the smart contracts during settlement time. They require active participation of raiden nodes.
##Service Comparison

Pathfinding Service

The pathfinding service requires a global overview of the current network. Raiden Nodes sacrifice this privacy aspect in order to obtain a well functioning network and to be involved as intermediaries to earn money in terms of a fee. As a trade off pathfinding services could censor nodes due to their centralized characteristic. The worst case for a node would be denial of service and no earning through fees.
Do you want to have efficient routing of your payments? Use the PFS

Monitoring Service

The monitoring service offer the ability for a node to be offline. The MS holds the last balance proof in case of running into a challenge period while the respective client is offline. The MS will intervene in case of a dispute. Being offline in the moment of settlement therefore is equivalent of trusting the MS to act on behalf of the node itself. In the worst case the MS is not intervening and an old balance proof is used to settle the channel. This results in a potential loss of funds.
Do you want to be able to go offline? Use the MS

Commitment Service

The CS offers the service of binding two transfers together. It guides the process of signing since there are potentially two parties involved. The final outcome of the service is an enforceable proof of two balances in two different channels - like two balance proofs in one. In order to function properly it needs to know the current state of a channel. In the worst case an evil CS will not share the signed commitment making the bound transfer non existent. Users can not lose their funds.
Do you want to exchange safely? Use the CS

The Commitment Service

As proposed in #82 and above the commitment service is an optional service to improve the contract signing of exchanges by creating a transfer binding. All participating clients involved in the channels are commiting to the current state and transfer by signing it. Synchronizing the commitments and putting them into one authenticated message is the service provided by the commitment service. The service is optional because participants could agree and sign on this message directly without the interaction of the commitment service. This unfortunately introduces the risk of misbehaviour of one of the participants, leaving the other in an uncertain state. Since this is an undesirable state for any participant the assumption can be made that they want to consult a service acting as a notary authenticating the message. Same as participants could not want to pay for a monitoring service taking the risk of being offline during settlement.

Commitment Service vs. Raidex

The Commitment Service would then be an instance creating a proof to make the use of the Raiden ecosystem in-built ability of binding transfers together. For what this service is going to be used is not stated out.

The Raidex exchange on the other hand is a client implementation of and Raiden based exchange using the Commitment service within its protocol to strengthen the successful execution of an exchange. To be more precised the commitment service is only consulted within the State Validation & Commitment Phase and its output could be used later in the protocol.

This separation enables a raiden related service to offer a general functionality of new abilities within the raiden eco system. Raidex itself will be the first implementation of such a service.

Why introducing a new service (some thoughts)

Developer Adoption

Introducing a new service with the ability of binding transfers offers a new functionality which developer should easily integrate into their dApps. Especially exchanges should be onboarded much simpler and much faster then having the need of implementing this service by themselves. It also enables the raiden network natively supporting all features necessary to be used in an fair exchange protocol. This is cruical for making decentralized exchanges work. I'd rather argue that it is necessary introducing necessary features on the raiden implementation in order to make it possible to be used in fair exchange protocols.

User Adoption

By enabling raiden to be used as the underlying exchange platform user adoption could come along with the rise of new exchanges.

Native Fee of CS - RDN

The CS could like the other services be paid in RDN natively. By adopting more users through exchanges the circulation and demand of RDN rise. In general characteristics and implementation structure could be adapted from the other services.

Idea: Overlapping Commitments
Rebalance

Improvements:

Service registry - similar to PFS/MS ideas

proposal:

Introducing another service.
Generalized a transfer binding service.
Usage:
exchanges
rebalancing schemes
multi currency payments
split payments
Introducing same properties as other services.
Being paid in RDN.
Registered on chain.
Reputation scheme.

Why?
Enabling different use cases such as exchanges - potentially new users
Making effective exchange as a built in raiden feature
Making rebalancing trustless through overlapping transfer bindings
Promoting RDN token by having a new service paid in RDN (potentially high volume with exchanges, rebalancing also)