1.1.1. 1. Separated Ledger – Fragmented System

1. Verification
   

   For example, each time an asset is sold, both sides requires to have their own provenance (history of ownership) established anew. Not only it is a laborious process, but also there is no efficient way for a single party to prove whether a record is valid.

2. Manual Processes
   

   Many processes, like contract signing and execution, are still done manually, which is slow and inefficient.

1.1.2. 2. Fault Tolerance – Replicas

1.2.1. 1. Distributed Ledger

1.2.2. 2. Immutable and Shared Processes

1. Immutable & Reliable
   

   Once a transaction is recorded on the blockchain, it cannot be altered.

2. Transparency
   

   Unlike traditional systems where each participant uses private programs to update their records, a blockchain system uses shared programs (smart contracts) to update the shared ledger.

1.2.3. 3. Streamlining Processes (i.e., Human)

2.1.1. Channels

2.1.2. Chaincode

1. 1. Package the chaincode
   

   This step can be completed by one organization or by each organization.

2. 2. Install the chaincode on peers:
   

   Every organization that will use the chaincode to endorse a transaction or query the ledger needs to complete this step.

3. 3. Approve a chaincode definition for your organization:
   

   Every organization that will use the chaincode needs to complete this step. The chaincode definition needs to be approved by a sufficient number of organizations to satisfy the channel’s LifecycleEndorsement policy (a majority, by default) before the chaincode can be started on the channel.

   1. Code Inspection:
      

      Organizations may choose to inspect the source code to ensure it's not malicious and adheres to best practices. While this can be cumbersome, it's a critical step for ensuring trust in the network.

   2. Testing:
      

      Organizations might run the chaincode in a controlled environment to test its functionality and ensure it behaves as expected.

   3. Security Audits:
      

      In some cases, organizations might perform security audits on the chaincode, either internally or through third parties.

      In a consortium where members have established trust, the process might be less stringent compared to a more open network.

4. 4. Commit the chaincode definition to the channel:
   

   The commit transaction needs to be submitted by one organization once the required number of organizations on the channel have approved. The submitter first collects endorsements from enough peers of the organizations that have approved, and then submits the transaction to commit the chaincode definition.

   Please notice that in Ethereum, smart contracts are stored on the blockchain itself. Every node on the Ethereum network has a copy of the entire blockchain, including all the smart contracts.

   In contrast, Hyperledger Fabric stores chaincode on peer nodes, not on the blockchain. The chaincode is executed on these peer nodes, and the results (transactions) are then recorded on the ledger. This approach allows for greater flexibility and efficiency, especially in a permissioned blockchain setting where trust among participants is higher. And in addition, even though a organization modify the chaincode and wishing to act maliciously, as long as that org do not control major number of peers, the system remains safe.

2.1.3. Ledger

1. World State
   

   A database that holds current values of a set of ledger states. Ledger states are, by default, expressed as key-value pairs. The world state makes it easy for a program to directly access the current value of a state rather than having to calculate it by traversing the entire transaction log. The world state is implemented as a database. This makes a lot of sense because a database provides a rich set of operators for the efficient storage and retrieval of states.

   Reading data from the World State in Hyperledger Fabric does not require endorsements, and is a local operation for each peer. If an organization alters its local World State, it will face inconsistencies and operational issues, but this will not impact the network's overall integrity, as the other peers' World States and the shared ledger remain unaffected.

   1. Merkle Patricia Trie (State Trie)
      

      In public blockchains (e.g., Ethereum here), since the risks of a node act dishonestly is increased, it uses a data structure called a "state trie" (Merkle Patricia Trie) to securitly store the entire state of the network (chain), the state trie is a complex, cryptographic tree-like structure, which has following features:

      1. Merkle Tree
         

         In Merkle Tree, every leaf node is a hash of data (like a transaction), and every non-leaf node is a hash of its child nodes. The top node, called the Merkle root, represents the hash of all the data in the tree.

   2. 1. Efficiency
      

      The trie structure allows for efficient lookups and updates. Changes to any account only require updating the path from that account's leaf to the root, not the entire trie. In the trie, navigating between nodes are based on the value of the account address.

   3. 2. Security:
      

      The cryptographic nature of the trie ensures that the state is tamper-evident. Any change in a leaf (account state) changes the root hash.

   4. 3. Merkle Proofs:
      

      The trie enables Merkle proofs, allowing nodes to verify that a particular piece of data is included in the trie without needing the entire trie. (i.e., two leafs and their hashed root)

2.1.4. Peers and Orderers

1. Fabric Gateway
   

   Fabric Gateway is a service, introduced in Hyperledger Fabric v2.4 peers, that provides a simplified, minimal API for submitting transactions to a Fabric network.

   Fabric's design relies on deterministic consensus algorithms, any block validated by the honest peer is guaranteed to be final and correct. It features a node called an orderer (it's also known as an "ordering node") that does this transaction ordering, which along with other orderer nodes forms an ordering service.

3.1.1. 1. Bring up the test network

./network.sh up

1. 1). createOrgs
   

   Before brings up the network, we should first create organizations that will participates.

   cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output="organizations"
   
   

   cryptogen is an utility for generating Hyperledger Fabric key material. It is provided as a means of preconfiguring a network for testing purposes. It would normally not be used in the operation of a production network.

   1. The cryptogen tool reads the provided YAML configuration file
      

      For each entity defined in the configuration file (like peers, users, and orderers), cryptogen generates the necessary cryptographic material. This includes:

      1. X.509 Certificates:
         

         Used for TLS (Transport Layer Security) and client authentication. Each entity in the network (peer, orderer, CA, etc.) needs a certificate to participate securely in the network.

      2. Private and Public Keys:
         

         Each certificate is paired with a private key, which is used for signing and encryption purposes. In the case of fabric network, generated files should be located in organizations/peerOrganizations and organizations/ordererOrganizations.

2. 2). start the docker container
   

   COMPOSE_FILES="-f compose/${COMPOSE_FILE_BASE} -f compose/${CONTAINER_CLI}/${CONTAINER_CLI}-${COMPOSE_FILE_BASE}"
   DOCKER_SOCK="${DOCKER_SOCK}" ${CONTAINER_CLI_COMPOSE} ${COMPOSE_FILES} up -d 2>&1
   
   

   Docker Compose efficiently starts and manages multiple Docker containers based on the configurations provided in a docker-compose.yaml file. It streamlines the process of deploying multi-container applications. The DOCKER_SOCK is used for explicit communication with Docker daemon. Which is usually refers to var/run/docker.sock

3.1.2. 2. Create the channel

./network.sh createChannel

1. 1). configtxgen
   

   The configtxgen command allows users to create and inspect channel config related artifacts.

   configtxgen -profile ChannelUsingRaft -outputBlock ./channel-artifacts/${CHANNEL_NAME}.block -channelID $CHANNEL_NAME
   
   

   Basically, what this command will do is generate artifacts (i.e., the genesis block file) based on the config file in configtx/configtx.yaml. The term "creating the genesis block" refers to the process of generating the first block in the blockchain from the configurations specified in configtx.yaml. The file configtx.yaml includes definitions for various elements such as:

   1. Organizations
      

      Information about each participating organization, their MSP (Membership Service Provider) details, etc.

   2. Orderer Settings
      

      Configuration for the ordering service, which might include the type of consensus (like Raft), and settings related to batching, etc.

   3. Channel Configurations:
      

      Specific settings for channels, including the policies for governance the participants, and the endorsement

      The generated .block file includes static, fundamental information like orderer endpoints and network policies, it does not include dynamic details like peer endpoints, which are managed outside the genesis block through other mechanisms in Hyperledger Fabric.

      Please note that this step aim to establish trust among multiple organizations by listing locations of each organizations's root CA in Profile section of configtx.yaml.

2. 2). osnadmin
   

   The osnadmin channel command allows administrators to perform channel-related operations on an orderer.

   osnadmin channel join --channelID ${channel_name} --config-block ./channel-artifacts/${channel_name}.block -o localhost:7053 --ca-file "$ORDERER_CA"
   --client-cert "$ORDERER_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER_ADMIN_TLS_PRIVATE_KEY" >> log.txt 2>&1
   
   

   osnadmin is primarily used for managing channels on the orderer side, like join the orderer to the channel, this usually involved installing the genesis block to the orderers.

3. 3). peer channel
   

   The peer channel command allows administrators to perform channel related operations on a peer, such as joining a channel or listing the channels to which a peer is joined.

   peer channel join -b $BLOCKFILE >&log.txt
   
   

   Be aware that before you call join, you should set up the global environment variables such as key, certificate of that organization. This also involved install the genesis block to the peers.

3.1.3. 3. Deploying a smart contract (chaincode) to the channel

1. 1). Package the smart contract
   

   peer lifecycle chaincode package basic.tar.gz --path ../asset-transfer-basic/chaincode-go/ --lang golang --label basic_1.0
   
   

2. 2). Install the chaincode package
   

   peer lifecycle chaincode install basic.tar.gz
   
   

3. 3). Approve a chaincode definition
   

   peer lifecycle chaincode approveformyorg
   
   

4. 4). Committing the chaincode definition to the channel
   

   peer lifecycle chaincode querycommitted --channelID mychannel --name basic