If the error like this appears in the logs:
```
INFO:bridge::bridge::withdraw_confirm: waiting for new withdraws that
should get signed
WARN:bridge: Bridge crashed with Error(Transport("Incomplete"), State {
next_error: None, backtrace: None })
Error(Transport("Incomplete"), State { next_error: None, backtrace: None
})
```
it is hard to understand which side of the bridge failed. The message
must contains type of operation (`deposit_relay`, `withdraw_confirm` or
`withdraw_relay`) and side of bridge (URL of RPC channel).
Solution: record error's top level context and print it out if recorded
Addresses #75
Sometimes there's an event and eth_getLogs returns
nothing.
Solution: trim the nulls from the topic filter's tail
It appears that in some implementations or setups
eth_getLogs topics: [A, null, null, null] won't return
logs when only [A] was there.
This patch is a quick workaround that trims nulls from
that said tail. A proper fix would likely require
an incursion into ethabi to make Topic optional.
The current behavior for logs displayed during the bridge initialization
is not consistent - home url is reported whereas foreign url is not.
Solution: report it
Fixes#69
This is because it is limiting them to one at a time
per operation type. This was done so that there's no
gaps in nonces due to undelivered transactions.
Solution: allow concurrent sending of transactions
By default, 100 transactions are allowed.
Note, however, that now there's a chance that nonce
gaps may be formed under cerain circumstances.
Contracts in the repo are not used for the bridge any more.
So, in order to reduce number of questions in the future, a note to reflect the status of contracts is added.
Examples in the git repo could lead to situation when a public node (especially a Kovan public) could drop transaction due to low gas price (0 by default).
In order to reduce number of questions which could appear with usage of examples, the `gas_price` field is initialized with 1 gwei in the corresponding files.
There are even sometimes incorrectly deducted.
There are more situations that can be distinguished -- for example,
nonce re-use. This particular error will be conflated with insufficient
funds because they share the error code in the JSON-RPC respponse.
Proposed solution: discriminate JSON-RPC responses with 32010 code
according to their message.
Closes#54
It is only necessary when deploying
Solution: remove the requirement for this configuration option
but leave it for the `deploy` feature used in integration tests
until they are rewritten to use external deployment mechanics.
Bridge's contracts are now developed in a separate repository
and have their own deployment procedure:
https://github.com/poanetwork/poa-parity-bridge-contracts
However, our integration tests are not yet updated to
use this deployment procedure.
Solution: disable deployment compile-time by default
and only use it in integration tests as a stopgap measure
until the new deployment procedure (or any other viable
alternative) has been used.
In cases when the node is backed by a cluster of nodes,
one node will not share the same information with the
other, hence it will not be able to report nonce reuse,
ultimately leading to lost transactions as they are
discarded later.
Solution: combine getTransactionCount with an internal counter
so that validator controls its own nonces, but in case if
something external happens, it can reset itself against
those externalities.
Unfortunately, bridge will still reuse nonce very often.
Specifically when trying to send more than one transaction at
a time, clearly a faulty behaviour.
Solution: chain retrieving a nonce with subsequent sending
of the transaction.
However, chaining these is not enough as it'll still fail.
This is happening because bridge module is polling all its components
(deposit_relay, withdraw_confirm, withdraw_relay) sequentially,
and some of them maybe waiting on their transactions to go through.
However, those transactions are also done as composed futures of nonce
retrieval and transaction sending. This means that it is very often
that first, these futures will go through the nonce acquisition process,
get the same values, and then submit transactions with the same nonce.
This patch makes NonceCheck future check if the transaction failed
with this specific issue of nonce reuse and effectively restarts from
the beginning in that case, repeating nonce acquisition process... until
it succeeeds.
If a node configured as Foreign for the bridge and it has no validator
account unlocked the bridge crashes and produces the following message:
```
INFO:bridge::bridge::withdraw_confirm: got 1 new withdraws to sign
INFO:bridge::bridge::withdraw_confirm: withdraw is ready for signature
submission. tx hash 0x6493…4fa8
INFO:bridge::bridge::withdraw_confirm: signing
WARN:bridge: Bridge crashed with Error(Transport("Unexpected response
status code: 405 Method Not Allowed"), State { next_error: None,
backtrace: None })
Error(Transport("Unexpected response status code: 405 Method Not
Allowed"), State { next_error: None, backtrace: None })
```
Solution: sign messages locally
Closes#49
On my computer, this takes approximately 0.3 seconds, which is clearly
a deal-breaker. In retrospect, this is an obvious problem because
of key derivation function use.
Solution: unlock accounts permanently.
This cut down time to sign one transaction is 0.0001 or so.
This means that the node has to sign the transaction itself.
It might be acceptable in a localized setup, but can't be used
with untrusted setups. For example, once HTTP RPC is supported,
we can't really use infrastructure like INFURA to send transactions.
Solution: switch to signing transactions in bridge
This absolutely requires separating the accounts used by validators
and administrative tasks as this will otherwise interfere with
management of nonces.
As a part of the original feature request, there was a need
for the bridge to be able to sign its own transactions. However,
this didn't fully materialize in the original patch, and only
configuration parameters were implemented.
Solution: remove these last conflated bits
and make this a pure transport change patch.
Alexander Kolotov
Yurii Rashkovskii
Igor Barinov