Add support for multihop payments #132
Conversation
| selected[i] = shuffled[i] | ||
| } | ||
|
|
||
| // TODO: Virtual defunding seems to fail if intermediaries are not in "order". |
There was a problem hiding this comment.
To co-ordinate who initiates the ledger channel between two hubs I've introduced a simple rule: The participant with the lowest sequence number of the two hubs is responsible for creating the ledger channel.
It seems that the intermediaries need to passed in the correct order, based on the ledger initiator (I think?).
Since we use the sequence number to determine who initiates ledger channels we can just sort the intermediaries we pass in by their sequence number.
If I don't do this I get this error:
[0m panic: 0xA73B1683e0FCD74CEFF77aA5A90cAE1cF52d1c0F, error in run loop: signed proposal is not addressed to a known ledger connection {Signature:{R:[92 99 4 159 107 148 113 183 88 34 206 249 199 58 188 66 200 68 183 34 223 59 233 114 212 234 215 169 34 23 226 41] S:[123 131 214 254 250 117 65 42 222 212 113 236 31 15 36 251 243 88 198 162 117 13 215 51 6 198 227 98 105 176 200 126] V:28} Proposal:{LedgerID:0x1db0ab987f97ca8d2d21845016ebe74996102fb884b78c77efb88739a0b069c0 ToAdd:{Guarantee:{amount:<nil> target:[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] left:[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] right:[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]} LeftDeposit:<nil>} ToRemove:{Target:0x6d8536f70e580266089f52475b49a95d97bed033b94a516b02a16803242e24f2 LeftAmount:+9999995628}} TurnNum:4}
There was a problem hiding this comment.
Let's get an issue open to track this.
lalexgap
force-pushed
the
multi-hop
branch
3 times, most recently
from
2cdd2b0 to
f7cc2dc
Compare
lalexgap
added
the
🇵🇹 Lisbon
There was a problem hiding this comment.
Thanks @lalexgap, it looks like this work is throwing up some important bugs in go-nitro that we should go and chase down.
I think we will want to think about network topologies and which scenarios we would like to investigate in particular.
| // Close all the ledger channels with the hub | ||
| oIds := []protocols.ObjectiveId{} | ||
| for _, ledgerId := range ledgerIds { | ||
| runEnv.RecordMessage("Closing ledger %s", utils.Abbreviate(ledgerId)) |
There was a problem hiding this comment.
I was cleaning up some debug log statements and got a little overzealous. I may leave this out though, as I found it a bit spammy.
| // We wait to allow hubs to finish processing messages and close out their channels. | ||
| // The duration we wait is based on the payment test duration and the amount of concurrent jobs. |
There was a problem hiding this comment.
Let's have an issue to track this? I agree with @NiloCK that the issues should live in go-nitro repo.
There was a problem hiding this comment.
I think we could use statechannels/go-nitro#883
| selected[i] = shuffled[i] | ||
| } | ||
|
|
||
| // TODO: Virtual defunding seems to fail if intermediaries are not in "order". |
There was a problem hiding this comment.
Let's get an issue open to track this.
Adds support for "multihop" (multiple intermediaries) payments. There is a new parameter
numOfIntermediariesthat can be used to specify the number of intermediaries to use when creating a virtual channel.Right now every participant has a ledger channel with every hub, meaning that the multihop payments are a bit superfluous (since participants could pay anyone in one hop). In the future we might want to look at making a more complicated ledger network which would require the multhop virtual channels.
A successful 60 second test run with 5 hops and 10 concurrency can be seen here
Caveats