This is because other changes on master are in conflict.
Solution: merge and resolve conflicts
Merge remote-tracking branch 'origin/master' into required-signatures
Solution: fix the maximum number of concurrent HTTP request
at a transport level.
It is set by default to 64 and there's now a new configuration
parameter (`concurrent_http_requests`) in `home` and `foreign`
sections. Previously used `concurrency` parameter from transactions
configuration has been removed.
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
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.
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.
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.
Currently there are two possible situations related to low balance on
the account which is used for bridge operations:
1. The account which is used to sign transactions to be addressed by
ForeignBridge contract has low balance. So, the bridge is not able to do
deposit_relay and withdraw_confirm.
2. The account which is used to sign transactions to be addressed by
HomeBridge contract has low balance. So, the bridge is not able to do
withdraw_relay.
In both cases bridges hangs silently at the moment of sending
transactions and does not proceed with further actions even the
operation is intended to be performed in opposite direction (e.g. the
bridge hangs at the moment to perform withdraw_relay, so deposit_relay
cannot be performed either).
Solution: make bridge track its balance and hande insufficient
Bridge will crash with ERR_INSUFFICIENT_FUNDS (code 4) so that
supervisor can decide what should happen next. It will also log the
condition.
P.S.Make sure to run the tests with `--test-threads=1` to avoid
other test conflicting with this one. A better solution to this
issue must be devised later, however.
Yurii Rashkovskii
Peter van Nostrand
Maximilian Krüger
debris