Key Expectations for Blockchain Accessibility: Integrity, Availability, and Privacy

Table of Links

Abstract and I. Introduction

II. Expectations of Blockchain Accessibility

III. Approach I: Maintain a Ledger Locally - Run a Full Node

IV. Approach II: Query a Third-Party Ledger-Node-As-A-Service (NAAS)

V. Approach III: Light Node - External Query & Local Verification

VI. Concluding Remark and References

II. EXPECTATIONS OF BLOCKCHAIN ACCESSIBILITY

The process for a blockchain user to retrieve information from blockchains is similar to using any web service, such as browsing websites (retrieving information from a web server), checking e-mails (retrieving information from a mail server), etc. Therefore, the security expectations match the standard security triad: integrity, availability, and privacy.

A. Integrity

For blockchain accessibility, integrity means that the user can obtain the correct information on blockchains under the given security model. Much of the existing research focuses on the integrity of the blockchains from the perspective of full nodes, guaranteeing integrity if the user has access to a trusted (e.g. self-owned) full node.

However, as more and more users turn to third-party service providers for information on blockchains, we notice that integrity may not be achieved if these service providers are untrusted. While some client protocols, such as Flyclient [10], ensure data integrity without much overhead, such techniques are not universally deployed on every blockchain or adopted by every service provider.

B. Availability

For blockchain accessibility, availability means that the user can freely access information on blockchains. Most incidents on third-party service providers revolve around availability [36] [39], and at least one vulnerability that creates a denial-of-service has been studied [35].

These cases of empirical evidence suggest that fully relying on a single third-party service may create availability issues. While it is industry practice to diversify and use several thirdparty services as backups of each other, it may also help if the user can employ a solution that does not rely on a single service but utilizes a group of nodes to ensure maximum availability.

C. Privacy

Privacy encompasses a broad range of cases available in this context: some users may want to conceal their queries from specific eavesdroppers to prevent frontrunning [17], while others may not want to be found using blockchains at all, with Bitcoin being illegal in some countries. These different concerns require drastically different security models that cannot be summarized in a nonspecific way.

Therefore, we devote our discussion of privacy in this paper strictly to the problems specific to blockchain accessibility rather than general Internet anonymity needs: an untrusted server of the network should have no information about the users’ queries and the results.

While existing Internet protocols such as HTTPS largely realize end-to-end confidentiality between the user and the trusted server, we note that if resolving the user’s query for information involves untrusted parties such as miners and third-party service providers, privacy is not trivially guaranteed and must be discussed on a case-by-case basis. For example, ConsenSys, the company that developed Infura and MetaMask, has claimed that when users use Infura as the default RPC provider in MetaMask, Infura will collect their IP address and Ethereum wallet address they send a transaction [15].