# Research: Gnosis Bridge Questions
## "Signature" message to Recipient Bridge
### Question: What is the format of the message passed to `SubmitSignature` and `ExecuteAffirmation`? Can we Recover the incoming transaction hash?
#### Preliminary Findings:

* `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).

## `SubmitSignature` vs `ExecuteAffirmation`
### Question: Are there possible race conditions between `submitSignature` and `executeAffirmation`?
#### Preliminary Findings:
_`submitSignature()` seems to be used for briging from Home -> Foreign, and `executeAffirmation()` seems to be used for for briging from foreign -> home_ . So no, it does not seem that there are race conditions since they're used in parallel by independent transactions (bridging to vs bridging from)
### Question: Why was there a lack of `submitSignature` calls during the 20 Aug downtime?
#### Preliminary Findings:
This could be explained by a lack of withdrawal traffic.

## Failed Transactions to Bridge Contract
### Question: Why is there a large number of failed transactions?
#### Preliminary Findings:
* `executeAffirmation()`: Seems that when some validators are slow to sign (or are offline alltogether, as was the case during the downtime), the faster ones try to sign again and get an error for duplicated affirmations. It seems that the Gnosis Dao and Gnosis Safe validators are pretty fast, which could explain why they frequently get that error. Below is an example
* `submitSignatures()`: 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
### Question: Did the Validators call `executeAffirmation()` multiple times?
#### Preliminary Findings:
Yes, it is being called. Viewing the input params you can match them up to verify that thay are indeed affirming the same transaction. For reference, here's a sampling of a few duplicated affirmations that happened during that downtime:
* https://blockscout.com/xdai/mainnet/tx/0xc73df8386023621c6a5bcdcb540ad8dac63433b8c87244940259baa46f611c7e
* https://blockscout.com/xdai/mainnet/tx/0xd0ae540f9acd12837983def4fab22b3b43a4f55485fd4d2a8c2a4f86782bd778
* https://blockscout.com/xdai/mainnet/tx/0xa52fbf5fdb5e4e475819cddf6e4335419f0d5d11b2c5c497093a1bd2fb3801e0
* https://blockscout.com/xdai/mainnet/tx/0xcef4185d34ec1d2ca54ea086acef00657c1b229780db4b2998f4c865afeee5b4
* https://blockscout.com/xdai/mainnet/tx/0xe56c2aa2b57000c86058bad667d78c97ccaa7f86f1c3683165e4eaca9e384602

Potential solution: Bridge Validator clients should check if they have already attempted an `executeAffirmation` or `submitSignature`, and have [exponential backoff](https://dantt.medium.com/circuit-breaker-and-retry-64830e71d0f6) (to avoid wasting gas)

## Giveth Validator
### Question: 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?
#### Preliminary Findings:
I'm not able to identify a "pattern" per se, but it does seem to be offline much more often than the others. Please see the following Dune visualizations:

* https://dune.com/queries/1197177