Developing Smart Contracts

In this and the following two chapters, we're going to tackle the task of smart contract and application programming in a business network that uses Hyperledger Fabric technology. Our first two chapters—this one and Chapter 7, Developing Applications, will explain how to perform the two major tasks a software developer needs to complete in order to implement a business network:

• Smart contract design and development
• Application design and development

Our third chapter, Chapter 8, Advanced Topics for Developing Smart Contracts and Applications, will introduce more advanced techniques that you'll find helpful as your requirements expand to support advanced privacy requirements typically found in real-world networks.

These chapters are not concerned with the management of the technical infrastructure of Hyperledger. While infrastructure components such as peers, ordering services, and certificate authorities are...

Business networks

As we learned in Chapter 3, Business Networks, a business network contains a collection of participants and assets that undergo a life cycle described by a series of transactions. We saw at a high level how Hyperledger Fabric provides a technology infrastructure to help implement a business network.

Let's examine the high-level structure of a business network, as shown in Figure 6.1:

Figure 6.1: Recalling a business network with four organizations and their participants

We see a business network involving four organizations. As we learned in Chapter 3, Business Networks, organizations are important because every participant that performs transactions in the network—whether an individual, system, or machine—is associated with an organization.

Figure 6.1 shows that organizations communicate with each other using a network channel. This is both simpler and more complex than it seems.

It's simpler because the network channel...

Solution application components

As we saw in Chapter 3, Business Networks, individual participants interact with a Hyperledger Fabric network using one or more applications. These are not the applications that run on a user's desktop or phone, or on the device or machine that wishes to transact in the network. Instead, we're going to look at the application that provides the APIs that these desktops, phones, devices, and machines use.

Let's have a look at the main application components in a Hyperledger Fabric network in Figure 6.2:

Figure 6.2: The four basic application components of a solution using Hyperledger Fabric

We can see that there are four major application components in a solution that uses Hyperledger Fabric. We're going to discuss these components in some detail during the next three chapters; let's briefly examine them now to give us a high-level map that will help us navigate.

The transaction ledger and multi-party transactions...

The multi-party transaction

At the heart of a business network implemented in Hyperledger Fabric is a multi-party transaction. This single idea allows us to understand the entire philosophy of Hyperledger Fabric, so it's right to spend a little time making sure we fully grasp this concept.

The good news is that a multi-party transaction is a powerfully simple idea. As we explained in Chapter 3, Business Networks, a multi-party transaction describes the change in a set of business objects involving two or more participants.

In the following code, we can see an example of a multi-party transaction that describes the transfer of a car between two participants: Sara Seller and Bob Buyer (we've given them alliterative names to help us recall their roles):

car transfer transaction:
 identifier: 1234567890
 proposal: 
  input: {CAR1, Sara Seller, Bob Buyer}
  signature: input signed by Sara Seller
 response: 
  output: 
    {CAR1.currentOwner = Sara Seller, 
     CAR1...

The ledger

With our solid grasp of a multi-party transaction, we're ready to see how it is stored at the heart of a Hyperledger Fabric blockchain system—in a ledger. Figure 6.3 shows a sample Hyperledger Fabric ledger:

Figure 6.3: A Hyperledger Fabric ledger has two major components: a state database and a blockchain

We can see that there are two parts to a ledger—a state database and a blockchain. The state database holds the current value of all objects in the ledger, while the blockchain holds a history of all transactions affecting these objects. These are the two key data structures with which our smart contracts and application programs will interact.

Make no mistake though, the blockchain is the primary component of the ledger. That's because it generates the state database. If the state database was deleted or lost, we could regenerate it from the blockchain by replaying all the transactions contained within it. In contrast, if the...

Smart contracts

Let's now move on to the primary user of the ledger—a smart contract.

A central role in the network

A ledger is important because it immutably stores multi-party transactions. Our attention now turns to how a smart contract helps generate these transactions in the first place.

As we begin, we issue a gentle caution to the reader! When compared to a program that reads and writes to a database over which it has complete control, a smart contract may not exhibit the behaviors we expect. Specifically, we'll see how a smart contract can sometimes:

• Read and write to the ledger, as we would intuitively expect
• Read from the ledger, but cannot write to it
• Write to the ledger, but cannot read from it

We realize that these statements may seem counterintuitive at the moment, but they stem from the fact that a blockchain is owned by multiple organizations, and every organization must agree to ledger changes in a mechanism...

Programming language

As we discovered earlier in the chapter, at the heart of Hyperledger Fabric is an immutable log of multi-party transactions. This idea transcends any given programming language; indeed, we'd really like as many participants as possible to participate in a network of multi-party transactions.

Moreover, given we have a decentralized system where different organizations develop different smart contracts and applications, it's just not feasible to suggest that only one programming language can be used.

This joint desire and need for language openness is why Hyperledger Fabric allows multiple programming languages to be used for smart contract and application development. At the time of writing, the most popular programming languages are JavaScript, TypeScript, Java, and Golang, and support for these is built into Fabric. Additionally, the Hyperledger Burrow project allows developers to write smart contracts in Solidity, a programming language used...

Endorsement policy

Now that we understand how a smart contract generates, for a single organization, a signed transaction response comprising the before- and after-images of changed states, we're close to understanding how to generate a multi-party transaction. We're going to see how an endorsement policy is central to this process.

In Figure 6.9, we can see an endorsement policy for the car smart contract we've been discussing:

Figure 6.9: A smart contract has an endorsement policy associated with it

The car contract has an associated endorsement policy: AND(SARA, BOB). This says, "any transaction generated by the car smart contract is only valid if it is signed by Sara and Bob."

In Hyperledger Fabric, every smart contract has an associated endorsement policy to describe the set of signatures required for the transaction that generated it to be considered valid. Multi-party transactions are the core of Hyperledger Fabric—that...

Summary

We've reached the end of our journey on smart contract development in Hyperledger Fabric. Let's spend a few moments recapping the key steps:

• We started by examining the central concept of a multi-party transaction, which represents the mutual agreement by a set of organizations in a network consortium to a change to a set of business objects.
• We moved on to see how transactions involving these business objects were stored in a distributed ledger replicated across all network organizations, and how it held both the transaction history of these objects and their current value.
• We discussed how smart contracts operate within a consensus framework, and the operations that need to happen for a smart contract to generate a multi-party transaction that is stored in the ledger.
• We examined the important interplay between a smart contract and the ledger's current value in generating a transaction response expressed as before- and after-images...