1

Yellow Paper
Version 1.0
 2

ABSTRACT

Despite the undeniable growth of the Ethereum ecosystem and community of users and developers,
mass adoption still hasn’t happened. This is because there are various challenges to overcome affecting
the entire community specially the developers. This is, scalability or the lack of it which results in slow
and expensive transactions; usability limitations due to the low flexibility offered to developers, the
“one-size fits all” nature of the EVM as well as the lack of programming languages available which
greatly limit developers ability to customise the framework to the specific needs of their projects.
Moreover the lack of blockchain interoperability results in siloed blockchain ecosystems which cannot
communicate with each other.
Taking these factors into account we have built EtherLite to provide fast transaction finality and higher
throughput with lower gas fees and creating a developer friendly framework which is easily customis-
able to specific use cases. EtherLite aims to further enable mainstream adoption of the Blockchain
promoting decentralised community building.

1.0 INTRODUCTION
EtherLite is a community driven application-
specific blockchain that is customized for the
business logic defined by a stand-alone applica-
tion. EtherLite’s architecture leverages the
Proof-of-Stake functionality and EVM
compatibility.
EtherLite is fully compatible with Ethereum
meaning that any smart contract, DAO, and
decentralised applications will work on Ether-
Lite. Not only it is fully compatible with
Ethereum as well as it is faster, cheaper, and
more adaptable and it offers instant finality,
opening a new array of options for developers.
Features of EtherLite
• Web3 compatibility.
• High throughput.
• Fast transaction finality using a PoS
consensus engine.
• Ability to use existing smart contract and
tooling.
• Compatible with existing tools like Clients,
Metamask, Remix, and Truffle etc. which are
used in Ethereum Blockchain.
2.0 ARCHITECTURE
EtherLite uses a modular architecture which
gives developers an easier yet efficient system
to build various decentralized applications.
2.1 Blockchain Application
A Decentralized application (dApp) is an appli-
cation built on a decentralized network that
combines a smart contract and a frontend user
interface. In EtherLite smart-contracts are ac-
cessible and transparent – like open source
code – it is easy to customize them to any
application requirement, so any decentralized
application can even include a smart contract
that someone else has written.
3
2.2 Smart Contract
A smart contract is code that lives on the
EtherLite Virtual Machine and runs exactly as
programmed. Once a smart contract is de-
ployed on the network it can't be changed. It is
resistant to fraud, censorship and third party
interference. One of the characteristics of a de-
centralized application, as described above, is
that it is controlled by the logic code written
into the smart contract running behind that
dApp which is what makes it decentralized as it
is run by a contract, not an individual or a
company.
2.3 EtherLite Virtual Machine
EtherLite Virtual Machine works similarly to
Ethereum virtual machine however we are us-
ing an enhanced GETH library in it.
The EtherLite Virtual Machine has the ability
to deploy and execute smart contracts on to the
network. This is a program which is protected
and continuously running and it is not accessi-
ble from any outside network. Smart contracts
even have limited access to other smart con-
tracts. The EVM module packaged inside
EtherLite blockchain can be used separately. It
can be added as a dependency to any EtherLite
chain, which will allow for smart contract sup-
port.
Using a predefined validator set and the EVM
module as a dependency, provides projects with
scalability and interoperability as well as Proof-
of-Stake (PoS) consensus with fast finality.
The EVM works similar to a mathematical
function as once an input is given, it will pro-
duce a deterministic output. The transition
function describing Ethereum will also apply to
EtherLite:
Y(S, T)= S’
Given an old valid state (S) and a new set of
valid transactions (T), the Ethereum state tran-
sition function Y(S, T) produces a new valid
output state S’

2.4 Instruction Set
The instruction set of the EVM offer many op-
erations although these are kept minimal in or-
der to avoid incorrect implementations which
could impact the consensus algorithm. All
bytecode operations run on the basic data type,
256-bit words. The usual arithmetic, bit, logical
and comparison operations are present. Condi-
tional and unconditional jumps are possible. In
addition to this, the EVM can access relevant
block information such as block number and
timestamp or account information like address
and balance. Below are the operations the EVM
offers:
• Stack-manipulating opcodes (POP, PUSH,
DUP, SWAP)
• Arithmetic/comparison/bitwise opcodes
(ADD, SUB, GT, LT, AND, OR)
• Environmental opcodes (CALLER, CALL-
VALUE, NUMBER)
• Memory-manipulating opcodes (MLOAD,
MSTORE, MSTORE8, MSIZE)
• Storage-manipulating opcodes (SLOAD,
SSTORE)
• Program counter related opcodes (JUMP,
JUMPI, PC, JUMPDEST)
• Halting opcodes (STOP, RETURN, RE-
VERT, INVALID, SELFDESTRUCT)
2.5 Accounts
The EVM has two types of accounts sharing
the same address space which are treated
equally:
2.5.1 External Accounts
Controlled by public-private keys (i.e humans).
The public key determines the address.
2.5.2 Contract accounts
Controlled by the code kept within the account.
The creator’s address and amount of their
transactions
4
Every account has a persistent key-value store
mapping 256-bit words to 256-bit words called
storage.
Furthermore, every account has a balance in
aETL (1 ETL = 1 x 10^-18 aETL) which can be
modified by sending transactions that include
ETL.
2.6 Transactions
Transactions are cryptographically signed in-
structions from accounts. There are two types
of transactions: those which result in message
calls due to containing code and those where if
the target account is not set, the code sent is
executed and returns resulting in contract cre-
ation.
Contract creation results in the creation of a
new contract account containing compiled
smart contract bytecode. Whenever another ac-
count makes a message call to that contract, it
executes its bytecode.
2.7 Gas in EtherLite
In order to limit the amount of work a certain
operation requires, each transaction is charged
with a certain amount of fee to execute. While
the EtherLite Virtual Machine executes the
transaction, the gas is gradually used up ac-
cording to specific rules.
The creator of the transactions sets the value of
gas and has to pay it upfront gas_price*gas
from the sending account, in case any gas is not
used up, it will be refunded in the same
manner.
If the gas is used up at any point (i.e. it is nega-
tive), an out-of-gas exception is triggered,
which reverts all modifications made to the
state in the current call frame.
 5

Web3.js can be used to connect to the EtherLite

In essence, gas fees are paid in EtherLite's na-
tive currency, EtherLite (ETL). Gas prices are
denoted in aETL, which itself is a denomina-
tion of ETL - each attoETL is equal to
0.00000000000000001 ETL (10-18ETL). For
example, instead of saying that your gas costs
0.00000000000000001 ETL, you can say your
gas costs 1 attoETL.
network via any EtherLite node that allows ac-
cess via HTTP.
Web3JS Example:
// New RPC Provider
var web3 = new Web3("http://localhost:8545")
// or
var web3 = new Web3(new Web3.provider-
s.HttpProvider("http://localhost:8545"))

// change RPC provider

Unit Name Multiples Number of ETL web3.setProvider("ws://localhost:8546")
// or
1 DeciETL 1E-01 0.1 web3.setProvider(new Web3.providers.Web-
socketProvider("ws://localhost:8546"))
1 centiETL 1E-02 0.01
1 milliETL 1E-03 0.001 In order to use Web3.js to connect to EtherLite,
a programmer must specify a Web3 provider.
1 microETL 1E-06 0.000001 The code for this depends, of course, on the
1 nanoETL 1E-09 0.000000001 particular node to which the programmer wish-
es to connect.
1 picoETL 1E-12 0.00000000001
To interact with a deployed smart contract, the
1 femtoETL 1E-15 0.000000000001 contract’s address and the Application Binary
1 attoETL 1E-18 0.00000000000001 Interface (ABI) is required. The ABI is a de-
scription of the contracts public interface in the
1 zeptoETL 1E-21 0.0000000000000001 form of a JSON object.

4.0 WEB3 JSON-RPC LAYER 5.0 CONSENSUS MECHANISM

In order for a web app to interact with the
EtherLite blockchain (i.e. read blockchain data
and/or send transactions to the network), it
must connect to an EtherLite node.
Web3JS is a popular library that allows pro-
grammers to interact with the EtherLite
blockchain. It represents a JavaScript language
binding for EtherLite’s JSON RPC interface,
which makes it directly usable in web technol-
ogy, as JavaScript is natively supported in al-
most all web browsers.
The nature of the blockchain, a distributed
ledger that records transactions across the net-
work requires validators to store and update
this ledger. These validators have a major role
which is to determine which transactions have
settled, therefore there must be an agreement
across the validators, otherwise called, to solve
the Byzantine General’s Problem or otherwise
called consensus.
Satoshi (2008) solved the Byzantine General’s
Problem implementing Proof-of-Work (PoW)
with the release of Bitcoin and this is the most
widely used consensus mechanism. PoW
requires validators in this case miners, to solve
 6

a mathematical puzzle which is to find the If the network detects a fraudulent transaction,
nonce of the last recorded block and add that a penalty will be applied where a substantial
block to the blockchain. The miner who solves part of the forger’s stake, if not all, will be
the puzzle first is rewarded with a fraction of slashed and they will automatically lose their
the blockchain native coin turning PoW into a right to participate as a forger in the future.
competition to update the blockchain. This has
Proof-of-stake offers a solution to the above
proved to be an extremely secure and trustwor-
mentioned limitations of Proof-of-work. Firstly,
thy consensus mechanism. However PoW re-
it very much reduces the barriers to entry which
quires brute force only and no skill, hence it
were the huge initial hardware set up costs as
uses up immense computer power resulting in
well as the energy consumption. In terms of
high electricity consumption. On top of this,
decentralisation, there are less concerns about
miners incur huge set up costs and as more
energy consumption and it is relatively easy to
miners begin to run nodes on a blockchain, the
participate in PoS therefore a much larger
hash rate increases and so does the computation
group is able to participate and generate rev-
power required. Bitcoin alone uses more power
enue making this a far more decentralised
than an entire country such as Ireland (Vries
mechanism.
2018, p. 801) and on top of that as it gets more
difficult and expensive to mine, mining pools
are created to pool computational power to-
gether which in itself puts the entire decentrali- 6.0 Governance
sation concept at risk as there is a greater cen-
EtherLite is governed by its community of val-
tralisation of miners. Lastly PoW architecture
idators and delegators. Stakeholders can vote
limits scalability as each block can only contain
on proposals that change pre-set parameters of
a limited amount of data which in times of high
the system, organize upgrades or vote for
demand, can sometimes lead to long waiting
changes to the policies governing EtherLite.
for transactions which have to wait for the next
block to be processed.
In response to the issues with the PoW consen- 7.0 References:
sus mechanism, Proof-of-Stake (PoS) was cre-
ated. In a PoS system, the validators are also Ethereum:https://github.com/ethereum/wiki/
stakeholders as these people lock up a stake wiki/WhitePaper
inside the system. In contrast to PoW, PoS re- Ethereum Docs: https://ethereum.org/en/devel-
places competition (energy expend) by offering opers/docs/evm/
a randomly selected validator, who is also a
stakeholder, the authority to update the web3.js - Ethereum JavaScript API
blockchain. Once a node gets selected to forge https://web3js.readthedocs.io/en/v1.3.0/
the next block it will check if the transactions
in that block are valid, will sign and propose Blockchain Without Waste: Proof-of-Stake-
the block. Once enough nodes validate the https://papers.ssrn.com/sol3/Papers.cfm?ab-
block, it is added to the blockchain. Validators stract_id=3183935
receive a reward from the transaction fees for Saleh, F., 2018. Blockchain Without Waste:
both successfully proposing the block and for Proof-Of-Stake. [online] Available at: <https://
validating the blocks. The staking acts as an papers.ssrn.com/sol3/papers.cfm?
incentive to deter reward proper behaviour and abstract_id=3183935>
deter fraudulent validations or block creations.