Perun: virtual payment and state channel networks


#21

And wearing the hat of promoter for generalized state channels, pay-per-hop can also be viewed as “pre-compiled” SLA resolution, where per payment fee is depending on the SLA of “deliver my payment to destination”.


#22

Can you give an example of a simple SLA proof construction that works? I’m struggling to see how whether an off-chain SLA has been met falls into the class of things that the chain can adjudicate. For example, the following things look the same to the chain:

  1. A promised B to route up to 5ETH a day. A claims that they met the SLA, as B sent them one request to route 2ETH, which they routed to C for them.
  2. A promised B to route up to 5ETH a day. B claims that they missed the SLA, as B sent them two requests to route 2ETH, and they only routed one of them to C.

Is it possible to distinguish between these two cases on-chain? It seems like you’d at least need to introduce a trusted third party here (in which case it can’t be done trustlessly), and even then it’s difficult to see how to judge whether someone actually received something that they’re claiming they didn’t (when, for example, you allow messages to be dropped by the network so that “proof of send” != “proof of receipt”).


#23

On reflection of my above answer, I believe I made an mistake implying there are various simple SLAs can be enforced in a state channel network scenario. The only simple SLA that is on-chain verifiable is one’s service provider’s total deposit and deposit time length to him/herself and that is trivial to verify. This SLA is simple to verify because the state is local between involved counterparties. In that model, subscription can be done and it is just like today’s Internet ISP’s SLA to end users: “down load speed up to 100Mbps”. If people feels like their ISP is not living up to that promise, they will just pay up this month’s subscription fee and switch to a different provider next month.

“Guaranteed delivery” is a indeed a more complicated SLA to verify. Before going into trust/trustless constructs, I would like to highlight that this is hard because the state being disputed involves parties external to the channel being disputed. However, I am inclined to think that it is still possible with more intricacies. Thinking out loud here and let’s discuss and see if the following construct works.

Let’s assume the simple topology A – B – C. Let’s also assume the SLA between A and B is specified as “able to deliver all available deposits to destinations”. Note that this SLA needs to be mutual in nature: for A -> B direction, destination can be a very wide range or simply *, but for B->A direction, the destination is just A. Similar arrangement exists between B and C. Let’s assume A is trying to transfer money to C. A will only qualify to complain about the SLA by claiming (may not be true) an HTL transfer that is destined to C is not reaching C. He will file that complaint by submitting a pending HTL transfer (however one constructs it, can be specialized object but we are doing it as a generalized conditional state transition object) to the instantiated SLA judgement contract.

Upon this challenge, if B seriously cannot deliver this payment to C (e.g. due to depleted channel balance), then B will just swallow this and accept the failure of SLA.

However, if B believe that A is being unreasonable, he can pick up that HTL transfer, deliver it to C, get C’s signed ACK and use that as a counter-proof for this dispute. A and B will hopefully figure out if there is network outage problem or not. Note that in this A<->B only case, the common griefing scenario for state channel exists: after this back-and-forth dispute bystanders/blockchain is not able to distinguish whether A is being unreasonable or B is being deliberately unresponsive until A complains on-chain. However, this is reduces to a general challenge-response problem that every state channel will face and a common specification is defined to handle this.

Now onto the interesting stuff: the involvement of external parties. Let’s say B got the HTL transfer, it also has enough capacity to deliver it to C and he tried to send that to C, but C is just not responsive (offline or colluding with A trying to indict B on SLA). The mutual SLA comes in here. B here will claim that C is violating the SLA on the direction of B->C by submitting the HTL transfer it was trying to relay to C to the SLA contract between B and C. If C is indeed unresponsive, B, like relaying payment, effectively relays “SLA violation claims” from A to C. C will pay B certain penalty for not honoring the SLA and B will pay A SLA penalty. In this chained construct, the one who is faulty finally pays. How the penalties are constructed exactly I haven’t thought through, but this is the gist of the idea. This can also be extended to the case of multiple hops between source and destination.

Of course, I might have missed something here, happy to discuss more.


#24

Ok, that makes sense to me. At a high level, it seems that instead of providing a proof that the off-chain SLA wasn’t met (which does seem impossible - as you put it, due to the common griefing scenario), you’re providing a challenge to meet the SLA then and there. It’s then the response (or lack of response) to this challenge, that the chain can adjudicate on. :+1:


#25

yes sir and one particular interesting thing is the dependency on external factors here in a networked state channel scenario.