The client-server-peer-to-peer blockchain application
By: J. David Mitchell
Tags: Peer To Peer, P2p, Software Architecture, Blockchain, Ethereum

Even though peer-to-peer networks have been around for over 30 years, with the increasing popularity of blockchain, there has been a renewed sense of enthusiasm with respect to the world-wide embrace of peer-to-peer (P2P) architecture. P2P architecture is touted as part of the new “sharing economy,” which is characterized by decentralization, self-determination, inherent trust and profit sharing. While there are benefits, certainly, from self-determination, inherent trust and profit sharing, this article focuses on the role of P2P architecture in the technology stack of the future. Will client-server fade while P2P increases in popularity? What is the role of client-server in future blockchain tech stacks? Client-server architecture will have a significant role in future technology stacks because (1) in some ways, client-server is more efficient, (2) thin clients are desirable, (3) the blockchain public gateway will play a greater and greater role and (4) while Ethereum may be turing complete, it does not provide facilities for indexing, filtering and searching.

The History P2P architecture

In P2P architecture, each system acts as both a client (or node) and a server (information storage). IBM created one of the first P2P systems with the token-ring network. Each system was connected to every other system in the network via a ring typology. In this way, the systems could communicate with each other and share resources. Token ring technology was quickly enhanced by NetBIOS and server message blocks (SMB). SMB via Ethernet allowed direct connections of P2P systems rather than traversing a ring, and this enhancement was a step forward in moving toward a client-server architecture.

The client-server architecture in the form of a LAN manager was first introduced to so that disparate systems (e.g., OS2, Novell Netware and Microsoft Windows systems) could communicate with each other over SMB. SMB via IP (and SMB over TCP/IP) was a further enhancement, and the Common Internet File System (CIFS) with authentication over a LAN manager (or Directory Server) became a networking standard.

In the context of the LAN, client-server was an improvement over P2P in several ways. First, authentication and authorization could be centralized in a server (rather than using local system authentication and authorization). While LAN administrators were needed to manage the network, centralization of authentication and authorization was an improvement in efficiency. Second, file servers were created, backed by RAID controllers and fast networks, and these file servers were more robust and enabled vast numbers of clients. Third, by means of centralization, tracking and monitoring was greatly improved. Access audits could be performed with greater ease. Finally, client-server architecture enabled more complexity, supporting larger networks with thousands of clients, and enabled a greater number of simultaneous transactions. So, in these respects, client-server architecture was an improvement in the efficiency of local area networks.

In the blockchain ecosystem, the trend is toward thin clients.

Just as in the LAN, the trend in the blockchain ecosystem is toward thin clients. Rather than each system acting as both a client (or node) and a server (information storage), a “thin client” only contains enough information to do its job — not the full blockchain ledger. For example, the first Bitcoin wallet (viz., Bitcoin core) downloaded the complete Bitcoin ledger. Thin clients, which did not fully validate all transactions or all blocks, were quickly introduced. These thin clients connected to the Bitcoin P2P network, but they only sent information to the network to verify and to confirm the transactions that are affecting the client’s wallet. In the case of Bitcoin core, the client downloads over 200 GB of data, and the size of the data continues to grow. It is not surprising that the trend is for wallet owners to choose thin clients. Today, the vast majority of Bitcoin wallets are not full nodes; rather, they are thin clients or eWallets.

In the blockchain ecosystem, the trend is toward public gateways

Similar to thin clients, public gateways allow users to participate in blockchain networks without the cost of having to instantiate a full node (or a system acting as both client and server) on a P2P network. Public gateways are a return to the client-server architecture in the blockchain ecosystem. Public gateways provide the necessary tools for any application (or user) to start reading from and writing to a blockchain immediately, without the need to run the complicated infrastructure of a full node. These gateways expose a blockchain to “zero clients” (not merely thin clients). These zero clients are willing to trust the public gateway for the convenience of merely connecting to a JSON-RPC, REST or websocket endpoint.

Public gateways are typically backed by a server farm of full nodes. The server farm consists of load-balanced groups of full nodes, that can be scaled horizontally to meet demand of thousands of zero clients. The nodes are fully managed by the public gateway provider. In addition to providing the basic security of TLS enabled APIs, public gateways are typically enhanced with middleware to enable advanced routing, caching and tuning based on traffic patterns. Some public gateways are even providing indexing of blockchains in separate data stores so that many of the incoming read requests do not have to read from a full node at all; rather, the requests are served by reading from an index from a separate data store, which greatly improves response times. The client-server architecture of public gateways provides some increased efficiencies and greatly simplify the task of reading from and writing to blockchains.

Reduced complexity is one of the compelling reasons why users have been adopting public gateways, and the cost is trusting a remote public gateway. But, trust is the fabric upon which society is built. And, even when a user is installing a full node, there is still some trust involved. Is it open source software? Then, are you trusting the open source community to vet the code? Or are you auditing the code? Typically, a user will not even check that the downloaded software hashes match the published hashes, much less audit the code. So, even when one is using open-source software to install a full node, there is typically some level of trust involved. And, many users are extending their trust to public gateways in exchange for the reduced complexity of using a zero client.

The examples of public gateways are too numerous to list, but two of the most popular are ConsenSys Media’s Infura and Cloudflare. The popularity of these public gateways are difficult to measure, but MetaMask uses Infura with a zero-client approach, serving over one million installed users. Infura and Cloudflare both provide public gateways for the Ethereum blockchain and the InterPlanetary File system (IPFS). Both public gateways provide free TLS certificates for two-way, mutual TLS, ensuring that any client connected to the gateway is secure from snooping and manipulation. Both public gateways support caching to speed up reads. These public gateways view themselves as bringing client-server architecture to the P2P distributed world and bridging the gap between the traditional web and the new generation of P2P technologies.

While Ethereum may be turing complete, the JSON-RPC API does not provide facilities for indexing, filtering and searching

One potential of Ethereum is to build a complex application completely on the blockchain via smart contracts. While Ethereum may be turing complete, nevertheless, application developers have not had a lot of success in building complex applications using only smart contracts on the Ethereum blockchain. One of the reasons is that complex applications typically need the ability to do fast searches. Moreover, complex applications need to be able to filter data and return the results with pagination. But, indexing (or enabling fast lookups), filtering and pagination are facilities that are not provided by the Ethereum JSON-RPC API. As a result, application developers tend to provide a parallel storage system along side of the blockchain. The need for a parallel storage system so that data can be indexed, filtered and paginated increases the complexity of blockchain applications and reduces the ability for developers to provide unadulterated P2P systems.

There are many models for building blockchain applications using a parallel storage system. For some, the blockchain remains the single source of truth, and blockchain data is replicated into a parallel storage system, which can be indexed, filtered and paginated. For others, a blockchain is combined with IPFS, and the combination of the blockchain and IPFS form a single source of truth. And, data from both the blockchain and IPFS is replicated into a parallel storage system. For still others, the primary data is stored in a parallel storage system, and this data or metadata is synced with a blockchain. But, regardless of the model, parallel storage systems are used to enable developers to create complex applications, which are backed by a blockchain.

Rather than embracing client-server architecture, many application developers have created novel solutions in an effort to preserve P2P architecture. One such solution is to expose a custom web service on each full node, which is backed by a caching database. In this way, a developer could replicate data from a blockchain or IPFS for the data that is exposed by the custom web service into a caching database to enable fast access to data, filtering and pagination. And, the developer would call one or more custom web services to retrieve the data for an end-user application.

A further enhancement of the above web services architecture is to use a private gateway to federate diverse web services. Rather than calling individual web services that might be spread out over many nodes, the diverse web services can be federated into an API gateway. And, the application developer can call the API gateway (comprised of many web services) to retrieve the data for an end-user application.

Even though there is an effort to preserve the P2P architecture of blockchain-based APIs, the reliance upon an API gateway, in some respects, is a return to client-server architecture. It is interesting to note that public gateways have started to provide indexes to reduce the latency of reads for normal JSON-RPC calls, and some public gateways are providing custom REST and websocket APIs for filtering and pagination. But, whether one is using a private or a public API gateway, the use of a gateway is a return to client-server architecture.

Due to the limits of the Ethereum JSON-RPC API, the use of parallel storage systems and creating custom web services appears to be a necessary step in creating complex end-user applications. Moreover, even with the workarounds to preserve P2P architecture, there tends to be a reliance upon an API gateway to federate web services. So, it appears that client-server architecture will continue to have a significant role in current and possibly future blockchain technology stacks.

In review, in some respects, client-server architecture has offered some improvements and efficiencies to P2P networks. Moreover, there is a trend toward thin clients and zero clients in the blockchain ecosystem. Public gateways are also very popular, and many applications rely on them exclusively. Finally, without indexes, filtering and pagination, it is difficult to build complex applications on the Ethereum blockchain. There are workarounds that enable indexing and filtering, but even these workarounds tend to use the client-server architecture of an API gateway. So, rather than shun the use of client-server architecture, why not embrace it? We should not fear the client-server-P2P blockchain hybrid. Rather, we should embrace it. Will P2P architecture reign supreme over client-server architecture in the near future? Probably not. In the near future, client-server and P2P architectures will coexist in the same ecosystem.