Oct 5, 2017

Transaction Flow in a Block-chain network

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.


Assumptions

This flow assumes that a channel is set up and running. The application user has registered and enrolled with the organization’s certificate authority (CA) and received back necessary cryptographic material, which is used to authenticate to the network.

The chaincode (containing a set of key value pairs representing the initial state of the radish market) is installed on the peers and instantiated on the channel. The chaincode contains logic defining a set of transaction instructions and the agreed upon price for a radish. An endorsement policy has also been set for this chaincode, stating that both peerA and peerB must endorse 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 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 cryptographic credentials to produce a unique signature for this transaction proposal.


2. Endorsing peers verify signature & execute the transaction

The endorsing peers verify (1) that the transaction proposal is well formed, (2) it has not been submitted already in the past (replay-attack protection), (3) the signature is valid (using MSP), and (4) that the submitter (Client A, in the example) is properly authorized to perform the proposed operation on that channel (namely, each endorsing peer ensures that the submitter satisfies the channel’s Writers policy). The endorsing peers take the transaction proposal inputs as arguments to the invoked chaincode’s function. The chaincode is then executed against the current state database to produce transaction results including a response value, read set, and write set. No updates are made to the ledger at this point. The set of these values, along with the endorsing peer’s signature is passed back as a “proposal response” to the SDK which parses the payload for the application to consume.

{The MSP is a peer component that allows them to verify transaction requests arriving from clients and to sign transaction results(endorsements). The Writing policy is defined at channel creation time, and determines which user is entitled to submit a transaction to that channel.}

3. Proposal responses are inspected

The application verifies the endorsing peer signatures and compares the proposal responses to determine if the proposal responses are the same. If the chaincode only queried the ledger, the application would inspect the query response and would typically not submit the transaction to Ordering Service. If the client application intends to submit the transaction to Ordering Service to update the ledger, the application determines if the specified endorsement policy has been fulfilled before submitting (i.e. did peerA and peerB both endorse). The architecture is such that even if an application chooses not to inspect responses or otherwise forwards an unendorsed transaction, the endorsement policy will still be enforced by peers and upheld at the commit validation phase.


4. Client assembles endorsements into a transaction

The application “broadcasts” the transaction proposal and response within a “transaction message” to the Ordering Service. The transaction will contain the read/write sets, the endorsing peers signatures and the Channel ID. The Ordering Service does not need to inspect the entire content of a transaction in order to perform its operation, it simply receives transactions from all channels in the network, orders them chronologically by channel, and creates blocks of transactions per channel.


5. Transaction is validated and committed

The blocks of transactions are “delivered” to all peers on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid.


6. Ledger updated

Each peer appends the block to the channel’s chain, and for each valid transaction the write sets are committed to current state database. An event is emitted, to 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.

(Source: http://hyperledger-fabric.readthedocs.io)

Hyperledger Fabric

Introduction

Hyperledger Fabric is a platform for distributed ledger solutions underpinned by a modular architecture delivering high degrees of confidentiality, resiliency, flexibility and scalability. It is designed to support pluggable implementations of different components and accommodate the complexity and intricacies that exist across the economic ecosystem.

Hyperledger Fabric delivers a uniquely elastic and extensible architecture, distinguishing it from alternative blockchain solutions. Planning for the future of enterprise blockchain requires building on top of a fully vetted, open-source architecture; 

What is a Blockchain?

A Distributed Ledger

At the heart of a blockchain network is a distributed ledger that records all the transactions that take place on the network.

A blockchain ledger is often described as decentralized because it is replicated across many network participants, each of whom collaborate in its maintenance. We’ll see that decentralization and collaboration are powerful attributes that mirror the way businesses exchange goods and services in the real world.



In addition to being decentralized and collaborative, the information recorded to a blockchain is append-only, using cryptographic techniques that guarantee that once a transaction has been added to the ledger it cannot be modified. This property of immutability makes it simple to determine the provenance of information because participants can be sure information has not been changed after the fact. It’s why blockchains are sometimes described as systems of proof.

Smart Contracts

To support the consistent update of information – and to enable a whole host of ledger functions (transacting, querying, etc) – a blockchain network uses smart contracts to provide controlled access to the ledger.


Smart contracts are not only a key mechanism for encapsulating information and keeping it simple across the network, they can also be written to allow participants to execute certain aspects of transactions automatically.

A smart contract can, for example, be written to stipulate the cost of shipping an item that changes depending on when it arrives. With the terms agreed to by both parties and written to the ledger, the appropriate funds change hands automatically when the item is received.

Consensus

The process of keeping the ledger transactions synchronized across the network – to ensure that ledgers only update when transactions are approved by the appropriate participants, and that when ledgers do update, they update with the same transactions in the same order – is called consensus.


We’ll learn a lot more about ledgers, smart contracts and consensus later. For now, it’s enough to think of a blockchain as a shared, replicated transaction system which is updated via smart contracts and kept consistently synchronized through a collaborative process called consensus.

Why is a Blockchain useful?


Today’s Systems of Record

The transactional networks of today are little more than slightly updated versions of networks that have existed since business records have been kept. The members of a Business Networktransact with each other, but they maintain separate records of their transactions. And the things they’re transacting – whether it’s Flemish tapestries in the 16th century or the securities of today – must have their provenance established each time they’re sold to ensure that the business selling an item possesses a chain of title verifying their ownership of it.

What you’re left with is a business network that looks like this:


Modern technology has taken this process from stone tablets and paper folders to hard drives and cloud platforms, but the underlying structure is the same. Unified systems for managing the identity of network participants do not exist, establishing provenance is so laborious it takes days to clear securities transactions (the world volume of which is numbered in the many trillions of dollars), contracts must be signed and executed manually, and every database in the system contains unique information and therefore represents a single point of failure.

It’s impossible with today’s fractured approach to information and process sharing to build a system of record that spans a business network, even though the needs of visibility and trust are clear.

The Blockchain Difference

What if instead of the rat’s nest of inefficiencies represented by the “modern” system of transactions, business networks had standard methods for establishing identity on the network, executing transactions, and storing data? What if establishing the provenance of an asset could be determined by looking through a list of transactions that, once written, cannot be changed, and can therefore be trusted?

That business network would look more like this:


This is a blockchain network. Every participant in it has their own replicated copy of the ledger. In addition to ledger information being shared, the processes which update the ledger are also shared. Unlike today’s systems, where a participant’s private programs are used to update their private ledgers, a blockchain system has shared programs to update shared ledgers.

With the ability to coordinate their business network through a shared ledger, blockchain networks can reduce the time, cost, and risk associated with private information and processing while improving trust and visibility.

You now know what blockchain is and why it’s useful. There are a lot of other details that are important, but they all relate to these fundamental ideas of the sharing of information and processes.

What is Hyperledger Fabric?

The Linux Foundation founded Hyperledger in 2015 to advance cross-industry blockchain technologies. Rather than declaring a single blockchain standard, it encourages a collaborative approach to developing blockchain technologies via a community process, with intellectual property rights that encourage open development and the adoption of key standards over time.

Hyperledger Fabric is one of the blockchain projects within Hyperledger. Like other blockchain technologies, it has a ledger, uses smart contracts, and is a system by which participants manage their transactions.

Where Hyperledger Fabric breaks from some other blockchain systems is that it is private and permissioned. Rather than an open permissionless system that allows unknown identities to participate in the network (requiring protocols like Proof of Work to validate transactions and secure the network), the members of a Hyperledger Fabric network enroll through a Membership Service Provider (MSP).

Hyperledger Fabric also offers several pluggable options. Ledger data can be stored in multiple formats, consensus mechanisms can be switched in and out, and different MSPs are supported.

Hyperledger Fabric also offers the ability to create channels, allowing a group of participants to create a separate ledger of transactions. This is an especially important option for networks where some participants might be competitors and not want every transaction they make - a special price they’re offering to some participants and not others, for example - known to every participant. If two participants form a channel, then those participants – and no others – have copies of the ledger for that channel.

Shared Ledger

Hyperledger Fabric has a ledger subsystem comprising two components: the world state and the transaction log. Each participant has a copy of the ledger to every Hyperledger Fabric network they belong to.

The world state component describes the state of the ledger at a given point in time. It’s the database of the ledger. The transaction log component records all transactions which have resulted in the current value of the world state. It’s the update history for the world state. The ledger, then, is a combination of the world state database and the transaction log history.

The ledger has a replaceable data store for the world state. By default, this is a LevelDB key-value store database. The transaction log does not need to be pluggable. It simply records the before and after values of the ledger database being used by the blockchain network.

Smart Contracts

Hyperledger Fabric smart contracts are written in chaincode and are invoked by an application external to the blockchain when that application needs to interact with the ledger. In most cases chaincode only interacts with the database component of the ledger, the world state (querying it, for example), and not the transaction log.

Chaincode can be implemented in several programming languages. The currently supported chaincode language is Go with support for Java and other languages coming in future releases.

Privacy

Depending on the needs of a network, participants in a Business-to-Business (B2B) network might be extremely sensitive about how much information they share. For other networks, privacy will not be a top concern.

Hyperledger Fabric supports networks where privacy (using channels) is a key operational requirement as well as networks that are comparatively open.

Consensus

Transactions must be written to the ledger in the order in which they occur, even though they might be between different sets of participants within the network. For this to happen, the order of transactions must be established and a method for rejecting bad transactions that have been inserted into the ledger in error (or maliciously) must be put into place.

This is a thoroughly researched area of computer science, and there are many ways to achieve it, each with different trade-offs. For example, PBFT (Practical Byzantine Fault Tolerance) can provide a mechanism for file replicas to communicate with each other to keep each copy consistent, even in the event of corruption. Alternatively, in Bitcoin, ordering happens through a process called mining where competing computers race to solve a cryptographic puzzle which defines the order that all processes subsequently build upon.

Hyperledger Fabric has been designed to allow network starters to choose a consensus mechanism that best represents the relationships that exist between participants. As with privacy, there is a spectrum of needs; from networks that are highly structured in their relationships to those that are more peer-to-peer.

(Source: http://hyperledger-fabric.readthedocs.io)

Sep 25, 2017

Blockchain basics: Glossary and use cases ( from IBM)

"Get to know this game-changing technology and how to start using it."

Blocks and blockchain networks

A blockchain is a type of distributed ledger that is shared across a business network. Business transactions are permanently recorded in sequential, append-only, tamper-evident blocks to the ledger. All the confirmed and validated transaction blocks are hash-linked from the genesis block to the most current block, hence the name blockchain.

A blockchain is thus a historical record of all the transactions that have taken place since the beginning of the blockchain in the network. The blockchain serves as a single source of truth for the network.

A blockchain network can be either permissioned or permissionless. Permissionless networks are open to any participant, and transactions are verified against the pre-existing rules of the network. Any participant can view transactions on the ledger, even if participants are anonymous. Bitcoin is the most familiar example of a blockchain network that is permissionless and public.

Permissioned networks, on the other hand, are usually private and are limited to participants within a given business network. On permissioned blockchains, participants are allowed to view only the transactions relevant to them. Hyperledger is a collaborative effort, hosted by the Linux Foundation, to support the development of permissioned blockchains for business.

Distributed ledgers

A distributed ledger is a type of database, or system of record, that is shared, replicated, and synchronized among the members of a network. The distributed ledger records the transactions, such as the exchange of assets or data, among the participants in the network. This shared ledger eliminates the time and expense of reconciling disparate ledgers.

Participants in the network govern and agree by consensus on the updates to the records in the ledger. No central, third-party mediator, such as a bank or government, is involved. Every record in the distributed ledger has a timestamp and unique cryptographic signature, thus making the ledger an auditable history of all transactions in the network.

One implementation of distributed ledger technology is the open source Hyperledger Fabric blockchain, which is one of several open source projects hosted by The Linux Foundation.

Participants

A blockchain network for business is a collectively owned peer-to-peer network that is operated by a group of identifiable and verifiable participants. Participants may be individuals or institutions, such as a business, university, or hospital, for example.

Assets, transactions, and channels

Anything that can be owned or controlled to produce value is an asset. Assets can be tangible (such as a car or farm-fresh peaches) or intangible (such as a mortgage or patent). A transaction is an asset transfer onto or off of the ledger. In a Hyperledger Fabric blockchain, assets are represented as a collection of key-value pairs (for example, vehicleOwner=Daisy) in binary or JSON form, or both.
In a Hyperledger Fabric blockchain, a channel is a private "subnet" of communication between two or more specific network members, for the purpose of conducting private and confidential transactions. If two participants form a channel, then those participants — and no others — must be authenticated and authorized to transact on that channel and share copies of the ledger for that channel. Thanks to channels, the network members who need private and confidential transactions can coexist on the same blockchain network with their business competitors and other restricted members.

Consensus

Consensus is the collaborative process that the members of a blockchain business network use to agree that a transaction is valid and to keep the ledger consistently synchronized. Consensus mechanisms lower the risk of fraudulent transactions, because tampering with transactions added to the ledger would have to occur across many places at the same time.

To reach consensus, participants agree to the transaction and validate it before it is permanently recorded in the ledger. Participants can also establish rules to verify transactions. No one, not even a system administrator, can delete a transaction that has been added to the ledger. A trusted network of participants reduces the costs of establishing consensus, relative to the higher costs present in permissionless blockchains.

In a business blockchain, a wide variety of consensus mechanisms are available to choose from. Where trust is high, a simple majority voting may suffice, or the network may choose to use a more sophisticated method.

Smart contracts and chaincode

Smart contracts govern interactions with the ledger, and they can allow network participants to execute certain aspects of transactions automatically. For example, a smart contract could stipulate the cost of shipping an item that changes depending on when it arrives. With the terms agreed to by both parties and written to the ledger, the appropriate funds change hands automatically when the item is received.

In the context of Hyperledger Fabric, smart contracts are written into chaincode, and the terms are considered essentially synonymous.

in Hyperledger Fabric, chaincode is a piece of code, written in Go, that defines the network assets and the transaction instructions (business logic) for modifying the assets. Chaincode is installed and instantiated onto a channel by an appropriately authorized member. When a transaction is invoked in that channel, a function in chaincode reads and writes values to the ledger.

Blockchain applications

A blockchain application requires three interdependent components: the user-facing application, the smart contract, and the ledger.
The top layer is the user-facing application that meets the needs of the network participants. The application lets users invoke smart contracts that trigger transactions in the business network. The smart contract encapsulates the business logic of the network: assets, ownership, and transfers. Each invocation of a smart contract creates a transaction in the network and updates the ledger. The ledger holds the current value of smart contract data (for example, vehicleOwner=Daisy), and is distributed across the network.

Blockchain use cases

To determine whether your use case is a good fit for blockchain, ask yourself these questions:
  • Is a business network involved?
  • Is consensus used to validate transactions?
  • Is an audit trail, or provenance, required?
  • Must the record of transactions be immutable, or tamper proof?
  • Should dispute resolution be final?
If you answered yes to the first question and to at least one other, then your use case would benefit from blockchain technology. A network always needs to be involved for blockchain to be the right solution, but the network can take many forms. The network can be between organizations, such as a supply chain, or the network can be within an organization. Within an organization, a blockchain network could be used to share reference data between divisions or to create an audit or compliance network, for example. The network can also exist between individuals, who might need to store data, digital assets, or contracts on the blockchain, for example.

Here's just a sampling of its infinite possibilities:

Internet of Things

  • Freight transportation: Move freight with multiple transportation companies, ensuring transparency and timely delivery
  • Component tracking and compliance: Store provenance records for original and replacement parts for fleet maintenance
  • Log operational maintenance data: Store operational and maintenance records for sharing among business partners or for regulatory purposes

Identity management

  • Build a trusted digital identity
  • Supply chain
  • Improve traceability, transparency, and efficiency in the food safety network

Financial services

  • Know Your Customer: Access to trusted up-to-date information on customers improves the accuracy of customer services in financial institutions
  • Clearing and settlement: Real-time point-to-point transfer of funds between financial institutions accelerates settlement
  • More examples: Letters of credit, Corporate debts and bonds, Trading platforms, Payment remittance, Repurchase agreements, and Foreign exchange

Healthcare

  • Electronic medical records
  • Virus banks
  • Doctor-vendor RFP services and assurance contracts
  • Blockchain health research commons
  • Blockchain health notaries

Insurance

  • Claims processing
  • P2P insurance
  • Ownership titles
  • Sales and underwriting

Government

  • Government tender processes
  • Voting
  • Taxes

Gaming

Music

(Source: https://www.ibm.com)