L1 to L3 Bridgers

[godzillaba]

I AM GOING TO CLOSE THIS PR

This PR introduces 3 new classes to help bridge tokens directly from L1 to L3:

• Erc20L1L3Bridger
• RelayedErc20L1L3Bridger
• EthL1L3Bridger

See #346 for test setup changes for L3's

[gzeoneth]

so instead of hacking with calldata, I am thinking if we should simply modifier the L1 contract to accept additional parameters and calculate the address (instead of calculating the address offchain)

[yahgwai]

Is it possible to something like below instead of manually polling?

const depositTx = await l1l3Bridger.deposit(...);
const depositReceipt = await depositTx.wait()
const l1tol2Message = depositReceipt.getL1ToL2Messages()[0]
const l2TxReceipt = new L1TransactionReceipt(await l1ToL2Message.waitForL2())
const l2tol3Message = depositReceipt.getL1ToL2Messages()[0]
await l2toL3Message.waitForL2()

[godzillaba]

i had a function like this before instead of getDepositStatus but the full stack team said they wouldn't use it and would instead do polling. I thought it might be best to just take it out

[yahgwai]

Oh, fair enough.

Here though I mean that we could just do the above code instead of polling to make your test simpler.

[yahgwai]

Generally we've put the status methods on the messages themselves. In this case we dont have an l1toL3 message, I'm not sure if it makes sense to have one or not, what do you think?

If we do keep this functions here I feel like they could be simplified by using the existing status functions on the underlying l1tol2Messages

[godzillaba]

i'm not sure. i put it here initially because it was easier.

one argument though for keeping it here is that the statuses will be different for each type of L1-L3 transfer:
standard erc20 bridge: 2x L2, 1x L3 initiated by the second L2 message
relayed erc20: 1x L2, 1x L3 initiated by a relayer
ETH: 1x L2, 1x L3 initiated by L2 message

whereas with the existing L1L2 message status functions it's just a single message so it's simpler

[yahgwai]

yeh, i think it's ok to keep it - unless we make a full l1tol2message class.

However internally i think we should use the status() functions to calculate the return of getDepositStatus

[godzillaba]

so instead of hacking with calldata, I am thinking if we should simply modifier the L1 contract to accept additional parameters and calculate the address (instead of calculating the address offchain)

@gzeoneth If we want to use a relayer to save costs and not touch any additional L1 contracts i think we have to calculate offchain. I assume you're talking about 5d7388a?

[godzillaba]

moved to #396