* eth-sign: initial implementation
* sighash: pre-refactor
* sighash: refactor, all old tests pass
* sighash: test ovmsigner code paths for eip155 and eth_sign
* sighash: tx serialization tests
* sighash: refactor to sign bytes
* common/varbytes: use varbytes serialization from btcd
* transactionmeta: implement and test
* rawdb: add new index
* types/transaction: use txmeta
* blockchain: index tx meta on new block
* rpc: fix sendrawethsigntransaction docstring
* meta test: remove dead code
* ethapi: clean up comment
* lint: fix
* txmeta: clean up compares
* ethapi: remove rlp tag
* signer: remove rlp encoding tags from struct
* types: use factory pattern for getting sighash type
* sighash: migrate to using const
* tx pool: use ovmsigner for tx validation
* tx signing: fix eth_sign serialization
* sighash: new version
* sighash: commit to chainid
* sighash: bugfixes
* core/types: prevent panic on tx sort
* core/types: rename to transaction_meta
* core/blockchain: index txmeta
* sighash: no native value
* ethapi: use ovm signer
* sighash: move chainid
* Adding L1RollupTxId field to Transactions
* Adding rollup transactions signing key config and bug fixing within api.go. Signing key and endpoint will be removed when go handles batch fetching
* Adding L1MessageSender to Transaction
* Adding logic to omit L1MessageSender in encoding / decoding when nil and never use it in hash computation
Co-authored-by: ben-chain <ben@pseudonym.party>
This change
- implements concurrent LES request serving even for a single peer.
- replaces the request cost estimation method with a cost table based on
benchmarks which gives much more consistent results. Until now the
allowed number of light peers was just a guess which probably contributed
a lot to the fluctuating quality of available service. Everything related
to request cost is implemented in a single object, the 'cost tracker'. It
uses a fixed cost table with a global 'correction factor'. Benchmark code
is included and can be run at any time to adapt costs to low-level
implementation changes.
- reimplements flowcontrol.ClientManager in a cleaner and more efficient
way, with added capabilities: There is now control over bandwidth, which
allows using the flow control parameters for client prioritization.
Target utilization over 100 percent is now supported to model concurrent
request processing. Total serving bandwidth is reduced during block
processing to prevent database contention.
- implements an RPC API for the LES servers allowing server operators to
assign priority bandwidth to certain clients and change prioritized
status even while the client is connected. The new API is meant for
cases where server operators charge for LES using an off-protocol mechanism.
- adds a unit test for the new client manager.
- adds an end-to-end test using the network simulator that tests bandwidth
control functions through the new API.
