# Research: Gnosis Bridge Questions

## "Signature" message to Recipient Bridge

* What is the format of the message passed to `SubmitSignature` and `ExecuteAffirmations`
* Are we able to recover the **incoming txn hash** from that message?
* `executeAffirmation()`: Yes, `transactionHash` is recoverable. `transactionHash` is the 3rd arg passed into executeAffirmation. Recipient address and amount are also recoverable. See example under input [here](https://blockscout.com/xdai/mainnet/tx/0x70238687f83970a4a43f7842f515b3e30a2df23a4ba7821d976f3bf3b55631bd). Blockscout nicely decodes params automatically.
* `submitSignature()`: not as clear. Params are `bytes signature` and `bytes message`. Message is encoded uniquely. From [`parseMessage()`](https://github.com/omni/tokenbridge-contracts/blob/908a48107919d4ab127f9af07d44d47eac91547e/contracts/libraries/Message.sol#L32):

         assembly {
            recipient := mload(add(message, 20))
            amount := mload(add(message, 52))
            txHash := mload(add(message, 84))
            contractAddress := mload(add(message, 104))
        }

* `recipient`: 32 bytes starting 20 bytes after the start of the message
* `amount`: the next 32 bytes (start of message + 52 bytes)
* `txHash`: the 32 bytes after the amount (start of message + 84 bytes)
* `contractAddress`: the 32 bytes starting at (start of message + 104 bytes). This seems to overlap with the `txHash`, which ends at byte 116 (84 + 32 = 116).

* Able to then map `SubmitSignature` and `ExecuteAffirmation` calls to inbound bridge txn hashes
* yes, more straightforward going from Foreign->Home and looking at the `executeAffirmation()` params since blockscout can decode them, Home->Foreign isn't as straigtforward
* This can help Nithin build the Bridge Monitoring Dashboard (https://hackmd.io/DEFASyRWS0KYutCbiqvF4A)

## `SubmitSignature` vs `ExecuteAffirmations`
_`submitSignature()` seems to be used for briging from Home -> Foreign, and `executeAffirmation()` seems to be used for for briging from foreign -> home_ .
* Race conditions between `SubmitSignatures` and `ExecuteAffirmations`
* Quick glance thru code suggest signatures are submitted
* Last validator `SubmitSignatures` and `ExecuteAffirmations`
* However: possible race conditions?
* I dont think so since they're used in parallel by independent transactions (bridging to vs bridging from)
* During the downtime of 20 Aug there was a dearth of `SubmitSignatures`
* Needs to be verified (I only recall seeing `ExecuteAffirmations`)
* this could be explained by a lack of withdrawal traffic


## Failed Transactions to Bridge Contract

- Large number of failed transactions (often of `ExecuteAffirmations`)
- e.g. https://gnosisscan.io/tx/0xe84d6965de64a37e65fa2f7eb146d5fa3abfbd7ff573ccdc42f094f1b188f266
- Why did they fail?
* Seems that when some validators are slow to sign (or are offline alltogether, as was the case during the downtime), the faster ones (seems that the gnosis dao one is pretty fast) try to sign again and get an error for duplicated affirmations.

- During the downtime there was a large number of failed transactions overall (including `SubmitSignatures`)
- e.g. https://gnosisscan.io/tx/0xaf9da8753891edb29559eb32ff1c4e23fc3d5c83c445ad5b3c2b4f275bbc3085
- Why did they fail?
* seems top be a similar case as above: I postulate that some validators are too slow to sign and the faster ones try and sign again. Sometimes, it seems that 4 successful `submitSignature`'s with duplicate messages (indicating the validators are signing the same txn) are followed by a series of failures. See below:


All of those transactions have the same `message` param:
`0x53c46a9705bbcc76866ede57a795af7f3eaa363700000000000000000000000000000000000000000000006f21770aa26ec80000cad9b92acf799234de13d173675d0c492805e090dd21d0cab75a2d2ad181cd914aa42145aa6ebf72e164c9bbc74fbd3788045016`
For Reference:
* https://blockscout.com/xdai/mainnet/tx/0x2194b69ac95d384b25bf4676b186bf1cd93077f5891b9092e9e40469bb4e4379
* https://blockscout.com/xdai/mainnet/tx/0x293316cf88b18b67fce2232213d4d11d32b72e70285e3857b0a0d8c9b761ff30
* https://blockscout.com/xdai/mainnet/tx/0xc497a5660c9089c88f0fbd1e4a646319e322a128aff466bc86944dcb13858da8
* https://blockscout.com/xdai/mainnet/tx/0x7acedbf22cb1ba702b534e3839f3e4dd7c0648b98ed7f97bbeed328cee9dab87
* https://blockscout.com/xdai/mainnet/tx/0x6237ed549c37c5e0726f23ee9d64e5905af145f79a1a421484f213cd6b48055c
* https://blockscout.com/xdai/mainnet/tx/0xb8e00dc8a8a9a73e378047c76754d6d6cec3c1aafd165b100ee488d1b8b3278e
>My guess is that there's not a way for a validator to know whether it has signed a transaction or not, need to dig more in that code to see

## Multiple `ExecuteAffirmation` calls without backoff

* Need to verify that contract did indeed call `ExecuteAffirmation` multiple times
* the contract doesn't call it, the validator calls it on the contract. But yes, it is being called. Links to txns are included in that google doc. Viewing the input params you can match them up to be voting on the same txn
* Long-term, need to build some logic on exponential backoff


## Giveth Validator

- During the downtime, the Giveth validator did not sign any messages
- However, in the days after, it seems to be online
- Is there a systemic downtime pattern for Giveth?
- https://dune.com/queries/1197177