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

Ultimately, any blockchain accessibility solution has to decide on a split of responsibilities: either the user does most of the computation necessary or some third party does. A spectrum of solutions may be developed based on different types and needs of users, from a full node to a full third-party service. However, we consider that any solution must still adhere to reasonable security expectations: integrity, availability, and privacy.

Most blockchain research is based on the assumption that users run their local nodes. This means the fact that running a full node is still the best way to provide integrity, availability, and privacy. Indeed we surveyed third-party service providers in the field and noted the lack of a data integrity guarantee when the provider is not trusted. We also recalled events that render the providers unable to provide service. These facts mean that third-party service providers can and do fail, and thus relying on them can become risky.

At the same time, considering the high cost of running a full node locally, we believe that users should have more choice that does not impact the security guarantees. We observe the emergence of so-called ultralight nodes, which provides a way for third-party services to give a verifiable statement that requires little hardware power from the client.

Many open questions remain regarding the accessibility of blockchains, even regarding full-node solutions and third-party providers. Any number of light node protocols can also be built to serve different users’ needs.

We reiterate that ensuring the accessibility of blockchains is paramount for the technology. If we believe that blockchains are a common good, then making them accessible to all in a secure and available manner is critical for the future development of Web3 technology. Any information is as useful as how it can be read, and such reasoning also applies to blockchains.

REFERENCES

[1] AL-BASSAM, M., SONNINO, A., AND BUTERIN, V. Fraud and data availability proofs: Maximising light client security and scaling blockchains with dishonest majorities. arXiv preprint arXiv:1809.09044 (2018).

[2] ALCHEMY. Alchemy. https://alchemy.com/, 2022.

[3] ALL THAT NODE. All That Node. https://allthatnode.com/, 2022.

[4] ANKR. Ankr. https://www.ankr.com/, 2022.

[5] BADDOUR, R. Setting up a Litecoin super node: A complete step-bystep recipe that anyone can follow. https://medium.com/@baddour/sett ing-up-a-litecoin-full-node-a-complete-step-by-step-recipe-that-anyon e-can-follow-fb18b82d5cfe, 2022.

[6] BINANCE. Binance. https://www.binance.us/, 2022.

[7] BITCOIN PROJECT. Minimum requirements. https://bitcoin.org/en/ful l-node#minimum-requirements, 2022.

[8] BITCOIN PROJECT. RPC API reference. https://developer.bitcoin.org/ reference/rpc/#, 2022.

[9] BLOCKDAEMON. BlockDeamon. https://blockdaemon.com/, 2022.

[10] BUNZ, B., KIFFER, L., LUU, L., AND ZAMANI, M. Flyclient: Superlight clients for cryptocurrencies. In 2020 IEEE Symposium on Security and Privacy (SP) (2020), IEEE, pp. 928–946.

[11] CHAINSTACK. Chainstack. https://chainstack.com/, 2022.

[12] CHATZIGIANNIS, P., BALDIMTSI, F., AND CHALKIAS, K. Sok: Blockchain light clients. In International Conference on Financial Cryptography and Data Security (2022), Springer, pp. 615–641.

[13] CLEPER, Y., AND BINDER, G. Lava: A decentralized RPC network for blockchains - litepaper v0.1. Tech. rep., Lava Protocol Inc., 2022.

[14] COINCASHEW. How to run your own Monero node. https://www.co incashew.com/coins/overview-xmr/guide-or-how-to-run-a-full-node, 2022.

[15] CONSENSYS. Privacy policy. http://web.archive.org/web/2022112109 5716/https://consensys.net/privacy-policy/, 2022.

[16] CRYPTO.COM. Crypto.com. https://crypto.com/us, 2022.

[17] DAIAN, P., GOLDFEDER, S., KELL, T., LI, Y., ZHAO, X., BENTOV, I., BREIDENBACH, L., AND JUELS, A. Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability. In 2020 IEEE Symposium on Security and Privacy (SP) (2020), IEEE, pp. 910–927.

[18] DASH CORE GROUP. Masternode requirements. https://docs.dash.org/ en/stable/masternodes/understanding.html#masternode-requirements, 2022.

[19] DATAHUB. DataHub. https://datahub.figment.io/, 2022.

[20] DENNIS, R., AND DISSO, J. P. An analysis into the scalability of bitcoin and ethereum. In Third International Congress on Information and Communication Technology (2019), Springer, pp. 619–627.

[21] ELECTRIC COIN COMPANY. Troubleshooting guide. https://zcash.read thedocs.io/en/latest/rtd pages/troubleshooting guide.html, 2022.

[22] ETHEREUM FOUNDATION. Ethereum portal network. https://www.ethp ortal.net/, 2022.

[23] ETHEREUM FOUNDATION. Light Ethereum subprotocol (LES). https: //github.com/ethereum/devp2p/blob/master/caps/les.md, 2022.

[24] ETHEREUM FOUNDATION. Light node. https://ethereum.org/en/develo pers/docs/nodes-and-clients/#light-node, 2022.

[25] ETHEREUM FOUNDATION. Node as a service. https://ethereum.org/en/ developers/docs/nodes-and-clients/nodes-as-a-service/, 2022.

[26] ETHEREUM FOUNDATION. Requirements. https://ethereum.org/en/deve lopers/docs/nodes-and-clients/run-a-node/#requirements, 2022.

[27] ETHEREUM FOUNDATION. Who should run a node? https://ethereum .org/en/run-a-node/, 2022.

[28] FANTI, G., KOGAN, L., AND VISWANATH, P. Economics of proof-ofstake payment systems, 2019.

[29] GETBLOCK. GetBlock. https://getblock.io/, 2022.

[30] GOES, C. The interblockchain communication protocol: An overview. arXiv preprint arXiv:2006.15918 (2020).

[31] GRIFFITH, E. Why the crypto collapse matters. The New York Times (Nov 2022).

[32] INFSTONES. InfStones. https://infstones.com/, 2022.

[33] INFURA. Infura. https://infura.io/, 2022.

[34] KALEIDO. Kaleido. https://kaleido.io/, 2022.

[35] LI, K., CHEN, J., LIU, X., TANG, Y. R., WANG, X., AND LUO, X. As strong as its weakest link: How to break blockchain dapps at rpc service. In NDSS (2021).

[36] MALWA, S. Two Polygon, Fantom front ends hit by DNS attack. https: //www.coindesk.com/tech/2022/07/01/two-polygon-fantom-front-end s-hit-by-dns-attack/, 2022.

[37] MEE, D. Bitcoin full node on RBP3 (revised). https://medium.com/@ meeDamian/bitcoin-full-node-on-rbp3-revised-88bb7c8ef1d1, 2017.

[38] MEE, D. Litecoin full node on RBP3. https://medium.com/@meeDam ian/litecoin-full-node-on-rbp3-69f851f74f1b, 2017.

[39] METAMASK SUPPORT. Why Infura cannot serve certain areas. https: //metamask.zendesk.com/hc/en-us/articles/360059386712-Why-MetaM ask-and-Infura-cannot-serve-certain-areas, 2022.

[40] MORALIS. Moralis. https://moralis.io/, 2022.

[41] NAKAMOTO, S. Bitcoin: A peer-to-peer electronic cash system. Decentralized Business Review (2008), 21260.

[42] NELSON, B. J. Remote procedure call. PhD thesis, Carnegie Mellon University, 1981.

[43] NOWNODES. NOWNodes. https://nownodes.io/, 2022.

[44] PAAVOLAINEN, S., AND CARR, C. Security properties of light clients on the ethereum blockchain. IEEE Access 8 (2020), 124339–124358.

[45] POCKET NETWORK. Pocket Network. https://www.pokt.network/, 2022.

[46] QUICKNODE. QuickNode. https://www.quicknode.com/, 2022.

[47] RIVET. Rivet. https://rivet.cloud/, 2022.

[48] SENSEINODE. SenseiNode. https://senseinode.com/, 2022.

[49] SETTLEMINT. SettleMint. https://console.settlemint.com/, 2022.

[50] SOLANA FOUNDATION. Validator requirements. https://docs.solana.co m/running-validator/validator-reqs, 2022.

[51] SONG, Y.-D., AND ASTE, T. The cost of bitcoin mining has never really increased. Frontiers in Blockchain (2020), 44.

[52] WATCHDATA. WatchData. https://watchdata.io/, 2022. [53] XRP LEDGER. System requirements. https://xrpl.org/system-requireme nts.html, 2022.

[54] YAISH, A., AND ZOHAR, A. Correct cryptocurrency asic pricing: Are miners overpaying. arXiv preprint arXiv:2002.11064 (2020).

[55] ZMOK. ZMOK. https://zmok.io/, 2022.