Skip to content

Commit 46649a1

Browse files
docs: add arch overview and refactor home page
refactor documentation for v1.0 to add in architecture overview and link to the system architecture. edited with Nick and Murali's comments. Addressed kostas comments fix mkdocs.yml address Gari's comments Change-Id: Id637f355de6b6cfe67336e5d80e7d9b69c311783 Signed-off-by: Christopher Ferris <[email protected]>
1 parent f1674db commit 46649a1

7 files changed

+682
-197
lines changed

docs/CONTRIBUTING.md

+26-2
Original file line numberDiff line numberDiff line change
@@ -78,6 +78,14 @@ the `lf-sandbox`
7878
you should be ready to set up your local development
7979
[environment](dev-setup/devenv.md).
8080

81+
Next, try [building the project](dev-setup/build.md) in your local development
82+
environment to ensure that everything is set up correctly.
83+
84+
[Logging control](Setup/logging-control.md) describes how to tweak the logging
85+
levels of various components within the Fabric. Finally, every source file
86+
needs to include a [license header](dev-setup/headers.txt): modified to include
87+
a copyright statement for the principle author(s).
88+
8189
## What makes a good change request?
8290

8391
* One change at a time. Not five, not three, not ten. One and only one. Why?
@@ -138,8 +146,24 @@ getting it merged and adds more work for you - to remediate the merge conflicts.
138146

139147
## Coding guidelines
140148

141-
Be sure to check out the language-specific [style guides](Style-guides/go-style.md)
142-
before making any changes. This will ensure a smoother review.
149+
Be sure to check out the language-specific
150+
[style guides](Style-guides/go-style.md) before making any changes. This will
151+
ensure a smoother review.
152+
153+
## Communication <a name="communication"></a>
154+
155+
We use [RocketChat](https://chat.hyperledger.org/) for communication and
156+
Google Hangouts&trade; for screen sharing between developers. Our development
157+
planning and prioritization is done in [JIRA](https://jira.hyperledger.org),
158+
and we take longer running discussions/decisions to the
159+
[mailing list](http://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric).
160+
161+
## Maintainers
162+
163+
The project's [maintainers](MAINTAINERS.md) are responsible for reviewing and
164+
merging all patches submitted for review and they guide the over-all technical
165+
direction of the project within the guidelines established by the Hyperledger
166+
Project's Technical Steering Committee (TSC).
143167

144168
### Becoming a maintainer
145169

docs/arch-deep-dive.md

+369
Large diffs are not rendered by default.

docs/architecture.md

+99
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
Hyperledger Fabric is a unique implementation of distributed ledger technology
2+
(DLT) that ensures data integrity and consistency while delivering
3+
accountability, transparency, and efficiencies unmatched by other blockchain
4+
or DLT technology.
5+
6+
Hyperledger Fabric implements a specific type of
7+
[permissioned](glossary.md#permissioned-network)
8+
[blockchain network](glossary.md#blockchain-network) on which members can
9+
track, exchange and interact with digitized assets using
10+
[transactions](glossary.md#transactions) that are governed by smart
11+
contracts - what we call [chaincode](glossary.md#chaincode) - in a secure and
12+
robust manner while enabling [participants](glossary.md#participants) in the
13+
network to interact in a manner that ensures that their transactions and data
14+
can be restricted to an identified subset of network participants - something
15+
we call a [channel](glossary.md#channel).
16+
17+
The blockchain network supports the ability for members to establish
18+
shared ledgers that contain the source of truth about those digitized
19+
assets, and recorded transactions, that is replicated in a secure manner only
20+
to the set of nodes participating in that channel.
21+
22+
The Hyperledger Fabric architecture is comprised of the following components:
23+
peer nodes, ordering nodes and the clients applications that are likely
24+
leveraging one of the language-specific Fabric SDKs. These components have
25+
identities derived from certificate authorities. Hyperledger Fabric also
26+
offers a certificate authority service, *fabric-ca* but, you may substitute
27+
that with your own.
28+
29+
All peer nodes maintain the ledger/state by committing
30+
transactions. In that role, the peer is called a
31+
[committer](glossary.md#committer). Some peers are also responsible for
32+
simulating transactions by executing chaincodes (smart contracts) and endorsing
33+
the result. In that role the peer is called an [endorser](glossary.md#endorser).
34+
A peer may be an endorser for certain types of transactions and just a ledger
35+
maintainer (committer) for others.
36+
37+
The [orderers](glossary.md#orderer) consent on the order of transactions in a
38+
block to be committed to the ledger. In common blockchain architectures
39+
(including earlier versions of the Hyperledger Fabric) the roles played by
40+
the peer and orderer nodes were unified (cf. validating peer in Hyperledger
41+
Fabric v0.6). The orderers also play a fundamental role in the creation and
42+
management of channels.
43+
44+
Two or more [participants](glossary.md#participant) may create and join a
45+
channel, and begin to interact. Among other things, the policies governing the
46+
channel membership and chaincode lifecycle are specified at the time of
47+
channel creation. Initially, the members in a channel agree on
48+
the terms of the chaincode that will govern the transactions. When consensus
49+
is reached on the [proposal](glossary.md#proposal) to deploy a given chaincode
50+
(as governed by the life cycle policy for the channel), it is committed to
51+
the ledger.
52+
53+
Once the chaincode is deployed to the peer nodes in the channel,
54+
[end users](glossary.md#end-users) with the right privileges can propose
55+
transactions on the channel by using one of the language-specific client SDKs
56+
to invoke functions on the deployed chaincode.
57+
58+
The proposed transactions are sent to endorsers that execute the chaincode
59+
(also called "simulated the transaction"). On successful execution, endorse
60+
the result using the peer's identity and return the result to the client that
61+
initiated the proposal.
62+
63+
The client application ensures that the results from the endorsers are
64+
consistent and signed by the appropriate endorsers, according to the endorsement
65+
policy for that chaincode and, if so, the application then sends the transaction,
66+
comprised of the result and endorsements, to the ordering service.
67+
68+
Ordering nodes order the transactions - the result and endorsements received
69+
from the clients - into a block which is then sent to the peer nodes to be
70+
committed to the ledger. The peers then validate the transaction using the
71+
endorsement policy for the transaction's chaincode and against the ledger for
72+
consistency of result.
73+
74+
Some key capabilities of Hyperledger Fabric include:
75+
76+
- Allows for complex query for applications that need ability to handle complex
77+
data structures.
78+
79+
- Implements a permissioned network, also known as a consortia network, where
80+
all members are known to each other.
81+
82+
- Incorporates a modular approach to various capabilities, enabling network
83+
designers to plug in their preferred implementations for various capabilities
84+
such as consensus (ordering), identity management, and encryption.
85+
86+
- Provides a flexible approach for specifying policies and pluggable mechanisms
87+
to enforce them.
88+
89+
- Ability to have multiple channels, isolated from one another, that
90+
allows for multi-lateral transactions amongst select peer nodes, thereby
91+
ensuring high degrees of privacy and confidentiality required by competing
92+
businesses and highly regulated industries on a common network.
93+
94+
- Network scalability and performance are achieved through separation of
95+
chaincode execution from transaction ordering, which limits the required levels
96+
of trust and verification across nodes for optimization.
97+
98+
For a deeper dive into the details, please visit
99+
[this document](arch-deep-dive.md).

0 commit comments

Comments
 (0)