0.9.0 Bridge problem

[polygomic]

I can not deposit or withdrow

Description

I use mumbi and created token with contract address 0x03e7582c080ADD170aAD9160727AC469a814F63B

then I created genesis with :
polygon-edge genesis --validators-path ./ --validators-prefix test-chain- --pos --block-gas-limit 12500000 --native-token-config "test Token":test:18:true --chain-id 4000 --name test-POS --epoch-size 5
--stake 0x3a270F9F468b8B66527400D2651F97997e953633
--stake 0x31bAFbbeF9147cECe567ABEb6E9185be44a4c939
--stake 0xD020Cf97C5a3eE27f5c59B673998a9705A549cA1
--stake 0x8A4A075Ea9e2659481793365643C063a463DBfE6
--bootnode /ip4/127.0.0.1/tcp/30301/p2p/16Uiu2HAm83aZzJuDHmBcxDNitG7wD8Ph5YUqD9JFGo5GB5hUi2W5
--reward-wallet 0xA1a5C63049D7E76E6996fb906C9BE14aE96414C8:40000000000000000000000000000

I deploy to root chain with command : polygon-edge rootchain deploy --deployer-key 4f4602723e5517db90a1c0f81e997b5a5a4f955f9983f125a0a2f3b2c3ed870d --erc20-token 0x03e7582c080ADD170aAD9160727AC469a814F63B --json-rpc https://matic-mumbai.chainstacklabs.com/

after that I start 4 servers with commands :

polygon-edge server --data-dir /root/test-chain-1 --chain genesis.json --grpc-address :5001 --libp2p :30301 --jsonrpc :8545 --seal --relayer --log-level INFO --num-block-confirmations 2

polygon-edge server --data-dir /root/test-chain-2 --chain genesis.json --grpc-address :5002 --libp2p :30302 --jsonrpc :8546 --seal --relayer --log-level INFO --num-block-confirmations 2

polygon-edge server --data-dir /root/test-chain-3 --chain genesis.json --grpc-address :5003 --libp2p :30303 --jsonrpc :8547 --seal --log-level INFO --num-block-confirmations 2

polygon-edge server --data-dir /root/test-chain-4 --chain genesis.json --grpc-address :5004 --libp2p :30304 --jsonrpc :8548 --seal --log-level INFO --num-block-confirmations 2

the deployed smart contracts on root chains are :

[ROOTCHAIN - CONTRACTS DEPLOYMENT] started... Rootchain JSON RPC address https://matic-mumbai.chainstacklabs.com/.

[ROOTCHAIN - DEPLOY CONTRACT]
Name = RootERC721
Contract (address) = 0x7e4FC6D05D59BC9977F28cE48c9718AEB07DD7Ad
Transaction (hash) = 0x78b2389f54cbacc28f0a07e6bc47715bf7a96a4f154b08094ffa18405aee9ff7

[ROOTCHAIN - DEPLOY CONTRACT]
Name = RootERC1155
Contract (address) = 0x8Ae063B6788C81c68A305ae32E82c2c8E59c31CC
Transaction (hash) = 0x2df0bb933a5426c2afef0b51fc828968bbfb5bbae9418eeba08a0dbe0d8ec6c5

[ROOTCHAIN - DEPLOY CONTRACT]
Name = StateSender
Contract (address) = 0x0f2647a0E434e1dE1217485696eaa7CEaC784619
Transaction (hash) = 0xfa879fa60ea266d5997388488da298f9974128b1b04f49eef4c3b208563511e6

[ROOTCHAIN - DEPLOY CONTRACT]
Name = CheckpointManager
Contract (address) = 0x54372110CeA6E78A677f44cb7a82d7204a012fB4
Transaction (hash) = 0x8aed39ba77520b9fc1bd013d769851973948c907f3bd8923ec03f665c9fcdad7

[ROOTCHAIN - DEPLOY CONTRACT]
Name = BLS
Contract (address) = 0x1cD10964D1a267169d1Be2409EDE4cd08006AC59
Transaction (hash) = 0xaadff120d21ad8dcda1e39d30a11d5f47354795f3e875da87bf5d7dab492df43

[ROOTCHAIN - DEPLOY CONTRACT]
Name = BN256G2
Contract (address) = 0x6549049188616b311556b7f88CeB13b093A054bf
Transaction (hash) = 0x7acde7837378d6869ab2b680f83846f3dc539ff4e96fffb68ad86038f87642e3

[ROOTCHAIN - DEPLOY CONTRACT]
Name = ExitHelper
Contract (address) = 0x7000b6F706823dF053EaD3E4e097c85C53663b28
Transaction (hash) = 0x71ab85a6523a5e10d76e805e1867480c9fa1049243f30d5d2db5f23137eb3b4a

[ROOTCHAIN - DEPLOY CONTRACT]
Name = RootERC20Predicate
Contract (address) = 0x94b55F35318c21fc037A6AEc3E0B93E1d1297737
Transaction (hash) = 0x873890d2035c4ab33f3520614040e15c7a510d4db7159165d64f861b0af2c0c3

[ROOTCHAIN - DEPLOY CONTRACT]
Name = ERC20Template
Contract (address) = 0x73AEe43a0621bE196b7A6f774237cFE123aB447f
Transaction (hash) = 0x3a2d575cea9a113ec3ac321f2f72813408b94660935f67b5d0a8bca3bd1b2bbe

[ROOTCHAIN - DEPLOY CONTRACT]
Name = RootERC721Predicate
Contract (address) = 0x825dE1FA72b4BB4077c73a6eB7E9C14B4deB6594
Transaction (hash) = 0xf298e5737754692de9ccb45eedd2391c2a87b6b3a564d300e10acab30c99016b

[ROOTCHAIN - DEPLOY CONTRACT]
Name = ERC721Template
Contract (address) = 0x4894B2aACDc97251997BBD7Dba80bfB122978e52
Transaction (hash) = 0x5742352ca014c8b8c51a5e44ff9a138965424b609233a4e082681885e23df7bc

[ROOTCHAIN - DEPLOY CONTRACT]
Name = RootERC1155Predicate
Contract (address) = 0x9Cc8950fA5FF36E0Fe64983823957631693FF8a4
Transaction (hash) = 0xc13e84438d5b0966327c420d430fd5a6b86595307cbf5165bd191541637b1e45

[ROOTCHAIN - DEPLOY CONTRACT]
Name = ERC1155Template
Contract (address) = 0x26b460d9CDE8E9C2cd3f8E86c5b7AE537Bf6808e
Transaction (hash) = 0xede152449462641ccf2e2633a3764413dc011783e6d99af94e6a0ecaffe491c4

[ROOTCHAIN - DEPLOY CONTRACT]
Name = StakeManager
Contract (address) = 0xbe1bB1331363e394E508C61384F15c49E5Fb4DE1
Transaction (hash) = 0x15bbcda1e5dc369cd14249feeda148c93a2ae31582480a99a92fe77dd2080948

[ROOTCHAIN - DEPLOY CONTRACT]
Name = CustomSupernetManager
Contract (address) = 0xa5DE420F7F8A7845f3C178393a305722d0E759E7
Transaction (hash) = 0x2b28e6f1598e9cea7b506874d2967436f9c21c9c2c52145dfd153e376887453d

[ROOTCHAIN - CONTRACTS DEPLOYMENT] StakeManager contract is initialized

[ROOTCHAIN - CONTRACTS DEPLOYMENT] CustomSupernetManager contract is initialized

[ROOTCHAIN - CONTRACTS DEPLOYMENT] RootERC721Predicate contract is initialized

[ROOTCHAIN - CONTRACTS DEPLOYMENT] ExitHelper contract is initialized

[ROOTCHAIN - CONTRACTS DEPLOYMENT] RootERC1155Predicate contract is initialized

[ROOTCHAIN - CONTRACTS DEPLOYMENT] RootERC20Predicate contract is initialized

[ROOTCHAIN - CONTRACTS DEPLOYMENT] [VALIDATORS]
Address=0x3a270F9F468b8B66527400D2651F97997e953633; Balance=1000000000000000000000000; P2P Multi addr=/ip4/127.0.0.1/tcp/30301/p2p/16Uiu2HAm83aZzJuDHmBcxDNitG7wD8Ph5YUqD9JFGo5GB5hUi2W5; BLS Key=241565f77289237af1a1553eed4e5158a4c8fd3dea37656085b50c98f1bfc8792d143d4b881573f225a8c0ee8ada414f9335447b233dde3c6949bdd69720cef72a268bf00537863ce5b63e3d441cbe109d1f19ac18a371f2fdaebef7e7abcd1b06f3bf43a5856864ef16e0699b171e244750eec08fd243956a0896910967db8f;
Address=0x31bAFbbeF9147cECe567ABEb6E9185be44a4c939; Balance=1000000000000000000000000; P2P Multi addr=/ip4/127.0.0.1/tcp/30302/p2p/16Uiu2HAmPV7risYUqAVrXHXrVrmYRXfKoH8uumdxc5wpP8Xs49xE; BLS Key=0cb7f3e90967cb662ebf2fb7c60e1bc3ea817ff8e58c6093261c4803dadd66d5154ad3858bde3e919d71bf54cba9d85763e9da194fcede5562b10e18fcdcbbd818a156926f394f5bfe5a87860c5165c341d6ae31f15d38540f9c4b39f320a38910299f62807a8085c21419219f9c6a1d069650897f235340d871f8f4cb4d06bf;
Address=0xD020Cf97C5a3eE27f5c59B673998a9705A549cA1; Balance=1000000000000000000000000; P2P Multi addr=/ip4/127.0.0.1/tcp/30303/p2p/16Uiu2HAm8XWR5prbEJ3LQmAjiRp7Wt2P7jQbeijZLQEfDRQxWEQb; BLS Key=2d312a3d0ee4497ceb294c5b84db21428051cd33123394b82c76a2ea156fc654059422b03915d4e764f25ac438cc38483194c8cfc0afb08b376bc2b3db1d5b7e13e7a0685aabaa9381ec5a257a4bd5a20f1b690cb4f7907247c16a2d006803f92f81ad5eda0ee6d1e926ee31b1307adfc1cb1800099b427d8fe30099bb8d0d66;
Address=0x8A4A075Ea9e2659481793365643C063a463DBfE6; Balance=1000000000000000000000000; P2P Multi addr=/ip4/127.0.0.1/tcp/30304/p2p/16Uiu2HAmHP7UTPNW39jz3nA7muRB7amEw3ScosJ6gMnc4AoMJBhA; BLS Key=04df8b9a5b2585684ad9808bc5793499df7e0e9e4e0af17f34a9f4085bd40d5020be1d3b2ec61e94a08c967229b1f1165014fbc15dd8110bb53e210c988709fa17134e3f807f11f8000f05e4cb816adc1c9a62cf57d4e4b3b93ef60a0ca25e8e185f2648010cee0d8f617110adf51c09ba94491df478ffd8f11ccdd1061eea75;
[ROOTCHAIN - CONTRACTS DEPLOYMENT] Validators hash: 0x9759276f440dffa82f78db568b70eb570cd4609b3203430260466d9a3b68c189
[ROOTCHAIN - CONTRACTS DEPLOYMENT] CheckpointManager contract is initialized

[ROOTCHAIN - CONTRACTS DEPLOYMENT] finished. All contracts are successfully deployed and initialized.

after that I run :

polygon-edge bridge deposit-erc20 --json-rpc https://matic-mumbai.chainstacklabs.com/ --receivers 0xA1a5C63049D7E76E6996fb906C9BE14aE96414C8 --root-predicate 0x94b55F35318c21fc037A6AEc3E0B93E1d1297737 --root-token 0x03e7582c080ADD170aAD9160727AC469a814F63B --sender-key 4f4602723e5517db90a1c0f81e997b5a5a4f955f9983f125a0a2f3b2c3ed870d --amounts 2000000000000000000000

all amounts goes to contracts Name RootERC20Predicate
Contract (address) = 0x94b55F35318c21fc037A6AEc3E0B93E1d1297737

and not transfer to side chain
what is the problem
I has this problem from 0.8.0 until now
please help me friends.

Your environment

• OS and version.
• The version of the Polygon Edge.
  (Confirm the version of your Polygon edge client by running the following command: polygon-edge version --grpc-address GRPC_ADDRESS)
• The branch that causes this issue.
• Locally or Cloud hosted (which provider).
• Please confirm if the validators are running under containerized environment (K8s, Docker, etc.).

Steps to reproduce

• Tell us how to reproduce this issue.
• Where the issue is, if you know.
• Which commands triggered the issue, if any.
• Provide us with the content of your genesis file.
• Provide us with commands that you used to start your validators.
• Provide us with the peer list of each of your validators by running the following command: polygon-edge peers list --grpc-address GRPC_ADDRESS.
• Is the chain producing blocks and serving customers atm?

Expected behavior

• Tell us what should happen.
• Tell us what happened instead.

Logs

Provide us with debug logs from all of your validators by setting logging to debug output with: server --log-level debug

Proposed solution

If you have an idea on how to fix this issue, please write it down here, so we can begin discussing it

[squiddyswap]

Version 0.9 (which is about to be released in the following weeks) is going to introduce the concept of root chain staking. Basically, each validator that wants to participate in the consensus protocol on the child chain, needs to stake on a root chain first as a pre-requisite. After that stake information is bridged to a child chain and a validator is able to participate in the consensus and accumulate rewards.

As per the 0.7 and 0.8 versions, staking is happening on a child chain. However, validators need to have a non-zero root chain balance in order to be able to send checkpoints to a root chain (e.g. for the Mumbai network acting as a root chain, it is MATIC as a native token), which is critical in order to be able to do withdrawals (namely transferring assets from a child chain to a root chain).

In either case, accounts that are going to participate as Supernets/child chain validators, need to have a non-zero balance of a root chain native token associated. It is a pre-requisite.

"Before starting the validator nodes on the childchain, we need to fund them on the rootchain network. This is necessary for validators to be able to send transactions to Ethereum, as they need to have enough funds to cover the gas fees."

That is correct: each (validator) account should receive some amount of MATICs. This is a manual step which can be performed via Metamask. But first, it would need to have an account that has pre-mined MATIC tokens on the Mumbai network that can re-distribute MATICs to validator account addresses.

Question is validators' addresses being deployed on Polygon Mumbai when this command is run?

As Edge is Ethereum compatible client, it means that it is using Ethereum-compatible addresses. No need to "deploy" the account to the Polygon Mumbai, but when the validator account receives MATICs for the first time, it is going to be stored in the world state of Mumbai.

[squiddyswap]

You will need to fund each validator with MATIC via Metamask or the with the new function ./polygon-edge rootchain fund --amount 10000000000 --json-rpc https://mumbai.rpc --mint --private key your-private-key wallet --native-root-token native-root-token. Once all of the validators are funded and one of your validators have the flag --relayer then you will get the transferred funds.

[polygomic]

All validators credited with 1 matic but can not bridge tokens.
and also e2e-polybft all test works excepts bridge test witch failed.

[mrandall101]

Now when I have taken a look to your commands more carefully, I see another potential cause of the issue: currently, due to some technical limitations, the minimum commitment size is set to 2. This means that when making deposits of root native tokens, there must be at least two deposits at one time in order for them to be included in the commitment (which represents a batch of bridge events). So if you can, just make at least one or two more deposits and see if it gets executed on the Supernets.