Add 2 hop RPC example #5
Conversation
|
|
||
| Alice wants to execute a transaction on chainC. She crafts the transaction but does not yet sign it. Instead, she routes it to Irene, who appends a payment for herself in the Alice-Irene wallet on chainA. Irene forwards it to Isaac, who appends a payment for himself on the Irene-Isaac wallet on chainB. This completes the chain. Isaac combines the two payments and the transaction into a `UserOp`. This is then countersigned by everyone, forming `UserOp*`. The operation is not valid unless it is completely countersigned. | ||
|
|
||
| Now each party has an effect they want to happen. Isaac wants his payment from Irene. Irene wants her payment from Alice. Alice wants her Tx to be launched on chainC. Each party can force that through by submitting `UserOp*` to the relevant chain (which will cause the relevant wallet to check all the signatures, and slice into the relevant payment to check the chain id). |
There was a problem hiding this comment.
After all is said and done, we leave Alice with a deployed wallet on chainC. It probably makes sense for that wallet to be configured with an intermediary, most likely Isaac since he has liquidity on that chain already.
|
We should consider adding an ADR about hashlocks vs signatures (as cryptographic primitives that can "enable" a collection of operations). |
|
Is there a timing attack that we need to take care of? There usually is with HTLC / cross chain atomic operations stuff. |
|
Let's make an issue to make switching intermediaires possible / easier. |
|
|
||
| Now each party has an effect they want to happen. Isaac wants his payment from Irene. Irene wants her payment from Alice. Alice wants her Tx to be launched on chainC. Each party can force that through by submitting `UserOp*` to the relevant chain (which will cause the relevant wallet to check all the signatures, and slice into the relevant payment to check the chain id). | ||
|
|
||
| As an optimization, the payments can be completed off chain so that the `UserOp*` is never actually submitted anywhere save for the (final) target chain. It can then be discarded. If any party refuses or fails to perform the offchain accounting, their counterparty can eject from the wallet and forcibly extract the payment due to them. |
There was a problem hiding this comment.
Is this necessary, or an optimization? Naively, it seems that each party has a proof about the funds that they are owed, so they don't need to collaborate to make yet another proof (with 2 signatures instead of N+1 signatures).
There is a timing attack, where someone challenges with an older userop on one chain, and uses a newer userop to challenge on another chain. They can break the atomicity of all the operations that way. Presently there is non deadline on the user operation(s). We may want to add one to make the system more predictable (we don't want userops to stall and then suddenly go through a week later? You could eject anyone who doesn't respond swiftly, in principle). Without a deadline, it seems safe to monitor all chains and make sure if any challenge goes in, to respond with a later state if it exists. If we did have a deadline, we would need to consider differential timeouts to make things safe. This would be to prevent a challenge going in "just before the deadline" leaving no time for folks to respond. |
No description provided.