Uploaded image for project: 'Fabric'
  1. Fabric
  2. FAB-12221

Validator/Committer refactor



    • Type: Epic
    • Status: In Progress (View Workflow)
    • Priority: High
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: fabric-peer
    • Labels:


      This epic tracks the work to refactor the validator/committer components of a hyperledger fabric peer, to make it simpler, more maintainable, performant, and extensible to support various processing models.

      Design Goals

      • High throughput: the validation component should strive to make use of all the available computation resources.
      • Testability: it should be possible to unit-test the validator component without having to set up peer artifacts such as the ledger or the MSP.
      • Increase test coverage.
      • Create a validation pipeline: structuring the validation/committer pipeline as a set of processing elements connected in series has several advantages:
        • It paves the way for low-latency validation if in the future processing of block n+1 may commence before processing of block n is complete (the benefits of this approach are described here https://arxiv.org/abs/1808.08406)
        • It keeps the code simpler: understanding, coding and testing a component (e.g. the component that does signature checking) doesn’t require understanding or changing another component
        • It makes it easy to extend the validation logic by adding a new stage in the pipeline (e.g. a new component that filters transactions based on a new logic, or that handles a specific new type of transactions)
      • Avoid capability switches in the validation path: instead of performing capability checks inside the validation code, keep different validation logics, one for each release that modifies the validation logic in substantial ways. The right validation logic should be called based on the channel capabilities. This should go beyond what was done for FAB-11552.
      • Minimize unmarshalling: the current validation component repeatedly performs unmarshalling to extract the same fields. Fields relevant for validation should be unmarshalled only once as part of the input validation step.
      • Avoid complex synchronization if possible: state-based endorsement requires synchronization mechanisms to detect dependencies and ensure the correct validation scheduling; we should attempt to only parallelize tasks that are not constrained by dependencies such as signature verification, while performing others sequentially. It’s a matter of balancing performance with correctness.
      • Plan for the hooks for enhanced concurrency control (FAB-10711): enhanced concurrency control requires the ability to further mutate the read-write set of a transaction based on the richer set of operations requested at chaincode-simulation time. We should plan for a step in the validation/committing pipeline where such a hook may be enabled.


      Latest detailed design thoughts and additional background can be found here:




          Issue Links



              ales Alessandro Sorniotti
              4 Vote for this issue
              24 Start watching this issue



                  Git Integration