Executing large-scale processesin a blockchain

Ramkumar, Mahalingam Article Executing large-scale processesin a blockchain Journal of Capital Markets Studies (JCMS) Provided in Cooperation with: Turkish Capital Markets Association Suggested Citation: Ramkumar, Mahalingam (2018) : Executing large-scale processesin a blockchain, Journal of Capital Markets Studies (JCMS), ISSN 2514-4774, Emerald, Bingley, Vol. 2, Iss. 2, pp. 106-120, https://doi.org/10.1108/JCMS-05-2018-0020 This Version is available at: https://hdl.handle.net/10419/313258 Standard-Nutzungsbedingungen: Die Dokumente auf EconStor dürfen zu eigenen wissenschaftlichen Zwecken und zum Privatgebrauch gespeichert und kopiert werden. Sie dürfen die Dokumente nicht für öffentliche oder kommerzielle Zwecke vervielfältigen, öffentlich ausstellen, öffentlich zugänglich machen, vertreiben oder anderweitig nutzen. Sofern die Verfasser die Dokumente unter Open-Content-Lizenzen (insbesondere CC-Lizenzen) zur Verfügung gestellt haben sollten, gelten abweichend von diesen Nutzungsbedingungen die in der dort genannten Lizenz gewährten Nutzungsrechte. Terms of use: Documents in EconStor may be saved and copied for your personal and scholarly purposes. You are not to copy documents for public or commercial purposes, to exhibit the documents publicly, to make them publicly available on the internet, or to distribute or otherwise use the documents in public. If the documents have been made available under an Open Content Licence (especially Creative Commons Licences), you may exercise further usage rights as specified in the indicated licence. https://creativecommons.org/licenses/by/4.0/ Executing large-scale processes in a blockchain Mahalingam Ramkumar Department of Computer Science and Engineering, Mississippi State University, Starkville, Mississippi, USA Abstract Purpose –The purpose of this paper is to examine the blockchain as a trusted computing platform. Understanding the strengths and limitations of this platform is essential to execute large-scale real-world applications in blockchains. Design/methodology/approach –This paper proposes several modifications to conventional blockchain networks to improve the scale and scope of applications. Findings –Simple modifications to cryptographic protocols for constructing blockchain ledgers, and digital signatures for authentication of transactions, are sufficient to realize a scalable blockchain platform. Originality/value –The original contributions of this paper are concrete steps to overcome limitations of current blockchain networks. Keywords Cryptography, Blockchain, Scalability, Transactions, Blockchain networks Paper type Research paper 1. Introduction A blockchain broadcast network (Bozic et al., 2016; Croman et al., 2016; Nakamoto, 2008; Wood, 2014) is a mechanism for creating a distributed, tamper-proof, append-only ledger. Every participant in the broadcast network maintains a copy, or some representation, of the ledger. Ledger entries are made by consensus on the states of a process “executed”on the blockchain. As an example, in the Bitcoin (Nakamoto, 2008) process: (1) Bitcoin transactions transfer Bitcoins from a wallet to one or more other wallets. (2) Bitcoins created by “mining”are added to the miner’s wallet. (3) Bitcoin process state is the unspent balance in each wallet. The identity Aof a Bitcoin wallet is a public key of an asymmetric digital signature scheme. The possessor of the corresponding private key can initiate signed transactions to transfer Bitcoins from her wallet to other wallets. For example, a Bitcoin transaction: Ti¼ti;X;x;Y;y ½ A(1) signed by A, and broadcast at time t i , is for transferring (from wallet A), xBitcoins to wallet X, and yBitcoins to wallet Y. The transaction T i is deemed well-formed only if x+y⩽a, where ais the unspent balance in wallet Abefore the transaction. Only well-formed transactions are added to the Bitcoin-distributed ledger (ill-formed transactions are ignored). More specifically, a plurality of well-formed transactions is added to a block, and such blocks are added to the ledger, to create a “chain of blocks.” Journal of Capital Markets Studies Vol. 2 No. 2, 2018 pp. 106-120 Emerald Publishing Limited 2514-4774 DOI 10.1108/JCMS-05-2018-0020 Received 16 May 2018 Revised 16 May 2018 Accepted 1 September 2018 The current issue and full text archive of this journal is available on Emerald Insight at: www.emeraldinsight.com/2514-4774.htm © Mahalingam Ramkumar. Published in Journal of Capital Markets Studies. Published by Emerald Publishing Limited. This article is published under the Creative Commons Attribution (CC BY 4.0) licence. Anyone may reproduce, distribute, translate and create derivative works of this article (for both commercial and non-commercial purposes), subject to full attribution to the original publication and authors. The full terms of this licence may be seen at http://creativecommons.org/licences/by/4.0/legalcode 106 JCMS 2,2 While the Bitcoin network is intended for a single fixed process, namely, tracking the state of Bitcoin wallets, more recent blockchain networks like Ethereum (Wood, 2014) are intended for running any number of flexible, software defined, processes. Ethereum provides a JavaScript-like programming language for implementing functions triggered by various types of transactions, along with a virtual machine for executing of such functions. 1.1 Auditing the ledger A blockchain network can be justifiably regarded as a universally trusted platform for executing processes, as the trust is based solely on good cryptographic assumptions, namely, the quantifiable preimage and/or collision-resistance strength of a cryptographic hash function h( ). Blockchain ledger entries are a record of progression of states of the process. Protocols constructed using a standard cryptographic hash function h( ) make it possible to create an open, distributed, immutable (for past entries), append-only ledger that can be audited by anyone. In other words, the integrity guarantees regarding a process executed on a blockchain network stem from the fact that anyone can reliably audit the entire history of all process states. However, the fact that anyone can audit a blockchain ledger does not imply that everyone will. To address this issue, some participants are explicitly incentivised to do so. In other words, blockchain participants can be seen as belonging to two broad categories: (1) a small number of incentivised participants, who take an active part in making ledger entries; and (2) a much larger number (typically) of passive participants, who do not take part in the process of making ledger entries, but can nevertheless audit the ledger, if they choose to do so. Typically, every participant in a blockchain network maintains a copy of the ledger. Periodically, after a set of transactions have been processed, an incentivised user “makes a motion”to add a block to the blockchain. Most often, such a motion passes, and every participant updates their copy of the ledger. The reason that incentivised users do not make motions to add blocks with ill-formed transactions is due to the fact that they have a stake in the correctness of their ledger entries. Two common types of incentive mechanisms (Bentov et al., 2014) include Proof-of-Stake (PoS) and Proof-of-Work (PoW). In PoS-based (Kiayias et al., 2017) incentive systems, incentivised participants are required to explicitly stake some amount on the correctness of their ledger entries. Any error (deliberate or otherwise) will result in loss of stake. In PoW schemes (Nakamoto, 2008), the stake is in the form of expensive energy invested by incentivised participants (“miners”in Bitcoin) to solve a computationally intensive puzzle. In general, the puzzle itself has nothing to do with the process executed in the Blockchain. The incentive for minerstoensurecorrectnessofentriesisthata miner’s expensive work may be rendered moot if they make an erroneous entry. More specifically, in Bitcoin, solving the puzzle has two purposes: to gain the privilege of adding a block to the Bitcoin ledger; and “mine”a certain number of new Bitcoins. The main shortcoming of PoW incentives stems from growing sustainability concerns (Digital Trends) –the annual energy cost for mining Bitcoins is estimated to be already over a billion dollars (Digiconomist). While regular Bitcoin users may not solve puzzles, they are expected to audit the well-formedness of every ledger entry. Users who interact only intermittently with the blockchain network can still sync their copy of the ledger by downloading and examining all transactions that occurred since their last sync. 107 Large-scale processes in a blockchain 1.2 Cryptographic hash functions Central to blockchain networks is a cryptographic hash function h( ) for computing a succinct commitment to the ledger. The power of a cryptographic one-way hash function h() is deceptively simple –it is simply a mechanism to quantify certainty in the chronological order in which two events occurred. Specifically: y¼hx ðÞ )xA0;1 fg nexisted before yA0;1 fg n :(2) More specifically, given two sequences of bits (or bit-strings) x,y,whereh( ) transforms a preimage xA{0, 1}* (bit-string of any length), to a digest yA{0, 1} n (bit-string of fixed length n), one can conclude with a very high degree of certainty that “xexisted before y.”More specifically, the uncertainty in such a claim is? (2 −n ). In other words, for large enough n(say, n⩾128 bits) it is impractical to choose a digest first, and determine a suitable preimage later. In current blockchain networks the most commonly employed hash function h()isthe hash standard SHA-2 with 256-bit digests. The specific utility of the hash function h( ) in a blockchain is that it enables computation of a single hash (a 256-bit SHA-2 hash) α, as the commitment to the entire ledger. More specifically: (1) a Merkle (1987) hash tree is used to compute a commitment (a hash) v i to each block; and (2) a hash accumulator (Bayer et al., 1993) is used to compute the commitment αto a chain of values v 1 ,v 2 ,…. The explicit consensus between all users (at any specific time) is on the precise value of α. Due to the properties of h( ) (and more complex constructions using h( )), an explicit consensus on αis an implicit consensus on every ledger entry. 1.3 Scalable blockchain processes The practical utility of executing processes on a universally trusted platform (like a blockchain network) is that such as platform can eliminate, or substantially reduce the scope of, expensive infrastructures in the form of organizations like banks, insurance companies and even governments. However, real-world processes needed to replace such infrastructures may have possibly billions or even trillions of process states. For such large-scale processes, it is impractical for every blockchain participant to audit the complete history of all process states. More specifically, while some active participants may be incentivised (or paid) to audit every transaction, it is impractical to expect passive users, who may only participate intermittently, to do so. Realizing scalable blockchains calls for strategies that permit passive users to selectively audit the correctness of any specific ledger entry. More specifically, scalable blockchains should strive to reduce the overhead necessary for passive and intermittent participants to perform selective audits. Second, proactive strategies to eliminate ambiguities are essential for universal consensus, and thus, prevent forking of the blockchain. Consider a scenario where two miners Aand Bprovide two different correct solutions to a puzzle (for adding a block). Such a state can cause forking of the blockchain, where different users may sync up with different forks. The practical implication of a forked ledger is that users following different forks have different interpretation of the truth, namely, the actual state of the process. For example, the state of wallet Aand Bwill be different in both forks (Ais the beneficiary of the mined Bitcoins in one fork and Bin the other). If the reason for forking is due to an erroneous entry in one fork (e.g. inclusion of an ill-formed transaction), reducing the overhead for selective audits enables passive users to readily identify and follow the correct fork. Reasons for multiple forks without ill-formed transactions can be due to ambiguities in the order of transactions, and possibly even the interpretation of the process. 108 JCMS 2,2 Third, it is essential to reduce the susceptibility of the blockchain broadcast network to clogging attacks (Oppliger, 1999). One common form of clogging attack involves an attacker sending a transaction with random bits as “signature.”Only after performing expensive asymmetric cryptographic computations to verify the “signature,”will verifiers realize that the signature is invalid. Clogging attacks are an especially serious concern in broadcast networks, as it takes very little effort for an attacker to send random bits, to expend computational resources of a large number of receivers. This paper proposes multiple strategies aimed at addressing the three requirements above. Specifically: (1) Toward reducing overhead for intermittent passive users to sync up with the current state of the ledger, a hash calendar (Buldas and Saarepera, 2014) is proposed as a better alternative to the hash accumulator. (2) Toward reducing the overhead for selective audits, an ordered Merkle tree (OMT) (Ramkumar, 2014) is used to capture succinct commitments to process states. (3) Two strategies are proposed for eliminating ambiguities that may lead to forking: •the first is the use a separate timestamp ledger (TSL); and •the second is to interpret any blockchain process as a finite state machine (FSM), where every blockchain transaction is associated with an unambiguous next-state function. (4) Finally, to address clogging attacks, the use of expensive asymmetric cryptography-based digital signatures is eliminated. The rest of this paper is organized as follows. Section 2 outlines cryptographic protocols for scalable blockchains. Section 3 outlines strategies for: (1) introducing checkpoints in ledger entries to enable selective audits; and (2) unambiguous description of (FSM) next-state functions as explicit predicates –in the form of: •preconditions (predicates to commence the state transition); and •postconditions (predicates on completion of the transition). Section 4 outlines the architecture for a scalable blockchain that takes advantage of strategies outlined in Sections 2 and 3. Conclusions are offered in Section 5. 2. Cryptographic protocols Hash chain based protocols discussed in this section include Merkle (1987) hash trees, OMT (Ramkumar, 2014), hash accumulators (Bayer et al., 1993), hash calendar (Buldas and Saarepera, 2014) and the timed efficient stream loss-tolerant authentication (TESLA) broadcast authentication protocol (Perrig et al., 2000). 2.1 Merkle hash tree A binary Merkle (1987) hash tree (Merkle, 1987) of depth dhas 2 i nodes at each of the depths 0⩽I⩽dnodes. Figure 1 depicts a tree with depth d¼3. The N¼2 3 ¼8 nodes at depth d¼3 are leaf nodes. Internal nodes have two child nodes –a left child and a right child. Specifically, an internal node uk iat depth kis related to its two child nodes ukþ1 2iand ukþ1 2iþ1at depth k+1 as follows: uk i¼hu kþ1 2i;ukþ1 2iþ1  :(3) 109 Large-scale processes in a blockchain Corresponding to every leaf (non-internal) node at depth d, are dverification objects (VOs), one in each of the levels d,d−1, …, 1. The sets of dVOs u i of a leaf node ud iare nodes complementary to ud i, as they are commitments to all leaf nodes except ud i. Typically, a leaf node ud i¼hLðÞ, where Lis a leaf. Thus, for any leaf Lthere is a sequence of dhash operations f bt ( ), namely: r¼fbt hL ðÞ ;ui ðÞ ;(4) which outputs the root rof the tree. For example, consider leaf L d in Figure 1 with leaf node u3 3¼hL d ðÞ. The three VOs of u3 3are u¼u3 2;u2 0;u1 1  . The sequence of d¼3 hash operations are as follows: r¼fbtðu3 3;fu3 2;u2 0;u1 1gÞ ¼ hðhðu2 0;hðu3 2;u3 3ÞÞ;u1 1Þ:(5) In Equation (4), the fact that the output of f bt ()isris proof that “the leaf L(and the VOs u i of L) should have existed before the root rwas computed.”In other words, given (a tree with) root r, this constitutes proof of existence of the leaf Land its VOs u i in the tree. In most blockchain networks, N⩾1 well-formed transactions included in a block are leaves of a Merkle hash tree. The root of the tree v i is a commitment to the entire block. Existence of the leaf Lin the block can be demonstrated by providing a set of log 2 NVOs u that satisfy f bt (h(L), u¼v i . In addition, the tree structure also permits efficient incremental updates to the leaves, which is a feature that is not taken advantage of in most blockchain networks. Specifically, given that r¼f bt (h(L), u, proving existence of leaf L, two kinds of incremental updates are possible: (1) leaf update: corresponding to an update of the verified leaf Lto L′, the new root is r′¼f bt (h(L), u; and (2) insertion/deletion of leaves: if a new leaf L n is inserted to the right of existing leaf L, the new root is r′¼f bt (h(h(L), h(L n ))), u; if root update r→r′can be demonstrated to be consistent with inserting a leaf, then an update r′→ris for deleting a leaf. Thus, a Merkle hash tree permits efficient computation of a commitment (root) to a dynamic set of leaves with practically unrestricted cardinality. For a tree with a billion leaves, 30 hash operations using 30 VOs will be required to verify the existence of a leaf. An additional u3 2 u0 0 u0 1 u0 2u1 2 u0 3u1 3u2 3u3 3u4 3 u2 2 u7 3 u6 3 u5 3 u1 1 LbLcLdLeLfLgLh La 2 Notes: Gray shaded nodes u2 ; u0 and u1 are complementary to (hatched) leaf node u3=h(L3) 3 3 1 Figure 1. A binary Merkle hash tree 110 JCMS 2,2 30 hash operations (using the same VOs) will be required to update the leaf, or insert a new leaf, or delete a leaf. 2.2 Ordered Merkle tree In an OMT (Ramkumar, 2014), proof of existence of a leaf can simultaneously convey existence of key-value pairs, nonexistence of key-value pairs and possibly highest/ lowest keys. Each leaf in an OMT is a three-tuple of the form {i,i n ,v i }. Together, all leaves form collection of key-value pairs with unique keys. In a leaf {i,i n ,v}, iis the unique key in the collection, i n is the next-key and v i is the value of the item with key i. For a lone item in the collection with i n ⩽i,iand i n are respectively the highest and lowest keys (i¼i n for a collection with a single item). An item with key jcan be inserted only if no item with key jcurrently exists. Nonexistence of key jcan be demonstrated by demonstrating existence of a leaf {i,i n ,v i } such that: jAi;in) ½½ iojoinif in4i joinpior inpiojif inpi (:(6) 2.3 Hash accumulator A hash accumulator (Bayer et al., 1993; Ramkumar, 2014) is a dynamic commitment to a growing list of values v 1 …v n , and is computed as follows: a1¼v1;a2¼ha1:v2  ;...;an¼han1:vn  ...:(7) Specifically, the accumulated hash α i is a commitment to all values v 1 …v i accumulated thus far, and the chronological order in which they were accumulated. From the properties of h(), it is impractical to determine any sequence of values different from v 1 …v i , for which the accumulated hash is α i . In most blockchains, values like v 1 ,v 2 ,…are commitments (Merkle tree roots) of blocks. The accumulated hash αis a commitment to the entire ledger. Given the value of the current accumulated hash α, all values v 1 …v n are necessary to determine if a specific v j exists in the list. 2.4 Hash calendar A hash calendar (Buldas and Saarepera, 2014) can be used to compute a dynamic commitment to growing list of values v 1 …v n …, if new values are added at a constant rate (e.g. v i is added at time iΔ+τwhere τis the calendar start-time, and Δis a fixed interval). The hash calendar is implemented as a Merkle hash tree where leaves v 1 …v n …are added from left to right. In general, when nis not a power of 2, the tree may be seen consisting of up to log 2 ncomplete subtrees. For example, after 18 intervals (n¼18), the tree can be seen as consisting of two complete subtrees –a tree with 16 leaves, and a tree with 2 leaves. Note that the number of ones in the binary representation of nis the same as the number of complete subtrees. If n¼22 ¼10,110 b the tree will have three complete subtrees with 16, 4 and 2 leaves, respectively. The dynamic commitment gto a calendar is the accumulated hash of the roots of all (maximum of log 2 n) complete subtrees. 111 Large-scale processes in a blockchain 2.5 TESLA In the TESLA (Perrig et al., 2000) broadcast authentication protocol, the sender A of a broadcast stream chooses a random value (say) KA 0, and creates a hash chain fKA 0KA Lg, where: KA 1¼hK A 0  ;KA 2¼hK A 1  ;...;KA L¼hK A L1  : From the properties of h( ), given KA iit is trivial to compute KA jXi(by repeated hashing j−itimes), but impractical to compute KA joi. The tail value of the chain KA Lis the “public key”of A. It is associated with two additional values: an absolute value of time Tand a time interval Δ. The interpretation of this association is that “KA Liwill remain A’s secret until time T+iΔ.” A hashed message authentication code (HMAC) for a message Mand secret K, namely, μ¼HMAC(M,k), is typically a token accompanying a message M. The receiver with knowledge of Kon verifying that HMAC(M,k) is the same as the token accompanying the message can safely conclude that the token μcould have been computed only by an entity with the knowledge of the key K. Consider a scenario where an HMAC sM¼HMACðM;KA LiÞfor a message Musing value KA Lifrom the hash chain was seen before time t¼T+iΔ. Later, after time T+iΔ, the value KA Lifrom the chain is disclosed, satisfying sM¼HMACðM;KA LiÞ. This is proof that σ M could have been computed only with the knowledge of KA Li(and only the creator of the chain Acould have had knowledge of KA Libefore time t¼T+iΔ). In other words, as long as it is possible for everyone to establish that σ M was “seen” before time t, everyone can be convinced that the message was sent by A. In such a scenario, σ M is a digital signature for the message Mby A. As we shall see later, one possible approach to ensure that “σ M was seen before time t”is by employing a timestamping service (TSS) to timestamp the value σ M . Thus, in conjunction with a TSS, TESLA broadcast authentication becomes a non-reputable digital signature scheme. In theory, digital signatures based on asymmetric cryptographic primitives do not need to rely on an additional infrastructure for timestamping. In practice, timestamps for signatures are required in any case in scenarios where we need to cater for revocation of keys. Specifically, timestamping is required to ensure that a signature was computed before the key was revoked. Another advantage of asymmetric cryptography-based digital signatures is that they are instantly verifiable. Note that TESLA signatures have to be computed when the key used for computing the HMAC was a secret that can be verified only after the key used for HMAC is made public (along with the signed message/transaction). This disadvantage of TESLA is perhaps more than offset by its advantages. First, clogging attacks can be effectively addressed. Second, in several evolving blockchain-based application scenarios, transactions may be measurements from sensors or severely resource-limited Internet of Things devices (Xu et al., 2016) that may not be capable of performing asymmetric computations. Third, in the emerging post-quantum computing (Chen et al., 2016) world, asymmetric cryptography may no longer be a viable option anyway. 3. Blockchain processes as an FSM The FSM model of process Pwith dynamic process states Scan be represented as d:IS/Swhere δrepresents a next-state function triggered by unconstrained input I. In practice, any process Pcan be defined as using a set of (say) mnext-state functions f 1 ()…f m (). 112 JCMS 2,2 In a blockchain, inputs that trigger execution of next-state functions are broadcast transactions of mdifferent types. Specifically, execution of a next-state function f j ()is triggered by a transaction Tj iof type j, broadcast at some time tj i. Function fjðTj iÞ is executed only if the transaction is well-formed, and results in a change in the process state S. The progression of states of process Pdue to a sequence of transactions Tj1 1;...;Tjn ncan be represented as follows: S0⟶ fj1Tj1 1  S1⟶ fj2Tj2 2  S2Sn1⟶ fjnTjn n  Sn;...jiA1...mfg:(8) In Equation (8), S0is the initial state of the process, and Tji iis the ith “well-formed” transaction of type j i A{1 …m}. Given the initial state S0, and descriptions of functions f 1 ()…f m ( ), the state Snis completely determined by the sequence of transactions T 1 ,T 2 ,…,T n . Consequently, for purposes of auditing the correctness of process states, it is sufficient for the ledger entries e 1 ,e 2 ,…to be a list of transactions in their chronological order, or more specifically: e1¼t1;T1 ðÞ ;e2¼t2;T2 ðÞ ;...ei¼ti;Ti ðÞ ;...:(9) As an example, if the process executed by a blockchain represents a bank, the types of transactions may be OpenAccount(),CloseAccount(),Transfer( ), etc. A transaction Transfer( ) to transfer an amount xfrom an account Ato an account B will be deemed well-formed only if it is authorized (using a digital signature) by A, and sufficient balance exists in account A. A TSS (Bayer et al., 1993) attributes a “seen-at-time”tto a value vto be timestamped. If the blockchain is used to implement a TSS, where the state of the process is merely receipt of timestamp requests, no further processing is necessary. A blockchain TSS merely needs to maintain a ledger with entries of the form: e1¼t1;v1 ðÞ;e2¼t2;v2 ðÞ;...ei¼ti;vi ðÞ;...;(10) where an entry (t i ,v i ) states that v i was seen-at-time t i (or more specifically, v i was submitted for timestamping at time t i ). In general, blockchain transactions like T 1 …T i need to be signed because we need to know the source of the broadcast. Values like v 1 …v i submitted for timestamping need not be digitally signed, as a TSS says nothing about who sent v i –it just says that v i existed at time t i . Most often, a timestamp is for a document. The creator of a document Dcan compute a hash v¼h(D) and submit it to the TSS for timestamping. Later, existence of a timestamp (t,v) is proof that a document Dsatisfying v¼h(D) existed before time t(as it is impractical for anybody to create the document Dafter the timestamp for vwas obtained). This mechanism is useful for resolving copyright issues. 3.1 Checkpoints As we saw in the previous section, it is sufficient for ledger entries to be a sequence as transactions as in Equation (9). With this information, while anyone can determine the state of the system Snfollowing ntransactions, the overhead may be prohibitive for regular users, especially for large-scale systems with billions of process states. If it is possible to introduce “checkpoints”corresponding to process states like Si,Siþ1 before and/or after each transaction, then verification of correctness of any specific transaction will involve verification of correctness of the single state change: Si⟶ fjiTji i  Siþ1:(11) 113 Large-scale processes in a blockchain Nakamoto, S. (2008), “Bitcoin: a peer-to-peer electronic cash System”, October 31, available at: http:// nakamotoinstitute.org/bitcoin/ (accessed October 21, 2018). Oppliger, R. (1999), “Protecting key exchange and management protocols against resource clogging attacks”, in Preneel, B. (Ed.), Secure Information Networks, Springer, Boston, MA, pp. 163-175. Perrig, A., Tygar, J.D., Song, D. and Canetti, R. (2000), “Efficient authentication and signing of multicast streams over lossy channels”,Proceedings of the 2000 IEEE Symposium on Security and Privacy, May 14-17, p. 56. Ramkumar, M. (2014), Symmetric Cryptographic Protocols, Springer, Dubai. Wood, G. (2014), “Ethereum: a secure decentralised generalised transaction ledger”, Ethereum Project Yellow Paper, available at: https://github.com/ethereum/wiki/wiki/White-Paper Xu, K., Qu, Y. and Yang, K. (2016), “A tutorial on the Internet of Things: from a heterogeneous network integration perspective”,IEEE Network, Vol. 30 No. 2, pp. 102-108. Further reading ECDSA (2013), National Institute of Standards and Technology (NIST), Federal Information Processing Standard (FIPS) 186-4, July, pp. 19-26. Corresponding author Mahalingam Ramkumar can be contacted at: [email protected] For instructions on how to order reprints of this article, please visit our website: www.emeraldgrouppublishing.com/licensing/reprints.htm Or contact us for further details: [email protected] 120 JCMS 2,2