Chain Abstraction for Cross chain Token Bridge

My Project is an idea to greatly improve user experience (UX) for Cross-Chain Defi applications. I will attempt to build a token bridge as a use case or case study to convey these enhanced UX techniques.

Problem Description

Currently cross chain Defi applications such as token bridges and cross chain AMM's are very arduous to use and have a high barrier to entry for no web3 folk and even moderately tuned in Defi users. lets the example of a typical "token bridge" to explain these UX problems. 

Currently if i want to bridge TokenX on ChainX to ChainY a typical process looks as follows

1. Connect you wallet to the application. (many bridges ask you to connect a wallet compatible for the source chain transaction and another wallet compatible with the destination chain transaction. Meaning if the two chains are not EVM compatible you will need to connect two different wallets to the app. NOT GOOD)
2. Then you will select the token you want to bridge and select the amount
3. Next you will sign the source chain transaction
4. After this you will wait a couple of minutes for the bridge to compete
5. Finally you will get a notification and be prompted to sign the destination chains release transaction to receive your tokens

This process involves a lot of steps and takes a long time to completely resolve. Not only this but the user needs to make sure that they have gas tokens in each of their wallets in order to be able to complete the transactions.

This current process has terrible UX and can/should be improved. The solution I will no propose aims to solve many of these issues and greatly optimize the flow described above

My Solution

My solution will attempt to use "Smart Contracts" to solve a lot of the issues described above. To give a quick summary of the key features that my solution will enable we can consider the following

1. Chain Abstraction. This idea lets be such that a user can use my bride without ever having to need to know or worry about what chain/network their wallet is on. In other words a user could in theory execute an Ethereum transaction from the polygon network or any other chain for that matter, hence greatly improving UX
2. No need to care about gas Tokens. My bridge will remove the need for users to worry about having enough gas tokens in their wallet in order to execute a bridge transaction. We will get into how this works below.
3. Singe Transaction. As mentioned above typical bridges include a source chain initiation transaction followed by a destination chain release transaction. My model improves this by only requiring the user to execute the source chain transaction, and by using ECDSA verification techniques we can securely verify information to safely autonomously execute the destination chain transaction under the hood, again, greatly improving UX

How Does This Work

My solution will make use of two incredibly powerful Smart contract techniques to implement all of the features mentioned above. Those are the ERC2771's method of a trusted forwarder for transaction execution and the EIP712 for transaction metadata signing and type transaction metadata.

ERC2771 is basically an openzeppelin standard that makes use of a trusted entity that can execute transaction on the behalf of a user. How it works is the user will sign the metadata of some smart contract function that they want to evoke. Once they sign the metadata, they have effectively wrapped their permission to execute the TX into the TX metadata through the generated signature. We can then forward this metadata and signature to this forwarder entity, who will then reviver our ENS address from the signature using ECDSA techniques. If the recovered address matches the users the forwarder will execute the transaction for them and pay the gas tokens. 

This method solves two things. The double transaction issue and the gas tokens issue. We can do an ec.recover requirement on the destination chain TX in order to guarantee security, allowing our forwarder to autonomously execute the destination chain TX.

Secondly EIP712 is a signature signing scheme for typed metadata in solidity. EIP712 has the concept of a domain separator which with out getting into too much detail we can use for signing a transaction on one chain, and verifying the signature on another chain and doing the execution there. This allows us to abstract away the need for our user to need to be on a specific chain deepening on what token they're bridging.

Summary

So this is my idea of what i would like to try and build at the hackathon. I have build a basic forwarder before for another unrelated application so i have knowledge of how they work however the forwarder i want to build here will function more as a smart contract wallet following the ERC4337 standard, using the base ERC2777 implementation as boilerplate. I also have worked with bridging tech before as i sued to work at the Ren protocol, so i feel i should be able to build a basic bridge using the old ren SDK and combine the my two ideas to make a unique user flow for Cross chain bridge applications. I have been thinking of this idea for a while and eventually was going to build it as a side project. so the hackathon is coming at a nice time i hopefully can get a really simple Proof of concept demo working so that i can expand on it in future to hopefully one day make a production application from this idea.