* Add checkpoint list generation scripts
* Limit the checkpoint block data size
* Limit the checkpoint height gap
* Add Mainnet and Testnet checkpoint lists
* Parse hard-coded checkpoint lists
The lists were generated using the following limits:
- 256 MB spacing, based on block byte size, and
- 2000 blocks.
* Add MIN and MAX for BlockHeight and LockTime
* Remove duplicate test cases
* fix a comment about the minimum lock time
The minimum LockTime::Time is 5 November 1985 00:53:20 UTC, so the first
day that only contains valid times is 6 November 1985 (in all timezones).
Similarly, the maximum LockTime::Time is 7 February 2106 06::28::15 UTC,
so the last day that only contains valid times in all time zones is
5 February 2106.
* fix: Reject checkpoint lists with bad hashes or heights
Reject the all-zeroes hash, because it is the parent hash of the genesis
block, and should never appear in a checkpoint list.
Reject checkpoint heights that are greater than the maximum block
height.
* fix: Resist CheckpointVerifier memory DoS attacks
Allow a maximum of 2 queued blocks at each height, as a tradeoff between
efficient bad block rejection, and memory usage.
Closes#628.
* fix: Make max queued blocks at height equal to fanout
* fix: Just allocate all the capacity upfront
* fix: Use with_capacity(1) and reserve_exact(1)
* Flatten consensus::verify::* to consensus::*
* Move consensus::*::tests into their own files
* Move CheckpointList into its own file
* Move Progress and Target into a types module
QueuedBlock and QueuedBlockList can stay in checkpoint.rs, because
they are tightly coupled to CheckpointVerifier.
Using tower-batch-based async pattern.
Now the Verifier is agnostic of redjubjub SigTypes. Updated tests to
generate sigs of both types and batch verifies the whole batch.
Resolves#407
* Return Poll::Ready(Err(_)) when verification has finished
* Turn checkpoint::init() into CheckpointVerifier::new()
* Accept IntoIterator<...> for CheckpointVerifier::new()
* Add a CheckpointList type
* Replace the state service with oneshot channels.
* Reject redundant checkpoint blocks
* impl Drop for CheckpointVerifier
* Add fields for caching blocks, and managing verify chains.
* Add current checkpoint functions
* Use a checkpoint range
* Get full backtraces with Err::Try
* Add enums for verification progress and target block heights.
* Replace install_tracing() with zebra_test::init()
* Add a test that mixes good and bad blocks
* Add timeouts to the checkpoint test futures
* Use spandoc correctly
* Refactor consensus test error handling
* Delete a checkpoint test that will soon be obsolete
* Only initialise tracing once for the block tests
* Use tracing in the checkpoint tests
* Move BlockVerifier and tests into block.rs
* Update a BlockVerifier comment
* Tweak some TODO comments
node_time_check() is a small function, so we inline it into its callers.
(And then rename node_time_check_helper() to node_time_check().)
Part of #477.
We don't want to call the state's AddBlock until we know the block is
valid. This avoids subtle bugs if the state is modified in call().
(in_memory currently modifies the state in call(), on_disk modifies the
state in the async block.)
Part of #477.
consensus: Add a checkpoint verifier stub
This stub only verifies blocks whose hashes are in the checkpoint
list.
It doesn't have tests, chain child verifies to their ancestors, or
support checkpoint maximum height queries.
Part of #429.
Move block header hashing from zebra-consensus to zebra-state.
Handle zebra-state AddBlock errors in zebra-consensus BlockVerifier.
Add unit tests for BlockVerifier state error handling.
Part of #428.
Placing bounds on the service's future is less ideal, because the future is
already constrained by the `Service` trait, so the bounds can be expressed more
directly and simply by bounding the service itself.
If the verification service already has to have a generic parameter for the
future (the `ZSF`), it could instead be generic over `S`, the storage service.
This has the upside that it's no longer required for the verification service
to box the storage service, so we don't add any extra layers of indirection,
and the where bounds become more straightforward, since they're centered on the
requirements for the storage service itself, not the future it returns.
Finally, we can simplify the bounds by using the request / response types
directly rather than defining wrapper types.
The reason the test failed is that the future returned by `call` on the state
service was immediately dropped, rather than being driven to completion.
Instead, we link the state update future with the verification future by
.awaiting it in an async block.
Note that the state update future is constructed outside of the async block
returned by the verification service. Why? Because calling
`self.state_service.call` requires mutable access to `state_service`, which we
only have in the body of the verification service's `call` method, and not
during execution of the async block it returns (which could happen at some
later point, or never).
In Tower's model, the `call` method itself only does the work necessary to
construct a future that represents completion of the service call, and the rest
of the work is done in the future itself. In particular, the fact that
`Service::call` takes `&mut self` means two things:
1. the service's state can be mutated while setting up the future, but not
during the future's subsequent execution,
2. any nested service calls made *by* the service *to* sub-services (e.g., the
verification service calling the state service) must either be made upfront,
while constructing the response future, or must be made to a clone of the
sub-service owned by the the response future.
We want to allow different state service implementations, and wrapped
state services. So we make verify::init() take a state_service, and
store that service in the BlockVerifier state_service field.
Part of #428.
teor
Alfredo Garcia
Jane Lusby
Deirdre Connolly
Henry de Valence