[v1.3] Error when Bridging Rootchain ERC20 to Native Supernet Tokens

[sahil3Vedi]

Error when Bridging Rootchain ERC20 with Native Supernet Tokens

Steps to Setup Supernet:

https://github.com/integrations-Polygon/Supernets-Edge-Tutorials/blob/master/Supernets_v1.3_setup.md

Command for Bridging:

./polygon-edge bridge deposit-erc20 --amounts 200000000000000000 --json-rpc <mumbai_rpc> --receivers 0xAE3ac03497aB6aFfF786bCFF95DD6e9095Dc5d55 --root-predicate <erc20Predicate from genesis.json> --root-token 0xaADBC81Dec3D3f27a23b9fC8d9F1f031034079e6 --sender-key <private_key>

Output:

[DEPOSIT ERC 20]
Sender                  = 0xAE3ac03497aB6aFfF786bCFF95DD6e9095Dc5d55
Receivers               = 0xAE3ac03497aB6aFfF786bCFF95DD6e9095Dc5d55
Amounts                 = 200000000000000000
Inclusion Block Numbers = 41122460

Testing Supernet Native balance

Next I use this script to check my address balance on the Supernet:

const { ethers } = require("ethers")
const RPC = "http://127.0.0.1:9545"

async function main(){
    const provider = new ethers.providers.JsonRpcProvider(RPC)
    const balance_1 = await provider.getBalance("0xAE3ac03497aB6aFfF786bCFF95DD6e9095Dc5d55")
    console.log(balance_1)
}

main()

I would expect to see the transferred amount in my Native Supernet balance, unfortunately this does not seem to be the case:

BigNumber { _hex: '0x00', _isBigNumber: true }

Your environment

• PopOS 22.04
• Version 1.3, Commit #c27d222

Let me know if have missed anything, thanks!

[goran-ethernal]

Do you have a node started with --relayer flag?

[sahil3Vedi]

@goran-ethernal yes, I have used the --relayer flag when running the nodes.

Exact commands can be found here: https://github.com/integrations-Polygon/Supernets-Edge-Tutorials/blob/master/Supernets_v1.3_setup.md#12-run-child-chain-cluster-in-relayer-mode

[goran-ethernal]

Could you reproduce this on Debug level, and give us logs from the validator nodes?

[Stefan-Ethernal]

Also, can you check if you have provided this address: 0xaADBC81Dec3D3f27a23b9fC8d9F1f031034079e6 (root-token flag value) to erc20-token when you have executed rootchain deploy command? Because the erc20-token value is in fact rootchain token that gets mapped to Supernets' native token. Otherwise, if that value is either omitted or different than the one you have provided for the root-token, it means that deposit would not reflect the Supernets' native token, but rather some other child ERC20 token that is automatically deployed and mapped by the Supernets predicate contract.

If you don't figure out the aforementioned, then provide us the genesis.json file as well.

[sahil3Vedi]

Hi @Stefan-Ethernal I've indeed mentioned the correct Rootchain Parent Token alongside the --erc20-token flag when deploying Rootchain Contracts.

Feel free to go through my genesis.json file: genesis.json

[Stefan-Ethernal]

For starters, just a quick check: have you bridged some tokens to any relayer node (it is enough to have just one of them btw)?

This command seems correct:

./polygon-edge bridge deposit-erc20 --amounts 200000000000000000 --json-rpc <mumbai_rpc> --receivers 0xAE3ac03497aB6aFfF786bCFF95DD6e9095Dc5d55 --root-predicate 0x6335ed5f00FbC1DFD47cCccF1a6f544D9D1aCA97 --root-token 0xaADBC81Dec3D3f27a23b9fC8d9F1f031034079e6 --sender-key <private_key>

Also, we can verify that RootERC20Predicate (https://mumbai.polygonscan.com/address/0x6335ed5f00FbC1DFD47cCccF1a6f544D9D1aCA97) has locked 0.2 PTK, that was being deposited. However, this deposit is not successfully settled on the Supernets side of things for some reason (I suspect that the relayer probably does not have enough tokens to cover fees for settling deposit transactions on the Supernets).

Do you have, by any chance, logs from validators when you have reproduced the issue? If not, can you please reproduce it once again and deliver it to us?

[sahil3Vedi]

Hi @Stefan-Ethernal, The relayer not having enough tokens on the Supernet could be an issue. There would be to ways to fund the Supernet relayer:

1. Bridge Rootchain ERC20 to the Supernet Relayer (validator) address so that it's funded with native tokens.
2. Modify the genesis file during setup to assign an initial balance.

While I am trying the first method and reporting whats returned, would you recommend using the second method?

[sahil3Vedi]

I get these logs from the 1st Supernet Validator node when I transfer funds to it's address:

Supernet_Relayer_logs.txt

However if I check the balance of the validator #1 on the Supernet, it still returns 0. Let me know if the logs are missing anything. I could try funding the validators during genesis too if you think that might work.

[Stefan-Ethernal]

Hi @sahil3Vedi,

Bridge Rootchain ERC20 to the Supernet Relayer (validator) address so that it's funded with native tokens.

this is the only way to do it since when using rootchain-originated Supernets native token, it is allowed to premine only 0x0 and reward wallet addresses in the genesis.

Anyway, I have tried to reproduce the issue on my end and this is the error I'm getting, which means that we are not able to send a "free" transaction anymore (max priority fee per gas and fee per gas set to 0) to fund the relayer, since the relayer does not have any balance prior to this first deposit:

2023-10-19T08:09:47.402+0200 [ERROR] polygon.server.relayer: State sync execution failed: err="failed to send execute state sync transaction for id 1: {\"code\":-32600,\"message\":\"insufficient funds for gas * price + value\"}"

Can you just try re-running the deposit and see whether you are facing the same error message in any of the relayers' logs (in case you have multiple relayers)?

I'll try to investigate this furthermore, because it is a bug.

[sahil3Vedi]

I personally use these shell commands to prefund native Supernets tokens to my wallet address and the validators. They modify the genesis.json to assign initial balance.

jq --arg key "$DEPLOYER_ADDRESS" '.genesis.alloc += { ($key): { "balance": "0x56bc75e2d63100000"  } }' genesis.json > temp.json && mv temp.json genesis.json

jq --arg key "$VALIDATOR_1" '.genesis.alloc += { ($key): { "balance": "0x56bc75e2d63100000"  } }' genesis.json > temp.json && mv temp.json genesis.json

jq --arg key "$VALIDATOR_2" '.genesis.alloc += { ($key): { "balance": "0x56bc75e2d63100000"  } }' genesis.json > temp.json && mv temp.json genesis.json

jq --arg key "$VALIDATOR_3" '.genesis.alloc += { ($key): { "balance": "0x56bc75e2d63100000"  } }' genesis.json > temp.json && mv temp.json genesis.json

jq --arg key "$VALIDATOR_4" '.genesis.alloc += { ($key): { "balance": "0x56bc75e2d63100000"  } }' genesis.json > temp.json && mv temp.json genesis.json

I wanted to know if this would be appropriate. I understand this could disrupt the total supply of mapped tokens by introducing new tokens. Is there any other concern apart from this?

[Stefan-Ethernal]

I understand this could disrupt the total supply of mapped tokens by introducing new tokens. Is there any other concern apart from this?

You would not be able to bridge that supply of tokens back to the rootchain, because they are assigned to the accounts out of thin air and are not previously locked on a rootchain. I'm not sure if there are any more consequences, but that is a hacky approach that's for sure.

We are working on providing a proper solution fix, that is to lock Supernets native token on a rootchain during bootstrap and then based on that information populate genesis allocations (something similar which was done for staking in the genesis time). However, seems like this approach requires a chain reset alongside regenesis.