Introduction to the endorsement of transactions in a business network

How is endorsement handled in a business network, and how much is enough?

Endorsement is an important part of the network consensus algorithm in the
IBM
Blockchain Platform. This article explores the meaning of
endorsement, how it relates to participating organizations in a blockchain
network, and the underlying technical process.

Examples of endorsement

First, let’s step back from blockchain and define what we mean by
endorsement. Basically, it means to
support or approve something. Some industry-specific examples include:

In the finance industry, endorsement can mean signing a cheque to
transfer money to the payee. This is an example of approving the
transfer of money from an account.

In the insurance industry, a policy document is endorsed by adding or
removing conditions. This saves the policy from having to be
completely rewritten and is an example of the insurance company
approving changes to it.

In government here in the U.K., the Driving and Vehicle Licensing Agency
(DVLA) can add endorsements to your driving license for any driving
penalties received. In effect, the DVLA is approving the changes to
the driving license.

Endorsement (supporting or approving something) is often an action in
response to a request. Continuing the above examples:

In order to pay for goods or services, I write a cheque to make
payment. The input is the request for payment to which I endorse the
cheque by signing it. (There are, of course. many more steps in the
overall process.)

An insurance company reviewing a policy document will add endorsements
before agreeing to it.

The DVLA, upon notification of penalties from a court of law, will add
endorsements to a driving license.

Breaking the idea of endorsement down further, there are often rules
governing the actual endorsement. As a result of these rules, the process
of endorsement will result in an updated state or output of some
description. For example:

When signing a cheque, I will write the amount and cross the cheque
with Payee Only to ensure only the intended recipient receives the
correct amount. The output is the endorsed cheque, which the payee can
pay in to their bank.

An insurance company will make many decisions on the precise wording
of the policy document before deciding which endorsements to include.
The output is the updated policy document.

The DVLA will add any endorsements and, if appropriate, withdrawal of
the driving license from the driver. The output is the updated driving
licence.

The value of trust

Although endorsement establishes trust between the participants,
endorsement alone is not necessarily enough. If I were to sign a cheque
for which I am not the account holder, then I don’t have the authority to
endorse the cheque. So, although the cheque is endorsed in the literal
sense, it is not endorsed by an approved account holder and should
therefore be rejected.

We can see from this example that trust is also an important aspect of
endorsement. The more we trust the endorser, the more we trust their
endorsement.

As we think about endorsement, we can see how, as individuals, we both
endorse and receive endorsements in everyday life, whether writing
cheques, taking out a new mortgage, or insuring a car. These endorsements
form the basis of agreements and trust between ourselves and others,
including organisations.

Endorsement between organisations

If we shift the focus to business organisations for a moment, we can see
how endorsement also underpins everything an organisation does in regard
to other organisations. For example:

A transfer of money from Company A to Company B will usually occur as
a bank-to-bank transfer, where all the appropriate checks and balances
are in place. In particular, Company A’s bank will transfer only the
correct amount of funds on receipt of an endorsed request.

Company A enters into an agreement with Company B to provide services.
A legally binding Statement of Work is agreed upon and signed by both
companies. In this example, certain employees in both companies will
have the right to sign (endorse) contracts on behalf of their
company.

Company A agrees to buy regulated goods from Company B. Company A
signs a Purchase Order (PO). Similar to the previous example, a person
in Company A will have the right to sign the PO. As this is a
regulated industry, Company B will want to ensure compliance with regulations of the industry when providing goods to
Company A.

In these broad examples, we see how one company approves (endorses)
transactions with other companies they are doing business with. These
transactions: are endorsed, have a set of inputs, and have a set of output
actions.

Some general observations on endorsement:

Endorsement can be made by one or more individuals or organisations
for the same transaction. For example, a cheque may require
countersigning (a second signature) from another authorised account
holder.

Endorsement is generally based on a pre-existing set of data and conditions. For example, I may write a cheque to a recipient because I know I have sufficient funds in my bank account.

Endorsement is sometimes required multiple times for the same thing.
For example, a mortgage application may require me to sign multiple
copies of the same document: one that I keep, and one that is sent to
the lender.

It’s tempting to think that the more endorsements there are for a
transaction, then the more trustworthy it is. This, however, isn’t
necessarily true. I would trust a cheque signed by a family member more
than a countersigned cheque from two people I don’t know. So knowledge of
the endorser and their reputation is important when accepting endorsement
from them, and this comes back to trust.

Endorsement spanning multiple organisations in a business network

We’ve now considered the concepts of endorsement and some high-level
examples of when businesses might endorse transactions. While it’s
important for all internal transactions within an organisation to be
trustworthy for the purposes of fraud prevention and audit, etc., it
becomes increasingly important that transactions are done in a trustworthy
way when they cross organisational boundaries. Would any organisation act
on a request to transfer money or an asset if they didn’t trust the
request and weren’t sure it was endorsed correctly by the requesting
organisation?

For these transactions that span multiple organisations, a private
permissioned blockchain network, such as the IBM Blockchain Platform, can
provide the trust and endorsement required.

As a simple example of cross-organisation endorsement, let’s assume there
are two companies, and Company B purchases an asset from Company A. These
are the types of checks that might be required:

Company A owns the asset currently. They want to know who the purchase
order is from, the quantity, and current inventory levels.

Company B is purchasing the asset. They want to check whether Company
A is the legal owner, and they may be interested in the history of the
asset. They also want to receive the correct number of items
purchased.

In addition to the validation checks, Company A wants to be certain
that their inventory levels are adjusted correctly when they transfer
the asset(s) to Company B, and Company B wants to know they become the
legal owner upon execution of the transfer.

Even in this simple example, we can see the need for trust between the two
companies and the types of approvals or endorsements that may be
necessary.

In version 1.0 of Hyperledger Fabric, a new network consensus algorithm was
introduced that has trust and endorsement at its core.

What is a consensus algorithm? Put simply, a blockchain network is
a peer-to-peer network of nodes that are managing a shared and replicated
ledger of transactions. In order for the network to manage the
simultaneous receipt of transactions from multiple sources, ensure that
appropriate members of the network agree the transactions are valid, and
then securely store and deliver a single shared version of the ledger,
there needs to be a consensus algorithm. Put another way, it’s the glue
that holds the network together. Learn more about consensus algorithms.

Getting back to endorsement, I need to cover one last blockchain concept
and that is the smart contract.

What is a smart contract? Put simply, it’s a program that defines
the business rules associated with a transaction. In Hyperledger Fabric,
smart contracts are also known as chaincode, and every
transaction submitted to the network must be invoked against a smart
contract. In fact, it is the smart contract that defines the transaction,
so without it, there is no transaction.

Now back to endorsement. Hyperledger Fabric’s consensus algorithm has three
stages that happen in an ordered sequence:

Endorsement

Ordering

Validation

This article focuses on the first of these stages of consensus, which is to
endorse the transaction. In Hyperledger Fabric, this means the execution
of the smart contract by the correct organisation(s), and it is a policy
that defines which organisation(s) must endorse the transaction. In a more
detailed view, this initial endorsement consists of the following
steps:

An application running the Hyperledger Fabric client code (Fabric SDK) constructs and submits a transaction to an organisation’s blockchain peer running on the IBM Blockchain Platform. This is called the endorsement proposal. The transaction includes input data, and the whole transaction is cryptographically signed by the client. The client may choose to send this same transaction to multiple endorsers (more on this later).

The blockchain network peer being run by the organisation that receives the transaction verifies the signature to ensure the transaction hasn’t been modified. It then simulates the execution of the transaction against the smart contract and returns what is called the endorsement response. The response is cryptographically signed by the peer.

We can see from these steps that within the IBM Blockchain Platform, endorsement can be specifically defined as the output of the peer simulating the execution of the input transaction against a smart contract. The output includes the transaction proposal, data that was read in order to run the smart contract, and any simulated updates.

Let’s pause to consider a few new observations:

The client application may or may not be part of the same organisation as the peer to which the endorsement proposal is sent.

The endorsement policy may define that two or more different organisations must endorse the transaction. In this case, the client application must send the endorsement proposal to multiple organisation’s peers.

No changes are persisted by the peers doing the endorsement at this stage, as the transaction may later be invalidated. Endorsement is part of a larger transaction consensus lifecycle.

A transaction is considered “endorsed” if the client application receives the correct number of endorsement responses from the organisations listed in the endorsement policy, and the endorsement responses are the same. In other words, given the same transaction input, each organisation defined in the policy produces the same result when executing the smart contract.

Now we mentioned earlier that endorsement alone was not enough to have a
trusted system. How do we know that a client application is who we think
they are, and that the peers within each organisation can be trusted?
Thankfully, IBM Blockchain Platform is a permissioned blockchain network,
which means that every entity within the network, whether the client
application or the peer, must have a cryptographic identity secured by a
private key and public certificate. The certificate must have a proven
root of trust back to a known Certificate Authority, although each
organization can have its own CA.

In order to trust transactions and know they haven’t been compromised,
every transaction within an IBM Blockchain Platform network is
cryptographically signed by the sender, and then validated by the
receiver. So the endorsement request is signed by the sending client
application, and validated by the receiving peer. The endorsement response
is signed by the sending peer and validated by the receiving client
application.

Bear in mind that there’s more to the endorsement phase than simple
execution of the transaction to produce an output. Endorsement critically
can prevent non-deterministic transactions across the network. Executing
the transaction on multiple peers and subsequently only committing if all
the endorsement responses are exactly the same will stop transactions and
smart contracts from producing random or unexpected results. This is also
one of the mechanisms to stop malicious actors in the network.

Endorsement is the way that an organisation participates in a transaction.
Company B will not simply want to accept the result of Company A executing
a transaction unilaterally. However, if Company B can also endorse the
transaction along with Company A and know that the network will only
commit the transaction if both agree, this gives both companies a high
degree of trust. It gives control and an off-switch for extreme
circumstances. An organisation knows that by suspending their endorsing
peers, no transactions needing their approval can proceed. There’s
obviously a flip side to this, as well, as no new transactions can be
committed to the ledger if endorsement is suspended.

Sufficient number of endorsements

So how many endorsers are needed in an IBM Blockchain Platform network? As
is often the case, there’s no simple answer, but these guiding principles
will lead us to a thoughtful answer!

Be led by the business requirements. Deciding which organisations and peers should endorse a transaction is a business requirement, not a technical one. If the transaction affects only two organisations, then why have three or four organisations be part of the endorsement policy.

Be guided by the levels of trust within the network and between the participants. A good rule of thumb is: the less trust there is, the more endorsement is required.

Is there a concern of corruption or deviation in the network that might require more endorsers?

Must there always be at least two endorsers for every transaction? Well, no, not necessarily. But be careful here! Use the previous principles to help answer this. If using one peer for endorsement, are the business requirements in alignment with this, and is the single endorsing peer trusted to act unilaterally in relation to the smart contract? A transaction endorsed by a single peer is still a trusted transaction. It has been signed by the client application and represents information that we know cannot have been changed after the client submitted it, and we have an irrefutable proof of which client sent the information and which peer endorsed it. However, it lacks the cross-organisational agreement that is often required for the majority of transactions in a business network. Another consideration is that a single endorser cannot catch non-deterministic smart contracts.

The endorsement policy supports both mandatory organisations that must endorse a transaction, as well as optional endorsers, allowing policies like:

Company A and (Company B or Company C).

Additional policy configurations include n of m, where n organizations must endorse the transaction. For example, five out of 10 organizations in the business network must endorse the transaction.

The future of endorsement

As you’d expect, the Hyperledger community who builds and maintains Hyperledger Fabric and Hyperledger Composer is already looking at additional endorsement features, such as potentially being able to define endorsement policies at the level of transactions rather than at the higher smart contract level.

Conclusion

In this article, we examined endorsement in a wide context. Reviewing endorsement in context of the IBM Blockchain Platform revealed the benefits it brings to enabling trusted transactions within the blockchain network. And finally, we reviewed the guiding principles for selecting the right number of endorsers for a specific smart contract.

Acknowledgments

The author thanks these colleagues for their expert and thorough review of this article during its development:

Resources

IBM Blockchain Platform Starter Plan In this pre-production staging environment on the IBM Cloud, you can easily build and deploy applications for a multi-organization blockchain network. Give the Starter Plan a try!