POSTED 2 months ago

Ethereum 101 - Part III - Dapps & Libraries

Part III - Dapps and Libraries

How an End-User Would Interact with Your Decentralized App

Using ethereumjs to execute a raw transaction is quite an arduous code-heavy process for such a simple task. MetaMask is one such decentralized application that serves to improve the user experience of transacting on the Ethereum network while protecting the end-users private keys.

Let’s execute a simple transaction using MetaMask. First, if you haven’t added the app to your Chrome or Firefox browser, go ahead and do that now at the following link: https://metamask.io/ then move through the steps and setup a password.

The above is what the MetaMask end-user sees when sending a transaction. It’s both immensely more intuitive and easy. Using this decentralized application, most transactions can be broadcast out to the Ethereum mainnet and testnets within a minute.

In the top left corner you can see that this transaction was broadcast onto the the Rinkeby testnet. The 18.750 ETH is not real ether, as it was obtained using Rinkeby’s faucet @ https://faucet.rinkeby.io/.

Web3 Libraries

Interacting with the Ethereum network occurs through use of various Web3 libraries, each of which represent or are built for a specific language or programming protocol.

There are various libraries that allow developers and end-users to interact with the Ethereum blockchain, among these are the ethereumjs modules (which we used “ethereumjs-tx” earlier to sign and execute a raw transaction), web3.js, and pyEVM.

Web3.js is the Ethereum compatible JavaScript API which implements the Generic JSON RPC spec. The Web3.js library is available on npm as a node module, for browsers and components it is available as an embeddable js, and is further available as a meteor.js package. Web3js communicates via RPC with the local node or test node.

Although Web3.js is the de facto JavaScript Ethereum API, developers have access to a plethora of other libraries and tools. Among these are web3j (a more lightweight, reactive type safe Java and Android API), ethereum-js (the simple library we used above to execute a raw transaction), pyEVM (python library seen as the incoming replacement of pyethereum), Web3.py (another Python library), eth.js (maintained by Nick Dodson), and a long rendition of other libraries.

Development environments such as Truffle, which we will describe in greater detail later, utilize consoles that can access Web3 libraries.

Ethereum can be accessed by a browser, a server, and in general anything that can correctly interpret the protocol. An example of a client-side browser interface is ConsenSys’ MetaMask browser extension, which uses the Web3.js API. An example of a server-side service is etherscan.io, a service that many in the ethereum community see as a generally reliable source for information on ethereum addresses, address balances, and smart contracts.

Web3 library Quick overview
Web3.js The sort of ‘flagship’ Ethereum library, it is the Javascript API implementing the Generic JSON-RPC spec.
py-evm New python implementation intended on replacing pyethereum.
Web3j Java library built to be lightweight and modular.
ethereumjs modules We used ethereumjs-tx to complete our raw transaction. Ethereumjs Github states that their library is outdated, but refers users to a set of modules you can find in the link to the right.
eth.js Lightweight and modular JavaScript library.

Ethereum Virtual Machine (EVM)

The EVM is a sandboxed runtime environment designed for smart contract development. It is completely isolated from the internet and external file systems, and provides users deterministic algorithmic outcome for their smart contract development needs.

Now we have a basic understanding of Ethereum. We understand basic account structures, how to execute a transaction, how to execute a transaction with a contract, and so forth. Let’s now delve into the more complex nuances of Ethereum that make it so special.

We’ve seen the EVM mentioned throughout this article, but haven’t gone into significant detail about its capabilities. The EVM is the Ethereum Virtual Machine, it is the Turing complete virtual machine that handles all of the transaction processing on the Ethereum network. It is a complete 256 bit virtual machine that serves to execute arbitrary EVM bytecode.

EVM Byte Code

On the current Ethereum blockchain, the EVM generally executes received byte code slower than one would expect of other virtual machines. The salient reason for this is that each operation must be executed simultaneously by every full node in the network in order to achieve a trust-less environment. This is by design. The EVM was designed to achieve decentralized consensus across the whole network, and as a result, computation speeds and costs tend to be greater than one would find on a centralized network. The upside is that Ethereum network experiences immutability, significantly improved fault tolerance, and zero downtime.

Additionally, while not contributing to slower byte code execution, the gas mechanism ensures that miners receive an upfront payment to complete the transaction. This prevents programs from looping eternally, eventually the program will exhaust its gas limit and the transaction will throw. The gas costs are split into two variables, gas price and gas limit, which we will review next.

Explanation of Gas Costs

Each transaction received by the EVM contains a gasLimit and a gasPrice set by the transaction sender. The gasLimit is the maximum gas allotted to the transaction, and it is paid to the EVM upfront. The gasPrice is the pre-allocated value of gas that the sender is willing to pay for each computational step. The EVM continues through its single run loop until the byte code is finished and terminated, or if an exception is thrown when all pre-allotted gas has been exhausted. Any remaining gas is refunded to the transaction sender.

Other exceptions that will force the EVM to terminate the transaction are invalid opcodes, invalid jump destinations (the EVM is able to jump to arbitrary positions only if lands on a jump-destination), and stack underflows.

Without going into greater details, it’s important to mention that the go-ethereum repository implements two EVM interpreters. The first being a simple byte code interpreter that performs simple loops over the byte code. The second being a ‘JIT-like’ interpreter, of which has received upgrades converting big integer arithmetic into 64 bit, that compiles the byte code into manageable data types and structures. More information on these interpreters and their performance variance can be found here: https://medium.com/@jeff.ethereum/optimising-the-ethereum-virtual-machine-58457e61ca15

While on the topic of gas costs, it is worthwhile to understand the various Ethereum units. Ether is naturally the most discussed, as it is the intrinsic currency of Ether. However, there are many sub-denominations of Ether. For example, one Ether is 1018 wei. Please reference the web3js unitMap variable below for the full breakdown of sub-denominations: https://github.com/ethereum/web3.js/blob/0.15.0/lib/utils/utils.js#L40

In our tutorial above, where we executed a raw transaction, the EVM is the processor that carries out that transaction.

Additional resources you may find helpful:

  • ETH Gas Station: To estimate the estimate the costs of particular transaction and contract execution, the ETH Gas Station can be used: https://ethgasstation.info/
  • Infura: Developers, in your search of scalable infrastructure for your dapps, will find solace in Infura. For several years, Infura has been providing the greater Ethereum community scalable access to the Web3 API through their infrastructure of geth, parity, and IPFS nodes.
  • Infura API: In addition to the Web3 API, the Infura team provides their own API, which contains within it a RESTful APIs, Market Data APIs, and Security APIs. For more information: https://blog.infura.io/

Additional resources that may be of interest to you in your development pursuits:

  • Balanc3 - blockchain based accounting platform
  • Etherscan - ethereum blockchain explorer

Introduction to Smart Contracts

Smart contracts are typically written first in a high level language before being compiled into EVM byte code. Solidity is currently the de facto primary language used to write smart contracts. It is a high level language that draws influences from Python, JavaScript, and C++. Viper and Serpent are two additional smart contract languages, though they are not used to the extent that Solidity is.

As discussed in the preceding section, EVM byte code can be both time intensive and expensive to execute, since it must be simultaneously accepted and executed by every full node in the network. Smart contracts perform best when they’re written to handle straightforward logic. As smart contracts grow more complex, they tend to cost the transaction sender more gas. Additionally, unnecessarily robust smart contracts introduce more potential attack vectors for malicious actors to exploit. It is best to keep smart contracts as simple as possible.

Below is a sample escrow smart contract that you could drop into a Remix virtual machine instance and interact with and manipulate to your liking: `pragma solidity ^0.4.11;

contract Escrow { address owner = msg.sender; // sets owner to whoever created this contract address receiver; // Specifies who can withdraw money from this contract address approver; // Specifies who has authority to release the value bool approved = false; // Specifies whether the 'approved' has released the value

// Should be called by the 'approver' authority so that 'receiver'
// can withdraw current stored value

function Escrow(address _receiver, address _approver) {
    receiver = _receiver;
    approver = _approver;
}

modifier onlyReceiver() {
    require(msg.sender == receiver);
    _;
}

modifier onlyApprover() {
    require(msg.sender == approver);
    _;
}

function approve() onlyApprover {
    approved = true;
}

// Called by 'receiver' to withdraw funds
function withdraw() onlyReceiver payable {
    require(approved);
    assert(receiver.send(this.balance));
    approved = false;
}

// This function is called by customers to make payments
function() payable {}

} `

Remaining Cognizant of Smart Contract Security

If you simply want to try your hand at coding Solidity smart contracts in a virtual environment, then access Remix via your browser @ https://remix.ethereum.org/ then navigate to the ‘Run’ tab and set the environment field to ‘JavaScript VM.’ Using this method, all transactions will be executed in a sandbox virtual environment within your browser.

Now that you’re moving along and building and deploying smart contracts, you’ll want to ensure that you’re writing secure code. After all, smart contracts are immutable once written to the blockchain. Learning to write secure smart contracts is a difficult endeavor. Tools such as Mythril help devs identify vulnerabilities in their smart contracts. Further, it is suggested that users who have a desire to improve their knowledge in this area reference the documents available @ https://github.com/ConsenSys/smart-contract-best-practices

Secondly, developers within the Ethereum community saw the inherent need for improved smart contract frameworks, and as a result, various tools and libraries such as Zeppelin Open source have emerged that offer developers secure, community reviewed smart contracts that can be inherited.

Additionally, as Ethereum grows and scales, so will the demand for smart contract security auditing professionals. To date, there have been several high profile smart contract attacks (e.g. the DAO, Parity wallet hacks) that have both shaped and influenced ethereum’s development and resulted in the loss of large sums of money. The DAO attack significantly shaped and divided the Ethereum community, resulting in the forking of Ethereum Classic.

The environments we will discuss throughout the next section are both a good springboard to more advanced smart contract development, testing, and auditing tools and offer developers the ability to tailor their development environment to their needs and abilities.

Outline
  • Part III - Dapps and Libraries

OWNER
wil