Page tree
Skip to end of metadata
Go to start of metadata

https://hyperledger-fabric.readthedocs.io/en/latest/key_concepts.html

TermDefinition
Block

A block contains one or more transactions. The contents of the block are not encrypted in the blockchain. A block, in general, contains valid and invalid transactions. However invalid transactions have no effect on the State.

A block usually contains three sections: a blockheader, the payload (with at least the transactions) and the metadata section (containing the valid/invalid indicator per transaction).

Fabric: A block in Fabric contains both valid and invalid transactions.

Sawtooth: A block in Sawtooth contains only valid transactions.

Burrow: A block in Burrow contains only valid transactions.

Iroha: A block in Iroha contains only valid transactions.

Block - A set of transactions that are bundled together and added to the chain at the same time.


Blockchain


According to hyperledger.org,

"A blockchain is a peer-to-peer distributed ledger forged by consensus, combined with a system for "smart contracts" and other assistive technologies".

Smart contracts are simply computer programs that execute predefined actions when certain conditions within the system are met.

Consensus refers to a system of ensuring that parties agree to a certain state of the system as the true state.


A blockchain is a chain of blocks each containing transaction (transition) data. Each block, except the first block, is linked with the previous block and each block, except the last block, is linked with the next block, together forming a chain.

Once a block has entered the blockchain, it is ‘chiselled in granite’. This characteristic delivers the immutability of the data in the blockchain, also referred to as practically tamper-resistant data or virtually incorruptible data. This aspect is one of the main reasons for the broad interest in blockchain technology.

[For those with software development experience: In computer science language a blockchain is an append-only data structure; a blockchain (instance) consists at any moment in time of a number of blocks. If the chain has N blocks, then it has N-1 links, valid for N>=1. The blockchain contains all the transitions, while the World State is derived from all transitions (there is a better optimization as World State (N) = valid transactions in block N applied to World State (N-1).]

Chain

Each block header contains, besides its identifier within the scope of the blockchain, a hash of the data in the block. It also contains a copy of the hash of the previous block. Because of this relationship, the a copy of the hash of the previous block, the term chain is used. This is the basis for the tamper-resistant characteristic of a blockchain.

Chain

Blockchain

Blockchain B contains blocks 0, 1, 2.


The ledger’s chain is a transaction log structured as hash-linked blocks of transactions. Peers receive blocks of transactions from the ordering service, mark the block’s transactions as valid or invalid based on endorsement policies and concurrency violations, and append the block to the hash chain on the peer’s file system.

Chaincode

Chaincode is a computer program that either provides functionalities for Enterprise transactions or state. It is useful to distinguish chaincode specific for an enterprise and chaincode that provides domain agnostic functions.

Fabric: The current trend in Fabric is to use the term chaincode to cover both enterprise specific and domain agnostic chaincode. Enterprise specific chaincode is what most people call smart contracts.

Chaincode - Smart contracts in Hyperledger Fabric. They encapsulate both the asset definitions and the business logic (or transactions) for modifying those assets.

Cryptography

Cryptography is the practice and study of techniques for secure communication in the presence of third parties called adversaries. More generally, cryptography is about constructing and analyzing protocols that prevent third parties or the public from reading private messages; various aspects in information security such as data confidentiality, data integrity, authentication, and non-repudiation are central to modern cryptography. Modern cryptography exists at the intersection of the disciplines of mathematics, computer science, electrical engineering, communication science, and physics. Applications of cryptography include electronic commerce, chip-based payment cards, digital currencies, computer passwords, and military communications.

Adapted from: Wikipedia

Cryptography - The study of the techniques used to allow secure communication between different parties, and to ensure the authenticity and immutability of the data being communicated.

Hash

A hash of a (variable length) piece of data results in a unique fixed length data field. The hash is a one-way function that assigns to the variable length field a unique fixed length data field. It is not possible to reconstruct from the hash of the original variable length data field, therefore, a making a hash a one-way function.

Key Pairs

Public key

Public Key is the Public Key Infrastructure (PKI) component that a person or organization shares with third-parties. Such a third party uses the Public Key to encrypt messages that are sent back to the owner of the public key. The owner of the Public Key then uses the associated Private Key to decrypt the message.

Private key

Private Key is the  Public Key Infrastructure (PKI) component that a person or organization should keep confidential. The Private Key is used to decrypt messages sent by third parties that were encrypted using the Public Key.

Digital Certificate

A document that contains attributes related to the bearer of the certificate, that is secured by cryptography. Digital Certificates are issued by a Certificate Authority (CA), and is used by the bearer to prove their identity provided that the other party trusts the CA.

Permissioned

The term permissioned blockchain technology is sometimes used as a synonym for blockchain for enterprise or blockchain for business. Permissioned blockchains require permission to read the information on the blockchain, limit the parties who can transact on the blockchain and set who can write new blocks into the chain.

Consensus

A consensus algorithm is a process in computer science used to achieve agreement on a single data value among distributed processes or systems. Consensus algorithms are designed to achieve reliability in a network involving multiple unreliable nodes. Solving that issue – known as the consensus problem – is important in distributed computing and multi-agent systems.

Consensus, as an algorithm

An algorithm to achieve agreement on a block among peers in the network. By having it in the system, reliability is increased.

Consensus, as a component

Preserves consistent state among the peers within a peer network. Iroha uses own consensus algorithm called Yet Another Consensus (aka YAC). Distinctive features of this algorithm are its scalability, performance, and Byzantine fault tolerance. If there are missing blocks, they will be downloaded from another peer via Synchronizer. Committed blocks are stored in Ametsuchi block storage.

Transaction

A transaction consists of facts (populated fields) about a state transition in the Universe of Discourse (the scope of the business communication). This could be in regard to anything, not just monetary assets.

World State

The World State consists of facts (populated fields) about the current state of the Universe of Discourse as agreed by the blockchain network community. This could regard anything, not just monetary assets. The World State State changes after each block that is added to the Blockchain; see exception for Fabric.

Fabric: In case there is a block with only invalid transactions, there is no new state in Fabric after adding such a block to the blockchain.

Channel

A channel is a virtual blockchain with its own private ledger only visible to the organizations that make up the channel.

Fabric: A Fabric blockchain network will have at least two channels (exactly 1 system channel and at least 1 application channel). The visibility of an application channel's ledger is limited to the organizations that make up the channel.

An organization can be involved in any number of application channels and any application channel can have any number of organizations. Each network has at least one application channel with its own blockchain and every application channel has its own private blockchain.

Immutability

Immutability of a block means that once the contents of the block is committed to the blockchain, it is free from tampering.

Trust

“A blockchain is a distributed database with no central authority and no [single] point of trust. When you want to share a database, but you don’t have a lot of trust in the other people who might use it, a blockchain can be very helpful. In this context, “trust” could mean many things. Trust could mean trusting others to perform actions on the database properly. Trust could mean not trying to pry into each other’s private information. Or trust could mean not degrading someone else’s performance to gain a competitive advantage. Discussing trust brings up the two main kinds of blockchain. Most cryptocurrencies use permissionless blockchains where anyone can join and have full rights to use it. For example, anyone can buy Bitcoin or Ether because those use wide-open, permissionless blockchains. On the other hand, business blockchains tend to be permissioned. This means a person needs to meet certain requirements to perform certain actions on the blockchain. Some permissioned blockchains restrict access to pre-verified users who have already proven they are who they say they are. Others allow anyone to join, but only let trusted identities verify transactions on the blockchain. Remember our example of the database shared between head office and the field reps of a company. If a blockchain was used to manage that database, it would definitely be permissioned: Everyone accessing the blockchain would have to be an employee of the company or perhaps a trusted trading partner.”

Source: An Introduction to Hyperledger, The Hyperledger White Paper WG, v1.1

Governance

Governance is the way the rules, norms and actions are structured, sustained, regulated and held accountable. The degree of formality depends on the internal rules of a given organization and, externally, with its business partners. As such, governance may take many forms, driven by many different motivations and with many different results. For instance, a government may operate as a democracy where citizens vote on who should govern and the public good is the goal, while a non-profit organization may be governed by a small board of directors and pursue more specific aims.

In addition, a variety of external actors without decision-making power can influence the process of governing. These include lobbies, think tanks, political parties, non-government organizations and the media.

Source: Wikipedia.

Node

A node is a HLF blockchain network is a piece of software.

Fabric: In Hyperledger Fabric it is either a peer, which is either an endorsing peer or a committing peer, or element of the ordering service. For Hyperledger Fabric the follow integrity rules hold: The endorsing peers are a subset of the committing peers. Every peer is a committing peer. No element of the set of peers is an orderer.

Peer

A peer is a participant in blockchain; in general, a peer can endorse a transaction, commit a transaction or order transactions in a block.

Fabric: The nodes inside a Fabric network consists of peers and orderers. The set of peers and the set of orderers have no element in common. All peers have the role of maintaining the ledger of the channel, consisting of the blockchain and the World State; some peers use smart contracts to simulate the transaction and to decide on the endorsement of a submitted transaction.

Chaincode

Chaincode is a computer program that either provides functionalities for Enterprise transactions or state. It is useful to distinguish chaincode specific for an enterprise and chaincode that provides domain agnostic functions.

Fabric: The current trend in Fabric is to use the term chaincode to cover both enterprise specific and domain agnostic chaincode. Enterprise specific chaincode is what most people call smart contracts.

Ledger

The ledger consists of two components, the immutable chain containing the transactions (transitions) and the state.

According to the Fabric documentation (v1.2) the ledger consists of the blockchain and the World State.




LinuxFoundationX: LFS171x Blockchain for Business - An Introduction to Hyperledger Technologie


Glossary

On this page, we will have a list of the key concepts that are used in this course, and their definitions, that will help you when going through the course content. These definitions will be quickly accessible from anywhere within the course, just click on the Glossary tab.

Block - A set of transactions that are bundled together and added to the chain at the same time.

Byzantine Fault Tolerance Algorithm - A consensus algorithm designed to defend against failures in the system caused by forged or malicious messages. In order to be fault tolerant of a Byzantine fault, the number of nodes that must reach consensus is 2f+1 in a system containing 3f+1, where f is the number of faults in the system. 

Chaincode - Smart contracts in Hyperledger Fabric. They encapsulate both the asset definitions and the business logic (or transactions) for modifying those assets.

Consensus Algorithm - Refers to a system of ensuring that parties agree to a certain state of the system as the true state.

Cryptocurrency - is a digital asset that is used as a medium of exchange. A cryptocurrency is exchanged by using digital signatures to transfer ownership from one cryptographic key pair to another key pair. Since this digital asset has characteristics of money (like store of value and medium of exchange), it is generally referred to as currency. Note: It should not be confused with digital currency or virtual currency.

Cryptoeconomics - A field of study that explores the intersection of cryptography and economic incentives. While cryptography is used for ensuring network security at various levels and functions, the built-in economic incentives provided to the participating nodes in the network ensure that, at any given point, the majority of players in the network operate in a desirable way. 

Cryptography - The study of the techniques used to allow secure communication between different parties, and to ensure the authenticity and immutability of the data being communicated.

Distributed Ledger - A type of data structure which resides across multiple computer devices, generally spread across locations and regions.

Hash Function - It is used to map data of any size to a fixed length. The output of a hash function is referred to as a hash, hash value, or digest. One important characteristic of a hash function is that, when given a specific input, the hash function will always produce the exact same output.

Key/Value Pair - It consists of two parts, one designated as a 'key', and another as a 'value'. The 'key' is an identifier that allows you to look up the 'value'. The 'value' is the data that is stored for a given 'key'.

Mining - The process of solving computational challenging puzzles in order to create new blocks in the Bitcoin blockchain.

Node - Computer device attached to a blockchain network. Types of nodes include: mining nodes, validator nodes, committer nodes, and endorser nodes. Nodes are sometimes also called 'peers' because they make up the devices within a peer-to-peer network.

Peer-to-Peer Network - A network which consists of computer systems directly connected to each other via the Internet without a central server.

Private/Public Keys - Private keys are used to derive a public key. While private keys remain confidential, public keys are available to everyone in the network (similar to an email address). Anything encrypted with a public key can only be decrypted using its corresponding private key, and vice versa. 

Proof of Elapsed Time (PoET) - Consensus algorithm used by Hyperledger Sawtooth that utilizes a lottery function in which the node with the shortest wait time creates the next block. 

Proof of Stake (PoS) - Consensus algorithm where nodes are randomly selected to validate blocks, and the probability of this random selection depends on the amount of stake held.

Proof of Work (PoW) - Consensus algorithm first utilized by Bitcoin that involves solving a computational challenging puzzle in order to create a new block.

Smart Contract - Computer program that executes predefined actions when certain conditions within the system are met. Smart contracts were first proposed by Nick Szabo in 1996 (http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html).

State - Contains up-to-date data that represents the latest values for all keys included in the network's ledger. The state of a network encompasses all past transactions in the network, from the genesis block to the present time.

Transaction - A record of an event, cryptographically secured with a digital signature, that is verified, ordered, and bundled with other such records into blocks. 

Transaction Families - Smart contracts in Hyperledger Sawtooth. They define the operations that can be applied to transactions. Transaction families consist of both transaction processors (the server-side logic) and clients (for use from web or mobile applications).

Turing-Complete - Named after Alan Turing, an English mathematician and computer scientist, it refers to a computer that can solve any problem that a Turing Machine can. A Turing Machine is a machine that can simulate any computer algorithm, no matter how complicated. Bitcoin scripting language is not Turing-Complete, as there are no looping and branching types of computing sequences. Ethereum's Solidity language is considered Turing-Complete, as it does have looping and branching.  

Glossary FABRIC

Terminology is important, so that all Hyperledger Fabric users and developers agree on what we mean by each specific term. What is a smart contract for example. The documentation will reference the glossary as needed, but feel free to read the entire thing in one sitting if you like; it’s pretty enlightening!

Anchor Peer

Used by gossip to make sure peers in different organizations know about each other.

When a configuration block that contains an update to the anchor peers is committed, peers reach out to the anchor peers and learn from them about all of the peers known to the anchor peer(s). Once at least one peer from each organization has contacted an anchor peer, the anchor peer learns about every peer in the channel. Since gossip communication is constant, and because peers always ask to be told about the existence of any peer they don’t know about, a common view of membership can be established for a channel.

For example, let’s assume we have three organizations — A, B, C — in the channel and a single anchor peer — peer0.orgC — defined for organization C. When peer1.orgA (from organization A) contacts peer0.orgC, it will tell peer0.orgC about peer0.orgA. And when at a later time peer1.orgB contacts peer0.orgC, the latter would tell the former about peer0.orgA. From that point forward, organizations A and B would start exchanging membership information directly without any assistance from peer0.orgC.

As communication across organizations depends on gossip in order to work, there must be at least one anchor peer defined in the channel configuration. It is strongly recommended that every organization provides its own set of anchor peers for high availability and redundancy.

ACL

An ACL, or Access Control List, associates access to specific peer resources (such as system chaincode APIs or event services) to a Policy (which specifies how many and what types of organizations or roles are required). The ACL is part of a channel’s configuration. It is therefore persisted in the channel’s configuration blocks, and can be updated using the standard configuration update mechanism.

An ACL is formatted as a list of key-value pairs, where the key identifies the resource whose access we wish to control, and the value identifies the channel policy (group) that is allowed to access it. For example lscc/GetDeploymentSpec: /Channel/Application/Readers defines that the access to the life cycle chaincode GetDeploymentSpec API (the resource) is accessible by identities which satisfy the /Channel/Application/Readers policy.

A set of default ACLs is provided in the configtx.yaml file which is used by configtxgen to build channel configurations. The defaults can be set in the top level “Application” section of configtx.yaml or overridden on a per profile basis in the “Profiles” section.

Block

A Block

Block B1 is linked to block B0. Block B2 is linked to block B1.


A block contains an ordered set of transactions. It is cryptographically linked to the preceding block, and in turn it is linked to be subsequent blocks. The first block in such a chain of blocks is called the genesis block. Blocks are created by the ordering system, and validated by peers.

Chain

Blockchain

Blockchain B contains blocks 0, 1, 2.


The ledger’s chain is a transaction log structured as hash-linked blocks of transactions. Peers receive blocks of transactions from the ordering service, mark the block’s transactions as valid or invalid based on endorsement policies and concurrency violations, and append the block to the hash chain on the peer’s file system.

Chaincode

See Smart-Contract.

Channel

A Channel

Channel C connects application A1, peer P2 and ordering service O1.


A channel is a private blockchain overlay which allows for data isolation and confidentiality. A channel-specific ledger is shared across the peers in the channel, and transacting parties must be properly authenticated to a channel in order to interact with it. Channels are defined by a Configuration-Block.

Commit

Each Peer on a channel validates ordered blocks of transactions and then commits (writes/appends) the blocks to its replica of the channel Ledger. Peers also mark each transaction in each block as valid or invalid.

Concurrency Control Version Check

Concurrency Control Version Check is a method of keeping state in sync across peers on a channel. Peers execute transactions in parallel, and before commitment to the ledger, peers check that the data read at execution time has not changed. If the data read for the transaction has changed between execution time and commitment time, then a Concurrency Control Version Check violation has occurred, and the transaction is marked as invalid on the ledger and values are not updated in the state database.

Configuration Block

Contains the configuration data defining members and policies for a system chain (ordering service) or channel. Any configuration modifications to a channel or overall network (e.g. a member leaving or joining) will result in a new configuration block being appended to the appropriate chain. This block will contain the contents of the genesis block, plus the delta.

Consensus

A broader term overarching the entire transactional flow, which serves to generate an agreement on the order and to confirm the correctness of the set of transactions constituting a block.

Consenter set

In a Raft ordering service, these are the ordering nodes actively participating in the consensus mechanism on a channel. If other ordering nodes exist on the system channel, but are not a part of a channel, they are not part of that channel’s consenter set.

Consortium

A consortium is a collection of non-orderer organizations on the blockchain network. These are the organizations that form and join channels and that own peers. While a blockchain network can have multiple consortia, most blockchain networks have a single consortium. At channel creation time, all organizations added to the channel must be part of a consortium. However, an organization that is not defined in a consortium may be added to an existing channel.

Chaincode definition

A chaincode definition is used by organizations to agree on the parameters of a chaincode before it can be used on a channel. Each channel member that wants to use the chaincode to endorse transactions or query the ledger needs to approve a chaincode definition for their organization. Once enough channel members have approved a chaincode definition to meet the Lifecycle Endorsement policy (which is set to a majority of organizations in the channel by default), the chaincode definition can be committed to the channel. After the definition is committed, the first invoke of the chaincode (or, if requested, the execution of the Init function) will start the chaincode on the channel.

Current State

See World-State.

Dynamic Membership

Hyperledger Fabric supports the addition/removal of members, peers, and ordering service nodes, without compromising the operationality of the overall network. Dynamic membership is critical when business relationships adjust and entities need to be added/removed for various reasons.

Endorsement

Refers to the process where specific peer nodes execute a chaincode transaction and return a proposal response to the client application. The proposal response includes the chaincode execution response message, results (read set and write set), and events, as well as a signature to serve as proof of the peer’s chaincode execution. Chaincode applications have corresponding endorsement policies, in which the endorsing peers are specified.

Endorsement policy

Defines the peer nodes on a channel that must execute transactions attached to a specific chaincode application, and the required combination of responses (endorsements). A policy could require that a transaction be endorsed by a minimum number of endorsing peers, a minimum percentage of endorsing peers, or by all endorsing peers that are assigned to a specific chaincode application. Policies can be curated based on the application and the desired level of resilience against misbehavior (deliberate or not) by the endorsing peers. A transaction that is submitted must satisfy the endorsement policy before being marked as valid by committing peers.

FabToken

FabToken is an Unspent Transaction Output (UTXO) based token management system that allows users to issue, transfer, and redeem tokens on channels. FabToken uses the membership services of Fabric to authenticate the identity of token owners and manage their public and private keys.

FabToken

FabToken is an Unspent Transaction Output (UTXO) based token management system that allows users to issue, transfer, and redeem tokens on channels. FabToken uses the membership services of Fabric to authenticate the identity of token owners and manage their public and private keys.

Follower

In a leader based consensus protocol, such as Raft, these are the nodes which replicate log entries produced by the leader. In Raft, the followers also receive “heartbeat” messages from the leader. In the event that the leader stops sending those message for a configurable amount of time, the followers will initiate a leader election and one of them will be elected leader.

Genesis Block

The configuration block that initializes the ordering service, or serves as the first block on a chain.

Gossip Protocol

The gossip data dissemination protocol performs three functions: 1) manages peer discovery and channel membership; 2) disseminates ledger data across all peers on the channel; 3) syncs ledger state across all peers on the channel. Refer to the Gossip topic for more details.

Hyperledger Fabric CA

Hyperledger Fabric CA is the default Certificate Authority component, which issues PKI-based certificates to network member organizations and their users. The CA issues one root certificate (rootCert) to each member and one enrollment certificate (ECert) to each authorized user.

Init

A method to initialize a chaincode application. All chaincodes need to have an an Init function. By default, this function is never executed. However you can use the chaincode definition to request the execution of the Init function in order to initialize the chaincode.

Install

The process of placing a chaincode on a peer’s file system.

Instantiate

The process of starting and initializing a chaincode application on a specific channel. After instantiation, peers that have the chaincode installed can accept chaincode invocations. This method was used in the previous version of the chaincode lifecycle. For the current procedure used to start a chaincode on a channel with the new Fabric chaincode lifecycle introduced as part of the Fabric v2.0 Alpha, see Chaincode-definition.

Invoke

Used to call chaincode functions. A client application invokes chaincode by sending a transaction proposal to a peer. The peer will execute the chaincode and return an endorsed proposal response to the client application. The client application will gather enough proposal responses to satisfy an endorsement policy, and will then submit the transaction results for ordering, validation, and commit. The client application may choose not to submit the transaction results. For example if the invoke only queried the ledger, the client application typically would not submit the read-only transaction, unless there is desire to log the read on the ledger for audit purpose. The invoke includes a channel identifier, the chaincode function to invoke, and an array of arguments.

Leader

In a leader based consensus protocol, like Raft, the leader is responsible for ingesting new log entries, replicating them to follower ordering nodes, and managing when an entry is considered committed. This is not a special type of orderer. It is only a role that an orderer may have at certain times, and then not others, as circumstances determine.

Leading Peer

Each Organization can own multiple peers on each channel that they subscribe to. One or more of these peers should serve as the leading peer for the channel, in order to communicate with the network ordering service on behalf of the organization. The ordering service delivers blocks to the leading peer(s) on a channel, who then distribute them to other peers within the same organization.

Ledger

A Ledger

A Ledger, ‘L’

A ledger consists of two distinct, though related, parts – a “blockchain” and the “state database”, also known as “world state”. Unlike other ledgers, blockchains are immutable – that is, once a block has been added to the chain, it cannot be changed. In contrast, the “world state” is a database containing the current value of the set of key-value pairs that have been added, modified or deleted by the set of validated and committed transactions in the blockchain.

It’s helpful to think of there being one logical ledger for each channel in the network. In reality, each peer in a channel maintains its own copy of the ledger – which is kept consistent with every other peer’s copy through a process called consensus. The term Distributed Ledger Technology (DLT) is often associated with this kind of ledger – one that is logically singular, but has many identical copies distributed across a set of network nodes (peers and the ordering service).

Log entry

The primary unit of work in a Raft ordering service, log entries are distributed from the leader orderer to the followers. The full sequence of such entries known as the “log”. The log is considered to be consistent if all members agree on the entries and their order.

Member

See Organization.

Membership Service Provider

An MSP

An MSP, ‘ORG.MSP’

The Membership Service Provider (MSP) refers to an abstract component of the system that provides credentials to clients, and peers for them to participate in a Hyperledger Fabric network. Clients use these credentials to authenticate their transactions, and peers use these credentials to authenticate transaction processing results (endorsements). While strongly connected to the transaction processing components of the systems, this interface aims to have membership services components defined, in such a way that alternate implementations of this can be smoothly plugged in without modifying the core of transaction processing components of the system.

Membership Services

Membership Services authenticates, authorizes, and manages identities on a permissioned blockchain network. The membership services code that runs in peers and orderers both authenticates and authorizes blockchain operations. It is a PKI-based implementation of the Membership Services Provider (MSP) abstraction.

Ordering Service

Also known as orderer. A defined collective of nodes that orders transactions into a block. The ordering service exists independent of the peer processes and orders transactions on a first-come-first-serve basis for all channel’s on the network. The ordering service is designed to support pluggable implementations beyond the out-of-the-box SOLO and Kafka varieties. The ordering service is a common binding for the overall network; it contains the cryptographic identity material tied to each Member.

Organization


An Organization

An organization, ‘ORG’

Also known as “members”, organizations are invited to join the blockchain network by a blockchain service provider. An organization is joined to a network by adding its Membership Service Provider (MSP) to the network. The MSP defines how other members of the network may verify that signatures (such as those over transactions) were generated by a valid identity, issued by that organization. The particular access rights of identities within an MSP are governed by policies which are also agreed upon when the organization is joined to the network. An organization can be as large as a multi-national corporation or as small as an individual. The transaction endpoint of an organization is a Peer. A collection of organizations form a Consortium. While all of the organizations on a network are members, not every organization will be part of a consortium.

Peer

A Peer

A peer, ‘P’

A network entity that maintains a ledger and runs chaincode containers in order to perform read/write operations to the ledger. Peers are owned and maintained by members.

Policy

Policies are expressions composed of properties of digital identities, for example: Org1.Peer OR Org2.Peer. They are used to restrict access to resources on a blockchain network. For instance, they dictate who can read from or write to a channel, or who can use a specific chaincode API via an ACL. Policies may be defined in configtx.yaml prior to bootstrapping an ordering service or creating a channel, or they can be specified when instantiating chaincode on a channel. A default set of policies ship in the sample configtx.yaml which will be appropriate for most networks.

Private Data

Confidential data that is stored in a private database on each authorized peer, logically separate from the channel ledger data. Access to this data is restricted to one or more organizations on a channel via a private data collection definition. Unauthorized organizations will have a hash of the private data on the channel ledger as evidence of the transaction data. Also, for further privacy, hashes of the private data go through the Ordering-Service, not the private data itself, so this keeps private data confidential from Orderer.

Private Data Collection (Collection)

Used to manage confidential data that two or more organizations on a channel want to keep private from other organizations on that channel. The collection definition describes a subset of organizations on a channel entitled to store a set of private data, which by extension implies that only these organizations can transact with the private data.

Proposal

A request for endorsement that is aimed at specific peers on a channel. Each proposal is either an Init or an invoke (read/write) request.

Prover peer

A trusted peer used by the FabToken client to assemble a token transaction and list the unspent tokens owned by a given authorized party.

Prover peer

A trusted peer used by the FabToken client to assemble a token transaction.

Query

A query is a chaincode invocation which reads the ledger current state but does not write to the ledger. The chaincode function may query certain keys on the ledger, or may query for a set of keys on the ledger. Since queries do not change ledger state, the client application will typically not submit these read-only transactions for ordering, validation, and commit. Although not typical, the client application can choose to submit the read-only transaction for ordering, validation, and commit, for example if the client wants auditable proof on the ledger chain that it had knowledge of specific ledger state at a certain point in time.

Quorum

This describes the minimum number of members of the cluster that need to affirm a proposal so that transactions can be ordered. For every consenter set, this is a majority of nodes. In a cluster with five nodes, three must be available for there to be a quorum. If a quorum of nodes is unavailable for any reason, the cluster becomes unavailable for both read and write operations and no new logs can be committed.

Raft

New for v1.4.1, Raft is a crash fault tolerant (CFT) ordering service implementation based on the etcd library of the Raft protocol <https://raft.github.io/raft.pdf>`_. Raft follows a “leader and follower” model, where a leader node is elected (per channel) and its decisions are replicated by the followers. Raft ordering services should be easier to set up and manage than Kafka-based ordering services, and their design allows organizations to contribute nodes to a distributed ordering service.

Software Development Kit (SDK)

The Hyperledger Fabric client SDK provides a structured environment of libraries for developers to write and test chaincode applications. The SDK is fully configurable and extensible through a standard interface. Components, including cryptographic algorithms for signatures, logging frameworks and state stores, are easily swapped in and out of the SDK. The SDK provides APIs for transaction processing, membership services, node traversal and event handling.

Currently, the two officially supported SDKs are for Node.js and Java, while three more – Python, Go and REST – are not yet official but can still be downloaded and tested.

Smart Contract

A smart contract is code – invoked by a client application external to the blockchain network – that manages access and modifications to a set of key-value pairs in the World State. In Hyperledger Fabric, smart contracts are referred to as chaincode. Smart contract chaincode is installed onto peer nodes and then defined and used on one or more channels.

State Database

Current state data is stored in a state database for efficient reads and queries from chaincode. Supported databases include levelDB and couchDB.

System Chain

Contains a configuration block defining the network at a system level. The system chain lives within the ordering service, and similar to a channel, has an initial configuration containing information such as: MSP information, policies, and configuration details. Any change to the overall network (e.g. a new org joining or a new ordering node being added) will result in a new configuration block being added to the system chain.

The system chain can be thought of as the common binding for a channel or group of channels. For instance, a collection of financial institutions may form a consortium (represented through the system chain), and then proceed to create channels relative to their aligned and varying business agendas.

Transaction

A Transaction

A transaction, ‘T’

Transactions are created when a chaincode or FabToken client is used to read or write to data from the ledger. If you are invoking a chaincode, application clients gather the responses from endorsing peers and then package the results and endorsements into a transaction that is submitted for ordering, validation, and commit. If using FabToken to create a token transaction, the FabToken client uses a prover peer to create a transaction that is submitted to the ordering service and then validated by committing peers.

World State

Current State

The World State, ‘W’

Also known as the “current state”, the world state is a component of the HyperLedger Fabric Ledger. The world state represents the latest values for all keys included in the chain transaction log. Chaincode executes transaction proposals against world state data because the world state provides direct access to the latest value of these keys rather than having to calculate them by traversing the entire transaction log. The world state will change every time the value of a key changes (for example, when the ownership of a car – the “key” – is transferred from one owner to another – the “value”) or when a new key is added (a car is created). As a result, the world state is critical to a transaction flow, since the current state of a key-value pair must be known before it can be changed. Peers commit the latest values to the ledger world state for each valid transaction included in a processed block.


















  • No labels