As at the time of writing, Bitcoin, Ethereum and Bitcoin Cash network data combined, are approximately three-hundred thousand Megabyte in size.
Also, with the lingering argument on Bitcoin's block size increase, and the rise of new blockchain networks, the difficulty in hosting all of these networks on dedicated servers, whether on the cloud or inhouse, is growing exponentially.
As a blockchain service provider, or one in constant need of varying blockchain network information, API servers, which offer real-time access to a specific network data, and one that requires minimal commitments from you, may just be the right way to go in meeting your network needs. Interestingly, Getblock offers you the opportunity of a tailor-made API key for your network needs, at zero cost.
However, before we talk on why you may need an API server for your blockchain data needs, let's look at the various alternatives to your network exploration
How Full Node Servers Work
A full node server is the standard security best-practice for distributed blockchain network interactions, whether as a service provider, a user in need of up-to-date network ledger, or as an ordinary digital asset holder that desires absolute sovereignty over their funds while interacting frequently with the network.
With networks like Bitcoin, however, to get a wholesome copy of its blockchain will require you to install a wallet software, which supports full-node network backup (these are wallet clients like Bitcoin Core, Bitcoin Knots and so on.) After that, the current copy of the ledger is downloaded, backed remotely, and subsequently updated.
While this guarantees for private key security and sovereignty over their asset, it however comes with some responsibility and downside, some of which we would be looking at in subsequent paragraphs.
Full Server maintenance Responsibility: with a full node wallet, the end-user is fully responsible for their server's security and maintenance, this sometimes comes with an extra server support to keep it in sync with the network, especially when constant network interaction is necessary.
Bandwidth Inefficiency: since the bandwidth efficiency of any node’s server is constantly reducing if the data transfer is increasing, against a static network throughput and bandwidth capacity, the bandwidth efficiency of full-node servers will constantly be on the decrease if there is no provision for increasing a networks bandwidth capacity.
While this may not be that much of a deal for a blockchain service provider, with decent cash inflow; on the contrary, it is for users with limited bandwidth capacity, when compared with a constantly growing trail of related blocks.
Simplified Payment Verification (SPV) Queries on Full Node Servers
With networks like Bitcoin, there are, however, some exemptions with interacting with the network without running a full node server, or using an API key query; this is called Simplified Payment Verification (SPV). This was originally noted in section 8 of Satoshi’s original whitepaper.
With SPV nodes a fully updated copy of the network is not necessary, rather the supporting SPV wallet client queries any available full node(s) server on the network with, what is called, a Bloom filter query for a particular transaction verification associated with the said wallet’s private key. In other words, SPV queries are transaction verification related.
With SPV wallet queries, users enjoy bandwidth efficiency, without compromising their private key security. Also there is no need to keep a complete, up-to-date copy of the blockchain, as it is not required in SPV bloom filter queries. However, some of the down-side to this request is that:
The scope of the query is very limited: since SPV queries are targeted to specific transaction hash output or address activities, on the network. it is usually very efficient at minimal network throughput and bandwidth resources.
Unfortunately, verification queries that are not associated with the said user’s wallet can’t be made. By implication, this type of wallet clients are somewhat limited in their exploration of a network’s big data. So, for a blockchain network analyst looking to explore a wide array of network information, an SPV query may not be efficient, since it is only limited to the user’s wallets transaction history.
Risk of interacting with dishonest full node servers: like with almost every query on a decentralized network, query commands are sent at random to any available full node on the network. This is done on the assumption that these so-called full-nodes are honest, which may not always be true.
From his 2008 Bitcoin Whitepaper, Satoshi Nakamoto wrote of the possibility of an SPV client being fooled by a Sybil attack on the network. In his own words —
“As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.”
Risk of privacy compromise: Also, since SPV queries are always associated with all of a node's associated wallet addresses. It is then very easy for anyone running an active full-node server to get complete transaction information associated with a user’s wallet through the user's wallet address(es), just by one SPV query.
In other words, users of an SPV wallet user might as well publish their transaction history on Reddit or any public forum, since it is technically possible for anyone running a full node to have that information.
How API Servers Work On the Blockchain
API servers, in general, go a long way with HTTP, file transfer and request. This is either amongst peers in a centralized network or in a P2P network, like Bitcoin. The general rule of thumb with these server connections is that, any user with any of the API protocol’s designated query, can fetch a specific data from or update these servers, with the dedicated API Key for that query.
So rather than have an up-to-date blockchain ledger, a blockchain service provider or user can implement custom-made keys, required for their service or needs, from the specific blockchain.
This could be for a customized network explorer, an exchange, a wallet provider, a coin tumbler, or even a trader who is in need of bespoke network information. With the exponential rise in blockchain file sizes, it is now becoming necessary to interact with blockchain network ledgers, via API keys.
API server against full & SPV node limitations
Bandwidth Efficiency: like with SPV wallets queries, API Servers come with the privilege of optimum bandwidth efficiency, while having an almost unlimited access to the users desired range of network information.
Even more, unlike SPV wallet clients, which need to keep a record of the Merkel root of every block in a blockchain, API servers only keep the specific key for specific query commands.
Server Confidentiality: This may not be a problem for a wallet running a full node server. However, unlike with SPV wallets, that send queries at random into the network. With API queries, your API key interacts with specific and familiar servers. The only down-side to this is that the user must make sure to use keys from trusted API server providers, like the getblock.io free API access.
Multiple and unlimited network access: Also, with API servers, blockchain service providers or any user can have full access to multiple blockchain networks without needing to backup the complete ledger or needing an associated SPV client for these blockchains, which is why we provide free API access to over 20+ blockchain networks. With the right API key, the user can efficiently navigate all of these networks and get relevant, and specific, real-time, information.
Getting Started with your API Server key at Getblock
At getblock we offer unlimited API key access for over 20+ cryptocurrencies, all for free. This includes high market cap currencies like Bitcoin, Ethereum, Monero, Litecoin, and other nodes of very popular cryptocurrencies. Also, we support API protocols like JSON-RPC, REST, and WebSockets.
What is more, with our API protocols you still get full sovereignty of all your private keys, end-to-end encryption, 24/7 server uptime, and no limits to your API key customization all for free.