chore(docs): update bridge documentation

[adaki2004]

Bridge documentation update

Hey guys,

The Bridge got a little bit of a face-lift and when (hopefully this week) the branch will finally get merged into main, this document/page needs some update and we go to audit soon maybe it will be helpful to have up-to-date.

Here are my notes what shall be changed, so that hopefully it will be easier to incorporate.

1.
Instead of: The bridge is a set of smart contracts and a frontend web app that allow you to send testnet ETH and ERC-20 tokens between Sepolia and Taiko.

use: The bridge is a set of smart contracts and a frontend web app that allow you to send testnet ETH and ERC-20, ERC-1155 and ERC-721 tokens between Sepolia and Taiko.



2.



sendMessage diagram: shall be slightly modified, I’d use 2-distinguished diagram. Ether only vs. Others*





(others can be: ERC20, or ERC20+Ether, ERC721 or ERC721+Ether, ERC1155, ERC1155+Ether but more on them later.)





The first case (Ether only):




- The user/UI interacts directly with the Bridge, (via sendMessage) and not with the ‘’TokenVault”.





 - The L2: EtherVault observation is correct (only on L2) but this is not a ‘decision object’ so I feel the SignalService ‘path/route of a decision’ is a bit confusing. This storage of the message happens independently. (I know we wanted to express this, but the diagram is a bit confusing.)







 The other cases (ERC20, etc..):




 
- The user/UI interacts directly with the ERCXXXVault contracts, and this vault contract then calls the Bridge contract which will proceed to the SignalService.





 
- We have both ERCXXXVault contracts deployed on both of the chains, and this will hold custody.




 


3.
processMessage diagram: So the first point of contact here is indeed the Bridge, if Ether only, it will distribute the ether (the way it is described) but in case message.data encodes some function data then it is an ERCXXX transfer and if that is the case then the Bridge will call (via InvokMessageCall) the appropriate ERCXXVault.




Worth to mention also:

A “new” (or not really new but not implemented) feature is this: 
You are able to bridge ether only - (this is not new) - but now you are also able to bridge ether (optionally) in the exact same transaction where you are bridging other tokens. ( ERC20+ether, ERC721+ether, etc.).





How to technically bridge ether:


1) setting the to to the recipient address and data to "", and value to the amount of ether, 


2) setting the to to an app on the destination change, and value to the amount of ether, and inside the app, a function will further forward the ether to the recipient address encoded in data.




4.

Instead of: A contract for the ERC-20 must first be deployed on the destination chain (will be done automatically by the TokenVault if not already deployed)
… be done automatically by the ERCXXVault if …



5. 

Instead of: Call sendERC20 on the source chain TokenVault, this will transfer the amount by using the … to the TokenVault….
… Call sendToken on the source chain …. to the ERCXXXVault.


6.
Between point 2 and 3 in (Bridge from canonical chain to destination chain section) , there is a step, where the ERCXXXVault will call the Bridge contract which then will construct the message and then invoke the SignalService.

7.
Instead of: It will attempt to invoke the receiveERC20 method encoded in the message
invoke the receiveToken method



So every sendERC20 and receiveERC20 can be replaced with sendToken and receiveToken


Rest is fine, maybe we shall mention that other token + ether thing + that the ERC721 and ERC1155 works the same way as the ERC-20.

Let me know if you have any questions (here or DM).

[dantaik]

Lets get this done by Sept 15th? @d1onys1us

[adaki2004]

Daniel created a .pdf which might be helpful to you ! Please get back to me if you need anything else or you have any questions.
bridging-on-taiko.pdf

[2manslkh]

For point 3. Is it possible to extend the concept by packing multiple transfers into a multicall?

[adaki2004]

For point 3. Is it possible to extend the concept by packing multiple transfers into a multicall?

Technically possible for sure, but I would not do so because initially it was (mainly) for view functions to to minimize the number of calls towards nodes. (For this it is still great IMO).

But when you bridge a token you want it to be "atomic" in a way, that it bridges right away (or asap) - no batching/waiting and usually do not care about the underlying 'how many calls to rpc'.

If we - on the relayer - aggregate those transactions i see the following pros:

• You save on your RPC call quota

On the cons:

• you lose time (same tho with network congestion..)
• you still pays the same fee (even more with that extra multicall logic)
• if you aggregate more you risk of gassing out
• you make debugging much harder

[adaki2004]

This PR contains these: https://github.com/taikoxyz/taiko-mono/pull/14665/files