Pick two: fast, cheap, secure? Solving the bridge trilemma.
 | Good news everyone, this is the continuation to our previous post on bridges, here is the previous post. https://www.reddit.com/r/btc/comments/u2v2sn/the_internet_of_value/ A perfect bridge between SmartBCH and Ethereum as an example, would allow anyone to instantly move a token, for a very small fee at no risk. At least with the tools that we currently have available, such a bridge is very unlikely to happen. Because of how blockchains work if you want a bridge that is very fast, there is a risk of a block reorganization creating an imbalance on the bridge, so you could choose to have a very fast bridge, yet it won't be secure. Now lets say you want a bridge that is secure, you will need to wait for finality, that means that a set of blocks is unlikely to be replaced with a different set of transactions, so in this case it won't be fast. Perhaps you can pay some kind of insurance on your transaction, so it will be fast and “secure”, but it won't be cheap.So what will you want in your bridge? Would you mind having to wait a bit in order to get a secure transaction for a low fee? That is what we believe we should build. A very resilient and inexpensive bridge, one that is optimized for security and low transaction cost.But users don't want to wait, and there is a solution to that. The bridge can be built with two layers. The first layer provides the actual token transfer protocol. While a second layer takes care of the final user with support, great UX, and speed in exchange for a small fee. We have discussed before how that first protocol layer works, now let's go over how the second service layer would work. We already have something like this on SmartBCH, https://hop.cash/ will bridge a user BCH to SmartBCH and back This service makes this possible by having liquidity on both sides, to do settlement later using the current service of CoinFlex (that will be replaced by Sha-Gate). A service layer is not doing work directly at protocol level, but allowing users access to the protocol and charging a small fee for a great fast service and support of its users. Users that don't mind waiting a few hours can securely and cheaply bridge their tokens, while those that need something quick can make use of a service built on top of the bridge. Those services can then from time to time put all transactions together and settle them with one transaction to balance their liquidity on the protocol layer. Service layer and Protocol layer bridge But why do Signatories wait hours before they certify a bridge transaction? Vitalik discussing bridgesVitalik: “Now, imaging what happens if you move 100 ETH onto a bridge on Solana to get 100 Solana-WETH, and then Ethereum gets 51% attacked. The attacker deposited a bunch of their own ETH into Solana-WETH and then reverted that transaction on the Ethereum side as soon as the Solana side confirmed it. The Solana-WETH contract is now no longer fully backed, and perhaps your 100 Solana-WETH is now only worth 60 ETH. Even if there's a perfect ZK-SNARK-based bridge that fully validates consensus, it's still vulnerable to theft through 51% attacks like this.” Vitalik would undeniably prefer that all value stays inside of Ethereum. Vitalik mentions this attack where a chain is reverted after the attacker bridges back value, leaving the bridge no longer fully backed. What Vitalik does not mention is that it is exactly this reason why transfer of bridges takes time. You see, the longer time a Signatory waits to certify a bridging transaction, the more expensive and risky the attack described by Vitalik gets. So for example, if a Signatory bridge waits 24 hours before it certifies a deposit on the locking contract, then it means the attacker would have to be able to do an attack that reverts the chain 24 hours. Very expensive and risky for the attacker as his chances to succeed would be extremely small. The time no only makes the attack very expensive but allows for the community to be alerted on it, to stop it. But then 24 hours is a long time for a regular user to wait, that is why we propose a two layers bridge platform. As for the service providers working on top of the protocol bridge, doing settlement once a day wouldn't be a problem and would actually result in fee savings. We can then have the best of both worlds, a bridge that is fast, secure and with the right fees in exchange for great service and support. Notice that while we mention hours, Signatories actually look at block height, that is the number of blocks. Our proposal for a Signatory built, two layers bridge, fixes the bridge trilemma, with a service that is secure, cheap an fast. It enables a true internet of value where value freely and securely flows through different chains, and not a world of independent networks. If you would like to support our work on bridges and learn more about our project, join us on our Telegram Channel: https://t.me/+Hi_qG5A59IhiZGQx [link] [comments] |
