On Blockchain Auditability

White Paper

Facilitating auditability and accountability are major benefits of using blockchain technology. In thiswhite paper, we examine the notions of auditability, accountability and non-repudiation in blockchainsand focus on the aspects of blockchain technology that allow for these properties. We focus on blockchain receipts, blockchain anchoring, and proof of work as the means to provide non-repudiation andaccountability in permissioned blockchains that utilize Byzantine consensus. A technical descriptionto implement Bitcoin Blockchain anchoring for permissioned blockchains without reducing securityproperties is provided.

Version

1.0 (Nov 14, 2016)

2016 Bitfury Group Limited

Without permission, anyone may use, reproduce or distribute any material in this paper for noncommercial and

. original source and the

educational use (i.e., other than for a fee or for commercial purposes) provided that theapplicable copyright notice are cited.

Blockchain technology has been posited as a solution for various applications in the financialsphere, such as payment systems [1], securities trading [2], post-trade settlement [3], regulation [4],consulting and auditing [5, 6], etc. Furthermore, blockchains have been proposed for non-financialuse cases including public registries [7], copyright [8] and provenance [9, 10]. Pragmatically, thereason of blockchain popularity may be simple: financial services and other applications are ina need of modernization, and blockchain technology seems to provide a solution [11]. Thus, thecrucial question impacting the adoption of blockchain technology is whether the technology providessubstantial benefits compared to alternate digital solutions.Blockchains, as envisioned by Satoshi Nakamoto [12], combine the characteristics of three distincttechnologies: Byzantine fault-tolerant systems Digital timestamping services Currency ledgers using cryptographic primitivesOn its own, each of these technologies were studied well before Nakamotos publication. Byzantinefault tolerance (i.e., tolerance to arbitrary malicious behavior, including attempts to thwart the systemby an active adversary) was defined in 1980s [13, 14]; the practical Byzantine fault-tolerant (PBFT)algorithm [15], which is now frequently used as a building block for private blockchains, datesback to 1999. Digital timestamping i.e., notarizing digital documents, associating these documentswith reliable timestamps and establishing ordering among all notarized documents was exploredstarting in 1990s [16, 17]. David Chaums DigiCash [18] an electronic ledger extensively relying oncryptography primitives was founded in 1990 (and went bankrupt in 1998). It is the combination oftimestamping, replicated log and cryptography that made Nakamotos blockchain design innovative.The digital timestamping feature of blockchain technology is sometimes overlooked in blockchainstudies in favor of the other two aforementioned characteristics. In our opinion, this may lead to adistorted understanding of blockchain technology. If a blockchain is viewed only as a distributed faulttolerant system with embedded business logic (such as a currency), it may seem that all blockchainusers are equal; once we switch to the timestamping perspective, it becomes clear that this is notnecessarily the case. Namely, there are entities that determine the state of the blockchain (e.g.,a bank or a consortium of banks in a financial ledger; the registry agency in a public registry;insurance company or companies in an insurance network) and external users who do not participatein consensus, but would like to be sure that the blockchain is operated correctly (e.g., bank clients;immutable property owners; policyholders). An important category of external users are auditorsand regulators.One of the core features expected from timestamping services is accountability [19]. Accountabilitymeans that every user of a timestamping service can reliably verify that the service operates in theintended way (e.g., information provided by the service agrees with the information it provided toother users). If verification fails, the user has a proof of services malicious behavior, which could beOn Blockchain Auditability

used to hold the service accountable. Accountability may be lost if external parties are excluded fromconsideration when constructing the blockchain.Feasibility of external audits is one of attractive characteristics of permissionless cryptocurrencyblockchains such as Bitcoin. Bitcoin would not likely have gained as substantial popularity if itrequired each user to operate a full Bitcoin node to ensure the system operates correctly. In practice,the Bitcoin ecosystem allows each user to choose a fitting trust model to perform transactions: usinga full node, a lightweight (SPV) node, a non-custodial multisignature wallet or a trusted third party.User trust in the automatically enforced properties of a blockchain, instead of in the identities of itsprocessors (and by extension, trust in formally specified properties of services built on top of theblockchain instead of identities of the service providers) could be beneficial for both permissionedand non-permissioned blockchains. In other words, increased user trust could create an environmentfor even more third party service development and integration of blockchain technology.Another useful feature provided by blockchain technology is non-repudiation [20], i.e., the abilityto definitively verify authenticity of statements recorded on the blockchain. Non-repudiation couldbe accomplished with the help of digital signatures combined with public key infrastructure (PKI) [21]and reliable timestamping. The latter is important to prevent anyone (even the colluding blockchainmaintainers) from backdating statements and to make retrospective authenticity verification notcritically reliant on security of the utilized public key cryptosystem(s).Many proposed blockchain applications (currency ledgers, public registries, insurance, copyright,supply chains, etc.) could benefit from built-in external auditability and non-repudiation, as they arelegally required or at least expected by application users. External auditability of blockchains couldmake them a preferable means of computerization of such applications compared to alternatives.Furthermore, external auditability aligns with Web 2.0, i.e., the general shift from service-centric touser-centric applications (cf. the notion of self-sovereign identity [22, 23]). The ability for any clientto perform a partial or complete audit of the system could be viewed as a competitive advantagein the emerging user-centric world. Thus, auditability and accountability capabilities of blockchainsconstitute a promising topic for research.Previous research.

Accountability is one of core topics of the research on digital timestamping (see,

e.g., [19]). The Bitcoin white paper mentions reliable timestamping as one of the design goals of thesystem (Sections 3, 4 of [12]). Interestingly, the reference list in the white paper contains 4 works ontimestamping more than on distributed computations and e-cash cryptography combined.The topic of accountability was brought up in blockchain research with relation to the nothingat stake problem encountered by early proof of stake blockchains [24]; in fact, the problem couldbe viewed as a typical accountability failure. Later research on proof of stake codified the problemswith accountability with the notion of weak subjectivity [25]. Security deposits were introduced intoproof of stake to provide economic accountability of blockchain participants (see, e.g., Slasher [26],Tendermint [27] and Casper [28] consensus algorithms).

On Blockchain Auditability

Private blockchain concepts, mostly based on the PBFT family of consensus algorithms, frequentlydeclare auditability by external parties (i.e., accountability), often by introducing a special role ofauditing nodes in the blockchain network (see, e.g., IBM Open Blockchain [29]). However, researchanalyzing and quantifying blockchain accountability is somewhat lacking (see [30] as one of examples).As we show in this paper, Byzantine fault-tolerant design and presence of auditing nodes in the systemmay not be enough to provide meaningful accountability for all applications.Blockchain anchoring, which we consider in this paper as one of accountability measures, issimilar to the notion of attested append-only memory (A2M) [31] in providing additional security fordistributed consensus. Using the Bitcoin Blockchain as a means to provide accountability with thehelp of anchoring is explored by Proof of Existence [32], Factom [33], Tierion [34], Openchain [35],ChainDB [36], etc. Our description of anchoring a blockchain on the Bitcoin Blockchain in Section 3.3resembles that used in Factom and Openchain with the exception of the structure and authorizationof anchoring transactions.We have briefly described anchoring and proof of work as means to achieve accountability in ourwhite paper [37]. This work could be viewed as the extension and elaboration of that research.Our contribution. We consider auditing capabilities, accountability and non-repudiation for statemachine systems and define blockchains as a subtype of such systems that fulfill these properties. Thisconclusion is derived from the semantics of the word blockchain, as well as the design goals and linkedtimestamping roots of the Bitcoin Blockchain. Thus, our view of blockchains is narrower comparedto defining a blockchain as an atomic broadcast ([38]; a similar or even looser definition is commonlyused in non-specialized press). On the other hand, we do not limit accountability in blockchains toeconomic accountability provided by proof-of-work mining of native blockchain tokens.As means to implement auditability, accountability and non-repudiation, we describe blockchainreceipts (aka SPV proofs) and blockchain anchoring. We also examine proof of work in permissionless blockchains from the point of view of accountability. Both blockchain receipts and blockchainanchoring are well-known technologies; our contribution is in connecting them to accountabilityand, for blockchain anchoring, in reviewing implementations that would not compromise securityassumptions on the system.Contents. The rest of the paper is organized as follows. We describe auditability and accountabilityfor state machine systems in Section 1. In Section 2, we reason that replicated logs without a propersetup are not accountable and that blockchain design specifically addresses this issue; we also studyblockchain receipts as basic accountability measures. Section 3 describes traditional anchoring, proofof work and blockchain anchoring as means to increase accountability of blockchains. Section 4 isdedicated to an overview of alternative approaches to accountability and auditability. An analysis ofaccountability of alternative consensus algorithms used in cryptocurrencies is given in Appendix A.Finally, Appendix B offers a framework for estimating attack costs on blockchain anchoring.

On Blockchain Auditability

Basic Definitions

We start by giving basic definitions within the problem domain.

Definition 1. A state machine system [39] is a software product comprising: Data storage reflecting the system state in a certain domain (e.g., users balances in a ledger) Transactions, which are the atomic, linearly ordered, sufficiently small changes to the systemstate (e.g., value issuance or transfer in a ledger) Consistency rules allowing to assess whether the system operates correctly, i.e., accordingto expectations placed on it by its users. Consistency rules determine whether a particulartransaction is correct with respect to the current system state. Each transaction can be eithercorrect or incorrect, but not both or something in between. Incorrect transactions must not beenacted; any correct transaction can be enacted without compromising the systemIn essence, we assume that changes to a state machine system could be decomposed into smallpieces (transactions) applied in a sequential order, and the problem of ensuring the correctness of thesystem could be reduced to the computational task of ensuring the correctness of transactions. We alsoassume that consistency rules are objective and deterministic, thus can be automated. As an exampleof consistency rules, there are usually rules regarding system security [40] (e.g., all unauthorizedtransactions are incorrect).Definition 2. Auditing is a systematic and independent examination of a state machine system withthe goal of determining whether its operation is correct (according to the consistency rules) and wascontinuously correct in the past.We use the common definition of auditing [41] and confine it to state machine systems. Therefore,we assume that such computer systems in general can and should reflect objective reality; we rejecta nihilistic point of view that computer systems cannot automate auditing process, as the evolutionof computer technology proves the opposite. In this regard, we do not see substantial differencesbetween state machine systems and other data sources subjectable to auditing.The goal of auditing is to prevent or minimize system corruption, i.e., a failure of some enactedtransactions to agree with consistency rules. This goal could be achieved in several ways: Make system corruption technically impossible (tamper proofness) Make system corruption prohibitively economically costly for anyone to try (tamper resistance).Costs may come from various sources: System corruption may require bribing / corrupting many independent parties System corruption may require solving a difficult computational problem requiring nontrivial resources at attackers disposal

On Blockchain Auditability

Make system corruption easily and immediately detectable and the evidence of it independentlyverifiable and irrefutable (tamper evidence) Make system corruption irrefutably attributable to specific persons or organizationsExamples of state machine systems requiring auditing are financial ledgers (e.g., currency ledgersused in banking; securities ledgers operated by stock exchanges) and public state registries. There arethree main user roles in such a system: maintainers, auditors and clients (Table 1). The first two rolesare self-explanatory; we define clients as entities who initiate and authorize (whether directly or withthe help of trusted intermediaries) changes to the system state. The user roles may overlap; e.g., in apermissionless blockchain any client can act as an auditor and/or as a maintainer.Table 1: Core notions of auditable systems in various domainsProperty

DomainFinancial ledger

Maintainer

Bank(s), exchange(s)

Public registryGovernment agency

ProvenanceGoods manufacturer(s) orspecialized blockchainprovider(s)

Auditors

Internal auditors,

Government-appointed

regulators, law

auditors; NGOs

Customers

enforcementClients

Bank clients; securities

Citizens (e.g., immovable

owners

property owners,

Goods manufacturer(s)

copyright owners)System state

Balances of all clients;

State of all registered

state of contracts between

property

Registered goods

clientsTransactions

Value issuance and

Ownership change,

Goods issuance and

transfer

leasing

tracking

Examples of

The same asset does not

A property cannot be sold

Goods with the same tag

consistency rules

belong to two accounts

if its owner already leases

cannot be sold twice

(i.e., no double-spending)

it

1.1

Internal and External Audits

We assume that a state machine system could be subjected to two kinds of threats.Definition 3. Local threat is a threat corrupting a minor part of the system, so that operation of themajor part remains correct. System-wide threat is a threat corrupting the system in whole.An example of a local threat would be system components being corrupted by an external hackeror a rogue employee. An example of a system-wide threat is corruption of the bank ledger by thebanks executives in an attempt to hide its insolvency. Note that threats may be caused by operational

On Blockchain Auditability

errors committed by persons interacting with the system, and not necessarily by internal or externalmalicious activity.By discerning local and system-wide threats, we assume that the system can provide for a certaindegree of redundancy so that each transaction is checked by multiple independent verifiers; localthreats can corrupt only a certain minority of these verifiers. This assumption is not necessarily thecase: in some centralized systems, any local threat would realistically escalate to a system-wide threat.Assumption 1. Certain state machine systems necessitate continuous auditing of their operation bothby internal and external parties: The goal of internal audits is to ensure protection against local threats The goal of external audits is to ensure that the system operates according to expectations ofits clients and to the public interests, i.e., provide protection against system-wide threatsThe notion of accountability is closely related to the feasibility of external audits. Accountabilityessentially means that external users (auditors and, ideally, clients) have the means to timely detectsystem corruption attempted by maintainers, attribute such activity and provide unambiguous proofsof it that could be used publicly, e.g., in a court of law. Correspondingly, we will use terms externalauditability and accountability interchangeably.By confining ourselves to Assumption 1, we assume that:Assumption 2. The state machine system is anti-discretionary [42], i.e., there are objective consistencyrules governing its operation which cannot be changed at will by the system maintainers.Assumption 2 is true for regulated systems (public registries, banks, exchanges, etc.), in whichcase there are generally parties interested in the system auditability who do not maintain the system.For example, citizens may be interested in having an auditable immovable property registry withoutneeding to participate in the registry operation (which may be unwieldy for an ordinary citizen); thesame is true for bank or exchange clients. Another application area of Assumption 2 is peer-to-peerfinancial services (e.g., P2P lending and insurance). Naturally, cryptocurrencies are anti-discretionaryas well; indeed, the goal of cryptocurrencies is to completely abstract from the identities of systemmaintainers (so called trustless-ness property).At the same time, Assumption 2 does not hold for many ledger-like or registry-like systems (e.g.,an in-game currency ledger), in which external audits are superfluous or illogical because of trustedparties being inherent to the system design. In some other cases (e.g., a supply chain ledger or an interbank settlement system), the initial requirements on the system may not satisfy Assumption 2 as thesesystems may not require external auditing from the start. However, these systems may eventually fallinto the scope of Assumption 2 in the process of their evolution: It would be quite natural to use supply chain ledgers for determining taxation. In this case,ledger maintainers might collude to evade taxation

On Blockchain Auditability

Inter-bank settlement system could be fine-grained and include client accounts instead of bankaccounts, thereby attracting clients interest in the system auditability Inter-bank settlement system could be used by the regulator to assess systemic risks for theparticipating banksAn approach to automate internal audits by making a system fault-tolerant may be ineffective inthe case of external auditing. Here is why:Assumption 3. Maintainers of a state machine system may have a common interest to mislead anexternal auditor.This assumption is quite sound if a system is operated by a single entity even if the maintainedsystem is distributed. For example, a distributed bank ledger with separate nodes corresponding toregional departments could be secure against a rogue employee or a hacker (as it is reasonable toassume that the attacker cannot corrupt more than a couple of nodes); however, it could not be secureagainst the banks board of directors conspiring to mislead the regulator (as in this case, all bank nodesmay be rigged). Consortium systems may be prone to this kind of attacks too, as evidenced by practice[43, 44, 45, 46] and the following weak argument: if maintainers have reached the agreement to createand maintain a shared system, they may as well reach an agreement to rig it.The theoretical goal of external auditability would be to make the system completely auditable byany interested party (as there is always a possibility of institutional auditors colluding with systemmaintainers). The biggest reason why public auditability is not implemented for existing systems isthat it contradicts clients confidentiality and/or similar concerns (e.g., non-disclosure of trade secrets).Hence, auditing on behalf of the clients or public is performed by the designated auditors who have anon-disclosure agreement with the system maintainers. Therefore, we will keep in mind that: There should be means to perform a complete audit of the system A system should ideally provide public auditability insofar it does not contradict the declaredsecurity properties (e.g., clients confidentiality)In particular, we would like to implement the following simplest audit capabilities for the clients: A client may want to know all concerning transactions (e.g., incoming and outgoing valuetransfers in a ledger) and receive timely updates on these transactions A client may want to receive electronic receipts for concerning transactions and for the part ofthe state of the system concerning the client (e.g., clients balance in a ledger). The authenticityof an electronic receipt should be independently verifiable; it should be difficult to create a fakereceipt, both for a client and for system maintainersAnother property we would like to provide is non-repudiation, i.e., correspondence between thesyntax of transactions recorded in the system, and real-world semantics of these transactions. Forexample, we want to ensure that the timestamp of any transaction is accurate, and that it has beenOn Blockchain Auditability

indeed authorized by the entities purported by its syntax. Basic non-repudiation is a well-studiedproblem usually addressed with public key cryptography and secure key management (e.g., usingpublic key infrastructure with hardware tokens). A bigger challenge is retrospective non-repudiation,i.e., ensuring transactions remain non-repudiated if some keys (or even the whole underlying publickey cryptosystem) are compromised, and/or if the system maintainers may act maliciously. This kindof non-repudiation is especially important for public state machine systems, such as public registries.

1.2

Auditable Logs

We are now ready to define the core notion of our study: auditable systems.Definition 4. Auditable state machine system is a state machine system satisfying Assumptions 13and providing internal and external auditors with sufficient means to conduct online, periodic and/orby-request audits of the system in order to minimize the risk of system corruption.Auditability could be beneficial for system auditors since it provides them with data as to thestate of the system, which could be used to quickly identify or prevent system failures (e.g., bankinsolvency; damages incurred by a rogue employee). As audits and regulation in financial servicesare often performed on behalf of the system clients, they could indirectly benefit from the systemauditability as well.For system maintainers, profits from auditability are indirect and correspond to the inducedsecurity properties (e.g., counterfeit resistance, flexible regulation compliance framework, the offthe-shelf secondary market, and streamlined third-party application development capabilities in thecase of a digital asset ledger). The cost of implementing auditability could be substantially reduced byusing an existing blockchain as a cloud platform (PaaS) [47]; one may argue that external auditabilityis the enabling feature for the cloud deployment of auditable state machine systems.In order to build an auditable state machine system, we postulate that the entire history oftransactions is stored in a linear audit log. It is quite obvious that audits of a state machine systemcould be reduced to the audits of its log, as system states could be sequentially restored from the log.The approach with a linear log is commonly used in distributed computing in replicated logs (see,e.g., [48]). Blockchains are a subset of replicated logs. Replicated logs provide sufficient and wellstudied tools for internal audits; they enjoy correct operation even if a certain percentage of nodes inthe system behaves incorrectly. Thus, we will assume that audited systems are built using a replicatedlog as a starting point.Definition 5. A replicated log is auditable if it satisfies the following requirements:1. Log consistency: All changes in the system audit log are valid according to the consistency rules.(Note that it follows from this property that the system state is also valid.)2. State consistency: The state of the system corresponds to the state inferred by replaying alltransactions in the audit logOn Blockchain Auditability

3. Transaction finality: The audit log is append-only, i.e., transactions are never removed fromthe log, modified in the log or added to the log retroactively. The only possible operation isappending transactions to the end of the log4. Reliable timestamping: transactions in the log are reliably timestamped with a degree ofaccuracy sufficient for a problem domain5. Log uniqueness: The audit log is unique in the sense that all system users (including auditorsand clients) never receive conflicting logs or system states6. Blame ascription: It is possible to reliably identify parties failing to uphold to the propertiesabove (e.g., in the case several conflicting system states are presented to different users)7. Retrospective auditability: It is possible to check that properties 16 hold for any previousmoment of timeCompared to the requirements on auditable systems outlined in Section 1.1, we add two additionalrequirements deserving explanation: transaction finality and reliable timestamping.1.2.1

Transaction Finality

Transaction finality (also commonly referred to as log immutability) is a vital requirement for nonrepudiation. Indeed, compromised finality makes statements about transactions challengeable; e.g.,it becomes impossible to definitively state that a transaction has indeed occurred at the time impliedby its timestamp and ordering rather than was retroactively added to the log later.Transaction finality may seem to contradict transaction reversibility, which may be required bythe problem domain. For example, a bank may want to reverse transactions during a chargebackprocedure; a public registry may want to remove documents from the registry deemed falsified orotherwise void by a court decision. However, reversibility could be implemented without removingor modifying existing transactions in the audit log: In a financial ledger, a transaction may be logically reversed by creating a new transaction withthe equal value flow in the opposite direction. Special authorization may be introduced forreversing transactions (e.g., by encoding the corresponding logic into the smart contracts) forcompliance. For example, in the case of a centrally issued electronic currency the reversingtransaction may be authorized by the currency issuer instead of the sender More generally, a special type of transactions could mark a previous log transaction as voidSimilarly, log revisions that erase transactions entirely from the log, while more attractive to someparties, could lead to abuse of the system. A careful system design (e.g., anonymization of sensitivedata with the help of cryptographic commitments, public-key encryption and zero knowledge proofsof data integrity) could take better care of the issue.

On Blockchain Auditability

10

If there exists an ability for any party to revise the audit log, then the log no longer reflects allchanges to the system state, i.e., it ceases to be a single source of truth about the system. Thus, amutable log harms auditability, non-repudiation and increases risks of system corruption.1.2.2

Timestamping

As with transaction finality, timestamping is beneficial for non-repudiation. Timestamping could be

useful in financial contracts, establishing precedence for copyright, auction bids, etc. Transactions aretimestamped by the system maintainers since clients clocks are generally unreliable; it is assumedthat the accuracy of timestamping could be later verified by auditors.1.2.3

External Auditability Properties

Properties 57 from Definition 5 are fundamental for external auditability:

It is usually not enough for an auditor to check that a system seems to be correct now; he needsto be sure that it operated correctly in the past, prior to the audit Similarly, it is instrumental that the audit log presented to an auditor correspond to the audit logpresented to other users of the system. That is, system maintainers should not be able to craft aseemingly correct audit log specifically for the purpose of being audited If there are violations of the rules, they need to be attributable to specific entities, both for thepurpose of investigation and to discourage system participants from transgressionsAs we will see, these properties are substantially more difficult to implement than properties fromDefinition 5 corresponding to internal auditability.

22.1

Auditability in BlockchainsReplicated Log Structure

A generic replicated log consists of several servers, each of which maintains a local replica of the globallog. Changes to the log (i.e., transactions) are requests sent by clients. Servers and clients communicateamong themselves over an unreliable network, which may delay, lose, reorder or duplicate packets ofdata. Both servers and clients are identified within a certain public key cryptosystem; correspondingly,every message in the system is authenticated. Every replicated log implements a certain consensusprotocol in order to reach common understanding among servers as to the system state; the key partof consensus is establishing the complete ordering of all the transactions. Consensus usually impliesdynamic server roles (such as a Leader, Candidates and Followers in Raft), which change according tothe network state to maintain system liveness.Replicated logs are used for fault tolerance (i.e., there is a requirement for a system to remainoperational under the assumption that some hardware or software components may fail). There aretwo main types of fault tolerance explored in replicated logs:On Blockchain Auditability

11

Ordinary (non-Byzantine) faults include arbitrary network faults (duplicated and reorderedmessages, delays in message delivery, packet loss, etc.) and replicas being non-responsive, e.g.,because of hardware faults. Ordinary fault-tolerant consensus algorithms include Paxos [49]and Raft [48], which are implemented in many distributed databases Byzantine faults [13, 14] correspond to inconsistent behavior of replicas, whether caused bybenign faults or by an active adversary. Byzantine fault-tolerant (BFT) consensus algorithmsinclude PBFT [15], QU [50], Zyzzyva [51], RBFT [52], Aardvark [53], etc.Fault-tolerant systems have well-defined limits of tolerating faults. For example, it is impossibleto reach agreement with even a single faulty server if the system is deterministic and asynchronous,i.e., when message relay and processing can be arbitrarily slow [54]. Thus, the network is usuallyconsidered to be partially synchronous [55]: bounds on message relay and processing exist, but arenot known a priori1 . If there can be f simultaneously faulty servers in the system, the minimumnumber of servers required for a functional ordinary fault-tolerant system is 2f + 1; for a Byzantinefault-tolerant system, the minimum number is 3f + 1 [58].Because of the auditability requirement, the structure of an auditable log network differs fromthe client server model utilized for replicated logs. Instead, it includes 3 types of replicating nodescorresponding to three user roles described in Section 1: Consensus/maintainer nodes are nodes that participate in consensus. Each consensus nodemaintains the up to date system state and possibly (but not necessarily), the complete audit log.Consensus nodes may be identifiable if it is required by the consensus algorithm Verifying/auditing nodes are nodes operated by external auditors. These nodes do not take partin consensus, however, they maintain the complete blockchain. An auditing node can verify thecorrectness of all transactions or an arbitrary subset of transactions not known to the systemmaintainers; it may perform online verification of incoming blocks of transactions or verifytransactions on demand Lightweight nodes are nodes operated by clients in order to satisfy their needs in simplestaudits (Section 1.1). Lightweight nodes do not participate in consensus and do not store neitherthe full system state nor the full blockchain. Instead, a lightweight node replicates a chain ofblock headers and transactions concerning the client. Lightweight nodes could be identifiablein order to limit transactions the node has the access to. Semi-anonymous lightweight nodes ina public system could be implemented using Bloom filters [59], as in Bitcoin2It follows from the properties of BFT systems that a BFT replicated log with n consensus nodes mayprovide protection against local attacks in which the adversary controls at most (n 1)/3 consensus1

An alternative approach relies on a secure source of randomness [56, 38], which allows building a Byzantine fault-

tolerant consensus in a completely asynchronous setting. Another approach is to use failure detectors [57] that can tell withnon-zero accuracy whether a certain replica works properly.2

Note that Bloom filters as implemented in Bitcoin do not provide a sufficient level of privacy [60].

On Blockchain Auditability

12

nodes, making these attacks impossible to succeed under standard cryptographic assumptions. Inorder to provide full protection from local attacks, all components of the system need to be Byzantinefault tolerant with the expected degree of redundancy; if there are centralized components, such asan authorization verification module, they are required to be incorruptible.

2.2

Blockchains

Given the description above, it may seem that a BFT system with appropriate business logic couldbe effectively used to implement an auditable log as per Definition 5. The main obstacle is that BFTsystems are usually not adapted for external audits and do not mitigate system-wide attacks for thefollowing reasons: Replicated logs usually contain log compaction logic, which is detrimental in audits All consensus logic is internal to the servers, whereas external parties (including auditors) havea limited view of the system operation. For this reason, we would want for the audit log to recordvoting results for each consensus decision; it could help both in ascribing blame and verifyingthe correctness of the audit log retrospectively To complete any request, a client needs to receive a response from at least 1/3 of consensus nodes(e.g., at least 34 consensus nodes in a system with 100 such nodes). This drastically differs froma common practice when a client communicates with a system using a single entry point, suchas a website Log uniqueness is only partially addressed by BFT consensus. It is impossible to create analternative log if the system corresponds to the BFT threat model (i.e., there is no more than 1/3of faulty servers). However, the threat model itself may be inappropriate. If there is a possibilityof maintainer collusion (Assumption 3), then the maintainers can overwrite the log partially orcompletely at any time, present different versions of the log to various clients and auditors, etc.2.2.1

Transaction Blocks

Blockchain architecture solves problems with blame ascription, retrospective audits and interactionwith clients by grouping transactions into blocks (cf. checkpoints in PBFT). Consensus decisions aremade on the block level instead of the transaction level. Each block consists of two parts: relativelysmall block header, the size of which does not depend on the number of transactions in the block,and transactions. Transactions are committed to the block header, usually as a root of a Merkle tree[61] (Merkle root) since Merkle trees provide the optimal O(log N ) length of a proof of existence for atransaction included into a block with N transactions. A block header can also include: Reference to the previous block (a cryptographic hash of its header) Block timestamp Commitment to the state of the system (e.g., using Merkle Patricia trees [62, Appendix D])On Blockchain Auditability

13

Data allowing to independently verify the consensus. In a consensus with known validators (e.g.,Tendermint [27]), consensus-related data in the block header could be a set of digital signaturesof the previous block belonging to more than 2/3 of validators. In a proof of work consensus,consensus-related data is a nonce and the network difficulty; a block is valid if its hash is lessthan a threshold value determined by the network difficultyGrouping transactions into blocks is beneficial in several ways: Batching transactions decreases the number of messages sent over the network. Batching mayincrease delays in transaction processing, but the delay is acceptable for most applications Blocks boost the speed of verifying consensus decisions. The boost is particularly importantif these decisions are encoded as digital signatures, as operations with digital signatures arecomputationally costly compared to other parts of block header verification Blocks introduce a possibility of efficient simplest audits and lightweight nodes (see Section 2.4)Because of the block structure, a synchronizing node can reliably download blocks from any noderegardless of whether it participates in consensus. Thus, the network of auditing nodes could providea blockchain content delivery network (CDN) [63], which would distribute the load more evenly amongnodes replicating the blockchain in whole. Bitcoin demonstrates a well-developed auditing nodenetwork with over 5,000 auditing nodes [64]. The number is particularly impressive because auditingnodes in Bitcoin perform online validation of all incoming blocks.2.2.2

Autonomy

Another characteristic feature of blockchains is embedding authorization data into all transactions;i.e., for any transaction it is possible to determine who authorized the transaction. Authorization datais commonly represented as digital signatures, possibly of more than one party (e.g., multisignaturewallets [65]; cf. multi-factor authentication).More generally, blockchains are autonomous (i.e., minimizing reliance on external componentsas sources of truth), which makes blockchains good for external audits and strong non-repudiationpolicies. A scheme in which some transactions on a blockchain do not include any authorization datawould not be autonomous, as it would rely on unprovable and non-auditable (within the blockchain)assumption that authorization logic was properly executed when the transaction was made. If aPKI-based scheme is used for authorization, all PKI operations (adding a new certificate, revokinga certificate, etc.) should ideally be recorded into the blockchain otherwise the system becomescritically dependent on non-verifiable external assumptions.Consensus verification data in block headers could be viewed as another example of blockchainautonomy.

Similar to the example above, all changes to consensus nodes (adding a new node,

removing a node from consensus, etc.) should be recorded in the blockchain to increase auditability.With the autonomy property described, we are ready to define blockchains in terms of auditing.

On Blockchain Auditability

14

Definition 6. A blockchain is a replicated, autonomous, Byzantine fault-tolerant log with consensus

based on blocks that permits external auditing and lightweight nodes, and provides non-repudiationof the log entries.Note that support of external audits and lightweight nodes can be directly inferred from the veryterm blockchain (i.e., organization of an audit log as a linear sequence of blocks of transactions that arelinked within a block with the help of Merkle trees)3 . Autonomy and having multiple consensus nodesare implied in the Bitcoin white paper and could be useful in most practical blockchain applicationssince these features provide internal auditability and fault tolerance. Similarly, accountability andnon-repudiation are implicit goals of the Bitcoin Blockchain design and are achieved with proof ofwork and incentivization of the blockchain maintainers with the help of mining. We require theseproperties from blockchains, but do not enforce a particular way to implement them.In the following discussion, we will consider a subset of blockchains with identifiable consensusnodes (permissioned blockchains); blockchains with anonymous consensus nodes (permissionlessblockchains) are briefly considered in Appendix A.Definition 7. Permissioned blockchain is an (atomically) consistent blockchain with the identifiableconsensus nodes. Auditing and lightweight nodes in a permissioned blockchain may be identifiableaccording to security requirements on the system.Atomic consistency property [66] is required in order for blockchains to fully satisfy Definition 5with regard to transaction finality; BFT replicated logs with identifiable nodes are generally consistentby construction.

2.3

Accountability Threat Model

Per Section 2.1, permissioned blockchain designs take care of internal audits by making local attacksimpossible provided security parameters of the system are chosen correctly (e.g., each component ofthe system has an appropriate level of redundancy). Therefore, we need to analyze susceptibility ofblockchains to system-wide attacks.For the purpose of external audits, the system looks as follows: There is a monolithic constructof system maintainers, which supply audit nodes with properly authenticated blocks (e.g., by usingdigital signatures of 2/3 of the consensus node set, as in Tendermint). The attacker is the colludingmajority of system maintainers who control 2/3 or more of the consensus nodes. The goal of theattacker is one of the following: Audacity attack: make honest parties in the system accept an incorrect audit log Revision attack: retroactively modify the audit log and make honest parties accept the change Equivocation attack [31]: present various external nodes with the conflicting versions of theaudit log (e.g., in order to hide service insolvency)3

Compare with the term distributed ledger, in which replication (or, more generally, distribution of data) among several

consensus nodes is explicit, and other properties from Definition 5 may or may not apply.

On Blockchain Auditability

15

By eliciting these kinds of attacks, we assume, per A. Lincolns words, that the attacker cannotfool all of the people all of the time, i.e., cannot continuously lie to all clients and auditors in the samemanner for the prolonged period of time. If this assumption does not hold (e.g., if the blockchain inquestion has inappropriately lax consistency rules), neither blockchains nor alternative technologiescan mitigate an attack. Additionally, we do not analyze censorship attacks since they do not violateblockchain consistency rules if a blockchain is autonomous; as censored transactions are not reflectedon the blockchain, detecting censorship requires external sources of truth.For the purposes of this paper, we restrict our definition of an attack in the following ways: The consistency rules of the system are known in advance and cannot be changed by the attacker The attacker does not control auditing and client nodes; e.g., there are no backdoors allowing toskip rule checks for the logs corrupted by the attacker on auditor and client nodes The attacker does not control the network. In particular, he does not control communicationamong honest parties, neither can he delay the deliverance of messages to honest parties forprolonged periods of time. Attack duration is much longer than a typical latency of messagedelivery in the system The attacker can lie consistently for a long period of time, but only if doing so is computationallyand economically soundIn most cases, system-wide attacks cannot be considered impossible. We consider the attack thwartedif it is timely detected by honest parties and irrefutably attributed; this may prevent attacks by makingtheir consequences (e.g., legal action) unfavorable for the attacker. Additionally, we want to make thedirect attack costs as high as possible.The above restrictions on the attacker may be too optimistic. For example, an authoritarianstate government may coerce citizens to accept revisions to the blockchain-based public registryof immovable property and not be held liable despite compelling evidence; after all, blockchaintechnology is a human tool. Despite this, blockchain technology provides security aspects makingit beneficial even in the worst case: Because blockchain data is distributed to lightweight nodes and auditor nodes out of the controlof the attacker, the attacker would not be able to destroy the evidence pertaining to the state ofthe blockchain before the attack. The snapshot of the blockchain before the attack could still beaccessed by clients and independently verified as authentic As blockchains are based on universal mathematical laws instead of trust in system maintainers,clients appeal to courts could be more likely to succeed

2.4

Blockchain Receipts

Basic blockchain accountability could be provided with the help of blockchain receipts a particularkind of electronic receipts. The general idea of a blockchain receipt is to provide a succinct summaryOn Blockchain Auditability

16

regarding a particular transaction or a part of a system state authenticated by system maintainers.

Blockchain receipts are designed to be independently verifiable; e.g., they could be used by a clientto prove a payment or his balance in third-party applications. At the same time, receipts improveaccountability in the following ways: Blockchain receipts allow to efficiently verify that information provided to a client correspondsto the information provided to the system auditors The construction of blockchain receipts is such that malicious actions by system maintainerswould render previously issued blockchain receipts invalid, therefore negatively impactingperformance and increasing indirect costs of a system-wide attackIn order to deduce the framework for blockchain receipts, we use the following assumption.Assumption 4. There exists at least one correct auditing node in the network at each moment of time.Because the attacker cannot prevent auditing nodes communicating with each other, all auditingnodes will have the same version of the blockchain at all times. We assume the attacker cannot supplyan auditor with an incorrect version of the blockchain because that would provide the auditor withthe sufficient evidence of the attack.Theorem 1. Under Assumption 4, any system-wide attack defined per the threat model in Section 2.3involves presenting some clients with a version of blockchain different from the one presented to auditors.Proof.The attacker cannot present an auditing node with an incorrect version of the blockchain; hence,if an attack involves creating an incorrect audit log, it will differ from the version seen by the auditors.The attacker cannot revise auditors version of the blockchain, hence, if the attack includes log revision,it also creates several versions of the blockchain. If the attackers goal is to create several versions ofthe blockchain, the proof is self-evident.

Therefore, we can formulate the problem of thwarting a system-wide attack as follows.

Problem 1. The attacker provides system auditors with a cryptographically authenticated statement

A, A , where A is a full audit log, and A is its cryptographic authentication, and a client with anauthenticated receipt B, B . The client wants to be able to check whether B contradicts to A.If B is a free-form statement not tied to the blockchain in any way, the task of checking compatibilitybetween A and B could be difficult, especially if the blockchain is fully private, i.e., the client has noinformation about A. In this case, the client may verify B only by submitting it to the auditors, whichwould arguably take place only if the client is already suspicious about the system operation. In orderto simplify the check, receipts could be made electronic.Definition 8. A blockchain receipt (called SPV proof in other research) for a certain transaction is achain of block headers up to the block containing the transaction in question, together with the MerkleOn Blockchain Auditability

17

path [61] to the transaction and the transaction itself in the same digital form as used in the blockchain(Fig. 1). Similarly, a blockchain receipt for a part of the system state at a certain block is a chain ofblock headers up to the block, a path in the Merkle Patricia tree and the state itself in the digital form.

Previous block: Merkle root:

Previous block: Merkle root: root

root

.Tx1

Tx2

Tx3

Tx4

Tx5

Tx6

Tx7

Tx8

Figure 1: The structure of a blockchain receipt for a transaction Tx3. Hashes included into the Merkle path aremarked with fill

A blockchain receipt can be verified in several steps:

1. Check that a transaction or a system state in the receipt is valid on its own right2. Check that the hash of the transaction or the system state and the Merkle path in the receiptyield the same root hash as mentioned in the header of the corresponding receipt block Brec3. Check that each block header in the chain is valid according to the consistency rules (e.g.,properly authenticated)4. Check that the chain of block headers forms a link to the first blockchain block (genesis block)

Bgen specified by the consistency rules

5. Verify that auditors have the same state of the chain. This could be accomplished by supplyingthe hash of Brec to a web service maintained by an auditorAs per digital timestamping research, blockchain receipts could be made compact by introducing anon-trivial block linking scheme (i.e., by making each block reference a deterministic subset of previousblocks instead of the preceding block in the chain) [67, 19]. Linking schemes allow creating receiptswith O(log Brec .h) block headers, where Brec .h is the height of the receipt block in the blockchain.Because of the properties of Merkle trees, receipts are not falsifiable: it is impossible to create avalid receipt for a transaction or a part of the system state not present in the blockchain. It is alsoimpossible to construct two different sets of transactions or Merkle Patricia trees for the system state,which would hash to the same root. Blockchain receipts ascribe blame in the following sense: if the

On Blockchain Auditability

18

receipt is incorrect (on its own right, or together with some other receipts, e.g., as a result of a doublespend), or the chain of block headers in the receipt contradicts the one supplied to auditors, the blameis attributed to specific consensus nodes.In order to make blockchain receipts more compact, block headers could be made public. Thiswould not harm confidentiality, as block headers do not include any confidential information; inparticular, headers contain no recoverable information about transactions in the block or the systemstate. A public sequence of block headers could serve another purpose: if the access to block headersis anonymous, the attacker cannot create multiple blockchain versions, as any of the requests to readblock headers may belong to an auditor. Thus, block verification performed by clients would no longerrequire interaction with the auditors.With public block headers, a chain of block headers in receipts could be replaced with a singleblock header hash (and possibly the block height to facilitate lookups). Lightweight nodes essentiallyimplement this logic and collect client receipts together with replicating the chain of block headers.If a non-trivial block linking scheme is used, a lightweight node may skip downloading and verifyingheaders for blocks that contain no transactions related to the node (which, as stated previously, couldbe determined based on authentication or Bloom filters).If the attacker revises the blockchain, all receipts in the blocks following the modification becomeinvalid, because all hashes of succeeding blocks change. For this reason, it is not sufficient to includejust the block height into a receipt, as Merkle roots and/or Merkle Particia roots in some succeedingblocks after the attack may remain the same. All lightweight nodes effectively cease functioning aftera revision attack because they no longer accept block headers proposed by the attacker; because ofthe transaction finality property, any valid blockchain update would only append new blocks, and notreplace them. Depending on the problem domain, non-functioning receipts and lightweight nodesmay be harmful enough to deter a revision attack.

2.5

State Commitments

State commitments briefly described in Section 2.2 prevent a minority of malicious consensus orauditing nodes from withholding transactions from clients equipped with lightweight nodes. This isbecause nodes cannot fake state commitments; thus, withheld transactions would make the systemstate reported to the client inconsistent with that inferred by transactions received by the client.Example. Consider a blockchain implementing an electronic currency; a state commitment in thiscase could be implemented as a Merkle Patricia tree mapping all accounts in the system to theirbalance. Client Alice connects to a malicious node (Mallory) using a lightweight node. Another clientBob then sends to Alice some currency. If there is no state commitment, Mallory can easily withholdthis transaction from Alice; in order to detect foul play, Alice would have to connect to other nodes.On the other hand, if there is a state commitment containing all client balances, Alice can watch herbalance and request a proof that her balance is indeed committed in the block header. Because ofproperties of Merkle Patricia trees, Mallory will not be able to construct such a proof for the old AlicesOn Blockchain Auditability

19

balance once a transaction from Bob to Alice is included into the blockchain.

2.6

Whistleblowing

The setup described in Section 2.2 allows for effective whistleblowing in the case of malicious activitybeing perpetrated by system maintainers. A whistleblower can submit a fraud proof in the form ofcontradicting blockchain receipts (or, in the case of an equivocation attack, conflicting block headersat the same height) to the system auditors or leak the proof anonymously. Because of the structureof block headers and blockchain receipts, the revealed fraud proof does not require any additionalauthentication. A fraud proof warrants an investigation by the auditors, as it unambiguously signifiesthat the blockchain system is operating incorrectly: either the system maintainers are participating ina system-wide attack on the system, or an external perpetrator has successfully forged a fraud proof,which is only possible if he has compromised more than 1/3 of consensus nodes.

Increasing Accountability: Blockchain Anchoring

In some cases, Assumption 4 may be too optimistic. In particular:

Auditors may be non-existent, may not function properly (e.g., due to the collusion with theattacker) or not to perform sufficient blockchain checks The attacker may control all sources supplying block headers to users, correctly identify theorigination of each request and lie to them correspondingly. This is especially easy if access tothe blockchain is authenticated and provided exclusively by the system maintainersIn order to prevent system-wide attacks under these conditions, blockchains may utilize anchoringand/or proof of work described below. Even if the system falls under the optimistic assumptions,additional measures to increase accountability, especially anchoring, could be quite cost-effective andwould help diversify the security of the system.Anchoring and proof of work help against equivocation and revision attacks; on their own, theydo not prevent system maintainers from including contradicting transactions into the blockchain(audacity attacks in Section 2.3). Intuitively, audacity attacks may be overcome either by havingfunctioning auditing nodes, or by using a public blockchain with encrypted sensitive data (Section 4.2).

3.1

Generic Anchoring

In traditional timestamping services, service accountability can be accomplished using anchors. An

anchor is a cryptographic hash of the current system state (in terms of blockchains, the latest blockheader) published using an anchoring service usually a printed medium (e.g., a newspaper). Anchorsare published periodically, e.g., daily.In a timestamping scheme with anchors, a user can check the existence a link between the receiptblock Brec and any anchored block Banc (which may be situated in the blockchain before or afterOn Blockchain Auditability

20

Brec ) and ensure that the anchor is indeed present in the printed medium. A link between Brec andBanc could be provided interactively by system maintainers; in the case the sequence of block headersis public, it could be obtained non-interactively. In the simplest case, the link is the chain of blockheaders between Brec and Banc ; using linking schemes, it is possible to shorten the length of the linkto O(log |Brec .h Banc .h|). In order to increase reliability of the result, the verifier may try severalanchored blocks Banc ; verification must succeed for all of them. To ensure accountability, it sufficesfor every client to check a link to the first anchor published after Brec [19].Because of the blockchain construction, it is infeasible to create a link from an anchored block toa block not present in the same chain. Thus, it is guaranteed that all receipts with the receipt blockup to the latest anchor belong to the same version of the blockchain. On the other hand, receiptscreated after the latest anchor are unreliable in the sense that the attacker may produce seeminglyvalid receipts for data on several alternative chains (Fig. 2).

Balice

Genesis.block

Banc

Bsplit

Anchor

Bbob

Figure 2: Seemingly valid, but contradicting receipts provided by EveBank for clients Alice (with the chain ofblocks ending at Balice ) and Bob (with the chain of blocks ending at Bbob ). To produce contradicting receipts,EveBank creates two versions of the blockchain with the split starting at the block Bsplit , which is locatedafter the latest anchored block Banc . Any anchor checks performed by Alice and Bob will succeed, despitethem seeing different versions of the blockchain. Notice that in order to perform the next anchoring,EveBank needs to choose a single blockchain version; thus, at least one of Alices and Bobs receipts willbecome invalid after the next anchoring.

The security of anchoring comes from the following assumptions:

The printed medium is publicly available, meaning verification could be performed by any user Each copy of the printed medium contains no more than a single anchor The printed medium cannot identify its reader and display different anchor values to differentreaders (i.e., demonstrate Byzantine behavior). Creating separate versions of the medium forspecific readers may be risky and economically costly In order to retroactively modify the blockchain, the attacker would need to reprint all mediumcopies after the retroactive modification and destroy the existing ones. This could be practicallyinfeasible or very costly for a comparatively popular printed media

On Blockchain Auditability

21

While these assumptions are sound, using printed media for anchoring has certain drawbacks. Mostprinted media are issued no more often than daily; thus, the pool of unreliable latest transactions notsecured by an anchor may be quite large. Additionally, accessing anchors in printed form could beinconvenient; it introduces the human factor into the verification procedure.Publicly available block headers replicated by auditors and lightweight nodes could be viewed asa particular case of anchoring. If the blockchain is replicated only by the auditors, and clients are notaware of blockchain data, the anchoring procedure is no longer effective against equivocation attacks;as the auditing nodes are identified within the system (either explicitly or implicitly as all nodes exceptfor the consensus nodes), the colluding system maintainers can provide the auditors with consistentlyfalsified information.Timestamping authorities (TSAs) [68] could be treated as a subtype of anchoring services. A TSAis a trusted third party providing reliable timestamping; in the blockchain context, one or more TSAscould be used to periodically timestamp the latest block header. Utilizing TSA services in a blockchainsystem does not solve the problem of accountability completely, simply shifting it from the blockchainmaintainers to the TSAs. Furthermore, TSAs introduce additional trusted parties into the system.Nevertheless, TSAs could complement the accountability measures described below, as well as employthese measures themselves.Anchoring provides retrospective non-repudiation even if a public key cryptosystem used by theblockchain (but not hash functions used for linking transactions) is compromised4 . In this case,anchors can help provide a definitive answer whether a given blockchain receipt was produced atthe implied time. As it is currently understood, quantum computers would compromise presentlyused public key cryptosystems (e.g., RSA and elliptic curves), but not hash functions; therefore, nonrepudiation provided by anchoring can be quite meaningful.

3.2

Proof of Work

In the blockchain design proposed by Satoshi Nakamoto, accountability is achieved without relyingon third-party anchoring services, which is specifically addressed in Sections 3, 4 of the Bitcoin whitepaper. Instead, Nakamotos design relies on proof of work (PoW): the cryptographic hash of each blockheader treated as an unsigned integer needs to be less than a specific threshold which depends onthe consensus-based network difficulty. The difficulty is automatically adjusted to keep the expectedtime interval between blocks constant (10 minutes in Bitcoin). The consensus algorithm assumes theblockchain with the greatest cumulative block difficulty as valid.System maintainers in PoW blockchains are not identified for consensus. The maintainers areincentivized with cryptocurrency native to the blockchain, by discovering (mining) valid blocks (blockreward), and by including transactions into a block (transaction fees).PoW consensus design and miner incentivization provides economic accountability:4

Non-repudiation accounting for possible weaknesses in hash functions may be achieved by utilizing measures akin to

those described for evidence records in RFC 4998 [69].

On Blockchain Auditability

22

As the blockchain is fully public, conflicting versions of the blockchain are easily detectable System maintainers spend real-world resources (e.g., electricity) on proof of work. Therefore,equivocating is measurably costly; playing against the rules would result in system maintainerslosing their revenue. Similarly, retroactively modifying the blockchain requires resources toproduce a blockchain that overrides the blockchain produced by honest system maintainersThe cost of retroactively modifying a PoW blockchain measurably increases with time passedsince the intended modification (i.e., PoW blockchains are designed with long-term non-repudiationin mind). The older the modified transaction, the more computational work to create a blockchainaccepted by honest nodes (Appendix B; cf. the number of issues needed to be reprinted and swappedduring an attack on printed media anchoring).Because PoW is secret-free (i.e., its security is not contingent upon non-disclosure of information,such as private key material when using public key cryptosystems), there is no way to reduce attackcosts short of breaking the hash function that PoW is based on. Compare with traditional financialsystems, in which the attack costs can be substantially reduced with access to secrets and/or negligenceby the personnel responsible for the manual verification of transactions (for an example, see thecompromise of the SWIFT network in 2016 [70]).In order to remove, add or modify a sufficiently old transaction (>1 day old) from the PoWblockchain, an attacker would need to:1. Acquire enough proof-of-work mining equipment in order to compete with the honest systemmaintainers. Rational maintainers are unlikely to participate in long-term attacks on the system,as it would cause substantial problems with the blockchain operation for a prolonged periodof time and would therefore negatively impact the price of the blockchain cryptocurrency.Therefore, cryptocurrency rewards obtained as a result of the attack is unlikely to cover attackcosts for the participating maintainers.2. Provide infrastructure for the mining equipment (electricity supply, cooling, datacenter housing,etc.). Mining process could need to be geographically distributed for fault tolerance.3. Operate the mining equipment continuously for a long period of time in order to override theblockchain produced by honest transaction processors. If the attacker has two times the hashrateof honest system maintainers, he needs the same time as the age of a modified transaction at thestart of the attack (e.g., a 1-year long attack for a year-old transaction) [37].Thus, the cost of a long-term attack is proportional to the cost of mining equipment securing thePoW blockchain. In blockchains with memory-hard proof of work (e.g., Ethereum), mining is mostlyperformed on general-purpose GPUs; therefore, an attacker could decrease attack costs by rentingequipment for the attack duration, acquiring it with the help of botnets or selling the equipment afterthe attack is accomplished. In the case of Bitcoin, the attack cost is increased by the fact that miningequipment is highly specialized. The expenses on designing, producing, and maintaining bitcoinmining equipment necessary for a long-term attack would be prohibitively high for many practicalOn Blockchain Auditability

23

applications (they could be estimated as a billion US dollars), and they steadily increase as a result ofmarket competition among bitcoin miners.

3.3

Blockchain Anchoring

Observe that requirements on anchoring services described in Section 3.1 are similar to that ofauditable logs. Indeed, an anchoring service requires (anchor) finality, reliable timestamping anduniqueness capabilities. Therefore, it could make sense to use another blockchain as an anchoringservice, provided that the latter is public and sufficiently distributed (in order to prevent crafting datafor a particular user) and is accountable on its own. As shown in Section 3.2, blockchains with proof ofwork (e.g., Bitcoin) satisfy accountability without requiring anchoring. Thus, these blockchains couldbe used for blockchain anchoring.Definition 9. Anchored blockchain is a blockchain that requires anchoring (e.g., a public registry).Target blockchain is a PoW blockchain that acts as the anchoring service (e.g., the Bitcoin Blockchain).The basic blockchain anchoring procedure is as follows.1. Obtain the compact form of the current state of the anchored blockchain, i.e., a cryptographichash of the header of the latest block in the anchored chain2. Create an anchoring transaction for the target blockchain authorized by the supermajority ofconsensus nodes specified according to security assumptions on the anchored blockchain. Perordinary Byzantine fault tolerance assumptions, the anchoring transaction should be authorizedby more than 2/3 of consensus nodes3. Broadcast the anchoring transaction to the target blockchain, or send this transaction directly toknown maintainers on the target blockchain who may provide a SLA for anchoring4. Wait until the anchoring transaction is sufficiently confirmed according to security assumptionsfor the target blockchain. For example, a Bitcoin transaction may be considered practically finalafter it has 6 confirmations [71] (i.e., when there are 5 blocks built on top of the block includingthe anchoring transaction)5. (Optional) Add into the anchored blockchain an SPV proof for the placement of the anchoringtransaction on the target blockchainAnchoring could be performed periodically (e.g., every 30 minutes). Depending on the problemdomain, blockchain anchoring could be considered mandatory for blockchain validity (e.g., the blockchain may be considered invalid if no anchor was produced for the latest 12 hours). Otherwise, afailure to produce anchors for the extended period of time could warrant the investigation by theauditors and carefully worded alerts for the clients.Compared to traditional medium anchoring, blockchain anchoring has the following advantages: Blockchain anchors could be verified automatically by auditing and lightweight nodes (e.g., byusing a lightweight node for the target blockchain) and be more accessible than printed anchorsOn Blockchain Auditability

24

Blockchain anchoring could be significantly more frequent, meaning there is less non-anchoredtransactions at each moment of time Blockchain anchoring is measurably cheap (its price per anchor is generally determined bytransaction fees on the target blockchain) and permissionless, meaning anchoring could beperformed without reaching an agreement with the anchoring service Blockchain anchoring could provide more measurable attack costs than traditional anchoring Blockchain anchoring allows for easier anchor authorizationAs we argued in Section 3.2, the Bitcoin Blockchain is the most resilient among PoW blockchainsin terms of attack costs. The attack would most likely fail to be covert because of the necessarypreparations and, in any case, would fail to covertly replace the anchors (as the target blockchain isfully public), therefore defeating the attack purpose. An analogue of this attack in the case of printedmedia anchoring would be an attacker buying the printed media or disrupting its operation; in bothtraditional and blockchain anchoring, such an attack would be obvious to the auditors and clients.The rest of the section will be dedicated to anchoring on the Bitcoin Blockchain specifically.3.3.1

Anchoring Transaction

The structure of anchoring transactions is determined as a part of consensus rules on the anchoredblockchain. In the basic case, the anchoring transaction consists of one input and two outputs.The transaction spends on transaction fees a certain number of bitcoins associated with an addressjointly managed by consensus nodes. (We consider below two practical approaches of joint addressmanagement: Bitcoin multisignatures and threshold ECDSA signatures, each of which has its ownpros and cons.) The change is returned to the same address or another address also jointly controlledby consensus nodes. Besides the change output, the anchoring transaction contains a provablyunspendable RETURN output, which is used to store the anchored information. The approximatestructure of this output is as follows: A short string serving as an identifier of the anchored blockchain (4 bytes) Height of the anchored block to facilitate anchor verification (4 bytes) Anchored block header hash (32 bytes)The consensus rules should determine all anchoring transaction contents except for authorization.For example, the consensus rules should deterministically select an unspent transaction output forspending in the case several are available, transaction fees, etc. Authorization of the anchoringtransaction generally requires interaction among the consensus nodes and thus needs to be a partof the consensus algorithm.

On Blockchain Auditability

25

3.3.2

Bitcoin Multisignatures

The most straightforward scheme for Bitcoin anchoring is to utilize Bitcoin multisignature transactioncapabilities [65]. In this scheme, every consensus node on the anchored blockchain independently3f +1

f is the maximum number of Byzantine nodes in the system and 3f + 1 is the minimum number ofconsensus nodes required to tolerate this number of Byzantine failures.) Public node keys pk1 , pk2 , ,

pk3f +1 are then publicly announced in order to facilitate audits; they may be certified by certificateauthorities. A pay-to-script-hash is formed from the public keys:HASH160 HM EQUAL,where HM is the 20-byte hash of a standard multisignature script, which allows for a transaction tobe authorized by any 2f + 1 consensus nodes:

HM = hash160({2f + 1 pk1 pk2 . . . pk3f +1 3f + 1 CHECKMULTISIG}).

(Hereafter, figure braces in Bitcoin Script correspond to the parts of the script jointly serialized asa single data item.) HM determines Bitcoin address M jointly managed by the consensus nodes,which is used to pay transaction fees for anchors. The balance of the address could be replenishedautomatically or manually by maintainers of the anchored blockchain or by third parties.To authorize an anchoring transaction, consensus nodes independently sign it and submit thesignatures, which are then agreed upon as a part of the consensus (Fig. 3). In a PBFT/Tendermint-likeconsensus, agreement could be reached within one block after the block being anchored. Indeed,during voting for the next block Bnext after the anchored block Banc , consensus nodes can shareamong themselves individual signatures on the anchoring transaction similarly to the signatures on

Banc (which are to be included into Bnext ). When Bnext is finalized, the set of signatures on theanchoring transaction for a supermajority of consensus nodes is finalized as well. After that, thetransaction can be submitted into the Bitcoin network by any consensus node.Inputs

Ichain is the anchored chain identifier; Banc .h and H(Banc ) are the height and the hash of the anchoredblock, respectively. Signatures j are agreed upon among consensus nodes as a part of the consensusalgorithm on the anchored blockchain.

On Blockchain Auditability

26

In practice, Bitcoin native multisignature capabilities are somewhat limited by anti-DoS measuresput forward by the notion of standard transactions [72]. Non-standard transactions are commonly notrelayed by Bitcoin nodes; most bitcoin transaction processors currently create blocks with standardtransactions only. According to the current Bitcoin specification [73], standard transactions cancontain no more than 15 public keys in a single multisignature, which effectively yields the restrictionon the number of Byzantine nodes f 4. Correspondingly, Bitcoin multisignatures could be onlyused for anchoring blockchains with a small number of consensus nodes. Even if the restrictionsput forward by standard transactions are lifted, anchoring transaction size linearly increases withthe number of consensus nodes on the anchored blockchain; i.e., managing anchoring transactionsbecomes more complicated.3.3.3

pk is produced by the supermajority of consensus nodes (Fig. 4).

Inputs

Outputs

(Amount: balance)

Amount: balance fee

Script: pk

Script: DUP HASH160 hash160(pk)

EQUALVERIFY CHECKSIGAmount: 0Script: RETURN {Ichain Banc .h H(Banc )}

Figure 4: The structure of the anchoring transaction using threshold ECDSA signatures. Braces correspondto the parts of Bitcoin Script jointly serialized as a single number. Signature for the transaction input isobtained as a part of the consensus algorithm on the anchored blockchain.

Threshold signatures use Shamirs secret sharing technique [77] to distribute shares of the privatekey sk corresponding to pk , among the consensus nodes. During signing, every node creates a partialsignature, which are then exchanged among nodes to compute the combined signature keyed by pk .Unlike native Bitcoin multisignatures, threshold signatures are interactive (i.e., require cooperationamong the consensus nodes to be produced); thus, the time and computational resources spent onproducing a combined threshold signature could be greater than in the case of Bitcoin multisignatures.The threshold signature protocol described by Gennaro et al. [76] satisfies Byzantine fault toleranceassumptions, i.e., can tolerate up to f Byzantine faults in the system with 3f + 1 nodes. Therefore,threshold signatures could be used for authorizing anchoring transactions without relaxing securityassumptions on consensus nodes. To further increase resilience of the signing scheme, the thresholdsignature protocol allows proactively refreshing private key shares among consensus nodes while

On Blockchain Auditability

27

keeping the combined private and public keys the same [78].Compared to native Bitcoin multisignatures, threshold signatures are more compact. The size ofanchoring transactions does not depend on the number of consensus nodes; thus, threshold signaturescould be used for anchoring blockchains with hundreds of these nodes. This improvement is achievedat the cost of requiring O(f 2 ) dedicated computations performed on each consensus node [76].3.3.4

No Multisignatures

A simpler version of anchoring could be obtained by relaxing fault tolerance of the process, i.e., notrequiring a 2/3 supermajority of the consensus nodes to form an anchoring transaction on step 2 ofthe procedure on p. 24. For example, anchoring transactions could be submitted by a single consensusnode rotated according to a certain protocol, as it is performed in Factom. Compared to the faulttolerant methods described above, single-node anchors may require more communication amongnodes and may necessitate out-of-band methods to interpret certain events (e.g., if a consensus nodesubmits an anchor of a seemingly incorrect blockchain state).

44.1

Alternatives and Improvements

Trusted Hardware

System maintainers could install untamperable hardware security modules (HSMs) [79] that can becertified by the system auditors. These HSMs could implement the blockchain logic in whole or inparts; e.g., an HSM could provide consensus logic and associated digital signatures for the blockchain.The HSMs could be periodically inspected by the auditors and/or provide the auditors with onlineupdates via encrypted channels that cannot be tampered with by the system maintainers.One could say that proof of work hardware is a special type of HSM, the operation of which istransparent to external observers, as proofs of work are impossible to fake and are easy to verifywithout compromising security of the system. At the same time, most of operations performed byordinary HSMs (e.g., digital signing) rely on trusting the HSM properties (such as the impossibilityto extract a private key from the HSM) that can hardly be verified remotely and independently. Ingeneral, the HSM approach could be seamlessly combined with other accountability means, includingblockchain receipts, anchoring and proof of work.

4.2

Fully Public Blockchain

Instead of making the chain of block headers public (which is proposed in Section 2.4 to decreasethe length of blockchain receipts), the whole blockchain could be made public, thus allowing everyinterested party with sufficient computational resources to act as an independent auditor. The conceptof partial verification nodes [12] is aimed to provide accountability with the moderate amount ofcomputational resources allocated for each auditing node. A partial verification node verifies a

On Blockchain Auditability

28

comparatively small percentage of transactions (e.g., 1%); in the event incorrect blockchain operationis discovered, the node broadcasts a fraud proof functioning similar to ones described in Section 2.4.The mentioned approach is utilized in cryptocurrency blockchains, such as Bitcoin. Solutionsdeveloped by the cryptocurrency community provide confidentiality of transaction amounts and/ortransacting entities [80, 81, 82], obfuscation of relations among clients (hierarchical deterministicwallets [83], Bitcoin payment protocol [84]), confidential smart contracts [85], etc. We expect for new,more mature solutions in the area to emerge in the short to medium term. These solutions wouldallow to prevent audacity attacks (Section 2.3) that cannot be addressed by blockchain anchoring.

4.3

Blockchain as a Service

Instead of deploying an application-specific private blockchain, some applications may utilize existingblockchains (whether permissionless or permissioned) as a specialized cloud platform blockchain asa service (BaaS); see [47] for a description of a BaaS platform for digital asset management. From theeconomical point of view, blockchain as a service may be a more cost-effective and secure solutionfor small and medium enterprises compared to the deployment of an application-specific blockchain;moreover, in the former case, the enterprise could benefit from the network effect, availability ofthird-party blockchain applications, etc. On the other hand, BaaS solutions may not be viable becauseof domain-specific requirements; e.g., a public registry could hardly be organized on a permissionlessblockchain (at least in the nearest future) because of the legal obligations of the registry maintainer.The accountability in BaaS is partially relegated to third parties (system maintainers of the BaaSblockchain). The BaaS maintainers guarantee transaction finality, reliable timestamping, blockchainuniqueness, etc. If the customer base for the BaaS is diversified, maintainers could be less likely toperform system-wide attacks on the system for the sake of a single application than in the case thesame application is hosted on a separate blockchain, as the discovery of the attack would have anegative effect on the system in whole.Application-specific accountability in BaaS could be achieved with the help of expressive means ofthe underlying blockchain and cryptographic primitives such as Merkle trees. For example, solutionsby G. Maxwell [86] and J. Bonneau et al. [87] both provide tools for bitcoin exchanges to prove theirsolvency while preserving a sufficient level of confidentiality.

Conclusion

Accountability and universal auditing capabilities are strong points of the blockchain design proposedby Satoshi Nakamoto. The term blockchain is derived from a hash-based linking among transactions,the main purposes of which are: Make blockchain revisions and equivocation detectable and costly (i.e., ensure accountability ofblock producers) Enable audits by computationally and space-constrained lightweight clientsOn Blockchain Auditability

29

Thus, the term blockchain puts an emphasis on accountability, whereas some proposed alternativeterms (e.g., distributed ledger) focus on distribution and sharing of data (for which alone blockchaintechnology may not be necessary). In the light of calls for service transparency and accountability,boosted by computerization and the spread of the Internet, blockchains could provide a necessaryframework to implement these properties.In the Nakamotos design, the accountability of system maintainers is obtained through economicalmechanisms, meaning that the attack costs could be independently assessed with a reasonable degreeof accuracy. An alternative approach Byzantine fault-tolerant replication offers tamper proofnessfor a substantial range of attacks by an external computationally bounded adversary, but does notprovide a clear estimate of attack costs, which critically depend on the security of node identification.Additionally, Byzantine fault tolerance on its own is not effective against attacks perpetrated by thecolluding system maintainers; without a proper setup, such attacks cannot be timely detected byclients and auditors. The allure of blockchain technology lies in providing protection against thesekinds of attacks and attaining in this way a greater degree of transparency and accountability.In this paper, we demonstrated how accountability is implicitly present in proposed blockchaindesigns that use BFT replication, and how it could be augmented with the help of blockchain receiptsand anchoring (including blockchain anchoring). Blockchain receipts and anchoring provide thetamper evidence property, i.e., timely detection of attacks on the blockchain system (including attacksperpetrated by the system maintainers). Anchoring on a PoW blockchain also provides tamperresistance, i.e., a measurable economic expense required to even attempt an attack on the system.These security properties, together with tamper proofness against external threats, could justify theuse of blockchains in a variety of security-sensitive applications, including scenarios with a blockchainbeing used as a specialized PaaS.Blockchain receipts could provide a basic level of accountability and serve as an alternative totraditional receipts. Using linking schemes inspired by timestamping services and/or publishing thechain of block headers (which contains no recoverable confidential information about the blockchainoperation) could make blockchain receipts compact and easy to verify. Receipts together with anchoring could provide strong guarantees for non-repudiation, including the case when a public keycryptosystem used by the blockchain system is compromised.Blockchain anchoring does not require substantial expenses from system maintainers and at thesame time provides a substantial degree of resilience against attacks. The Bitcoin Blockchain is themost cost-effective blockchain for anchoring because of the greatest network hashrate and the use ofASIC-friendly proof of work. Anchoring could be deployed on a blockchain together with traditionalanchoring on printed media, trusted timestamping and/or hardware security modules in order todiversify security and accountability of the system.As an auxiliary accountability service, blockchain anchoring does not constitute a single pointof failure. Even in the extraordinary event that the blockchain with anchors ceases functioning orundergoes a hostile takeover, the anchored blockchain would continue normal operation, as the event

On Blockchain Auditability

30

would be observable and interpretable in the same way by the system maintainers, auditors andclients. Thus, blockchain anchoring could be used in applications without sacrificing availability.

Appendix A Accountability in Permissionless Blockchains

The popularity of Bitcoin has given rise to other cryptocurrencies, with various consensus algorithmsand, correspondingly, varying accountability of participants (Table 2). The main three approachesto consensus in cryptocurrencies are proof of work (PoW), proof of stake (PoS) and the web of trust(WoT) approach; there are also hybrid consensus models using proof of work and proof of stake.Accountability properties of PoW were considered in Section 3.2. First proposed PoS versions, in whichevery cryptocurrency holder can create blocks with the probability proportional to his balance, sufferfrom impaired accountability (so called nothing at stake problem). We address the reader to [24, 88]for the analysis of simple PoS schemes and their comparison with PoW. In the more advanced versionsof proof of stake (referred to as deposited-based, or punitive, proof of stake DPoS), consensus nodesmake security deposits, which are confiscated in the case of incorrect behavior. The consensus weightof a node is proportional to the amount of the deposit. Deposits address the accountability problemand make accountability in delegated PoS measurable in terms of the blockchain cryptocurrency (cf.mining equipment and electricity costs in PoW both measurable in terms of the real-world resources).Finally, in the WoT approach, each client selects a set of nodes he trusts; thus, accountability is trustbased and does not differ much from existing financial services and other applications, in whichblockchains could be used.Table 2: Accountability and a category under the CAP theorem [89] for various kinds of consensus algorithmsused in permissionless blockchains. Availability is understood more loosely than in the general case (seein text)ConsensusProof of work

ExamplesBitcoin, Ethereum

CAP categoryAP

(Ethash), Litecoin

AccountabilityEconomical through proof of work;deviations from the protocol make amaintainer waste real-world resources

Proof of stake

Peercoin, Nxt

AP

(simple)

Impaired nothing at stake; deviations

from the protocol are easy

Delegated proof

Tendermint,

of stake

Ethereum (Casper)

CP

Economical through deposits; deviations

from the protocol make a maintainer losein-blockchain currency

Web of trust

Ripple, Stellar

CP

Trust-based

Blockchain utilizing PoW or simple versions of PoS do not fully satisfy Definition 5 of auditablelogs; they allow for blockchain reorganizations, thereby not enjoying atomic consistency. Intuitively,the consensus algorithm not making any assumptions about the behavior of consensus nodes cannotbe atomically consistent. Indeed, in such systems, it is impossible to discern a network split with theOn Blockchain Auditability

31

case when the substantial portion of consensus nodes has permanently abandoned their duties. Thus,the best course of action of consensus nodes that perceive a split from the majority of the network isto continue working, taking for granted the risk that their work may be voided after partition healing.Therefore, PoW and PoS blockchains fall under the AP (available and partition-tolerant) categoryunder the CAP theorem, with availability redefined per the realities of permissionless blockchains asthe finite time for a transaction with sufficient fee to be included into a block; if we required for thenetwork to process all transactions in finite time as per the ordinary definition of availability, it wouldbe vulnerable to transaction spam. DPoS and WoT consensus algorithms achieve consistency at thecost of identifying nodes and/or assuming their fault tolerance: DPoS algorithms identify nodes to assign them weights according to security deposits. The realworld identities of consensus nodes may or may not be known; intuitively, stakeholders withlarge security deposits in a popular DPoS system would probably have known identities In WoT systems, consensus nodes are identified in order to build trust relationships. Intuitively,the real-world identities of the consensus node owners should be known, as it would be strangefor users to trust the nodes otherwiseProof of stake and web of trust blockchains are not as attractive as a medium for anchoring asproof of work blockchains. Indeed, PoS itself suffers from impaired accountability, and WoT givesan inherently subjective view of the system. DPoS blockchains could potentially be better in thisregard, although long-range attacks for them could be easier than for PoW blockchains [88]; presentlythere are no DPoS blockchains that could offer the same level of economic accountability as Bitcoin.Additionally, neither (D)PoS nor WoT algorithms are secret-free like PoW. Their security depends onsecrets in the form of private keys, which are necessary for identification of accounts in the case of(D)PoS and identification of trusted nodes in the WoT approach.

Appendix B

Cost of Attack on Blockchain Anchoring

Assume an attacker decides to retroactively modify the anchor on a permissionless cryptocurrency

blockchain that utilizes proof of work (e.g., the Bitcoin Blockchain). In order to accomplish this,the attacker would need to overwrite the blockchain starting from the block containing the targetedanchor. According to proof-of-work blockchain consensus rules, the attacker would need to producean alternative chain of blocks with more cumulative proof of work than that created by honestmaintainers. Furthermore, the attacker would need to keep his version of blockchain secret untilit becomes preferable to the blockchain generated by the honest part of the network. An ordinarymajority attack (e.g., censoring all blocks not generated by the attacker) does not change the blockchainhistory, hence it would not accomplish the attackers goals.Note that the attack would have obvious issues: Full nodes would retain the version of the blockchain maintained by the honest miners after theattack. Thus, existing blockchain users (including the users of the anchored blockchain) wouldOn Blockchain Auditability

32

be able to verify that the attack took place, significantly diminishing its utility for most use cases(cf. anchoring on printed media, the successful attack on which would necessitate unnoticeablyswapping existing printed issues of the medium). The attack itself would require significantamount of preparation, further diminishing the chance to accomplish it covertly Because the attack would be highly noticeable, the attacker would be unlikely to gain profit fromselling mined cryptocurrency, as its exchange rate would probably significantly drop after theattack. Hence, it is unlikely that the attack would be supported by rational maintainers on thetarget blockchainAssume that the attack begins at the moment t = 0, and the attacked anchor corresponds to

that h and g are both monotonically nondecreasing: t h(t)

The initial cumulative difficulty handicap of the attackers chain is =

0ta

g(t) dt. The attack

ends at the moment such that the cumulative difficulty of the attackers chain reaches that of thehonest network, i.e.,

h(t) dt = +0

g(t) dt.

(1)

h(t) dt min

(2)

The attack costs

J(h, ) = R + Ch( ) + O

consist of three factors:

R, measured in $, are inelastic capital expenses on the production of hashing equipment C , measured in $/(GH/s), are elastic capital expenses of developing, producing and deploying aunit of hashing equipment O, measured in $/GH, are operating expenses of maintaining a unit of hashing equipmentNaturally, R, C and O are positive.Observe that the integral part of (2) can be simplified using (1), resulting in a one-sided optimalcontrol problem for the control h:

J = R + O + Ch( ) + Og(t) dt min,h0

h(t) dt = +g(t) dt;0

h(0) = 0;

s.t.

(3)

t (0, ) h(t) 0.

Rather than trying to solve this problem in the generic case (which can be accomplished numerically),we examine a simple partial case.Assumption 5. h(t) = h is constant on the interval (0, ] (i.e., the attacker starts the attack after aninitial equipment procurement and does not increase the amount of the equipment during the attack).

On Blockchain Auditability

33

The transition to the constant attackers hashrate may be justified by the following observation.Statement 1. The constant attackers hashrate h(t) = h is optimal in (3) for any fixed .Proof.Assumption 5 leads to the constraint (1) simplified as

Minimizing J in (4) for , we obtain

Statement 2. If g(t) is continuous, Equation (6) has the only solution on the interval (0, +).Proof.

J( )= Og(0) + limlim +0 +0

Cg(0) C 2

)= .

As g(t) is a nondecreasing function,

J( )

()()

CCCO+g( ) 2 +g( ) dt = Og( ) 2 > 0 with +.

Hence, J/ has different signs on the ends of the explored interval, and since it is a continuousfunction, there is at least one point , at which J( )/ = 0.Next, observe that (6) has the same solutions on (0, +) as the equation

2 J

O g( ) + C g( ) C C2

g(t) dt = 0.

(7)

Differentiate the left part of (7) for :

()() g( )2 J

= O 2 + C+ 2O g( ) > 0 0,

because g/ 0, and g( ) > 0. Hence, the left part of (7) monotonically increases meaning that (7)and (6) may have no more than a single solution. This completes the proof.

On Blockchain Auditability

34

Consider the simplest instantiation of the honest hashrate function g(t): constant g(t) = g0 for all

from which the optimal attack duration = C/Og0 , and the optimal expenses

J = R + O + Cg0 + 2 O Cg0 .|{z} |{z}J0

Jconst

A part of expenses J0 can be viewed as the costs spent on anchor security by the honest minersby the time t = 0, and Jconst is the additional penalty. A much-desired property is that Jconst can becomparable to J0 , i.e., costs spent on securing the anchor are significantly less than the costs to attackit (Fig. 5).

13R

Attack costs J Security costs J0

12R11RCosts

10R9R8R7R6R5R0

0.5

1.5

Anchor age ta , years

Figure 5: Costs to attack anchoring on a blockchain with the static honest hashrate g0 depending on the anchorage ta . It is assumed that the cost factors in (2) R = Og0 1 year = Cg0 /4, which is by our estimations closeto the current distribution of the factors for the Bitcoin Blockchain.