Decimal Bridges

Bridges in the web3 space, which connect data, assets, tokens, and messages, play a vital role in widening cross-chain usability. However, they come with a significant risk of potential disasters or targeted traps in case of hacks or bugs. In the last 18 months, nearly $2 billion has been lost due to bridge hacks, hint: multichain.

Despite these losses, the current bridges are still not optimal in their reliability, cost, speed and overall ease of doing business.

The bridges today typically work through relays and 3rd party opportunistic oracles and validators to validate current data states to process transfers. This approach generally requires whitelisting or costly staking mechanics, putting additional cost burden on the network users.

There is a new era of zkBridges that is in the horizon. They are the most secure bridges till date. But, they also come with their own set of challenges. They are very complex to build and operate, deployment through liteclients have to be custom built and audited for each network pair and is hence affordable only by a few big groups. That leaves a wide audience without any accurate and reliable bridge resource.

How do we make the web3 more inclusive? Is there a different and better way out there? Can we build cost-efficient, faster and safer bridges, that are easier to scale and operate?

Links

• https://github.com/its-adityajohri/ETHIndia2023_ui
• https://github.com/its-adityajohri/ETHIndia2023_Contracts
• https://github.com/its-adityajohri/ETHIndia2023_enclaves

Business Understanding

1. We are introducing an unorthodox method of achieveing correctness by using a decentralised hardware. Another name for them is enclaves or Trusted Execution Environement(TEE). But there is a lack of understanding around them and required us train our audience on how they work and provide undeniable attestations or how can they are offered in a decentralised manner so that they are not single points of failures.

Integrations

1. WSS urls were not readily available for some of the chains, due to which we could not integrate Decimal bridge for our demo, though we managed to deploy contracts in respective bridges for our hack.

Anon Aadhar

1. Expected better docs. From a dev's perspective there should be clear transition between what doesn from frontend into smart contract. We couldn't find what all the 34 public signals were the Anon Aadhar verifier contract. We could easily build more sophisticated KYC modules with knowledge of all those signals.

2. The anon aadhar UI was using different version anon-aadhar package. There seemed to no proper mapping of interconnected packages and we couldn't test the standalone npm package without modification from our side.