5 stars based on
77 reviews
The blockchain is a distributed system consisting of many nodes that communicate with each other. The blockchain runs programs called chaincode, holds state and ledger data, and executes transactions. The chaincode is the central element as transactions are operations invoked hyperledger blockchain ppt the chaincode.
There may exist one or more special chaincodes for management functions and parameters, collectively called system chaincodes. As described later, deploy transactions are special cases of invoke transactions, where a deploy transaction that creates new chaincode, corresponds to an invoke transaction on a system chaincode. This document does not yet describe: The latest state of the blockchain or, simply, state is modeled as a versioned key-value store KVSwhere keys are names and values are arbitrary blobs.
These entries are manipulated by the chaincodes applications running on the blockchain through put and get KVS-operations.
The state is stored persistently and updates to the state are logged. Keys in the KVS can be recognized from their name to belong to a particular chaincode, in the sense that only transaction of a certain chaincode may modify the keys belonging to this chaincode. In principle, any chaincode can read the keys belonging to other chaincodes.
Support for cross-chaincode transactions, that modify the state belonging to hyperledger blockchain ppt or more chaincodes is a post-v1 feature.
Ledger provides hyperledger blockchain ppt verifiable history of all successful state changes we talk about valid transactions and unsuccessful attempts to change state we talk about invalid transactionsoccurring during the operation of the system. Ledger is constructed by the ordering service see Sec 1. The hashchain imposes the total order of blocks in a ledger and each block contains an array of totally ordered transactions. This imposes total order across hyperledger blockchain ppt transactions.
Ledger is kept at all peers and, optionally, at a subset of orderers. In the context of an orderer we refer to the Ledger as to OrdererLedgerwhereas in the context of a peer we refer hyperledger blockchain ppt the ledger as to PeerLedger. PeerLedger differs from the OrdererLedger in that peers locally maintain a bitmask that tells hyperledger blockchain ppt valid transactions from invalid ones see Section XX for more details. Orderers maintain OrdererLedger for fault-tolerance and availability of the PeerLedger and may decide to prune it hyperledger blockchain ppt anytime, provided that properties of the ordering service see Sec.
The ledger allows peers to replay the history hyperledger blockchain ppt all transactions and to reconstruct the state. Therefore, state as described in Sec 1. Hyperledger blockchain ppt are the communication entities of the blockchain.
The client represents hyperledger blockchain ppt entity that acts on behalf of an end-user. It must connect to a peer for communicating hyperledger blockchain ppt the blockchain. The client may connect to any peer of its choice. Clients create and thereby invoke transactions. A peer receives ordered state updates in the form of blocks from the ordering hyperledger blockchain ppt and maintain the state and the ledger.
Peers can additionally take up a special role of an endorsing peeror an endorser. The special function of an endorsing peer occurs with respect to a particular chaincode and consists in endorsing a transaction before it is committed. Every chaincode may specify an endorsement policy that may refer to a set of endorsing peers. In the special case of deploy transactions that install new chaincode the deployment endorsement policy is specified as an endorsement policy of the system chaincode.
The orderers form the ordering servicei. The ordering service can be implemented in different ways: Ordering service provides a shared communication channel to clients and peers, offering a broadcast service hyperledger blockchain ppt messages containing transactions.
Clients connect hyperledger blockchain ppt the channel and may broadcast messages on the channel which are then hyperledger blockchain ppt to all peers. The channel supports atomic delivery of all messages, that is, message communication with total-order delivery and implementation specific reliability. In other words, the channel outputs the same messages to all hyperledger blockchain ppt peers and outputs them to all peers hyperledger blockchain ppt the same logical order.
This atomic communication guarantee is also called total-order broadcastatomic broadcastor consensus in the context of distributed systems. The communicated messages are the candidate transactions for inclusion in the blockchain state. Partitioning ordering service channels.
Clients can connect to a given channel and can then send messages and obtain the messages that arrive.
Channels can be thought of as partitions - clients connecting to one channel are unaware of the existence of other channels, but clients may connect to multiple channels. Peers connect to the channel provided by the ordering service, via the interface provided by the ordering service.
The ordering service API consists of two basic operations more generally asynchronous events:. Ledger and block formation. The ledger see also Sec. In a nutshell, it is a sequence of deliver seqno, prevhash, blob events, which form a hash chain according to the computation of prevhash described before.
Most of the time, for efficiency reasons, instead of outputting individual transactions blobsthe ordering service will group batch the blobs and output blocks within a single deliver event. In this case, the ordering service must impose and convey a deterministic ordering of the blobs within each block. The number of blobs in a block may be chosen dynamically by an ordering service implementation.
In the following, for ease of presentation, we define ordering service properties rest of this subsection and explain the workflow of transaction endorsement Section 2 assuming one blob per deliver event. These hyperledger blockchain ppt easily extended to blocks, assuming that a deliver event for a block corresponds to a sequence of individual deliver events for each blob within a block, according to the above mentioned deterministic ordering of blobs within a blocs.
The guarantees of the ordering service or atomic-broadcast channel stipulate what happens to a broadcasted message and what relations exist among delivered messages. These guarantees are as follows:. As long as peers are connected for sufficiently long periods of time to the channel hyperledger blockchain ppt can disconnect or crash, but will restart and hyperledger blockchain pptthey will see an identical series of delivered seqno, prevhash, blob messages.
This means the outputs hyperledger blockchain ppt events occur in the same order on all peers and according to sequence number and carry identical content blob and prevhash for the same sequence number. Note this is only a logical orderand a deliver seqno, prevhash, blob on one peer is not required to occur in any real-time relation to hyperledger blockchain ppt seqno, prevhash, blob that outputs the same message at another peer.
Put differently, given a particular seqnono two correct peers deliver different prevhash or hyperledger blockchain ppt values. Moreover, no value blob is delivered unless some client peer actually called broadcast blob and, preferably, every broadcasted blob is only delivered once.
Furthermore, the deliver event contains the cryptographic hash of the data in the previous deliver event prevhash. When the ordering service implements atomic broadcast guarantees, prevhash is the cryptographic hash of the parameters from the deliver hyperledger blockchain ppt with sequence number seqno This establishes a hash chain across deliver events, which is used to help verify the integrity of the ordering service output, as discussed in Sections 4 and 5 later.
In the special case of the first deliver event, prevhash has a default value. Liveness guarantees of the ordering service are specified by a ordering service implementation. The exact guarantees may depend on the network and node fault model.
In principle, if the submitting client does not fail, the ordering service should guarantee that every correct peer that connects to the ordering service eventually delivers every submitted transaction. The set of endorsing peers for a given chaincodeID is made available to client via peer, which in turn knows the set of endorsing peers from endorsement policy see Section 3.
For example, the transaction could be sent to all endorsers of a given chaincodeID. That said, some endorsers could be offline, others may object and choose not to endorse the transaction. The submitting client tries to satisfy the policy expression with the endorsers available. In the following, we first detail PROPOSE message format and then discuss possible patterns of interaction between submitting client and endorsers. The details of txPayload will differ between invoke transactions and deploy transactions i.
For an invoke transactiontxPayload would consist of two fields. For a deploy transactiontxPayload would consist of three fields. If the client specifies the anchor argument, an endorser endorses a transaction hyperledger blockchain ppt upon read version numbers of corresponding keys in its local KVS match anchor see Section 2. Cryptographic hash of tx is used by all nodes as a unique transaction hyperledger blockchain ppt tid i. The client stores tid in memory hyperledger blockchain ppt waits for responses from endorsing peers.
The client decides on the sequence of interaction with endorsers. Different patterns of communication are possible and client is free to decide on those see also Section 2. If the client specifies anchor then endorsing peer simulates the transactions only hyperledger blockchain ppt read version numbers i.
Simulating a transaction involves endorsing peer tentatively executing a transaction txPayloadby invoking the chaincode to which the transaction refers chaincodeID and the copy of the state that the endorsing peer locally holds.
Recall that the state consists of key-value hyperledger blockchain ppt. All key-value entries are versioned; that is, every entry contains ordered version information, which is incremented each time the value stored under a key is updated. The peer that interprets the transaction records all key-value pairs accessed by the chaincode, either for reading hyperledger blockchain ppt for writing, but the peer does not yet update its state.
If a client specifies anchor in the PROPOSE message then client specified anchor must equal readset produced by endorsing peer when simulating the transaction. By default, endorsing logic at a peer accepts the tran-proposal and simply signs the tran-proposal.
However, endorsing logic may interpret arbitrary functionality, to, e. The intention is to have txContentBlob used as some representation of tx e. Notice that an endorser does not change its state in this step, the updates produced by transaction simulation in the context of endorsement do not affect the state!
As discussed in Section 2. If the endorsement policy is satisfied, the transaction has been endorsed ; note that it is not yet committed. If hyperledger blockchain ppt submitting client does not manage to collect an endorsement for a transaction proposal, it abandons this transaction with an option to retry later.
For transaction with a valid endorsement, we now start using the ordering service. If the client does not have capability of invoking ordering service directly, it may proxy its broadcast through some peer of its choice. Such a peer must be trusted by the client not to remove any message from the endorsement or otherwise the transaction may be deemed invalid.
Notice that, however, a proxy peer hyperledger blockchain ppt not fabricate a valid endorsement. When an event deliver seqno, prevhash, blob occurs and hyperledger blockchain ppt peer has applied all state updates for blobs with sequence hyperledger blockchain ppt lower than seqnohyperledger blockchain ppt peer does the following:.
Serializability is a default isolation guarantee, unless chaincode endorsement policy specifies a different one.
