The Lifecycle of a User Transaction in a Hyperledger Fabric Blockchain Network Part 2: Order and Validate

The paper describes the second part of the happy path of a user transaction through a Hyperledger Fabric Blockchain Network. The full cycle of a user transaction originates from the Client Application (an actor outside the Hyperledger Ledger Network but inside an organization that is part of a set of organizations that jointly run the Hyperledger Fabric Blockchain Network). In the process of making the Hyperledger Fabric Blockchain network knowledge explicit, essential parts of FBM were applied in cooperation with the developers of the Fabric Blockchain platform.

Authors and Affiliations

1. Heerlen, The Netherlands

   Sjir Nijssen

2. Maastricht University, Maastricht, The Netherlands

   Peter Bollen

Corresponding author

Correspondence to Peter Bollen .

Editors and Affiliations

1. Trinity College Dublin, Dublin, Ireland

   Christophe Debruyne

2. University of Lorraine, Vandoeuvre-les-Nancy, France

   Hervé Panetto

3. Luxembourg Institute of Science and Technology, Esch-sur-Alzette, Luxembourg

   Wided Guédria

4. Maastricht University, Maastricht, The Netherlands

   Peter Bollen

5. University Babes-Bolyai, Cluj-Napoca, Romania

   Ioana Ciuciu

6. TU Graz, Graz, Austria

   Robert Meersman

Appendix A

Example endorsement policies (Source: Fabric Docs 1.2, Architecture Reference, Sub Section Endorsement Policies, Sub Section Example Endorsement Policies) [8].

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 assignment of stake in the previous example condition could be static (fixed in the metadata of the chaincode) or dynamic (e.g., dependent on the state of the chaincode and be modified during the execution).

  • Valid signatures from (Alice OR Bob) on tran-proposal1 and valid signatures from (any two of: Charlie, Dave, Eve, Frank, George) on tran-proposal2, where tran-proposal1 and tran-proposal2 differ only in their endorsing peers and state updates.

Reprints and permissions

© 2019 Springer Nature Switzerland AG

Policies and ethics