Blockchain Note – DApp Basics

DApp Basics
Before step into the world of DApp, feel free to read the white paper of

1. What is DApp?

DApp is like a blockchain compared to Android and iOS. DApp has the following five features:1). DApp decentralizes operations through network nodes. It can run on the user’s personal device, such as a mobile phone or a personal computer. It belongs to the user forever, and can be freely transferred to anyone.

2). The DApp runs on a peer-to-peer network. It does not rely on a central server, does not require a dedicated communication server to deliver messages, and does not require a central database to record data. The data is stored in the user’s personal space, either a mobile phone or a personal cloud disk.

3). The DApp data is encrypted and stored on the blockchain. It can rely on the blockchain to conduct property transactions and sales, and to carry transactions without intermediary.

4). DApp participant information is stored securely. It can protect digital assets and ensure that property rights will not be leaked or destroyed.

5). DApp must be open source and autonomous. Can be freely packaged by the user to generate, the signature mark belongs to. Its release is not subject to any institutional restrictions. Various ideas and innovations can be freely expressed and realized. Only one DApp that meets the above four conditions is considered to be an application that can run.

2. What is the difference between DAPP and APP ?

From the perspective of customer experience, APP has four major problems with DAPP. One is to intercept user data, the other is to monopolize the ecological platform, the third is to retain user rights, and the fourth is to limit product standards to stifle innovation.
From a technical point of view, there are two main differences between DAPP and APP. One is that APP is installed and running on Android or Apple system; DAPP is developed on the blockchain public chain and combined with smart contract; Second, APP information is stored in data service platform. It can be directly modified by the operator; DAPP data is stored in the blockchain after being encrypted, which is difficult to tamper with.

At the same time, the following three conditions can be called a DApp.
First, running on a distributed network;
Second, the participant information is stored securely and privacy is well protected;
Third, decentralized operations through network nodes.

ETH is based on BTC and is a super single-threaded computer.

3. What is Solidity?

Solidity is a contract-oriented, high-level language for implementing smart contracts. It was influenced by C++, Python and JavaScript and is designed to target the Ethereum Virtual Machine (EVM).

Solidity is statically typed, supports inheritance, libraries and complex user-defined types among other features

4. What is gas and why need them?

1) Ethereum’s EVM function is very powerful, known as “Turing complete.” “Turing complete” virtual machine can implement looping statements. With the loop, there will be illegal molecules or unqualified programmers to make an infinite loop. The computer will die in a loop, and it will be a big crash. It is good to restart, but Ethereum is going to the center. If the EVM is in an infinite loop, it can’t be restarted.
For the “Turing shutdown problem”, many years ago, it has been proved that there is no way to detect whether the program will die. Is there any other way to stop the infinite loop?

So Ethereum introduced the gas mechanism. The name gas is very appropriate, and the translation is the meaning of gasoline. If you compare Ethereum to a car, if the car is not oily, can you stop it? So in Ethereum, each operation needs to consume a certain amount of gas. If the gas is consumed, the program can stop. When Ethereum initiates each transaction, it will preset a certain amount of gas limit. If gas is consumed during execution, the operation will fail.
Gas The currency of the Ethereum Virtual Machine (EVM), the Ethereum virtual machine uses gas to charge for transaction packaging, smart contract execution and other operations.

2) Ethereum’s programmability makes it impossible to use Ethereum directly as a fee for Bitcoin. Since the standard for bitcoin handling fees is the size of each transaction byte, for a transaction, the bytes are computable and the resources they occupy are therefore also measurable. Ethereum is programmable. For a piece of code that can run, it is impossible to pre-calculate its resources.

For example, if you write a loop in a program, you don’t know how many times it loops. If you use ETH as a fee, the more cycles you consume, the more ETH you consume. For example, if you have a 100-cycle contract, the commission is 10 times that of 10 cycles, and no one is willing to write some logic. More intelligently speaking, gas is actually a workload unit, the gas limit represents how much work the contract does, and the gas price indicates the unit price of the workload, which is charged by ETH. Because the gas price can be adjusted, it avoids the excessive gap between the fees required for the same contract to be executed at different times due to the drastic changes in the ETH price.

When submitting a transaction to the Ethereum network, gas involves two parameters to be set (most of the time only need to set the gas limit):

Gas Price: Specify the highest price we are willing to pay for each unit of gas. The unit of gas price is the unit in Ethereum, such as Wei, GWei.

Gas Limit: Specify how many gas we are willing to pay for the execution of the transaction.

What is the meaning of gas price and gas limit? For example, the gas limit is equivalent to how much gasoline the car needs to add. The gas price is equivalent to the price per liter of gasoline. There is also a gas used by Txn, which means the actual amount of gasoline used after the end of the execution. If it is less than the gas limit, the remaining gas will be returned to the sender.

Gas cost = gas used (gas used) x gas price (gas price)

For smart contracts, different operations will correspond to different gas, such as:
Perform addition: 3 gas
Store the value of a variable: 100 gas
Call other smart contracts: 20 gas

4. What is remix?

Remix, previously known as Browser Solidity, is a web browser based IDE that allows you to write Soliditysmart contracts, then test, deploy and run the smart contract.
EB2F92AF-83DF-46E3-80FA-B881ED240772.png

Figure 1. Remix UI

5. How does contract work with Javascript?

      1. What is web3.js?
To talk to an ethereum node from inside a JavaScript application use the web3.js library, which gives a convenient interface for the RPC methods. See the JavaScript APIfor more.
  1. What is ABI?
ABI stands forapplication binary interface.
In general, an ABI is the interface between two program modules, one of which is often at the level of machine code. The interface is the de facto method for encoding/decoding data into/out of the machine code.
In Ethereum, it’s basically how you can encode Solidity contract calls for the EVM and, backwards, how to read the data out of transactions.
  1. What is Json-RPC?
JSONis a lightweight data-interchange format. It can represent numbers,
strings, ordered sequences of values, and collections of name/value pairs.
JSON-RPC is a stateless, lightweight remote procedure call (RPC) protocol. Primarily this specification defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message passing environments. It uses JSON (RFC 4627) as data format.
  1. ERC-20
The ERC20token standard describes the functions and events that an Ethereum token contract has to implement.
contract ERC20Interface {
    function totalSupply() public view returns (uint);
    function balanceOf(address tokenOwner) public view returns (uint balance);
    function allowance(address tokenOwner, address spender) public view returns (uint remaining);
    function transfer(address to, uint tokens) public returns (bool success);
    function approve(address spender, uint tokens) public returns (bool success);
    function transferFrom(address from, address to, uint tokens) public returns (bool success);
    event Transfer(address indexed from, address indexed to, uint tokens);
    event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
}
  1. ERC-721
ERC-721 is a more advanced token that is “non-fungible”. Think of ERC-20 as the token type for things that are money (any $5 bill is worth the same as any other $5 bill, usually) and ERC-721 as the token type for collectibles (it’s the Ethereum equivalent of baseball cards).
In ERC-721, each token is completely unique and non-interchangeable with other tokens. Another example: Pets. Many people have dogs, but THAT dog is theirs and they will not accept some other dog as a substitute. You can use ERC-721 tokens to represent those dogs and dog ownerships.
ERC-20: For money and money-like tokens.
ERC-721: For things and thing-like tokens.

6. Ethereum DApp Architecture

C64DE693-2B8E-45CF-8AB5-24D0FBB99923

Because of the special nature of DAPP, it is not possible to put everything on the ETH chain, and the efficiency overhead is not cost-effective, so it is necessary to consider this when planning. In addition to driving ETH through web3, the other is not much different from ordinary applications. It is better to have a cache of its own central database, and it is better to have high concurrent high availability.

The interface with ETH is web3, which is a set of RPC interfaces. There is nothing special about the interface and docking platforms.
Every write operation of ETH (consuming gas) is almost divided into two parts. The first step is to publish to the chain. At this time, an address will be obtained, and then the address status will be checked to determine whether the operation is completed. It may be a long time. You need to consider various exceptions, as well as server process restarts.
A765D54E-91CE-4FB6-9056-B907AF966862

7. EVM (EthereumVirtual Machine)

Smart contracts are just computer programs, and we can say that Ethereum contracts are smart contracts that run on the Ethereum Virtual Machine. The EVM is the sandboxed runtime and a completely isolated environment for smart contracts in Ethereum. This means that every smart contract running inside the EVM has no access to the network, file system, or other processes running on the computer hosting the VM

In order to reduce resource consumption and ensure system performance, the Ethereum virtual machine does not use a model that simulates a complete computer, but uses a more lightweight virtual framework.

Ethereum designed its own virtual machine (EVM) to execute transaction codes, which is the core difference between Ethereum and other systems. EVM is Turing-complete. Since the concept of gas is introduced in the Ethereum system, in principle, the total amount of calculations that can be performed in the EVM is limited by the total amount of gas. EVM uses a stack-based architecture, which is a last in, first out (LIFO) approach.

EVM has the following special design:
1) Distinguish between temporary storage (Memory, which exists in every instance of the VM and disappears after VM execution ends) and permanent storage (Storage, which exists in the blockchain state layer)
2) Using a stack-based architecture
3) Word size is 32 bytes
4) Variable, scalable memory size is used
5) Stack size is unlimited
6) 1024 call depth limit
7) No type

Highly recommend to read this two blogs:
9EEE52FE-6A1C-42B7-BCBF-874E8F73D29D
17B1C200-9DD3-4588-A59F-CCCEB340B687

8. Ethereum Storage

Let’s take a simple example of Alice giving Bob 10$.
As we can see here that we can change the state by executing a transaction on it.
Here we have to keep track of the balances and other details of different people(states) and the details of what happens between them on blockchain(transactions). Different platforms handle this differently.
Bitcoin
Bitcoin’s “state” is represented by its global collection of Unspent Transaction Outputs (UTXOs). The transfer of value in bitcoin is actioned through transactions. More specifically, a bitcoin user can spend one or more of their UTXOs by creating a transaction and adding one or more of their UTXOs as the transaction’s input.
This model of UTXO makes Bitcoin different from Ethereum. Let’s see some examples to understand the difference.
Firstly, bitcoin UTXOs can not be partially spent. If a bitcoin user spends 0.5 bitcoin (using their only UTXO which is worth 1 bitcoin) they have to deliberately self-address (send themselves) 0.5 bitcoin in return change. If they don’t send themselves change, they will loose the 0.5 bitcoin change to the bitcoin miner who mines their transaction.
UTXO transaction
Secondly, at the most fundamental level, bitcoin does not maintain user account balances. With bitcoin, a user simply holds the private keys to one or more UTXO at any given point in time.Digital wallets make it seem like the bitcoin blockchain automatically stores and organizes user account balances and so forth. This is not the case.
A visualization of how wallets work in bitcoin
The UTXO system in bitcoin works well, in part, due to the fact that digital wallets are able to facilitate most of the tasks associated with transactions. Including but not limited to:
a) handling UTXOs
b) storing keys
c) setting transaction fees
d) providing return change addresses
e) aggregating UTXOs (to show available, pending and total balances)
One analogy for the transactions in the UTXO model is paper bills (banknotes). Each account keeps track of how much money it has by adding up the amount of bills (UTXOs) in the purse (associated with this address/wallet). When we want to spend money, we use one or more bills (existing UTXOs), enough to cover the cost and maybe receive some change back (new UTXO). Each bill can only be spent once since, once spent, the UTXO is removed from the pool.
To summarize, we know that:
  • the bitcoin blockchain does not hold account balances
  • bitcoin wallets hold keys to UTXOs
  • if included in a transaction, an entire UTXO is spent (in some cases partially received back as “change” in the form of a brand new UTXO)
Ethereum
In contrast to the information above, the Ethereum world state is able to manage account balances, and more. The state of Ethereum is not an abstract concept. It is part of Ethereum’s base layer protocol. As the yellow paper mentions, Ethereum is a transaction-based “state” machine; a technology on which all transaction based state machine concepts may be built.
Let’s start at the beginning. As with all other blockchains, the Ethereum blockchain begins life at its own genesis block. From this point (genesis state at block 0) onward, activities such as transactions, contracts and mining will continually change the state of the Ethereum blockchain. In Ethereum, an example of this would be an account balance (stored in the state trie) which changes every time a transaction, in relation to that account, takes place.
Importantly, data such as account balances are not stored directly in the blocks of the Ethereum blockchain. Only the root node hashes of the transaction trie, state trie and receipts trie are stored directly in the blockchain. This is illustrated in the diagram below.
A533EFA7-EDB8-4805-A663-539E6B1EE2A5.png
There are two vastly different types of data in Ethereum; permanent data and ephemeral data. An example of permanent data would be a transaction. Once a transaction has been fully confirmed, it is recorded in the transaction trie; it is never altered. An example of ephemeral data would be the balance of a particular Ethereum account address. The balance of an account address is stored in the state trie and is altered whenever transactions against that particular account occur. It makes sense that permanent data, like mined transactions, and ephemeral data, like account balances, should be stored separately. Ethereum uses trie data structures to manage data.
A Comparison between UTXO and Account approach
The benefits of the UTXO Model:
  • Scalability — Since it is possible to process multiple UTXOs at the same time, it enables parallel transactions and encourages scalability innovation.
  • Privacy — Even Bitcoin is not a completely anonymous system, but UTXO provides a higher level of privacy, as long as the users use new addresses for each transaction. If there is a need for enhanced privacy, more complex schemes, such as ring signatures, can be considered.
The benefits of the Account/Balance Model:
  • Simplicity — Ethereum opted for a more intuitive model for the benefit of developers of complex smart contracts, especially those that require state information or involve multiple parties. An example is a smart contract that keeps track of states to perform different tasks based on them. UTXO’s stateless model would force transactions to include state information, and this unnecessarily complicates the design of the contracts.
  • Efficiency — In addition to simplicity, the Account/Balance Model is more efficient, as each transaction only needs to validate that the sending account has enough balance to pay for the transaction.
One drawback for the Account/Balance Model is the exposure to double spending attacks. An incrementing nonce can be implemented to counteract this type of attack. In Ethereum, every account has a public viewable nonce and every time a transaction is made, the nonce is increased by one. This can prevent the same transaction being submitted more than once. (Note, this nonce is different from the Ethereum proof of work nonce, which is a random value.)
A closer look at the trie structure in Ethereum
State trie — the one and only
There is one, and one only, global state trie in Ethereum.
This global state trie is constantly updated.
The state trie contains a key and value pair for every account which exists on the Ethereum network.
The “key” is a single 160 bit identifier (the address of an Ethereum account).
The “value” in the global state trie is created by encoding the following account details of an Ethereum account (using the Recursive-Length Prefix encoding (RLP) method):
– nonce
– balance
– storageRoot
– codeHash
The state trie’s root node ( a hash of the entire state trie at a given point in time) is used as a secure and unique identifier for the state trie; the state trie’s root node is cryptographically dependent on all internal state trie data.
4F4F1361-2CAD-4075-8680-711610113761
Relationship between the State Trie (leveldb implementation of a Merkle Patricia Trie) and an Ethereum block
Storage trie — where the contract data lives
A storage trie is where all of the contract data lives. Each Ethereum account has its own storage trie. A 256-bit hash of the storage trie’s root node is stored as the storageRoot value in the global state trie (which we just discussed).
896711C7-388A-48D7-B474-A20E3A289BFB
Transaction trie — one per block
Each Ethereum block has its own separate transaction trie. A block contains many transactions. The order of the transactions in a block are of course decided by the miner who assembles the block. The path to a specific transaction in the transaction trie, is via (the RLP encoding of) the index of where the transaction sits in the block. Mined blocks are never updated; the position of the transaction in a block is never changed. This means that once you locate a transaction in a block’s transaction trie, you can return to the same path over and over to retrieve the same result.
11F63715-4DE6-4D5E-BDF0-A9125B0DBBFB
Concrete examples of tries in Ethereum
The main Ethereum clients use two different database software solutions to store their tries. Ethereum’s Rust client Parity uses rocksdb. Whereas Ethereum’s Go, C++ and Python clients all use leveldb.
Ethereum and levelDB
LevelDB is an open source Google key-value storage library which provides, amongst other things, forward and backward iterations over data, ordered mapping from string keys to string values, custom comparison functions and automatic compression. The data is automatically compressed using “Snappy” an open source Google compression/decompression library. Whilst Snappy does not aim for maximum compression, it aims for very high speeds. Leveldb is an important storage and retrieval mechanism which manages the state of the Ethereum network. As such, leveldb is a dependency for the most popular Ethereum clients (nodes) such as go-ethereum, cpp-ethereum and pyethereum.
Whilst the implementation of the trie data structure can be done on disk (using database software such as leveldb) it is important to note that there is a difference between traversing a trie and simply looking at the flat key/value database.
Analysing the Ethereum database
As we mentioned previously there are many Merkle Patricia Tries (referenced ineachblock) within the Ethereum blockchain:
  • State Trie
  • Storage Trie
  • Transaction Trie
  • Receipts Trie
In Ethereum, a single Modified Merkle Patricia trie node is either:
  • an empty string (referred to as NULL)
  • an array which contains 17 items (referred to as a branch)
  • an array which contains 2 items (referred to as a leaf)
  • an array which contains 2 items (referred to as an extension)
The size complexity of a Merkle proof is logarithmic in the quantity of data stored. This means that, even if the entire state tree is a few gigabytes in size, if a node receives a state root from a trusted source that node has the ability to know with full certainty the validity of any information with the tree by only downloading a few kilobytes of data in a proof.

Reference

  1. https://theethereum.wiki/w/index.php/Remix
  2. https://ethereum.github.io/browser-solidity/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s