Commit b0ced541 authored by joe-alewine's avatar joe-alewine Committed by Joe Alewine
Browse files

[FAB-8171] Ordering service concept doc



Cherry picking change merged in master

Conceptual information on orderers and the
ordering service generally, and then a
discussion of implementations, focusing on
Raft.

Change-Id: I679594b542d1496f9ee7b566f70f73ba84734607
Signed-off-by: default avatarjoe-alewine <Joe.Alewine@ibm.com>
Signed-off-by: default avatarDavid Enyeart <enyeart@us.ibm.com>
(cherry picked from commit bf40f9857928278d0c923bde969d02dc38f5ddf5)
parent 98b9b0a5
......@@ -11,7 +11,8 @@ Key Concepts
identity/identity.md
membership/membership.md
peers/peers.md
private-data/private-data.md
ledger/ledger.md
smartcontract/smartcontract.md
ledger/ledger.md
orderer/ordering_service.md
private-data/private-data.md
usecases
This diff is collapsed.
......@@ -3,24 +3,24 @@
A blockchain network is comprised primarily of a set of *peer nodes* (or, simply, *peers*).
Peers are a fundamental element of the network because they host ledgers and smart
contracts. Recall that a ledger immutably records all the transactions generated
by smart contracts (or *chaincode*). Smart contracts and ledgers are used to encapsulate the
by smart contracts (which in Hyperledger Fabric are contained in a *chaincode*,
more on this later). Smart contracts and ledgers are used to encapsulate the
shared *processes* and shared *information* in a network, respectively. These
aspects of a peer make them a good starting point to understand a Hyperledger
Fabric network.
aspects of a peer make them a good starting point to understand a Fabric network.
Other elements of the blockchain network are of course important: ledgers and
smart contracts, orderers, policies, channels, applications, organizations,
identities, and membership, and you can read more about them in their own
dedicated sections. This section focusses on peers, and their relationship to those
other elements in a Hyperledger Fabric network.
other elements in a Fabric network.
![Peer1](./peers.diagram.1.png)
*A blockchain network is comprised of peer nodes, each of which can hold copies
of ledgers and copies of smart contracts. In this example, the network N
consists of peers P1, P2 and P3, each of which maintain their own instance
of the distributed ledger L1. P1, P2 and P3 use the same chaincode, S1, to access their copy of
that distributed ledger*.
of the distributed ledger L1. P1, P2 and P3 use the same chaincode, S1, to access
their copy of that distributed ledger*.
Peers can be created, started, stopped, reconfigured, and even deleted. They
expose a set of APIs that enable administrators and applications to interact
......@@ -29,11 +29,12 @@ this section.
### A word on terminology
Hyperledger Fabric implements smart contracts with a technology concept it calls
Fabric implements **smart contracts** with a technology concept it calls
**chaincode** --- simply a piece of code that accesses the ledger, written in one
of the supported programming languages. In this topic, we'll usually use the
term **chaincode**, but feel free to read it as **smart contract** if you're
more used to that term. It's the same thing!
more used to that term. It's the same thing! If you want to learn more about
chaincode and smart contracts, check out our [documentation on smart contracts and chaincode](smartcontract/smartcontract.html).
## Ledgers and Chaincode
......@@ -53,9 +54,9 @@ can be many ledgers and chaincodes hosted on an individual peer.*
Because a peer is a *host* for ledgers and chaincodes, applications and
administrators must interact with a peer if they want to access these resources.
That's why peers are considered the most fundamental building blocks of a
Hyperledger Fabric network. When a peer is first created, it has
neither ledgers nor chaincodes. We'll see later how ledgers get created,
and how chaincodes get installed, on peers.
Fabric network. When a peer is first created, it has neither ledgers nor
chaincodes. We'll see later how ledgers get created, and how chaincodes get
installed, on peers.
### Multiple Ledgers
......@@ -92,9 +93,8 @@ many chaincodes which access it. In this example, we can see that peer P1
hosts ledgers L1 and L2, where L1 is accessed by chaincodes S1 and S2, and
L2 is accessed by S1 and S3. We can see that S1 can access both L1 and L2.*
We'll see a little later why the concept of **channels** in Hyperledger Fabric
is important when hosting multiple ledgers or multiple chaincodes on a
peer.
We'll see a little later why the concept of **channels** in Fabric is important
when hosting multiple ledgers or multiple chaincodes on a peer.
## Applications and Peers
......@@ -102,12 +102,12 @@ We're now going to show how applications interact with peers to access the
ledger. Ledger-query interactions involve a simple three-step dialogue between
an application and a peer; ledger-update interactions are a little more
involved, and require two extra steps. We've simplified these steps a little to
help you get started with Hyperledger Fabric, but don't worry --- what's most
important to understand is the difference in application-peer interactions for
ledger-query compared to ledger-update transaction styles.
help you get started with Fabric, but don't worry --- what's most important to
understand is the difference in application-peer interactions for ledger-query
compared to ledger-update transaction styles.
Applications always connect to peers when they need to access ledgers and
chaincodes. The Hyperledger Fabric Software Development Kit (SDK) makes this
chaincodes. The Fabric Software Development Kit (SDK) makes this
easy for programmers --- its APIs enable applications to connect to peers, invoke
chaincodes to generate transactions, submit transactions to the network that
will get ordered and committed to the distributed ledger, and receive events
......@@ -242,8 +242,8 @@ Applications connect either to peers in their organization, or peers in another
organization, depending on the nature of the ledger interaction that's required.
For ledger-query interactions, applications typically connect to their own
organization's peers. For ledger-update interactions, we'll see later why
applications need to connect to peers representing *every* organization that is required to
endorse the ledger update.
applications need to connect to peers representing *every* organization that is
required to endorse the ledger update.
## Peers and Identity
......@@ -298,8 +298,8 @@ Org2.
## Peers and Orderers
We've seen that peers form the basis for a blockchain network, hosting ledgers and chaincode
which can be queried and updated by peer-connected applications.
We've seen that peers form the basis for a blockchain network, hosting ledgers
and smart contracts which can be queried and updated by peer-connected applications.
However, the mechanism by which applications and peers interact with each other
to ensure that every peer's ledger is kept consistent is mediated by special
nodes called *orderers*, and it's to these nodes we now turn our
......@@ -394,63 +394,20 @@ transaction workflow early. We'll see later that if an application tries to use
an inconsistent set of transaction responses to update the ledger, it will be
rejected.
### Phase 2: Packaging
### Phase 2: Ordering and packaging transactions into blocks
The second phase of the transaction workflow is the packaging phase. The orderer
is pivotal to this process --- it receives transactions containing endorsed
transaction proposal responses from many applications. It orders each
transaction relative to other transactions, and packages batches of transactions
into blocks ready for distribution back to all peers connected to the orderer,
including the original endorsing peers.
![Peer11](./peers.diagram.11.png)
*The first role of an orderer node is to package proposed ledger updates. In
this example, application A1 sends a transaction T1 endorsed by E1 and E2 to
the orderer O1. In parallel, Application A2 sends transaction T2 endorsed by E1
to the orderer O1. O1 packages transaction T1 from application A1 and
transaction T2 from application A2 together with other transactions from other
applications in the network into block B2. We can see that in B2, the
transaction order is T1,T2,T3,T4,T6,T5 -- which may not be the order in which
these transactions arrived at the orderer node! (This example shows a very
simplified orderer configuration.)*
An orderer receives proposed ledger updates concurrently from many different
applications in the network on a particular channel. Its job is to arrange
these proposed updates into a well-defined sequence, and package them into
*blocks* for subsequent distribution. These blocks will become the *blocks* of
the blockchain! Once an orderer has generated a block of the desired size, or
after a maximum elapsed time, it will be sent to all peers connected to it on a
particular channel. We'll see how this block is processed in phase 3.
It's worth noting that the sequencing of transactions in a block is not
necessarily the same as the order of arrival of transactions at the orderer!
Transactions can be packaged in any order into a block, and it's this sequence
that becomes the order of execution. What's important is that there **is** a
strict order, rather than **what** that order is.
This strict ordering of transactions within blocks makes Hyperledger Fabric a
little different from other blockchains where the same transaction can be
packaged into multiple different blocks. In Hyperledger Fabric, this cannot
happen --- the blocks generated by a collection of orderers are said to be
**final** because once a transaction has been written to a block, its position
in the ledger is immutably assured. Hyperledger Fabric's finality means that a
disastrous occurrence known as a **ledger fork** cannot occur. Once transactions
are captured in a block, history cannot be rewritten for that transaction at
a future point in time.
We can see also see that, whereas peers host the ledger and chaincodes,
orderers most definitely do not. Every transaction that arrives at an orderer is
mechanically packaged in a block --- the orderer makes no judgement as to the
value of a transaction, it simply packages it. That's an important property of
Hyperledger Fabric --- all transactions are marshalled into a strict order ---
transactions are never dropped or de-prioritized.
transaction proposal responses from many applications, and orderes the
transactions into blocks. For more details about the
ordering and packaging phase, check out our
[conceptual information about the ordering phase](../orderer/ordering_service.html#phase-two-ordering-and-packaging-transactions-into-blocks).
### Phase 3: Validation and commit
At the end of phase 2, we see that orderers have been responsible for the simple
but vital processes of collecting proposed transaction updates, ordering them,
packaging them into blocks, ready for distribution.
### Phase 3: Validation
and packaging them into blocks, ready for distribution to the peers.
The final phase of the transaction workflow involves the distribution and
subsequent validation of blocks from the orderer to the peers, where they can be
......@@ -545,7 +502,7 @@ now, think of orderers as nodes which collect and distribute proposed ledger
updates from applications for peers to validate and include on the ledger.
That's it! We've now finished our tour of peers and the other components that
they relate to in Hyperledger Fabric. We've seen that peers are in many ways the
they relate to in Fabric. We've seen that peers are in many ways the
most fundamental element --- they form the network, host chaincodes and the
ledger, handle transaction proposals and responses, and keep the ledger
up-to-date by consistently applying transaction updates to it.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment