Certified Blockchain Professional - Module 06: Open Source Business Blockchain Frameworks

As previously discussed, I'm doing the Certified Blockchain Professional course. It is self-directed learning, so I'm going through it at my own pace. In order to consolidate my learning, and help organise my thoughts, I'm blogging about my reflections on each module.

These are mostly notes to myself - but I hope if you find something interesting (or incorrect) that you'll leave a comment.

• Permissioned Ledger
  • All the participants are known and trusted. This removes the need for PoW or other consensus mechanisms.
  • Doesn't have to be "private" - multiple trusted entities can be added.

• Permissionless

  • Decentralised (ha!) so anyone with sufficient resources can become a node
  • Don't have to be "public", just that the entities are not sufficiently trusted without a consensus mechanism

• Hyperledger

  • A collaborative effort by members (who?) to create open source Distributed Ledger frameworks for cross-industry blockchain things
  • Focus on reliability and performance
  • Consists of:
    1. Blockchain projects
    2. Tools / modules to support the projects
  • Part of Linux Foundation
  • Projects usually contain:
    • Consensus layer - how to validate transactions and agree on network activity
    • Smart Contract - business logic in code which run automatically on the blockchain
    • Communications - message transmission between nodes
    • Security / Cryptography - algorithms / modules for Privacy, Confidentiality, Non-repudiation
    • Data Stores - how and where to store the state of the ledger, including databases
    • Policy - management of endorsement policy and consensus policy
    • API / SDK - how 3rd parties can programmatically interface with the blockchains

• Fabric

  • IBM's permissioned distributed ledger
  • Multiple languages can be used to develop smart contracts
  • Based on Docker
  • Chaincode in a sandbox
  • Designed to be scalable, private, and confidential
  • Modular design for flexibility
  • Requires membership services to make sure only trusted people allowed on - secured by Enrollment Certificates
  • P2P storage
  • Applications typically written with a UI in HTML+JS, which interacts with the chaincode

• Burrow

  • Yet more word-salad!
  • Seems pretty similar to Fabric
  • Separation of logic and action

• Sawtooth

  • PoET is a consensus algorithm - Intel desperately trying to find a use for SGX and trusted computing.

• Cello

  • It seems there are a plethora of services to manage the services of the services which eventually run Blockchains!
  • Lifecycle management of chains

• Composer

  • Yet again, another management service.
  • Uses JS and NPM - a disaster for precision and accountability

The chapter continues to list half a dozen projects - giving a couple of paragraphs to each. But it is mostly content-free.

Most interesting is the concept of "notary services" - temporal validation and ordering. Timestamping, basically.

Assignment

Download the paper “Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains”

(This is a long and tedious paper!)

• What services does a membership service provide?
  • The MSP issues cryptographic keys to members. Only authorised members are allowed to use a permissioned blockchain. So this as a gatekeeper - restricting entry. Theoretically, it could check any aspect of the service before issuing credentials.
  • The MSP can act as a federated service. That is, MSP X can choose to recognise the credentials issued by MSP Y.
• How many roles can a node take up in a Fabric network? Name the roles.
  1. Client. Issues transaction proposals to be executed by the network. They also help ordering, and broadcast transactions to be ordered.
  2. Peer. Execute transactions. Validate transactions. Maintain the ledger. Peers don't have to execute all transactions - on the subset of endorsing peers.
  3. Ordering Service Nodes. This seems vague. They come to a consensus on the total ordering of the system.
• How is Bitcoin style UTXO model captured in Fabric?
  • Unspent Transaction Output. Like in that Superman Movie - it's the fraction of a coin left over after a transaction.
  • A Key Value Store
  • > Every transaction creates one or more output states in the KVS representing the new owners, deletes the input states in the KVS, and ensures that the sum of the values in the input states equals the sum of the output states’ values.
  • Effectively they are tracked