Solution: by default, disallow use of non-TLS RPC endpoints
For testing, there's an escape hatch of a command line
argument `--allow-insecure-rpc-endpoints` (purposefully
long) that will reduce the severity of using a non-TLS
RPC endpoint to a warning in a log file.
It was not made to be a configuration file option to reduce
the risk of this option slipping into a production configuration
file by mistake.
Closes#79
This is because other changes on master are in conflict.
Solution: merge and resolve conflicts
Merge remote-tracking branch 'origin/master' into required-signatures
This means that a misspelled config field can cause a lot
of confusion -- things won't work as expected.
Solution: restore more restrictive config deserialization
where unknown keys would trigger an error
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.
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
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.
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.
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.
Using IPC means bridge has to run alognside the node
on the same machine. This, at times, presents problems
in terms of efficiency or coupling of deployment.
Solution: switch to RPC
Alexander Kolotov
Yurii Rashkovskii
Peter van Nostrand
Edward Mack
debris
Maximilian Krüger
viktor