This is an introduction of a new proposed feature on smart contract level. The Token Network Contracts are the last instance to actually settle a channel respectively received and sent payments. They act as a judge validating the signed messages which where submitted by the participants. In reality a balance proof is just a promise or proof to settle the pooled funds as the counterpart promised. In case of a dispute automated mechanisms compare the signed messages and settle the channel by paying out the correct amounts to each participant derived from the promises they have made.
Adapting this idea to exchanges
As stated in #81 effectiveness is given if an exchange is effective after both parties are committed. It was also stated that this is only possible if assets can be transferred by this commitment. This is only possible if some entity has control over both funds - even if it has only control with the allowance of the rightful owner. These characteristics align perfectly with the characteristics of Token Network Contracts. They act in some sense as a custodian holding the funds. They have already the ability to move funds according to the promises the participants have made. They act as a judge in case of a dispute and enforce the effectiveness / execution of those promises. They furthermore are not a jurisdical entity rather than a trustless automated program removing the risk of Trusted Third Party fraud. (The reason for what smart contracts are there)
This brings the conclusion that the only truely logic bullet proof Fair Exchange Protocol includes a Token Network Contract with the enhanced ability to settle two transfers at the same time in case of a dispute. It is worth mentioning that obviously the arguments why this does not make sense for any participant are the same arguments as they are for normal payments. Economic incentives can push users to behave correctly. The usual way should always be settling the exchange by making payments through raiden but as a fallback the commitment must be enforceable!
Enforcing locked transfers vs Enforcing exchange promises
Locked Transfers
The above described problem is not new at all. It is quite similar to settling locked transfers with a secret. In a sense receiving a secret to a already received locked transfer can be seen as a promise that can be made effective on chain. As communicated by definition receiving the secret is seen as the payment which is already finalized or settled. Because it does not make sense to force the counterpart to go on chain and close the channel the participant would then just send the unlocked transfer. By the nature of second layer technologies participants only benefit if the channel stays alive as long as possible. In case of a dispute the disadvantaged participant would claim his promise by registering the secret to the locked transfer and force the channel to be closed and being paid out.
Exchange Promise
Looking to the agreement of an exchange it is quite similiar. It is just a promise in the next greater dimension. The locked transfer is a unidirectional promise in a single Token Network. The exchange commitment is a bidirectional promise valid in two Token Networks. The handling in case of a dispute however stays the same. Upon commitment of both participants the latter described promise is enforceable on chain. The disadvantaged participant would register the commitment (like the secret in the latter case) and settle the channel. Both corresponding Token Network Contracts would then settle by the promise given and payout the funds as the promises were made. Since it is in no ones best interest to close the channel the participants would then resolve the promise by making two unidirectional promises.
Another way to see the difference in dimension: The secret given in the Locked Transfer case is a promise to send an unlocked transfer. In case of a dispute - go on chain.
The commitment created in the second way - now bidirectional and claimable by both parties - is a promise to send the respective raiden payment which then results in the Locked Transfer case again. If anything goes wrong? Take the commitment and go on chain.
It is important to notice that the first dimension promise is unidirectional and therfore it does not require synchronization alignment. It is sufficient that the promising party commits by signing it and make sure the target receives the promise (achieved by secret request mechanism).
Since we now have a bidirectional promise which must be therefore mutually signed we introduce the problem of asynchronism. It is recommendable to involve a third party to align and synchronize communication and make sure nothing goes wrong (Notary Behavior).
Implementation Idea
To think about a way of implementing this functionality it is actually quite recommendable to look for existing implementation ways. And you do not have to look far... If the common understanding is clear that a commitment of binding two transfers together is quite the same as a promise of a payment (secret to a locket transfer) then the implementation of solving the secret settlement can be used as a reference.
There could be a Registry where any participant claim the mutually signed commitment of the two transfers. Upon closing the channel both respective Token Network Contracts would check if a commitment for the closing channel is given. If the submitted balance proof would be then older then the commitment, the commitment will be enforced and made effective. If both participants did the corresponding uni directional payment of the commitment the commitment can be seen made effective respectively closed.
Introduction
This is an introduction of a new proposed feature on smart contract level. The Token Network Contracts are the last instance to actually settle a channel respectively received and sent payments. They act as a judge validating the signed messages which where submitted by the participants. In reality a balance proof is just a promise or proof to settle the pooled funds as the counterpart promised. In case of a dispute automated mechanisms compare the signed messages and settle the channel by paying out the correct amounts to each participant derived from the promises they have made.
Adapting this idea to exchanges
As stated in #81 effectiveness is given if an exchange is effective after both parties are committed. It was also stated that this is only possible if assets can be transferred by this commitment. This is only possible if some entity has control over both funds - even if it has only control with the allowance of the rightful owner. These characteristics align perfectly with the characteristics of Token Network Contracts. They act in some sense as a custodian holding the funds. They have already the ability to move funds according to the promises the participants have made. They act as a judge in case of a dispute and enforce the effectiveness / execution of those promises. They furthermore are not a jurisdical entity rather than a trustless automated program removing the risk of Trusted Third Party fraud. (The reason for what smart contracts are there)
This brings the conclusion that the only truely logic bullet proof Fair Exchange Protocol includes a Token Network Contract with the enhanced ability to settle two transfers at the same time in case of a dispute. It is worth mentioning that obviously the arguments why this does not make sense for any participant are the same arguments as they are for normal payments. Economic incentives can push users to behave correctly. The usual way should always be settling the exchange by making payments through raiden but as a fallback the commitment must be enforceable!
Enforcing locked transfers vs Enforcing exchange promises
Locked Transfers
The above described problem is not new at all. It is quite similar to settling locked transfers with a secret. In a sense receiving a secret to a already received locked transfer can be seen as a promise that can be made effective on chain. As communicated by definition receiving the secret is seen as the payment which is already finalized or settled. Because it does not make sense to force the counterpart to go on chain and close the channel the participant would then just send the unlocked transfer. By the nature of second layer technologies participants only benefit if the channel stays alive as long as possible. In case of a dispute the disadvantaged participant would claim his promise by registering the secret to the locked transfer and force the channel to be closed and being paid out.
Exchange Promise
Looking to the agreement of an exchange it is quite similiar. It is just a promise in the next greater dimension. The locked transfer is a unidirectional promise in a single Token Network. The exchange commitment is a bidirectional promise valid in two Token Networks. The handling in case of a dispute however stays the same. Upon commitment of both participants the latter described promise is enforceable on chain. The disadvantaged participant would register the commitment (like the secret in the latter case) and settle the channel. Both corresponding Token Network Contracts would then settle by the promise given and payout the funds as the promises were made. Since it is in no ones best interest to close the channel the participants would then resolve the promise by making two unidirectional promises.
Another way to see the difference in dimension: The secret given in the Locked Transfer case is a promise to send an unlocked transfer. In case of a dispute - go on chain. The commitment created in the second way - now bidirectional and claimable by both parties - is a promise to send the respective raiden payment which then results in the Locked Transfer case again. If anything goes wrong? Take the commitment and go on chain.
It is important to notice that the first dimension promise is unidirectional and therfore it does not require synchronization alignment. It is sufficient that the promising party commits by signing it and make sure the target receives the promise (achieved by secret request mechanism). Since we now have a bidirectional promise which must be therefore mutually signed we introduce the problem of asynchronism. It is recommendable to involve a third party to align and synchronize communication and make sure nothing goes wrong (Notary Behavior).
Implementation Idea
To think about a way of implementing this functionality it is actually quite recommendable to look for existing implementation ways. And you do not have to look far... If the common understanding is clear that a commitment of binding two transfers together is quite the same as a promise of a payment (secret to a locket transfer) then the implementation of solving the secret settlement can be used as a reference.
There could be a Registry where any participant claim the mutually signed commitment of the two transfers. Upon closing the channel both respective Token Network Contracts would check if a commitment for the closing channel is given. If the submitted balance proof would be then older then the commitment, the commitment will be enforced and made effective. If both participants did the corresponding uni directional payment of the commitment the commitment can be seen made effective respectively closed.