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

Examples of endorsement

First of all, 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 UK, 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 license.

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 2 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 may 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.

Endorsement in the IBM Blockchain Platform

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:

  1. Endorsement
  2. Ordering
  3. Validation

This post 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.

How many endorsements are sufficient?

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!

  1. 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 2 organisations, then why have 3 or 4 organisations be part of the endorsement policy.
  2. 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.
  3. Is there a concern of corruption or deviation in the network that might require more endorsers?
  4. Must there always be at least 2 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.

  5. 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, 5 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 post, 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 post during its development:

  • Christian Cachin, IBM Research, Cryptography and protocols for distributed systems and blockchain
  • Luc Desrosiers, IBM Blockchain Labs, Blockchain Solution Architect
  • Matthew Golby-Kirk, IBM Blockchain Labs – Blockchain Engagement

Next steps

Join The Discussion

Your email address will not be published. Required fields are marked *