Docs: Atomic Swaps with Local Verification #16
Conversation
arkoc
force-pushed
the
docs/atomic-swaps
branch
from
987fe94 to
b4aa5fc
Compare
There was a problem hiding this comment.
Explainations are easy to follow, however I believe the neutrality of this document can be improved by making a clearer separation on what could be standarized in an implementation-agnostic way, and what is coupled to the train protocol.
Also, wdyt on making an entry on docs/intent-types.md?
|
|
||
| ```mermaid | ||
| sequenceDiagram | ||
| participant P1 as User |
There was a problem hiding this comment.
This diagram would be clearer if Alice and Bob were separate participants
There was a problem hiding this comment.
I'm not sure I understand. Aren't they already separate? (P1: User, P2: Solver)
Added a new section, Standardization, to further elaborate on what can be standardized. Should I move the entire document to docs/intent-types.md, or should I just add a reference to this one? |
| @@ -0,0 +1,63 @@ | |||
| # Atomic Swaps with Local Verification | |||
|
|
|||
| This proposal introduces a mechanism for achieving asset interoperability between Ethereum L2s (and beyond) using Atomic Swaps. The approach does not require a cross-chain messaging protocol, does not introduce new trust assumptions, and remains open and permissionless for any network to participate. It leverages an enhanced version of HTLCs (PreHTLC) in conjunction with recent advancements in local verification techniques, such as running a light client in the browser (e.g., Helios), to achieve two primary objectives: | |||
There was a problem hiding this comment.
Does "The approach does not require a cross-chain messaging protocol" refer to the Settlement System defined in ERC-7683, or to something else?
There was a problem hiding this comment.
It's just a broader term, which includes the Settlement System defined in ERC-7683 as well.
| - The dApp performs local verification by monitoring Bob’s transaction on Optimism. | ||
| - If a light client is available, it is utilized for validation. Otherwise, the dApp queries multiple RPC endpoints or a user-specified node. |
There was a problem hiding this comment.
It would be nice to read some security considerations regarding the verification step. In ERC-7683, I believe it is better understood since it relies on a message layer. In this case, it would be useful to understand what things could potentially go wrong.
There was a problem hiding this comment.
There is one scenario where a user's funds could be compromised. For this to occur, all of the following statements must be true:
- There is no Light Client for the destination network.
- Only a single RPC provider is available for that network.
- This single RPC provider is also the solver matched with the user.
Even in this case, the user still has the ability to manually verify/check the destination hashlock and decide whether they want to proceed with the transaction or not.
docs/atomic-swaps.md
Outdated
|
|
||
| By integrating an intent/solver-based framework with PreHTLCs and local verification, this protocol achieves: | ||
|
|
||
| - Sub-30-second settlement times for cross-chain transfers. |
There was a problem hiding this comment.
This sounds quite good; just to understand better, these 30 seconds are measured based on what exactly? Is there any specific checkpoint you’re referring to?
There was a problem hiding this comment.
It's basically the time it takes for all transactions in flow to be included in the blocks. Updated doc to reflect that.
Introduces a permissionless and trustless cross-chain asset transfer mechanism using Atomic Swaps, PreHTLCs, and local verification. This approach ensures fast settlement times without relying on cross-chain messaging protocols or third-party trust.