Currently, gas-prices are set upon bridge startup via the
Users's config TOML file; this value remains constant for the
life of the Bridge.
Solution: create a mechanism that asynchronously queries
gas-prices from an "Oracle" service on a timed interval. This
mechanism should be a stream of gas-prices that can be polled
from the Bridge.
This requires retreiving validators contract, calling
`requiredSignatures()` and carefully tracking
`RequiredSignaturesChanged` events.
Solution: use recently introduced additional parameter in
CollectedSignatures to obtain the number of required signatures.
Validators' information is completely configured through validators
contracts and does not depend on `authorities.required_signatures`
parameter of bridge's configuration.
The number of validators also could be changed during run-time and
therefore `authorities.required_signatures` parameter will not reflect
the actual number of signatures required for transaction validation.
Solution: retrieve required_signatures from RequiredSignaturesChanged
event and requiredSignatures() method
Closes#74
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
Peter van Nostrand
Yurii Rashkovskii
Alexander Kolotov
Igor Barinov