The Secure Bridge Between Algorand and Ethereum
Joined June 2022
- Tweets90
- Following12
- Followers867
- Likes83
London Bridge retweeted
Welcome to TestNet, @LondonBridgeApp!
📢 Exciting News! London Bridge is Live on Testnets! 🚀
Are you ready to embark on an extraordinary journey with London Bridge? The long-awaited moment has finally arrived! We are now live on testnets: testnet.londonbridge.io/
Unsure sure how to test? We’ve put together a comprehensive testing guide on “How to use the London Bridge Web App”: londonbridge.io/news/how-to-…
Stay tuned for more updates and announcements and follow us on our social media channels to ensure you don’t miss out on any important information.
@AlgoFoundation @Algorand @AlgoFamily @JohnAlanWoods @fredestante @VitalikButerin @ethereum @algodevs #Algorand #LondonBridge #TestnetLaunch #Ethereum
London Bridge retweeted
We're thrilled to host @AndyAppBlock and @SelvaggiaDF from @AppBlockchain on a #Reddit AMA next week to dive deep on the tech of the @LondonBridgeApp.
🗓️ Mark your calendars for Tuesday, July 4th
London Bridge retweeted
Could technically be possible to go Algorand to EVM chains as well but would need a state proof validation lib in Solidity (currently only in go I believe) and fees a lot lower than ETH mainnet currently has
London Bridge retweeted
The answer is a little nuanced will try to clarify:
We validate state proofs inside SGX then a key within SGX signs to attest to the state of the Algorand blockchain, this signature is what is validated on the Ethereum blockchain.
So if the question is "does our solution rely on state proofs?" the answer is yes. If the question is "Does the solidity smart contract validate state proofs" the answer is no for the reasons specified in the tweet linked above.
We will be publishing Intel attestations of our state proof validation code and Ethereum light client code in time which will prove that this is the code being run on the Intel chips with key access.
London Bridge retweeted
The problems with validating state proofs directly in a contract (solidity in this case) are:
1. The complexity of the validation logic leading to an unmanageable gas fee
2. The need for a solution in the other direction ETH -> Algo
But we will keep an eye on these assumptions
London Bridge retweeted
Most bridges use a network of validators to attest the state of the source chain. We are instead using Intel SGX to generate keys and validate the state of the source chain. We will be posting attestation reports of the code we run from Intel in time intel.com/content/www/us/en/…
London Bridge retweeted
So, to your tweet above, what makes London Bridge different from other bridges? Also, are you planning on adding other chains?
London Bridge retweeted
No plans right now, to do this directly we'd need to implement a bitcoin light client in SGX. A wrapped BTC ERC-20 token could be bridged though via the existing solution
London Bridge retweeted
Fees are broken into two:
1. A per token fee charged in eth/algo based on the amount of token you are transferring
2. A flat fee charged in eth/algo to cover txn costs on the destination chain
In terms of amounts that's TBD and depends on the token
London Bridge retweeted
The Avalanche Bridge <-> Ethereum uses similar tech.
In terms of decentralisation the solution is run by Applied Blockchain at the moment. Most bridges use some kind of validator network to secure themselves here we are using Trusted Executions Environments (TEEs), though the two methods could be combined in the medium/long term
London Bridge retweeted
Is there any other bridge that uses similar tech or London Bridge is one of a kind?
How would you rank London Bridge vs other bridging solutions? Both in terms of security and decentralization (or TAs)
London Bridge retweeted
Light clients implemented in Intel sgx enclaves, our algorand light client uses state proofs
London Bridge retweeted
Different tech but similar outcome and TAs. Really the trust is in SGX on both sides. If coming from Ethereum we still have a lightclient, we wait a number of blocks to be sure there isn't going to be a fork. For Algorand we just wait for the state proof as we have finality