diff --git a/docs/source/FAQ/chaincode_FAQ.rst b/docs/source/FAQ/chaincode_FAQ.rst
index fe51964c98e..c5bf0950308 100644
--- a/docs/source/FAQ/chaincode_FAQ.rst
+++ b/docs/source/FAQ/chaincode_FAQ.rst
@@ -11,7 +11,7 @@ executed and validated by chain validators together during the consensus
process. Developers can use chaincodes to develop business contracts,
asset definitions, and collectively-managed decentralized applications.
-* How do I create a business contract using the fabric?
+* How do I create a business contract using the fabric?
There are generally two ways to develop business contracts: the first way is to
code individual contracts into standalone instances of chaincode; the
@@ -20,7 +20,7 @@ create decentralized applications that manage the life cycle of one or
multiple types of business contracts, and let end users instantiate
instances of contracts within these applications.
-* How do I create assets using the fabric?
+* How do I create assets using the fabric?
Users can use chaincode (for business rules) and membership service (for digital tokens) to
design assets, as well as the logic that manages them.
@@ -35,7 +35,7 @@ fabric does not advocate either one over the other. Instead, one of our
first requirements was to ensure that both approaches can be easily
implemented with tools available in the fabric.
-* Which languages are supported for writing chaincode?
+* Which languages are supported for writing chaincode?
Chaincode can be written in any programming language and executed in containers
inside the fabric context layer. We are also looking into developing a
@@ -49,7 +49,7 @@ additional languages and the development of a fabric-specific templating
language have been discussed, and more details will be released in the
near future.
-* Does the fabric have native currency?
+* Does the fabric have native currency?
No. However, if you really need a native currency for your chain network, you can develop your own
native currency with chaincode. One common attribute of native currency
diff --git a/docs/source/FAQ/confidentiality_FAQ.rst b/docs/source/FAQ/confidentiality_FAQ.rst
index c17b4a2b5b1..c2f6406b515 100644
--- a/docs/source/FAQ/confidentiality_FAQ.rst
+++ b/docs/source/FAQ/confidentiality_FAQ.rst
@@ -19,7 +19,7 @@ known only to their originators, validators, and authorized auditors.
Only holders of the secret keys can interpret transaction contents.
* What if none of the stakeholders of a business contract are
-validators?
+validators?
In some business scenarios, full confidentiality of contract
logic may be required – such that only contract counterparties and
diff --git a/docs/source/FAQ/consensus_FAQ.rst b/docs/source/FAQ/consensus_FAQ.rst
index 929db98f1be..52e50f5a3d7 100644
--- a/docs/source/FAQ/consensus_FAQ.rst
+++ b/docs/source/FAQ/consensus_FAQ.rst
@@ -1,7 +1,7 @@
Consensus Algorithm
-------------------
-Which Consensus Algorithm is used in Fabric?
+Which Consensus Algorithm is used in Fabric?
The fabric is built on a pluggable architecture such that developers can configure
their deployment with the consensus module that best suits their needs.
diff --git a/docs/source/FAQ/identity_management_FAQ.rst b/docs/source/FAQ/identity_management_FAQ.rst
index 476e22e72bd..a96b0014f3e 100644
--- a/docs/source/FAQ/identity_management_FAQ.rst
+++ b/docs/source/FAQ/identity_management_FAQ.rst
@@ -1,7 +1,7 @@
Identity Management (Membership Service)
----------------------------------------
-* What is unique about the fabric's Membership Service module?
+* What is unique about the fabric's Membership Service module?
One of the things that makes the Membership Service module stand out from
the pack is our implementation of the latest advances in cryptography.
diff --git a/docs/source/FAQ/usage_FAQ.rst b/docs/source/FAQ/usage_FAQ.rst
index 977aa61c0ff..bd6278ab954 100644
--- a/docs/source/FAQ/usage_FAQ.rst
+++ b/docs/source/FAQ/usage_FAQ.rst
@@ -1,7 +1,7 @@
Usage
-----
-* What are the expected performance figures for the fabric?
+* What are the expected performance figures for the fabric?
The performance of any chain network depends on several factors: proximity
of the validating nodes, number of validators, encryption method,
@@ -15,7 +15,7 @@ continuously improving the performance and the scalability of the
system.
* Do I have to own a validating node to transact on a chain
-network?
+network?
No. You can still transact on a chain network by owning a
non-validating node (NV-node).
@@ -32,7 +32,7 @@ In addition, NV-nodes retain full copies of the ledger, enabling local
queries of the ledger data.
* What does the error string "state may be inconsistent, cannot
-query" as a query result mean?
+query" as a query result mean?
Sometimes, a validating peer will be out
of sync with the rest of the network. Although determining this
diff --git a/docs/source/Setup/TLSSetup.rst b/docs/source/Setup/TLSSetup.rst
index a3b05fe1091..22e74248016 100644
--- a/docs/source/Setup/TLSSetup.rst
+++ b/docs/source/Setup/TLSSetup.rst
@@ -10,7 +10,7 @@ Steps to enable TLS for all sever (ECA , ACA , TLSCA , TCA) and between ACA clie
serverhostoverride:
tls_enabled: false
client:
- cert:
+ cert:
file:
To enable TLS between the ACA client and the rest of the CA Services
@@ -45,7 +45,7 @@ output of the form:
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key:
- pub:
+ pub:
04:38:d2:62:75:4a:18:d9:f7:fe:6a:e7:df:32:e2:
15:0f:01:9c:1b:4f:dc:ff:22:97:5c:2a:d9:5c:c3:
a3:ef:e3:90:3b:3c:8a:d2:45:b1:60:11:94:5e:a7:
@@ -55,16 +55,16 @@ output of the form:
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
- X509v3 Extended Key Usage:
+ X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
- X509v3 Subject Key Identifier:
+ X509v3 Subject Key Identifier:
E8:9C:86:81:59:D4:D7:76:43:C7:2E:92:88:30:1B:30:A5:B3:A4:5C
- X509v3 Authority Key Identifier:
+ X509v3 Authority Key Identifier:
keyid:5E:33:AC:E0:9D:B9:F9:71:5F:1F:96:B5:84:85:35:BE:89:8C:35:C2
- X509v3 Subject Alternative Name:
+ X509v3 Subject Alternative Name:
DNS:www.example.com
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:9f:7e:93:93:af:3d:cf:7b:77:f0:55:2d:57:
diff --git a/docs/source/Style-guides/go-style.rst b/docs/source/Style-guides/go-style.rst
index e2b9d708b23..e8078ec50a0 100644
--- a/docs/source/Style-guides/go-style.rst
+++ b/docs/source/Style-guides/go-style.rst
@@ -1,7 +1,7 @@
Coding guidelines
-----------------
-Coding Golang
+Coding Golang
~~~~~~~~~~~~~~
We code in Go™ and strictly follow the `best
@@ -12,7 +12,7 @@ code and fix all errors and warnings: -
vet `__ -
`goimports `__
-Generating gRPC code
+Generating gRPC code
---------------------
If you modify any ``.proto`` files, run the following command to
diff --git a/docs/source/biz/usecases.rst b/docs/source/biz/usecases.rst
index 361fb413dc6..1999e74d5c1 100644
--- a/docs/source/biz/usecases.rst
+++ b/docs/source/biz/usecases.rst
@@ -188,7 +188,7 @@ Key Components
interrogate the chaincode that defines an asset type. If an asset
represents shares of publicly traded companies, then the view access
right must be granted to every entity on the network.
-
+
One Trade, One Contract
-----------------------
diff --git a/docs/source/case_for_fabric.rst b/docs/source/case_for_fabric.rst
index bfbab034e3a..1e73a2ab964 100644
--- a/docs/source/case_for_fabric.rst
+++ b/docs/source/case_for_fabric.rst
@@ -1,71 +1,71 @@
The Case for Fabric
===================
-Hyperledger Fabric is a social innovation that is about to free innovators in startups,
-enterprises and government to transform and radically reduce the cost of working together
-across organizations. By the end of this section, you should have the essential understanding
+Hyperledger Fabric is a social innovation that is about to free innovators in startups,
+enterprises and government to transform and radically reduce the cost of working together
+across organizations. By the end of this section, you should have the essential understanding
of Fabric you need to start *knitting* together a great business network.
-Fabric is a network of networks, like the Internet itself. An application can use one or more
-networks, each managing different :ref:`Assets`, Agreements and Transactions between different
-sets of :ref:`Member` s. In Fabric, the Ordering Service is the foundation of each network.
-The founder of a network selects an Ordering Service (or creates a new one) and passes in a
-config file with the rules (usually called Policies) that govern it. Examples of these rules
-include setting/defining which Members can join the network, how Members can be added or removed,
-and configuration details like block size. While it is possible for one company to set and control
-these rules as a "dictator," typically these rules will also include policies that make changing
-the rules a matter of consensus among the members of the network. Fabric also requires some level of
-"endorsement" in order to transact. Check out the power and intricacy of :doc:`endorsement-policies`
-, which are used across the Fabric landscape - from a consortium's network configuration to a simple
+Fabric is a network of networks, like the Internet itself. An application can use one or more
+networks, each managing different :ref:`Assets`, Agreements and Transactions between different
+sets of :ref:`Member` s. In Fabric, the Ordering Service is the foundation of each network.
+The founder of a network selects an Ordering Service (or creates a new one) and passes in a
+config file with the rules (usually called Policies) that govern it. Examples of these rules
+include setting/defining which Members can join the network, how Members can be added or removed,
+and configuration details like block size. While it is possible for one company to set and control
+these rules as a "dictator," typically these rules will also include policies that make changing
+the rules a matter of consensus among the members of the network. Fabric also requires some level of
+"endorsement" in order to transact. Check out the power and intricacy of :doc:`endorsement-policies`
+, which are used across the Fabric landscape - from a consortium's network configuration to a simple
read operation.
-We mentioned that the Ordering Service (OS) is the foundation of the network, and you're probably
-thinking, "It must do something beyond just ordering." Well you're right! All members and entities
-in the network will be tied to a higher level certificate authority, and this authority is defined
-within the configuration of the Ordering Service. As a result, the OS can verify and authenticate
-transactions arriving from any corner of the network. The OS plays a central and critical role in
-the functionality and integrity of the network, and skeptics might fear too much centralization of
-power and responsibility. After all, that's a principal feature of shared ledger technology - to
-decentralize the control and provide a foundation of trust with entities who you CAN'T wholeheartedly
-trust. Well let's assuage that fear. The OS is agnostic to transaction details; it simply orders on
-a first-come-first-serve basis and returns blocks to their corresponding channels. Perhaps more
-importantly though, control of the ordering service can be shared and co-administered by the
-participating members in the network. OR, if even that solution is untenable, then the OS can be
-hosted and maintained by a trusted third-party. Fabric is built upon a modular and pluggable
-architecture, so the only real decision for business networks is how to configure an OS to meet
-their requirements.
+We mentioned that the Ordering Service (OS) is the foundation of the network, and you're probably
+thinking, "It must do something beyond just ordering." Well you're right! All members and entities
+in the network will be tied to a higher level certificate authority, and this authority is defined
+within the configuration of the Ordering Service. As a result, the OS can verify and authenticate
+transactions arriving from any corner of the network. The OS plays a central and critical role in
+the functionality and integrity of the network, and skeptics might fear too much centralization of
+power and responsibility. After all, that's a principal feature of shared ledger technology - to
+decentralize the control and provide a foundation of trust with entities who you CAN'T wholeheartedly
+trust. Well let's assuage that fear. The OS is agnostic to transaction details; it simply orders on
+a first-come-first-serve basis and returns blocks to their corresponding channels. Perhaps more
+importantly though, control of the ordering service can be shared and co-administered by the
+participating members in the network. OR, if even that solution is untenable, then the OS can be
+hosted and maintained by a trusted third-party. Fabric is built upon a modular and pluggable
+architecture, so the only real decision for business networks is how to configure an OS to meet
+their requirements.
-(This notion of the OS as a pluggable component also opens the door to exciting opportunities for
-innovative teams and individuals. Currently there are only a few OS orchestrations - Solo and Kafka.
-However, other options such as Intel's PoET or BFT flavors could be powerful supplementaries to Fabric,
+(This notion of the OS as a pluggable component also opens the door to exciting opportunities for
+innovative teams and individuals. Currently there are only a few OS orchestrations - Solo and Kafka.
+However, other options such as Intel's PoET or BFT flavors could be powerful supplementaries to Fabric,
and help solve challenging use cases.)
-To participate in the Network, each Organization maintains a runtime called a :ref:`Peer`, which will
-allow an application to participate in Transactions, interact with the Ordering Service, and maintain
-a set of ledgers. Notice we said a set of ledgers. One of Fabric's key innovations is the ability to
-run multiple :ref:`Channel` s on each network. This is how a network can conduct both highly confidential
-bilateral transactions and multilateral, or even public, transactions in the same solution without
-everyone having a copy of every transaction or run the code in every agreement. Watch how Fabric is
+To participate in the Network, each Organization maintains a runtime called a :ref:`Peer`, which will
+allow an application to participate in Transactions, interact with the Ordering Service, and maintain
+a set of ledgers. Notice we said a set of ledgers. One of Fabric's key innovations is the ability to
+run multiple :ref:`Channel` s on each network. This is how a network can conduct both highly confidential
+bilateral transactions and multilateral, or even public, transactions in the same solution without
+everyone having a copy of every transaction or run the code in every agreement. Watch how Fabric is
Building a Blockchain for Business .
-If you're still reading, you clearly have some knowledge and an interest in distributed ledger
-technology, AND you probably think a key piece is missing. Where is consensus in all of this? Well,
-it's embedded in the entire life cycle of a transaction. Transactions come into the network, and the
-submitting client's identity is verified and consented upon. Transactions then get executed and endorsed,
-and these endorsements are consented upon. Transactions get ordered, and the validity of this order is
-consented upon. Finally, transactions get committed to a shared ledger, and each transaction's subsequent
-impact on the state of the involved asset(s) is consented upon. Consensus isn't pigeonholed into one
-module or one function. It lives and exists throughout the entire DNA of Fabric. Fabric is built
-with security at the forefront, not as an afterthought. Members and participating entities operate with
-known identities, no action on the network circumvents the sign/verify/authenticate mandate. Requirements
-such as security, privacy and confidentiality are paramount in some manner to nearly all business dealings,
-and they, like consensus, are stitched into the very essence of Fabric.
+If you're still reading, you clearly have some knowledge and an interest in distributed ledger
+technology, AND you probably think a key piece is missing. Where is consensus in all of this? Well,
+it's embedded in the entire life cycle of a transaction. Transactions come into the network, and the
+submitting client's identity is verified and consented upon. Transactions then get executed and endorsed,
+and these endorsements are consented upon. Transactions get ordered, and the validity of this order is
+consented upon. Finally, transactions get committed to a shared ledger, and each transaction's subsequent
+impact on the state of the involved asset(s) is consented upon. Consensus isn't pigeonholed into one
+module or one function. It lives and exists throughout the entire DNA of Fabric. Fabric is built
+with security at the forefront, not as an afterthought. Members and participating entities operate with
+known identities, no action on the network circumvents the sign/verify/authenticate mandate. Requirements
+such as security, privacy and confidentiality are paramount in some manner to nearly all business dealings,
+and they, like consensus, are stitched into the very essence of Fabric.
-So what problem do you want to solve? What assets are at stake? Who are the players? What levels of
-security and encryption do you need? Fabric is designed to provide an answer and solution to this
-challenging collective of questions and beyond. Just like fabric - in the literal sense of the word - is
-used in everything from airplane seats to bespoke suits, solutions built on Hyperledger Fabric can range
-from diamond provenance to equities trading. Explore the documentation and see how you can leverage Fabric
+So what problem do you want to solve? What assets are at stake? Who are the players? What levels of
+security and encryption do you need? Fabric is designed to provide an answer and solution to this
+challenging collective of questions and beyond. Just like fabric - in the literal sense of the word - is
+used in everything from airplane seats to bespoke suits, solutions built on Hyperledger Fabric can range
+from diamond provenance to equities trading. Explore the documentation and see how you can leverage Fabric
to craft a PoC for your own business network.
diff --git a/docs/source/chaincode.rst b/docs/source/chaincode.rst
index 3c59343a407..324cc4202fc 100644
--- a/docs/source/chaincode.rst
+++ b/docs/source/chaincode.rst
@@ -11,19 +11,19 @@ languages such as Go or Java. It is installed and instantiated through
an SDK or CLI onto a network of Hyperledger Fabric peer nodes, enabling
interaction with that network's shared ledger.
-There are three aspects to chaincode development:
+There are three aspects to chaincode development:
* Chaincode Interfaces
-* APIs
+* APIs
* Chaincode Responses
Chaincode interfaces
--------------------
A chaincode implements the Chaincode Interface that supports two
-methods:
+methods:
-* ``Init``
+* ``Init``
* ``Invoke``
Init()
@@ -45,10 +45,10 @@ Dependencies
------------
The import statement lists a few dependencies for the chaincode to
-compile successfully.
+compile successfully.
* fmt – contains ``Println`` for debugging/logging.
-* errors – standard go error format.
+* errors – standard go error format.
* `shim `__ – contains the definitions for the chaincode interface and the chaincode stub, which are required to interact with the ledger.
Chaincode APIs
@@ -80,7 +80,7 @@ The chaincode response comes in the form of a protobuffer.
.. code:: go
- message Response {
+ message Response {
// A status code that should follow the HTTP status codes.
int32 status = 1;
@@ -98,22 +98,22 @@ events.
.. code:: go
- messageEvent {
+ messageEvent {
oneof Event {
- //Register consumer sent event
+ //Register consumer sent event
Register register = 1;
- //producer events common.
- Block block = 2;
- ChaincodeEvent chaincodeEvent = 3;
+ //producer events common.
+ Block block = 2;
+ ChaincodeEvent chaincodeEvent = 3;
Rejection rejection = 4;
- //Unregister consumer sent events
- Unregister unregister = 5;
+ //Unregister consumer sent events
+ Unregister unregister = 5;
- }
+ }
}
@@ -121,9 +121,9 @@ events.
messageChaincodeEvent {
- string chaincodeID = 1;
- string txID = 2;
- string eventName = 3;
+ string chaincodeID = 1;
+ string txID = 2;
+ string eventName = 3;
bytes payload = 4;
}
diff --git a/docs/source/included.rst b/docs/source/included.rst
index 50fb2e8fd2a..3295fd5ff92 100644
--- a/docs/source/included.rst
+++ b/docs/source/included.rst
@@ -2,28 +2,28 @@ What's Offered?
================
The getting started example uses Docker images to generate the Fabric
-network components. The scenario includes a consortium of three
+network components. The scenario includes a consortium of three
members, each managing and maintaing a peer node, as well as a "SOLO"
:ref:`Ordering-Service` and a Certificate Authority (CA). The cryptographic identity
material, based on standard PKI implementation, has been pre-generated
-and is used for signing + verification on both the server (peer + ordering service)
+and is used for signing + verification on both the server (peer + ordering service)
and client (SDK) sides. The CA is the network entity responsible for issuing
-and maintaing this identity material, which is necessary for authentication by all
+and maintaing this identity material, which is necessary for authentication by all
components and participants on the network. This sample uses a single CA. However,
in enterprise scenarios each :ref:`Member` would likely have their own CA, with more
complex security/identity measures implemented - e.g. cross-signing certificates, etc.
-The members will transact on a private channel, with a shared ledger maintained by
+The members will transact on a private channel, with a shared ledger maintained by
each peer node. Requests to read and write data to/from the ledger are sent
as "proposals" to the peers. These proposals are in fact a request for endorsement
-from the peer, which will execute the transaction and return a response to the
-submitting client.
+from the peer, which will execute the transaction and return a response to the
+submitting client.
-The sample demonstrates two methods for interacting with the network - a programmatical
+The sample demonstrates two methods for interacting with the network - a programmatical
approach exercising the Node.js SDK APIs and a CLI requiring manual commands.
-It's recommended to follow the sample in the order laid forth - application first,
-followed by the optional CLI route.
+It's recommended to follow the sample in the order laid forth - application first,
+followed by the optional CLI route.
diff --git a/docs/source/ledger.rst b/docs/source/ledger.rst
index 69edd74e495..b5230bd4623 100644
--- a/docs/source/ledger.rst
+++ b/docs/source/ledger.rst
@@ -65,8 +65,8 @@ database. If the data that was read has been changed by another transaction, the
transaction in the block is marked as invalid and is not applied to the ledger state database.
The client application is alerted, and can handle the error or retry as appropriate.
-See the :doc:`txflow` and :doc:`readwrite` topics for a deeper dive on transaction structure,
-concurrency control, and the state DB.
+See the :doc:`txflow` and :doc:`readwrite` topics for a deeper dive on transaction structure,
+concurrency control, and the state DB.
State Database options
----------------------
diff --git a/docs/source/license.rst b/docs/source/license.rst
index 53ac460a7b1..86bb7eb5a81 100644
--- a/docs/source/license.rst
+++ b/docs/source/license.rst
@@ -1,4 +1,4 @@
-License
+License
========
The Hyperledger Project uses the `Apache License Version
diff --git a/docs/source/nodesdk.rst b/docs/source/nodesdk.rst
index 922f3102202..01f44c79c81 100644
--- a/docs/source/nodesdk.rst
+++ b/docs/source/nodesdk.rst
@@ -12,4 +12,4 @@ OR
Refer to the
`fabric-sdk-node `__
repository in the Hyperledger community. The README will take you through
-a simple setup to build HTML output for the API classes and methods.
+a simple setup to build HTML output for the API classes and methods.
diff --git a/docs/source/orderingservice.rst b/docs/source/orderingservice.rst
index 48de2923c83..71abbeb373f 100644
--- a/docs/source/orderingservice.rst
+++ b/docs/source/orderingservice.rst
@@ -5,8 +5,8 @@ Ordering Service
This topic will outline the role and functionalities of the ordering
service, and explain its place in the broader network and in the lifecycle of a transaction.
-The v1 architecture has been designed such that the ordering service is the centralized point
-of trust in a decentralized network, but also such that the specific implementation of "ordering"
+The v1 architecture has been designed such that the ordering service is the centralized point
+of trust in a decentralized network, but also such that the specific implementation of "ordering"
(solo, kafka, BFT) becomes a pluggable component.
Refer to the design document on a `Kafka-based Ordering
diff --git a/docs/source/txflow.rst b/docs/source/txflow.rst
index f68278aa5d7..33857252e1b 100644
--- a/docs/source/txflow.rst
+++ b/docs/source/txflow.rst
@@ -3,8 +3,8 @@ Transaction Flow
This document outlines the transactional mechanics that take place during a standard asset
exchange. The scenario includes two clients, A and B, who are buying and selling
-radishes. They each have a peer on the network through which they send their
-transactions and interact with the ledger.
+radishes. They each have a peer on the network through which they send their
+transactions and interact with the ledger.
.. image:: images/step0.png
@@ -27,16 +27,16 @@ any transaction.
1. **Client A initiates a transaction**
What's happening? - Client A is sending a request to purchase radishes. The
-request targets ``peerA`` and ``peerB``, who are respectively representative of
-Client A and Client B. The endorsement policy states that both peers must endorse
+request targets ``peerA`` and ``peerB``, who are respectively representative of
+Client A and Client B. The endorsement policy states that both peers must endorse
any transaction, therefore the request goes to ``peerA`` and ``peerB``.
Next, the transaction proposal is constructed. An application leveraging a supported
SDK (node, java, python) utilizes one of the available API's which generates a
transaction proposal. The proposal is a request to invoke a chaincode function
so that data can be read and/or written to the ledger (i.e. write new key value
-pairs for the assets). The SDK serves as a shim to package the transaction proposal
-into the properly architected format (protocol buffer over gRPC) and takes the user’s
+pairs for the assets). The SDK serves as a shim to package the transaction proposal
+into the properly architected format (protocol buffer over gRPC) and takes the user’s
cryptographic credentials to produce a unique signature for this transaction proposal.
.. image:: images/step2.png
@@ -102,5 +102,5 @@ notify the client application that the transaction (invocation) has been
immutably appended to the chain, as well as notification of whether the
transaction was validated or invalidated.
-**Note**: See the :ref:`swimlane` diagram to better understand the server side flow and the
+**Note**: See the :ref:`swimlane` diagram to better understand the server side flow and the
protobuffers.