Layer 2 Interoperability through Shared Validity Sequencing
AI summary of the linked articleShared Validity Sequencing (SVS) is proposed as a way for Layer 2 rollups to share one globally valid transaction history, so users can move assets such as ETH between rollups without a traditional bridge. The article gives an example of moving ETH from Base to Mode for a game, in which the lock on Base is recorded in a shared global sequence that Mode references before releasing equivalent ETH. It argues that this removes reliance on third-party relayers and validators, which it describes as adding cost and vulnerability, and that bridges have been a frequent target for hacks. The article does not provide measured fee, speed or security figures for SVS. |
 |
Recommended by 5 curators |
3 comments I have one question about the design. Let's say SVS is implemented, and I lock my ETH on Chain A. Do I need to specify on which Chain (B, C, D, etc.) I want to unlock my ETH just like I have with bridging, or - since these chains have a shared TX history, so I assume there's no double-spending risk - I can unlock it on any chain that's part of this 'SVS alliance'?  ccarella.ethSubmitter Yea I understand it to be the later but haven't seen much in the name of actual implementation details yet.  Good stuff! I wonder when we'll see the first people to actually implement something like it. I know that isn't exactly the scope of the article, but I think it'd be interesting to see SVS contrasted with the Chain Signatures approach currently tried by NEAR. Maybe another article ;) |
More from app.t2.world on Kiwi News |
