First of all I have verified the contracts in the both Volta and Kovan chains. Now the source code of contracts is associated with exact bytecode. If you look at the list of calls after that it is easy to see how exactly user interact to the contracts and contracts interact to each other.
Then let’s look at the bridge operations just after the transaction you refer:
0x11b286fcde98b591109ddaac5da2d5612b2e413068283714f98ac780bcb52629 - the validator
0x054a3EbE6599e9e7299fEc5abBFa6c697BCec2EE sends its confirmation to relay the assets to another side of the bridge.
0xbe2567727de7784426906040e0cfe9c030fe70206b8dd31f731eb1c4d58014fb - the validator
0x58D29CeB1A7D5192DD3A840D77D88779c8BF5246 sends the confirmation.
0x0feeb1a80fbe6fa17f2cdeeca33c64f5f8e8f7df84178359c982103c1946c20f - the validator
0x8BEf9E7aeb7Ef2EC7680C299F7DD8BdA27490eb7 sends its confirmation. But the call is reverted since enough number of signatures already collected (the first two confirmations).
- The validator
0x064Ad23A6688d5d4127a1f0BEbBf1D2E249E11a2 did not send its confirmation at all. Either it handled the situation that enough signatures already collected or it was turned off.
So, the last transaction applied to change the state of the contract is 0xbe2567727de7784426906040e0cfe9c030fe70206b8dd31f731eb1c4d58014fb. The logs tab in this transaction shows to events raised by the contract. The second event is
SignaturesCollected() and it contains the address of the validator responsible for transferring the collected signatures to the contract on the foreign side of the bridge.
Another point that is important to notice is the timestamp of the block which this transaction was included into.
This timestamp is needed to try to find the corresponding transaction sent by the validator
on the foreign side.
Let’s open the Blockscout for Kovan chain and look at transactions sent to the bridge contract in that chain.
Block #11558540 was produced on June-13-2019 09:03:04 PM +3 UTC.
Block #11571274 - on June-14-2019 11:12:16 AM +3 UTC.
Block #11571438 - on June-14-2019 11:23:12 AM +3 UTC
Block #11571628 - on June-14-2019 11:35:52 AM +3 UTC.
It is expected that
0x58D29CeB1A7D5192DD3A840D77D88779c8BF5246 should send the transaction with signatures somewhere in this time frame. But as we can see there is no such transaction.
The reason why the validator did not send the transaction cannot be analysed without the logs from the node where the corresponding token bridge oracle is run. Most probably it is due to fact that the originator of some transactions to transfer tokens to VT chain was
0x58D29CeB1A7D5192DD3A840D77D88779c8BF5246 and it is the bridge validator account too. So, the nonce in the Kovan chain for this account was increased by these manual operations to send the tokens whereas the corresponding oracle instance doesn’t know about this and tries to operate with old nonce. Anyway please provide the logs which could help identify the root cause. Our statistic of running xDai bridge shows that the validators never missed the blocks so it is quite impossible that this issue happened on your system.
In order to fix the situation you need to stop the token bridge oracle, reset the block observed by the validator in the oracle database and start the oracle. For this you need to login to the node where the validator with the address
0x58D29CeB1A7D5192DD3A840D77D88779c8BF5246 is run and follow the instruction in the deployment component README file. It is necessary to reset the block for the
collected-signatures watcher. Since we want that the watcher handles the
CollectedSignature() event one more time the target block should be
Here is the list of the commands that needs to be performed on the node. They are applicable only for the case if you used the deployment playbooks to deploy the token bridge oracles on the nodes. If you used another approach please let me know and I will prepare another instruction:
$ sudo service poabridge stop
$ sudo su poadocker
$ cd ~/bridge
$ docker-compose stop bridge_affirmation bridge_request bridge_collected
$ docker-compose exec bridge_senderhome bash ./reset-lastBlock.sh collected-signatures 771653
$ sudo service poabridge start
Monitor the new transactions on Kovan chain after the oracle restart. Few new transactions should appear from the
If it is no transaction which transfer
42 VT to
0x58D29CeB1A7D5192DD3A840D77D88779c8BF5246 (yes, the originator of the transaction to relay the assets is the same private key as the bridge validator) like this:
Prepare the gist with logs from that system and specify the link to the gist in the reply to this message.