Ethereum part 3 – The dApp ecosystem
Ethereum has made running smart contracts on decentralized network a reality. This is resulting in proliferation of dApps (decentralized applications) over the Ethereum’s blockchain platform. In this article, we would have brief look at the dApp ecosystem and Ethereum stack for dApp development.
Nodes
Node in blockchain is referred to a computer running the underlying software (known as client) which can verify blocks and transactions and create new blocks following the set of rules defined by the network protocol. There are three types of nodes – full, light and archive.
Full Node
Full node stores the complete copy of the blockchain. Full node participates in mining, block validation, and verifying blocks, transactions and state. They serve the network and get rewarded with block rewards and transactions fees. Storing a complete copy of Ethereum requires significant disk space for a user computer. As of this writing the size of the Ethereum blockchain on GETH (default) client is about 1085 Gb and on the OpenEthereum client it is 539 Gb (source).
Light Node
They store only the headers of the chain and request any other data like balances from the full nodes. They can verify the validity of received data against the state roots in the block headers. Light nodes are useful for low-capacity devices such as mobile phones, embedded devices and even low-end user computers which can not afford to store gigabytes of blockchain data.
Archive Nodes
They store everything as a full node would and also build the archive of the historical states. This is useful when one needs to query the balance of an account in history. Having archive node is not attractive to average users but useful for the services like bock explorers, wallet vendors or chain analytics.
Networks
There are different networks for different environments for the purpose of development, testing or production. A single account can work across all the networks but the state and balances are not carried over, in fact an account would have its balances for each network.
Mainnet
This is the primary public Ethereum production network where the real/actual transactions take place.
Testnets
There are few public testnets which are production-like environments. These are used by protocol developers to test protocol upgrades (upgrade to Ethereum platform is protocol upgrades). The testnets are also used by smart contract developers for testing before deploying to the mainnet. For deploying and executing smart contracts in test environments, gas fees need to be paid. For this purpose, any developer can request free testnet Ethers over the testnet faucets. Test ETH has no market value and is freely given over testnet faucets. This helps in development of new dApps as developers do not have to pay real monies for testing smart contracts.
Development network
As testnets are test environments, development network is a development environment similar to a local server/development machine where developer writes and tests the code. Development networks are isolated private Ethereum networks (not connected to the public mainnet or testnet) and can be run on a single or multiple computers.
Consortium Network
A network of trusted nodes which control the consensus mechanism with predefined set of rules instead of Proof of work like algorithm. If public mainnet is like the public internet, the consortium network is akin to a private intranet. The consortium networks are common in academic institutions, universities, group of companies/banks/insurance providers. Many consortiums are formed to research, evaluate and implement the use cases of blockchain and dApps.
Ethereum Stack
Below diagram depicts typical layers and communication within the dApp ecosystem. Ethereum stack is a part of the bigger ecosystem that includes the external entities such as decentralized storage networks and decentralized Oracles. The main components of the Ethereum stack are user application, client API, node, smart contract and EVM.
领英推荐
Smart contract
Smart contract is a self-executing agreement between parties and written as lines of code. Smart contracts can be explained as a software program that enables developers to write business logic that can be run on any node in the network and the output state can be stored in a distributed ledger and shared across the network. A dApp can execute any smart contract deployed to the network by anyone without the risk of change as the contracts are immutable.
Solidity is the most popular and widely used language to write smart contracts on Ethereum, while other options are Vyper and Yul. The contract code written with any of those languages, compiles into EVM bytecode called opcodes. Smart contracts are open source, you can view any smart contract on public network and its opcodes. This (link) is a live smart contract code on etherscan.
Ethereum Virtual Machine (EVM)
EVM is the runtime environment for smart contracts in Ethereum. There are thousands of nodes running the Ethereum client software, an implementation of EVM. EVM uses a set of Opcode (140 unique) instructions to execute a transaction or smart contract in the form of several tasks. Like many virtual machines, EVM is also an abstraction layer between executing machine and executed code. A dApp /smart contract developer doesn’t need to know much about EVM except that it exists on each node in the network and executes the contract in exact same way resulting same output state.
Ethereum Node
To run the smart contract a user application needs to connect to the node which runs EVM. Applications can connect to these nodes using?JSON-RPC API. Hence, each Ethereum client implements the?JSON-RPC specification. JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol.
Client API
To help dApp development, there are many open-source freely available API libraries that developers can use to make RPC call in a single line of code. Client APIs can be used at the front-end which makes the system decentralized. While in some cases, the API is called by the server upon request from the applications. This brings some sort of centralization but use cases for such scenarios vary. The choice to implement API at front end or backend (server side) is with the developer. If the user application is web app then a front-end library JavaScript API can be used while?Python?or?Java can be implemented at server-side.
There are three possible ways to implement the client APIs.
End user application
User applications are at the top of the stack. They are primarily web/mobile applications that connect to the Ethereum node for running a dApp/smart contract.
Decentralized Storage
Ethereum is designed to store the state of the accounts and the contract code and data. With this, the size of the blockchain is already grown to 500 Gb – 1Tb (depending on client). The question arises, where the other large data to be stored? One of the simplest examples of the large data required to run the applications is the billions of images and documents on the web. Even if we try to store these files in Ethereum, huge gas fees would be a good deterrent, or even the network may come to a grinding halt as nodes would not be able to keep up with the humongous data to store and replicate. On the other hand, to make a dApp fully decentralized, this large amount of data needs to be stored in a decentralized storage that can be implemented with blockchain or a peer-to-peer based network. More details about the decentralized storage tools and systems (including IPFS) can be found at link.
Oracles
Data Source Problem
In a blockchain like Ethereum, all nodes need to arrive at a consensus and maintain the state of the system with the longest chain of blocks. Consensus is arrived by a process in which all the nodes replay each transaction included in a new block and verify the validity of transactions and block itself. For this purpose, all the nodes should execute the smart contracts with the same input data. When the input like stock/currency price or weather data is coming from external sources, different nodes may query this data from different sources and get different inputs. This results in a different transaction/contract execution output, breaking the consensus.
Solution
A single source of truth can address the above problem. What if this single source of truth is on the blockchain itself? Great, there come Oracles, which typically consist of a smart contract/s and some off-chain components that can query the external APIs. These oracle smart contracts are executed periodically and their data (in the world state – state of all accounts in Ethereum) is updated. This updated state/data is accessed by whichever smart contracts need the input data. This solves the problem of all nodes needing same input by using the data of Oracles.
Another problem arises out of the above solution. A single source of truth can not be relied upon in blockchain which is a trustless distributed network of numerous nodes. Relying on a single source of truth is insecure and also defies the idea of decentralization. This is called “Oracle Problem”. This problem can be avoided by using decentralized oracle that pulls the data from multiple sources. In that case, if one source is hacked or fails, the system would still function as expected.?