1. 03 Mar, 2019 2 commits
    • yacovm's avatar
      [FAB-13363] Block verification for onboarding · b6dc844a
      yacovm authored
      This change set connects the block verification infrastructure
      for onboarding to the production code.
      Now, whenever an orderer onboards a channel - it also verifies the blocks
      of the application channels, by:
      1) Creating a bundle from the genesis block, which is derived from
         the system channel (which is verified using backward hash chain validation).
      2) Verifying blocks using the bundle.
      3) Replacing the bundle with a new bundle whenever a config block is pulled.
      It also adds a check in the integration test, that ensures that no errors
      are reported in the log of the onboarded OSN.
      Change-Id: I3c5714f9d4491cdfd78e4e47407925136906d413
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
      Signed-off-by: default avatarArtem Barger <bartem@il.ibm.com>
    • yacovm's avatar
      [FAB-13716] Block verifier book-keeping for onboarding · e0e3ddbb
      yacovm authored
      This change set adds the following supporting structs for adding
      support for verifying blocks pulled by onboarding in future CRs:
      - Ledger interceptor: intercepts a commit of a block, and invokes
        a callback.
      - VerificationRegistry: tracks commit of config blocks, and builds
        channelconfig bundles from them, in order to support verification
        of blocks pulled.
      - BlockVerifierAssembler and BlockValidationPolicyVerifier: together
        they build block verifiers out of config blocks.
      - verifierLoader: Loads a mapping of chainID->cluster.BlockVerifier,
        which is to be used at OSN startup to preload the existing verifiers.
        It is needed in cases we recover from a crash, or if we do
        dynamic onboarding and the previous config blocks have been committed
        to the ledger before the OSN was started.
      In the next CR, I will wire all these into the onboarding infrastructure
      itself, and they will be used to hold the latest bundle per channel
      in order to verify block signatures.
      Change-Id: Ic9fc99243baa5c2cef97103d001180207414d98a
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
  2. 27 Feb, 2019 1 commit
  3. 04 Dec, 2018 1 commit
  4. 01 Nov, 2018 1 commit
    • yacovm's avatar
      [FAB-12673] Make cluster connections asynchronous · 836161ac
      yacovm authored
      This change set makes cluster outgoing connections be asynchronous.
      It is needed because etcdraft sends all messages in a blocking manner
      as well as processes commands from the etcdraft library from the same
      goroutine, and thus a node that is offline slows down
      all messsage sending, and processing of messages.
      Thus we make the connection creation asynchronous, and the book-keeping
      for reconnecting to the offline nodes is done by the gRPC infrastructure.
      Change-Id: I88268b1d67684c34bee71a126b01e2c237d2dcec
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
  5. 28 Oct, 2018 1 commit
    • yacovm's avatar
      [FAB-12550] OSN config block hash chain validation · 785ebd12
      yacovm authored
      This change set adds support for hash chain validation in presense
      of configuration blocks that are found inside the block batches
      being validated.
      This is important because if a config block alters the validation rules
      inside a batch, then validating the signature/certificates of the last
      block in the batch needs to take into account the config block updates
      Change-Id: I03ef2a268ddc9ff63755d3a878f77d4814c5279d
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
  6. 25 Oct, 2018 2 commits
  7. 18 Oct, 2018 1 commit
  8. 20 Aug, 2018 1 commit
    • yacovm's avatar
      [FAB-11585] Raft communication layer, part 1 · bb311c5b
      yacovm authored
      This change set implements a base communication layer for
      the raft orderer, but it can actually be used for any
      consensus protocol that has:
      - A specified number of members at any given point in time
      - uses TLS pinning for identification
      - Represents members as integers
      The communication has 3 basic capabilities:
      1) Obtain a remote context given a destination node ID and a channel
      2) Configure the communication on the context of a given channel
      3) Get notified of Step() and Submit() messages from other remote nodes
      Change-Id: I87f193b7723f95f359cc4071e28b362be703ab74
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>