Executing large-scale processes in a blockchain

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 modi ﬁ cations 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.


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 A of 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: signed by A, and broadcast at time t i , is for transferring (from wallet A), x Bitcoins to wallet X, and y Bitcoins to wallet Y.
The transaction T i is deemed well-formed only if x + y ⩽ a, where a is the unspent balance in wallet A before 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." 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.

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 miners to ensure correctness of entries is that a 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

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 simpleit is simply a mechanism to quantify certainty in the chronological order in which two events occurred.Specifically: More specifically, given two sequences of bits (or bit-strings) x, y, where h( ) transforms a preimage x A {0, 1}* (bit-string of any length), to a digest y A {0, 1} n (bit-string of fixed length n), one can conclude with a very high degree of certainty that "x existed 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( ) is the 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.

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 A and B provide 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 A and B will be different in both forks (A is the beneficiary of the mined Bitcoins in one fork and B in 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.
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 predicatesin 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.

Merkle hash tree
A binary Merkle (1987) hash tree (Merkle, 1987) of depth d has 2 i nodes at each of the depths 0 ⩽ I ⩽ d nodes.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 nodesa left child and a right child.Specifically, an internal node u k i at depth k is related to its two child nodes where L is a leaf.Thus, for any leaf L there is a sequence of d hash operations f bt ( ), namely: which outputs the root r of the tree.For example, consider leaf L d in Figure 1 with leaf node The sequence of d ¼ 3 hash operations are as follows: In Equation ( 4), the fact that the output of f bt ( ) is r is proof that "the leaf L (and the VOs u i of L) should have existed before the root r was computed."In other words, given (a tree with) root r, this constitutes proof of existence of the leaf L and 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 L in the block can be demonstrated by providing a set of log 2 N VOs 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 L to 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′→r is 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 Notes: Gray shaded nodes u 2 ; u 0 and u 1 are complementary to (hatched) leaf node 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.

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}, i is 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, i and i n are respectively the highest and lowest keys (i ¼ i n for a collection with a single item).
An item with key j can be inserted only if no item with key j currently exists.Nonexistence of key j can be demonstrated by demonstrating existence of a leaf {i, i n , v i } such that:

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: 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.

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 n is not a power of 2, the tree may be seen consisting of up to log 2 n complete subtrees.For example, after 18 intervals (n ¼ 18), the tree can be seen as consisting of two complete subtreesa tree with 16 leaves, and a tree with 2 leaves.Note that the number of ones in the binary representation of n is 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 g to 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) K A 0 , and creates a hash chain fK A 0 Á Á Á K A L g, where: From the properties of h( ), given K A i it is trivial to compute K A j X i (by repeated hashing j − i times), but impractical to compute K A j o i .The tail value of the chain K A L is the "public key" of A. It is associated with two additional values: an absolute value of time T and a time interval Δ.The interpretation of this association is that "K A LÀi will remain A's secret until time T + iΔ."A hashed message authentication code (HMAC) for a message M and secret K, namely, μ ¼ HMAC(M, k), is typically a token accompanying a message M. The receiver with knowledge of K on 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 s M ¼ HMACðM ; K A LÀi Þ for a message M using value K A LÀi from the hash chain was seen before time t ¼ T + iΔ.Later, after time T + iΔ, the value K A LÀi from the chain is disclosed, satisfying s M ¼ HMACðM ; K A LÀi Þ.This is proof that σ M could have been computed only with the knowledge of K A LÀi (and only the creator of the chain A could have had knowledge of K A LÀi before 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 M by 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.

Blockchain processes as an FSM
The FSM model of process P with dynamic process states S can be represented as d: I Â S/S where δ represents a next-state function triggered by unconstrained input I.In practice, any process P can be defined as using a set of (say) m next-state functions f 1 ( ) … f m ( ).

JCMS 2,2
In a blockchain, inputs that trigger execution of next-state functions are broadcast transactions of m different types.Specifically, execution of a next-state function f j ( ) is triggered by a transaction T j i of type j, broadcast at some time t j i .Function f j ðT j 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 P due to a sequence of transactions T j 1 1 ; . ..; T j n n can be represented as follows: In Equation ( 8), S 0 is the initial state of the process, and T j i i is the ith "well-formed" transaction of type j i A {1 … m}.Given the initial state S 0 , and descriptions of functions f 1 ( )…f m ( ), the state S n is 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: 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 x from an account A to 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" t to a value v to 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: 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 iit just says that v i existed at time t i .Most often, a timestamp is for a document.The creator of a document D can 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 D satisfying v ¼ h (D) existed before time t (as it is impractical for anybody to create the document D after the timestamp for v was obtained).This mechanism is useful for resolving copyright issues.

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 S n following n transactions, 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 S i , S i þ 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: 113

Large-scale processes in a blockchain
An OMT is useful for creating such checkpoints.Specifically, if all process states are considered as leaves of an OMT, then two values s i and s i+1 can be seen as commitment to process states before and after the transaction.More specifically, s i is the root of an OMT whose leaves represent process state S i ; s i+1 is the root of an incrementally updated OMT, whose leaves represent process states S i þ 1 .
In the proposed approach, process states, and all nodes of the OMT with process states as leaves, need to be maintained only by incentivised users.Ledger entries corresponding to every transaction include OMT roots like s i and s i+1 .
As long as regular users have reliable access to any ledger entry, and if it is possible for users to determine which specific process states were implicated (read/updated or inserted/deleted) in the transaction, they can check the correctness of the state change, by obtaining Oðlog 2 NÞ VOs from incentivised users.

An example
As an example, consider a ledger entry: where T is a transaction that occurred at time t.According to the ledger entry, transaction T required the system state (OMT root) to be updated from s to s′.Assume that the purpose of this transaction T ¼ [B, x] A was to transfer an amount x from an account A to account B.
The process states (leaves of a tree) implicated in this transaction are: (1) a leaf L A ¼ {A, A n , a} showing current balance a in account A, and A n as the next account number; and (2) a leaf A state-change function is f( ), where s⟶ f T ð Þ s 0 checks if the transaction is well-formed.
According to f( ), transaction T ¼ [B, x] A is considered well-formed only if it is signed by A, and if the balance in account A, a ⩾ x + m + f, where m is a minimum balance requirement, and f is a transaction fee.Following the transaction, the two leaves need to be updated to (A, a′) and (B, b′), respectively, where a′ ¼ a − x − m − f and b′ ¼ b + x.In other words, using: (1) values A, B included in the transaction T; and (2) auxiliary values I ¼ {a, A n , b, B n , VOs} provided by an incentivised user (from leaves and nodes of the OMT maintained by the incentivised user).
Any regular user can determine that the state change s→s′ is correct, only if the following predicates are true, namely: (1) leaves L A ¼ {A, A n , a} and L B ¼ {B, B n , b} exist in a tree with root s; and (2) leaves exist in a tree with root s′.

A scalable blockchain platform
In the broad outline of a scalable blockchain platform in Figure 2 for executing any number of possibly unrelated large-scale processes, two separate ledgers are maintaineda TSL and a process ledger (PL).Blockchain broadcasts of two types, namely, transactions and TESLA MACs (which are signatures for transactions to be broadcast at a later time) are timestamped and entered in the TSL.In practice, a small number of portals may exist for users to submit broadcast packets for timestamping.Transactions in the TSL are then processed in a chronological order to create PL entries.

Timestamp ledger
Two types of broadcasts that are timestamped include: (1) [μ, t′]: a TESLA signature (MAC) μ along with an expected time t′ when a transaction (for which μ is a signature) will be sent; and (2) [T, ∑]: a signed transaction T along with signature ∑; in the signature ∑ ¼ {S, K, j, n, t mac }, K is jth value in the nth TESLA chain of sender S; t mac is the time at which the MAC was timestamped earlier.
The operator of each portal batches the requests into regular intervals.The operator timestamps each request, and computes an accumulated hash of all (now timstamped) requests received during the current interval.At the end of the current interval, the operator signs the accumulated hash as proof of acceptance of all requests during the interval.The portal broadcasts the stream of all timestamp requests received during the interval along with the accumulated hash and signature for the interval.
The process for creating the TSL involves collating all timestamp requests from possibly multiple portals, and creating blocks corresponding to uniform intervals of time, say Δ tl .Each entry in a block (a Merkle tree leaf ) can be a timestamped TESLA MAC (t μ , μ, t′), or a timestamped transaction (t T , T, ∑).
For creation of the TSL one entity is declared to have the power to resolve ambiguities in consensus.Merkle tree roots v tl 1 ; v tl 2 ; . . . of blocks created in this fashion (at a fixed rate) are used to construct a hash calendar with dynamic commitment g tl .

Notes:
Two types of timestamp requests are timestamped by portal operators p 1 ... p n .Timestamp requests are collated and used for creating timestamp ledger (TSL) blocks, where each block corresponds to an interval of length tl .The commitments to TSL blocks v i tl , v 2 tl ,... are TSL entries made at a constant rate (1/ tl ) to create a hash calendar with commitment tl .Execution of transactions (t T , T, Σ) in the TSL (signed using a MAC entry (t, , t′ t T ), also in the TSL) triggers state changes, resulting entries of the form {(t T , T, s, s′)} added to in uniformly spaced process ledger (PL) blocks (corresponding to intervals of length pl ); commitments v i pl , v 2 pl ,... to PL blocks are PL entries made at a constant rate (1/ pl ) to create a hash calendar with commitment pl Large-scale processes in a blockchain 4.2 Blockchain processes and PL Timestamped signed transactions (t T , T, ∑) in the TSL are processed by incentivised users to create PL entries.The first step toward this is the verification of signature ∑ ¼ {S, K, j, n, t mac }, using TSL entry (t mac , μ, t′ ≈ t T ).Incentivised users, who continuously monitor the broadcast channel, may simply cache broadcasts like (t T , T, ∑), (t mac , μ, t′) that are intended to be added to TSL to avoid the overhead of actually accessing the TSL.The process for signature verification using ∑ and μ is outlined later in Section 4.3.
Transactions with good signatures are processed to create PL entries.Every process has a unique identifier Θ.Every process is defined by a set of m state-change functions Broadcast transactions T that trigger a state-change function d Y i ð Þ explicitly identify the process Θ, function index i and the sender (who signed the transaction), in addition to other process specific values.
The unique process identifier Θ is the root of a static hash tree.The leaves of the static tree are static descriptions of state-change functions Þ can be seen as a mapping: where: (1) T is the triggering transaction with a timestamp t T ; (2) I are auxiliary values that are not included in the transaction, but are available to incentivised users who maintain all OMT leaves and nodes; (3) the OMT root s is the commitment to the process states before the transaction T; and (4) the OMT root s′ is the commitment to the process states after the transaction T.
Successful execution of a state-change function results in the creation of an entry in the PL.More specifically, the PL consists of blocks created at regular intervals of time, where each block consists of multiple entries of the form: All well-formed transactions occurring in a specific interval of time are added to a single block as leaves of a hash tree.The sequence of roots of such trees v 1 , v 2 , v 3 , … (one corresponding to each block) is added to the ledger at regular intervals of time using a hash calendar.Incentivised users may choose to maintain an additional log of auxiliary values I necessary to verify preconditions and postconditions for every transaction.
Given a ledger entry, {t T , T, s, s′} any user can verify the validity of the signature ∑ by fetching the timestamped MAC μ from the TSL.The user can then proceed to verify the correctness of the state change in exactly the same manner as an incentivised user, except that auxiliary values I necessary to verify that preconditions and postconditions are demanded from an incentivised user.

Infrastructure for digital signatures
Timestamped transactions of the form (t T , T, ∑) in the TSL are first verified for a consistent signature ∑ ¼ (S, K, j, n, t mac ).The process for verifying a signature utilizes another TSL entrya timestamped MAC of the form (t mac , μ, t′) where t′ ≈ t T was the expected timestamp of the transaction T. Conveying the expected time t′ is merely to permit incentivised used to cache MAC μ in anticipation.Regular users, however, have the additional overhead for fetching a TSL entry.
The signature ∑ ¼ (S, K, j, n, t mac ) for T is deemed legitimate only if the following predicates are true: (1) the nth chain of user S, associated with a commitment c, start-time T and interval Δ, has not been revoked; (2) μ ¼ h (T, K) and t mac o T + jΔ, where (t mac , μ, t′) exists in the TSL; and (3) the result of hashing K repeatedly, j times, is c.
The infrastructure for maintaining parameters associated with different chains of users is itself a blockchain process/application with a unique identifier, say Θ ∑ .4.3.1 Process Θ ∑ states.Every user is associated with a long-term public identity, which is the same as the commitment to the first hash chain created by the user.The user can later create any number of hash chains with different start times and intervals, and bind commitments to such chains to the user's long-term identity.Three different transaction types for this application are employed by users to create their long-term identity, certify new chains and revoke chains.
The states of the process for maintaining hash chain parameters are represented using leaves that represent key-value pairs of the form: where item keys are concatenations of a long-term key S and a chain index i.The value of an item with key S:i is a concatenation of five values: (1) a commitment c to chain i (where c ¼ S for i ¼ 1); (2) interval Δ; (3) start-time T; (4) a value R, whose preimage needs to be disclosed by the user S to revoke the chain; and (5) the time t r at which the chain was revoked (which is set to 0 for an unrevoked chain).
To join the blockchain network: (1) a user generates her first chain K 0 … K l of any length, and chooses appropriate values of interval Δ and start-time T; S ¼ K l will ultimately become the user's long-term identity; (2) the user chooses a random R 0 and computes R ¼ h (R 0 ), and stores R 0 and K 0 in a secure location; and (3) the user computes a MAC μ ¼ h(K n , Δ, T, R, K i ) where K i is a secret from the hash chain (usually K l−1 ), and submits the value [μ, t′] for timestamping while K i is a secret.The value t′ is an estimate of time at which the certificate (for which μ is the signature) will be submitted.
Let the timestamp obtained for μ be t mac .Around time t′, the user submits a transaction T (indicating process Θ ∑ and function index i ¼ 1 for creating the first chain) along with a signature ∑ s , where: As no entry exists for user S yet, the verification of the signature for this transaction is considered as a special case.If entry (t mac , μ ¼ h (T, K i )) exists in TSL, and if t mac o T + jΔ, and if hashing K, j times, yields S, the signature is accepted as valid. 117 Large-scale processes in a blockchain 4.3.2Process Θ ∑ transactions.The predicates (preconditions and postconditions) for different Θ ∑ transactions are as follows.
Transaction type 1 is for creating the first chain for a new user.Type 2 is for creating the nth chain where n W 1 chains.Type 3 is for revoking the nth chain.If the OMT roots of the process Θ ∑ are s and s′, respectively (before and after a transaction), the preconditions and postconditions for each transaction can be expressed as follows: Timestamped transactions of the form (t T , T) in the TSL with valid signatures (from a sender S) are triggers to state changes.The precondition for a type 1 transaction from a user S is that no entry should exist for key S:1, which is demonstrated by the existence of an item for key x with next-key y, such that S:1A x; y ½ .The postcondition is that an entry for index S:1 is added with values Δ, T, R included in the transaction.
The precondition for adding the nth chain (transaction type 2) for S is the existence of the n−1th chain for S, with next index x satisfying S:n A S:nÀ1; x Â Ã .The postconditions include modification of the next index x in the existing item, and introduction of a new item for key S:n with next index as x.
The precondition for revoking the nth chain is that the value R 0 included in the transaction should be a preimage of a value R in the certificate of the unrevoked nth chain for S. The postcondition is that the time of revocation is updated from 0 (for an unrevoked chain) to the transaction time t T .

Selective audits by regular users
Let T b be the start-time of the both blockchain ledgers (TSL and PL).As users know the current time, they are aware of the current number of blocks (say n t , n p ) in both TSL and PL.
If, for example, n ¼ 274 ¼ 100,010,010 b (where bits 9, 5 and 2 are one) the user expects a calendar hash g n to be accompanied by two values r 5 and r 9 , satisfying: If the next time the same user utilizes the ledger is at a time when n′ ¼ 308 ¼ 100,110,100 b the user expects g 0 n along with values r 0 3 ; r 0 5 ; r 0 6 and r 0 9 where r 0 9 ¼ r 9 ; r 0 5 ¼ r 5 , and r 5 ¼ r 0 5 and r 3 should be nodes in a tree with root r 0 6 .VOs for verifying this fact can also be demanded from active users.
Thus, using a calendar hash permits intermittent users to check the validity of the current calendar hash against previously known values.Consequently, passive users store only minimal state information (past commitments to log 2 n calendar hashes), and are not required to fetch every single block to verify the validity of the current calendar hash g n .
The trust in the correctness of g n can be leveraged verifying the commitment v i to any block in the past, by requesting up to log 2 n VOs.With trust in the correctness of v i , the user may demand the entire block, or a specific entry, or the last m entries, etc., along with VOs for existence proofs in a tree with root v i .
Once users have authentic copy of a specific leaf in a specific PL block, namely, a PL entry {t, T, s, s′}, they can proceed to check the correctness of the state change s→s′ triggered by transaction T as described in Section 4.2.

Conclusions
Blockchain networks offer a universally trusted computing platform, which can be leveraged to replace (or, at the minimum, limit the role of ) high-overhead infrastructures like banks, insurance and governments.
Utilizing the full ability of blockchain networks calls for explicit mechanisms to reduce/eliminate ambiguities, to promote universal consensus (to avoid forking); low overhead strategies for selective audits, to ensure that even intermittent users can readily follow the correct fork (in the event a fork occurs); and mechanisms to reduce susceptibility of the broadcast network to clogging attacks.
An architecture for a scalable blockchain platform and cryptographic protocols underlying the architecture were proposed to address three major concerns that affect scalability of blockchains.
Figure 2. A scalable blockchain for executing large-scale processes