Understanding Ethereum
Ethereum
Ethereum
is a distributed computer; each node in the network executes some
bytecode (hint: Smart Contracts), and then stores the resulting state in
a blockchain. Due to the properties of the blockchain representing
application state, this results in “applications that run exactly as
programmed without any possibility of downtime, censorship, fraud or
third party interference”.
Obviously an acceptable explanation won’t fit into a paragraph. Go ahead and read the Ethereum whitepaper. Or one of the other trillion “how do I Ethereum/Blockchain/Smart Contract” posts on the internet. Or watch this video titled “Ethereum in 25 Minutes”.
Smart Contract
A
“Smart Contract” is literally just some code (seriously, that’s it)
that’s executed in a distributed environment like the Ethereum platform.
The platform on which it’s executed gives this piece of code some
properties such as: immutability, deterministic operation, distributed
& verifiable state, etc. The state managed by this code is stored,
immutably, on a blockchain and anyone can double check that the current
state is correct by replaying all of the transactions from the beginning
of the chain.
In
Ethereum, contracts are given an address to uniquely identify them
(it’s a hash of the creator’s address and how many transactions they’ve
sent before). Clients can then interface with this address by sending it
ether, calling functions, querying the distributed state that it
manages, etc.
Smart
Contracts, again, are just some code with some distributed state
managed by a blockchain. For example, your wallet that you’re using to
receive/send ETH is just a smart contract with a fancy UI on it.
This
concept is pretty powerful, and I’m sure you’ve already read all about
it. If you haven’t, browse your favorite mildly-technical new source
(hey Medium!) and you’ll be inundated with people telling you how much
potential there is. Some buzzwords: asset/rights management,
decentralized autonomous organizations (DAOs), identity, social
networking, etc.
Gas
Smart Contracts (again, just blobs of code) are executed by every single full node in the network,
which is a lot of redundancy (good) but this costs a lot of energy and
time (bad). Because it costs money to perform computations, the cost of
performing computations is directly tied to which computations your code
performs. To say that another way, each low level opcode in the EVM
costs a certain amount of “gas” to perform. The word “gas” is totally
arbitrary; it’s just an abstract label given to the cost of performing
computation. There’s also a network-enforced gas limit, to solve the halting problem;
i.e., you can’t write a program that never ends, because you’d run out
of gas and the computation would be rejected by the network.
The
“price” of gas (i.e. “how much $$$ does adding two numbers together on
this distributed computer cost me”) is determined by the market, similar
to Bitcoin’s transaction fees. If you pay a higher gas price, nodes
will prioritize your transactions for that sweet sweet profit.
In
general, it’s way more expensive to compute and store things on
Ethereum than it would be to do it in a traditional environment, but
Ethereum gives your code all those nice properties we discussed above,
which can be just as valuable.
In general, reading state is free and writing state costs gas. Here’s a more in-depth overview of the concept of gas:
Distributed App (dApp)
A
Distributed App is an app where the “server side” is just one or more
well-known Smart Contracts that exist on the Ethereum network.
A
Distributed App doesn’t need to store all of its state and perform all
of its computation on the blockchain, which would be pretty expensive
for end-users, but a distributed app does eventually store trusted state
on the Ethereum blockchain, which anyone can then read. Many
distributed apps also use technologies like IPFS and Golem (discussed
later) to handle computation and storage off of the Ethereum blockchain,
but in an equally decentralized manner.
The ethereum organization on github has a dapp-bin repository
that has some references and examples. Make sure you check the activity
on the file you’re looking at, though, cause this kind of information
gets stale very quickly.
Also,
we’ve finally agreed on the proper capitalization of “dApp” via twitter
poll (so you know it’s statistically significant), so let’s all just
write it as “dApp” then, yeah?
dApp Client
These
distributed applications are usually accompanied by some sort of
user-friendly frontend because nobody wants to manually send
transactions to/from contracts using a cli or manually craft requests
with hashes and opcodes oh my.
A
dApp Client is literally just any “client” or “frontend” as you’d
normally use the term in programming, except this client interfaces with
the Ethereum blockchain (perhaps in addition to other services)
somehow. These clients are frequently written in JavaScript because we
haven’t yet finished converting everything in the world to NodeJS.
More
seriously, most dApp clients are written primarily in JavaScript
because it can be run in a web browser and everyone’s already got one of
those. They’re also frequently written in Go due to a superior state of
existing tooling available. It’s a viciously positive cycle of
improvement, which means unless you really know what you’re doing, you
get to choose between JavaScript and Go (and to a certain extent, Rust)
for interfacing with the Ethereum blockchain and the protocols being
developed on top of it.
*
So there’s a little bit of confusion/discussion around the exact
terminology/definition of “Distributed App”: is it just the smart
contract(s)? Is it the entire backend of a system which, at some point,
interfaces with the Ethereum platform to store trust? Or maybe it
includes the client code, too, and the user interface so the whole
bundle of stuff is called a “dApp”?
*
I’ve gone ahead and defined as “the backend of a system that interfaces
with the Ethereum blockchain”. This is different enough from “Smart
Contract” to warrant its own concept and also implies (correctly) that anyone can create a client to interface with a distributed app
dApp Browsers
A
dApp Browser is exactly what it says on the tin; it’s an application (a
normal one that we’re all familiar with) that makes using dApp clients
(usually javascript that interfaces with an Ethereum node to communicate
with smart contracts) easier.
The primary purposes of a dApp browser are to
- Provide a connection to an Ethereum node (either to one hosted locally or remotely) and an easy way to change that connection to point to a different node (which might be connected to a different network),
- And provide an account (and optionally a wallet) for the user so that they can easily interface with these dApps.
Mist
is the official Ethereum dApp browser. It’s really just a pretty web UI
for interfacing with an Ethereum node and sending transactions to/from
Smart Contracts (dApps!).
Status is a mobile browser with a unique approach to the UX of using dApps.
Toshi is Coinbase’s foray into building an Ethereum wallet and browser. It bets big on the “wechat” + “chatbot” vibes.
MetaMask is a Chrome Extension that turns Chrome into a “dApps Browser”. Its core feature is that it injects
web3,
a JavaScript Ethereum client library, into every page, allowing dApps
to connect to MetaMask’s hosted Ethereum nodes. The Chrome extension
allows you to manage wallets and connect to the different Ethereum
networks available.
Parity
is a an Ethereum client (as well as a full-node implementation) that
integrates with your web browser, turning it into a dApp browser.
Ethereum Nodes
Mostly
everything you know about Bitcoin nodes applies here. Nodes store a
copy of the blockchain and optionally execute all of the transactions to
confirm the resulting state. Run yourself a full node or light client
with geth (first-party, Go) or parity (third-party, Rust).
Your
node needs to know which blockchain to download and which peers to talk
to; see below for a discussion of the different networks available.
You
should probably go ahead and run all of these node clients with docker
and some sort of persistent storage. If you don’t feel like running a
node on your own, you can use a third party like Infura. There is also a way to run a local node for testing and development, discussed later.
If
you’re distributing a dApp client to users, you don’t necessarily need
to provide access to an Ethereum node as well; dApp Browsers provide the
connection to any client that needs it.
Ethereum Tokens
So
you know how we can write code (a “Smart Contract”) that stores some
state on a blockchain? What if, in that state, we stored a map of
ethereum addresses to an integer. And called that integer your balance.
Your balance of what? Let’s just call them “tokens”. Oh.
Yeah,
all of the “tokens” that you hear about are just numbers in a
distributed hash table with an API (aka protocol) to add and subtract. Here’s what a basic token contract looks like (that’s 38 lines of code, half of it comments and whitespace).
Go ahead and read the ethereum.org tutorial on creating a crowdsale; you’ll see that it’s just a contract (
Crowdsale) that interfaces with another contract (MyToken) which is just like the basic token contract linked above. It’s not magic.
People are using tokens for a variety of uses, and you’ll quickly see that imagination has no limits.
Tokens are frequently used to incentivize interaction with a protocol,
prove ownership of assets, proof of voting rights, etc. Fred Ehrsam from Coinbase has a good talk about tokens, why they exist, and how they’re being used.
Vitalik recently wrote a blog post analyzing token sale models, which is a good read.
ERC20 Tokens / ERC223 Tokens / ERC721 NFT
Everyone
started defining their own protocol for interfacing with their Token
contract and that got old pretty quickly, so some some people got
together and created the ERC20 spec. It just says “hey, support these function signatures and we’ll all have a much better time”.
Some people thought ERC20 was too complicated so they proposed ERC197, which is slightly less complicated.
Due to minor issues with the ERC20 spec, an ERC223 Token spec was proposed.
ERC223 is backwards-compatible with ERC20, but still under discussion.
If you’re creating a Token contract, consider supporting ERC223.
* there had been some confusion around ERC223 vs ERC23, but they are the same concept; the ERC number is 223, so this standard should be referred to as ERC223.
ERC721
defines a non-fungible token standard. Non-fungibility means that each
token is not equal to another; one “token” can be worth more or less
than another and have unique properties. The best example of this is
something like CryptoPunks or CryptoKitties.
Protocol Tokens and “App Coins”
A Protocol Token is designed to incentivize usage of a protocol.
For example, REP, an Augur Reputation Token, encourages usage of the
Augur decentralized oracle protocol. Most of the Ethereum ERC20/ERC23
Tokens are protocol tokens; for example, Augur’s REP, Golems GNT,
ICONOMI, the Basic Attention Token, etc.
An
app coin is designed to incentivize usage of a specific dApp or client,
rather than the protocol it uses to provide its value. A good example
of this is the Status SNT token, which users can exchange for value
within the Status mobile app (like push notifications, voting rights,
obtaining a username, etc).
The
paradigm shift here is that we can start investing in protocols rather
than apps, since we can build upon them (anyone can build a dApp using a
protocol or build a dApp client for a dApp that implements that
protocol).
Previously this wasn’t really possible, because to monetize a protocol you generally built an app on top of it and sold that instead. Now you can monetize the protocol itself, which is better for collaboration and the future.
You should probably just read this post by Will Warren of the 0xProject.
Interfacing with Smart Contracts
You
interface with your smart contract (aka, calling functions and reading
state) by connecting to an Ethereum node and issuing opcodes over a JSON
RPC API. There are a variety of Ethereum node clients that perform this
in a developer-friendly way. Both geth and parity provide
consoles/browsers for interfacing with contracts.
If you’d like to programmatically interface with contracts, there are various Ethereum client implementations. For JavaScript, web3.js and ethjs are popular. For golang, the
abigen executable in go-ethereum
provides go packages for interfacing with contracts. At the end it’s
just a JSON RPC API, so you can always write your own adaptor for the
language of your choice if once isn’t available. Some client libraries
provide convenience functions as well, beyond simple function execution.
Run a local ethereum node for testing and development with Ganache (previously called ethereumjs-testrpc).
When you “deploy” a smart contract, all you’re really doing is sending a transaction to the 0-address (
0x0 ) with the contract bytecode as an argument.
Here’s more information about transactions:
Truffle, Embark, Populous, Perigord & Others
Once
you start writing smart contracts, you end up doing a lot of the same
things over and over again; compiling your source code to bytecode and
an abi, deploying it to the network, testing the deployed contract, etc.
You probably also want a nice way to play around with new ideas.
Frameworks
like Truffle, Embark, Populous, and Perigord standardize and automate a
lot of the minutiae. They provide a nice developer experience for
writing contracts, deploying contracts, and incredibly importantly,
testing contracts.
Truffle (written in Node) has the most developer adoption and seems to have the most active development; follow the Getting Started guide to get up to speed.
This post has a lot of good information and uses truffle to deploy and interface with a contract.
Embark (Node) has similar but different ideas for how developers should structure projects.
Perigord (Go) is very similar to Truffle.
Populous (Python) is an actively developed python framework that satisfies the same niche.
When
you first start playing around with contracts, you should avoid using a
framework until you understand the value it provides, much in the same
way you shouldn’t start learning how to write HTML with
rails new . The easiest thing to do at first is use Remix to play around with the language and ideas.ETHPM & NPM
Sharing is caring, so ETHPM is a decentralized repository of smart contract packages.
Using ETHPM, you can inherit from or link to other well-known contracts
and libraries, reducing code duplication and ideally providing a strong
foundation of good contracts for future development.
Of note, you can also use NPM to provide smart contract code for distribution, which a lot of people do, notably Open Zeppelin.
Read the spec for more information and background.
State of the Networks
Mainnet — the main Ethereum network, and generally the default in whatever client or browser you’re using.
Ropsten — The
primary Ethereum testnet using Proof of Work. This network, because of
low computation volume, is easy to DDOS, split, and otherwise mess with.
It was recently revived and is usable again after being temporarily
abandoned after a spam attack.
Kovan — A
parity-client only testnet using Proof of Authority which advertises
immunity to spam attacks and a consistent 4 second block time.
Rinkeby — A
geth-client only testnet using Clique Consensus, which is therefore
more resilient to malicious actors, despite the low computation volume.
You can also run your own private Ethereum network. The go-ethereum team built puppeth
to configure a full network, complete with custom bootnodes, genesis
block, and consensus rules, which is what powers the Rinkeby network.
You can also run your own infrastructure, perhaps using kubernetes or docker-compose. But you probably won’t need to run a private network any time soon.
“Accounts” vs “Wallet”
An Ethereum account
is a private key and address pair. They basically just store Ether, and
they don’t cost gas to create. All transactions on the Ethereum network
originate from an account; contracts don’t have the ability to initiate
a transaction.
A wallet is just a smart contract (which, again, is just some code); it’s not a native concept. Here’s the Solidity implementation on GitHub that’s used by the Mist browser.
They can come in many flavors like multisignature, paper, etc. “Wallet”
can also be used to describe a fancy client-side interface for
generating and sending transactions from an account (in the case of
MyEtherWallet).
Now
that we’ve correctly defined the two, prepare to see people confusing
the two terms everywhere and labelling anything that stores Ether as a
Wallet and calling anything and everything an account.
EVM and the State of Smart Contract Creation
The
code that is your Smart Contract runs on every full node in the network
within the EVM (Ethereum Virtual Machine). It’s your standard virtual
machine that executes some bytecode, except the vm is specifically
isolated from the network, the filesystem, processes, etc. Nobody wants
to write bytecode, so we’ve got some higher level languages that compile
down to EVM bytecode.
Solidity
Solidity
is the first-party language for describing smart contracts. It’s the
most popular and therefore has the most examples, references, and
tutorials. You should probably learn this one unless you know what
you’re doing.
Play around with Solidity in Remix, a web-based playground for Solidity contracts.
Here’s what Solidity looks like:
pragma solidity ^0.4.11;
contract BasicToken {
mapping(address => uint256) balances;
function transfer(address _to, uint256 _value) returns () {
balances[msg.sender] = balances[msg.sender] - _value;
balances[_to] = balances[_to] + _value;
}
function balanceOf(address _owner) constant returns (uint256 balance) {
return balances[_owner];
}
}
LLL
LLL,
which stands for Low-Level Lisp-Like Language, is exactly what it
sounds like on the tin. While LLL isn’t advertised as the primary
language supported by the Ethereum team, it still receives updates and
is hosted in the same repo as Solidity.
LLL looks something like:
(seq
(def 'node-bytes 0x00)
(def 'owner 0x20) ; address
(def 'set-node-owner 0x5b0fc9c3) ; setOwner(bytes32,address)
(def 'get-owner (node)
(sload (+ node owner)))
.... this is just for illustration purposes, this definitely won't compile.
If you’re learning, you probably don’t want to write anything in LLL.
Serpent
Serpent is a high-level python-esq language that compiles to EVM bytecode. It’s primarily used by the Augur team.
The
compiler was recently audited by Zeppelin Solutions, who discovered a
set of critical-severity bugs; it’s not recommended to use Serpent until
these points are fixed.
If you’re interested in how Augur handled the vulnerability disclosure, you can read Zeppelin Solutions’ post here.
The Augur team is also migrating to Solidity, which doesn’t bode well for the existing Serpent codebase.
Here’s what Serpent looks like, for reference:
def register(key, value):
# Key not yet claimed
if not self.storage[key]:
self.storage[key] = value
return(1)
else:
return(0) # Key already claimed
def ask(key):
return(self.storage[key])Viper
Viper is also python-inspired and developed with a focus on security, simplicity, and no-surprises. It is still in development.
Bamboo
Bamboo
is a language designed to represent a smart contract as a finite state
machine; your contract is a function of state and transaction and
produces a new state. It is still in development.
Others
There
are a bunch of other high-level languages in various states of
usability and development and more will undoubtedly be developed. In
order to reach wide adoption, though, a language and compiler must be
thoroughly vetted and tested, which will take time.
Smart Contract Decompilation/Disassembly
Decompile Ethereum smart contract bytecode with prosity or disassemble it with evmdis. This is a constantly evolving area, and new tools are bing developed pretty quickly. The Awesome Ethereum Virtual Machine repo will contain more information.
Smart Contract Security
Once
a smart contract is deployed to Ethereum, it is immutable and exists
forever. If you write a bug, you don’t get to take down the broken
version; you can only fix-forward*.
Because
so many engineers developing for Ethereum and other smart contract
platforms are coming from web development, this concept might be new and
crazy.
There
are a variety of different security-related traps your code could fall
into, both at a language level and from a high-level logic perspective. When
you deploy a production smart contract that handles real money, you
need to be 100% confident in the operation of the contract.
ConsenSys has a beautiful repository of smart contract best practices that you should understand at a deep level.
Before you deploy a smart contract that’ll handle real cash money, you should probably open a bug bounty and have it pentested. If you’re handling RealMoney™, you should have your code professionally audited.
* there’s a selfdestruct() function that a contract can use to remove itself from the network.
Whisper
Whisper
is a messaging system build into Ethereum. It allows dApps to publish
small amounts of information for the purpose of communicating with each
other in non-real-time.
It uses the protocol
shh which is pretty cute. There’s surprisingly little documentation and adopting of this protocol.
Although it hasn’t been updated in a while, here’s an example dapp using Whisper to implement a chat client.
Whether or not whisper is under active development is up for discussion.
Decentralized Autonomous Organizations (DAOs)
This
is an organization (like, a group of human beings) where, instead of
using legal documents to enforce operation, they use a bunch of smart
contracts. Your group of human beings then uses these contracts to do
all the normal stuff an organization does, like vote on things and
determine what color all the local co-op houses should be painted.
A
side effect of this is that decision making, governance, and what color
the houses should be painted is immutably stored on the blockchain (in
the state of those contracts). Cool stuff.
The people at slock.it have created a “Standard DAO Framework” to illustrate the concept. The GitHub README has a good overview of the concept of a DAO and how you can use their framework to start your own.
Ethereum Classic and the DAO Hack
You’ve probably heard about the “DAO hack”
and how big of a deal it was. The exploit occurred due to a now
highly-recognized re-entrancy bug; a malicious contract could cause a
non-infinite, recursive call to the contract, causing it to update
internal state incorrectly. In the case of the DAO contract, this meant
lots of money being sent to someone that should have only gotten small
amounts of money. The community voted as a super majority to hard-fork
the network and restore funds to the DAO contributors. This resulted in
the birth of Ethereum Classic, where no funds were returned; the code that was written is the law of the land, and cannot be reverted.
Credits :Matt Condon
Comments
Post a Comment