Illustrate design goals of EVM & Ethereum Ecosystem.

 Ethereum is a programmable blockchain that allows users to create their own operations.
 EVM is the execution engine of Ethereum that serves as the runtime environment for smart contracts.
 The primary innovation of Ethereum that makes it unique compared with other blockchain systems.
 EVM also plays a critical role in transaction execution, changing the state of Ethereum and achieving consensus.

DESIGN GOALS OF EVM :

Simplicity :
 The idea was to make EVM as simple as possible with the low-level constructs.
 This is why the number of low-level opcodes is kept to a minimum and so are the data types to the extent that complex
logics could still be written conveniently using these constructs.
 Total 160 instructions, out of which 65 are logically distinct.
Absolute determinism :
 Ensuring that the execution of instructions with the same set of inputs should produce the same set of outputs
(deterministic!) helps maintain the integrity of the EVM without any ambiguity.
 Determinism along with the concept of computational step helps estimate gas expense with close approximation.
Space optimization :
 In decentralized systems, space saving is a biggest concern.
 This is why the EVM assembly is kept as compact as possible.
Tuned for native operations :
 EVM is tuned for some native operations such as the specific types of arithmetic operations used for cryptography
(modular arithmetic), reading blocks or transaction data, interacting with states, etc.
 Another such example is: 256-bit (32 bytes) word length to store cryptographic hashes where EVM operates on the
same 256-bits integer.
Easy security :
 In a way, gas Price helps ensure that the EVM is non-exploitable.
 If there was no cost, attackers could just keep attacking the system in every possible way.
 While almost every operation on EVM requires some gas cost, it should be easy to come up with good gas cost model
on EVM.

SMART CONTRACTS :
 In every participating node in the Ethereum network runs EVM locally, executes all transactions and smart contracts,
and saves the final state locally.
 It is the EVM that writes code (smart contracts) and data to blockchain and executes instructions (opcodes) of
transaction code and smart contract code written in a Turing-complete language.
 EVM serves as a runtime environment (RTE) for Ethereum smart contracts and ensures secured execution of the code.
 Obviously, when the code or transactions are validated through their respective digital signatures, they are executed on
EVM.
 So, only after successful execution of instructions through EVM, the Ethereum state can change.
 Unless one connects the EVM with the rest of the network to participate in the P2P network, it can be isolated from the
main network.
 In an isolated and sandboxed environment, EVM could be used to test smart contracts.
 It facilitates in building better, robust, and production ready-smart contracts.

1
MEMORY MANAGEMENT :
1.Storage (persistent) :
 Key-value storage mapping (i.e., 256- bit to 256-bit word mapping). This means both keys and values are 256 bits (i.e.,
32 bytes).
 From within a contract, it is not possible to enumerate storage.
 At any given point in time, the state of the contract can be determined by the contract level variables called state
variables that are always in storage and it cannot be updated at runtime. This means that the structure of the storage is
set only once during the contract creation and cannot be altered. However, their content can be changed with send
Transaction calls.
 Read/update of storage is an expensive affair.
 Contracts cannot read, write, or update to any other storage that is not owned by them.
 SSTORE/SLOAD are the frequently used instructions. Example: SSTORE instruction pops the top two items off the
stack, considers the first item as the index, and inserts the second item into the contract‘s storage at that index location.
2.Memory (volatile) :
 It is similar to RAM requirement in a general computer system for any code or application execution and used to store
temporary values.
 A contract can use any amount of memory during execution by paying for it, and that memory space is cleaned up after
execution completes. The outputs during execution could be pushed to the persistent storage that can be reused in future
executions.
 Memory is actually a byte-array that is contiguous, unlike storage. It is allocated in 256-bit (32 bytes) chunks.
 Starts with no space and takes on space in the units of 32-byte chunks.
 Without the ―memory‖ keyword, smart contract languages such as Solidity are expected to declare variables in storage
for persistence.
 Memory cannot be used at the smart contract level; it can only be used in methods.
 Function arguments are almost always in memory.
 MSTORE/MLOAD are the frequently used instructions.
3.Stack :
 EVM is stack based, hence follows LIFO (Last-in, First-Out), where stack is used to perform computations.
 Stack entries are also 256-bit words used to mimic 256-bit pseudo registers. They are used to hold local variables of
value type and to pass parameters to instructions or functions, memory operations, and other algorithmic operations.
 Allows a maximum of 1024 element and is almost free to use.
2
  Most of the stack operations are limited to top of the stacks. The execution is pretty similar to the way Bitcoin script
was executed.

ETHEREUM ECOSYSTEM :
 Above are the core components of how Ethereum really works.
 There are some limitations to Ethereum such as the following :
 The EVM is slow ; it is not advisible to be used for large computations.
 Computation and storage on the blockchain is expensive ; it is advisible to use offchain computations and use
IPFS/Swarm for storage.
 Scalability is an issue ; there are different techniques to address it, but they are subjective to the business case you
are dealing with.
 Private blockchains are more likely to flourish.
Swarm :
 It is not only a distributed storage platform of static files in a P2P fashion, but also a distribution service.
 Swarm ensures adequate decentralization and redundant storage of Ethereum‘s blockchain data, DApp code, etc. Unlike
WWW, the uploads to Swarm are not centralized to one web server.
 It is designed to have zero downtime and is DDOS resistant and fault tolerant.
Whisper :
 It is a communications protocol that allows DApps to communicate with each other.
 It provides a distributed yet private messaging functionality.
 It supports singlecast, multicast, and broadcast of messages.
DApp :
 A DApp usually has two components, a front-end and a back-end component.
 The back-end code runs on the actual blockchain coded up in smart contracts.
 The front-end code and user interfaces could be written in any language such as HTML, CSS, and JavaScript, as long
as it can make calls to its back end.
 Also, the front end can be hosted in a decentralized storage like SWARM or IPFS instead of a centralized web server.
 User interface components will be cached on some kind of decentralized BitTorrent-like cloud and pulled in by the
DApp Browser as needed.
 Like any App store, it is possible to browse the distributed DApps catalog in the browser.
 The end user can install any DApp of interest in their browser.
Development Components :
 There are so many development components used to develop decentralized applications on Ethereum and interact with
them. Some of them are below :
1. Web3.js :
This is a very important element in developing DApps.
2. Truffle :
Truffle provides the building blocks to create, compile, deploy, and test blockchain applications.
3. Mist Wallet :
To store, accept and send Ether, the users need a wallet.
Mist Wallet is a UI-based solution that can be used to connect to the Ethereum blockchain.
Using Mist wallet, one can create accounts, design and deploy contracts, transfer Ether across accounts and view
transaction details.
Internally, Mist is dependent on client to perform all the operations seamlessly.
3