Introduction

We continue our demonstration of Daml working with various types of ledger. In the previous several articles, we have walked through the code and tested it with Daml Studio (link), and then the same code on Daml Sandbox and Navigator (link). The latest one is the same code persistent in PostgreSQL-based ledger (link), which is close to a production environment when a centralized ledger is required. In case a distributed or decentralized setup is needed, like a cross-organization deployment, we can use a distributed ledger environment. In this article we use the same “fix my bike” example and deploy it over a fabric-based Daml ledger. You will see all happening at the backend side, and it does not present any difference when using this Daml application.

Besides, I also include some observation from Fabric network side and see how daml-on-fabric is working with a fabric network.

Overview

It is obvious that this setup is composed of two systems developed separately: Daml application and Hyperledger Fabric (Fabric). Those reading this series of articles should know Daml well. Here is just a quick overview on some concepts in Fabric, which will be referred to later in this article.

Quick Overview of Hyperledger Fabric

Hyperledger Fabric is an enterprise blockchain platform for building consortium applications. The consortium application is serving multiple organizations, such that all of them are accessing the same source of trustful information (from the ledger), and executing the same business logic (chaincode).

A typical fabric network is composed of two types of nodes: peer and orderer. Peers keep ledger, responsible for committing new blocks, updating world state, and executing chaincode when needed. Orderers are responsible for new block creations. In a typical setup, peers are deployed in participating organizations, while orderers usually run as a cluster in a separate organization. This is the setup of our demonstration.

Note: in a decentralized setup, orderers are running in each participating organization. Both centralized and decentralized ordering services are supported in Fabric. For those who are interested in this decentralized setup, please refer to these two articles (link and link).

Channel is a key aspect in Fabric, representing a group of organizations sharing the same ledger and deployed with the same set of chaincode. A fabric network supports more than one channel, and an organization can join one or more channels.

Each peer holds a ledger per channel. Ledger is composed of two parts: blockchain keeps all the transactions in a “blockchain” structure, while the world state database stores the latest states. When a new block sent by an orderer is received by peer, the peer will commit the block: if all transactions are validated, the block is appended on existing blockchain, and the world state is updated.

As a permissioned blockchain platform, every component in the network (orderer and peer) and every user using the network are identified and authorized. This part is implemented by Member Service Provider (MSP), which is done through Certificate Authority.

Chaincode is the smart contract capability in Fabric. In a nutshell it contains the business logics including the workflow, authorization requirement, and how state is updated. It is implemented with coding languages. Golang is the native language, while JavaScript and Java are also supported.

These are the concepts we will see in our demo. For detail please refer to the Fabric documentation (link).

Fabric Network in this Demo

Our demonstration is a simple two-peer-org setup, with a separate orderer organization. One peer exists in each peer organization, while one orderer is in orderer organization. A channel mainchannel is created and joined by both peers. After that network is up and running, a chaincode daml_on_fabric is deployed in mainchannel. It contains those functions to be invoked later by the daml-on-fabric driver (seen below).

Here is how the fabric network looks.

Daml-on-fabric

Overview

Daml-on-fabric is the software enabling Daml application running on top of Hyperledger Fabric. In short, on one side daml-on-fabric presents a standard Daml ledger API to Daml application, while on the other side invokes chaincode functions in the fabric network where the ledger is kept.

Daml-on-fabric can be roughly divided into two parts.

The part deployed in the fabric network is the chaincode, in which the data structure to be stored in the ledger and the functions acting upon the ledger are defined. The design of chaincode is closely coupled to how Daml ledger is operating, and the functions will be invoked by the client application. The chaincode is written in Golang and here you can find the chaincode (link).

The other part is the daml-on-fabric driver (driver). It presents the Daml ledger API to the Daml application. When Daml runtime needs to change contract state (e.g. create a new contract), the driver is responsible for invoking chaincode functions to update the state. From fabric perspective, this is the client application, with proper authorization to perform these tasks. The daml-on-fabric driver is written in Scala.

When we run the daml-on-fabric, we specify the DAR files created through compilation of our model (Daml code). It will be shown in the demonstration later.

Daml-on-Fabric Repository

The daml-on-fabric repository provides the driver, plus all the necessary components for setting things up. The driver comes with the sample fabric network setup mentioned above. All crypto material, MSP definition and network components are there. A script fabric.sh is prepared for bringing up and tearing down the network, which is also used by another script restart_fabric.sh.

The daml-on-fabric driver is brought up through the scala build tool (sbt). The driver will first create an application channel for the driver (mainchannel) and then install and commit the chaincode (daml_on_fabric) to the channel. After working on the fabric network, the driver is being brought up and gets the Daml ledger API ready for Daml runtime.

There are several options in daml-on-fabric. You can refer here for more details.

Demonstration

Our demonstration uses the daml-on-fabric repository to bring up the setup. Like previous articles, we again apply the “fix my bike” model. After the setup completes, Navigator is brought up and we repeat what we have done in previous articles.

Here is the setup for demonstration.

Step 1: Bring up the fabric network

First we clone the daml-on-fabric repository.

git clone https://github.com/digital-asset/daml-on-fabric.git

As mentioned, this repo has all on the daml-on-fabirc driver, and a pre-configured fabric network. Bring up the fabric network first.

cd daml-on-fabric
cd src/test/fixture
./restart_fabric.sh

With this we have a fabric network, with an orderer org and two peer org (org1 and org2). Note that no channel is created yet. The channel and chaincode will be established by daml-on-fabric driver later. Keep this terminal as it shows all logs from the fabric network perspective.

When we open another terminal, we see those network components running

daml new my-proj --template skeleton
cd my-proj

sdk-version: 1.10.0
name: bikedemo
source: daml
parties:
  - Martin
  - BikeShop
  - SwissBank
version: 0.0.1
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script
sandbox-options:
  - --wall-clock-time

module BikeShop wheredata Currency = USD | EUR | GBP | CHF
  deriving (Eq, Show)template Cash 
  with
    issuer: Party
    owner: Party
    currency: Currency
    amount: Decimal
  where
    signatory issuer
    controller owner can
      Transfer : ContractId Cash
        with
          newOwner: Party
        do
          create this with owner=newOwnertemplate BikeRepair
  with
    bikeShop: Party
    bikeOwner: Party
    description: Text
    price: Decimal
    paymentDue: Date
  where
    signatory bikeShop, bikeOwner
    controller bikeOwner can
      Pay : ContractId Cash
        with
          cashCid: ContractId Cash
        do
          cash <- fetch cashCid
          assert (
            cash.currency == CHF && 
            cash.amount == price)
          exercise cashCid Transfer with newOwner=bikeShoptemplate BikeRepairProposal
  with
    proposer: Party
    receiver: Party
    proposal: BikeRepair
  where
    signatory proposer
    controller receiver can
      Accept : ContractId BikeRepair
        do
          create proposal

cd my-proj
daml build

cd ../daml-on-fabric
sbt "run --port 6865 --role provision,time,ledger ../my-proj/.daml/dist/my-proj-0.0.1.dar"

cd my-proj
daml ledger allocate-parties --host localhost --port 6865 Martin BikeShop SwissBank

cd my-proj
daml navigator server --port 7500

Source link