Originally published: https://medium.com/the-crypto-masters-guide-tcmg/how-client-architecture-applies-to-decentralization-security-in-crypto-231971519466
Whenever the topics of security & decentralization around blockchain come up, the discussion tends to fall into one of two camps, consensus mechanisms or hardware.
Certainly, these are both valid & important points to address, however, there is another vector that is hidden from plain sight.
That is the node client.
What is a Client
In the context of blockchain/DLTs, a client is a piece of software that connects a node to the network & allows its user to read/write information to/from the blockchain. So, a miner would need to install a software client on their hardware device in order to join & participate in the network.
Blockchain = Server
Node = hardware w/ client
Client = software
Clients provide key network operational functionality including: an execution environment for processing transactions, storage of transactional data, P2P networking tools, and APIs for interfacing with the network directly.
Every blockchain must have its own client software that complies with the protocol/consensus rules of that specific chain. Ethereum clients do not work in Bitcoin & a Bitcoin client does not work on Solana.
Each client will vary based on the language that it is written in & their own unique operational specifications (some might be focused on memory optimization while others focus on performance optimization through consensus modularity for launching side-chain).
Types of Clients
Generally speaking, clients are categorized by their node application type. Typically, there are four (3 + 1) types of node clients for a blockchain; full nodes, archival nodes, lite nodes & miner nodes.
Full Nodes/Clients:
The most common type of node on a network that contributes to network security/consensus & stores the most recent state of the chain. They act as the main carriers of information that validate blocks, verify transactions & serve data to other nodes. These node types do not provide any incentive for being operated but do act as a means of direct connection to a chain.
Archival Nodes/Clients:
The most demanding, in terms of memory, of all node types, archival nodes store the entire history of a blockchain. In order to run an archival node, an immense amount of storage space is required; therefore, these are rarely, if ever, run by individuals. Once a chain reaches a certain stage, server farms or enterprise-grade clusters of machines are required. These nodes are for providing strong network security & data-rich services such as explorers or on-chain data analytics.
Lite Nodes/Clients:
Sometimes also called SPV (simplified payment verification) node, this version of clients only contain a tiny sliver of the state & only store data relevant to a specific set of information. Lite nodes connect to a full node in order to get access to on-chain data. A good example of a lite node is a wallet. Wallets only require information that is related to a certain account & have no desire/need to participate in network operations. These are clients for most of the basic user applications.
Miner Nodes/Clients (+1):
The reason this is a +1 is because this variation of a node client does not apply to all blockchains; it does not exist in staking networks & is only applicable to POW chains. As the name might suggest, miner nodes have a single function, to mine. These client types have evolved to become suited for single-purpose equipment such as ASICs in Bitcoin. Sometimes, this function meshes with full node operations, but the vast majority of the time it will be a separate function.
The Single Client Dilemma & Common Concerns
Whenever a blockchain network has only one client, it is a double-edged sword that can serve as a security issue. If there is only one implementation of the protocol, any bug or vulnerability in that implementation can potentially compromise the entire network.
Question: What happens whenever/if ever there is a bug found in the client?
side 1: Then the whole network is at risk.
side 2: if all developer efforts are allocated to a single purpose, then the bug risk is lower to begin with.
Question: What happens if/whenever a hacker finds a vulnerability in a client?
side 1: Then the whole network & its participants are at risk.
side 2: no comment…
Question: What if the client was designed in such a way that it keeps new developers out from joining & requires a strict set of specially trained developers?
side 1: This then creates a bottleneck that stifles innovation.
side 2: This then creates higher quality special purpose developers.
MCA — Multi-Client Architecture
Multi-Client Architecture refers to a software design principle where there are multiple independent implementations of a client for a given blockchain protocol.
There are four prominent reasons that MCA improves the overall health & well-being of a blockchain network:
-
Fault tolerance:
The risk of a single bug or vulnerability affecting the entire network is reduced. As an example, let’s take a network with 1,000 nodes and 4 clients. In the event that a single client malfunctions & takes down 25% of all the network nodes, the network will be able to operate uninterrupted. If there had only been that one corrupt client then the whole network would have halted. -
Resilience against attacks:
With multiple independent implementations, an attacker would need to discover and exploit vulnerabilities in multiple implementations to have a significant impact on the network. The increased surface area of raw code & individual complexity that a hacker/bad actor would need to go through in order to break a network increases dramatically with each new client. -
Decentralization:
MCA reduces the overcast of any single client dominating the network because multiple clients have to abide by protocol consensus to agree on the state of the blockchain before any new transactions can be added. -
Openness and transparency:
Multi-Client Architecture promotes openness and transparency by allowing anyone to contribute to the development of a client implementation. It minimizes the reliance & need to trust a single team to produce honest products. Instead, it increased competition between developer teams to drive adoption. Additionally, multiple parties working on the development of a blockchain protocol can in turn help prevent the development of hidden vulnerabilities or backdoors. (unless they are all corrupt & colluding against the public)
#The current state of MCA in Crypto
The vast majority of projects only have one client version & rarely mention the introduction of any new ones (after all developing clients requires funding).
However, a few technology-focused OG projects such as Ethereum, Polkadot & (recently in development) Solana, have taken this subject matter seriously & are leading the implementation of MCA.
Massive credit must be given to Ethereum for always having the most diverse set of client software. As of this writing, there are 4 major active implementations:
— Geth ***(~70.1% of all clients)***The most robust protocol client that allows users the flexibility to run any version of a node. Implementation of Ethereum in the GO programming language.
— Nethermind ***(~13.6% of all clients)***Implemented in the .NET programming language, Nethermind is a protocol execution client that optimizes operations for Full nodes.
— Erigon ***(~10.8% of all clients)***A fork of Geth client (also in the GO programming language) that is focused on maximizing the efficiency of storage for archive nodes.
— Besu ***(~5.5% of all clients)***Enterprise-focused client in the JAVA language. Created & open-sourced by the hyperledger foundation, Besu provides the extended modularity to swap out the consensus mechanisms for private implementations.
Ultimately there is no perfect solution.
I am personally very supportive of having a diverse set of clients but am very aware of the possibility that even with more clients available it is not guaranteed that they will attract enough attention to displace older, original clients that are already battle tested.
Thank you for reading;
I hope this serves you well on your journey through the blockchain
See you all on the other side 🥂
Originally published: https://medium.com/the-crypto-masters-guide-tcmg/how-client-architecture-applies-to-decentralization-security-in-crypto-231971519466
No comments:
Post a Comment