Add support for running erc20 rollup which uses custom fee token

[gvladika]

Adds support in test-node.bash to quickly spin up Orbit chain on top of L2 chain. If flag --fee-token in combination with --l3node, then test script will then create basic ERC20 token and configure it as Orbit chains native fee token.

It can be used like this: ./test-node.bash --init --dev nitro --no-tokenbridge --l3node --fee-token

[gvladika]

it seems the rollup and tokenbridge would be deployed to different address due to the nonce bump

That should be ok as we don't need to have RollupCreator at a specific address. Rollup is then deployed from there using create2

[gzeoneth]

it seems the rollup and tokenbridge would be deployed to different address due to the nonce bump

That should be ok as we don't need to have RollupCreator at a specific address. Rollup is then deployed from there using create2

I mean the sdk expect the rollup to be deployed at some static address https://github.com/OffchainLabs/arbitrum-sdk/blob/382dd9e8a00a6fc2aeb8021cbe9e33146a6fc473/src/lib/dataEntities/networks.ts#L462-L468 but we will need to update it anyway due to the new CREATE2 salt; would be nice if we can have a nicer way to expose those address

[gvladika]

it seems the rollup and tokenbridge would be deployed to different address due to the nonce bump

That should be ok as we don't need to have RollupCreator at a specific address. Rollup is then deployed from there using create2

I mean the sdk expect the rollup to be deployed at some static address https://github.com/OffchainLabs/arbitrum-sdk/blob/382dd9e8a00a6fc2aeb8021cbe9e33146a6fc473/src/lib/dataEntities/networks.ts#L462-L468 but we will need to update it anyway due to the new CREATE2 salt; would be nice if we can have a nicer way to expose those address

I changed deployer for fee token. So bridge contracts will have consistent addresses on parent (L2) chain for both ETH/ERC20 Orbit chains. Router and gateways addresses on parent chain will differ between ETH and ERC20 chains. Router and gateways addresses on child (L3) chain will be consistent (the canonical ones)

[gvladika]

LGTM worth to note the deployment of l2->l3 token bridge is missing

yep, will add it in separate PR

[gvladika]

wasn't there also some config change necessary to make things work without spamming

Right, I added it now - https://github.com/OffchainLabs/nitro-testnode/pull/6/commits/11170fe36318991973bea632d9f348816a64a974

However I noticed that spamming is still needed in creation phase, I guess for inclusion of init msg. After that no more spamming is needed