-
-While confidential agreements are a key business case, there are many scenarios where contracts can and should be easily discoverable by all parties on a ledger. For example, a ledger used to create offers (asks) seeking bids, by definition, requires access without restriction. This type of contract may need to be standardized so that bidders can easily find them, effectively creating an electronic trading platform with smart contracts (aka chaincode).
-
-#### Persona
-
-* Contract participant – Contract counter parties
-
-* Third party participant – A third party stakeholder guaranteeing the integrity of the contract.
-
-#### Key Components
-
-* Multi-sig contract activation - When a contract is first deployed by one of the counter parties, it will be in the pending activation state. To activate a contract, signatures from other counterparties and/or third party participants are required.
-
-* Multi-sig contract execution - Some contracts will require one of many signatures to execute. For example, in trade finance, a payment instruction can only be executed if either the recipient or an authorized third party (e.g. UPS) confirms the shipment of the good.
-
-* Discoverability - If a contract is a business offer seeking bids, it must be easily searchable. In addition, such contracts must have the built-in intelligence to evaluate, select and honor bids.
-
-* Atomicity of contract execution - Atomicity of the contract is needed to guarantee that asset transfers can only occur when payment is received (Delivery vs. Payment). If any step in the execution process fails, the entire transaction must be rolled back.
-
-* Contract to chain-code communication - Contracts must be able to communicate with chaincodes that are deployed on the same ledger.
-
-* Longer Duration contract - Timer is required to support B2B contracts that have long execution windows.
-
-* Reuseable contracts - Often-used contracts can be standardized for reuse.
-
-* Auditable contractual agreement - Any contract can be made auditable to third parties.
-
-* Contract life-cycle management - B2B contracts are unique and cannot always be standardized. An efficient contract management system is needed to enhance the scalability of the ledger network.
-
-* Validation access – Only nodes with validation rights are allowed to validate transactions of a B2B contract.
-
-* View access – B2B contracts may include confidential information, so only accounts with predefined access rights are allowed to view and interrogate them.
-
-
-
-
-### Manufacturing Supply Chain
-
-Final assemblers, such as automobile manufacturers, can create a supply chain network managed by its peers and suppliers so that a final assembler can better manage its suppliers and be more responsive to events that would require vehicle recalls (possibly triggered by faulty parts provided by a supplier). The blockchain fabric must provide a standard protocol to allow every participant on a supply chain network to input and track numbered parts that are produced and used on a specific vehicle.
-
-Why is this specific example an abstract use case? Because while all blockchain cases store immutable information, and some add the need for transfer of assets between parties, this case emphasizes the need to provide deep searchability backwards through as many as 5-10 transaction layers. This backwards search capability is the core of establishing provenance of any manufactured good that is made up of other component goods and supplies.
-
-
-
-#### Persona
-
-* Final Assembler – The business entity that performs the final assembly of a product.
-
-* Part supplier – Supplier of parts. Suppliers can also be assemblers by assembling parts that they receive from their sub-suppliers, and then sending their finished product to the final (root) assembler.
-
-#### Key Components
-
-* Payment upon delivery of goods - Integration with off-chain payment systems is required, so that payment instructions can be sent when parts are received.
-
-* Third party Audit - All supplied parts must be auditable by third parties. For example, regulators might need to track the total number of parts supplied by a specific supplier, for tax accounting purposes.
-
-* Obfuscation of shipments - Balances must be obfuscated so that no supplier can deduce the business activities of any other supplier.
-
-* Obfuscation of market size - Total balances must be obfuscated so that part suppliers cannot deduce their own market share to use as leverage when negotiating contractual terms.
-
-* Validation Access – Only nodes with validation rights are allowed to validate transactions (shipment of parts).
-
-* View access – Only accounts with view access rights are allowed to interrogate balances of shipped parts and available parts.
-
-
-
-
-### Asset Depository
-
-Assets such as financial securities must be able to be dematerialized on a blockchain network so that all stakeholders of an asset type will have direct access to that asset, allowing them to initiate trades and acquire information on an asset without going through layers of intermediaries. Trades should be settled in near real time and all stakeholders must be able to access asset information in near real time. A stakeholder should be able to add business rules on any given asset type, as one example of using automation logic to further reduce operating costs.
-
-
-#### Persona
-
-* Investor – Beneficial and legal owner of an asset.
-
-* Issuer – Business entity that issued the asset which is now dematerialized on the ledger network.
-
-* Custodian – Hired by investors to manage their assets, and offer other value-add services on top of the assets being managed.
-
-* Securities Depository – Depository of dematerialized assets.
-
-#### Key Components
-
-* Asset to cash - Integration with off-chain payment systems is necessary so that issuers can make payments to and receive payments from investors.
-
-* Reference Rate - Some types of assets (such as floating rate notes) may have attributes linked to external data (such as reference rate), and such information must be fed into the ledger network.
-
-* Asset Timer - Many types of financial assets have predefined life spans and are required to make periodic payments to their owners, so a timer is required to automate the operation management of these assets.
-
-* Asset Auditor - Asset transactions must be made auditable to third parties. For example, regulators may want to audit transactions and movements of assets to measure market risks.
-
-* Obfuscation of account balances - Individual account balances must be obfuscated so that no one can deduce the exact amount that an investor owns.
-
-* Validation Access – Only nodes with validation rights are allowed to validate transactions that update the balances of an asset type (this could be restricted to CSD and/or the issuer).
-
-* View access – Only accounts with view access rights are allowed to 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.
-
-
-
-
-# Extended Use Cases
-
-The following extended use cases examine additional requirements and scenarios.
-
-### One Trade, One Contract
-
-From the time that a trade is captured by the front office until the trade is finally settled, only one contract that specifies the trade will be created and used by all participants. The middle office will enrich the same electronic contract submitted by the front office, and that same contract will then be used by counter parties to confirm and affirm the trade. Finally, securities depository will settle the trade by executing the trading instructions specified on the contract. When dealing with bulk trades, the original contract can be broken down into sub-contracts that are always linked to the original parent contract.
-
-
-
-
-
-### Direct Communication
-
-Company A announces its intention to raise 2 Billion USD by way of rights issue. Because this is a voluntary action, Company A needs to ensure that complete details of the offer are sent to shareholders in real time, regardless of how many intermediaries are involved in the process (such as receiving/paying agents, CSD, ICSD, local/global custodian banks, asset management firms, etc). Once a shareholder has made a decision, that decision will also be processed and settled (including the new issuance of shares) in real time. If a shareholder sold its rights to a third party, the securities depository must be able to record the new shares under the name of their new rightful owner.
-
-
-
-
-
-### Separation of Asset Ownership and Custodian’s Duties
-
-Assets should always be owned by their actual owners, and asset owners must be able to allow third-party professionals to manage their assets without having to pass legal ownership of assets to third parties (such as nominee or street name entities). If issuers need to send messages or payments to asset owners (for example, listed share holders), issuers send them directly to asset owners. Third-party asset managers and/or custodians can always buy, sell, and lend assets on behalf of their owners. Under this arrangement, asset custodians can focus on providing value-add services to shareowners, without worrying about asset ownership duties such as managing and redirecting payments from issuers to shareowners.
-
-
-
-
-
-### Interoperability of Assets
-
-If an organization requires 20,000 units of asset B, but instead owns 10,000 units of asset A, it needs a way to exchange asset A for asset B. Though the current market might not offer enough liquidity to fulfill this trade quickly, there might be plenty of liquidity available between asset A and asset C, and also between asset C and asset B. Instead of settling for market limits on direct trading (A for B) in this case, a chain network connects buyers with "buried" sellers, finds the best match (which could be buried under several layers of assets), and executes the transaction.
-
-
diff --git a/docs/blockchain.md b/docs/blockchain.md
deleted file mode 100644
index 2f1515d5a79..00000000000
--- a/docs/blockchain.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Why blockchain?
-
-...coming soon
diff --git a/docs/bootstrap.md b/docs/bootstrap.md
deleted file mode 100644
index 9c62d74fe2a..00000000000
--- a/docs/bootstrap.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Starting a network
-
-[WIP]
-...coming soon
-
-Intended to contain the recommended steps for generating prerequisite cryptographic
-material and then bootstrapping an ordering service (i.e. overall network) with
-participating organizations, ordering node certificates, load balancing, configuration,
-policies, etc...
diff --git a/docs/carlease.md b/docs/carlease.md
deleted file mode 100644
index 4146668448b..00000000000
--- a/docs/carlease.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Car Lease
-
-[WIP]
-...coming soon
-
-Uses the blockchain to record the lifecycle of a vehicle from materials provenance,
-manufacture, buyer, all the way to scrap yard. Not yet stable with v1 codebase.
-
-Learn more about the application and underlying chaincode [here](https://github.com/IBM-Blockchain/car-lease-demo)
diff --git a/docs/chaincode.md b/docs/chaincode.md
deleted file mode 100644
index 5b1b69cee6b..00000000000
--- a/docs/chaincode.md
+++ /dev/null
@@ -1,343 +0,0 @@
-# What is chaincode?
-
-[WIP]
-
-coming soon ... end-to-end examples of chaincode demonstrating the available
-APIs.
-
-Chaincode is a piece of code that is written in one of the supported 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:
-* The interfaces that the chaincode should implement
-* APIs the chaincode can use to interact with the Fabric
-* A chaincode response
-
-## Chaincode interfaces
-
-A chaincode implements the Chaincode Interface that supports two methods:
-* `Init`
-* `Invoke`
-
-#### Init()
-
-Init is called when you first deploy your chaincode. As the name implies, this
-function is used to do any initialization your chaincode needs.
-
-#### Invoke()
-
-Invoke is called when you want to call chaincode functions to do real work (i.e. read
-and write to the ledger). Invocations are captured as transactions, which get
-grouped into blocks on the chain. When you need to update or query the ledger,
-you do so by invoking your chaincode.
-
-## Dependencies
-
-The import statement lists a few dependencies for the chaincode to compile successfully.
-* fmt – contains Println for debugging/logging.
-* errors – standard go error format.
-* [shim](https://github.com/hyperledger/fabric/tree/master/core/chaincode/shim) –
-contains the definitions for the chaincode interface and the chaincode stub,
-which you are required to interact with the ledger.
-
-## Chaincode APIs
-
-When the Init or Invoke function of a chaincode is called, the fabric passes the
-`stub shim.ChaincodeStubInterface` parameter and the chaincode returns a `pb.Response`.
-This stub can be used to call APIs to access to the ledger services, transaction
-context, or to invoke other chaincodes.
-
-The current APIs are defined in the shim package, and can be generated with the
-following command:
-```bash
-godoc github.com/hyperledger/fabric/core/chaincode/shim
-```
-However, it also includes functions from chaincode.pb.go (protobuffer functions)
-that are not intended as public APIs. The best practice is to look at the function
-definitions in chaincode.go and and the
-[examples](https://github.com/hyperledger/fabric/tree/master/examples/chaincode/go)
-directory.
-
-## Response
-
-The chaincode response comes in the form of a protobuffer.
-
-```go
-message Response {
-
- // A status code that should follow the HTTP status codes.
- int32 status = 1;
-
- // A message associated with the response code.
- string message = 2;
-
- // A payload that can be used to include metadata with this response.
- bytes payload = 3;
-
-}
-```
-The chaincode will also return events. Message events and chaincode events.
-```go
-messageEvent {
-
- oneof Event {
-
- //Register consumer sent event
- Register register = 1;
-
- //producer events common.
- Block block = 2;
- ChaincodeEvent chaincodeEvent = 3;
- Rejection rejection = 4;
-
- //Unregister consumer sent events
- Unregister unregister = 5;
-
- }
-
-}
-```
-
-```go
-messageChaincodeEvent {
-
- string chaincodeID = 1;
- string txID = 2;
- string eventName = 3;
- bytes payload = 4;
-
-}
-```
-
-Once developed and deployed, there are two ways to interact with the chaincode -
-through an SDK or the CLI. The steps for CLI are described below. For SDK interaction,
-refer to the [balance transfer](https://github.com/hyperledger/fabric-sdk-node/tree/master/examples/balance-transfer)
-samples. __Note__: This SDK interaction is covered in the __Getting Started__ section.
-
-## Command Line Interfaces
-
-To view the currently available CLI commands, execute the following:
-```bash
-# this assumes that you have correctly set the GOPATH variable and cloned the Fabric codebase into that path
-cd /opt/gopath/src/github.com/hyperledger/fabric
-build /bin/peer
-```
-You will see output similar to the example below. (__NOTE__: rootcommand below is
-hardcoded in main.go. Currently, the build will create a _peer_ executable file).
-```bash
-Usage:
- peer [flags]
- peer [command]
-
- Available Commands:
- version Print fabric peer version.
- node node specific commands.
- channel channel specific commands.
- chaincode chaincode specific commands.
- logging logging specific commands
-
-
- Flags:
- --logging-level string: Default logging level and overrides, see core.yaml for full syntax
- --test.coverprofile string: Done (default “coverage.cov)
- -v, --version: Display current version of fabric peer server
- Use "peer [command] --help" for more information about a command.
-```
-The `peer` command supports several subcommands and flags, as shown above. To
-facilitate its use in scripted applications, the `peer` command always produces a
-non-zero return code in the event of command failure. Upon success, many of the
-subcommands produce a result on stdout as shown in the table below:
-
-| - -Command - - | - -- -stdout result in the event of success - - | - -
|---|---|
| - -version - - | - -- -String form of peer.version defined in core.yaml - - | - -
| - -node start - - | - -- -N/A - - | - -
| - -node status - - | - -- -String form of StatusCode - - | - -
| - -node stop - - | - -- -String form of StatusCode - - | - -
| - -chaincode deploy - - | - -- -The chaincode container name (hash) required for subsequent chaincode invoke and chaincode query commands - - | - -
| - -chaincode invoke - - | - -- -The transaction ID (UUID) - - | - -
| - -chaincode query - - | - -- -By default, the query result is formatted as a printable - - | - -
| - -channel create - - | - -- -Create a chain - - | - -
| - -channel join - - | - -- -Adds a peer to the chain - - | - -
-
---peer-defaultchain=true
-
- |
-
-- - Allows users to continue to work with the default TEST_CHAINID string. Command line options support writing this value as raw bytes (-r, –raw) or formatted as the hexadecimal representation of the raw bytes (-x, –hex). If the query response is empty then nothing is output. - - | - - -
 |
-
-An application follows a MVC-B architecture – Model, View, Control, BlockChain.
- - -
-For example, a Bluemix PaaS application using Node.js might have a Web front-end user interface or a native mobile app with backend model on Cloudant data service. The control logic may interact with 1 or more chaincodes to process transactions on the blockchain. - - |
-
|
-
-一个遵循MVC-B架构的应用– Model, View, Control, BlockChain.
- - -
- -例如，使用 Node.js 的一个 Bluemix PaaS 的应用程序可能有一个 Web 前端用户界面或与 Cloudant 数据服务后端模型中的原生移动应用。控制逻辑可以被 1 或多个链码交互以处理对区块链交易。 - - |
-
+Rocket Chat CI +StackOverflow +{% endblock %} diff --git a/docs/source/abstract_v1.rst b/docs/source/abstract_v1.rst new file mode 100644 index 00000000000..a10c98c77b9 --- /dev/null +++ b/docs/source/abstract_v1.rst @@ -0,0 +1,108 @@ +HYPERLEDGER FABRIC v1.0 +======================= + +Hyperledger Fabric is a platform that enables the delivery of a secure, +robust, permissioned blockchain for the enterprise that incorporates a +byzantine fault tolerant consensus. We have learned much as we +progressed through the v0.6-preview release. In particular, that in +order to provide for the scalability and confidentiality needs of many +use cases, a refactoring of the architecture was needed. The +v0.6-preview release will be the final (barring any bug fixes) release +based upon the original architecture. + +Hyperledger Fabric's v1.0 architecture has been designed to address two +vital enterprise-grade requirements – **security** and **scalability**. +Businesses and organizations can leverage this new architecture to +execute confidential transactions on networks with shared or common +assets – e.g. supply chain, FOREX market, healthcare, etc. The +progression to v1.0 will be incremental, with myriad windows for +community members to contribute code and start curating the fabric to +fit specific business needs. + +WHERE WE ARE: +------------- + +The current implementation involves every validating peer shouldering +the responsibility for the full gauntlet of network functionality. They +execute transactions, perform consensus, and maintain the shared ledger. +Not only does this configuration lay a huge computational burden on each +peer, hindering scalability, but it also constricts important facets of +privacy and confidentiality. Namely, there is no mechanism to “channel” +or “silo” confidential transactions. Every peer can see the most minute, +and at times, sensitive details and logic of every transaction. This is +untenable for many enterprise businesses, who must abide by stringent +regulatory statutes. + +WHERE WE'RE GOING +----------------- + +| The new architecture introduces a clear functional separation of peer + roles, and allows a transaction to pass through the network in a + structured and modularized fashion. +| The peers are diverged into two distinct roles – Endorser & Committer. + As an endorser, the peer will simulate the transaction and ensure that + the outcome is both deterministic and stable. As a committer, the peer + will validate the integrity of a transaction and then append to the + ledger. Now confidential transactions can be sent to specific + endorsers and their correlating committers, without the broader + network being made cognizant of the transaction. Additionally, + policies can be set to determine what levels of “endorsement” and + “validation” are acceptable for a specific class of transactions. +| A failure to meet these thresholds would simply result in a + transaction being withdrawn or labeled as "invalid", rather than + imploding or stagnating the entire network. +| This new model also introduces the possibility for more elaborate + networks, such as a foreign exchange market. For example, trade + settlement might be contingent upon a mandatory "endorsement" from a + trusted third party (e.g. a clearing house). + +| The consensus or "ordering" process (i.e. algorithmic computation) is + entirely abstracted from the peer. This modularity not only provides a + powerful security layer – the ordering nodes are agnostic to the + transaction logic – but it also generates a framework where ordering + can become a pluggable implementation and scalability can truly occur. +| There is no longer a parallel relationship between the number of peers + in a network and the number of orderers. Now networks can grow + dynamically (i.e. add endorsers and committers) without having to add + corresponding orderers, all the while existing in a modular + infrastructure designed to support high transaction throughput. + Moreover, networks now have the capability to completely liberate + themselves from the computational and legal burden of ordering by + tapping into a pre-existing or third party-hosted "ordering service." + +As v1.0 manifests, we will see the foundation for interoperable +blockchain networks that have the ability to scale and transact in a +manner adherent with regulatory and industry standards. Watch how fabric +v1.0 and the Hyperledger Project are building a true blockchain for +business - + +|HYPERLEDGERv1.0\_ANIMATION| + +HOW TO CONTRIBUTE +----------------- + +Use the following links to explore upcoming additions to the codebase +that will spawn the capabilities in v1.0: + +- Familiarize yourself with the `guidelines for code + contributions
| + +Command + +.. raw:: html + + | + +.. raw:: html + ++ +stdout result in the event of success + +.. raw:: html + + | + +.. raw:: html + +
|---|---|
| + +version + +.. raw:: html + + | + +.. raw:: html + ++ +String form of peer.version defined in core.yaml + +.. raw:: html + + | + +.. raw:: html + +
| + +node start + +.. raw:: html + + | + +.. raw:: html + ++ +N/A + +.. raw:: html + + | + +.. raw:: html + +
| + +node status + +.. raw:: html + + | + +.. raw:: html + ++ +String form of StatusCode + +.. raw:: html + + | + +.. raw:: html + +
| + +node stop + +.. raw:: html + + | + +.. raw:: html + ++ +String form of StatusCode + +.. raw:: html + + | + +.. raw:: html + +
| + +chaincode deploy + +.. raw:: html + + | + +.. raw:: html + ++ +The chaincode container name (hash) required for subsequent chaincode +invoke and chaincode query commands + +.. raw:: html + + | + +.. raw:: html + +
| + +chaincode invoke + +.. raw:: html + + | + +.. raw:: html + ++ +The transaction ID (UUID) + +.. raw:: html + + | + +.. raw:: html + +
| + +chaincode query + +.. raw:: html + + | + +.. raw:: html + ++ +By default, the query result is formatted as a printable + +.. raw:: html + + | + +.. raw:: html + +
| + +channel create + +.. raw:: html + + | + +.. raw:: html + ++ +Create a chain + +.. raw:: html + + | + +.. raw:: html + +
| + +channel join + +.. raw:: html + + | + +.. raw:: html + ++ +Adds a peer to the chain + +.. raw:: html + + | + +.. raw:: html + +
+
+.. raw:: html
+
+ --peer-defaultchain=true
+
+.. raw:: html
+
+ |
+
+.. raw:: html
+
+ + + Allows users to continue to work with the default TEST\_CHAINID string. +Command line options support writing this value as raw bytes (-r, –raw) +or formatted as the hexadecimal representation of the raw bytes (-x, +–hex). If the query response is empty then nothing is output. + +.. raw:: html + + | + +.. raw:: html + +