[ad_1]
In the computing world, a “client” refers to any type of software that is downloaded onto your computer and helps you interact with another type of software or service provided by a server. For example, Gmail is a software client that connects to an email server and allows users to send and receive emails.
An Ethereum client is the software needed to allow Ethereum nodes to read blocks on the Ethereum blockchain and Ethereum-based smart contracts. A “node” is the running piece of the client software. In order to run a node, you have to first download an Ethereum client application.
What are Ethereum nodes?
A “node” is a computer that performs a certain function on the Ethereum network and runs client software in order to do so. Depending on what your specific needs are, whether it be a decentralized application (dapp) or a wallet, there are three different types of nodes that can be run by any client: full nodes, light nodes and archive nodes. Each node will interpret data differently and offer different methods for synchronization – this refers to how quickly your node is able to retrieve updated information for your client to interpret.
- Full nodes are full of data; they store and can distribute all of the blockchain data from the Ethereum network. A full node will additionally participate in block validation (i.e. verify all blocks and states on the network).
An advantage of implementing a full node is that it can directly interact with any smart contract on the public blockchain. Full nodes can also directly deploy smart contracts into the public blockchain.
However, the full use and storage of data, as well as direct smart contract functionality, comes at a cost. Full nodes can be taxing on your computer’s hardware and bandwidth resources. Retrieving full data can also be very time consuming, sometimes taking multiple days to sync your data when the node is first deployed. Then, the node must be maintained, upgraded and kept online in order to not have to repeat the full synchronization process.
- Light nodes are similar to the full node but handle less information. The light node stores header chain information (basic information stored in a block such as a timestamp and the hash of the previous block,) but will only receive additional information upon request. They are able to verify the validity of data but do not fully participate in block validation. Light nodes are almost always implemented within remote clients. Because these nodes do not take on more intensive data storage and writing processes, they have proven to be useful for low-capacity devices like smartphones.
- Archive nodes are nodes that store all of the information that a full node does and builds an archive of historical blockchain states. Archive nodes will retain historical data even after a client has finished synchronization. Full and light nodes, on the other hand, will “prune” the historical blockchain data, meaning they can rebuild, but do not retain this information.
While archive nodes may not be useful for the average user, they have proven effective in the application of block explorers, wallet vendors and chain analytics.
What is an Ethereum client?
Clients can be useful for developers because they let them interact with the network and other network nodes using various programming languages. The Ethereum Foundation maintains several different clients for different programming languages, including Go, Rust, Java and C#. Various third-party developers have also created Ethereum clients for further language support.
The most common uses for Ethereum clients include transaction and mining interfaces, but its use cases can go far beyond basic blockchain interactions.
The Ethereum Foundation maintains the following clients:
These give developers options in implementing their Ethereum-based projects. If your preferred language isn’t officially supported by the Ethereum Foundation, numerous third-party Ethereum clients exist to provide additional language support.
The reason all of these different clients are possible is because Ethereum is defined by a formal specification (i.e. the “Yellow Paper”). The formal specifications that make up Ethereum sets the blockchain apart from Bitcoin. Where Ethereum defines standard behaviors for all Ethereum clients to follow, Bitcoin Core has no such definitions. By providing consistent documentation and clear language, Ethereum’s specifications enabled the blockchain to allow for independent, but interoperable, software implementations of an Ethereum client.
Types of ethereum client
Full client
Full clients store the entire Ethereum blockchain; a process that can take several days to synchronize and requires a huge amount of disk space – over 1 Terabyte to be exact, according to the latest figures. Full clients allow connected nodes to perform all tasks on the network, including mining, transaction and block-header validation and running smart contracts.
Light client
Ethereum clients may be implemented in full or in part. The above overview gives an explanation of how a “full” client works, however it is important to know that you don’t always need to run a full client. Typically when data storage and speed are at issue, developers will elect to use what are called “light clients.”
Light clients offer a subset of the functionality of a full client. Light clients can provide faster speeds and free up data storage availability because, unlike the full clients, they do not store the full Ethereum blockchain.
The scope of a light client’s functionality is tailored toward the goals of the Ethereum client. For example, light clients are frequently used for private keys and Ethereum address management within a wallet. Additionally, they tend to handle smart contract interactions and transaction broadcasts. Other uses for remote clients include web3 instances within JavaScript objects, dapp browsers and retrieving exchange rate data.
Remote client
There is a third type of client called a remote client which is similar to a light client. The main difference being, a remote client does not store its own copy of the blockchain, nor does it validate transactions or block headers. Instead, remote clients fully rely on a full or light client to provide them with access to the Ethereum blockchain network. These types of clients are predominantly used as a wallet for sending and receiving transactions.
The difference between nodes and clients
Nodes and clients work alongside one another and both terms are often used interchangeably. However, they both operate separately in order to access the Ethereum network.
Think of nodes and clients operating like a computer accessing the internet: the node is an operating system, like Windows or iOS, and the client is the computer itself. The client computer gives a user the ability to access the node operating system, which in turn, gives you the ability to access the internet. Different computers will be able to give you access to the same operating system and the different operating systems will give you access to the same internet.
MetaMask
To see how Ethereum clients work in the real world, we can look at MetaMask as an example. MetaMask is a browser-based wallet, Remote Procedure Call (RPC) client and basic contract explorer. Any computer with Chrome, Firefox, Opera or Brave Browser is able to run MetaMask.
MetaMask is an implementation of a remote client that interacts with the blockchain through a light client. In order to avoid any security issues, MetaMask operates its own light client to communicate with the remote client in order to ensure effective security and certainty of transactions.
MetaMask is unique from other browser-based wallets because it applies a web3 instance into a browser’s JavaScript reader, providing access to the Ethereum mainnet and other testnets as well, including Ropsten testnet, Kovan testnet and the local instance of an RPC node. Even with its unique functionality, MetaMask still runs a remote client just as most other browser wallets do. The remote client allows wallet storage functionality, transaction broadcasting and web3 JavaScript injections.
[ad_2]
