The `branch` of the operation contains enough information to induce
the `net_id`, and the code of the validator/prevalidator is now mature
enough to efficiently determine the `net_id` of an incoming operation.
The single validation module is split in multiple (simpler)
modules. In the process, we introduce one "validation worker" per
peer. This worker handle all the `New_head` and `New_branch`
advertised by a given peer. For so, it sends "fetching request" and
"validation request" to respectively the `Distributed_db` and and the
`Block_validator`. These two global workers are responsible of the
'fair' allocation of network and CPU ressources amongst the connected
'peers'.
The invariant of the `clear` function was not properly inforced by the
module interface. This patch remove the inappropriate invariant and
properly rename the function.
New category:
- node.distributed_db.p2p_reader
log all incoming message, from any peer (debug)
- node.distributed_db.scheduler.*
log the request scheduler of the given ressources (notice/debug),
where '*' might be:
- Operation_hash (individual operation)
- Block_hash (block header)
- operation_hashes (aggregated operation_hashes of a block)
- operations (aggregated operations of a block)
- Protocol_hash (protocol)
Let's get serious. The full index of operations is not sustainable in
the production code. We now only keep the index of operations not yet
in the chain (i.e. the mempool/prevalidation). Operations from the
chain are now only accesible through a block. For instance, see the
RPC:
/blocks/<hash>/proto/operations
The minimal header now (classically) contains the root of a Merkle tree,
wrapping a list of lists of operations. Currently, the validator only
accept a single list of operations, but the 3+pass validator will
requires at least two lists.
This refactors `src/node/shell/state.ml` in order to trace the source of
blocks and operations. This prepares the node for the three-pass
validator.
In the procces, it adds an in-memory overlay for blocks and operations.