Knowledgemanagement Lecture5 2019

ICt & KM lecture 5 1
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

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.

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.

Every participant in the blockchain network 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.

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.

Ledger = World State + Blockchain
Hyperledger user transaction
We will now describe, at a conceptual

level, how Hyperledger Fabric allows
organizations to transact with each other.

The lifecycle of a user transaction in a
Hyperledger Fabric Blockchain
Network :
Propose and Endorse

Specialization of Nodes
It is good for scalability and performance to have
the workhorses in Hyperledger Fabric, the nodes,
specialized by task. There are three kinds of
workshorses, jointly called nodes. A unique
characteristic of the HLF architecture is the
specialization of the nodes into three related
subclasses: Endorsers, Committers and Orderers

The endorsers, a selectable subset of the committing
peers, have as task to analyze the transaction proposed by
the Client Application, check the signatures and apply if
required (hence with an update transaction) by the Client
Application, the services of a smart contract. This means
a simulation of the transaction on the current World State,
without modifying the World State. However the
endorsers take a copy of all the relevant key-value pairs in
the World State and generate the insert and delete
statements to be used by the committing peers later in the
transaction cycle, assuming the transaction is declared
valid.

Ordering nodes (orderers), sometimes referred to as
ordering system, are business domain agnostic. Their job
is to guarantee that in a distributed network with many
transactions coming in asynchronously and concurrently,
from different client applications in different
organizations and in different channels, the sequence of
transactions submitted is correctly ordered in a block of
the HLF blockchain in a specific application channel. In a
Fabric network there is exactly one system channel and
one or more application channel(s), each having their
own blockchain. A block is primarily composed by the
orderers. The orderers are nodes that have no task in
common with the endorsing nor committing peers.

The committing peers receive a proposed
block of transactions from the orderer
nodes. Each (committing) peer checks that
each transaction of the block proposed by
the orderers satisfies the endorsement
policy, and that no concurrency problem
has occurred

Transmit a proposed transaction to endorsers

Endorsers simulate transaction proposal

Prepare the read part of the Read-Write set
As Endorsers records the data from the World State they
have used for the simulation and include these data in the
read part of the so-called Read-Write set. These data are
later in the transaction flow used by the Committing peers
for the management of distributed concurrency.

Prepare the write part of the Read-Write
set
The Endorser records the data that would have to be added to,
and/or deleted from the World State in the Write part of the Read
Write set.
We know from the carfabv.2 that color of a car is modifiable. In
such a case the key-value pairs look as follows:
Carkey Color Version DateTime
CAR0 Blue 0 2018-01-26-13:00
CAR0 Yellow 1 2018-01-31-15:00
CAR0 Blue 2 2018-02-01-13:00

The car identified by Carkey CARO has the color blue as
version 0 since 2018-01-26-13:00.
The car identified by Carkey CARO has the color yellow as

version 1 since 2018-01-31-15:00.
The car identified by Carkey CARO has the color blue as

version 2 since 2018-02-01-13:00.
These facts are called versioned key-value pairs in

Hyperledger Fabric. In the key-value pair, the value part may
consist of a set of attribute-value pairs.

Client application receives endorsement

Example endorsement policies Suppose the endorsement policy
specifies the endorser set E = {Alice, Bob, Charlie, Dave, Eve, Frank, George}. Some
example policies:
 A valid signature on the same tran-proposal from all members of E. [Please remember
that tran-proposal means endorsement; hence is common language: all endorsers from
set E have to endorse.]
 A valid signature from any single member of E[on a tran-proposal].
 Valid signatures on the same tran-proposal from endorsing peers according to the
condition (Alice OR Bob) AND (any two of: Charlie, Dave, Eve, Frank, George).
 Valid signatures on the same tran-proposal by any 5 out of the 7 endorsers. (More
generally, for chaincode with n > 3f endorsers, id signatures by any 2f+1 out of the n
endorsers, or by any group of more than (n+f)/2 endorsers.)
 Suppose there is an assignment of “stake” or “weights” to the endorsers, like
 like {Alice=49, Bob=15, Charlie=15, Dave=10, Eve=7, Frank=3, George=1}, where
the total stake is 100: The policy requires valid signatures from a set that has a
majority of the stake (i.e., a group with combined stake strictly more than 50), such as
{Alice, X} with any X different from George, or {everyone together except Alice}.
And so on.

The lifecycle of a user transaction in a
Hyperledger Fabric Blockchain
Network :
Order and Validate

The possible outcomes of the endorsing
transaction stage
With sufficient endorsements
Not sufficient endorsements after a set time
Client application detects that there are

inconsistent transaction responses

With sufficient endorsements
As soon as the Client application has decided it

has obtained a sufficient number of
endorsements from the endorsing peers for a
given submitted transaction instance, it sends
the transaction message (= proposed transaction
by client application, the Read-write sets and the
signatures of the Endorsing peers) to the
Orderers, of course properly signed and
encrypted.
Not sufficient endorsements after a set time
When the Client application comes to the

conclusion that there are not a sufficient number of
endorsements, the Client application will decide to
stop this proposed transaction as it will anyway be
later rejected by the Committers, would it be sent to
the orderers and from there packaged into a block to
the Committers.

Client application detects that there are
inconsistent transaction responses
If the client application detects that not all endorsed

responses are consistent, it may decide to stop the
transaction workflow early. Should the client
application in such a situation nevertheless decide to
forward the inconsistent set of responses to the
ordering service, the transaction will be declared
invalid during the committing process

Endorsed transactions send to orderers

Orderers create a proposed block for a channel

Orderers send proposed block to committers

The life cycle of a user transaction part 3: the
validating phase
The committing peers receive the proposed block from the orderers.
Each committer checks that each transaction in a proposed block
satisfies the associated endorsement policy. If not, the transaction will
be marked as invalid, yet will be left in the block, but it has no effect
on the World State.
Each committer uses the Read set of a proposed transaction to check
that that Read set used by the endorsing peers in the simulation
(during the endorsing phase) is still the same as now is available in
the World set. If not the same, the transaction will be marked as
invalid by the committer as invalid in the block, and has no effect on
the World State. The committers append the proposed block to the
blockchain and update the World State for all the valid transactions in
the block.

Committers check read-set with world state

Committers inform client application for every
transaction proposed in block

Hence the Client application can receive one of the following two messages.
 Transaction is accepted as valid and is now part of the immutable
blockchain, with effect on the World State
The committers inform each Client application that has submitted a
transaction to the Fabric Network that the transaction is now part of the
blockchain, that it is a valid transaction and that the World State has been
updated accordingly, in case the transaction satisfies all rules.
 Transaction is not accepted, hence declared invalid, but part of the

immutable blockchain, without effect on the World State
The second option is that the committers inform the submitting Client
application that the transaction has been declared invalid, nevertheless
included with the label invalid in the Block Chain and that this proposed
transaction has had no influence on the World State.
The final step in the workflow of a business transaction is the processing by
the Client application of the response of the Committers .

What is a blockchain network ?
A blockchain network is a technical infrastructure that provides
ledger and smart contract (chaincode) services to applications.
Primarily, smart contracts are used to generate transactions which
are subsequently distributed to every peer node in the network
where they are immutably recorded on their copy of the ledger.
The users of applications might be end users using client
applications or blockchain network administrators.
In most cases, multiple organizations come together as a
consortium to form the network and their permissions are
determined by a set of policies that are agreed by the consortium
when the network is originally configured. Moreover, network
policies can change over time subject to the agreement of the
organizations in the consortium,.

The team Project
How to approach the assignment

Four organizations, R1, R2, R3 and R4 have jointed decided and written into an agreement that
they will set up and exploit a Hyperledger Fabric network. R4 has been assigned to be the
network initiator – it has been given the power to set up the initial version of the network. R4 has
no intention to perform business transactions on the network. R1 and R2 have a need for a
private communications within the overall network, as do R2 and R3. Organization R1 has a client
application that can perform business transactions within channel C1. Organization R2 has a
client application that can do similar work both in channel C1 and C2. Peer node P1 maintains a
copy of the ledger L1 associated with C1. The network is governed according to policy rules
specified in network configuration NC4, the network is under the control of organizations R1 and
R4. Channel C1 is governed according to the policy rules specified in channel configuration CC1;
the channel is under the control of organizations R1 and R2. There is an ordering service O4 that
services as a network administration point for N, and uses the system channel. The ordering
service also supports application channels C1 and C2, for the purposes of transaction ordering
into blocks for distribution. Each of the four organizations has a preferred Certificate Authority.

For the teams A and B, the following assignment is given
In section 4 (the blockchain network) of the hyperledger fabric documentation, the
blockchain network is introduced in a student-friendly way. You and your team are
asked to do the following. Provide a conceptual schema including elementary fact
types, fact type forms, integrity rules, derivation rules and a list of concept
definitions for the universe of discourse that consists of the diagram in figure 4.1
A lot of domain information is available in this chapter 4 of the documentation. Also
use the other material that is made available to you if necessary.
For the teams C and D, the following assignment is given

 In section 7 (Peers) of the hyperledger fabric documentation, the blockchain
network is introduced in a student-friendly way. You and your team are asked to
do the following. Provide a conceptual schema including elementary fact types,
fact type forms, integrity rules, derivation rules and a list of concept definitions
for the universe of discourse that consists of the diagram in figure 7.11
 A lot of domain information is available in this chapter 7 of the documentation.
Also use the other material that is made available to you if necessary
A lot of domain information is available in this chapter 4 of the documentation. Also

use the other material that is made available to you if necessary.

Peer Node P1 maintains a copy of the ledger L1 associated with channel C1

Generalize into fact type form:
Peer node <R1> maintains a copy of the Ledger <R2> associated with channel <R3>

Peer node Ledger Channel
(node ID) (ledger ID) (channel ID)
R1 R2 R3
<R1> maintains a copy of <R2> associated with <R3>

R1 R2 R3

P1 L1 C1
P2 L1 C1

R1 R2 R3

P1 L1 C1
P2 L1 C1
Allowed in combination ?

R1 R2 R3

P1 L1 C1
P2 L1 C1
Allowed in combination ? Yes: See figure on page 1 of document Peers

R1 R2 R3

P1 L1 C1
P1 L2 C1

R1 R2 R3

P1 L1 C1
P1 L2 C1

R1 R2 R3

P1 L1 C1
P1 L2 C1
Allowed in combination ? No See document blockchain network p.23

The ledger L2 is effectively scoped to channel C2. The ledger L1 is completely
separate: it is scoped to channel C1
ur1
R1 R2 R3

P1 L1 C1 Not allowed
P1 L2 C1 in combination

ur1
R1 R2 R3

P1 L1 C1
P1 L1 C2

ur1
R1 R2 R3

P1 L1 C1
P1 L1 C2

ur1
ur2
R1 R2 R3

P1 L1 C1 Not allowed
P1 L1 C2 in combination

Peer (node) A network entity that maintains a <ledger> and runs <chaincode> containers in
order to perform read/write operations to the <ledger>. [Peer]s are owned and
maintained by <Member>s (source: Glossary)
Ledger A combination of a <blockchain> and a <world state> (source: Glossary and

ledger document p.1)
Channel A primary communications mechanism by which the <member>s of a consortium

can communicate with each other. (source: document blockchain network p.7)

1.Plan a meeting with your team on short
notice: 2 hours
2.Try to come to an agreement on which fact

types or fact type forms are relevant in the
example before next tutorial on thursday
3.Divide these fact type (forms) over the group

members.

4. Every member analyzes the fact types as was done in the
example given in this lecture
5. Plan another meeting with the team members
6. In this meeting harmonize and integrate the

concept definitions.
7. Try to integrate the fact types and uniqueness (and other

integrity and derivation) rules into one model
8. Add integrity rules that have become relevant after integration

(i.e. mandatory rules and set-comparision rules)>
9. Finalize and format the final report

Thursday March 14: tutorial on project progress
Monday 25th March. Lecture 6: Questions on

project assignments
Thursday March 28th: Questions on assignment

dealt with in tutorials
Deadline for handing in projects: April 5th, 23:59
Each team member sends a peer evaluation in an

e-mail to coordinator

Knowledgemanagement Lecture5 2019

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Knowledgemanagement Lecture5 2019

Încărcat de

Drepturi de autor:

Formate disponibile

ICt & KM lecture 5 1

At the heart of a blockchain network is a distributed ledger that records

A blockchain ledger is often described as decentralized because it is

ICt & KM lecture 5 2

ICt & KM lecture 5 3

ICt & KM lecture 5 4

With the ability to coordinate their business network through

ICt & KM lecture 5 5

The world state component describes the state of the ledger

ICt & KM lecture 5 6

We will now describe, at a conceptual

ICt & KM lecture 5 8

Propose and Endorse

ICt & KM lecture 5 9

ICt & KM lecture 5 10

ICt & KM lecture 5 11

ICt & KM lecture 5 12

ICt & KM lecture 5 13

ICt & KM lecture 5 15

ICt & KM lecture 5 16

ICt & KM lecture 5 17

CAR0 Blue 0 2018-01-26-13:00

CAR0 Yellow 1 2018-01-31-15:00

CAR0 Blue 2 2018-02-01-13:00

ICt & KM lecture 5 18

The car identified by Carkey CARO has the color yellow as

The car identified by Carkey CARO has the color blue as

These facts are called versioned key-value pairs in

ICt & KM lecture 5 19

ICt & KM lecture 5 20

ICt & KM lecture 5 21

Order and Validate

ICt & KM lecture 5 22

With sufficient endorsements

Not sufficient endorsements after a set time

Client application detects that there are

ICt & KM lecture 5 23

As soon as the Client application has decided it

When the Client application comes to the

ICt & KM lecture 5 25

If the client application detects that not all endorsed

ICt & KM lecture 5 26

ICt & KM lecture 5 27

ICt & KM lecture 5 28

ICt & KM lecture 5 29

ICt & KM lecture 5 30

ICt & KM lecture 5 31

ICt & KM lecture 5 32

 Transaction is not accepted, hence declared invalid, but part of the

ICt & KM lecture 5 33

ICt & KM lecture 5 36

How to approach the assignment

ICt & KM lecture 5 37

ICt & KM lecture 5 38

For the teams C and D, the following assignment is given

A lot of domain information is available in this chapter 4 of the documentation. Also

ICt & KM lecture 5 39

ICt & KM lecture 5 40

Generalize into fact type form:

ICt & KM lecture 5 41

<R1> maintains a copy of <R2> associated with <R3>

ICt & KM lecture 5 42

<R1> maintains a copy of <R2> associated with <R3>