By David Gorman | Published July 28, 2018 - Updated July 28, 2018
Endorsement is an important part of the network consensus algorithm in the
Blockchain Platform. This article explores the meaning of
endorsement, how it relates to participating organizations in a blockchain
network, and the underlying technical process.
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:
Endorsement (supporting or approving something) is often an action in
response to a request. Continuing the above examples:
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:
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
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,
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:
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
Some general observations on endorsement:
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.
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
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
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
The IBM Blockchain Platform allows a multi-organisation blockchain network
to be quickly and easily formed. The IBM Blockchain Platform is built on
the Linux Foundation’s Hyperledger
Fabric and Hyperledger
Composer. Learn more about both projects.
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:
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
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
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.
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:
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.
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.
The author thanks these colleagues for their expert and thorough review of this article during its development:
For further study, read Blockchain Consensus Protocols in the Wild and Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains.
Start building your own blockchain solutions with the IBM Blockchain Platform Starter Plan.
Stay in the know with the monthly Blockchain Newsletter for developers. Check out the current issue and subscribe.
Check out the many code patterns on IBM Developer, which provide roadmaps for solving complex problems with blockchain technology and include architecture diagrams, code repos, and additional reading.
Stop by the Blockchain Developer Center. It’s your source for free tools and tutorials, along with code and community support, for developing and deploying blockchain solutions for business.
January 14, 2019
December 5, 2018
Back to top