description::
"Ethereum is a programmable blockchain.
Rather than give users a set of pre-defined operations (e.g. bitcoin transactions), Ethereum allows users to create their own operations of any complexity they wish. In this way, it serves as a platform for many different types of decentralized blockchain applications, including but not limited to cryptocurrencies."
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]
name::
* McsEngl.McsTchInf000018.last.html//dirTchInf//dirMcs!⇒DnEthereum,
* McsEngl.dirMcs/dirTchInf/McsTchInf000018.last.html!⇒DnEthereum,
* McsEngl.D-stroke-Ethereum!⇒DnEthereum, {2017-12-20},
* McsEngl.Deth!⇒DnEthereum, {2019-06-16},
* McsEngl.Deth-net!⇒DnEthereum, {2019-04-14},
* McsEngl.DnEth!⇒DnEthereum, {2019-06-17},
* McsEngl.DnEthereum, {2019-06-18},
* McsEngl.Eth-net!⇒DnEthereum, {2019-03-26},
* McsEngl.Ethereum!⇒DnEthereum,
* McsEngl.Ethereum--blockchain-network!⇒DnEthereum,
* McsEngl.Ethereum-ecosystem!⇒DnEthereum,
* McsEngl.Ethereum-net!⇒DnEthereum,
* McsEngl.Ethereum-network!⇒DnEthereum,
* McsEngl.Ethereum-platform!⇒DnEthereum,
* McsEngl.Ethereum-project!⇒DnEthereum,
* McsEngl.Ethereum-space!⇒DnEthereum,
* McsEngl.decentralized-Ethereum-blockchain-net!⇒DnEthereum,
* McsEngl.netEth!⇒DnEthereum, {2017-01-28},
* McsEngl.network.Ethereum!⇒DnEthereum,
* McsEngl.blockchain-net.Ethereum!⇒DnEthereum,
* McsEngl.chain-net.Ethereum!⇒DnEthereum,
* McsEngl.Đb-Ethereum!⇒DnEthereum, {2018-01-30},
* McsEngl.Đ-Ethereum!⇒DnEthereum, {2017-12-19},
* McsEngl.Đ-Ethereum!⇒DnEthereum, {2017-12-19},
* McsEngl.Đblock-net.Ethereum!⇒DnEthereum,
* McsEngl.Đ-Eth!⇒DnEthereum,
description::
Ethereum is a peer to peer network where every peer stores the same copy of a blockchain database and runs an Ethereum virtual machine to maintain and alter it’s state. Proof of work is integrated into the blockchain technology by making the creation of a new block require all members of the network undertake the proof of work. Consensus is achieved via incentivization for peers to always accept the longest chain of blocks in the blockchain by distribution of a cryptographic token of value: ‘ether’.
This leaves us with a new piece of technology that does not fit within the client-server model nor does it qualify as a traditional peer-to-peer network as its existence is incentivised meaning it can be relied upon to provide a consistent deterministic service.
Because of its distributed nature and built in cryptographic security it can act as a third party, capable of arbitrating trustlessly, and without interference from outside parties. Through the use of cryptocurrencies decisions made by software can have financial consequences for people, organisations or even other software.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
Ether is a necessary element -- a fuel -- for operating the distributed application platform Ethereum. [https://ethereum.org/ether]
===
Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.
Ethereum is how the Internet was supposed to work.
Ethereum was crowdfunded during August 2014 by fans all around the world. It is developed by ETHDEV with contributions from great minds across the globe.
[https://www.ethereum.org/]
Original author(s) Vitalik Buterin, Gavin Wood
Developer(s) Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in C++, Go, JavaScript, Python, Java, node.js
Operating system Linux, POSIX, Windows, OS X
Type Decentralized computing
License GPL3, MIT, LGPL, et al
Website www.ethereum.org
Ethereum Software ETHEREUM-YOUTUBE-PROFILE-PIC.png
Original author(s) Vitalik Buterin, Gavin Wood
Developer(s) Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in C++, Go, JavaScript, Python, Java, node.js
Operating system Linux, POSIX, Windows, OS X
Type Decentralized computing
License GPL3, MIT, LGPL, et al
Website www.ethereum.org
Ethereum is a blockchain-based cryptocurrency that includes a virtual machine featuring stateful user-created smart contracts and a Turing-complete contract language. Ethereum uses its currency unit, Ether, as payment to incentivise a network of peers to provide computational services defined by the smart contracts deployed on the blockchain.
Ethereum was initially described by Vitalik Buterin in late 2013,[1] formally described by Gavin Wood in early 2014 in the so-called Yellow Paper[2] and launched 30 July 2015.[3] It is among a group of "next generation" (or "Bitcoin 2.0") platforms.[4]
[https://en.wikipedia.org/wiki/Ethereum]
===
Ethereum was designed as a smart contract platform.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
===
Ethereum – a Decentralised Consensus Network
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
Ethereum is the world's first publicly accessible computer. Situated on the Internet, anyone may pay a small fee to its open group of maintainers in order to use it. Secured and authenticated through cryptography, it provides a unprecedented opportunity for use as the cornerstone of IoT, Internet-law, smart contracts and the next digital economy.
[https://ethcore.io/]
===
The basis for decentralised consensus is the peer-to-peer network of participating nodes which maintain and secure the blockchain.
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-ecosystem/infrastructure.html#the-ethereum-network]
===
Ethereum is a programmable blockchain. Rather than give users a set of pre-defined operations (e.g. bitcoin transactions), Ethereum allows users to create their own operations of any complexity they wish. In this way, it serves as a platform for many different types of decentralized blockchain applications, including but not limited to cryptocurrencies.
Ethereum in the narrow sense refers to a suite of protocols that define a platform for decentralised applications. At the heart of it is the Ethereum Virtual Machine (“EVM”), which can execute code of arbitrary algorithmic complexity. In computer science terms, Ethereum is “Turing complete”. Developers can create applications that run on the EVM using friendly programming languages modelled on existing languages like javascript and python.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#what-is-ethereum]
===
Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.
Ethereum is how the Internet was supposed to work.
Ethereum was crowdfunded during August 2014 by fans all around the world. It is developed by ETHDEV with contributions from great minds across the globe.
[https://www.ethereum.org/]
Original author(s) Vitalik Buterin, Gavin Wood
Developer(s) Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in C++, Go, JavaScript, Python, Java, node.js
Operating system Linux, POSIX, Windows, OS X
Type Decentralized computing
License GPL3, MIT, LGPL, et al
Website www.ethereum.org
Ethereum Software ETHEREUM-YOUTUBE-PROFILE-PIC.png
Original author(s) Vitalik Buterin, Gavin Wood
Developer(s) Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in C++, Go, JavaScript, Python, Java, node.js
Operating system Linux, POSIX, Windows, OS X
Type Decentralized computing
License GPL3, MIT, LGPL, et al
Website www.ethereum.org
Ethereum is a blockchain-based cryptocurrency that includes a virtual machine featuring stateful user-created smart contracts and a Turing-complete contract language. Ethereum uses its currency unit, Ether, as payment to incentivise a network of peers to provide computational services defined by the smart contracts deployed on the blockchain.
Ethereum was initially described by Vitalik Buterin in late 2013,[1] formally described by Gavin Wood in early 2014 in the so-called Yellow Paper[2] and launched 30 July 2015.[3] It is among a group of "next generation" (or "Bitcoin 2.0") platforms.[4]
[https://en.wikipedia.org/wiki/Ethereum]
External Actor:
A person or other entity able to interface to an Ethereum node, but external to the world of Ethereum.
It can interact with Ethereum through depositing signed Transactions and inspecting the blockchain and associated state.
Has one (or more) intrinsic Accounts.
[http://gavwood.com/Paper.pdf]
Account:
Accounts have an intrinsic balance and transaction count maintained as part of the Ethereum state.
They also have some (possibly empty) EVM Code and a (possibly empty) Storage State associated with them.
Though homogenous, it makes sense to distinguish between two practical types of account: those with empty associated EVM Code (thus the account balance is controlled, if at all, by some external entity) and those with non-empty associated EVM Code (thus the account represents an Autonomous Object). Each Account has a single Address that identifies it.
[http://gavwood.com/Paper.pdf]
Transaction: A piece of data, signed by an External Actor. It represents either a Message or a new Autonomous Object. Transactions are recorded into each block of the blockchain.
[http://gavwood.com/Paper.pdf]
Autonomous Object: A notional object existent only within the hypothetical state of Ethereum. Has an intrinsic address and thus an associated account; the account will have non-empty associated EVM Code. Incorporated only as the Storage State of that account.
[http://gavwood.com/Paper.pdf]
Storage State: The information particular to a given Account that is maintained between the times that the
Account’s associated EVM Code runs.
[http://gavwood.com/Paper.pdf]
Message: Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts, either
through the deterministic operation of an Autonomous Object or the cryptographically secure signature of the Transaction.
[http://gavwood.com/Paper.pdf]
Message Call: The act of passing a message from one Account to another. If the destination account is associated with non-empty EVM Code, then the VM will be started with the state of said Object and the Message acted upon. If the message sender is an Autonomous Object, then the Call passes any data returned from the VM operation.
[http://gavwood.com/Paper.pdf]
Gas: The fundamental network cost unit. Paid for exclusively by Ether (as of PoC-4), which is converted freely to and from Gas as required. Gas does not exist outside of the internal Ethereum computation engine; its price is set by the Transaction and miners are free to ignore Transactions whose Gas price is too low.
[http://gavwood.com/Paper.pdf]
Contract: Informal term used to mean both a piece of EVM Code that may be associated with an Account or an Autonomous Object.
[http://gavwood.com/Paper.pdf]
Object: Synonym for Autonomous Object.
[http://gavwood.com/Paper.pdf]
App: An end-user-visible application hosted in the Ethereum Browser.
[http://gavwood.com/Paper.pdf]
Ethereum Browser: (aka Ethereum Reference Client) A cross-platform GUI of an interface similar to a simplified browser (a la Chrome) that is able to host sandboxed applications whose backend is purely on the Ethereum protocol.
[http://gavwood.com/Paper.pdf]
Ethereum Virtual Machine: (aka EVM) The virtual machine that forms the key part of the execution model for an Account’s associated EVM Code.
[http://gavwood.com/Paper.pdf]
Ethereum Runtime Environment: (aka ERE) The environment which is provided to an Autonomous Object executing in the EVM. Includes the EVM but also the structure of the world state on which the EVM relies for certain I/O instructions including CALL & CREATE.
[http://gavwood.com/Paper.pdf]
EVM Assembly: The human-readable form of EVM-code.
[http://gavwood.com/Paper.pdf]
This is why you might have heard people call Ethereum ‘trustless’ – there’s no need for users to trust into a central authority to ‘do the right thing’.
[https://dappsforbeginners.wordpress.com/tutorials/your-first-dapp/]
name::
* McsEngl.DnEthereum'trustless-attribute,
generic-tree::
* chain-net'decentralized-trust,
description::
The state in Ethereum essentially consists of a key-value map, where the keys are addresses and the values are account declarations, listing the balance, nonce, code and storage for each account (where the storage is itself a tree).
For example, the Morden testnet genesis state looks as follows:
{
"0000000000000000000000000000000000000001": {
"balance": "1"
},
"0000000000000000000000000000000000000002": {
"balance": "1"
},
"0000000000000000000000000000000000000003": {
"balance": "1"
},
"0000000000000000000000000000000000000004": {
"balance": "1"
},
"102e61f5d8f9bc71d0ad4a084df4e65e05ce0e1c": {
"balance": "1606938044258990275541962092341162602522202993782792835301376"
}
}
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
===
The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEthereum'state,
* McsEngl.DnEth-state,
* McsEngl.Ethereum-state,
description::
Unlike transaction history, however, the state needs to be frequently updated: the balance and nonce of accounts is often changed, and what’s more, new accounts are frequently inserted, and keys in storage are frequently inserted and deleted. What is thus desired is a data structure where we can quickly calculate the new tree root after an insert, update edit or delete operation, without recomputing the entire tree. There are also two highly desirable secondary properties:
The depth of the tree is bounded, even given an attacker that is deliberately crafting transactions to make the tree as deep as possible. Otherwise, an attacker could perform a denial of service attack by manipulating the tree to be so deep that each individual update becomes extremely slow.
The root of the tree depends only on the data, not on the order in which updates are made. Making updates in a different order and even recomputing the tree from scratch should not change the root.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
name::
* McsEngl.DnEthereum'protocol!⇒DnEthereum-protocol,
* McsEngl.DnEth-protocol, {2019-03-31},
* McsEngl.Ethereum-protocol!⇒DnEthereum-protocol,
* McsEngl.protocol-of-Ethereum!⇒DnEthereum-protocol,
generic::
* blockchain-protocol,
description::
Contrast this to the Ethereum ecosystem which today has no less than 6 implementations of consensus: C++, Go, Python, Java, JavaScript, and Haskell.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
name::
* McsEngl.DnEthereum'coding-language,
* McsEngl.DnEthereum'source-code-language,
* McsEngl.DnEth-protocol'implementation-language,
addressWpg::
* 0x: An open protocol for decentralized exchange on the Ethereum blockchain: https://0xproject.com/pdfs/0x_white_paper.pdf,
name::
* McsEngl.white-paper--of--Ethereum-net,
* McsEngl.DnEthereum'white-paper,
* McsEngl.DnEth-protocol'white-paper,
* McsEngl.Ethereum-wpr-(Ethereum--white-paper),
addressWpg::
* {2017-03-12} 36-revision: https://github.com/ethereum/wiki/wiki/White-Paper/307f463132be1878013196695ef82ca19eee4693,
A Next-Generation Smart Contract and Decentralized Application Platform
Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value" and no centralized issuer or controller.
However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin.
Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins"), the ownership of an underlying physical device ("smart property"), non-fungible assets such as domain names ("Namecoin"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules ("smart contracts") or even blockchain-based "decentralized autonomous organizations" (DAOs).
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades.
The anonymous e-cash protocols of the 1980s and the 1990s were mostly reliant on a cryptographic primitive known as Chaumian Blinding.
Chaumian Blinding provided these new currencies with high degrees of privacy, but their underlying protocols largely failed to gain traction because of their reliance on a centralized intermediary.
In 1998, Wei Dai's b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented.
In 2005, Hal Finney introduced a concept of "reusable proofs of work", a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend.
In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work."
The mechanism behind proof of work was a breakthrough because it simultaneously solved two problems.
First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of updates to the state of the Bitcoin ledger.
Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing Sybil attacks.
It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings.
Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not its computational resources.
The discussion concerning the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.
From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result.
In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value of A's account by $X and increases the value of B's account by $X.
If A's account has less than $X in the first place, the state transition function returns an error.
Hence, one can formally define:
APPLY(S,TX) -> S' or ERROR
In the banking system defined above:
APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
But:
APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key[ 1 ]).
A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO for addition to the state.
The state transition function APPLY(S,TX) -> S'
can be defined roughly as follows:
1. For each input in TX
:
* If the referenced UTXO is not in S
, return an error.
* If the provided signature does not match the owner of the UTXO, return an error.
2. If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.
3. Return S'
with all input UTXO removed and all output UTXO added.
The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value.
In order to use this for payment, the protocol is as follows.
Suppose Alice wants to send 11.7 BTC to Bob.
First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC.
Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12.
She then creates a transaction with those three inputs and two outputs.
The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change".
If Alice does not claim this change by sending it to an address owned by herself, the miner will be able to claim it.
If we had access to a trustworthy centralized service, this system would be trivial to implement; it could be coded exactly as described, using a centralized server's hard drive to keep track of the state.
However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transition system with a consensus system in order to ensure that everyone agrees on the order of transactions.
Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks".
The network is intended to create one block approximately every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e., hash of) the previous block and a list of all of the transactions that have taken place since the previous block.
Over time, this creates a persistent, ever-growing, "blockchain" that continually updates to represent the latest state of the Bitcoin ledger.
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
1. Check if the previous block referenced by the block exists and is valid.
2. Check that the timestamp of the block is greater than that of the previous block[ 2 ] and less than 2 hours into the future
3. Check that the proof of work on the block is valid.
4. Let S[0]
be the state at the end of the previous block.
5. Suppose TX
is the block's transaction list with n
transactions. For all i
in 0...n-1
, set S[i+1] = APPLY(S[i],TX[i])
If any application returns an error, exit and return false.
6. Return true, and register S[n]
as the state at the end of this block.
Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state.
Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block.
Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work".
The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187.
The purpose of this is to make block creation computationally "hard", thereby preventing Sybil attackers from remaking the entire blockchain in their favor.
Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.
At the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes.
In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere.
Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee".
Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker.
Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions.
The attacker's strategy is simple:
1. Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)
2. Wait for the delivery of the product
3. Produce another transaction sending the same 100 BTC to himself
4. Try to convince the network that his transaction to himself was the one that came first.
Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000.
After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it.
At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant.
Now, the attacker creates another transaction sending the 100 BTC to himself.
If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX)
and notice that TX
consumes a UTXO which is no longer in the state.
So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one.
Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate.
The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain.
In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").
01: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.
02: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.
An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure.
The "hash" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block.
A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree.
The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct.
The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof of work).
The Merkle tree protocol is arguably essential to long-term sustainability.
A "full node" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month.
Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate.
A protocol known as "simplified payment verification" (SPV) allows for another class of nodes to exist, called "light nodes", which download the block headers, verify the proof of work on the block headers, and then download only the "branches" associated with transactions that are relevant to them.
This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.
The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history.
In 2005, Nick Szabo came out with the concept of "secure property titles with owner authority", a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax.
However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice.
After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.
* Namecoin - created in 2010, Namecoin is best described as a decentralized name registration database.
In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy
.
Ideally, one would like to be able to have an account with a name like "george".
However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them.
The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol.
Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
* Colored coins - the purpose of colored coins is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain.
In the colored coins protocol, one "issues" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs).
This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.
* Metacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY'
.
Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY'(S,TX)
returns an error, the protocol defaults to APPLY'(S,TX) = S
.
This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol.
Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.
Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin.
The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code.
Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.
The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin.
SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state.
Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols.
Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid.
Currently, all "light" implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.
Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of "smart contracts".
UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language.
In this paradigm, a transaction spending that UTXO must provide data that satisfies the script.
Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise.
Other, more complicated, scripts exist for various additional use cases.
For example, one can construct a script that requires signatures from two out of a given three private keys to validate ("multisig"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations.
Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like "this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me", essentially allowing decentralized cross-cryptocurrency exchange.
However, the scripting language as implemented in Bitcoin has several important limitations:
* Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything.
The main category that is missing is loops.
This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient.
For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.
* Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn.
For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B.
This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now.
However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B.
* Lack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that.
This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties).
It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement.
Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.
* Blockchain-blindness - UTXO are blind to certain blockchain data such as the nonce and previous block hash.
This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.
Thus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin.
Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security.
Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability.
With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.
The intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important.
Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions.
A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty.
Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.
In Ethereum, the state is made up of objects called "accounts", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts.
An Ethereum account contains four fields:
* The nonce, a counter used to make sure each transaction can only be processed once
* The account's current ether balance
* The account's contract code, if present
* The account's storage (empty by default)
"Ether" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees.
In general, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code.
An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.
Note that "contracts" in Ethereum should not be seen as something that should be "fulfilled" or "complied with"; rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.
The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account.
Transactions contain:
* The recipient of the message
* A signature identifying the sender
* The amount of ether to transfer from the sender to the recipient
* An optional data field
* A STARTGAS
value, representing the maximum number of computational steps the transaction execution is allowed to take
* A GASPRICE
value, representing the fee the sender pays per computational step
The first three are standard fields expected in any cryptocurrency.
The data field has no function by default, but the virtual machine has an opcode with which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two "fields", the first field being a domain to register and the second field being the IP address to register it to.
The contract would read these values from the message data and appropriately place them in storage.
The STARTGAS
and GASPRICE
fields are crucial for Ethereum's anti-denial of service model.
In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use.
The fundamental unit of computation is "gas"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state.
There is also a fee of 5 gas for every byte in the transaction data.
The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.
Contracts have the ability to send "messages" to other contracts.
Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment.
A message contains:
* The sender of the message (implicit)
* The recipient of the message
* The amount of ether to transfer alongside the message
* An optional data field
* A STARTGAS
value
Essentially, a message is like a transaction, except it is produced by a contract and not an external actor.
A message is produced when a contract currently executing code executes the CALL
opcode, which produces and executes a message.
Like a transaction, a message leads to the recipient account running its code.
Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.
Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions.
For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.
The Ethereum state transition function, APPLY(S,TX) -> S'
can be defined as follows:
1. Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error.
2. Calculate the transaction fee as STARTGAS * GASPRICE
, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error.
3. Initialize GAS = STARTGAS
, and take off a certain quantity of gas per byte to pay for the bytes in the transaction.
4. Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.
5. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.
6. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.
For example, suppose that the contract's code is:
if !self.storage[calldataload(0)]:
self.storage[calldataload(0)] = calldataload(32)
Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code.
Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number 2
and bytes 32-63 representing the string CHARLIE
.
The process for the state transition function in this case is as follows:
1. Check that the transaction is valid and well formed.
2. Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the sender's account.
3. Initialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left.
3. Subtract 10 more ether from the sender's account, and add it to the contract's account.
4. Run the code. In this case, this is simple: it checks if the contract's storage at index 2
is used, notices that it is not, and so it sets the storage at index 2
to the value CHARLIE
. Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963
5. Add 963 * 0.001 = 0.963 ether back to the sender's account, and return the resulting state.
If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE
multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.
Note that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert.
This means that it is "safe" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas.
Finally, note that there is an opcode, CREATE
, that creates a contract; its execution mechanics are generally similar to CALL
, with the exception that the output of the execution determines the code of a newly created contract.
The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as "Ethereum virtual machine code" or "EVM code".
The code consists of a series of bytes, where each byte represents an operation.
In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP
or RETURN
instruction is detected.
The operations have access to three types of space in which to store data:
* The stack, a last-in-first-out container to which values can be pushed and popped
* Memory, an infinitely expandable byte array
* The contract's long-term storage, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term,
The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.
The formal execution model of EVM code is surprisingly simple.
While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas)
, where block_state
is the global state containing all accounts and includes balances and storage.
At the start of every round of execution, the current instruction is found by taking the pc
th (Program Counter) byte of code
(or 0 if pc >= len(code)
), and each instruction has its own definition in terms of how it affects the tuple.
For example, ADD
pops two items off the stack and pushes their sum, reduces gas
by 1 and increments pc
by 1, and SSTORE
pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item.
Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.
The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences.
The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state.
Aside from that, two other values, the block number and the difficulty, are also stored in the block.
The basic block validation algorithm in Ethereum is as follows:
1. Check if the previous block referenced exists and is valid.
2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
4. Check that the proof of work on the block is valid.
5. Let S[0]
be the state at the end of the previous block.
6. Let TX
be the block's transaction list, with n
transactions. For all i
in 0...n-1
, set S[i+1] = APPLY(S[i],TX[i])
. If any application returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT
, return an error.
7. Let S_FINAL
be S[n]
, but adding the block reward paid to the miner.
8. Check if the Merkle tree root of the state S_FINAL
is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.
The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin.
The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed.
Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees).
A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently.
Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.
A commonly asked question is "where" contract code is executed, in terms of physical hardware.
This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B
the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B
.
In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.
On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization.
Token systems are surprisingly easy to implement in Ethereum.
The key point to understand is that all a currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (ii) the transaction is approved by A.
All that it takes to implement a token system is to implement this logic into a contract.
The basic code for implementing a token system in Serpent looks as follows:
def send(to, value):
if self.storage[msg.sender] >= value:
self.storage[msg.sender] = self.storage[msg.sender] - value
self.storage[to] = self.storage[to] + value
This is essentially a literal implementation of the "banking system" state transition function described further above in this document.
A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address.
But that's all there is to it.
Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency.
The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction.
Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.
Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code.
The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is.
The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.
Given that critical ingredient, the hedging contract would look as follows:
1. Wait for party A to input 1000 ether.
2. Wait for party B to input 1000 ether.
3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x.
4. After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B.
Such a contract would have significant potential in crypto-commerce.
One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they may not wish to face that prospect of losing 23% of the value of their funds in a single day.
Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD).
The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset.
This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted.
In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist.
Financial derivatives provide an alternative.
Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays that role.
Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow.
Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.
The earliest alternative cryptocurrency of all, Namecoin, attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data.
The major cited use case is for a DNS system, mapping domain names like "bitcoin.org" (or, in Namecoin's case, "bitcoin.bit") to an IP address.
Other use cases include email authentication and potentially more advanced reputation systems.
Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:
def register(name, value):
if !self.storage[name]:
self.storage[name] = value
The contract is very simple; all it is is a database inside the Ethereum network that can be added to, but not modified or removed from.
Anyone can register a name with some value, and that registration then sticks forever.
A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership.
One can even add reputation and web-of-trust functionality on top.
Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee.
However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month.
Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.
The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract".
This contract works as follows.
First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it.
One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree.
When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.
An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession.
If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.
The general concept of a "decentralized autonomous organization" is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code.
The members would collectively decide on how the organization should allocate its funds.
Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work.
This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement.
So far much of the talk around DAOs has been around the "capitalist" model of a "decentralized autonomous corporation" (DAC) with dividend-receiving shareholders and tradable shares; an alternative, perhaps described as a "decentralized autonomous community", would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member.
The requirement that one person can only have one membership would then need to be enforced collectively by the group.
A general outline for how to code a DAO is as follows.
The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change.
Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage.
In a simple implementation of such a DAO contract, there would be three transaction types, distinquished by the data provided in the transaction:
* [0,i,K,V]
to register a proposal with index i
to change the address at storage index K
to value V
* [0,i]
to register a vote in favor of proposal i
* [2,i]
to finalize proposal i
if enough votes have been made
The contract would then have clauses for each of these.
It would maintain a record of all open storage changes, along with a list of who voted for them.
It would also have a list of all members.
When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change.
A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy-style vote delegation (ie. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote).
This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments.
An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision.
A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract).
Delegation would also exist Liquid Democracy-style, generalizing the concept of a "board of directors".
1. Savings wallets.
Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key.
She puts ether into a contract with Bob, a bank, as follows:
* Alice alone can withdraw a maximum of 1% of the funds per day,
* Bob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting off this ability,
* Alice and Bob together can withdraw anything,
Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help.
If Alice's key gets hacked, she runs to Bob to move the funds to a new contract.
If she loses her key, Bob will get the funds out eventually.
If Bob turns out to be malicious, then she can turn off his ability to withdraw.
2. Crop insurance.
One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index.
If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well.
This can be expanded to natural disaster insurance generally.
3. A decentralized data feed.
For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "SchellingCoin".
SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward.
Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth.
This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.
4. Smart multisignature escrow.
Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds.
Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day.
Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.
5. Cloud computing.
The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly.
This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat).
Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes.
Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform.
6. Peer-to-peer gambling.
Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's Cyberdice, can be implemented on the Ethereum blockchain.
The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.
7. Prediction markets.
Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of futarchy as a governance protocol for decentralized organizations.
8. On-chain decentralized marketplaces,
using the identity and reputation system as a base.
The "Greedy Heaviest Observed Subtree" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013.
The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security.
Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time.
Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size.
With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process.
As described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the "longest"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the block's ancestor (in Ethereum jargon, "uncles") are added to the calculation of which block has the largest total proof of work backing it.
To solve the second issue of centralization bias, we go beyond the protocol described by Sompolinsky and Zohar, and also provide block rewards to stales: a stale block receives 87.5% of its base reward, and the nephew that includes the stale block receives the remaining 12.5%.
Transaction fees, however, are not awarded to uncles.
Ethereum implements a simplified version of GHOST which only goes down seven levels.
Specifically, it is defined as follows:
* A block must specify a parent, and it must specify 0 or more uncles
* An uncle included in block B must have the following properties:
o It must be a direct child of the kth generation ancestor of B, where 2 <= k <= 7.
o It cannot be an ancestor of B
o An uncle must be a valid block header, but does not need to be a previously verified or even valid block
o An uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion)
* For every uncle U in block B, the miner of B gets an additional 3.125% added to its coinbase reward and the miner of U gets 93.75% of a standard coinbase reward,
This limited version of GHOST, with uncles includable only up to 7 generations, was used for two reasons.
First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid.
Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.
Because every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees, to prevent abuse.
The default approach, used in Bitcoin, is to have purely voluntary fees, relying on miners to act as the gatekeepers and set dynamic minimums.
This approach has been received very favorably in the Bitcoin community particularly because it is "market-based", allowing supply and demand between miners and transaction senders determine the price.
The problem with this line of reasoning is, however, that transaction processing is not a market; although it is intuitively attractive to construe transaction processing as a service that the miner is offering to the sender, in reality every transaction that a miner includes will need to be processed by every node in the network, so the vast majority of the cost of transaction processing is borne by third parties and not the miner that is making the decision of whether or not to include it.
Hence, tragedy-of-the-commons problems are very likely to occur.
However, as it turns out this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out.
The argument is as follows.
Suppose that:
1. A transaction leads to k
operations, offering the reward kR
to any miner that includes it where R
is set by the sender and k
and R
are (roughly) visible to the miner beforehand.
2. An operation has a processing cost of C
to any node (ie. all nodes have equal efficiency)
3. There are N
mining nodes, each with exactly equal processing power (ie. 1/N
of total)
4. No non-mining full nodes exist.
A miner would be willing to process a transaction if the expected reward is greater than the cost.
Thus, the expected reward is kR/N
since the miner has a 1/N
chance of processing the next block, and the processing cost for the miner is simply kC
.
Hence, miners will include transactions where kR/N > kC
, or R > NC
.
Note that R
is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and NC
is the cost to the entire network together of processing an operation.
Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost.
However, there are several important deviations from those assumptions in reality:
1. The miner does pay a higher cost to process the transaction than the other verifying nodes, since the extra verification time delays block propagation and thus increases the chance the block will become a stale.
2. There do exist nonmining full nodes.
3. The mining power distribution may end up radically inegalitarian in practice.
4. Speculators, political enemies and crazies whose utility function includes causing harm to the network do exist, and they can cleverly set up contracts where their cost is much lower than the cost paid by other verifying nodes.
(1) provides a tendency for the miner to include fewer transactions, and (2) increases NC
; hence, these two effects at least partially cancel each other out.
(3) and (4) are the major issue; to solve them we simply institute a floating cap: no block can have more operations than BLK_LIMIT_FACTOR
times the long-term exponential moving average.
Specifically:
blk.oplimit = floor((blk.parent.oplimit * (EMA_FACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)
BLK_LIMIT_FACTOR
and EMA_FACTOR
are constants that will be set to 65536 and 1.5 for the time being, but will likely be changed after further analysis.
There is another factor disincentivizing large block sizes in Bitcoin: blocks that are large will take longer to propagate, and thus have a higher probability of becoming stales.
In Ethereum, highly gas-consuming blocks can also take longer to propagate both because they are physically larger and because they take longer to process the transaction state transitions to validate.
This delay disincentive is a significant consideration in Bitcoin, but less so in Ethereum because of the GHOST protocol; hence, relying on regulated block limits provides a more stable baseline.
An important note is that the Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops.
EVM code allows looping in two ways.
First, there is a JUMP
instruction that allows the program to jump back to a previous spot in the code, and a JUMPI
instruction to do conditional jumping, allowing for statements like while x < 27: x = x * 2
.
Second, contracts can call other contracts, potentially allowing for looping through recursion.
This naturally leads to a problem: can malicious users essentially shut miners and full nodes down by forcing them to enter into an infinite loop?
The issue arises because of a problem in computer science known as the halting problem: there is no way to tell, in the general case, whether or not a given program will ever halt.
As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps that it is allowed to take, and if execution takes longer computation is reverted but fees are still paid.
Messages work in the same way.
To show the motivation behind our solution, consider the following examples:
* An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner.
The miner will process the transaction, running the infinite loop, and wait for it to run out of gas.
Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step.
* An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee.
However, the attacker will be required to submit a value for STARTGAS
limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps.
* An attacker sees a contract with code of some form like send(A,contract.storage[A]); contract.storage[A] = 0
, and sends a transaction with just enough gas to run the first step but not the second (ie. making a withdrawal but not letting the balance go down).
The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted.
* A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk.
An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas.
However, the financial contract can set a gas limit on the message to prevent this problem.
The alternative to Turing-completeness is Turing-incompleteness, where JUMP
and JUMPI
do not exist and only one copy of each contract is allowed to exist in the call stack at any given time.
With this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, as the cost of executing a contract would be bounded above by its size.
Additionally, Turing-incompleteness is not even that big a limitation; out of all the contract examples we have conceived internally, so far only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code.
Given the serious implications of Turing-completeness, and the limited benefit, why not simply have a Turing-incomplete language?
In reality, however, Turing-incompleteness is far from a neat solution to the problem.
To see why, consider the following contracts:
C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)
Now, send a transaction to A.
Thus, in 51 transactions, we have a contract that takes up 250 computational steps.
Miners could try to detect such logic bombs ahead of time by maintaining a value alongside each contract specifying the maximum number of computational steps that it can take, and calculating this for contracts calling other contracts recursively, but that would require miners to forbid contracts that create other contracts (since the creation and execution of all 26 contracts above could easily be rolled into a single contract).
Another problematic point is that the address field of a message is a variable, so in general it may not even be possible to tell which other contracts a given contract will call ahead of time.
Hence, all in all, we have a surprising conclusion: Turing-completeness is surprisingly easy to manage, and the lack of Turing-completeness is equally surprisingly difficult to manage unless the exact same controls are in place - but in that case why not just let the protocol be Turing-complete?
The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument (see the current mBTC/uBTC/satoshi debate in Bitcoin), the denominations will be pre-labeled:
* 1: wei
* 1012: szabo
* 1015: finney
* 1018: ether
This should be taken as an expanded version of the concept of "dollars" and "cents" or "BTC" and "satoshi". In the near future, we expect "ether" to be used for ordinary transactions, "finney" for microtransactions and "szabo" and "wei" for technical discussions around fees and protocol implementation; the remaining denominations may become useful later and should not be included in clients at this point.
The issuance model will be as follows:
* Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, a mechanism intended to fund the Ethereum organization and pay for development that has been used with success by other platforms such as Mastercoin and NXT. Earlier buyers will benefit from larger discounts. The BTC received from the sale will be used entirely to pay salaries and bounties to developers and invested into various for-profit and non-profit projects in the Ethereum and cryptocurrency ecosystem,
* 0.099x the total amount sold (60102216 ETH) will be allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block,
* 0.099x the total amount sold will be maintained as a long-term reserve,
* 0.26x the total amount sold will be allocated to miners per year forever after that point,
Group | At launch | After 1 year | After 5 years |
Currency units | 1.198X | 1.458X | 2.498X |
Purchasers | 83.5% | 68.6% | 40.0% |
Reserve spent pre-sale | 8.26% | 6.79% | 3.96% |
Reserve used post-sale | 8.26% | 6.79% | 3.96% |
Miners | 0% | 17.8% | 52.0% |
Long-Term Supply Growth Rate (percent):
Despite the linear currency issuance, just like with Bitcoin over time the supply growth rate nevertheless tends to zero
The two main choices in the above model are (1) the existence and size of an endowment pool, and (2) the existence of a permanently growing linear supply, as opposed to a capped supply as in Bitcoin.
The justification of the endowment pool is as follows.
If the endowment pool did not exist, and the linear issuance reduced to 0.217x to provide the same inflation rate, then the total quantity of ether would be 16.5% less and so each unit would be 19.8% more valuable.
Hence, in the equilibrium 19.8% more ether would be purchased in the sale, so each unit would once again be exactly as valuable as before.
The organization would also then have 1.198x as much BTC, which can be considered to be split into two slices: the original BTC, and the additional 0.198x.
Hence, this situation is exactly equivalent to the endowment, but with one important difference: the organization holds purely BTC, and so is not incentivized to support the value of the ether unit.
The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time.
We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (eg. at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium).
Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year.
In the event that the Ethereum organization loses funding or for any other reason disappears, we leave open a "social contract": anyone has the right to create a future candidate version of Ethereum, with the only condition being that the quantity of ether must be at most equal to 60102216 * (1.198 + 0.26 * n)
where n
is the number of years after the genesis block.
Creators are free to crowd-sell or otherwise assign some or all of the difference between the PoS-driven supply expansion and the maximum allowable supply expansion to pay for development.
Candidate upgrades that do not comply with the social contract may justifiably be forked into compliant versions.
The Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2192).
However, this mining algorithm is vulnerable to two forms of centralization.
First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining.
This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in.
Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers.
This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.
The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result.
This has two important benefits.
First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU.
Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction.
This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control.
This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm.
However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs.
The economic incentives exist for ASIC manufacturers to use such a trick to attack each other.
Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one.
One common concern about Ethereum is the issue of scalability.
Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network.
With Bitcoin, the size of the current blockchain rests at about 15 GB, growing by about 1 MB per hour.
If the Bitcoin network were to process Visa's 2000 transactions per second, it would grow by 1 MB per three seconds (1 GB per hour, 8 TB per year).
Ethereum is likely to suffer a similar growth pattern, worsened by the fact that there will be many applications on top of the Ethereum blockchain instead of just a currency as is the case with Bitcoin, but ameliorated by the fact that Ethereum full nodes need to store just the state instead of the entire blockchain history.
The problem with such a large blockchain size is centralization risk.
If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes.
In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (eg. change the block reward, give themselves BTC).
Light nodes would have no way of detecting this immediately.
Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack.
In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification suggested by Peter Todd which will alleviate this issue.
In the near term, Ethereum will use two additional strategies to cope with this problem.
First, because of the blockchain-based mining algorithms, at least every miner will be forced to be a full node, creating a lower bound on the number of full nodes.
Second and more importantly, however, we will include an intermediate state tree root in the blockchain after processing each transaction.
Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol.
If a miner publishes an invalid block, that block must either be badly formatted, or the state S[n]
is incorrect.
Since S[0]
is known to be correct, there must be some first state S[i]
that is incorrect where S[i-1]
is correct.
The verifying node would provide the index i
, along with a "proof of invalidity" consisting of the subset of Patricia tree nodes needing to process APPLY(S[i-1],TX[i]) -> S[i]
.
Nodes would be able to use those nodes to run that part of the computation, and see that the S[i]
generated does not match the S[i]
provided.
Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks, so the full information does not even exist to determine whether or not blocks are valid.
The solution to this is a challenge-response protocol: verification nodes issue "challenges" in the form of target transaction indices, and upon receiving a node a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity.
The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets and the like via a highly generalized programming language.
The Ethereum protocol would not "support" any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application.
What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency.
Protocols around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer.
Finally, there is also a substantial array of applications that have nothing to do with money at all.
The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance, Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.
1. A sophisticated reader may notice that in fact a Bitcoin address is the hash of the elliptic curve public key, and not the public key itself.
However, it is in fact perfectly legitimate cryptographic terminology to refer to the pubkey hash as a public key itself.
This is because Bitcoin's cryptography can be considered to be a custom digital signature algorithm, where the public key consists of the hash of the ECC pubkey, the signature consists of the ECC pubkey concatenated with the ECC signature, and the verification algorithm involves checking the ECC pubkey in the signature against the ECC pubkey hash provided as a public key and then verifying the ECC signature against the ECC pubkey.
2. Technically, the median of the 11 previous blocks.
3. Internally, 2 and "CHARLIE" are both numbers, with the latter being in big-endian base 256 representation. Numbers can be at least 0 and at most 2256-1.
1. Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
2. Smart property: https://en.bitcoin.it/wiki/Smart_Property
3. Smart contracts: https://en.bitcoin.it/wiki/Contracts
4. B-money: http://www.weidai.com/bmoney.txt
5. Reusable proofs of work: http://www.finney.org/~hal/rpow/
6. Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html
7. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf
8. Namecoin: https://namecoin.org/
9. Zooko's triangle: http://en.wikipedia.org/wiki/Zooko's_triangle
10. Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit
11. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec
12. Decentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/
13. Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification
14. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree
15. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree
16. GHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
17. StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html
18. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
19. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
20. Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
21. Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/
name::
* McsEngl.DnEth-protocol'Plasma,
* McsEngl.Plasma.Ethereum-protocol,
addressWpg::
* http://plasma.io/,
name::
* McsEngl.DnEth-protocol'yellow-paper,
addressWpg::
* http://gavwood.com/Paper.pdf,
description::
In a nutshell whisper is a communication protocol for DApps to communicate with each other.
[https://github.com/ethereum/wiki/wiki/Whisper]
===
Whisper is a part of the Ethereum P2P protocol suite that allows for messaging between users via the same network that the blockchain runs on.
There are many uses, some of which are listed on the wiki
The protocol is seperate from the blockchain, so smart contracts do not have access.
Whisper has existed in a sort of alpha, working-prototype state for some time now. It can be enabled by using the -shh flag in geth, but nodes do not relay the messages by default, so chances are that messages won't get through unless you are directly connected to the recipient. API documentation can be found on github.
[http://ethereum.stackexchange.com/a/134]
name::
* McsEngl.DnEth-protocol'Whisper,
* McsEngl.Whisper--Ethereum-protocol,
description::
Nodes are COMPUTERS that run the-client-programs
- stores a full or light copy of the-blockchain
- interacts with the-blockchain.
[hmnSngo.2017-03-16]
name::
* McsEngl.DnEthereum'node!⇒DnEthereum-node,
* McsEngl.DnEth-node,
* McsEngl.Ethereum-node!⇒DnEthereum-node,
generic::
* blockchain-network-node,
addressWpg::
* https://www.ethernodes.org/network/1,
description::
Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
===
Node overview
Id 000c157e3fdc04c299fcf1c433c51e7d079d33c4c9175275299c834f1fef355f
791741ae23ca387018320038caa90fc5e243bec3992d9a6d789b771dfea42f0f
Host 94.242-61-32
Port 46897
Client id Parity/v1.5.4-beta-74b850e-20170223/x86_64-linux-gnu/rustc1.15.1
Client Parity
Client version v1.5.4-beta-74b850e-20170223
OS x86_64-linux-gnu
Capabilities [par/1 par/2 eth/62 eth/63]
Protocol version 63
Network id 1
Total difficulty 204795435708956
Best hash c8268e06bf48ff52c6ce9be4f2b3560b5a881133b55f4a1e5d44a401a67477ad
Genesis hash 41941023680923e0fe4d74a34bdac8141f2540e3ae90623718e47d66d1ca4a2d
Last seen Thu Mar 16 2017 13:54:29 GMT+0100 (CET)
Country Russian Federation
City
[https://www.ethernodes.org/node/000c157e3fdc04c299fcf1c433c51e7d079d33c4c9175275299c834f1fef355f791741ae23ca387018320038caa90fc5e243bec3992d9a6d789b771dfea42f0f]
description::
Thanks to Merkle trees, it is possible to build Ethereum nodes that run on all computers and laptops large and small, smart phones, and even internet of things devices such as those that will be produced by Slock.it.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
name::
* McsEngl.DnEth-node.aggregate,
{2017-03-16},
Total | 10789 (100%) |
United States | 3175 (29.43%) |
Germany | 942 (8.73%) |
United Kingdom | 595 (5.51%) |
Canada | 496 (4.60%) |
Russian Federation | 484 (4.49%) |
China | 479 (4.44%) |
Netherlands | 459 (4.25%) |
France | 344 (3.19%) |
Australia | 275 (2.55%) |
Switzerland | 200 (1.85%) |
{2017-02-03},
Total 6176 (100%)
United States 1826 (29.57%)
Germany 481 (7.79%)
Russian Federation 368 (5.96%)
United Kingdom 299 (4.84%)
China 286 (4.63%)
Canada 258 (4.18%)
Netherlands 256 (4.15%)
France 228 (3.69%)
Australia 125 (2.02%)
Switzerland 125 (2.02%)
[https://www.ethernodes.org/network/1]
description::
Full nodes on the Bitcoin blockchain store every transaction made going back to the zero block; full nodes on the Ethereum blockchain additionally store the static code (if any) associated with a given account and that code’s current state in storage.
[https://medium.com/@ConsenSys/ethereum-bitcoin-plus-everything-a506dc780106#.izxhgdxdt]
name::
* McsEngl.DnEthereum'full-node,
* McsEngl.DnEth-node.full,
description::
Miner. A node on the network that mines, i.e., works to process blocks on the blockchain. You can see a partial list of live Ethereum miners here: stats.ethdev.com.
[https://medium.com/@ConsenSys/a-101-noob-intro-to-programming-smart-contracts-on-ethereum-695d15c1dab4#.5x9da12dp]
===
These transaction fees are collected by the nodes that validate the network. These “miners” are nodes in the Ethereum network that receive, propogate, verify, and execute transactions. The miners then group the transactions – which include many updates to the “state” of accounts in the Ethereum blockchain – into what are called “blocks”, and miners then compete with one another for their block to be the next one to be added to the blockchain. Miners are rewarded with ether for each successful block they mine. This provides the economic incentive for people to dedicate hardware and electricity to the Ethereum network.
...
Just as in the Bitcoin network, miners are tasked with solving a complex mathematical problem in order to successfully “mine” a block. This is known as a “Proof of Work”. Any computational problem that requires orders of magnitude more resources to solve algorithmically than it takes to verify the solution is a good candidate for proof of work. In order to discourage centralisation due to the use of specialised hardware (e.g. ASICs), as has occurred in the Bitcoin network, Ethereum chose a memory-hard computational problem. If the problem requires memory as well as CPU, the ideal hardware is in fact the general computer. This makes Ethereum’s Proof of Work ASIC-resistant, allowing a more decentralized distribution of security than blockchains whose mining is dominated by specialized hardware, like Bitcoin.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.DnEth-node.miner,
* McsEngl.DnEth-miner-node,
description::
To mine Ethereum you need a GPU, 4+GB RAM, Etherum account and GPU miner.
The GPU must have at least 2GB memory.
Recomended AMD GPU driver 15.12.
[https://eth.nanopool.org/help]
description::
Mining is the process of dedicating effort (working) to bolster one series of transactions (a block) over any other potential competitor block.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEthereum'mining,
* McsEngl.Ethereum-mining,
* McsEngl.Ethereum-mng-(Ethereum-mining),
description::
The Ethereum network is kept running by computers all over the world.
In order to reward the computational costs of both processing the contracts and securing the network, there is a reward that is given to the computer that was able to create the latest block on the chain.
Every 12 seconds, on average, a new block is added to the blockchain with the latest transactions processed by the network and the computer that generated this block will be awarded 5 ether.
Due to the nature of the algorithm for block generation, this process (generating a proof of work) is guaranteed to be random and rewards are given in proportion to the computational power of each machine.
This process is usually called mining in the crypto-currency logo.
[https://ethereum.org/ether]
===
Mining ether = Securing the Network = Verifying Computation
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#introduction]
addressWpg::
* {2016.07} Amazon AWS Ethereum Cloud Mining Tutorial-12 Step Guide to Generating ETC! https://steemit.com/ethereum/@coininstant/amazon-aws-ethereum-cloud-mining-tutorial...etc,
description::
The Ethereum blockchain (or "ledger") is the decentralized, massively replicated database in which the current state of all accounts is stored.
The blockchain uses a database called a Patricia tree (or "trie") to store all accounts; this is essentially a specialized kind of Merkle tree that acts as a generic key/value store.
[https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial#basics-of-the-ethereum-blockchain]
===
the blockchain, where all the EVM state is represented.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
===
Blockchain technology is the technological basis of Bitcoin, first described by its mysterious author Satoshi Nakamoto in his white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”, published in 2008. While the use of blockchains for more general uses was already discussed in the original paper, it was not until a few years later that blockchain technology emerged as a generic term. A blockchain is a distributed computing architecture where every network node executes and records the same transactions, which are grouped into blocks. Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block. In this way, the blockchain’s “distributed database” is kept in consensus across the whole network. Individual user interactions with the ledger (transactions) are secured by strong cryptography. Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
name::
* McsEngl.blockchain.Ethereum!⇒DnEthereum-blockchain,
* McsEngl.blockchain-of-Ethereum!⇒DnEthereum-blockchain,
* McsEngl.DnEth-blockchain, {2019-03-30},
* McsEngl.Ethereum-blockchain!⇒DnEthereum-blockchain,
* McsEngl.Ethereum-chain!⇒DnEthereum-blockchain,
* McsEngl.Ethereum-distributed-database!⇒DnEthereum-blockchain,
* McsEngl.Ethereum-ledger!⇒DnEthereum-blockchain,
* McsEngl.DnEthereum'blockchain!⇒DnEthereum-blockchain,
description::
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
The blocks on the blockchain represent units of time, the blockchain itself is a temporal dimension and represents the entire of history of states at the discrete time points designated by the blocks on the chain.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#eoa-vs-contract-accounts]
name::
* McsEngl.DnEth-block, {2019-03-30},
* McsEngl.Ethereum-block!⇒DnEthereum-block,
* McsEngl.DnEthereum'block!⇒DnEthereum-block,
description::
4.4. The Block.
The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
The block header contains several pieces of information:
parentHash: The Keccak 256-bit hash of the parent block’s header, in its entirety; formally Hp.
ommersHash: The Keccak 256-bit hash of the ommers list portion of this block; formally Ho.
beneficiary: The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally Hc.
stateRoot: The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally Hr.
transactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with
each transaction in the transactions list portion of the block; formally Ht.
receiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally He.
logsBloom: The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally Hb.
difficulty: A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block’s difficulty level and the timestamp; formally Hd.
number: A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally Hi.
gasLimit: A scalar value equal to the current limit of gas expenditure per block; formally Hl.
gasUsed: A scalar value equal to the total gas used in transactions in this block; formally Hg.
timestamp: A scalar value equal to the reasonable output of Unix’s time() at this block’s inception; formally Hs.
extraData: An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally Hx.
mixHash: A 256-bit hash which proves combined with the nonce that a sufficient amount of computation has been carried out on this block; formally Hm.
nonce: A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block; formally Hn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block'header,
* McsEngl.DnEth-block'H-(Ethereu-block-header),
description::
parentHash: The Keccak 256-bit hash of the parent block’s header, in its entirety; formally Hp.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block'parentHash,
* McsEngl.DnEth-block'parent-hash,
* McsEngl.EhtblkHp,
description::
ommersHash: The Keccak 256-bit hash of the ommers list portion of this block; formally Ho.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block'ommersHash,
* McsEngl.DnEth-block'ommers-hash,
* McsEngl.EhtblkHo,
description::
beneficiary: The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally Hc.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
20-bytes, 40-hexs,
===
Miner bb7b8287f3f0a933474a79eae42cbca977791171
[https://live.ether.camp/block/59]
name::
* McsEngl.DnEth-block'beneficiary,
* McsEngl.DnEth-block'miner,
* McsEngl.EhtblkHc,
generic::
* eth--address,
description::
stateRoot: The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally Hr.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
transactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally Ht.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block'transactionsRoot,
* McsEngl.EhtblkHt,
description::
receiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally He.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block'receiptsRoot,
* McsEngl.EhtblkHe,
description::
logsBloom: The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally Hb.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
difficulty: A scalar value corresponding to the difficulty level of this block.
This can be calculated from the previous block’s difficulty level and the timestamp; formally Hd.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Difficulty 17561410778
[https://live.ether.camp/block/59]
name::
* McsEngl.DnEth-block'difficulty,
* McsEngl.EhtblkHd,
description::
number: A scalar value equal to the number of ancestor blocks.
The genesis block has a number of zero; formally Hi.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Block #3000059
Hash 55bf7cf28ef891df9683fe80de1f7a985d803f8f21755a7977e76916b6dd78a3
Prev Hash d232b55f0b77a22fbc40ceea7ab9b9ba592034b5c9a71e2dca57c2912054bd72
Next Hash
Transactions 0
Uncle Hash 55bf7cf28ef891df9683fe80de1f7a985d803f8f21755a7977e76916b6dd78a3
Nonce c09eea000f9a5886
State Root 0920e25b921c1b518ce5ccbbada31fcec225f118a364d9c271d0bb3c591fa229
Tx Trie Root 56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421
Timestamp a month ago [1484475724]
Gas Limit 4000881
Gas Used 0
Miner c0ea08a2d404d3172d2add29a45be56da40e2949
Difficulty 104754858920035
Extra Data www.bw.com [7777772e62772e636f6d]
Bloom Filter
00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00
[https://live.ether.camp/block/3000059]
name::
* McsEngl.DnEth-block'height,
* McsEngl.DnEth-block'number,
* McsEngl.EhtblkHi,
description::
4.2. Homestead. A significant block number for compatibility with the public network is the block marking the transition between the Frontier and Homestead phases of the platform, which we denote with the symbol NH, defined thus
(13) NH = 1,150,000
The protocol was upgraded at this block, so this symbol appears in some equations to account for the changes.
description::
gasLimit: A scalar value equal to the current limit of gas expenditure per block; formally Hl.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
gasUsed: A scalar value equal to the total gas used in transactions in this block; formally Hg.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
timestamp: A scalar value equal to the reasonable output of Unix’s time() at this block’s inception; formally Hs.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Timestamp 2 years ago [1438270327]
[https://live.ether.camp/block/59]
description::
extraData: An arbitrary byte array containing data relevant to this block.
This must be 32 bytes or fewer; formally Hx.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Extra Data Geth/LVIV/v1.0.0/linux/go1.4.2 [476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32]
[https://live.ether.camp/block/59]
description::
mixHash: A 256-bit hash which proves combined with the nonce that a sufficient amount of computation has been carried out on this block; formally Hm.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block'mixHash,
* McsEngl.DnEth-block'mix-hash,
* McsEngl.EhtblkHm,
description::
nonce: A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block; formally Hn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Nonce: a meaningless value in a block which can be adjusted in order to try to satisfy the proof of work condition
[https://github.com/ethereum/wiki/wiki/Glossary]
===
Nonce 4ce04218c05e8275
[https://live.ether.camp/block/59]
description::
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
...The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block'transaction-list,
* McsEngl.DnEth-block'T-(Ethereu-block-transaction-list),
description::
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
...The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block'ommer-list,
* McsEngl.DnEth-block'U-(Ethereu-block-ommer-list),
description::
Hash 4d9423080290a650eaf6db19c87c76dff83d1b4ab64aefe6e5c5aa2d1f4b6623
Prev Hash cd5b5c4cecd7f18a13fe974255badffd58e737dc67596d56bc01f063dd282e9e
Next Hash 3cd0324c7ba14ba7cf6e4b664dea0360681458d76bd25dfc0d2207ce4e9abed4
Transactions 0
Uncle Hash 4d9423080290a650eaf6db19c87c76dff83d1b4ab64aefe6e5c5aa2d1f4b6623
[https://live.ether.camp/block/59]
description::
Gas Limit 5000
Gas Used 0
[https://live.ether.camp/block/59]
description::
First, the basics. A Merkle tree, in the most general sense, is a way of hashing a large number of “chunks” of data together which relies on splitting the chunks into buckets, where each bucket contains only a few chunks, then taking the hash of each bucket and repeating the same process, continuing to do so until the total number of hashes remaining becomes only one: the root hash.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
name::
* McsEngl.DnEth-block'Merkle-tree,
* McsEngl.DnEth-block'Merkle-tree-hashing-algorithm,
* McsEngl.DnEthereum'Merkle-tree,
* McsEngl.Merkle-tree,
description::
A Merkle proof consists of a chunk, the root hash of the tree, and the “branch” consisting of all of the hashes going up along the path from the chunk to the root. Someone reading the proof can verify that the hashing, at least for that branch, is consistent going all the way up the tree, and therefore that the given chunk actually is at that position in the tree. The application is simple: suppose that there is a large database, and that the entire contents of the database are stored in a Merkle tree where the root of the Merkle tree is publicly known and trusted (eg. it was digitally signed by enough trusted parties, or there is a lot of proof of work on it). Then, a user who wants to do a key-value lookup on the database (eg. “tell me the object in position 85273”) can ask for a Merkle proof, and upon receiving the proof verify that it is correct, and therefore that the value received actually is at position 85273 in the database with that particular root. It allows a mechanism for authenticating a small amount of data, like a hash, to be extended to also authenticate large databases of potentially unbounded size.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
description::
The original application of Merkle proofs was in Bitcoin, as described and created by Satoshi Nakamoto in 2009. The Bitcoin blockchain uses Merkle proofs in order to store the transactions in every block:
The benefit that this provides is the concept that Satoshi described as “simplified payment verification”: instead of downloading every transaction and every block, a “light client” can only download the chain of block headers, 80-byte chunks of data for each block that contain only five things:
A hash of the previous header
A timestamp
A mining difficulty value
A proof of work nonce
A root hash for the Merkle tree containing the transactions for that block.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
description::
Every block header in Ethereum contains not just one Merkle tree, but three trees for three kinds of objects:
- Transactions
- Receipts (essentially, pieces of data showing the effect of each transaction)
- State
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
name::
* McsEngl.DnEth-block'time,
description::
The-time between block creation.
===
As dictated by the protocol, the difficulty dynamically adjusts in such a way that on average one block is produced by the entire network every 15 seconds. We say that the network produces a blockchain with a 15 second block time
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]
description::
The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state.
Aside from that, two other values, the block number and the difficulty, are also stored in the block.
[https://github.com/ethereum/wiki/wiki/White-Paper#blockchain-and-mining]
addressWpg::
* https://etherchain.org/blocks,
* https://etherchain.org/block/3270980,
description::
First, to initialize a new private blockchain, we will need what is called a Genesis block, which is going to be the first block in our blockchain.
This first block sets a few fundamental parameters for our blockchain, captured in a genesis.json file:
{
"nonce": "0x0000000000000042",
"mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"difficulty": "0x4000",
"alloc": {},
"coinbase": "0x0000000000000000000000000000000000000000",
"timestamp": "0x00",
"parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"extraData": "Custom Ethereum Genesis Block",
"gasLimit": "0xffffffff"
}
[http://hypernephelist.com/2016/05/30/deploying-a-private-Ethereum-blockchain.html]
===
The genesis block has a number of zero; formally Hi.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-block.first,
* McsEngl.DnEth-block.genesis,
* McsEngl.DnEthereum'genesis-block,
addressWpg::
* BlockH0 https://etherscan.io/block/0,
* http://ethdocs.org/en/latest/network/test-networks.html#the-genesis-file,
name::
* McsEngl.DnEthereum'best-block,
* McsEngl.DnEthereum'last-block,
* McsEngl.DnEth-block.last,
description::
Uncles are stale blocks i.e. with parents that are ancestors (max 6 blocks back) of the including block.
Valid uncles are rewarded in order to neutralise the effect of network lag on the dispersion of mining rewards, thereby increasing security (this is called the GHOST protocol).
Uncles included in a block formed by the successful PoW miner receive 7/8 of the static block reward (=4.375 ether).
A maximum of 2 uncles are allowed per block.
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]
name::
* McsEngl.DnEth-block.uncle,
* McsEngl.DnEthereum'uncle,
name::
* McsEngl.DnEth-blockchain'explorer,
* McsEngl.DnEthereum'explorer,
* McsEngl.Ethereum-explorer,
specific::
* https://ethplorer.io/,
* https://etherscan.io/,
* https://etherchain.org/,
* https://live.ether.camp/,
description::
Consensus is based on choosing the block with the highest total difficulty.
... Note that in the Ethereum Serenity milestone, this is likely going to be replaced by a (see proof of stake model ).
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]
===
a system such that we can reasonably expect that an agreement will be thus enforced autonomously,
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
The basic block validation algorithm in Ethereum is as follows:
1. Check if the previous block referenced exists and is valid.
2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
4. Check that the proof of work on the block is valid.
5. Let S[0] be the state at the end of the previous block.
6. Let TX be the block's transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any application returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.
7. Let S_FINAL be S[n], but adding the block reward paid to the miner.
8. Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.
[https://github.com/ethereum/wiki/wiki/White-Paper#blockchain-and-mining]
name::
* McsEngl.DnEth-blockchain'block-validation-algorithm,
* McsEngl.DnEth-blockchain'consensus-algorithm,
* McsEngl.Ethereum-consensus-algorithm,
* McsEngl.DnEthereum'consensus-algorithm,
generic::
* bcnnet-consensus-algorithm,
description::
Fortunately, the next version of the Ethereum testnet, Kovan, has been announced by the Parity community. Although this new testnet is incompatible with geth nodes, it uses the PoA (Proof of Authority) consensus, which should improve its resilience to spam attacks. ChronoBank has also made an application to become a trusted validator for the new testnet.
PoA is a replacement for PoW and can be used for both public and private chain setups. There is no mining involved to secure the network with PoA. Instead, it relies on trusted ‘Validators’ to ensure that legitimate transactions are added to blocks, and are processed and executed by the EVM faithfully.
Because mining does not occur on our proposed public testnet, malicious actors are prevented from acquiring testnet Ether -- solving the spam attack that Ropsten currently faces. There is no difference in the way that contracts are executed on PoA and PoW chains, so developers can test their contracts and user interfaces before deploying to the mainnet in a more reliable and convenient environment.
[https://blog.chronobank.io/chronobank-dev-update-7-49b387396b2c#.odbp6hdr9]
name::
* McsEngl.DnEth-blockchain'proof-of-authority,
* McsEngl.DnEthereum'proof-of-authority,
* McsEngl.proof-of-authority-of--Ethereum-net,
{2016-03-16}:
Top News - Bitcoin Retweeted
Tuur Demeester ?@TuurDemeester 5h5 hours ago
8 months in, #Ethereum blockchain size is 10GB — some estimate growth rate of up to 1TB/yr. Thoughts on network scalability vs. security?
[https://twitter.com/TuurDemeester/status/710101175610286081]
How will Ethereum deal with ever increasing blockchain size?
There are many discussions around blockchain scalability. This questioned has been partially answered on this Ethereum StackExchange post and this blog post from Vitalik Buterin.
[https://ethereum-homestead.readthedocs.org/en/latest/frequently-asked-questions/frequently-asked-questions.html#how-will-ethereum-deal-with-ever-increasing-blockchain-size]
description::
Transactions fundamentally change the state of the network.
A transaction can be
- as simple as sending Ether to another account, or
- as complicated as executing a contract function or
- adding a new contract to the network.
The defining characteristic of a transaction is that it writes (or changes) data.
Transactions cost Ether to run, known as "gas", and transactions take time to process.
When you execute a contract's function via a transaction, you cannot receive that function's return value because the transaction isn't processed immediately.
In general, functions meant to be executed via a transaction will not return a value; they will return a transaction id instead.
So in summary, transactions:
- Cost gas (Ether)
- Change the state of the network
- Aren't processed immediately
- Won't expose a return value (only a transaction id).
[http://truffleframework.com/docs/getting_started/contracts#transactions]
name::
* McsEngl.DnEth-blockchain'message!⇒DnEthereum-tx,
* McsEngl.DnEth-blockchain'transaction!⇒DnEthereum-tx,
* McsEngl.DnEthereum'message!⇒DnEthereum-tx,
* McsEngl.DnEthereum'transaction!⇒DnEthereum-tx,
* McsEngl.Ethereum-transaction!⇒DnEthereum-tx,
* McsEngl.DnEth-tx, {2019-03-30},
generic::
* blockchain-transaction,
description::
The term “transaction” is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account.
images/chapter1/1-4.png
Transactions contain:
- recipient: The account the transaction is intended for.
- sender: A signature representing the originator of the transaction.
- amount: The amount of ETH to transfer from the sender to the recipient.
- data: An optional field to pass data to the smart contract.
- startgas: A value representing the maximum number of computational steps the transaction execution is allowed to take.
- gasprice: A value representing the fee the sender pays per computational step.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below). It can include binary data (its payload) and Ether.
If the target account contains code, that code is executed and the payload is provided as input data.
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract. As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”). The payload of such a contract creation transaction is taken to be EVM bytecode and executed. The output of this execution is permanently stored as the code of the contract. This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
===
A blockchain is a globally shared, transactional database.
This means that everyone can read entries in the database just by participating in the network.
If you want to change something in the database, you have to create a so-called transaction which has to be accepted by all others.
The word transaction implies that the change you want to make (assume you want to change two values at the same time) is either not done at all or completely applied.
Furthermore, while your transaction is applied to the database, no other transaction can alter it.
As an example, imagine a table that lists the balances of all accounts in an electronic currency. If a transfer from one account to another is requested, the transactional nature of the database ensures that if the amount is subtracted from one account, it is always added to the other account. If due to whatever reason, adding the amount to the target account is not possible, the source account is also not modified.
Furthermore, a transaction is always cryptographically signed by the sender (creator). This makes it straightforward to guard access to specific modifications of the database. In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#transactions]
===
The term “transaction” is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account to another account on the blockchain.
Transactions contain:
the recipient of the message,
a signature identifying the sender and proving their intention to send the message to the blockchain to the reciptient,
VALUE field - The amount of wei to transfer from the sender to the recipient,
an optional data field, which can contain the message sent to a contract,
a STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take,
a GASPRICE value, representing the fee the sender is willing to pay for gas. One unit of gas corresponds to the execution of one atomic instrucion, i.e., a computational step.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#what-is-a-transaction]
===
The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
description::
nonce: A scalar value equal to the number of transactions sent by the sender; formally Tn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
gasPrice: A scalar value equal to the number of Wei to be paid per unit of gas for all computation costs incurred as a result of the execution of this transaction; formally Tp.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
gasLimit:
A scalar value equal to the maximum amount of gas that should be used in executing this transaction.
This is paid up-front, before any computation is done and may not be increased later; formally Tg.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
to: The 160-bit address of the message call’s recipient or, for a contract creation transaction, Ø, used here to denote the only member of B0 ; formally Tt.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
If the destination of the transaction is another EOA, then the transaction may transfer some ether but otherwise does nothing.
However, if the destination is a contract, then the contract in turn activates, and automatically runs its code.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#account-interactions-example-betting-contract]
===
If the target account contains code, that code is executed and the payload is provided as input data.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.DnEth-tx'destination,
* McsEngl.DnEth-tx'recipient,
* McsEngl.DnEth-tx'recipient-account,
* McsEngl.DnEth-tx'target-account,
* McsEngl.DnEth-tx'to,
* McsEngl.DnEth-tx'Tt,
description::
value: A scalar value equal to the number of Wei to be transferred to the message call’s recipient or, in the case of contract creation, as an endowment to the newly created account; formally Tv.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below).
It can include binary data (its payload) and Ether.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.DnEth-tx'ether,
* McsEngl.DnEth-tx'value,
* McsEngl.DnEth-tx'Tv,
description::
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEth-tx'v-(value),
* McsEngl.DnEth-tx'Tw-(value),
description::
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
TxHash: 0xbe5070a938fa049d360e881fbbb1f3e4e0f71344f07921a9e167b5f49fe5f28b (64 hexsymbols)
name::
* McsEngl.DnEth-tx'age,
* McsEngl.DnEth-tx'timestamp,
description::
Furthermore, a transaction is always cryptographically signed by the sender (creator).
This makes it straightforward to guard access to specific modifications of the database.
In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html]
===
An Ethereum transaction contract code can trigger data reads and writes, do expensive computations like using cryptographic primitives, make calls (send messages) to other contracts, etc. Each of these operations have a cost measured in gas, and each gas unit consumed by a transaction must be paid for in Ether, based on a gas/Ether price which changes dynamically.
This price is deducted from the Ethereum account sending the transaction.
Transactions also have a gas limit parameter that is an upper bound on how much gas the transaction can consume, and is used as a safe-guard against programming errors that could deplete an account’s funds.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
description::
The total ether cost of a transaction is based on 2 factors:
gasUsed is the total gas that is consumed by the transaction
gasPrice price (in ether) of one unit of gas specified in the transaction
Total cost = gasUsed * gasPrice
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#estimating-transaction-costs]
===
Fees applied to transaction go to support the networks that run the coin/token - so, for instance, every standard (non-contract) ETH transaction currently applies a fee of .000441 ETH.
This fee does not go to us; it goes to reward miners (thereby ensuring that the transaction is logged into the blockchain in a timely fashion) and support the Ethereum network itself.
Note that transactions that interact with a contract address will be more costly.
[https://decentral.zendesk.com/hc/en-us/articles/225024248-What-are-transaction-fees-and-what-fees-does-Jaxx-apply-]
===
Like in Bitcoin, users must pay small transaction fees to the network. This protects the Ethereum blockchain from frivolous or malicious computational tasks, like DDoS attacks or infinite loops. The sender of a transaction must pay for each step of the “program” they activated, including computation and memory storage. These fees are paid in amounts of Ethereum’s native value-token, ether.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.DnEth-tx'cost,
* McsEngl.DnEth-tx'fee,
description::
Transactions also have a gas limit parameter that is an upper bound on how much gas the transaction can consume, and is used as a safe-guard against programming errors that could deplete an account’s funds.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
description::
Next we specify an event, which is how in Solidity we use the logging facility of the Ethereum Virtual Machine.
When called, events cause the arguments to be stored in the transaction’s log.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.DnEth-tx'log,
example::
* https://etherscan.io/tx/0x3238a040c9ff9c06067401b366b804ad4f3824186336eae4f1a8f43c8c981b78#eventlog,
name::
* McsEngl.DnEth-tx'security,
addressWpg::
* http://tap.dappbench.com/
* https://github.com/dob/tap,
addressWpg::
* https://etherscan.io/txs,
* https://etherchain.org/txs,
* https://etherchain.org/tx/ 0xfaee6da035c0a943002d2f4f65b7714d92f11a6465ca69595719f2707f134557,
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api#get-transaction-info,
description::
ether transfer or trigger contract code
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#externally-owned-accounts-eoas]
name::
* McsEngl.DnEth-tx.specific,
specific::
Broadly speaking there are three types transactions supported on Ethereum:
- Transfer of Ether from one party to another
- Creation of a smart contract
- Transacting with a smart contract
[https://docs.web3j.io/transactions.html]
===
There are two types of transactions: a sending transaction and a contract creating transaction.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
===
There are two types of transactions:
those which result in message calls and
those which result in the creation of new accounts with associated code (known informally as ‘contract creation’).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
There are two types of transactions:
those which result in message calls and
those which result in the creation of new accounts with associated code (known informally as ‘contract creation’).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.DnEthereum'message-call-transaction,
* McsEngl.DnEth-tx.message-call,
* McsEngl.DnEth-tx.Mc,
description::
In contrast, a message call transaction contains:
data: An unlimited size byte array specifying the input data of the message call, formally Td.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below).
It can include binary data (its payload) and Ether.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.DnEthereum'payload-of-tx,
* McsEngl.DnEth-tx'data,
* McsEngl.DnEth-tx'binary-data,
* McsEngl.DnEth-tx'payload,
* McsEngl.DnEth-tx'Td,
description::
The simplest transactions are ether transfer transactions.
[https://ethereum.gitbooks.io/frontier-guide/content/account_types.html]
===
A sending transaction is a standard transaction, containing a receiving address, an ether amount, a data bytearray and some other parameters, and a signature from the private key associated with the sender account.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
===
All code execution in the Ethreum Virtual Machine, or EVM must be triggered by a private key based account. This is done by sending a transaction, which may do something simple like transfering ether, or it may do something more complex like calling a function on a contract account.
[http://docs.ethereum-alarm-clock.com/en/latest/introduction.html]
name::
* McsEngl.DnEth-tx.sending,
* McsEngl.DnEth-tx.standard,
description::
your transactions are also of two types:
- those sent to normal accounts are ether transfers,
- while the rest are communication with smart contracts.
[https://www.ethereum.org/ether]
name::
* McsEngl.DnEth-tx.interacting-with-contract,
* McsEngl.DnEth-tx.transacting-with-contract,
* McsEngl.DnEth-tx.contract-calling,
* McsEngl.DnEth-tx.contract-invocating,
description::
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”).
The payload of such a contract creation transaction is taken to be EVM bytecode and executed.
The output of this execution is permanently stored as the code of the contract.
This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
===
A contract creating transaction looks like a standard transaction, except the receiving address is blank. When a contract creating transaction makes its way into the blockchain, the data bytearray in the transaction is interpreted as EVM code, and the value returned by that EVM execution is taken to be the code of the new contract; hence, you can have a transaction do certain things during initialization. The address of the new contract is deterministically calculated based on the sending address and the number of times that the sending account has made a transaction before (this value, called the account nonce, is also kept for unrelated security reasons). Thus, the full code that you need to put onto the blockchain to produce the above name registry is as follows:
PUSH1 16 DUP PUSH1 12 PUSH1 0 CODECOPY PUSH1 0 RETURN STOP PUSH1 0 CALLDATALOAD SLOAD NOT PUSH1 9 JUMPI STOP PUSH1 32 CALLDATALOAD PUSH1 0 CALLDATALOAD SSTORE
The key opcodes are CODECOPY, copying the 16 bytes of code starting from byte 12 into memory starting at index 0, and RETURN, returning memory bytes 0-16, ie. code byes 12-28 (feel free to "run" the execution manually on paper to verify that those parts of the code and memory actually get copied and returned). Code bytes 12-28 are, of course, the actual code as we saw above.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
name::
* McsEngl.DnEth-tx.contract-acount-creation,
* McsEngl.DnEth-tx.contract-creating-transaction,
* McsEngl.DnEth-tx.Cac,
description::
Additionally, a contract creation transaction contains:
init: An unlimited size byte array specifying the EVM-code for the account initialisation procedure, formally Ti.
init is an EVM-code fragment; it returns the body, a second fragment of code that executes each time the account receives a message call (either through a transaction or due to the internal execution of code). init is executed only once at account creation and gets discarded immediately thereafter.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
description::
GENESIS_2b241f037337eb4acc61849bd272ac133f7cdf4b block:0 age:580 days 32 mins ago (2015-07-30-03.26.13pm) from:GENESIS IN to:0x2b241f037337eb4acc61849bd272ac133f7cdf4b 378,000 Ether 0 Ether
[https://etherscan.io/address/0x2b241f037337eb4acc61849bd272ac133f7cdf4b]
name::
* McsEngl.DnEth-blockchain.specific,
specific::
Public blockchains: a public blockchain is a blockchain that anyone in the world can read, anyone in the world can send transactions to and expect to see them included if they are valid, and anyone in the world can participate in the consensus process – the process for determining what blocks get added to the chain and what the current state is. As a substitute for centralized or quasi-centralized trust, public blockchains are secured by cryptoeconomics – the combination of economic incentives and cryptographic verification using mechanisms such as proof of work or proof of stake, following a general principle that the degree to which someone can have an influence in the consensus process is proportional to the quantity of economic resources that they can bring to bear. These blockchains are generally considered to be “fully decentralized”.
Consortium blockchains: a consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of nodes; for example, one might imagine a consortium of 15 financial institutions, each of which operates a node and of which 10 must sign every block in order for the block to be valid. The right to read the blockchain may be public, or restricted to the participants, and there are also hybrid routes such as the root hashes of the blocks being public together with an API that allows members of the public to make a limited number of queries and get back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered “partially decentralized”.
Private blockchains: a fully private blockchain is a blockchain where write permissions are kept centralized to one organization. Read permissions may be public or restricted to an arbitrary extent. Likely applications include database management, auditing, etc internal to a single company, and so public readability may not be necessary in many cases at all, though in other cases public auditability is desired.
[https://ethereum-homestead.readthedocs.org/en/latest/network/connecting-to-the-network.html#public-private-and-consortium-blockchains]
description::
"Whereas the Bitcoin blockchain was purely a list of transactions, Ethereum’s basic unit is the account.
The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts."
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
===
"There are two types of accounts on the Ethereum blockchain.
- Accounts that have a private key.
- Contracts (which do not have a private key)
Private key accounts are the accounts that humans operate, where as contract accounts are deployed pieces of code capable of executing some computer program."
[http://docs.ethereum-alarm-clock.com/en/latest/introduction.html]
===
"There are two kinds of accounts in Ethereum which share the same address space: External accounts that are controlled by public-private key pairs (i.e. humans) and contract accounts which are controlled by the code stored together with the account.
The address of an external account is determined from the public key while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).
Apart from the fact whether an account stores code or not, the EVM treats the two types equally, though.
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 Ether (in “Wei” to be exact) which can be modified by sending transactions that include Ether."
[https://solidity.readthedocs.org/en/latest/introduction-to-smart-contracts.html#accounts]
===
"Accounts are a central part of the Ethereum network and are an essential part of any transaction or contract. In Ethereum, there are two types of accounts: Externally Owned accounts (EOA) and Contract accounts."
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/glossary.html]
name::
* McsEngl.DnEth-account, {2019-03-27},
* McsEngl.Ethereum-account!⇒DnEthereum-account,
* McsEngl.DnEthereum'account!⇒DnEthereum-account,
description::
Every account is defined by a pair of keys, a private key and public key.
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
name::
* McsEngl.DnEth-account'key,
* McsEngl.DnEth-account'keypair,
* McsEngl.Ethereum-keypair,
description::
Every account is defined by a pair of keys, a private key and public key.
Accounts are indexed by their address which is derived from the public key by taking the last 20 bytes.
Every private key/address pair is encoded in a keyfile.
Keyfiles are JSON text files which you can open and view in any text editor.
The critical component of the keyfile, your account’s private key, is always encrypted, and it is encrypted with the password you enter when you create the account.
Keyfiles are found in the keystore subdirectory of your Ethereum node’s data directory.
Make sure you backup your keyfiles regularly!
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
description::
The default data directory locations are platform specific:
Windows: C:\Users\username\%appdata%\Roaming\Ethereum\keystore
Linux: ~/.ethereum/keystore
Mac: ~/Library/Ethereum/keystore
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
name::
* McsEngl.DnEth-account'keystore,
* McsEngl.Ethereum-keystore,
description::
0x0998c9a0c7224Ec4ED782A4Ecfef53A0e25fA9FC
0x573383aFc6cd5eEc4114C8edA98D1915FE15425C
===
"address
An Ethereum address represents an account. For EOA, the address is derived as the last 20 bytes of the public key controlling the account, e.g., cd2a3d9f938e13cd947ec05abc7fe734df8dd826.
This is a hexadecimal format (base 16 notation), which is often indicated explicitly by appending 0x to the address.
Web3.js and console functions accept addresses with or without this prefix but for transparency we encourage their use.
Since each byte of the address is represented by 2 hex characters, a prefixed address is 42 characters long.
Several apps and APIs are also meant to implement the new checksum-enabled address scheme introduced in the Mist Ethereum wallet as of version 0.5.0."
[https://ethereum-homestead.readthedocs.io/en/latest/glossary.html]
===
Every account is defined by a pair of keys, a private key and public key.
Accounts are indexed by their address which is derived from the public key by taking the last 20 bytes.
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
===
There are two kinds of accounts in Ethereum which share the same address space: External accounts that are controlled by public-private key pairs (i.e. humans) and contract accounts which are controlled by the code stored together with the account.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
===
name::
* McsEngl.DnEth-account'address,
* McsEngl.DnEth-address,
* McsEngl.Ethereum-address,
* McsEngl.DnEthereum'address,
description::
ATTENTION: Ethereum addresses don't have built-in checks on them yet. That means that if you mistype an address, your ether will be lost forever, without a secondary confirmation window. If you are moving a significant amount, start with smaller quantities that you can afford to lose, until you feel comfortable enough.
[https://www.ethereum.org/ether]
addressWpg::
* https://etherscan.io/address/0x53d284357ec70ce289d6d64134dfac8e511c8a3d,
* https://etherchain.org/account/0x007abbe8057433641acb791d966d33a12cf82d01,
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api#get-address-info,
description::
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.DnEth-address.zero,
* McsEngl.zero-address.Ethereum,
description::
Furthermore, every account has a balance in Ether (in “Wei” to be exact) which can be modified by sending transactions that include Ether.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
name::
* McsEngl.DnEth-account'balance,
* McsEngl.DnEth-account'Ether,
description::
Account nonce: a transaction counter in each account.
This prevents replay attacks where a transaction sending eg. 20 coins from A to B can be replayed by B over and over to continually drain A's balance.
[https://github.com/ethereum/wiki/wiki/Glossary]
name::
* McsEngl.DnEth-account'nonce,
* McsEngl.Ethereum-nonce-of-account,
description::
All accounts in ethereum are stored in a merkle radix tree.
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#contracts]
name::
* McsEngl.DnEth-account'store-of-data,
structure::
Ethereum accounts contain the following four fields:
- nonce: A counter which ensures a transaction may only be processed exactly once.
- balance: The current ETH balance of the account.
- code: The account’s contract code (if there is any).
- storage: The account’s storage (if there is any).
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
description::
The-transactions of a specific account.
Transaction Information
TxHash: 0x01406301bd25b21c16d6a2a47dbbc64f1cb9231f5b26c3a084ad2161c34a2a69
Block Height: 2757949 (526943 block confirmations)
TimeStamp : 87 days 2 hrs ago (Dec-06-2016 11:52:02 AM +UTC)
From: 0x53b148c3650d248ea740439e268d07dcd27ddac4
To: 0xfbddda2a82ccab13b60b4488e87362959578ca15
Value: 4 Ether ($77.80)
Gas: 300000
Gas Price: 0.00000004 Ether
Gas Used By Transaction: 21000
Actual Tx Cost/Fee: 0.00084 Ether ($0.02)
Cumulative Gas Used: 21000
Nonce: 1
Input Data:
Transaction Information
TxHash: 0x7fdc591cd1a4e97e0623cded49cda5222714b7e321ecdae137a79fd38f618a28
Block Height: 2813266 (471621 block confirmations)
TimeStamp : 78 days 7 mins ago (Dec-15-2016 02:28:28 PM +UTC)
From: 0xfbddda2a82ccab13b60b4488e87362959578ca15
To: 0xb60508e4617c98131a36bbd46fb189e0efc8932c
Value: 3.5 Ether ($68.08)
Gas: 21000
Gas Price: 0.00000002 Ether
Gas Used By Transaction: 21000
Actual Tx Cost/Fee: 0.00042 Ether ($0.0082)
Cumulative Gas Used: 42000
Nonce: 0
Input Data:
addressWpg::
* https://etherscan.io/accounts, A total of 1095602 accounts found (89,342,484.874 Ether) {2017-03-01},
description::
Whereas the Bitcoin blockchain was purely a list of transactions, Ethereum’s basic unit is the account.
The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
description::
In general, there are two types of accounts:
- externally owned accounts, controlled by private keys, and
- contract accounts, controlled by their contract code.
[https://github.com/ethereum/wiki/wiki/White-Paper#ethereum-accounts]
name::
* McsEngl.DnEth-account.specific,
specific::
This distinction might be eliminated in Serenity.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#eoa-vs-contract-accounts]
description::
"There are two kinds of accounts in Ethereum which share the same address space: External accounts that are controlled by public-private key pairs (i.e. humans) and contract accounts which are controlled by the code stored together with the account.
The address of an external account is determined from the public key while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).
Apart from the fact whether an account stores code or not, the EVM treats the two types equally, though.
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 Ether (in “Wei” to be exact) which can be modified by sending transactions that include Ether."
[https://solidity.readthedocs.org/en/latest/introduction-to-smart-contracts.html#accounts]
===
"We need to use permissions like this because each contract is a separate account that can be called by any account in the system.
Even when we include a contract in the source file of another contract as with HelloFactory, each new contract will still be created as a separate, new contract account that is unrelated to its factory except for any references we might add ourselves."
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
Common info
Contract name ProofOfIdleness
Address 019d7e5ae8d2ba9a292244311dc7355058ab1b08
Involved in 76 Transactions
Balance ETHER 15.84
Nonce 1
[https://live.ether.camp/account/019d7e5ae8d2ba9a292244311dc7355058ab1b08]
name::
* McsEngl.DnEth-account.contract!⇒DnEthereum-contract-account,
* McsEngl.DcontractEth-account, {2019-03-28},
* McsEngl.DnEthereum'contract-account!⇒DnEthereum-contract-account,
description::
40 hexsymbols,
0xbf35faa9c265baf50c9cff8c389c363b05753275
===
The address of an external account is determined from the public key
while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
Tx: 0x581f761cb4c70cb329475f0a770df3fbe9a9d7fa760a5875d2b4d0c92b058aec
Block: 3175356
Time: 2017-02-13 11:47:42 (16 days ago)
From: 0xbF35fAA9C265bAf50C9CFF8c389C363B05753275
To: 0x7bE7Fad439128cca6738F8A6813519aF4248365C
Amount: 90 Ether
Account Nonce: 16
Gas Price: 2e-8 Ether
Gas Limit: 77,953
Total Gas Used: 0
Tx Price: 0 Ether
Invoked by: 0xdc81eff532b6423928f598f650658ce284443b72436dbe3870a239b89c1ce4af
Payload:
0x (ASCII: )
description::
For most users, the basic difference between these is that human users control EOAs - because they can control the private keys which give control over an EOA.
Contract accounts, on the other hand, are governed by their internal code.
If they are “controlled” by a human user, it is because they are programmed to be controlled by an EOA with a certain address, which is in turn controlled by whoever holds the private keys that control that EOA.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
===
Regardless of whether or not the account stores code, the two types are treated equally by the EVM.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
name::
* McsEngl.DcontractEth-account'relation-to-normal-account,
* McsEngl.DnEth-normal-account'relation-to-contract-account,
addressWpg::
* https://etherscan.io/accounts/c, A total of 251,357 contracts found (10,742,904.733 Ether) {2017-03-01},
* https://etherchain.org/contracts,
* https://etherchain.org/account/0xbf35faa9c265baf50c9cff8c389c363b05753275,
description::
An externally controlled account
- has an ether balance,
- can send transactions (ether transfer or trigger contract code),
- is controlled by private keys,
- has no associated code.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#externally-owned-accounts-eoas]
===
"Private key accounts are the accounts that humans operate, where as contract accounts are deployed pieces of code capable of executing some computer program."
[http://docs.ethereum-alarm-clock.com/en/latest/introduction.html]
===
Address 532219eff8c413621a7c68974dfec33d86350631
Involved in 38 Transactions
Balance ETHER 14,856.80 ...
Nonce 17
[https://live.ether.camp/account/532219eff8c413621a7c68974dfec33d86350631]
name::
* McsEngl.DnEth-account.contractNo!⇒DnEthereum-normal-account,
* McsEngl.DnEth-account.normal!⇒DnEthereum-normal-account,
* McsEngl.DnEth-EOA!⇒DnEthereum-normal-account,
* McsEngl.DnEth-exteranlly-owned-account!⇒DnEthereum-normal-account,
* McsEngl.DnEth-non-contract-account!⇒DnEthereum-normal-account,
* McsEngl.DnEth-normal-account, {2019-03-28},
* McsEngl.DnEth-private-key-account!⇒DnEthereum-normal-account,
description::
40 hexsymbos
0xb794F5eA0ba39494cE839613fffBA74279579268
===
The address of an external account is determined from the public key
while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
description::
Accounts are the most basic way to store Ether. They are simple public/private keypairs, which you use to sign transactions. You don't need to do anything to "register" an account with the network, just generate one and send some ether to it.
Wallets are smart-contracts that allow for advanced features such as transaction logging, multisig, withdrawal limits, and more. In order to create a wallet, you need to deploy the contract to the blockchain, which requires ether. You need to make sure you keep track not only of the keys required to access the wallet, but also the wallet address. Unlike with accounts, wallet addresses are not very easily derivable from the private key (although it's not the end of the world if you lose the wallet address, you can use a block explorer to find what contracts you've created recently). Technically you can recover the address from just the account that created it and the nonce of the transaction, but that's a hassle.
tl;dr: Start with an account, get some Ether, then create a wallet and store your ETH there
[http://ethereum.stackexchange.com/a/213]
addressWpg::
* https://etherscan.io/accounts/a, A total of 844266 addresses found (77,579,354.315 Ether) {2017-03-01},
* https://etherchain.org/accounts,
* https://etherchain.org/account/0xb794f5ea0ba39494ce839613fffba74279579268,
creating an account
$ geth account new
Your new account is locked with a password. Please give a password. Do not forget this password.
Passphrase:
Repeat Passphrase:
Address: {168bc315a2ee09042d83d7c5811b533620531f67}
[https://github.com/ethereum/go-ethereum/wiki/Managing-Your-Accounts#creating-an-account]
description::
In order to mine you need a fully synced Ethereum client that is enabled for mining and at least one ethereum account.
This account is used to send the mining rewards to and is often referred to as coinbase or etherbase.
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#the-algorithm]
name::
* McsEngl.DnEthereum'coinbase,
* McsEngl.DnEthereum'etherbase,
* McsEngl.DnEth-normal-account.coinbase,
* McsEngl.DnEth-normal-account.etherbase,
description::
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
description::
An empty account is an account that has zero balance, nonce and code.
Empty accounts are functionally equivalent to nonexistent accounts with the exception of a few gas calculations, and empty accounts can easily be turned into nonempty accounts by simply sending any amount of ether to them. Theoretically, if miners accept transactions with zero fees, even sending a transaction from an empty or nonexistent account is possible. The only practical difference is that empty accounts need to be stored in the Ethereum state tree, whereas nonexistent accounts do not.
[https://www.ethnews.com/vitalik-buterin-on-empty-accounts-and-the-ethereum-state]
description::
The-ethereum-network has the-ETH as consensus-exval-unit but it is relative easy to create non-consensus-exval-units.
name::
* McsEngl.asset-of-Ethereum,
* McsEngl.Ethereum-exchange-value-unit,
* McsEngl.Ethereum-evu-(Ethereum-exhange-value-unit),
* McsEngl.DnEthereum'asset,
* McsEngl.DnEthereum'exchange-value-unit,
* McsEngl.Ethereum-token,
specific::
* Ether,
* consensousNo-evu,
description::
· Ether is the-appending-Dasset of the-Deth-net.
===
Ether is the name of the currency used within Ethereum.
It is used to pay for computation within the EVM.
This is done indirectly by purchasing gas for ether as explained in gas.
[http://ethdocs.org/en/latest/ether.html?highlight=wei#what-is-ether]
name::
* McsEngl.DnEthereum'ETH!⇒DvETH,
* McsEngl.DnEthereum'consensus-token!⇒DvETH,
* McsEngl.DnEthereum'Ether-token!⇒DvETH,
* McsEngl.DevuETH!⇒DvETH, {2019-04-14},
* McsEngl.DvETH, {2019-06-03},
* McsEngl.ETH!⇒DvETH,
* McsEngl.ETH-(Ether-token)!⇒DvETH,
* McsEngl.ETH-evuC-(Ether-exchange-value-unit.consensus)!⇒DvETH, {2017-05-17},
* McsEngl.Ether-(ETH)!⇒DvETH,
* McsEngl.EvuETH!⇒DvETH, {2019-03-11},
* McsEngl.mnyEther!⇒DvETH,
* McsEngl.mnyEthereum!⇒DvETH,
* McsEngl.Ethereum-mny!⇒DvETH,
* đETH, {2018-01-17},
* Đ-Eth-cevt, {2017-04-15},
generic::
* Consensous-exchange-value-unit,
description::
THE CRYPTO-FUEL FOR THE ETHEREUM NETWORK
[https://www.ethereum.org/ether]
==
Ethereum ETH
Ethereum or Ether is a cryptocurrency designed to pay for the computational purposes of the Ethereum network. The name of the coin comes from the name of the platform intended to allow a network of peers to administer their own stateful user-created smart contracts in the absence of central authority.
[https://changelly.com/supported-currencies]
===
Ether is a necessary element -- a fuel -- for operating the distributed application platform Ethereum. It is a form of payment made by the clients of the platform to the machines executing the requested operations. To put it another way, ether is the incentive ensuring that developers write quality applications (wasteful code costs more), and that the network remains healthy (people are compensated for their contributed resources).
[https://ethereum.org/ether]
===
The currency unit of Ethereum is the Ether, used to pay for computational services on the network.
In order to finance development, Ethereum distributed the initial allocation of Ethers via a 42-day public sale, netting 31,591 bitcoins,[12] worth $18,439,086 at that time, in exchange for about 60,102,216 Ethers.
Ether is divided into smaller units of currency called finney, szabo, shannon, babbage, lovelace, and wei. Each larger unit is equal to 1000 of the next lower unit.[13] In practice, however, the developers encourage the use of ether and wei. Wei is the base unit of implementation and can not be further divided.
[https://en.wikipedia.org/wiki/Ethereum#Ether]
description::
Ethers have a natural unit with 18 decimal places.
1.23 ether is represented as 1,230,000,000,000,000,000 or 1.23e18 or 123e16 natural units.
[https://github.com/bokkypoobah/TokenTrader/wiki/Frequently-Asked-Questions#what-are-natural-units]
name::
* McsEngl.Ether-exchange-rate,
* McsEngl.DvETH'exchange-rate,
addressWpg::
* https://www.cryptonator.com/rates,
* http://ethereumprice.org/
* https://coinmarketcap.com/currencies/ethereum/
{2017-01-28}:
Ethereum (ETH)
From To Exchange Rate 24h Volume Change
ETH BTC 0.01146077 437895
ETH LTC 2.74647 139
ETH GBP 8.30021 57
ETH EUR 9.87598722 21747
ETH USD 10.502807 38919
ETH CAD 14.01432 41
ETH CNY 72.8 85
ETH RUR 613.11349041 586
ETH JPY 1267.761 37
ETH DOGE 50000.00000001 2
[https://www.cryptonator.com/rates#ETH]
{2016-03-28}:
Thus, the key resistance lines, which right now determine further development, are $10.9 and $11.4.
[http://cointelegraph.com/news/ethereum-eth-price-trends-3282016]
{2016-02-12}:
Launched in July 2015, the Ethereum coin includes a programmable smart contract platform and now ranks the second most expensive cryptocurrency after Bitcoin.
[http://cointelegraph.com/news/eight-months-since-release-ethereum-is-second-only-to-bitcoin]
description::
How are ethers created?
The total supply of ether and its rate of issuance was decided by the donations gathered on the 2014 presale. The results were roughly:
- 60 million ether created to contributors of the presale
- 12 Million (20% of the above) were created to the development fund, most of it going to early contributors and developers and the remaining to the Ethereum Foundation
- 5 ethers are created every block (roughly 15-17 seconds) to the miner of the block
- 2-3 ethers are sometimes sent to another miner if they were also able to find a solution but his block wasn't included (called uncle/aunt reward)
[https://www.ethereum.org/ether]
===
Ether (ETH), the cryptofuel that powers distributed applications on the Ethereum platform, will be issued at a constant annual linear rate via the block mining process. This rate is 0.3 times the total amount of ETH that will be purchased in the pre-sale.
[https://blog.ethereum.org/2014/04/10/the-issuance-model-in-ethereum/]
Denominations
Ethereum has a metric system of denominations used as units of ether.
Each denomination has its own unique name (some bear the family name of seminal figures playing a role in evolution of computer science and cryptoeconomics).
The smallest denomination aka base unit of ether is called Wei.
Below is a list of the named denominations and their value in Wei.
Following a common (although somewhat ambiguous) pattern, ether also designates a unit (of 1e18 or one quintillion Wei) of the currency.
Note that the currency is not called Ethereum as many mistakenly think, nor is Ethereum a unit.
Unit | Wei Value | Wei |
wei | 1 wei | 1 |
Kwei (babbage) | 1e3 wei | 1,000 |
Mwei (lovelace) | 1e6 wei | 1,000,000 |
Gwei (shannon) | 1e9 wei | 1,000,000,000 |
microether (szabo) | 1e12 wei | 1,000,000,000,000 |
milliether (finney) | 1e15 wei | 1,000,000,000,000,000 |
ether | 1e18 wei | 1,000,000,000,000,000,000 |
[http://ethdocs.org/en/latest/ether.html?highlight=wei#denominations]
description::
Wei is the smallest denomination unit of ether, aka base unit and equals to 1/10^18 ETH.
name::
* McsEngl.DvETH.Wei-(1/10^18-ETH),
* McsEngl.Ethereum-Wei-(1/10^18-ETH),
* McsEngl.Wei-unit-of-Ether-(1/10^18-ETH),
description::
Babbage equals to 1/10^15 ETH or 10^3 WEI
name::
* McsEngl.DvETH.Babbage-(1/10^15-ETH),
* McsEngl.Ethereum-Babbage-(1/10^15-ETH),
* McsEngl.Babbage-unit-of-Ether-(1/10^15-ETH),
* McsEngl.KWei-unit-of-Ether-(1/10^15-ETH),,
description::
Lovelace equals to 1/10^12 ETH or 10^6 WEI
name::
* McsEngl.DvETH.Lovelace-(1/10^12-ETH),
* McsEngl.Ethereum-Lovelace-(1/10^12-ETH),
* McsEngl.Lovelace-unit-of-Ether-(1/10^12-ETH),
* McsEngl.MWei-unit-of-Ether-(1/10^12-ETH),
description::
Shannon equals to 1/10^9 ETH or 10^9 WEI
name::
* McsEngl.DvETH.Shannon-(1/1-000-000-000-ETH),
* McsEngl.Ethereum-Shannon-(1/1-000-000-000-ETH),
* McsEngl.GWei-unit-of-Ether-(1/1-000-000-000-ETH),
* McsEngl.Shannon-unit-of-Ether-(1/1-000-000-000-ETH),
description::
Szabo equals to 1/10^6 ETH or 10^12 WEI
name::
* McsEngl.DvETH.Szabo-(1/1-000-000-ETH),
* McsEngl.Ethereum-Szabo-(1/1-000-000-ETH),
* McsEngl.Microether-(1/1-000-000-ETH),
* McsEngl.Szabo-unit-of-Ether(1/1-000-000-ETH),
* McsEngl.TeraWei-unit-of-Ether(1/1-000-000-ETH),
* McsEngl.TWei-unit-of-Ether(1/1-000-000-ETH),
description::
Finney equals to 1/10^3 ETH or 10^15 WEI
name::
* McsEngl.DvETH.Finney-(1/1-000-ETH),
* McsEngl.Ethereum-Finney-(1/1-000-ETH),
* McsEngl.Finney-unit-of-Ether-(1/1-000-ETH),
* McsEngl.Milliether-(1/1-000-ETH),
* McsEngl.PetaWei-unit-of-Ether-(1/1-000-ETH),
* McsEngl.PWei-unit-of-Ether-(1/1-000-ETH),
description::
How are ethers created?
The total supply of ether and its rate of issuance was decided by the donations gathered on the 2014 presale. The results were roughly:
60 million ether created to contributors of the presale
12 Million (20% of the above) were created to the development fund, most of it going to early contributors and developers and the remaining to the Ethereum Foundation
5 ethers are created every block (roughly 15-17 seconds) to the miner of the block
2-3 ethers are sometimes sent to another miner if they were also able to find a solution but his block wasn't included (called uncle/aunt reward)
Is the ether supply infinite?
No. According to the terms agreed by all parties on the 2014 presale, issuance of ether is capped at 18 million ether per year (this number equals 25% of the initial supply). This means that while the absolute issuance is fixed, the relative inflation is decreased every year. In theory if this issuance was kept indefinitely then at some point the rate of new tokens created every year would reach the average amount lost yearly (by misuse, accidental key lost, death of holders etc) and there would reach an equilibrium.
But the rate is not expected to be kept: sometime in 2017 Ethereum will be switched from Proof of Work to a new consensus algorithm under development, called Casper that is expected to be more efficient and require less mining subsidy. The exact method of issuance and which function it will serve is an area of active research, but what can be guaranteed now is that (1) the current maximum is considered a ceiling and the new issuance under casper will not exceed it (and is expected to be much less) and (2) whatever method is ultimately picked to issue, it will be a decentralized smart contract that will not give preferential treatment to any particular group of people and whose purpose is to benefit the overall health and security of the network.
[https://www.ethereum.org/ether]
name::
* McsEngl.DvETH.aggregate,
addressWpg::
* https://etherscan.io/stat/supply,
* https://coinmarketcap.com/currencies/ethereum/
specific::
* Circulating-supply,
* Total-supply,
{2017-02-23},
Genesis (60M Crowdsale+12M Other): 72,009,990.50 Ether
+ Mining Block Rewards: 16,223,980.63 Ether
+ Mining Uncle Rewards: 918,936.25 Ether
= Current Total Supply 89,152,907.37 Ether
{2017-02-12},
Genesis (60M Crowdsale+12M Other): 72,009,990.50 Ether
+ Mining Block Rewards: 15,892,811.25 Ether
+ Mining Uncle Rewards: 905,851.25 Ether
= Current Total Supply 88,808,653.00 Ether
[https://etherscan.io/stat/supply]
description::
On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization.
Token systems are surprisingly easy to implement in Ethereum.
The key point to understand is that all a currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (2) the transaction is approved by A.
All that it takes to implement a token system is to implement this logic into a contract.
[https://github.com/ethereum/wiki/wiki/White-Paper#token-systems]
===
Plutons follows the ERC20 Token standard, which means Pluton can be used by any Ethereum software that supports this standard.
[https://plutusit.zendesk.com/hc/en-us]
name::
* McsEngl.Ethereum-Evu.consensusNo, {2017-04-17},
* McsEngl.DnEthereum'asset.consensunNo,
* McsEngl.DnEthereum'consesusNo-exval-token, {2017-04-01},
* McsEngl.DnEthereum'token.consensusNo,
* McsEngl.Ethereum-subcurrency,
* McsEngl.Ethereum-subtoken,
* McsEngl.Ethereum-tkn-(Ethereum-token.consensusNo),
* Ethereum-cevtN, {2017-04-15},
* EthCNet, {2017-04-01},
* EthStn, {2017-03-16},
generic::
* Backness-of-bcnevu,
TxHash: 0xa26540fc32e3b136af585177618282dd4626986d90cfb75b433e6350925b7d6d
Block Height: 3273751 (67 block confirmations)
TimeStamp : 16 mins ago (Mar-01-2017 06:29:15 PM +UTC)
From: 0x354a7141ad6e6d3c6bd636635039eda3b86c39f9
To: Contract 0x48c80f1f4d53d5951e5d5438b54cba84f29f32a5 (REP-Augur)
330 REP TOKEN TRANSFER From 0x354a7141ad6e6d3c6bd636635039eda3b86c39f9 to 0x6830f081f460a59650deab16596f94eeca553c2c
Value: 0 Ether ($0.00)
Gas: 150000
Gas Price: 0.000000021 Ether
Gas Used By Transaction: 37210
Actual Tx Cost/Fee: 0.00078141 Ether ($0.01)
Cumulative Gas Used: 80466
Nonce: 2
Input Data:
[https://etherscan.io/tx/0xa26540fc32e3b136af585177618282dd4626986d90cfb75b433e6350925b7d6d]
addressWpg::
* https://etherscan.io/token-search,
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api#get-token-info,
* https://github.com/ethereum/EIPs/issues/20,
* https://ethereum.org/token,
specific::
* Arcade Token (0xAc709FcB44a43c35F0DA4e3163b117A17F3770f5)
* BCDN (0x1e797Ce986C3CFF4472F7D38d5C4aba55DfEFE40)
* Dentacoin (0x08d32b0da63e2C3bcF8019c9c5d849d7a9d791e6)
* Devcon2 (0xdd94De9cFE063577051A5eb7465D08317d8808B6)
* DVIP (0xadc46ff5434910bd17b24ffb429e585223287d7f)
* DXF - Decentralized Experience (0x72a68fb6d91ed8dc47b564e088e518c6d4a6ff44)
* EthereumMovieVenture (0xb802b24e0637c2b87d2e8b7784c055bbe921011a)
* HumaniQ - HMQ (0x9734c136F5c63531b60D02548Bca73a3d72E024D)
* ICONOMI (0x888666CA69E0f178DED6D75b5726Cee99A87D698)
* Mainstreet (0xe23cd160761f63fc3a1cf78aa034b6cdf97d3e0c)
* Melon (0xBEB9eF514a379B997e0798FDcC901Ee474B6D9A1)
* MetaGold (0x1dea4cA1Ca2A2c946B233a227883ef6846CF17d5)
* ROUND (0x4993CB95c7443bdC06155c5f5688Be9D8f6999a5)
* SIM (0x8FFf600F5c5F0Bb03F345fd60F09A3537845de0a)
* SwarmCity (0xb9e7f8568e08d5659f5d29c4997173d84cdf2607)
* TIME (0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53)
* VIP (0xb939ef33629bba211688724e401d4f6400c0ee6a)
* vSlice (0x5c543e7AE0A1104f78406C340E9C64FD9fCE5170)
* W-GNT (0x01afc37f4f85babc47c0e2d0eababc7fb49793c8)
* Willie Watts (0xd41f3b51e0c2d825a1178582d27c84dbfe48d1af)
description::
ERC: 20
Title: Token standard
Status: Draft
Type: Informational
Created: 19-11.2015
Resolution: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs
[https://github.com/ethereum/EIPs/issues/20]
name::
* McsEngl.ERC20-ethereun-token,
* McsEngl.ERC20-token-of-ethereun,
* McsEngl.DnEthereum'TokenERC20,
* McsEngl.TokenERC20-of-ethereum,
specific::
INTERESTING TOKENS
0xe23cd160761f63fc3a1cf78aa034b6cdf97d3e0c (Mainstreet)
0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53 (TIME)
0xb939ef33629bba211688724e401d4f6400c0ee6a (VIP)
0x08d32b0da63e2C3bcF8019c9c5d849d7a9d791e6 (Dentacoin)
0x1dea4cA1Ca2A2c946B233a227883ef6846CF17d5 (MetaGold)
0xBEB9eF514a379B997e0798FDcC901Ee474B6D9A1 (Melon)
0xb9e7f8568e08d5659f5d29c4997173d84cdf2607 (SwarmCity)
0xd41f3b51e0c2d825a1178582d27c84dbfe48d1af (Willie Watts)
0x9734c136F5c63531b60D02548Bca73a3d72E024D (HumaniQ)
0x8FFf600F5c5F0Bb03F345fd60F09A3537845de0a (SIM)
0x72a68fb6d91ed8dc47b564e088e518c6d4a6ff44 (DXF - Decentralized Experience)
0x01afc37f4f85babc47c0e2d0eababc7fb49793c8 (W-GNT)
0xb802b24e0637c2b87d2e8b7784c055bbe921011a (EthereumMovieVenture)
0x4993CB95c7443bdC06155c5f5688Be9D8f6999a5 (ROUND)
0xdd94De9cFE063577051A5eb7465D08317d8808B6 (Devcon2)
0x5c543e7AE0A1104f78406C340E9C64FD9fCE5170 (vSlice)
0x1e797Ce986C3CFF4472F7D38d5C4aba55DfEFE40 (BCDN)
0xAc709FcB44a43c35F0DA4e3163b117A17F3770f5 (Arcade Token)
0x888666CA69E0f178DED6D75b5726Cee99A87D698 (ICONOMI)
0xadc46ff5434910bd17b24ffb429e585223287d7f (DVIP)
[https://etherscan.io/token-search]
description::
Digix Tokens (DGX)
Dgx Tokens are minted via a Minter Smart Contract.
Each DGX token represents 1g of Gold and divisible to 0.001g.
For every PoA Card that is sent to the Minter Smart Contract, DGX tokens will be issued in return.
For instance, a 100g PoA Card sent to the Minter Smart Contract returns 100 DGX tokens to the user.
Digix Tokens are held in an Ethereum Wallet.
[https://dgx.io/whitepaper.pdf]
name::
* McsEngl.mnyDGX,
* McsEngl.DGX-money,
* McsEngl.Digix-Gold-token,
* McsEngl.Digix-token,
addressWpg::
* https://etherscan.io/address/0x55b9a11c2e8351b4ffc7b11561148bfac9977855,
description::
The First Self Mining Smart Contract
Type: ethereum token
Symbol: MNE
[https://www.minereum.com/]
name::
* McsEngl.Ethereum-MNE-token,
* McsEngl.Mineueum-MNE-token,
* McsEngl.MNE-ethereum-token,
* McsEngl.MNE-Minereum-token,
addressWpg::
* {2017-04-13} Announcement: https://bitcointalk.org/,
* White-paper,
description::
By connecting the existing NFC payment infrastructure with blockchain technology and smart contracts, we solve the universal problem of weak merchant adoption of Bitcoin.
...
Plutons are digital tokens you earn as a reward for shopping with Plutus. Just like cash back or air miles on a credit card, the more you spend the more you earn. (We’re merchant agnostic, so every purchase counts).
Plutons you earn (or purchase early) will be available to convert on the Plutus exchange network, allowing you to make in-store purchases with zero fees on conversion.
[https://plutus.it/]
addressWpg::
* https://etherscan.io/token/Pluton,
* https://medium.com/@PlutusIT/ how-to-get-your-pluton-balance-token-distribution-guide-4a671192a703,
description::
Augur REP
Augur is a decentralized platform with rewards for accurate predictions of certain events. The predictions may concern almost any event with any possible outcomes and can be made by buying virtual shares. Augur provides creation of any prediction market and is fueled by its own cryptocurrency of the same name.
[https://changelly.com/supported-currencies]
name::
* McsEngl.Augur-REP-of-Ethereum,
* McsEngl.REP-Augur--Ethereum-token,
addressWpg::
* https://www.augur.net/
description::
Gas is the-amount of computations of EVM needed to perform a-task.
Gas has a-cost, payed with ETH.
[hmnSngo.2017-09-03]
===
Gas is the-unit of computation-cost of EVM.
[hmnSngo.2017-03-16]
===
The fundamental unit of computation is “gas”; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
Gas Cost is a static value for how much a computation costs in terms of Gas, and the intent is that the real value of the Gas never changes, so this cost should always stay stable over time.
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
===
Executing transactions on Ethereum either runs computations or stores data.
This Costs the network CPU cycles or storage space.
That cost is paid for by the account that initiates the transaction.
The payment is called "gas".
Gas is currently paid using ETH.
At the time of writing this, 1 GAS = 0.00001 ETH.
[https://karl.tech/learning-solidity-part-1-deploy-a-contract/]
===
Just like a car needs so many gallons to travel such a distance, Ethereum transactions require so much Ether to spin so many CPU cycles or store such a quantity of data.
By simple virtue of Ether being a scarce and valuable resource, DoS attacks are prevented.
A blockchain billionaire looking to burn their fortune on a prank could slow the network for a time, but the winning miner of the nefarious transaction’s block would see quite a payday!
[https://medium.com/@ConsenSys/ethereum-bitcoin-plus-everything-a506dc780106#.s007sm8lm]
===
Gas: The fundamental network cost unit.
Paid for exclusively by Ether (as of PoC-4), which is converted freely to and from Gas as required.
Gas does not exist outside of the internal Ethereum computation engine; its price is set by the Transaction and miners are free to ignore Transactions whose Gas price is too low.
[https://ethereum.github.io/yellowpaper/paper.pdf]
===
Gas: a measurement roughly equivalent to computational steps. Every transaction is required to include a gas limit and a fee that it is willing to pay per gas; miners have the choice of including the transaction and collecting the fee or not. If the total number of gas used by the computation spawned by the transaction, including the original message and any sub-messages that may be triggered, is less than or equal to the gas limit, then the transaction processes. If the total gas exceeds the gas limit, then all changes are reverted, except that the transaction is still valid and the fee can still be collected by the miner. Every operation has a gas expenditure; for most operations it is 1, although some expensive operations fave expenditures up to 100 and a transaction itself has an expenditure of 500.
[https://github.com/ethereum/wiki/wiki/Glossary]
===
The principle behind Gas is to have a stable value for how much a transaction or computation costs on the Ethereum network.
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
===
Gas is the relative cost between operations.
So:
- a single step calculation like if(2 > 1) will cost 1 gas
- an operation to store a value in storage will cost 100 gas
If you want to run a contract, this means a certain amount of operations will be executed. The total gas cost of those operations will be the cost of your transaction. It's like the amount of cpu cycles per operation. Everytime you send a transaction to a contract, you need to specify 3 numbers:
- value: the amount of ether you want to send into the account balance
- gas: the maximum amount of gas that may be used for processing a transaction
- gas-price the price per unit of gas you are willing to pay
The processing cost (fee) you offer for the transaction will be calculated as:
gas * gas-price (in eth/g) = ether
Gas is just a way to express relative cost and you can't send gas from 1 person to another. It is not a sub-currency like some people tend to think.
[https://www.reddit.com/r/ethereum/comments/271qdz/can_someone_explain_the_concept_of_gas_in_ethereum/chwp9r7]
name::
* McsEngl.DnEth-gas, {2019-03-30},
* McsEngl.Ethereum-gas!⇒DnEthereum-gas,
* McsEngl.DnEthereum'gas!⇒DnEthereum-gas,
description::
gasPrice
A user constructs and signs a transaction, and each user may specify whatever gasPrice they desire, which can be zero.
However, the Ethereum clients launched at Frontier had a default gasPrice of 0.05e12 wei.
As miners optimize for their revenue, if most transactions are being submitted with a gasPrice of 0.05e12 wei, it would be difficult to convince a miner to accept a transaction that specified a lower, or zero, gasPrice.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#gasprice]
===
Gas Price is how much Gas costs in terms of another currency or token like Ether.
To stabilise the value of gas, the Gas Price is a floating value such that if the cost of tokens or currency fluctuates, the Gas Price changes to keep the same real value.
The Gas Price is set by the equilibrium price of how much users are willing to spend, and how much processing nodes are willing to accept.
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
name::
* McsEngl.DnEth-gas'price,
* McsEngl.DnEthereum'gasPrice,
description::
gas * gas-price (in eth/g) = gas-fee in ether
[hmnSngo.2017-09-03]
===
Gas Fee is effectively the amount of Gas needed to be paid to run a particular transaction or program (called a contract). The Gas Fees of a block can be used to imply the computational load, transaction volume, or size of a block. The gas fees are paid to the miners (or bonded contractors in PoS).
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
description::
Gas Limit is the maximum amount of Gas that can be used per block, it is considered the maximum computational load, transaction volume, or block size of a block, and miners can slowly change this value over time.
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
description::
If some gas is left after the execution, it is refunded in the same way.
[http://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#gas, 0-4-11.6d4cb248]
address::
* {2016-06-23} Joseph Chow: Ethereum, Gas, Fuel and Fees: https://media.consensys.net/,
name::
* McsEngl.DnEthereum'statistics,
* McsEngl.Ethereum-statistics,
addressWpg::
* https://ethstats.net/
* https://etherscan.io/
* http://www.etherlisten.com/
* https://www.etherchain.org/
* http://ethernodes.org/network/1,
* http://ethgasstation.info/about.php,
description::
EtherScan is a Block Explorer and Analytics Platform for Ethereum, which is a decentralized platform that runs smart contracts.
[http://etherscan.io/]
addressWpg::
* http://etherscan.io/
description::
the Ethereum governance process are not very well documented, and it’s hard to understand them without actively participating in them. They evolved over time, and are not an institutionalization of a formal model, and therefore have no inherent reason to be easy to identify or communicate.
No one has full information about the structure of the processes involved. Partly because documenting reality is hard work, and so is communication and education. Partly because the processes are still evolving. And also partly because people only inevitably learn about the processes that they participate in themselves. Most observers don’t participate, and can’t be expected to understand the process, at least until clear documentation is available.
To clear up some of the misinformation about Ethereum governance shared in Fred’s blog: Proof-of-stake will not change the Ethereum governance processes at all, and miners *do not* have a significant influence on the governance process today. Moreover, Vitalik does not have nearly the amount of power to influence governance outcomes that Fred (and lots of other people) assume that he does. The structure of the governance processes limit Vitalik’s power, just as it limits everyone’s power.
[https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca]
name::
* McsEngl.DnEthereum'governance-system,
* McsEngl.governance-system--of-Ethereum,
name::
* McsEngl.DnEthereum'program!⇒DnEthereum-program,
* McsEngl.DnEth-program, {2019-03-31},
* McsEngl.Ethereum-program!⇒DnEthereum-program,
addressWpg::
* docs: https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api,
* https://api.ethplorer.io/,
description::
To make your Đapp work on Ethereum, you can use the web3 object provided by the web3.js library.
Under the hood it communicates to a local node through RPC calls.
web3.js works with any Ethereum node, which exposes an RPC layer.
web3 contains the eth object - web3.eth (for specifically Ethereum blockchain interactions) and the shh object - web3.shh (for Whisper interaction). Over time we'll introduce other objects for each of the other web3 protocols. Working examples can be found here.
If you want to look at some more sophisticated examples using web3.js check out these useful Đapp patterns.
[https://github.com/ethereum/wiki/wiki/JavaScript-AP]
===
Ethereum JavaScript API
This is the Ethereum compatible JavaScript API which implements the Generic JSON RPC spec. It's available on npm as a node module, for bower and component as an embeddable js and as a meteor.js package.
You need to run a local Ethereum node to use this library.
[https://github.com/ethereum/web3.js]
name::
* McsEngl.DnEth-program'API.Javascript!⇒web3.js,
* McsEngl.DnEthereum'Javascript-API!⇒web3.js,
* McsEngl.DnEthereum'API.Javascript!⇒web3.js,
* McsEngl.Ethereum-Javascript-API!⇒web3.js,
* McsEngl.web3.js, {2019-03-28},
name::
* McsEngl.web3.js'oWeb3,
API::
// MetaMask - injected web3
> Object.getOwnPropertyNames(web3).sort().join(", ")
"_extend, _requestManager, bzz, currentProvider, db, eth, net, personal, providers, setProvider, settings, shh, version"
> Object.getOwnPropertyNames(web3.__proto__).sort().join(", ")
"BigNumber, constructor, createBatch, fromAscii, fromDecimal, fromICAP, fromUtf8, fromWei, isAddress, isChecksumAddress, isConnected, isIBAN, reset, setProvider, sha3, toAscii, toBigNumber, toChecksumAddress, toDecimal, toHex, toUtf8, toWei"
===
> const web3 = require('web3')
> const ow3 = new web3(new web3.providers.HttpProvider("http://localhost:8545"));
undefined
> Object.getOwnPropertyNames(ow3).sort()
[ '_extend',
'_requestManager',
'bzz',
'currentProvider',
'db',
'eth',
'net',
'personal',
'providers',
'settings',
'shh',
'version' ]
===
> Object.getOwnPropertyNames(web3).sort()
[ 'arguments',
'caller',
'length',
'name',
'prototype',
'providers' ]
> Object.getOwnPropertyNames(web3.prototype).sort()
[ 'BigNumber',
'constructor',
'createBatch',
'fromAscii',
'fromDecimal',
'fromICAP',
'fromUtf8',
'fromWei',
'isAddress',
'isChecksumAddress',
'isConnected',
'isIBAN',
'reset',
'setProvider',
'sha3',
'toAscii',
'toBigNumber',
'toChecksumAddress',
'toDecimal',
'toHex',
'toUtf8',
'toWei' ]
> Object.getOwnPropertyNames(oW3.prototype.__proto__).sort()
[ '__defineGetter__',
'__defineSetter__',
'__lookupGetter__',
'__lookupSetter__',
'__proto__',
'constructor',
'hasOwnProperty',
'isPrototypeOf',
'propertyIsEnumerable',
'toLocaleString',
'toString',
'valueOf' ]
API::
> Object.getOwnPropertyNames(oWeb3.eth).sort()
[ '_requestManager',
'accounts',
'blockNumber',
'call',
'coinbase',
'compile',
'estimateGas',
'gasPrice',
'getAccounts',
'getBalance',
'getBlock',
'getBlockNumber',
'getBlockTransactionCount',
'getBlockUncleCount',
'getCode',
'getCoinbase',
'getCompilers',
'getGasPrice',
'getHashrate',
'getMining',
'getProtocolVersion',
'getStorageAt',
'getSyncing',
'getTransaction',
'getTransactionCount',
'getTransactionFromBlock',
'getTransactionReceipt',
'getUncle',
'getWork',
'hashrate',
'iban',
'mining',
'protocolVersion',
'sendIBANTransaction',
'sendRawTransaction',
'sendTransaction',
'sign',
'submitWork',
'syncing' ]
API::
> Object.getOwnPropertyNames(oWeb3.personal).sort()
[ '_requestManager',
'getListAccounts',
'listAccounts',
'lockAccount',
'newAccount',
'sendTransaction',
'unlockAccount' ]
API::
> Object.getOwnPropertyNames(oWeb3.version).sort()
[ 'api',
'ethereum',
'getEthereum',
'getNetwork',
'getNode',
'getWhisper',
'network',
'node',
'whisper' ]
===
> oWeb3.version.api
'0.18.2'
name::
* McsEngl.web3.js'transaction-object,
A transaction object looks like this:
{
"blockHash": "0x361464a30ecc10640fd859bc90844a30f0ddff561e6805fb657aff0567da7b4f",
"blockNumber": 131494,
"from": "0x4cf24bf15bfead008b22ea33b7c99a82326031a7",
"gas": 90000,
"gasPrice": "20000000000",
"hash": "0xa11e9aa7aff1bd6cb6c7d886cc531e75a8bcdea1ddcf387937aae3f3a0addb20",
"input": "0x4326ee36000000000000000000000000000000000000000000000000000000000000034b",
"nonce": 1477,
"to": "0x58b671784f4fa6b02e3dcac9f9dd215b66b5669b",
"transactionIndex": 0,
"value": "0"
}
[http://hypernephelist.com/2016/06/21/a-simple-smart-contract-ui-web3.html]
name::
* McsEngl.web3.js'Infrsc,
addressWpg::
* <script src="https://cdn.rawgit.com/ethereum/web3.js/develop/dist/web3.js"></script>
* <script src="https://raw.githubusercontent.com/ethereum/web3.js/0.16.0/dist/web3.min.js"></script>
* https://github.com/ethereum/web3.js,
* https://github.com/ethereum/wiki/wiki/JavaScript-API,
* {2019-03-28} http://www.dappuniversity.com/articles/web3-js-intro,
name::
* McsEngl.DnEth-program.specific,
specific::
* Contract-program,
* Ethpm,
* EVM,
* Client,
* Mist-browser,
* Parity-browser,
* Đapp,
* Mix,
* Token-browser,
* Truffle,
* Mining,
description::
Mix: The integrated development environment for DApp authoring. Quickly prototype and debug decentralised applications on the Ethereum platform. More information can be found at the Mix GitHub Page.
[http://ethdocs.org/en/latest/frequently-asked-questions/frequently-asked-questions.html#how-can-i-store-big-files-on-the-blockchain]
description::
The Ethereum Package Registry
A package index for Ethereum smart contract packages.
[https://www.ethpm.com/]
name::
* McsEngl.Ethereum-package-registry),
* McsEngl.DnEth-program.Ethpm,
* McsEngl.DnEth-program.package-registry,
addressWpg::
* https://www.ethpm.com/,
* https://www.ethpm.com/registry,
* https://www.ethpm.com/docs/integration-guide,
description::
The EVM is not a register machine but a stack machine, so all computations are performed on an area called the stack.
It has a maximum size of 1024 elements and contains words of 256 bits. Access to the stack is limited to the top end in the following way: It is possible to copy one of the topmost 16 elements to the top of the stack or swap the topmost element with one of the 16 elements below it. All other operations take the topmost two (or one, or more, depending on the operation) elements from the stack and push the result onto the stack. Of course it is possible to move stack elements to storage or memory, but it is not possible to just access arbitrary elements deeper in the stack without first removing the top of the stack.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#storage-memory-and-the-stack]
===
The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts in Ethereum. It is not only sandboxed, but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem, or other processes. Smart contracts even have limited access to other smart contracts.
Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode). However, contracts are typically written in an Ethereum high level language, compiled into byte code using an EVM compiler, and finally uploaded on the blockchain using an Ethereum client.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
===
The Ethereum Virtual Machine is the primary innovation of the Ethereum project. This is a virtual machine designed to be run by all participants in a peer to peer network, it can read and write to a blockchain both executable code and data, Verify digital signatures, and is able to run code in a quasi-Turing complete manner. It will only execute code when it receives a message verified by a digital signature, and the information stored on the blockchain tells it is appropriate to do so.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
The Ethereum Virtual Machine or EVM is the runtime environment for smart contracts in Ethereum. It is not only sandboxed but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem or other processes. Smart contracts even have limited access to other smart contracts.
[https://solidity.readthedocs.org/en/latest/introduction-to-smart-contracts.html#overview]
name::
* McsEngl.DnEth-Evm!⇒DnEthvm, {2019-03-28},
* McsEngl.DnEthereum'Virtual-Machine!⇒DnEthvm,
* McsEngl.DnEthvm, {2019-06-21},
* McsEngl.EVM-(Ethereum-Vitrual-Machine)!⇒DnEthvm,
* McsEngl.Ethereum-EVM!⇒DnEthvm,
* McsEngl.Ethereum-Vitrual-Machine!⇒DnEthvm,
* McsEngl.Ethereum-VM!⇒DnEthvm,
whole::
Ethereum enables this complexity by placing a virtual machine (called the Ethereum Virtual Machine, or EVM) in every node on the network.
The EVM is not conceptually different than any other virtual machine.
You may already be familiar with the Java Virtual Machine (JVM), for example.
Just like JVM code will run on any machine hosting a JVM and produce identical outputs over the same set of inputs, the EVM enables the Ethereum blockchain to reach consensus about the proper output of any EVM code based on a set of inputs.
[https://medium.com/@ConsenSys/ethereum-bitcoin-plus-everything-a506dc780106#.izxhgdxdt]
description::
The EVM is not a register machine but a stack machine, so all computations are performed on an area called the stack.
It has a maximum size of 1024 elements and contains words of 256 bits.
Access to the stack is limited to the top end in the following way: It is possible to copy one of the topmost 16 elements to the top of the stack or swap the topmost element with one of the 16 elements below it.
All other operations take the topmost two (or one, or more, depending on the operation) elements from the stack and push the result onto the stack.
Of course it is possible to move stack elements to storage or memory, but it is not possible to just access arbitrary elements deeper in the stack without first removing the top of the stack.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-10]
===
The Ethereum VM is stack-based.
This means the operands for the instructions are taken from the stack, and it is also where the results are added.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-11-advanced-solidity-II.md#stack-machines]
===
Elements on the stack are 32-byte words,
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#overview]
===
// Prefer loops to recursion (max call stack depth is 1024)
[https://learnxinyminutes.com/docs/solidity/]
description::
Each account has a persistent memory area which is called storage.
Storage is a key-value store that maps 256-bit words to 256-bit words.
It is not possible to enumerate storage from within a contract and it is comparatively costly to read and even more so, to modify storage.
A contract can neither read nor write to any storage apart from its own.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#storage-memory-and-the-stack]
===
Unlike stack and memory, which reset after computation ends, storage persists for the long term.
... While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage.
[https://github.com/ethereum/wiki/wiki/White-Paper#code-execution]
===
Every account has a persistent key-value store mapping 256-bit words to 256-bit words called storage.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
===
Complex types, i.e. types which do not always fit into 256 bits have to be handled more carefully than the value-types we have already seen. Since copying them can be quite expensive, we have to think about whether we want them to be stored in memory (which is not persisting) or storage (where the state variables are held).
[http://solidity.readthedocs.io/en/v0.4.9/types.html#index-13]
===
“Contracts” in Ethereum should not be seen as something that should be “fulfilled” or “complied with”; rather, they are more like “autonomous agents” that live inside of the Ethereum execution environment, always executing a specific piece of code when “poked” by a message or transaction, and having direct control over their own ether balance and their own key/value store to store their permanent state.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#contract-accounts]
===
key-value storage (persisted in a merkle tree). ...
all keys and values in storage are 32 bytes.
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#overview]
name::
* McsEngl.DnEth-account'storage,
* McsEngl.DnEthvm'storage,
* McsEngl.DnEthereum'storage,
* McsEngl.DnEthvm'key-value-storage,
description::
The second memory area is called memory, of which a contract obtains a freshly cleared instance for each message call.
Memory is linear and can be addressed at byte level, but reads are limited to a width of 256 bits, while writes can be either 8 bits or 256 bits wide.
Memory is expanded by a word (256-bit), when accessing (either reading or writing) a previously untouched memory word (ie. any offset within a word).
At the time of expansion, the cost in gas must be paid.
Memory is more costly the larger it grows (it scales quadratically).
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-10]
===
Memory is an expandable byte-array used to store data during program execution.
It can be accessed using the MSTORE and MLOAD instructions
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-11-advanced-solidity-III.md#memory]
===
Complex types, i.e. types which do not always fit into 256 bits have to be handled more carefully than the value-types we have already seen. Since copying them can be quite expensive, we have to think about whether we want them to be stored in memory (which is not persisting) or storage (where the state variables are held).
[http://solidity.readthedocs.io/en/v0.4.9/types.html#index-13]
name::
* McsEngl.DnEthvm'memory,
* McsEngl.DnEthereum'memory,
* McsEngl.Ephemeral-memory-of-evm,
description::
Calldata is a byte-array, just like memory, but it is read-only.
It contains the data from the transaction that triggered the code execution.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-11-advanced-solidity-III.md#memory]
name::
* McsEngl.DnEthvm'calldata,
* McsEngl.DnEthereum'calldata,
name::
* McsEngl.DnEthvm'code,
description::
· Evm-assembly-code is human readable code close to bytecode which is-translated to bytecode in order to be-executed by the-Evm.
name::
* McsEngl.DnEthvm'code.assembly,
* McsEngl.DnEth-asm,
* McsEngl.DnEth-asm-code--of-Evm,
description::
· Evm-source-code is code writter in high-level-languages (Solidity, Serpent, LLL, Viper) which is translated to bytecode with an-Evm-compiler.
name::
* McsEngl.DnEthvm'code.source,
* McsEngl.DnEth-source-code--of-Evm,
description::
"Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode).
However, contracts are typically written in an Ethereum high level language, compiled into byte code using an EVM compiler, and finally uploaded on the blockchain using an Ethereum client."
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
===
"EVM Code: The bytecode that the EVM can natively execute. Used to formally specify the meaning and ramifications of a message to an Account."
[http://gavwood.com/Paper.pdf]
name::
* McsEngl.DnEthvm'bytecode,
* McsEngl.EVM-bytecode,
* McsEngl.bytecode-of-Evm,
description::
The instruction set of the EVM is kept minimal in order to avoid incorrect implementations which could cause consensus problems.
All instructions operate on the basic data type, 256-bit words.
The usual arithmetic, bit, logical and comparison operations are present.
Conditional and unconditional jumps are possible.
Furthermore, contracts can access relevant properties of the current block like its number and timestamp.
[http://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#instruction-set, 0-4-11.6d4cb248]
===
Every single operation that is executed inside the EVM is actually simultaneously executed by every node in the network.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
name::
* McsEngl.DnEthvm'computation!⇒DnEthereum-opcode,
* McsEngl.DnEthvm'instruction!⇒DnEthereum-opcode,
* McsEngl.DnEthvm'opcode!⇒DnEthereum-opcode,
* McsEngl.DnEthvm'operation!⇒DnEthereum-opcode,
* McsEngl.DnEth-inn!⇒DnEthereum-opcode, {2019-03-29},
* McsEngl.DnEth-inn!=Ethereum-instruction,
* McsEngl.DnEth-opcode, {2019-03-30},
* McsEngl.Ethereum-operation-code!⇒DnEthereum-opcode,
* McsEngl.operation-code-of-EVM!⇒DnEthereum-opcode,
description::
The table tells us how many arguments each opcode pops off the stack and pushes back onto the stack, as well as how much gas is consumed.
# schema: [opcode, ins, outs, gas]
opcodes = {
# arithmetic
Evm-opcode.0x00: ['Evm-opcode.STOP', 0, 0, 0],
Evm-opcode.0x01: ['Evm-opcode.ADD', 2, 1, 3],
Evm-opcode.0x02: ['Evm-opcode.MUL', 2, 1, 5],
Evm-opcode.0x03: ['Evm-opcode.SUB', 2, 1, 3],
Evm-opcode.0x04: ['Evm-opcode.DIV', 2, 1, 5],
Evm-opcode.0x05: ['Evm-opcode.SDIV', 2, 1, 5],
Evm-opcode.0x06: ['Evm-opcode.MOD', 2, 1, 5],
Evm-opcode.0x07: ['Evm-opcode.SMOD', 2, 1, 5],
Evm-opcode.0x08: ['Evm-opcode.ADDMOD', 3, 1, 8],
Evm-opcode.0x09: ['Evm-opcode.MULMOD', 3, 1, 8],
Evm-opcode.0x0a: ['Evm-opcode.EXP', 2, 1, 10],
Evm-opcode.0x0b: ['Evm-opcode.SIGNEXTEND', 2, 1, 5],
# boolean
Evm-opcode.0x10: ['Evm-opcode.LT', 2, 1, 3],
Evm-opcode.0x11: ['Evm-opcode.GT', 2, 1, 3],
Evm-opcode.0x12: ['Evm-opcode.SLT', 2, 1, 3],
Evm-opcode.0x13: ['Evm-opcode.SGT', 2, 1, 3],
Evm-opcode.0x14: ['Evm-opcode.EQ', 2, 1, 3],
Evm-opcode.0x15: ['Evm-opcode.ISZERO', 1, 1, 3],
Evm-opcode.0x16: ['Evm-opcode.AND', 2, 1, 3],
Evm-opcode.0x17: ['Evm-opcode.OR', 2, 1, 3],
Evm-opcode.0x18: ['Evm-opcode.XOR', 2, 1, 3],
Evm-opcode.0x19: ['Evm-opcode.NOT', 1, 1, 3],
Evm-opcode.0x1a: ['Evm-opcode.BYTE', 2, 1, 3],
# crypto
Evm-opcode.0x20: ['Evm-opcode.SHA3', 2, 1, 30],
# contract context
Evm-opcode.0x30: ['Evm-opcode.ADDRESS', 0, 1, 2],
Evm-opcode.0x31: ['Evm-opcode.BALANCE', 1, 1, 20],
Evm-opcode.0x32: ['Evm-opcode.ORIGIN', 0, 1, 2],
Evm-opcode.0x33: ['Evm-opcode.CALLER', 0, 1, 2],
Evm-opcode.0x34: ['Evm-opcode.CALLVALUE', 0, 1, 2],
Evm-opcode.0x35: ['Evm-opcode.CALLDATALOAD', 1, 1, 3],
Evm-opcode.0x36: ['Evm-opcode.CALLDATASIZE', 0, 1, 2],
Evm-opcode.0x37: ['Evm-opcode.CALLDATACOPY', 3, 0, 3],
Evm-opcode.0x38: ['Evm-opcode.CODESIZE', 0, 1, 2],
Evm-opcode.0x39: ['Evm-opcode.CODECOPY', 3, 0, 3],
Evm-opcode.0x3a: ['Evm-opcode.GASPRICE', 0, 1, 2],
Evm-opcode.0x3b: ['Evm-opcode.EXTCODESIZE', 1, 1, 20],
Evm-opcode.0x3c: ['Evm-opcode.EXTCODECOPY', 4, 0, 20],
# blockchain context
Evm-opcode.0x40: ['Evm-opcode.BLOCKHASH', 1, 1, 20],
Evm-opcode.0x41: ['Evm-opcode.COINBASE', 0, 1, 2],
Evm-opcode.0x42: ['Evm-opcode.TIMESTAMP', 0, 1, 2],
Evm-opcode.0x43: ['Evm-opcode.NUMBER', 0, 1, 2],
Evm-opcode.0x44: ['Evm-opcode.DIFFICULTY', 0, 1, 2],
Evm-opcode.0x45: ['Evm-opcode.GASLIMIT', 0, 1, 2],
# storage and execution
Evm-opcode.0x50: ['Evm-opcode.POP', 1, 0, 2],
Evm-opcode.0x51: ['Evm-opcode.MLOAD', 1, 1, 3],
Evm-opcode.0x52: ['Evm-opcode.MSTORE', 2, 0, 3],
Evm-opcode.0x53: ['Evm-opcode.MSTORE8', 2, 0, 3],
Evm-opcode.0x54: ['Evm-opcode.SLOAD', 1, 1, 50],
Evm-opcode.0x55: ['Evm-opcode.SSTORE', 2, 0, 0],
Evm-opcode.0x56: ['Evm-opcode.JUMP', 1, 0, 8],
Evm-opcode.0x57: ['Evm-opcode.JUMPI', 2, 0, 10],
Evm-opcode.0x58: ['Evm-opcode.PC', 0, 1, 2],
Evm-opcode.0x59: ['Evm-opcode.MSIZE', 0, 1, 2],
Evm-opcode.0x5a: ['Evm-opcode.GAS', 0, 1, 2],
Evm-opcode.0x5b: ['Evm-opcode.JUMPDEST', 0, 0, 1],
# logging
Evm-opcode.0xa0: ['Evm-opcode.LOG0', 2, 0, 375],
Evm-opcode.0xa1: ['Evm-opcode.LOG1', 3, 0, 750],
Evm-opcode.0xa2: ['Evm-opcode.LOG2', 4, 0, 1125],
Evm-opcode.0xa3: ['Evm-opcode.LOG3', 5, 0, 1500],
Evm-opcode.0xa4: ['Evm-opcode.LOG4', 6, 0, 1875],
# arbitrary length storage (proposal for metropolis hardfork)
Evm-opcode.0xe1: ['Evm-opcode.SLOADBYTES', 3, 0, 50],
Evm-opcode.0xe2: ['Evm-opcode.SSTOREBYTES', 3, 0, 0],
Evm-opcode.0xe3: ['Evm-opcode.SSIZE', 1, 1, 50],
# closures
Evm-opcode.0xf0: ['Evm-opcode.CREATE', 3, 1, 32000],
Evm-opcode.0xf1: ['Evm-opcode.CALL', 7, 1, 40],
Evm-opcode.0xf2: ['Evm-opcode.CALLCODE', 7, 1, 40],
Evm-opcode.0xf3: ['Evm-opcode.RETURN', 2, 0, 0],
Evm-opcode.0xf4: ['Evm-opcode.DELEGATECALL', 6, 0, 40],
Evm-opcode.0xff: ['Evm-opcode.SUICIDE', 1, 0, 0],
}
# push
for i in range(1, 33):
opcodes[0x5f + i] = ['PUSH' + str(i), 0, 1, 3]
# duplicate and swap
for i in range(1, 17):
opcodes[0x7f + i] = ['DUP' + str(i), i, i + 1, 3]
opcodes[0x8f + i] = ['SWAP' + str(i), i + 1, i + 1, 3]
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#overview]
specific::
There are over 100 opcodes,
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#overview]
===
All of the opcodes and their complete descriptions are available in the Ethereum Yellow paper. For convenience, though, I've made a handy reference list of them all:
0s: Stop and Arithmetic Operations
0x00 Evm-opcode.STOP Halts execution
0x01 Evm-opcode.ADD Addition operation
0x02 Evm-opcode.MUL Multiplication operation
0x03 Evm-opcode.SUB Subtraction operation
0x04 Evm-opcode.DIV Integer division operation
0x05 Evm-opcode.SDIV Signed integer
0x06 Evm-opcode.MOD Modulo
0x07 Evm-opcode.SMOD Signed modulo
0x08 Evm-opcode.ADDMOD Modulo
0x09 Evm-opcode.MULMOD Modulo
0x0a Evm-opcode.EXP Exponential operation
0x0b Evm-opcode.SIGNEXTEND Extend length of two's complement signed integer
10s: Comparison & Bitwise Logic Operations
0x10 Evm-opcode.LT Lesser-than comparison
0x11 Evm-opcode.GT Greater-than comparison
0x12 Evm-opcode.SLT Signed less-than comparison
0x13 Evm-opcode.SGT Signed greater-than comparison
0x14 Evm-opcode.EQ Equality comparison
0x15 Evm-opcode.ISZERO Simple not operator
0x16 Evm-opcode.AND Bitwise AND operation
0x17 Evm-opcode.OR Bitwise OR operation
0x18 Evm-opcode.XOR Bitwise XOR operation
0x19 Evm-opcode.NOT Bitwise NOT operation
0x1a Evm-opcode.BYTE Retrieve single byte from word
20s: SHA3
0x20 Evm-opcode.SHA3 Compute Keccak-256 hash
30s: Environmental Information
0x30 Evm-opcode.ADDRESS Get address of currently executing account
0x31 Evm-opcode.BALANCE Get balance of the given account
0x32 Evm-opcode.ORIGIN Get execution origination address
0x33 Evm-opcode.CALLER Get caller address. This is the address of the account that is directly responsible for this execution
0x34 Evm-opcode.CALLVALUE Get deposited value by the instruction/transaction responsible for this execution
0x35 Evm-opcode.CALLDATALOAD Get input data of current environment
0x36 Evm-opcode.CALLDATASIZE Get size of input data in current environment
0x37 Evm-opcode.CALLDATACOPY Copy input data in current environment to memory This pertains to the input data passed with the message call instruction or transaction
0x38 Evm-opcode.CODESIZE Get size of code running in current environment
0x39 Evm-opcode.CODECOPY Copy code running in current environment to memory
0x3a Evm-opcode.GASPRICE Get price of gas in current environment
0x3b Evm-opcode.EXTCODESIZE Get size of an account's code
0x3c Evm-opcode.EXTCODECOPY Copy an account's code to memory
40s: Block Information
0x40 Evm-opcode.BLOCKHASH Get the hash of one of the 256 most recent complete blocks
0x41 Evm-opcode.COINBASE Get the block's beneficiary address
0x42 Evm-opcode.TIMESTAMP Get the block's timestamp
0x43 Evm-opcode.NUMBER Get the block's number
0x44 Evm-opcode.DIFFICULTY Get the block's difficulty
0x45 Evm-opcode.GASLIMIT Get the block's gas limit
50s Stack, Memory, Storage and Flow Operations
0x50 Evm-opcode.POP Remove item from stack
0x51 Evm-opcode.MLOAD Load word from memory
0x52 Evm-opcode.MSTORE Save word to memory
0x53 Evm-opcode.MSTORE8 Save byte to memory
0x54 Evm-opcode.SLOAD Load word from storage
0x55 Evm-opcode.SSTORE Save word to storage
0x56 Evm-opcode.JUMP Alter the program counter
0x57 Evm-opcode.JUMPI Conditionally alter the program counter
0x58 Evm-opcode.PC Get the value of the program counter prior to the increment
0x59 Evm-opcode.MSIZE Get the size of active memory in bytes
0x5a Evm-opcode.GAS Get the amount of available gas, including the corresponding reduction
0x5b Evm-opcode.JUMPDEST Mark a valid destination for jumps
60s & 70s: Push Operations
Evm-opcode.0x60 Evm-opcode.PUSH1 Place 1 byte item on stack
0x61 Evm-opcode.PUSH2 Place 2-byte item on stack
…
0x7f Evm-opcode.PUSH32 Place 32-byte (full word) item on stack
80s: Duplication Operations
Evm-opcode.0x80 Evm-opcode.DUP1 Duplicate 1st stack item
0x81 Evm-opcode.DUP2 Duplicate 2nd stack item
…
0x8f Evm-opcode.DUP16 Duplicate 16th stack item
90s: Exchange Operations
Evm-opcode.0x90 Evm-opcode.SWAP1 Exchange 1st and 2nd stack items
0x91 Evm-opcode.SWAP2 Exchange 1st and 3rd stack items
… …
0x9f Evm-opcode.SWAP16 Exchange 1st and 17th stack items
a0s: Logging Operations
0xa0 Evm-opcode.LOG0 Append log record with no topics
0xa1 Evm-opcode.LOG1 Append log record with one topic
… …
0xa4 Evm-opcode.LOG4 Append log record with four topics
f0s: System operations
0xf0 Evm-opcode.CREATE Create a new account with associated code
0xf1 Evm-opcode.CALL Message-call into an account
0xf2 Evm-opcode.CALLCODE Message-call into this account with alternative account's code
0xf3 Evm-opcode.RETURN Halt execution returning output data
0xf4 Evm-opcode.DELEGATECALL Message-call into this account with an alternative account's code, but persisting the current values for sender
and value
Halt Execution, Mark for deletion
0xff Evm-opcode.SUICIDE Halt execution and register account for later deletion
[http://ethereum.stackexchange.com/a/120]
description::
Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode).
However, contracts are typically written in an Ethereum high level language, compiled into byte code using an EVM compiler, and finally uploaded on the blockchain using an Ethereum client.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
description::
The EVM is a security oriented virtual machine, designed to permit untrusted code to be executed by a global network of computers. To do so securely, it imposes the following restrictions:
- Every computational step taken in a program's execution must be paid for up front, thereby preventing Denial-of-Service attacks.
- Programs may only interact with each other by transmitting a single arbitrary-length byte array; they do not have access to each other's state.
- Program execution is sandboxed; an EVM program may access and modify its own internal state and may trigger the execution of other EVM programs, but nothing else.
- Program execution is fully deterministic and produces identical state transitions for any conforming implementation beginning in an identical state.
These restrictions motivated many of the design decisions of the overall Ethereum state transition machine, and their enforcement is pervasive throughout the specification.
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#security]
===
The Ethereum Virtual Machine or EVM is the runtime environment for smart contracts in Ethereum.
It is not only sandboxed but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem or other processes.
Smart contracts even have limited access to other smart contracts.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#overview 0-4-10.6258fe71]
addressWpg::
* https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md,
description::
In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected.
...
The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.
The formal execution model of EVM code is surprisingly simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage. At the start of every round of execution, the current instruction is found by taking the pcth (Program Counter) byte of code (or 0 if pc >= len(code)), and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item. Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.
[https://github.com/ethereum/wiki/wiki/White-Paper#code-execution]
===
... A commonly asked question is "where" contract code is executed, in terms of physical hardware.
This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.
[https://github.com/ethereum/wiki/wiki/White-Paper#blockchain-and-mining]
description::
The Ethereum clients are very analogous to a Java VM or .NET runtime.
They enable you to execute “Ethereum programs” on your computer. They are implemented to a written specification (the Yellow Paper) and by design are interoperable and somewhat “commodity”.
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-clients/choosing-a-client.html]
name::
* McsEngl.Ethereum-browser!⇒Ethereum-client,
* McsEngl.Ethereum-client, {2019-03-21},
* McsEngl.DnEthereum'client!⇒Ethereum-client,
* McsEngl.DnEthereum'browser!⇒Ethereum-client,
* McsEngl.DnEth-program.client!⇒Ethereum-client,
name::
* McsEngl.Ethereum-clt.specific,
specific::
The Ethereum Foundation publishes the specifications for Ethereum clients on their Github page, and funds development of official clients written in Go (go-ethereum), C++ (cpp-ethereum) and Python (py-ethereum). There are also community contributed clients in many other languages, including Ruby, Java, Haskell and Rust.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
As of September 2016, the leading implementations are go-ethereum and Parity.
[http://ethdocs.org/en/latest/ethereum-clients/choosing-a-client.html]
===
Client Language Developers Homestead Release
go-ethereum Go Ethereum Foundation geth-v1.3.5
cpp-ethereum C++ Ethereum Foundation eth-v1.2.2
pyethapp Python Ethereum Foundation v1.2.0 release imminent
ethereumjs-lib Javascript Ethereum Foundation ethereumjs-lib-v3.0.0
Ethereum(J) Java <ether.camp> ethereumJ-v1.2.0-homestead-RC
ethereumH Haskell ConsenSys not available yet
Parity Rust Ethcore Parity-v1.0.0
ruby-ethereum Ruby Jan Xie not available yet
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-clients/choosing-a-client.html]
===
* command-line-client
description::
Go Ethereum is available either as a standalone client called Geth that you can install on pretty much any operating system, or as a library that you can embed in your Go, Android or iOS projects.
[https://geth.ethereum.org/]
name::
* McsEngl.Ethereum-geth,
* McsEngl.DnEthereum'Go-ethereum,
* McsEngl.Ethereum-client.geth,
* McsEngl.DnEth-program.geth,
* McsEngl.geth-of-Ethereum,
* McsEngl.Go-ethereum-client,
$ geth help
NAME:
geth - the go-ethereum command line interface
Copyright 2013-2016 The go-ethereum Authors
USAGE:
geth [options] command [command options] [arguments...]
VERSION:
1.5.5-unstable
COMMANDS:
init Bootstrap and initialize a new genesis block
import Import a blockchain file
export Export blockchain into file
upgradedb Upgrade chainblock database
removedb Remove blockchain and state databases
dump Dump a specific block from storage
monitor Monitor and visualize node metrics
account Manage accounts
wallet Manage Ethereum presale wallets
console Start an interactive JavaScript environment
attach Start an interactive JavaScript environment (connect to node)
js Execute the specified JavaScript files
makedag Generate ethash DAG (for testing)
version Print version numbers
license Display license information
help, h Shows a list of commands or help for one command
ETHEREUM OPTIONS:
--datadir "/home/tron/.ethereum" Data directory for the databases and keystore
--keystore Directory for the keystore (default = inside the datadir)
--networkid value Network identifier (integer, 0=Olympic (disused), 1=Frontier, 2=Morden (disused), 3=Ropsten) (default: 1)
--olympic Olympic network: pre-configured pre-release test network
--testnet Ropsten network: pre-configured test network
--dev Developer mode: pre-configured private network with several debugging flags
--identity value Custom node name
--fast Enable fast syncing through state downloads
--light Enable light client mode
--lightserv value Maximum percentage of time allowed for serving LES requests (0-90) (default: 0)
--lightpeers value Maximum number of LES client peers (default: 20)
--lightkdf Reduce key-derivation RAM & CPU usage at some expense of KDF strength
PERFORMANCE TUNING OPTIONS:
--cache value Megabytes of memory allocated to internal caching (min 16MB / database forced) (default: 128)
--trie-cache-gens value Number of trie node generations to keep in memory (default: 120)
ACCOUNT OPTIONS:
--unlock value Comma separated list of accounts to unlock
--password value Password file to use for non-inteactive password input
API AND CONSOLE OPTIONS:
--rpc Enable the HTTP-RPC server
--rpcaddr value HTTP-RPC server listening interface (default: "localhost")
--rpcport value HTTP-RPC server listening port (default: 8545)
--rpcapi value API's offered over the HTTP-RPC interface (default: "eth,net,web3")
--ws Enable the WS-RPC server
--wsaddr value WS-RPC server listening interface (default: "localhost")
--wsport value WS-RPC server listening port (default: 8546)
--wsapi value API's offered over the WS-RPC interface (default: "eth,net,web3")
--wsorigins value Origins from which to accept websockets requests
--ipcdisable Disable the IPC-RPC server
--ipcapi value APIs offered over the IPC-RPC interface (default: "admin,debug,eth,miner,net,personal,shh,txpool,web3")
--ipcpath "geth.ipc" Filename for IPC socket/pipe within the datadir (explicit paths escape it)
--rpccorsdomain value Comma separated list of domains from which to accept cross origin requests (browser enforced)
--jspath loadScript JavaScript root path for loadScript (default: ".")
--exec value Execute JavaScript statement (only in combination with console/attach)
--preload value Comma separated list of JavaScript files to preload into the console
NETWORKING OPTIONS:
--bootnodes value Comma separated enode URLs for P2P discovery bootstrap
--port value Network listening port (default: 30303)
--maxpeers value Maximum number of network peers (network disabled if set to 0) (default: 25)
--maxpendpeers value Maximum number of pending connection attempts (defaults used if set to 0) (default: 0)
--nat value NAT port mapping mechanism (any|none|upnp|pmp|extip:<IP>) (default: "any")
--nodiscover Disables the peer discovery mechanism (manual peer addition)
--v5disc Enables the experimental RLPx V5 (Topic Discovery) mechanism
--nodekey value P2P node key file
--nodekeyhex value P2P node key as hex (for testing)
MINER OPTIONS:
--mine Enable mining
--minerthreads value Number of CPU threads to use for mining (default: 8)
--autodag Enable automatic DAG pregeneration
--etherbase value Public address for block mining rewards (default = first account created) (default: "0")
--targetgaslimit value Target gas limit sets the artificial target gas floor for the blocks to mine (default: "4712388")
--gasprice value Minimal gas price to accept for mining a transactions (default: "20000000000")
--extradata value Block extra data set by the miner (default = client version)
GAS PRICE ORACLE OPTIONS:
--gpomin value Minimum suggested gas price (default: "20000000000")
--gpomax value Maximum suggested gas price (default: "500000000000")
--gpofull value Full block threshold for gas price calculation (%) (default: 80)
--gpobasedown value Suggested gas price base step down ratio (1/1000) (default: 10)
--gpobaseup value Suggested gas price base step up ratio (1/1000) (default: 100)
--gpobasecf value Suggested gas price base correction factor (%) (default: 110)
VIRTUAL MACHINE OPTIONS:
--jitvm Enable the JIT VM
--forcejit Force the JIT VM to take precedence
--jitcache value Amount of cached JIT VM programs (default: 64)
LOGGING AND DEBUGGING OPTIONS:
--ethstats value Reporting URL of a ethstats service (nodename:secret@host:port)
--metrics Enable metrics collection and reporting
--fakepow Disables proof-of-work verification
--verbosity value Logging verbosity: 0=silent, 1=error, 2=warn, 3=info, 4=core, 5=debug, 6=detail (default: 3)
--vmodule value Per-module verbosity: comma-separated list of <pattern>=<level> (e.g. eth/*=6,p2p=5)
--backtrace value Request a stack trace at a specific logging statement (e.g. "block.go:271") (default: :0)
--pprof Enable the pprof HTTP server
--pprofaddr value pprof HTTP server listening interface (default: "127.0.0.1")
--pprofport value pprof HTTP server listening port (default: 6060)
--memprofilerate value Turn on memory profiling with the given rate (default: 524288)
--blockprofilerate value Turn on block profiling with the given rate (default: 0)
--cpuprofile value Write CPU profile to the given file
--trace value Write execution trace to the given file
EXPERIMENTAL OPTIONS:
--shh Enable Whisper
--natspec Enable NatSpec confirmation notice
MISCELLANEOUS OPTIONS:
--solc value Solidity compiler command to be used (default: "solc")
--netrestrict value Restricts network communication to the given IP networks (CIDR masks)
--help, -h show help
[https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options]
> exit
you exit with Ctrl D or exit
> eth.accounts
['0x407d73d8a49eeb85d32cf465507dd71d507100c1']
> checkAllBalances();
eth.accounts[0]: 0xd1ade25ccd3d550a7eb532ac759cac7be09c2719 balance: 63.11848 ether
eth.accounts[1]: 0xda65665fc30803cb1fb7e6d86691e20b1826dee0 balance: 0 ether
eth.accounts[2]: 0xe470b1a7d2c9c5c6f03bbaa8fa20db6d404a0c32 balance: 1 ether
eth.accounts[3]: 0xf4dd5c3794f1fd0cdc0327a83aa472609c806e99 balance: 6 ether
[https://github.com/ethereum/go-ethereum/wiki/Managing-your-accounts]
> admin.nodeInfo
To check the ports used by geth and also find your enode URI run:
> admin.setSolc("/usr/local/bin/solc")
solc, the solidity compiler commandline interface
Version: 0.2.2-02bb315d/.-Darwin/appleclang/JIT linked to libethereum-1.2.0-8007cef0/.-Darwin/appleclang/JIT
path: /usr/local/bin/solc
description::
I work on an Ethereum based key manager (coming soon, called MetaMask),
[https://medium.com/@danfinlay/daos-are-mere-identities-1f6247456561#.fgtcad2i8]
===
MetaMask is a bridge that allows you to visit the distributed web of tomorrow in your browser today. It allows you to run Ethereum dApps right in your browser without running a full Ethereum node.
MetaMask includes a secure identity vault, providing a user interface to manage your identities on different sites and sign blockchain transactions.
We’re initially building MetaMask as a Chrome plugin, but eventually plan to support Firefox and beyond. If you’re a developer, you can start developing with MetaMask today.
Our mission is to make Ethereum as easy to use for as many people as possible.
[https://metamask.io/#how-it-works]
name::
* McsEngl.DnEth-program.MetaMask,
* McsEngl.MetaMask-Ethereum-client,
addressWpg::
* {2019-11-05} https://medium.com/metamask/breaking-changes-to-the-metamask-inpage-provider-b4dde069dd0a,
* https://medium.com/metamask/metamask-3-migration-guide-914b79533cdd#.ytw5dcxi2,
description::
There are many Ethereum clients to choose from.
We recommend using different clients when developing and deploying.
WHEN DEVELOPING
EthereumJS TestRPC: https://github.com/ethereumjs/testrpc
When developing your Truffle-based application, we recommend using the EthereumJS TestRPC. It's a complete blockchain-in-memory that runs only on your development machine. It processes transactions instantly instead of waiting for the default block time – so you can test that your code works quickly – and it tells you immediately when your smart contracts run into errors. It also makes a great client for automated testing, and Truffle knows how to use its special features to speed up test runtime by almost 90%.
[http://truffleframework.com/docs/getting_started/client]
===
There are various compatible clients for the protocol, the most popular being geth, a Go language implementation. However, it’s not the most developer-friendly. The best option I’ve found is the testrpc node (yes, the name sucks). Trust me, it will save you a lot of time. Install it and run it:
$ sudo npm install -g ethereumjs-testrpc
$ testrpc
You should run testrpc
in a new terminal and leave it running while you develop. Each time you run testrpc, it will generate 10 new addresses with simulated test funds for you to use. This is not real money and you’re safe to try anything with no risk of losing funds.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
name::
* McsEngl.DnEth-program.testrpc,
* McsEngl.Ethereum-testrpc,
* McsEngl.testrpc-Ethereum-simulator,
addressWpg::
* https://github.com/ethereumjs/testrpc,
NOTE:
As of version 3.0.2, testrpc requires at least Node 6.9.1 to run - this is because the ethereumjs-vm@2.0.1 dependency is now shipping using ES2015 language features.
[https://github.com/ethereumjs/testrpc]
description::
The Mist browser is the tool of choice to browse and use Dapps.
[https://github.com/ethereum/mist]
===
Ethereum wallet is a wallet, Mist is a browser.
===
The Mist Browser includes the Ethereum Wallet. The Ethereum Wallet is the Mist Browser with the browser function disabled. If you plan on using contracts use the Mist, else if you're just holding ETH, use the Ethereum Wallet.
[https://www.reddit.com/r/ethereum/comments/53nifc/confusion_should_i_download_mist_or_ethereum/d7undsl/]
name::
* McsEngl.Ethereum-Mist,
* McsEngl.Ethereum-client.Mist,
* McsEngl.DnEth-program.Mist,
* McsEngl.Mist-browser,
API
mist.platform
mist.menu
mist.menu.setBadge(text)
mist.menu.add(id, options, callback)
mist.menu.update(id [, options] [, callback])
mist.menu.remove(id)
mist.menu.clear()
[https://github.com/ethereum/mist/blob/master/MISTAPI.md#api]
The data folder for Mist is stored in other places:
Windows %APPDATA%/Roaming/Mist (C:\Users\user\AppData\Roaming\Mist)
MacOSX ~/Library/Application Support/Mist
Linux ~/.config/Mist
[https://github.com/ethereum/mist]
addressWpg::
* https://blog.slock.it/the-ethereum-wallet-an-introduction-for-non-devs-9c530f75c018#.n1jtag8gq,
usage::
a GUI-based option for creating accounts: The “official” Mist Ethereum wallet.
description::
For updating simply download the new version and copy it over the old one (keep a backup of the old one if you want to be sure).
[https://github.com/ethereum/mist]
Wallet 0.5.2 (Beta 10)
@frozeman frozeman released this 19 days ago · 69 commits to wallet since this release
This release adds some additional log information to the splash screen and adds a feature to send all ether for an account.
Full list of changes:
Added a send-all functionality to the send page.
Add German (thanks to @ColRad) and Portuguese (@alexvandesande) translation for the wallet!
Added log infos to the splash screen, so users can see what the node is currently doing...
Improved ether display precision on the confirmation screen
Added a check with NTP servers to see if the computer time is correct, if not it shows an error
Increased error timeout
If you should notice that your wallet links lead to a white page, please run the following script in the console:
https://gist.github.com/frozeman/ed41008f4d30900da3e8
This changes all your wallet addresses internally back to lowercase (we introduced that by accident).
[https://github.com/ethereum/mist/releases]
description::
Parity is a full Ethereum node client and provides a wallet interface in it's web front-end.
[https://github.com/bokkypoobah/TokenTrader/wiki/Frequently-Asked-Questions]
===
http://127.0.0.1:8180/
PARITY
Our Best-in-Class Ethereum Browser
Parity is our fully-featured and integrated Ethereum browser. It is the first in a series of planned software releases by Ethcore and the culmination of more than two years of lessons learnt designing and implementing blockchains by the best minds in the industry. Implemented in Rust, it uses the cutting edge, highly sophisticated hybrid functional language to create a blockchain client which is uniquely high-performance, low-footprint and reliable.
[https://ethcore.io/index.html]
===
Next Generation Ethereum Browser
We've created the world's fastest and lightest Ethereum client and integrated it directly into your web browser. Using it you can access all the features of the Ethereum network including powerful Decentralised applications and the multitude of cryptocurrencies issued on ethereum.
We're happy to release our source code under the GPLv3 licence; we hope you'll have as much fun reading and using our code as we had designing and writing it. You can use it for any of your Ethereum needs.
[https://ethcore.io/parity.html]
name::
* McsEngl.Ethereum-client'Parity,
* McsEngl.Ethereum-Parity,
* McsEngl.DnEth-program.Parity,
* McsEngl.Parity-Ethereum,
description::
By default, Parity will also run a JSONRPC server on 127.0.0.1:8545. This is fully configurable and supports a number of RPC APIs.
[https://github.com/ethcore/parity]
description::
Parity comes with a built-in wallet.
To access Parity Wallet this simply go to http://127.0.0.1:8080/. It includes various functionality allowing you to:
create and manage your Ethereum accounts;
manage your Ether and any Ethereum tokens;
create and register your own tokens;
and much more.
[https://github.com/ethcore/parity]
Win::
C:\Users\username\AppData\Roaming\Parity\Ethereum\dapps
===
mklink /D C:\Users\username\AppData\Roaming\Parity\Ethereum\dapps\ethcoredap D:\dirBCN\ethcoredapp\dist
symbolic link created for C:\Users\username\AppData\Roaming\Parity\Ethereum\dapps\ethcoredap <<===>> D:\dirBCN\ethcoredapp\dist
Mac::
$HOME/Library/Application Support/io.parity.ethereum/dapps
description::
Proof of Authority Chains
Available only in 1.5 and above.
Parity supports a Proof-of-Authority consensus engine to be used with EVM based chains. Proof-of-Authority is a replacement for Proof-of-Work, which can be used for private chain setups.
It does not depend on nodes solving arbitrarily difficult mathematical problems, but instead uses a hard-configured set of "authorities" - nodes that are explicitly allowed to create new blocks and secure the blockchain. This makes it easier to maintain a private chain and keep the block issuers accountable.
[https://github.com/ethcore/parity/wiki/Proof-of-Authority-Chains]
name::
* McsEngl.blockchain-appending-algo.proof-of-authority,
* McsEngl.proof-of-authority--consensus-algorithm,
addressWpg::
* https://blog.kucoin.com/how-does-proof-of-authority-compare-to-other-consensus-mechanisms/,
* {2017-12-09} Moscow’s Ethereum Voting System Launches: https://www.ethnews.com/,
description::
If you run into an issue while using parity, feel free to file one in this repository or hop on our gitter chat room to ask a question. We are glad to help!
[https://github.com/ethcore/parity]
addressWpg::
* https://ethcore.io/parity.html,
* https://github.com/ethcore/parity,
=== DOCS:
* https://github.com/ethcore/parity/wiki,
* https://wiki.parity.io/Parity-Ethereum,
=== CHAT:
* gitter: https://gitter.im/ethcore/parity?
addressWpg::
* https://github.com/ethcore/parity/releases,
config.toml
# This config should be placed in following path:
# %UserProfile%\AppData\Roaming\Parity\Ethereum\config.toml
[parity]
# Test Network
chain = "ropsten"
[https://ethcore.github.io/parity-config-generator/]
addressWpg::
* https://github.com/ethcore/parity/releases,
eth-parity.1-5-7.2017-03-07:
arkpar released this 5 days ago · 700 commits to master since this release
This release resolves a single issue with failing auto-updates.
[https://github.com/ethcore/parity/releases/tag/v1.5.7]
description::
Access An Open Financial System
Token is a browser for the Ethereum network that provides universal access to financial services.
[https://www.tokenbrowser.com/]
name::
* McsEngl.Ethereum-client.Token,
* McsEngl.DnEth-program.Token-client,
addressWpg::
* {2017-04-18} Introducing Token: https://blog.tokenbrowser.com/introducing-token-2f2ceeab6d4c,
description::
Truffle is a development environment, testing framework and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier.
[http://truffleframework.com/docs/]
===
Truffle is a development environment, testing framework and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier. With Truffle, you get:
Built-in smart contract compilation, linking, deployment and binary management.
Automated contract testing with Mocha and Chai.
Configurable build pipeline with support for custom build processes.
Scriptable deployment & migrations framework.
Network management for deploying to many public & private networks.
Interactive console for direct contract communication.
Instant rebuilding of assets during development.
External script runner that executes scripts within a Truffle environment.
[https://github.com/ConsenSys/truffle]
name::
* McsEngl.Ethereum--truffle-tool),
* McsEngl.DnEthereum'Truffle-tool,
* McsEngl.DnEth-program.Truffle-tool,
* McsEngl.Truffle-ethereum-tool,
description::
PS C:\WINDOWS\system32> truffle -h
Truffle v3.1.2 - a development framework for Ethereum
Usage: truffle <command> [options]
Commands:
init Initialize new Ethereum project with example contracts and tests
compile Compile contract source files
migrate Run migrations to deploy contracts
build Execute build pipeline (if configuration present)
test Run Mocha and Solidity tests
console Run a console with contract abstractions and commands available
create Helper to create new contracts, migrations and tests
install Install a package from the Ethereum Package Registry
publish Publish a package to the Ethereum Package Registry
networks Show addresses for deployed contracts on each network
watch Watch filesystem for changes and rebuild the project automatically
serve Serve the build directory on localhost and watch for changes
exec Execute a JS module within this Truffle environment
version Show version number and exit
See more at http://truffleframework.com/docs
name::
* McsEngl.Ethereum-tflcmd-(truffle-command),
specific::
Commands:
init Initialize new Ethereum project with example contracts and tests
compile Compile contract source files
migrate Run migrations to deploy contracts
build Execute build pipeline (if configuration present)
test Run Mocha and Solidity tests
console Run a console with contract abstractions and commands available
create Helper to create new contracts, migrations and tests
install Install a package from the Ethereum Package Registry
publish Publish a package to the Ethereum Package Registry
networks Show addresses for deployed contracts on each network
watch Watch filesystem for changes and rebuild the project automatically
serve Serve the build directory on localhost and watch for changes
exec Execute a JS module within this Truffle environment
version Show version number and exit
structure::
Once completed, you'll now have a project structure with the following items:
contracts/ - directory where Truffle expects to find solidity contracts.
migrations/ - directory to place scriptable deployment files.
test/ - location of test files for testing your application and contracts.
truffle.js - your main Truffle configuration file.
[http://truffleframework.com/docs/getting_started/project#initialize-your-project]
description::
Artifacts of your compilation will be placed in the ./build/contracts directory, relative to your project.
This directory will be created if it does not exist.
These artifacts are integral to the inner workings of Truffle, and they play and important part to the successful deployment of your application.
You should not edit these files by hand as they'll be overwritten by contract compilation and deployment.
[http://truffleframework.com/docs/getting_started/compile]
description::
contracts/ should contain smart contracts written in Solidity,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
description::
migrations/ should contain scriptable deployment files.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
description::
should contain unit tests written using Mocha and Chai,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
description::
Migrations are Javascript files that help you deploy contracts to the Ethereum network.
These files are responsible for staging your deployment tasks, and they're written under the assumption that your deployment needs will change over time.
As your project evolves, you'll create new migration scripts to further this evolution on the blockchain.
A history of previously run migrations is recorded on-chain through a special Migrations contract, detailed below.
[http://truffleframework.com/docs/getting_started/migrations]
1_initial_migration.js:
var Migrations = artifacts.require("./Migrations.sol");
module.exports = function(deployer) {
deployer.deploy(Migrations);
};
description::
truffle.js is the main configuration file used by Truffle.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
module.exports =
{
networks: {
development: {
host: "localhost",
port: 8545,
network_id: "*" // Match any network id
}
}
};
truffle_migrate_test_frozen_testrpc:
Parity client run on background. We have to kill it.
addressWpg::
* http://truffleframework.com/
* http://truffleframework.com/docs/
* https://github.com/trufflesuite,
=== tutorial
* http://truffleframework.com/tutorials/truffle-and-metamask,
* https://steemit.com/ethereum/@brennanhm/ ethereum-smart-contract-testing-installing-truffle-and-testrpc,
* https://leanpub.com/decentralizedapplicationswithethereum,
description::
COMMAND
$ npm install -g truffle
REQUIREMENTS
NodeJS 5.0+ recommended.
Windows, Linux or Mac OS X
Truffle also requires that you have a running Ethereum client which supports the standard JSON RPC API (nearly all of them). There are many to choose from, and some better than others for development. We'll discuss them in detail in the next section.
RECOMMENDATIONS FOR WINDOWS
If you're a Windows user, we recommend installing and using Truffle via Windows PowerShell or Git BASH. These two shells provide features far beyond the standard Command Prompt, and will make your life on the command line much easier.
[http://truffleframework.com/docs/getting_started/installation]
===
RESOLVING NAMING CONFLICTS ON WINDOWS
When using the Command Prompt on Windows, the default configuration file name can cause a conflict with the truffle executable. If this is the case, we recommend using Windows PowerShell or Git BASH as these shells do not have this conflict. Alternatively, you can rename the configuration file to truffle-config.js to avoid this conflict.
[http://truffleframework.com/docs/advanced/configuration#resolving-naming-conflicts-on-windows]
name::
* McsEngl.DnEth-program.mining,
description::
ethminer-genoil
What is ethminer-0.9.41-genoil-1.x.x?
Formerly known as Genoil's CUDA miner, ethminer-0.9.41-genoil-1.x.x is a fork of the stock ethminer version 0.9.41. While native CUDA support is its most significant difference, it has the following additional features:
- realistic benchmarking against arbitrary epoch/DAG/blocknumber
- on-GPU DAG generation (no more DAG files on disk)
- stratum mining without proxy
- OpenCL devices picking
- farm failover (getwork + stratum)
[https://github.com/Genoil/cpp-ethereum]
===
Ethminer: A standalone miner. This can be used to mine or benchmark a mining set-up. It is compatible with eth, geth, and pyethereum. Check out the Mining page for more information.
[https://ethereum-homestead.readthedocs.io/en/latest/frequently-asked-questions/frequently-asked-questions.html#i-have-heard-of-ethereum-but-what-are-geth-mist-ethminer-mix]
name::
* McsEngl.Ethereum-miner-program,
* McsEngl.Ethereum-miner-genoil,
* McsEngl.Genoil's-CUDA-miner,
description::
Scrypt GPU miner
[https://github.com/sgminer-dev/sgminer]
description::
"What is the difference between smart contracts and dapps?
Anupam Vijayvergia
Written Nov 2
In simplest terms Dapps or rather decentralised apps is an app running on a decentralised network. Dapps has its backend and can have a front end code or user interface written on any language. However backend code runs on a decentralised network.
Smart contracts is a piece of code that is meant to do a specific purpose which is part of a decentralised application."
[https://www.quora.com/What-is-the-difference-between-smart-contracts-and-dapps/answer/Anupam-Vijayvergia?srid=uJVpm]
===
"The Ethereum platform itself is featureless or value-agnostic. Similar to programming languages, it is up to entrepreneurs and developers to decide what it should be used for. However, it is clear that certain application types benefit more than others from Ethereum’s capabilities. Specifically, ethereum is suited for applications that automate direct interaction between peers or facilitate coordinated group action across a network. For instance, applications for coordinating peer-to-peer marketplaces, or the automation of complex financial contracts. Bitcoin allows for individuals to exchange cash without involving any middlemen like financial institutions, banks, or governments. Ethereum’s impact may be more far-reaching. In theory, financial interactions or exchanges of any complexity could be carried out automatically and reliably using code running on Ethereum. Beyond financial applications, any environments where trust, security, and permanence are important – for instance, asset-registries, voting, governance, and the internet of things – could be massively impacted by the Ethereum platform."
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#what-is-ethereum]
name::
* McsEngl.Dcc-app.Ethereum!⇒DappEth,
* McsEngl.DappEth,
* McsEngl.Dapp.Ethereum!⇒DappEth,
* McsEngl.Ethereum-app-(Ethereum--decentralized-application)!⇒DappEth,
* McsEngl.DnEth-Dapp, {2019-04-11},
* McsEngl.Ethereum-Dapp!⇒DappEth,
* McsEngl.Ethereum-DApp-(Ethereum--decentralized-application)!⇒DappEth,
* McsEngl.DnEthereum'app!⇒DappEth,
* McsEngl.DnEthereum'blockchain-application!⇒DappEth,
* McsEngl.DnEthereum'Dapp!⇒DappEth,
* McsEngl.DnEthereum-Dapp!⇒DappEth,
* McsEngl.Đapp.Ethereum!⇒DappEth,
* McsEngl.Đbapp.Ethereum!⇒DappEth,
generic::
* blockchain-dApp,
name::
* McsEngl.DappEth'backend,
* McsEngl.DappEth'contract,
description::
A dapp ('decentralized app') consists of two parts: a frontend, written in HTML or QML, and a backend (think of it as the 'database' for your frontend). We'll focus here on an HTML dapp.
[https://forum.ethereum.org/discussion/1402/how-to-get-started-your-first-dapp-under-one-hour]
name::
* McsEngl.DappEth'tool,
* McsEngl.Tool-for-ethereum-Dapps,
specific::
* Dappbase: https://dappbase.com/,
* Embark,
description::
Framework for serverless Decentralized Applications using Ethereum, IPFS and other platforms
[https://github.com/iurimatias/embark-framework]
name::
* McsEngl.Embark--Eth-Dapp-tool,
description::
app/
|___ contracts/ #solidity or serpent contracts
|___ html/
|___ css/
|___ js/
config/
|___ blockchain.json #environments configuration
|___ contracts.json #contracts configuration
test/
|___ #contracts tests
Solidity/Serpent files in the contracts directory will automatically be deployed with embark run. Changes in any files will automatically be reflected in app, changes to contracts will result in a redeployment and update of their JS Bindings
[https://github.com/iurimatias/embark-framework#dapp-structure]
description::
EmbarkJS is a javascript library meant to abstract and facilitate the development of DApps.
[https://github.com/iurimatias/embark-framework#embarkjs]
addressWpg::
* https://ethereum.org/en/dapps/
* https://www.smashingmagazine.com/2021/01/nodejs-api-ethereum-blockchain/,
* http://dapps.ethercasts.com/
* https://blog.ethereum.org/2016/07/12/build-server-less-applications-mist/
=== tutorial
* https://medium.com/@mvmurthy/ full-stack-hello-world-voting-ethereum-dapp-tutorial-part-1-40d2d0d807c2#.4b357annh,
=== tool:
* https://github.com/uzyn/ethereum-webpack-example-dapp,
* https://github.com/dapphub/dapple,
name::
* McsEngl.DappEth.specific,
specific::
* https://github.com/ethereum/dapp-bin,
===
* CROWDFUNDING-ethdap,
* EXCHANGE-ethdap,
* FINANCIAL-ethdap,
* STORAGE-ethdap,
* VOTING-ethdap,
* WEB-BASED-ethdap,
===
* Aragon-ethdap,
* Augur-ethdap,
* Chronobank-ethdap,
* CryptoKitties,
* DAO-ethdap,
* Digix-ethdap,
* Ethlance-ethdap,
* IDEX-ethdap,
* Maker-ethdap,
* Plutus-ethdap,
* Swarm-ethdap,
* WeiFund.io-ethdap,
description::
To build web based dapps, Ethereum comes with a handy javascript library called web3.js which connects to your blockchain node. So you can just include this library in your famous js framework like reactjs, angularjs etc and start building.
[https://medium.com/@mvmurthy/ethereum-for-web-developers-890be23d1d0c#.ruvn38p8k]
name::
* McsEngl.DappEth.Webapp,
addressWpg::
* http://hypernephelist.com/2016/06/21/a-simple-smart-contract-ui-web3.html,
description::
While the developers of the game, Vancouver/San Franciso based AxionZen, sell their idea as an easy way to get to understand cryptocurrency, it was not expected that the game would become the biggest dAPP deployed on the Ethereum ecosystem, surpassing EtherDelta.
[https://cryptocoin.news/news/cryptokitties-clog-up-ethereum-network-3962/]
===
What’s the big deal?
CryptoKitties is one of the world’s first games to be built on blockchain technology—the same breakthrough that makes things like Bitcoin and Ethereum possible. Bitcoin and ether are cryptocurrencies but CryptoKitties are cryptocollectibles. You can buy, sell, or trade your CryptoKitty like it was a traditional collectible, secure in the knowledge that blockchain will track ownership securely.
[https://www.cryptokitties.co/]
name::
* McsEngl.CryptoKitties.Ethereum-DApp,
* McsEngl.DappEth.CryptoKitties,
description::
Ethlance is a first of its kind platform for job market, built entirely on blockchain and using only cryptocurrency for payments. Thanks to those technologies, platform can sustainably run with 0% service fees. Ethlance will never take cut from transactions between freelancers and employers.
We're running on public Ethereum blockchain with front-end source files written in Clojurescript and served from decentralised file storage IPFS. Ethlance is completely open-source and you can find its code on github.com/madvas/ethlance. If you found a bug, please don't hesitate to open an issue there.
If you're unsure how to use Ethereum, please see How it works page
Ethlance backend logic consists of 8 smart-contracts, deployed on following addresses:
EthlanceUser at 0x85c1b0dc9e3443e06e5f1b09844631378825bb14
EthlanceJob at 0x3d3bb143a6ee72deb9646c14b403ccc3f6e3c2c8
EthlanceContract at 0x12f4abc6c7ae413618d348bfdc855bca8654037d
EthlanceInvoice at 0x917db76c206f744274375428e261fa6521ac1b05
EthlanceConfig at 0x613e3395622eabdb2b12f9b77a0e5eb2b9a57f36
EthlanceDB at 0x5371a8d8d8a86c76de935821ad1a3e9b908cfced
EthlanceViews at 0xb7b882d1ea87da8506ba10bfbe8b751246bc3259
EthlanceSearch at 0x8c8cf5f0fe7ce048baa9573278c4b44b7a8646e4
[http://ethlance.com/#/about]
name::
* McsEngl.Ethlance-(Ethereum-dApp),
* McsEngl.DappEth.Ethlance,
description::
What is IDEX?
IDEX is a distributed cryptocurrency exchange powered by Ethereum smart contracts that provides the safest and most secure way to trade Ethereum tokens.
[http://idex.market/]
description::
We design and build KyberNetwork, an on-chain protocol which allows instant exchange and conversion of digital assets (e.g. crypto tokens) and cryptocurrencies (e.g. Ether, Bitcoin, ZCash) with high liquidity.
KyberNetwork will be the first system that implements several ideal operating properties of an exchange including trustless, decentralized execution, instant trade and high liquidity.
Besides serving as an exchange, KyberNetwork also provides payment APIs that will allow Ethereum accounts to easily receive payments from any crypto tokens.
As an example, any merchant can now use KyberNetwork APIs to allow users to pay in any crypto tokens, but the merchant will receive payments in Ether (ETH) or other preferred tokens.
Although running on the Ethereum network, KyberNetwork’s roadmap includes supporting cross-chain trades between different cryptocurrencies using relays and future protocols like Polkadot and Cosmos. Ethereum accounts will be able to safely receive payment from Bitcoin, ZCash and other cryptocurrencies via our payment APIs, through this trustless payment service.
Derivatives will be introduced to mitigate the exposure to the risk of volatilities for the users of KyberNetwork Crystals (KNC) and selected cryptocurrencies.
This will allow users to participate in the price movements synthetically.
[https://kyber.network/assets/KyberNetworkWhitepaper.pdf]
name::
* McsEngl.KyberNetwork,
addressWpg::
* {2018-01-19} New Strategic Partnership Announcement: Kyber Network + ICON: https://blog.kyber.network/,
description::
Peepeth is a decentralized alternative to Twitter.
It's unstoppable and uncensorable because it runs on the Ethereum blockchain.
No company or government controls the data on Peepeth.
[https://peepeth.com/about]
name::
* McsEngl.DappEth.Peepeth,
* McsEngl.Peepeth--Ethereum-Dapp,
description::
PAY WITH BITCOIN.
ANYWHERE.
Waiting for merchants to accept Bitcoin and Ethereum? You don't have to! With Plutus Tap & Pay, you can pay at any NFC-enabled merchant.
[https://plutus.it/]
===
Plutus operates by connecting to a decentralized exchange platform, which uses smart contracts to handle digital currency trading.
... Users send bitcoin to their Plutus account, which are then automatically transferred to trader(s) on the DEX network. Smart contracts verify the transaction before the resulting fiat (USD, EUR, etc.) from the trader’s funds in escrow is transferred to the user’s virtual debit card, which can then be spent at any merchant that accepts NFC payments.
[https://plutus.it/case-study]
description::
Swarm is a distributed storage platform and content distribution service, a native base layer service of the ethereum web 3 stack. The primary objective of Swarm is to provide a decentralized and redundant store of Ethereum's public record, in particular to store and distribute dapp code and data as well as block chain data.
From the end user's perspective, Swarm is not that different from WWW, except that uploads are not to a specific server. The objective is to peer-to-peer storage and serving solution that is DDOS-resistant, zero-downtime, fault-tolerant and censorship-resistant as well as self-sustaining due to a built-in incentive system which uses peer to peer accounting and allows trading resources for payment.
Swarm is designed to deeply integrate with the devp2p multiprotocol network layer of Ethereum as well as with the Ethereum blockchain for domain name resolution, service payments and content availability insurance.
[http://swarm-gateways.net/bzz:/theswarm.eth/]
description::
A Brief Overview
To use the WeiFund decentralized app (dApp), users will first open WeiFund in a web 3.0 enabled browser such as Ethereum's Mist.
A user would then immediately be able to start, contribute to, browse, and manage crowdfunding campaigns.
WeiFund's interface and user experience will be very similar to that of conventional crowdfunding platforms such as Kickstarter or GoFundMe, however, all funds raised on WeiFund will be accounted for in the Ether digital-currency.
Web 3.0 enabled browsers will come with their own wallet systems so that payments made on WeiFund to start and contribute to campaigns are done so in a secure and verifiable way.
[http://weifund.io/]
description::
The popular term “smart contracts” refers to code in a Contract Account – programs that execute when a transaction is sent to that account.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
===
One way of thinking about smart contracts, and the way we’re going to think about them here, is as extremely basic, stateless web-services. Webservices are units of functionality in a system (the internet), with a well defined API and an identifier (IP address) that can be used to call them. Similarly, a smart contract is a unit of functionality, the public functions exposed by their Solidity contracts is the API, and their public address is the identifier. A web-service is normally called by making an http request, and a contract is called by making a transaction. Also, in most cases everyone is allowed to call them the endpoints are exposed to the public, so security must be handled on a call-by-call basis, and the same thing goes for contracts and their functions. We can even utilize common patterns and architectures, such as for example the microservices architecture.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
“Contracts” in Ethereum should not be seen as something that should be “fulfilled” or “complied with”; rather, they are more like “autonomous agents” that live inside of the Ethereum execution environment, always executing a specific piece of code when “poked” by a message or transaction, and having direct control over their own ether balance and their own key/value store to store their permanent state.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#contract-accounts]
===
A contract is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain.
Contract accounts are able to pass messages between themselves as well as doing practically Turing complete computation.
Contracts live on the blockchain in a Ethereum-specific binary format called Ethereum Virtual Machine (EVM) bytecode.
Contracts are typically written in some high level language such as Solidity and then compiled into bytecode to be uploaded on the blockchain.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#contracts]
===
CT: Ethereum and smart contracts: Do you feel that in the real world it would be difficult to understand for lay people?
TG: I believe a large part of the misunderstanding with so-called smart contracts is that the name is partially a misnomer. Really what we're talking about is programs on blockchains. These programs can be coded to do just about anything, but have the added benefit of digital uniqueness without central point of failure. From this point, lots of things are possible from digital assets to autonomous assistants.
[https://cointelegraph.com/news/ethereum-co-founder-taylor-gerring-hard-fork-will-make-network-more-resilient]
===
Smart contracts are computer programs that can automatically execute the terms of a contract.
[http://www.ethereum.nz/]
===
So far, all contracts we listed were owned and executed by other accounts probably held by humans. But there is no discrimination against robots or humans in the Ethereum ecosystem and contracts can create arbitrary actions like any other account would. Contracts can own tokens, participate in crowdsales, and even be voting members of other contracts.
[https://www.ethereum.org/dao]
===
Our backend (referred to as a ‘contract’ in Ethereum) is going to use a language called Solidity. There are several other contract languages you can use when building Ethereum backend, LLL (similar to Lisp) and Serpent (similar to Python). We’ll use Solidity as it is the formally supported language by the ETHDEV team.
[https://dappsforbeginners.wordpress.com/tutorials/your-first-dapp/]
name::
* McsEngl.Ethereum-contract-program!⇒DcontractEth,
* McsEngl.Ethereum-smart-contract!⇒DcontractEth,
* McsEngl.DcontractEth, {2019-03-28},
* McsEngl.DnEthereum'contract-program!⇒DcontractEth,
* McsEngl.DnEthereum'smart-contract!⇒DcontractEth,
* McsEngl.DnEth-contract!⇒DcontractEth,
* McsEngl.DnEth-smart-contract!⇒DcontractEth,
* McsEngl.smart-contract.Ethereum!⇒DcontractEth,
* Ethcrt, {2017-02-11},
* Ethsct,
* Ethsmc,
name::
* McsEngl.DcontractEth'semantic-unit,
* McsEngl.Ethereum-ctpsut,
name::
* McsEngl.DcontractEth'function,
* McsEngl.Ethereum-ctpf,
description::
It is important to distinguish two kinds of functions that can appear in a contract:
Read-only (constant) functions: functions that don’t perform any state changes. They only read state, perform computations, and return values. As these functions can be resolved locally by each node, they cost no gas. Marked with the keyword constant
.
Transactional functions: functions that perform a state change in the contract or move funds. As these changes need to be reflected in the blockchain, transactional function execution requires sending a transaction to the network and spending gas.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
description::
It is important to distinguish two kinds of functions that can appear in a contract:
Read-only (constant) functions: functions that don’t perform any state changes. They only read state, perform computations, and return values. As these functions can be resolved locally by each node, they cost no gas. Marked with the keyword constant
.
Transactional functions: functions that perform a state change in the contract or move funds.
As these changes need to be reflected in the blockchain, transactional function execution requires sending a transaction to the network and spending gas.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
name::
* McsEngl.DcontractEth'sentence,
* McsEngl.Ethereum-ctpstc,
name::
* McsEngl.DcontractEth'paragraph,
* McsEngl.Ethereum-ctppgf,
description::
The-account (normal or contract) that created the-contract-program.
[hmnSngo.2017-03-05]
name::
* McsEngl.DcontractEth'creator,
* McsEngl.DcontractEth'owner,
description::
The key property of a smart contract is simple: there is only a fixed number of parties.
The parties do not all have to be known at initialization-time; a sell order, where A offers to sell 50 units of asset A to anyone who can provide 10 units of asset B, is also a smart contract.
Smart contracts can run on forever; hedging contracts and escrow contracts are good examples there.
However, smart contracts that run on forever should still have a fixed number of parties (eg. an entire decentralized exchange is not a smart contract), and contracts that are not intended to exist forever are smart contracts because existing for a finite time necessarily implies the involvement of a finite number of parties.
[https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/]
description::
Organizer address vs. Contract address.
Your deployed contract will have its own contract address (different from the organizer’s address) on the blockchain.
This address is accessible in a Solidity contract using this, as used inside the refundTicket function in the contract: address myAddress = this;
[http://consensys.github.io/developers/articles/101-noob-intro/]
description::
A contract can neither read nor write to any storage apart from its own.
[http://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack, 0-4-11.6d4cb248]
name::
* McsEngl.DcontractEth'storage,
description::
Smart-Contract Messages
Contracts have the ability to send “messages” to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment.
A message contains:
- sender: The sender of the message.
- recipient: The recipient of the message.
- amount: The amount of ether to transfer.
- data: An optional data field.
- startgas: A STARTGAS value.
Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL opcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
Message Calls
Contracts can call other contracts or send Ether to non-contract accounts by the means of message calls. Message calls are similar to transactions, in that they have a source, a target, data payload, Ether, gas and return data. In fact, every transaction consists of a top-level message call which in turn can create further message calls.
A contract can decide how much of its remaining gas should be sent with the inner message call and how much it wants to retain. If an out-of-gas exception happens in the inner call (or any other exception), this will be signalled by an error value put onto the stack. In this case, only the gas sent together with the call is used up. In Solidity, the calling contract causes a manual exception by default in such situations, so that exceptions “bubble up” the call stack.
As already said, the called contract (which can be the same as the caller) will receive a freshly cleared instance of memory and has access to the call payload - which will be provided in a separate area called the calldata. After it finished execution, it can return data which will be stored at a location in the caller’s memory preallocated by the caller.
Calls are limited to a depth of 1024, which means that for more complex operations, loops should be preferred over recursive calls.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#message-calls]
===
What is a message?
Contracts have the ability to send “messages” to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. They can be conceived of as function calls.
A message contains:
- the sender of the message (implicit).
- the recipient of the message
- VALUE field - The amount of wei to transfer alongside the message to the contract address,
an optional data field, that is the actual input data to the contract
- a STARTGAS value, which limits the maximum amount of gas the code execution triggered by the message can incur.
Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL or DELEGATECALL opcodes, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#what-is-a-message]
name::
* McsEngl.DcontractEth'message,
* McsEngl.DnEthereum'message-call-of-contract,
specific::
Contracts can even create other contracts using a special opcode (i.e. they do not simply call the zero address). The only difference between these create calls and normal message calls is that the payload data is executed and the result stored as code and the caller / creator receives the address of the new contract on the stack.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#create]
name::
* McsEngl.DnEthereum'language-of-smart-contract!⇒DnEthereum-contract-lang,
* McsEngl.DnEthereum'smart-contract-language!⇒DnEthereum-contract-lang,
* McsEngl.DcontractEth'language!⇒DnEthereum-contract-lang,
* McsEngl.DcontractEth-lang,
specific::
* LLL,
* Mutan,
* Serpent,
* Solidity,
* Viper,
name::
* McsEngl.DcontractEth-lang.Mutan,
* McsEngl.Mutan-Eth-contract-lang,
Mutan (deprecated)
Mutan is a statically typed, C-like language designed and developed by Jeffrey Wilcke. It is no longer maintained.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#mutan-deprecated]
description::
Solidity is a high-level language whose syntax is similar to that of JavaScript and it is designed to compile to code for the Ethereum Virtual Machine.
As you will see, it is quite easy to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
[https://solidity.readthedocs.org/en/latest/]
name::
* McsEngl.DcontractEth-lang.Solidity!⇒Lsol,
* McsEngl.DnEthereum'Solidity-language!⇒Lsol,
* McsEngl.Ethereum-Solidity-language!⇒Lsol,
* McsEngl.Lsol, {2019-06-27},
* McsEngl.Solidity-language!⇒Lsol,
* McsEngl.ethsol!⇒Lsol,
* McsEngl.lagSol!⇒Lsol, {2019-03-29},
* McsEngl.langSol!⇒Lsol, {2019-03-29},
generic::
* LanguageComputerPrograming,
description::
Solidity-archetype is a-document describing a-smart-contract the-way a-human executes it.
[hmnSngo.2019-06-27]
description::
Solidity-algorithm is a-document describing a-smart-contract the-way a-machine executes it.
[hmnSngo.2019-06-27]
name::
* McsEngl.Lsol'algorithm!⇒Lsol-algo,
* McsEngl.Lsol-algo,
description::
The-architecture of the-machine that will-execute smart-contracts is that of a-stack-virtual-machine.
[hmnSngo.2017-03-14]
description::
Contracts have state and functions.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
description::
· Lsol-program is an independent Lsol-algo (not a-library).
[hmnSngo.2019-06-27]
name::
* McsEngl.Lsol'program!⇒Lsol-program,
* McsEngl.Lsol'smart-contract!⇒Lsol-program,
* McsEngl.Lsol-program,
description::
A contract in the sense of Solidity is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.9aab3b86]
description::
Solidity defines an assembly language that can also be used without Solidity.
This assembly language can also be used as “inline assembly” inside Solidity source code.
We start with describing how to use inline assembly and how it differs from standalone assembly and then specify assembly itself.
TODO: Write about how scoping rules of inline assembly are a bit different and the complications that arise when for example using internal functions of libraries. Furhermore, write about the symbols defined by the compiler.
[https://solidity.readthedocs.io/en/v0.4.9/assembly.html]
name::
* McsEngl.Lsol-algo.assembly!⇒Lsol-asm,
* McsEngl.Lsol-asm,
description::
The assembly language described as inline assembly above can also be used standalone and in fact, the plan is to use it as an intermediate language for the Solidity compiler.
In this form, it tries to achieve several goals:
- Programs written in it should be readable, even if the code is generated by a compiler from Solidity.
- The translation from assembly to bytecode should contain as few “surprises” as possible.
- Control flow should be easy to detect to help in formal verification and optimization.
[https://solidity.readthedocs.io/en/v0.4.9/assembly.html#standalone-assembly]
description::
· with the-Solidity-source-language we write Solidity-source-algorithms which are-translated to Evm-bytecode and executed by the-Evm.
name::
* McsEngl.Lsol'contract-algo,
* McsEngl.Lsol'contract-sourcecode,
* McsEngl.Lsol'sourcecode-algo,
* McsEngl.Lsol-algo.sourcecode,
* McsEngl.Lsol-source-algo,
* McsEngl.lagSolscd,
* McsEngl.lagSolscp, {2017-03-14},
codeLsol::
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html]
//simple contract
pragma solidity ^0.4.0;
contract SimpleStorage {
uint storedData;
function set(uint x) {
storedData = x;
}
function get() constant returns (uint) {
return storedData;
}
}
description::
· the-units are Unicode-chars.
name::
* McsEngl.Lsol'semantic-unit!⇒Lsol-sunt,
* McsEngl.Lsol'type!⇒Lsol-sunt,
* McsEngl.Lsol-sunt,
* McsEngl.lagSolsut!⇒Lsol-sunt,
description::
// Data locations: Memory vs. storage vs. stack - all complex types (arrays,
// structs) have a data location
// 'memory' does not persist, 'storage' does
// Default is 'storage' for local and state variables; 'memory' for func params
// stack holds small local variables
// for most types, can explicitly set which data location to use
[https://learnxinyminutes.com/docs/solidity/]
description::
Since Solidity knows two kinds of function calls (internal ones that do not create an actual EVM call (also called a “message call”) and external ones that do), there are four types of visibilities for functions and state variables.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
name::
* McsEngl.Lsol'visibility-attribute,
* McsEngl.Lsol-sunt'access,
description::
public:
Public functions are part of the contract interface and can be either called internally or via messages.
For public state variables, an automatic getter function (see below) is generated.
...
Functions can be specified as being external, public, internal or private, where the default is public.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
===
The keyword public automatically generates a function that allows you to access the current value of the state variable. Without this keyword, other contracts have no way to access the variable. The function will look something like this:
function minter() returns (address) { return minter; }
Of course, adding a function exactly like that will not work because we would have a function and a state variable with the same name, but hopefully, you get the idea - the compiler figures that out for you.
... The getter function created by the public keyword is a bit more complex in this case. It roughly looks like the following:
function balances(address _account) returns (uint) {
return balances[_account];
}
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.6258fe71]
===
'public' makes externally readable (not writeable) by users or contracts
[https://learnxinyminutes.com/docs/solidity/]
description::
private:
Private functions and state variables are only visible for the contract they are defined in and not in derived contracts.
Note
Everything that is inside a contract is visible to all external observers. Making something private only prevents other contracts from accessing and modifying the information, but it will still be visible to the whole world outside of the blockchain.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
===
"private" means that other contracts can't directly query balances [sut] but data is still viewable to other parties on blockchain
[https://learnxinyminutes.com/docs/solidity/]
description::
external:
External functions are part of the contract interface, which means they can be called from other contracts and via transactions.
An external function f cannot be called internally (i.e. f() does not work, but this.f() works).
External functions are sometimes more efficient when they receive large arrays of data.
...
For state variables, external is not possible and the default is internal.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
description::
internal:
Those functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it), without using this.
...
For state variables, external is not possible and the default is internal.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
description::
Notice that _from and _to have an additional attribute indexed.
This attribute causes those arguments to be treated as log topics, rather than data.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
description::
Types are checked at compile-time, so if you make a mistake you will get a compiler error. For example, this is not possible:
contract Test {
bool bVar;
function causesError(address addr){
bVar = addr;
}
}
The error it would throw is this: Error: Type address not implicitly convertible to expected type bool.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
description::
Type conversion
The compiler allows you to convert between types in certain cases. Let’s say you have the number 1 stored in a uint variable, and you want to use it in another variable of type int. That is possible - but you generally have to do the conversion yourself. This is how you would do it:
uint x = 1;
int y = int(x);
Type conversion is also checked at compile time and will generally be caught but there are exceptions; the most important one is when converting an address to a contract type. These type of casts can lead to bugs. We will be looking at some examples in a later section.
Finally, type conversion is something that should be used with care. It’s good in some cases, but excessive and/or careless casting is usually a sign that the code is not well written and can sometimes have bad consequences (such as data-loss). Remember types are there for a reason.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
name::
* ethsolsut.specific,
* McsEngl.Lsol-sunt.specific,
specific::
* address - ad,
* array - a,
* boolean - b,
* bytes - bt,
* contract - c,
* enum - en,
* event - e,
* function - f,
* library - l,
* mapping - m,
* number:
- int,
- int8,
- uint,
- uint8,
* string - s,
* struct - sc,
===
* REFERENCY-TYPE,
* VALUE-TYPE,
* NAME-VALUE-PAIR,
* API,
* JSON-INTERFACE,
description::
Reference Types
Complex types, i.e. types which do not always fit into 256 bits have to be handled more carefully than the value-types we have already seen.
Since copying them can be quite expensive, we have to think about whether we want them to be stored in memory (which is not persisting) or storage (where the state variables are held).
- array
- stuct
[http://solidity.readthedocs.io/en/v0.4.9/types.html#reference-types]
name::
* McsEngl.Lsol'reference-type,
description::
Data location
Every complex type, i.e. arrays and structs, has an additional annotation, the “data location”, about whether it is stored in memory or in storage. Depending on the context, there is always a default, but it can be overridden by appending either storage or memory to the type. The default for function parameters (including return parameters) is memory, the default for local variables is storage and the location is forced to storage for state variables (obviously).
There is also a third data location, “calldata”, which is a non-modifyable non-persistent area where function arguments are stored. Function parameters (not return parameters) of external functions are forced to “calldata” and it behaves mostly like memory.
Data locations are important because they change how assignments behave: Assignments between storage and memory and also to a state variable (even from other state variables) always create an independent copy. Assignments to local storage variables only assign a reference though, and this reference always points to the state variable even if the latter is changed in the meantime. On the other hand, assignments from a memory stored reference type to another memory-stored reference type does not create a copy.
[http://solidity.readthedocs.io/en/v0.4.9/types.html#data-location]
===
* storage
* memory
* calldata
description::
Value Types
The following types are also called value types because variables of these types will always be passed by value, i.e. they are always copied when they are used as function arguments or in assignments.
- Booleans
- Integers
- Address
- Fixed-size byte arrays
- Dynamically-sized byte arrays
- Fixed point numbers
- Address-literals
- Rational and integer literals
- String literals
- Hexadecimal literals
- Enums
- Function types
[http://solidity.readthedocs.io/en/v0.4.9/types.html#value-types]
description::
Represents an-ethereum-account-address.
===
The address type is a 160-bit value that does not allow any arithmetic operations.
It is suitable for storing addresses of contracts or keypairs belonging to external persons.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.6258fe71]
===
address which is a cryptographic hash (SHA3)
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
address: Holds a 20 byte value (size of an Ethereum address).
Address types also have members(see [Functions on addresses](#functions-on-addresses)) and serve as base for all contracts.
Operators:
<=, <, ==, !=, >= and >
[https://solidity.readthedocs.org/en/latest/types.html#address]
===
// Addresses - holds 20 byte/160 bit Ethereum addresses
// No arithmetic allowed
address public owner;
// Types of accounts:
// Contract account: address set on create (func of creator address, num transactions sent)
// External Account: (person/external entity): address created from public key
// Add 'public' field to indicate publicly/externally accessible
// a getter is automatically created, but NOT a setter
// All addresses can be sent ether
owner.send(SOME_BALANCE); // returns false on failure
if (owner.send) {} // REMEMBER: wrap in 'if', as contract addresses have
// functions executed on send and these can fail
// Also, make sure to deduct balances BEFORE attempting a send, as there is a risk of a recursive
// call that can drain the contract
// can override send by defining your own
// Can check balance
owner.balance; // the balance of the owner (user or contract)
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol'address!⇒Lsolad,
* McsEngl.Lsol-sunt.address!⇒Lsolad,
* McsEngl.lagSoladdress!⇒Lsolad,
* McsEngl.Lsolad,
description::
It is possible to query the balance of an address using the property balance and to send Ether (in units of wei) to an address using the send function:
address x = 0x123;
address myAddress = this;
if (x.balance < 10 && myAddress.balance >= 10) x.send(10);
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
description::
Furthermore, to interface with contracts that do not adhere to the ABI, the function call is provided which takes an arbitrary number of arguments of any type. These arguments are padded to 32 bytes and concatenated. One exception is the case where the first argument is encoded to exactly four bytes. In this case, it is not padded to allow the use of function signatures here.
address nameReg = 0x72ba7d8e73fe8eb666ea66babc8116a41bfb10e2;
nameReg.call("register", "MyName");
nameReg.call(bytes4(keccak256("fun(uint256)")), a);
call returns a boolean indicating whether the invoked function terminated (true) or caused an EVM exception (false). It is not possible to access the actual data returned (for this we would need to know the encoding and size in advance).
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
description::
It is possible to query the balance of an address using the property balance and to send Ether (in units of wei) to an address using the send function:
address x = 0x123;
address myAddress = this;
if (x.balance < 10 && myAddress.balance >= 10) x.send(10);
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
description::
// Arrays
bytes32[5] nicknames; // static array
bytes32[] names; // dynamic array
uint newLength = names.push("John"); // adding returns new length of the array
// Length
names.length; // get length
names.length = 1; // lengths can be set (for dynamic arrays in storage only)
// multidimensional array
uint x[][5]; // arr with 5 dynamic array elements (opp order of most languages)
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol-sunt.array!⇒Lsola,
* McsEngl.Lsola,
* McsEngl.lagSola!⇒Lsola,
* McsEngl.lagSolarray!⇒Lsola,
name::
* McsEngl.Lsol-sunt!⇒Lsolb,
* McsEngl.Lsolb,
* McsEngl.lagSolb!⇒Lsolb,
codeLsol::
bool voted;
===
bool b = true; // or do 'var b = true;' for inferred typing
description::
Variables of type bytes and string are special arrays.
A bytes is similar to byte[], but it is packed tightly in calldata.
string is equal to bytes but does not allow length or index access (for now).
So bytes should always be preferred over byte[] because it is cheaper.
[http://solidity.readthedocs.io/en/v0.4.9/types.html#index-14]
===
// Bytes available from 1 to 32
byte a; // byte is same as bytes1
bytes2 b;
bytes32 c;
// Dynamically sized bytes
bytes m; // A special array, same as byte[] array (but packed tightly)
// More expensive than byte1-byte32, so use those when possible
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol'bytes-type!⇒Lsolbt,
* McsEngl.Lsol-sunt.bytes!⇒Lsolbt,
* McsEngl.Lsolbt,
* McsEngl.lagSolbytes!⇒Lsolbt,
* McsEngl.lagSolbt!⇒Lsolbt,
description::
Solidity uses the contract data-type to model smart contracts. It is very similar to a class.
A contract has a number of fields and methods; for example, the contract type can have a constructor, it can inherit from other contracts, etc.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
Contracts in Solidity are similar to classes in object-oriented languages.
Each contract can contain declarations of State Variables, Functions, Function Modifiers, Events, Structs Types and Enum Types.
Furthermore, contracts can inherit from other contracts.
[https://solidity.readthedocs.io/en/v0.4.9/structure-of-a-contract.html]
name::
* McsEngl.Lsol'contract-semantic-unit!⇒Lsolc,
* McsEngl.Lsol'contract-datatype!⇒Lsolc,
* McsEngl.Lsol-sunt.contract!⇒Lsolc,
* McsEngl.Lsolc,
* McsEngl.lagSolc!⇒Lsolc,
* McsEngl.Solidity-contract-datatype!⇒Lsolc,
* McsEngl.Sldtc!⇒Lsolc,
example::
* https://github.com/fivedogit/solidity-baby-steps,
description::
State Machine
Contracts often act as a state machine, which means that they have certain stages in which they behave differently or in which different functions can be called. A function call often ends a stage and transitions the contract into the next stage (especially if the contract models interaction). It is also common that some stages are automatically reached at a certain point in time.
An example for this is a blind auction contract which starts in the stage “accepting blinded bids”, then transitions to “revealing bids” which is ended by “determine auction autcome”.
Function modifiers can be used in this situation to model the states and guard against incorrect usage of the contract.
[https://solidity.readthedocs.org/en/latest/common-patterns.html#state-machine]
codeLsol::
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#function-modifiers]
contract owned {
function owned() { owner = msg.sender; }
address owner;
// This contract only defines a modifier but does not use
// it - it will be used in derived contracts.
// The function body is inserted where the special symbol
// "_;" in the definition of a modifier appears.
// This means that if the owner calls this function, the
// function is executed and otherwise, an exception is
// thrown.
modifier onlyOwner {
if (msg.sender != owner)
throw;
_;
}
}
contract mortal is owned {
// This contract inherits the "onlyOwner"-modifier from
// "owned" and applies it to the "close"-function, which
// causes that calls to "close" only have an effect if
// they are made by the stored owner.
function close() onlyOwner {
selfdestruct(owner);
}
}
description::
Contract functions can lack an implementation as in the following example (note that the function declaration header is terminated by ;):
pragma solidity ^0.4.0;
contract Feline {
function utterance() returns (bytes32);
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#abstract-contracts]
description::
Enums are one way to create a user-defined type in Solidity.
They are explicitly convertible to and from all integer types but implicit conversion is not allowed.
[https://solidity.readthedocs.org/en/latest/types.html#enums]
name::
* McsEngl.Lsol-sunt.enum!⇒Lsolen,
* McsEngl.Lsolen,
* McsEngl.lagSolen!⇒Lsolen,
* McsEngl.lagSolenum!⇒Lsolen,
codeLsol::
enum ActionChoices { GoLeft, GoRight, GoStraight, SitStill }
===
enum Status {maintenance, active, suspended, bankrupt}
===
// Enums
enum State { Created, Locked, Inactive }; // often used for state machine
State public state; // Declare variable from enum
state = State.Created;
// enums can be explicitly converted to ints
uint createdState = uint(State.Created); // 0
[https://learnxinyminutes.com/docs/solidity/]
description::
Events are used to dump information from Solidity contract code into the blockchain clients log. It is a way of making that information available to the “outside world”. On top of the events themselves, most clients also have a way of capturing this output and encapsulating it in an event data-structures. This is particularly important for efficiency between the blockchain clients and the “outside world” which will rely upon these events in order for other things to happen.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
event Transfer(address indexed _from, address indexed _to, uint256 _value);
Next we specify an event, which is how in Solidity we use the logging facility of the Ethereum Virtual Machine. When called, events cause the arguments to be stored in the transaction’s log. In this instance we are storing three parameters, _from which is of type address, _to_ which is another address, and _value which is a uint256 (256-bit unsigned integer). Notice that _from and _to have an additional attribute indexed. This attribute causes those arguments to be treated as log topics, rather than data.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
The line event Sent(address from, address to, uint amount); declares a so-called “event” which is fired in the last line of the function send. User interfaces (as well as server appliances of course) can listen for those events being fired on the blockchain without much cost.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
name::
* McsEngl.Lsol'event!⇒Lsole,
* McsEngl.Lsol-sunt.event!⇒Lsole,
* McsEngl.Lsole,
* McsEngl.lagSole,
codeLsol::
// Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount);
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
codeLsol::
[https://learnxinyminutes.com/docs/solidity/]
// B. Events
// Events are notify external parties; easy to search and
// access events from outside blockchain (with lightweight clients)
// typically declare after contract parameters
// Typically, capitalized - and add Log in front to be explicit and prevent confusion
// with a function call
// Declare
event LogSent(address indexed from, address indexed to, uint amount); // note capital first letter
// Call
Sent(from, to, amount);
// For an external party (a contract or external entity), to watch:
Coin.Sent().watch({}, '', function(error, result) {
if (!error) {
console.log("Coin transfer: " + result.args.amount +
" coins were sent from " + result.args.from +
" to " + result.args.to + ".");
console.log("Balances now:\n" +
"Sender: " + Coin.balances.call(result.args.from) +
"Receiver: " + Coin.balances.call(result.args.to));
}
}
// Common paradigm for one contract to depend on another (e.g., a
// contract that depends on current exchange rate provided by another)
name::
* McsEngl.Lsol'function'Lsolf,
* McsEngl.Lsol-sunt'Lsolf,
* McsEngl.Lsolf,
* McsEngl.lagSolf!⇒Lsolf,
* McsEngl.Solidity-function!⇒Lsolf,
* McsEngl.Sldtf!⇒Lsolf,
description::
// Functions can return many arguments, and by specifying returned arguments
// name don't need to explicitly return
function increment(uint x, uint y) returns (uint x, uint y) {
x += 1;
y += 1;
}
// Call previous functon
uint (a,b) = increment(1,1);
[https://learnxinyminutes.com/docs/solidity/]
description::
Since Solidity knows two kinds of function calls (internal ones that do not create an actual EVM call (also called a “message call”) and external ones that do), there are four types of visibilities for functions and state variables.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
JSON::
{
"constant": true,
"inputs": [ { "name": "", "type": "address" } ],
"name": "versions",
"outputs": [ { "name": "", "type": "uint256" } ],
"payable": false,
"type": "function"
}
===
{
"payable": false,
"type": "fallback"
}
name::
* ethsolf.specific,
* McsEngl.lagSolf.specific,
specific::
ethsolf.addmod(uint x, uint y, uint k) returns (uint):
compute (x + y) % k where the addition is performed with arbitrary precision and does not wrap around at 2**256.
ethsolf.mulmod(uint x, uint y, uint k) returns (uint):
compute (x * y) % k where the multiplication is performed with arbitrary precision and does not wrap around at 2**256.
ethsolf.sha3(...) returns (bytes32):
compute the Ethereum-SHA-3 hash of the (tightly packed) arguments
ethsolf.sha256(...) returns (bytes32):
compute the SHA-256 hash of the (tightly packed) arguments
ethsolf.ripemd160(...) returns (bytes20):
compute RIPEMD-160 hash of the (tightly packed) arguments
ethsolf.ecrecover(bytes32, uint8, bytes32, bytes32) returns (address):
recover public key from elliptic curve signature - arguments are (data, v, r, s)
[https://solidity.readthedocs.org/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions]
description::
a special function which is a constructor, denoted by the function having the same name as the contract itself. Generally constructors are used to initialize contract member variables to their initial state once the contract has been deployed.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
==
The special function Coin is the constructor which is run during creation of the contract and cannot be called afterwards.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
description::
Constant Functions
Functions can be declared constant. These functions promise not to modify the state.
pragma solidity ^0.4.0;
contract C {
function f(uint a, uint b) constant returns (uint) {
return a * (b + 42);
}
}
Note
Getter methods are marked constant.
Warning
The compiler does not enforce yet that a constant method is not modifying state.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#constant-functions]
===
What is the difference between a function marked constant and one that is not?
constant functions can perform some action and return a value, but cannot change state (this is not yet enforced by the compiler). In other words, a constant function cannot save or update any variables within the contract or wider blockchain. These functions are called using c.someFunction(...) from geth or any other web3.js environment.
“non-constant” functions (those lacking the constant specifier) must be called with c.someMethod.sendTransaction({from:eth.accounts[x], gas: 1000000}); That is, because they can change state, they have to have a gas payment sent along to get the work done.
[https://solidity.readthedocs.org/en/latest/frequently-asked-questions.html#what-is-the-difference-between-a-function-marked-constant-and-one-that-is-not]
description::
What is the difference between a function marked constant and one that is not?
constant functions can perform some action and return a value, but cannot change state (this is not yet enforced by the compiler). In other words, a constant function cannot save or update any variables within the contract or wider blockchain. These functions are called using c.someFunction(...) from geth or any other web3.js environment.
“non-constant” functions (those lacking the constant specifier) must be called with c.someMethod.sendTransaction({from:eth.accounts[x], gas: 1000000}); That is, because they can change state, they have to have a gas payment sent along to get the work done.
[https://solidity.readthedocs.org/en/latest/frequently-asked-questions.html#what-is-the-difference-between-a-function-marked-constant-and-one-that-is-not]
description::
internal:
Those functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it), without using this.
description::
Fallback Function
A contract can have exactly one unnamed function. This function cannot have arguments and cannot return anything. It is executed on a call to the contract if none of the other functions matches the given function identifier (or if no data was supplied at all).
Furthermore, this function is executed whenever the contract receives plain Ether (without data). In such a context, there is usually very little gas available to the function call (to be precise, 2300 gas), so it is important to make fallback functions as cheap as possible.
In particular, the following operations will consume more gas than the stipend provided to a fallback function:
Writing to storage
Creating a contract
Calling an external function which consumes a large amount of gas
Sending Ether
Please ensure you test your fallback function thoroughly to ensure the execution cost is less than 2300 gas before deploying a contract.
Warning
Contracts that receive Ether but do not define a fallback function throw an exception, sending back the Ether (this was different before Solidity v0.4.0). So if you want your contract to receive Ether, you have to implement a fallback function.
pragma solidity ^0.4.0;
contract Test {
// This function is called for all messages sent to
// this contract (there is no other function).
// Sending Ether to this contract will cause an exception,
// because the fallback function does not have the "payable"
// modifier.
function() { x = 1; }
uint x;
}
// This contract keeps all Ether sent to it with no way
// to get it back.
contract Sink {
function() payable { }
}
contract Caller {
function callTest(Test test) {
test.call(0xabcdef01); // hash does not exist
// results in test.x becoming == 1.
// The following call will fail, reject the
// Ether and return false:
test.send(2 ether);
}
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#fallback-function]
description::
Modifiers can be used to easily change the behaviour of functions, for example to automatically check a condition prior to executing the function. They are inheritable properties of contracts and may be overridden by derived contracts.
pragma solidity ^0.4.0;
contract owned {
function owned() { owner = msg.sender; }
address owner;
// This contract only defines a modifier but does not use
// it - it will be used in derived contracts.
// The function body is inserted where the special symbol
// "_;" in the definition of a modifier appears.
// This means that if the owner calls this function, the
// function is executed and otherwise, an exception is
// thrown.
modifier onlyOwner {
if (msg.sender != owner)
throw;
_;
}
}
contract mortal is owned {
// This contract inherits the "onlyOwner"-modifier from
// "owned" and applies it to the "close"-function, which
// causes that calls to "close" only have an effect if
// they are made by the stored owner.
function close() onlyOwner {
selfdestruct(owner);
}
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#function-modifiers]
===
// Modifiers validate inputs to functions such as minimal balance or user auth;
// similar to guard clause in other languages
// '_' (underscore) often included as last line in body, and indicates
// function being called should be placed there
modifier onlyAfter(uint _time) { if (now <= _time) throw; _ }
modifier onlyOwner { if (msg.sender == owner) _ }
// commonly used with state machines
modifier onlyIfState (State currState) { if (currState != State.A) _ }
// Append right after function declaration
function changeOwner(newOwner)
onlyAfter(someTime)
onlyOwner()
onlyIfState(State.A)
{
owner = newOwner;
}
// underscore can be included before end of body,
// but explicitly returning will skip, so use carefully
modifier checkValue(uint amount) {
_
if (msg.value > amount) {
uint amountToRefund = amount - msg.value;
if (!msg.sender.send(amountToRefund)) {
throw;
}
}
}
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.lagSolf.modifier,
* McsEngl.Lsol'modifier-function,
description::
// 3. Simple operators
// Comparisons, bit operators and arithmetic operators are provided
// exponentiation: **
// exclusive or: ^
// bitwise negation: ~
[https://learnxinyminutes.com/docs/solidity/]
description::
In Solidity, the command for removing (or suiciding) a contract is this: selfdestruct(addr).
The argument here is the address to which any remaining funds should be sent.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
ether sent to selfdestructed contract is lost
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol'selfdestruct,
* McsEngl.lagSolselfdestruct,
description::
Libraries are similar to contracts, but their purpose is that they are deployed only once at a specific address and their code is reused using the DELEGATECALL (CALLCODE until Homestead) feature of the EVM. This means that if library functions are called, their code is executed in the context of the calling contract, i.e. this points to the calling contract, and especially the storage from the calling contract can be accessed. As a library is an isolated piece of source code, it can only access state variables of the calling contract if they are explicitly supplied (it would have no way to name them, otherwise).
...
Restrictions for libraries in comparison to contracts:
No state variables
Cannot inherit nor be inherited
Cannot recieve Ether
(These might be lifted at a later point.)
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#libraries]
name::
* McsEngl.Lsol'library!⇒Lsoll,
* McsEngl.Lsol-sunt.library!⇒Lsoll,
* McsEngl.Lsoll,
* McsEngl.lagSoll!⇒Lsoll,
* McsEngl.lagSollibrary!⇒Lsoll,
description::
A mapping is a relational type, from keys to values,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
Mapping types are declared as mapping _KeyType => _ValueType, where _KeyType can be almost any type except for a mapping and _ValueType can actually be any type, including mappings.
Mappings can be seen as hashtables which are virtually initialized such that every possible key exists and is mapped to a value whose byte-representation is all zeros. The similarity ends here, though: The key data is not actually stored in a mapping, only its sha3 hash used to look up the value.
Because of this, mappings do not have a length or a concept of a key or value being “set”.
Mappings are only allowed for state variables (or as storage reference types in internal functions).
[https://solidity.readthedocs.org/en/latest/types.html#mappings]
===
// Dictionaries (any type to any other type)
mapping (string => uint) public balances;
balances["charles"] = 1;
console.log(balances["ada"]); // is 0, all non-set key values return zeroes
// 'public' allows following from another contract
contractName.balances("charles"); // returns 1
// 'public' created a getter (but not setter) like the following:
function balances(string _account) returns (uint balance) {
return balances[_account];
}
// Nested mappings
mapping (address => mapping (address => uint)) public custodians;
// To delete
delete balances["John"];
delete balances; // sets all elements to 0
// Unlike other languages, CANNOT iterate through all elements in
// mapping, without knowing source keys - can build data structure
// on top to do this
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol'dictionary!⇒Lsolm,
* McsEngl.Lsol'mapping!⇒Lsolm,
* McsEngl.Lsol-sunt.mapping!⇒Lsolm,
* McsEngl.lagSolm!⇒Lsolm,
name::
* McsEngl.Lsol-sunt.number!⇒Lsoln,
* McsEngl.Lsoln,
* McsEngl.lagSoln!⇒Lsoln,
description::
Integers in Solidity can be either signed or unsigned, and can be on the form intN/uintN, where N = 8*n for n = 1, 2, ... , 32. Some examples would be uint8, int32, int128, and uint240. Additionally, int and uint are shorthand for int256 and uint256, respectively.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-14-advanced-solidity-V.md]
===
int• / uint•: Signed and unsigned integers of various sizes. Keywords uint8 to uint256 in steps of 8 (unsigned of 8 up to 256 bits) and int8 to int256. uint and int are aliases for uint256 and int256, respectively.
Operators:
Comparisons: <=, <, ==, !=, >=, > (evaluate to bool)
Bit operators: &, |, ^ (bitwise exclusive or), ~ (bitwise negation)
Arithmetic operators: +, -, unary -, unary +, *, /, % (remainder), ** (exponentiation)
Division always truncates (it just maps to the DIV opcode of the EVM), but it does not truncate if both operators are literals (or literal expressions).
[https://solidity.readthedocs.org/en/latest/types.html#integers]
name::
* McsEngl.Lsol'integer,
* McsEngl.Lsol-sunt.integer-number,
* McsEngl.lagSolinteger,
description::
uint storedData;
//The line uint storedData; declares a state variable called storedData of type uint (unsigned integer of 256 bits).
===
uint used for currency amount (there are no doubles or floats) and for dates (in unix time)
...
uint constant VERSION_ID = 0x123A1; // A hex constant
[https://learnxinyminutes.com/docs/solidity/]
description::
// Currency units
// Currency is defined using wei, smallest unit of Ether
uint minAmount = 1 wei;
uint a = 1 finney; // 1 ether == 1000 finney
// Other units, see: http://ether.fund/tool/converter
// Time units
1 == 1 second
1 minutes == 60 seconds
// Can multiply a variable times unit, as units are not stored in a variable
uint x = 5;
(x * 1 days); // 5 days
// Careful about leap seconds/years with equality statements for time
// (instead, prefer greater than/less than)
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol'unit-of-measurement,
* McsEngl.Lsol.sunt.unit-of-measurement,
description::
// same as bytes, but does not allow length or index access (for now)
string n = "hello"; // stored in UTF8, note double quotes, not single
// string utility functions to be added in future
// prefer bytes32/bytes, as UTF8 uses more storage
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol'string!⇒Lsols,
* McsEngl.Lsol-sunt.string!⇒Lsols,
* McsEngl.Lsols,
* McsEngl.lagSols,
* McsEngl.lagSolstring,
description::
// Structs and enums
struct Bank {
address owner;
uint balance;
}
Bank b = Bank({
owner: msg.sender,
balance: 5
});
// or
Bank c = Bank(msg.sender, 5);
c.amount = 5; // set to new value
delete b;
// sets to initial value, set all variables in struct to 0, except mappings
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol'struct!⇒Lsolsc,
* McsEngl.Lsol-sunt.struct!⇒Lsolsc,
* McsEngl.Lsolsc,
* McsEngl.lagSolsc!⇒Lsolsc,
* McsEngl.lagSolstruct!⇒Lsolsc,
codeLsol::
// Defines a new type with two fields.
struct Funder {
address addr;
uint amount;
}
description::
Solidity is a strongly-typed language which means that variables must have a type given to them.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.Lsol'name-value-pair!⇒Lsolv,
* McsEngl.Lsol'variable!⇒Lsolv,
* McsEngl.Lsol-sunt.variable!⇒Lsolv,
* McsEngl.lagSolv!⇒Lsolv,
* McsEngl.lagSolvariable!⇒Lsolv,
codeLsol::
address public minter;
// declares a state variable of type address that is publicly accessible.
===
mapping (address => uint) balances;
description::
// by default, all values are set to 0 on instantiation
[https://learnxinyminutes.com/docs/solidity/]
description::
The Ethereum Virtual Machine has three areas where it can store items.
The first is “storage”, where all the contract state variables reside.
Every contract has its own storage and it is persistent between function calls and quite expensive to use.
[http://solidity.readthedocs.io/en/develop/frequently-asked-questions.html#what-is-the-memory-keyword-what-does-it-do]
===
contract Test {
int a = 999; // That's storage
function doIt() {
int b; // That's memory
assembly {
b := sload(a);
}
}
}
[http://ethereum.stackexchange.com/a/11677]
===
The Ethereum Virtual Machine has three areas where it can store items. ...
The third one is the stack, which is used to hold small local variables. It is almost free to use, but can only hold a limited amount of values.
...
local variables always reference storage
...
A common mistake is to declare a local variable and assume that it will be created in memory, although it will be created in storage:
[http://solidity.readthedocs.io/en/develop/frequently-asked-questions.html#what-is-the-memory-keyword-what-does-it-do]
name::
* McsEngl.Lsol'local-variable,
* McsEngl.Lsol'state-variable,
* McsEngl.Lsol'storage-variable,
* McsEngl.lagSolv.local,
description::
contract Test {
int a = 999; // That's storage
function doIt() {
int b; // That's memory
assembly {
b := sload(a);
}
}
}
[http://ethereum.stackexchange.com/a/11677]
name::
* McsEngl.Lsol'memory-variable,
* McsEngl.lagSolv.memory,
description::
// Type inferrence
// var does inferred typing based on first assignment,
// can't be used in functions parameters
var a = true;
// use carefully, inference may provide wrong type
// e.g., an int8, when a counter needs to be int16
// var can be used to assign function to variable
function a(uint x) returns (uint) {
return x * 2;
}
var f = a;
f(22); // call
[https://learnxinyminutes.com/docs/solidity/]
description::
Constant State Variables
State variables can be declared as constant (this is not yet implemented for array and struct types and not possible for mapping types).
pragma solidity ^0.4.0;
contract C {
uint constant x = 32**22 + 8;
string constant text = "abc";
}
This has the effect that the compiler does not reserve a storage slot for these variables and every occurrence is replaced by their constant value.
The value expression can only contain integer arithmetics.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#constant-functions]
===
uint constant VERSION_ID = 0x123A1; // A hex constant
// with 'constant', compiler replaces each occurrence with actual value
[https://learnxinyminutes.com/docs/solidity/]
description::
msg (together with tx and block) is a magic global variable that contains some properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
name::
* McsEngl.Lsol'global-variable,
* McsEngl.lagSolv.global,
specific::
* block ##
* msg ##
* now ##
* this ##
* tx ##
description::
// this
this; // address of contract
// often used at end of contract life to send remaining balance to party
this.balance;
this.someFunction(); // calls func externally via call, not via internal jump
[https://learnxinyminutes.com/docs/solidity/]
API::
block.blockhash(uint blockNumber) returns (bytes32): hash of the given block - only works for 256 most recent blocks excluding current
block.coinbase (address): current block miner’s address
block.difficulty (uint): current block difficulty
block.gaslimit (uint): current block gaslimit
block.number (uint): current block number
block.timestamp (uint): current block timestamp
[http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties]
===
// ** block - Information about current block **
now; // current time (approximately), alias for block.timestamp (uses Unix time)
block.number; // current block number
block.difficulty; // current block difficulty
block.blockhash(1); // returns bytes32, only works for most recent 256 blocks
block.gasLimit();
[https://learnxinyminutes.com/docs/solidity/]
description::
msg (together with tx and block) is a magic global variable that contains some properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
===
// ** msg - Current message received by the contract ** **
msg.sender; // address of sender
msg.value; // amount of ether provided to this contract in wei
msg.data; // bytes, complete call data
msg.gas; // remaining gas
[https://learnxinyminutes.com/docs/solidity/]
API::
msg.data (bytes): complete calldata
msg.gas (uint): remaining gas
msg.sender (address): sender of the message (current call)
msg.sig (bytes4): first four bytes of the calldata (i.e. function identifier)
msg.value (uint): number of wei sent with the message
[http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties]
API::
tx.gasprice (uint): gas price of the transaction
tx.origin (address): sender of the transaction (full call chain)
[http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties]
description::
// ** storage - Persistent storage hash **
storage['abc'] = 'def'; // maps 256 bit words to 256 bit words
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol-sunt.API,
* McsEngl.lagSolAPI,
eth-solapi.msg.sender:
special variable msg.sender, which is, intuitively, the address of the message sender.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
eth-solapi.tx.origin:
Here we use a special variable called tx.origin which is of type address and contains the sender of the transaction,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
description::
The-interface of the-functions of a-contract in JSON-format.
===
[
{
"constant": true,
"inputs": [],
"name": "t32Hash_of_will",
"outputs": [ { "name": "", "type": "bytes32", "value": "0x0000000000000000000000000000000000000000000000000000000000000000", "displayName": "" } ],
"type": "function",
"displayName": "t32 Hash<span class=\"punctuation\">_</span>of<span class=\"punctuation\">_</span>will"
},
{
"constant": false,
"inputs": [ { "name": "sWillIn", "type": "string", "typeShort": "string", "bits": "", "displayName": "s Will In", "template": "elements_input_string" } ],
"name": "fWillNew",
"outputs": [],
"type": "function",
"displayName": "f Will New"
},
{
"constant": true,
"inputs": [],
"name": "aWill_owner",
"outputs": [ { "name": "", "type": "address", "value": "0x0998c9a0c7224ec2ed782a3ecfef53a0e25fa9fc", "displayName": "" } ],
"type": "function",
"displayName": "a Will<span class=\"punctuation\">_</span>owner"
},
{ "constant": true, "inputs": [ { "name": "sWillUserIn", "type": "string", "typeShort": "string", "bits": "", "displayName": "s Will User In", "template": "elements_input_string" } ], "name": "fWillCheck", "outputs": [ { "name": "bWill_correct", "type": "bool" } ],
"type": "function", "displayName": "f Will Check"
},
{
"inputs": [],
"type": "constructor"
}
]
name::
* McsEngl.ABI.ethsol,
* McsEngl.Lsol'ABI,
* McsEngl.Lsol'JSON-interface,
* McsEngl.Lsol-sunt.ABI,
* McsEngl.lagSolscpsut.ABI,
name::
* McsEngl.lagSolstc!⇒Lsol-sentence,
* McsEngl.Lsol'sentence!⇒Lsol-sentence,
* McsEngl.Lsol-sentence,
description::
// Destructuring/Tuples
(x, y) = (2, 7); // assign/swap multiple value
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol-sentence.assignment,
* McsEngl.Lsol'assignment-sentence,
name::
* McsEngl.Lsol-sentence.branching,
codeLsol::
// 6. BRANCHING AND LOOPS
// All basic logic blocks work - including if/else, for, while, break, continue
// return - but no switch
// Syntax same as javascript, but no type conversion from non-boolean
// to boolean (comparison operators must be used to get the boolean val)
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol-sentence.loop,
codeLsol::
[https://learnxinyminutes.com/docs/solidity/]
// For loops that are determined by user behavior, be careful - as contracts have a maximal
// amount of gas for a block of code - and will fail if that is exceeded
// For example:
for(uint x = 0; x < refundAddressList.length; x++) {
if (!refundAddressList[x].send(SOME_AMOUNT)) {
throw;
}
}
// Two errors above:
// 1. A failure on send stops the loop from completing, tying up money
// 2. This loop could be arbitrarily long (based on the amount of users who need refunds), and
// therefore may always fail as it exceeds the max gas for a block
// Instead, you should let people withdraw individually from their subaccount, and mark withdrawn
name::
* McsEngl.Lsol'pragma,
* McsEngl.lagSolpragma,
* McsEngl.Lsol-sentence.pragma,
codeLsol::
pragma solidity ^0.4.0;
//The first line simply tells that the source code is written for Solidity version 0.4.0 or anything newer that does not break functionality (up to, but not including, version 0.5.0).
This is to ensure that the contract does not suddenly behave differently with a new compiler version.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.9aab3b86]
description::
Solidity supports import statements that are very similar to those available in JavaScript (from ES6 on), although Solidity does not know the concept of a “default export”.
At a global level, you can use import statements of the following form:
import "filename";
This statement imports all global symbols from “filename” (and symbols imported there) into the current global scope (different than in ES6 but backwards-compatible for Solidity).
import * as symbolName from "filename";
...creates a new global symbol symbolName whose members are all the global symbols from "filename".
import {symbol1 as alias, symbol2} from "filename";
...creates new global symbols alias and symbol2 which reference symbol1 and symbol2 from "filename", respectively.
Another syntax is not part of ES6, but probably convenient:
import "filename" as symbolName;
which is equivalent to import * as symbolName from "filename";.
[https://solidity.readthedocs.io/en/v0.4.9/layout-of-source-files.html#syntax-and-semantics]
name::
* McsEngl.Lsol'import,
* McsEngl.lagSolimport,
description::
Paths
In the above, filename is always treated as a path with / as directory separator, . as the current and .. as the parent directory. When . or .. is followed by a character except /, it is not considered as the current or the parent directory. All path names are treated as absolute paths unless they start with the current . or the parent directory ...
To import a file x from the same directory as the current file, use import "./x" as x;. If you use import "x" as x; instead, a different file could be referenced (in a global “include directory”).
It depends on the compiler (see below) how to actually resolve the paths. In general, the directory hierarchy does not need to strictly map onto your local filesystem, it can also map to resources discovered via e.g. ipfs, http or git.
[https://solidity.readthedocs.io/en/v0.4.9/layout-of-source-files.html#paths]
description::
Using For
The directive using A for B; can be used to attach library functions (from the library A) to any type (B). These functions will receive the object they are called on as their first parameter (like the self variable in Python).
The effect of using A for *; is that the functions from the library A are attached to any type.
In both situations, all functions, even those where the type of the first parameter does not match the type of the object, are attached. The type is checked at the point the function is called and function overload resolution is performed.
The using A for B; directive is active for the current scope, which is limited to a contract for now but will be lifted to the global scope later, so that by including a module, its data types including library functions are available without having to add further code.
Let us rewrite the set example from the Libraries in this way:
pragma solidity ^0.4.0;
// This is the same code as before, just without comments
library Set {
struct Data { mapping(uint => bool) flags; }
function insert(Data storage self, uint value)
returns (bool)
{
if (self.flags[value])
return false; // already there
self.flags[value] = true;
return true;
}
function remove(Data storage self, uint value)
returns (bool)
{
if (!self.flags[value])
return false; // not there
self.flags[value] = false;
return true;
}
function contains(Data storage self, uint value)
returns (bool)
{
return self.flags[value];
}
}
contract C {
using Set for Set.Data; // this is the crucial change
Set.Data knownValues;
function register(uint value) {
// Here, all variables of type Set.Data have
// corresponding member functions.
// The following function call is identical to
// Set.insert(knownValues, value)
if (!knownValues.insert(value))
throw;
}
}
It is also possible to extend elementary types in that way:
pragma solidity ^0.4.0;
library Search {
function indexOf(uint[] storage self, uint value) returns (uint) {
for (uint i = 0; i < self.length; i++)
if (self[i] == value) return i;
return uint(-1);
}
}
contract C {
using Search for uint[];
uint[] data;
function append(uint value) {
data.push(value);
}
function replace(uint _old, uint _new) {
// This performs the library function call
uint index = data.indexOf(_old);
if (index == uint(-1))
data.push(_new);
else
data[index] = _new;
}
}
Note that all library calls are actual EVM function calls. This means that if you pass memory or value types, a copy will be performed, even of the self variable. The only situation where no copy will be performed is when storage reference variables are used.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#using-for]
description::
Single-line comments (//) and multi-line comments (/*...*/) are possible.
// This is a single-line comment.
/*
This is a
multi-line comment.
*/
[https://solidity.readthedocs.io/en/v0.4.9/layout-of-source-files.html#comments]
description::
Errors
There is no real error handling system in Solidity (yet). There are no try - catch or throw statements, or something to that effect. Contract designers need to deal with errors themselves. Solidity does some sanity checks on arrays and such, but will often respond simply by executing the (STOP) instruction. According to the developers, this is just put in as a placeholder until a more sophisticated error handling and recovery system is put in place.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
description::
// 13. STYLE NOTES
// Based on Python's PEP8 style guide
// Quick summary:
// 4 spaces for indentation
// Two lines separate contract declarations (and other top level declarations)
// Avoid extraneous spaces in parentheses
// Can omit curly braces for one line statement (if, for, etc)
// else should be placed on own line
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.Lsol-source-algo.specific,
specific::
* https://github.com/fivedogit/solidity-baby-steps/tree/master/contracts,
* https://github.com/ConsenSys/dapp-store-contracts,
===
As you will see, it is possible to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
[https://solidity.readthedocs.io/en/latest/ 0-4-10.9aab3b86]
name::
* McsEngl.Lsol-source-algo.crowdfunding,
codeLsol::
[https://learnxinyminutes.com/docs/solidity/]
// *** EXAMPLE: A crowdfunding example (broadly similar to Kickstarter) ***
// ** START EXAMPLE **
// CrowdFunder.sol
/// @title CrowdFunder
/// @author nemild
contract CrowdFunder {
// Variables set on create by creator
address public creator;
address public fundRecipient; // creator may be different than recipient
uint public minimumToRaise; // required to tip, else everyone gets refund
string campaignUrl;
byte constant version = 1;
// Data structures
enum State {
Fundraising,
ExpiredRefund,
Successful
}
struct Contribution {
uint amount;
address contributor;
}
// State variables
State public state = State.Fundraising; // initialize on create
uint public totalRaised;
uint public raiseBy;
uint public completeAt;
Contribution[] contributions;
event LogFundingReceived(address addr, uint amount, uint currentTotal);
event LogWinnerPaid(address winnerAddress);
modifier inState(State _state) {
if (state != _state) throw;
_
}
modifier isCreator() {
if (msg.sender != creator) throw;
_
}
// Wait 6 months after final contract state before allowing contract destruction
modifier atEndOfLifecycle() {
if(!((state == State.ExpiredRefund || state == State.Successful) &&
completeAt + 6 months < now)) {
throw;
}
_
}
function CrowdFunder(
uint timeInHoursForFundraising,
string _campaignUrl,
address _fundRecipient,
uint _minimumToRaise)
{
creator = msg.sender;
fundRecipient = _fundRecipient;
campaignUrl = _campaignUrl;
minimumToRaise = _minimumToRaise;
raiseBy = now + (timeInHoursForFundraising * 1 hours);
}
function contribute()
public
inState(State.Fundraising)
{
contributions.push(
Contribution({
amount: msg.value,
contributor: msg.sender
}) // use array, so can iterate
);
totalRaised += msg.value;
LogFundingReceived(msg.sender, msg.value, totalRaised);
checkIfFundingCompleteOrExpired();
return contributions.length - 1; // return id
}
function checkIfFundingCompleteOrExpired() {
if (totalRaised > minimumToRaise) {
state = State.Successful;
payOut();
// could incentivize sender who initiated state change here
} else if ( now > raiseBy ) {
state = State.ExpiredRefund; // backers can now collect refunds by calling getRefund(id)
}
completeAt = now;
}
function payOut()
public
inState(State.Successful)
{
if(!fundRecipient.send(this.balance)) {
throw;
}
LogWinnerPaid(fundRecipient);
}
function getRefund(id)
public
inState(State.ExpiredRefund)
{
if (contributions.length <= id || id < 0 || contributions[id].amount == 0 ) {
throw;
}
uint amountToRefund = contributions[id].amount;
contributions[id].amount = 0;
if(!contributions[id].contributor.send(amountToSend)) {
contributions[id].amount = amountToSend;
return false;
}
return true;
}
function removeContract()
public
isCreator()
atEndOfLifecycle()
{
selfdestruct(msg.sender);
// creator gets all money that hasn't be claimed
}
function () { throw; }
}
// ** END EXAMPLE **
name::
* McsEngl.Lsol-source-algo.storage,
codeLsol::
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html]
pragma solidity ^0.4.0;
contract SimpleStorage {
uint storedData;
function set(uint x) {
storedData = x;
}
function get() constant returns (uint) {
return storedData;
}
}
description::
The following contract will implement the simplest form of a cryptocurrency. It is possible to generate coins out of thin air, but only the person that created the contract will be able to do that (it is trivial to implement a different issuance scheme). Furthermore, anyone can send coins to each other without any need for registering with username and password - all you need is an Ethereum keypair.
pragma solidity ^0.4.0;
contract Coin {
// The keyword "public" makes those variables
// readable from outside.
address public minter;
mapping (address => uint) public balances;
// Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount);
// This is the constructor whose code is
// run only when the contract is created.
function Coin() {
minter = msg.sender;
}
function mint(address receiver, uint amount) {
if (msg.sender != minter) return;
balances[receiver] += amount;
}
function send(address receiver, uint amount) {
if (balances[msg.sender] < amount) return;
balances[msg.sender] -= amount;
balances[receiver] += amount;
Sent(msg.sender, receiver, amount);
}
}
This contract introduces some new concepts, let us go through them one by one.
The line address public minter; declares a state variable of type address that is publicly accessible. The address type is a 160-bit value that does not allow any arithmetic operations. It is suitable for storing addresses of contracts or keypairs belonging to external persons. The keyword public automatically generates a function that allows you to access the current value of the state variable. Without this keyword, other contracts have no way to access the variable. The function will look something like this:
function minter() returns (address) { return minter; }
Of course, adding a function exactly like that will not work because we would have a function and a state variable with the same name, but hopefully, you get the idea - the compiler figures that out for you.
The next line, mapping (address => uint) public balances; also creates a public state variable, but it is a more complex datatype. The type maps addresses to unsigned integers. Mappings can be seen as hashtables which are virtually initialized such that every possible key exists and is mapped to a value whose byte-representation is all zeros. This analogy does not go too far, though, as it is neither possible to obtain a list of all keys of a mapping, nor a list of all values. So either keep in mind (or better, keep a list or use a more advanced data type) what you added to the mapping or use it in a context where this is not needed, like this one. The getter function created by the public keyword is a bit more complex in this case. It roughly looks like the following:
function balances(address _account) returns (uint) {
return balances[_account];
}
As you see, you can use this function to easily query the balance of a single account.
The line event Sent(address from, address to, uint amount); declares a so-called “event” which is fired in the last line of the function send. User interfaces (as well as server appliances of course) can listen for those events being fired on the blockchain without much cost. As soon as it is fired, the listener will also receive the arguments from, to and amount, which makes it easy to track transactions. In order to listen for this event, you would use
Coin.Sent().watch({}, '', function(error, result) {
if (!error) {
console.log("Coin transfer: " + result.args.amount +
" coins were sent from " + result.args.from +
" to " + result.args.to + ".");
console.log("Balances now:\n" +
"Sender: " + Coin.balances.call(result.args.from) +
"Receiver: " + Coin.balances.call(result.args.to));
}
}
Note how the automatically generated function balances is called from the user interface.
The special function Coin is the constructor which is run during creation of the contract and cannot be called afterwards. It permanently stores the address of the person creating the contract: msg (together with tx and block) is a magic global variable that contains some properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
Finally, the functions that will actually end up with the contract and can be called by users and contracts alike are mint and send. If mint is called by anyone except the account that created the contract, nothing will happen. On the other hand, send can be used by anyone (who already has some of these coins) to send coins to anyone else. Note that if you use this contract to send coins to an address, you will not see anything when you look at that address on a blockchain explorer, because the fact that you sent coins and the changed balances are only stored in the data storage of this particular coin contract. By the use of events it is relatively easy to create a “blockchain explorer” that tracks transactions and balances of your new coin.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
name::
* McsEngl.Lsol-source-algo.cryptocurrency,
* McsEngl.Lsol-source-algo.subcurrency,
name::
* McsEngl.Lsol-source-algo.will,
codeLsol::
contract CMgrWill {
address public aWill_owner;
bytes32 public t32Hash_of_will;
function fMgrWill(){
aWill_owner = msg.sender;
}
function fWillNew(string sWillIn) {
if (msg.sender != aWill_owner) throw;
t32Hash_of_will = sha3(sWillIn);
}
function fWillCheck(string sWillUserIn) constant returns (bool bWill_correct) {
return (sha3(sWillUserIn) == t32Hash_of_will);
}
}
Human.Reitwiessner.Cristian:
Dr. Christian Reitwieίner, the creator of the Ethereum smart contract language Solidity,
[https://blog.slock.it/creator-of-solidity-joins-slock-it-team-as-advisor-76b77d0aa459#.mqoj2umze]
name::
* McsEngl.Lsol'tool!⇒Lsol-tool,
* McsEngl.Lsol-tool,
specific::
* Browser-compiler,
* solcjs,
* Dapple,
* Populus,
* REPL,
* Solgraph,
===
* Solidity Parser in Javascript: https://github.com/ConsenSys/solidity-parser,
description::
The best way to try out Solidity right now is using the Browser-Based Compiler (it can take a while to load, please be patient).
[https://solidity.readthedocs.io/en/v0.4.9/]
name::
* McsEngl.Lsol'browser-compiler,
* McsEngl.Lsol-tool.browser-compiler,
addressWpg::
* https://ethereum.github.io/browser-solidity/#version=soljson-v0.4.9+commit.364da425.js,
description::
npm / Node.js
This is probably the most portable and most convenient way to install Solidity locally.
A platform-independent JavaScript library is provided by compiling the C++ source into JavaScript using Emscripten. It can be used in projects directly (such as Browser-Solidity). Please refer to the solc-js repository for instructions.
It also contains a commandline tool called solcjs, which can be installed via npm:
npm install -g solc
Note
The comandline options of solcjs are not compatible with solc and tools (such as geth) expecting the behaviour of solc will not work with solcjs.
[https://solidity.readthedocs.io/en/v0.4.9/installing-solidity.html#npm-node-js]
===
> solcjs --help
Usage: C:\Users\username\AppData\Roaming\npm\node_modules\solc\solcjs
[options] [input_file...]
Options:
--version Show version number [boolean]
--optimize Enable bytecode optimizer. [boolean]
--bin Binary of the contracts in hex. [boolean]
--abi ABI of the contracts. [boolean]
--output-dir, -o Output directory for the contracts. [string]
--help Show help [boolean]
description::
Dapple is a Solidity developer multitool designed to manage the growing complexity of interconnected smart contract systems.
Its core functionality encompasses three main areas:
Package management
Contract building
Deployment scripting
[http://dapple.readthedocs.io/en/master/]
description::
Populus is a smart contract development framework for the Ethereum blockchain.
[http://populus.readthedocs.io/en/latest/]
description::
Ethereum Solidity REPL.
[https://github.com/raineorshine/solidity-repl]
name::
* McsEngl.Lsol'REPL,
* McsEngl.Lsol-tool.REPL,
installation::
$ npm install -g solidity-repl
[https://github.com/raineorshine/solidity-repl]
usage::
$ solr
Welcome to the Solidity REPL!
> uint a = 10
> uint b = 20
> a + b
30
> msg.sender
0x2f42491c0a08e4bc0cd3d5a96533a69727e16911
[https://github.com/raineorshine/solidity-repl]
description::
Visualize Solidity control flow for smart contract security analysis.
[https://github.com/raineorshine/solgraph]
addressWpg::
* https://github.com/ethereum/solidity,
=== tutorial
* https://solidity.readthedocs.org/en/latest/
* http://solidity.readthedocs.io/en/v0.4.9/
* https://github.com/androlo/solidity-workshop,
* https://karl.tech/learning-solidity-part-1-deploy-a-contract/ metamask,
* https://ethereumbuilders.gitbooks.io/guide/content/en/solidity_tutorials.html,
* https://learnxinyminutes.com/docs/solidity/
=== community
* https://gitter.im/ethereum/solidity/
===
* SolidityX: Secure-by-default programming language that compiles to Solidity. https://solidityx.org/,
addressWpg::
* https://github.com/ethereum/solidity/blob/develop/Changelog.md,
Lsol'0-4-10.2017-03-15:
Features:
Add assert(condition), which throws if condition is false (meant for internal errors).
Add require(condition), which throws if condition is false (meant for invalid input).
Commandline interface: Do not overwrite files unless forced.
Introduce .transfer(value) for sending Ether.
Code generator: Support revert() to abort with rolling back, but not consuming all gas.
Inline assembly: Support revert (EIP140) as an opcode.
Parser: Support scientific notation in numbers (e.g. 2e8 and 200e-2).
Type system: Support explicit conversion of external function to address.
Type system: Warn if base of exponentiation is literal (result type might be unexpected).
Type system: Warn if constant state variables are not compile-time constants.
Bugfixes:
Commandline interface: Always escape filenames (replace /, : and . with _).
Commandline interface: Do not try creating paths . and ...
Commandline interface: Allow long library names.
Parser: Disallow octal literals.
Type system: Fix a crash caused by continuing on fatal errors in the code.
Type system: Disallow compound assignment for tuples.
Type system: Detect cyclic dependencies between constants.
Type system: Disallow arrays with negative length.
Type system: Fix a crash related to invalid binary operators.
Type system: Disallow var declaration with empty tuple type.
Type system: Correctly convert function argument types to pointers for member functions.
Type system: Move privateness of constructor into AST itself.
Inline assembly: Charge one stack slot for non-value types during analysis.
Assembly output: Print source location before the operation it refers to instead of after.
Optimizer: Stop trying to optimize tricky constants after a while.
[https://github.com/ethereum/solidity/blob/develop/Changelog.md]
Lsol'0-4-9.2017-01-31:
Features:
Compiler interface: Contracts and libraries can be referenced with a file: prefix to make them unique.
Compiler interface: Report source location for "stack too deep" errors.
AST: Use deterministic node identifiers.
Inline assembly: introduce invalid (EIP141) as an opcode.
Type system: Introduce type identifier strings.
Type checker: Warn about invalid checksum for addresses and deduce type from valid ones.
Metadata: Do not include platform in the version number.
Metadata: Add option to store sources as literal content.
Code generator: Extract array utils into low-level functions.
Code generator: Internal errors (array out of bounds, etc.) now cause a reversion by using an invalid instruction (0xfe - EIP141) instead of an invalid jump. Invalid jump is still kept for explicit throws.
Bugfixes:
Code generator: Allow recursive structs.
Inline assembly: Disallow variables named like opcodes.
Type checker: Allow multiple events of the same name (but with different arities or argument types)
Natspec parser: Fix error with @param parsing and whitespace.
Lsol'0-4-8.2017-01-13:
Features:
Optimiser: Performance improvements.
Output: Print assembly in new standardized Solidity assembly format.
Bugfixes:
Remappings: Prefer longer context over longer prefix.
Type checker, code generator: enable access to events of base contracts' names.
Imports: import ".dir/a" is not a relative path. Relative paths begin with directory . or ...
Type checker, disallow inheritances of different kinds (e.g. a function and a modifier) of members of the same name
Lsol'0-4-7.2016-12-15:
Features:
Bitshift operators.
Type checker: Warn when msg.value is used in non-payable function.
Code generator: Inject the Swarm hash of a metadata file into the bytecode.
Code generator: Replace expensive memcpy precompile by simple assembly loop.
Optimizer: Some dead code elimination.
Bugfixes:
Code generator: throw if calling the identity precompile failed during memory (array) copying.
Type checker: string literals that are not valid UTF-8 cannot be converted to string type
Code generator: any non-zero value given as a boolean argument is now converted into 1.
AST Json Converter: replace VariableDefinitionStatement nodes with VariableDeclarationStatement
AST Json Converter: fix the camel case in ElementaryTypeNameExpression
AST Json Converter: replace public field with visibility in the function definition nodes
Lsol'0-4-6.2016-11-22:
Bugfixes:
Optimizer: Knowledge about state was not correctly cleared for JUMPDESTs (introduced in 0.4.5)
Lsol'0-4-5.2016-11-21:
Features:
Function types
Do-while loops: support for a do <block> while (<expr>); control structure
Inline assembly: support invalidJumpLabel as a jump label.
Type checker: now more eagerly searches for a common type of an inline array with mixed types
Code generator: generates a runtime error when an out-of-range value is converted into an enum type.
Bugfixes:
Inline assembly: calculate stack height warning correctly even when local variables are used.
Code generator: check for value transfer in non-payable constructors.
Parser: disallow empty enum definitions.
Type checker: disallow conversion between different enum types.
Interface JSON: do not include trailing new line.
Lsol'0-4-4.2016-10-31:
Bugfixes:
Type checker: forbid signed exponential that led to an incorrect use of EXP opcode.
Code generator: properly clean higher order bytes before storing in storage.
Lsol'0-4-3.2016-10-25:
Features:
Inline assembly: support both suicide and selfdestruct opcodes (note: suicide is deprecated).
Inline assembly: issue warning if stack is not balanced after block.
Include keccak256() as an alias to sha3().
Support shifting constant numbers.
Bugfixes:
Commandline interface: Disallow unknown options in solc.
Name resolver: Allow inheritance of enum definitions.
Type checker: Proper type checking for bound functions.
Type checker: fixed crash related to invalid fixed point constants
Type checker: fixed crash related to invalid literal numbers.
Type checker: super.x does not look up x in the current contract.
Code generator: expect zero stack increase after super as an expression.
Code generator: fix an internal compiler error for L.Foo for enum Foo defined in library L.
Code generator: allow inheritance of enum definitions.
Inline assembly: support the address opcode.
Inline assembly: fix parsing of assignment after a label.
Inline assembly: external variables of unsupported type (such as this, super, etc.) are properly detected as unusable.
Inline assembly: support variables within modifiers.
Optimizer: fix related to stale knowledge about SHA3 operations
Lsol'0-4-2.2016-09-17:
Bugfixes:
Code Generator: Fix library functions being called from payable functions.
Type Checker: Fixed a crash about invalid array types.
Code Generator: Fixed a call gas bug that became visible after version 0.4.0 for calls where the output is larger than the input.
Lsol'0-4-1.2016-09-09:
Build System: Fixes to allow library compilation.
Lsol'0-4-0.2016-09-08:
This release deliberately breaks backwards compatibility mostly to enforce some safety features.
The most important change is that you have to explicitly specify if functions can receive ether via the payable modifier.
Furthermore, more situations cause exceptions to be thrown.
Minimal changes to be made for upgrade:
Add payable to all functions that want to receive Ether (including the constructor and the fallback function).
Change _ to _; in modifiers.
Add version pragma to each file: pragma solidity ^0.4.0;
Breaking Changes:
Source files have to specify the compiler version they are compatible with using e.g. pragma solidity ^0.4.0; or pragma solidity >=0.4.0 <0.4.8;
Functions that want to receive Ether have to specify the new payable modifier (otherwise they throw).
Contracts that want to receive Ether with a plain "send" have to implement a fallback function with the payable modifier. Contracts now throw if no payable fallback function is defined and no function matches the signature.
Failing contract creation through "new" throws.
Division / modulus by zero throws.
Function call throws if target contract does not have code
Modifiers are required to contain _ (use if (false) _ as a workaround if needed).
Modifiers: return does not skip part in modifier after _.
Placeholder statement _ in modifier now requires explicit ;.
ecrecover now returns zero if the input is malformed (it previously returned garbage).
The constant keyword cannot be used for constructors or the fallback function.
Removed --interface (Solidity interface) output option
JSON AST: General cleanup, renamed many nodes to match their C++ names.
JSON output: srcmap-runtime renamed to srcmapRuntime.
Moved (and reworked) standard library contracts from inside the compiler to github.com/ethereum/solidity/std (import "std"; or import owned; do not work anymore).
Confusing and undocumented keyword after was removed.
New reserved words: abstract, hex, interface, payable, pure, static, view.
Features:
Hexadecimal string literals: hex"ab1248fe"
Internal: Inline assembly usable by the code generator.
Commandline interface: Using - as filename allows reading from stdin.
Interface JSON: Fallback function is now part of the ABI.
Interface: Version string now semver compatible.
Code generator: Do not provide "new account gas" if we know the called account exists.
Bugfixes:
JSON AST: Nodes were added at wrong parent
Why3 translator: Crash fix for exponentiation
Commandline Interface: linking libraries with underscores in their name.
Type Checker: Fallback function cannot return data anymore.
Code Generator: Fix crash when sha3() was used on unsupported types.
Code Generator: Manually set gas stipend for .send(0).
Lots of changes to the documentation mainly by voluntary external contributors.
Lsol'0-3-6.2016-08-10:
Features:
Formal verification: Take external effects on a contract into account.
Type Checker: Warning about unused return value of low-level calls and send.
Output: Source location and node id as part of AST output
Output: Source location mappings for bytecode
Output: Formal verification as part of json compiler output.
Bugfixes:
Commandline Interface: Do not crash if input is taken from stdin.
Scanner: Correctly support unicode escape codes in strings.
JSON output: Fix error about relative / absolute source file names.
JSON output: Fix error about invalid utf8 strings.
Code Generator: Dynamic allocation of empty array caused infinite loop.
Code Generator: Correctly calculate gas requirements for memcpy precompile.
Optimizer: Clear known state if two code paths are joined.
Lsol'0-3-5.2016-06-10:
Features:
Context-dependent path remappings (different modules can use the same library in different versions)
Bugfixes:
Type Checking: Dynamic return types were removed when fetching data from external calls, now they are replaced by an "unusable" type.
Type Checking: Overrides by constructors were considered making a function non-abstract.
Lsol'0-3-4.2016-05-31:
No change outside documentation.
Lsol'0-3-3.2016-05-27:
Allow internal library functions to be called (by "inlining")
Fractional/rational constants (only usable with fixed point types, which are still in progress)
Inline assembly has access to internal functions (as jump labels)
Running solc without arguments on a terminal will print help.
Bugfix: Remove some non-determinism in code generation.
Bugfix: Corrected usage of not / bnot / iszero in inline assembly
Bugfix: Correctly clean bytesNN types before comparison
Lsol'0-3-2.2016-04-18:
Bugfix: Inline assembly parser: byte opcode was unusable
Bugfix: Error reporting: tokens for variably-sized types were not converted to string properly
Bugfix: Dynamic arrays of structs were not deleted correctly.
Bugfix: Static arrays in constructor parameter list were not decoded correctly.
Lsol'0-3-1.2016-03-31:
Inline assembly
Bugfix: Code generation: array access with narrow types did not clean higher order bits
Bugfix: Error reporting: error reporting with unknown source location caused a crash
Lsol'0.3.0.2016-03-11:
BREAKING CHANGES:
Added new keywords assembly, foreign, fixed, ufixed, fixedNxM, ufixedNxM (for various values of M and N), timestamp
Number constant division does not round to integer, but to a fixed point type (e.g. 1 / 2 != 1, but 1 / 2 == 0.5).
Library calls now default to use DELEGATECALL (e.g. called library functions see the same value as the calling function for msg.value and msg.sender).
<address>.delegatecall as a low-level calling interface
Bugfixes:
Fixed a bug in the optimizer that resulted in comparisons being wrong.
Lsol'0-2-2.2016-02-17:
Index access for types bytes1, ..., bytes32 (only read access for now).
Bugfix: Type checker crash for wrong number of base constructor parameters.
Lsol'0-2-1.2016-01-30:
Inline arrays, i.e. var y = [1,x,f()]; if there is a common type for 1, x and f(). Note that the result is always a fixed-length memory array and conversion to dynamic-length memory arrays is not yet possible.
Import similar to ECMAScript6 import (import "abc.sol" as d and import {x, y} from "abc.sol").
Commandline compiler solc automatically resolves missing imports and allows for "include directories".
Conditional: x ? y : z
Bugfix: Fixed several bugs where the optimizer generated invalid code.
Bugfix: Enums and structs were not accessible to other contracts.
Bugfix: Fixed segfault connected to function paramater types, appeared during gas estimation.
Bugfix: Type checker crash for wrong number of base constructor parameters.
Bugfix: Allow function overloads with different array types.
Bugfix: Allow assignments of type (x) = 7.
Bugfix: Type uint176 was not available.
Bugfix: Fixed crash during type checking concerning constructor calls.
Bugfix: Fixed crash during code generation concerning invalid accessors for struct types.
Bugfix: Fixed crash during code generating concerning computing a hash of a struct type.
Lsol'0.2.0.2015-12-02:
Breaking Change: new ContractName.value(10)() has to be written as (new ContractName).value(10)()
Added selfdestruct as an alias for suicide.
Allocation of memory arrays using new.
Binding library functions to types via using x for y
addmod and mulmod (modular addition and modular multiplication with arbitrary intermediate precision)
Bugfix: Constructor arguments of fixed array type were not read correctly.
Bugfix: Memory allocation of structs containing arrays or strings.
Bugfix: Data location for explicit memory parameters in libraries was set to storage.
Lsol'0-1-7.2015-11-17:
Improved error messages for unexpected tokens.
Proof-of-concept transcompilation to why3 for formal verification of contracts.
Bugfix: Arrays (also strings) as indexed parameters of events.
Bugfix: Writing to elements of bytes or string overwrite others.
Bugfix: "Successor block not found" on Windows.
Bugfix: Using string literals in tuples.
Bugfix: Cope with invalid commit hash in version for libraries.
Bugfix: Some test framework fixes on windows.
Lsol'0-1-6.2015-10-16:
.push() for dynamic storage arrays.
Tuple expressions ((1,2,3) or return (1,2,3);)
Declaration and assignment of multiple variables (var (x,y,) = (1,2,3,4,5); or var (x,y) = f();)
Destructuring assignment ((x,y,) = (1,2,3))
Bugfix: Internal error about usage of library function with invalid types.
Bugfix: Correctly parse Library.structType a at statement level.
Bugfix: Correctly report source locations of parenthesized expressions (as part of "tuple" story).
Lsol'0-1-5.2015-10-07:
Breaking change in storage encoding: Encode short byte arrays and strings together with their length in storage.
Report warnings
Allow storage reference types for public library functions.
Access to types declared in other contracts and libraries via ..
Version stamp at beginning of runtime bytecode of libraries.
Bugfix: Problem with initialized string state variables and dynamic data in constructor.
Bugfix: Resolve dependencies concerning new automatically.
Bugfix: Allow four indexed arguments for anonymous events.
Bugfix: Detect too large integer constants in functions that accept arbitrary parameters.
Lsol'0-1-4.2015-09-30:
Bugfix: Returning fixed-size arrays.
Bugfix: combined-json output of solc.
Bugfix: Accessing fixed-size array return values.
Bugfix: Disallow assignment from literal strings to storage pointers.
Refactoring: Move type checking into its own module.
Lsol'0-1-3.2015-09-25:
throw statement.
Libraries that contain functions which are called via CALLCODE.
Linker stage for compiler to insert other contract's addresses (used for libraries).
Compiler option to output runtime part of contracts.
Compile-time out of bounds check for access to fixed-size arrays by integer constants.
Version string includes libevmasm/libethereum's version (contains the optimizer).
Bugfix: Accessors for constant public state variables.
Bugfix: Propagate exceptions in clone contracts.
Bugfix: Empty single-line comments are now treated properly.
Bugfix: Properly check the number of indexed arguments for events.
Bugfix: Strings in struct constructors.
Lsol'0-1-2.2015-08-20:
Improved commandline interface.
Explicit conversion between bytes and string.
Bugfix: Value transfer used in clone contracts.
Bugfix: Problem with strings as mapping keys.
Bugfix: Prevent usage of some operators.
Lsol'0-1-1.2015-08-04:
Strings can be used as mapping keys.
Clone contracts.
Mapping members are skipped for structs in memory.
Use only a single stack slot for storage references.
Improved error message for wrong argument count. (#2456)
Bugfix: Fix comparison between bytesXX types. (#2087)
Bugfix: Do not allow floats for integer literals. (#2078)
Bugfix: Some problem with many local variables. (#2478)
Bugfix: Correctly initialise string and bytes state variables.
Bugfix: Correctly compute gas requirements for callcode.
Lsol'0.2014.10:
Solidity was started in October 2014 when neither the Ethereum network nor the virtual machine had any real-world testing, the gas costs at that time were even drastically different from what they are now.
Furthermore, some of the early design decisions were taken over from Serpent.
[https://blog.ethereum.org/2016/06/10/smart-contract-security/]
description::
Serpent is a language similar to Python which can be used to develop contracts and compile to EVM bytecode. It is intended to be maximally clean and simple, combining many of the efficiency benefits of a low-level language with ease-of-use in programming style, and at the same time adding special domain-specific features for contract programming. Serpent is compiled using LLL.
Serpent on the ethereum wiki
Serpent EVM compiler
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#serpent]
name::
* McsEngl.DcontractEth-lang.Serpent,
* McsEngl.Serpent-Ethereum-lang,
addressWpg::
* https://github.com/ethereum/serpent,
* https://github.com/ethereum/wiki/wiki/Serpent,
* http://mc2-umd.github.io/ethereumlab/docs/serpent_tutorial.pdf {2015-05-21},
description::
LLL is a thin layer on top of the EVM that resembles Lisp. All EVM opcodes are available in LLL. On top of that it provides control structures (for, when, if, etc.) that are difficult and confusing to do in assembler. It also provides other convenient abstractions such a macros, and has the ability to include other source files as well.
[http://blog.syrinx.net/the-resurrection-of-lll-part-1/]
===
Lisp Like Language (LLL) is a low level language similar to Assembly. It is meant to be very simple and minimalistic; essentially just a tiny wrapper over coding in EVM directly.
LIBLLL in GitHub
Examples of LLL
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#id4]
===
There does not appear to be active development on LLL as the Ethereum Foundation has identified Solidity as it's primary language that will receive development support from them. However, it is not "dead" in the sense that there are still bug fixes and small changes happening to the repository infrequently.
Interesting side note: Inline ASM may be eventually supported in the Solidity Ethereum language.
Vitalik Buterin said in Nov. 2015:
LLL was always meant to be very simple and minimalistic; essentially just a tiny wrapper over coding in ASM directly. In my opinion just use serpent; it has direct access to opcodes so it is a superset of LLL but it also has a whole bunch of high-level features as well for when you want them. The downside is that the compiler is more complex and so theoretically might contain more bugs.
[http://ethereum.stackexchange.com/a/519]
===
LLL: The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts and general low-level language toolkit for trans-compiling to.
[http://gavwood.com/Paper.pdf]
name::
* McsEngl.DcontractEth-lang.LLL,
* McsEngl.Lisp-Like-Language-of-Ethereum,
* McsEngl.LLL-Ethereum-lang,
* McsEngl.langLLL,
description::
Solidity has been separated from the cpp-ethereum repository. For now, all LLL libraries and the compiler itself are contained in the Solidity repository.
[http://blog.syrinx.net/the-resurrection-of-lll-part-7/]
===
The LLL compiler is contained in the Ethereum C++ client, cpp-ethereum. This page [http://www.ethdocs.org/en/latest/ethereum-clients/cpp-ethereum/] has extensive instructions on its installation for various platforms.
[http://blog.syrinx.net/the-resurrection-of-lll-part-2/]
addressWpg::
* forum: https://forum.ethereum.org/categories/lll,
* examples: http://ether.fund/contracts/lll,
* examples: https://github.com/androlo/EthereumContracts,
* http://blog.syrinx.net/the-resurrection-of-lll-part-1/
* https://github.com/ethereum/cpp-ethereum/wiki/LLL-PoC-6/ 04fae9e627ac84d771faddcf60098ad09230ab58,
* https://github.com/ethereum/cpp-ethereum/wiki/ LLL-Examples-for-PoC-5/04fae9e627ac84d771faddcf60098ad09230ab58,
description::
Viper is an experimental programming language that aims to provide the following features:
Bounds and overflow checking, both on array accesses and on arithmetic
Support for signed integers and decimal fixed point numbers
Decidability - it's possible to compute a precise upper bound on the gas consumption of any function call
Strong typing, including support for units (eg. timestamp, timedelta, seconds, wei, wei per second, meters per second squared)
Maximally small and understandable compiler code size
Limited support for pure functions - anything marked constant is NOT allowed to change the state
[https://github.com/ethereum/viper]
name::
* McsEngl.DcontractEth-lang.Viper,
* McsEngl.langViper,
* McsEngl.Viper-Ethereum-lang,
addressWpg::
* https://github.com/ethereum/viper,
description::
The JSON is called an ABI.
You do need the source code, as you have, and one way to get the ABI is to paste it in Solidity Browser, then copy the Interface value.
[http://ethereum.stackexchange.com/a/3150]
===
ABI stands for application 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 basicly how you can encode solidity contracts for the EVM and backwards how to read the data out of transactions.
[http://ethereum.stackexchange.com/a/235]
name::
* McsEngl.Ethereum-ABI-(Application-Binary-Interface),
* McsEngl.Ethereum-EVM--ABI,
* McsEngl.ABI-EVM,
* McsEngl.Application-Binary-Interface-of-EVM,
addressWpg::
* https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI,
* http://ethereum.stackexchange.com/questions/234/ what-is-an-abi-and-why-is-it-needed-to-interact-with-contracts,
* http://ethereum.stackexchange.com/questions/3149/ how-do-you-get-a-json-file-abi-from-a-known-contract-address,
description::
But we've recently seen how easy it is to cause chaos with one misplaced line of code.
Add to that the myriad of security concerns and the difficulty in addressing them and you have a system not suitable for casual developers, especially with real money at stake.
You have to be invested, so to speak, to develop secure contracts.
[http://blog.syrinx.net/the-resurrection-of-lll-part-1/]
===
Some problems you should be aware of (and avoid):
Reentrancy [http://hackingdistributed.com/2016/07/13/reentrancy-woes/]: Do not perform external calls in contracts. If you do, ensure that they are the very last thing you do.
Send can fail [http://vessenes.com/ethereum-griefing-wallets-send-w-throw-considered-harmful/]: When sending money, your code should always be prepared for the send function to fail.
Loops can trigger gas limit [http://solidity.readthedocs.io/en/latest/security-considerations.html#gas-limit-and-loops]: Be careful when looping over state variables, which can grow in size and make gas consumption hit the limits.
Call stack depth limit [https://ethereum.stackexchange.com/questions/6260/solidity-callstack-attack]: Don’t use recursion, and be aware that any call can fail if stack depth limit is reached.
Timestamp dependency [https://github.com/ConsenSys/smart-contract-best-practices#timestamp-dependence]: Do not use timestamps in critical parts of the code, because miners can manipulate them.
These are provided just as examples of unexpected behaviors that can lead for theft or destruction of funds in your smart contract. The morale is: if you’re writing smart contracts, you’re writing code that handles real money. You should be very careful! Write tests, do code reviews, and audit your code.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
name::
* McsEngl.DcontractEth'security,
addressWpg::
* {2016-10-16} https://medium.com/@MyPaoG/explaining-the-dao-exploit-for-beginners-in-solidity-80ee84f0d470,
* {>2016.06} Making Smart Contracts Smarter http://www.comp.nus.edu.sg/~loiluu/papers/oyente.pdf,
* {2016-06-21} https://medium.com/@hrishiolickel/why-smart-contracts-fail-undiscovered-bugs-and-what-we-can-do-about-them-119aa2843007#.rucpuv5wz,
* {2016-06-19} https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/
* {2016-06-10} https://blog.ethereum.org/2016/06/10/smart-contract-security/
* {2016-05-27} A Call for a Temporary Moratorium on The DAO http://hackingdistributed.com/2016/05/27/dao-call-for-moratorium/
description::
Dynamic Analysis is the process of executing code and data in real-time with the hope of finding issues during execution. It's a similar process to exploratory testing, with the same goals, but perhaps more technical.Dynamic analysis on the Ethereum blockchain has historically been costly at worst and tedious at best. If you were to perform dynamic analysis on the live Ethereum chain, transactions would cost you hard-earned Ether, which might limit the tests you perform. Moving away from the live chain is possible, but it's a tedious process to move the live data over to a separate chain, and you'd have to perform this process multiple times if you end up mucking with the chain state during testing.
[http://truffleframework.com/tutorials/chain-forking-exploiting-the-dao#what-is-dynamic-analysis-]
name::
* McsEngl.DcontractEth'disassember,
specific::
* https://github.com/Arachnid/evmdis,
addressWpg::
* https://etherscan.io/opcode-tool,
description::
DappHub is one of the oldest smart contract development firms in the Ethereum space, first formed to create the MakerDAO stablecoin contract system. As a group with a profound understanding of Ethereum’s smart contracts ecosystem, they were a natural choice when looking for a code audit.
[http://www.newsbtc.com/2017/02/13/makerdao-saviour-nikolai-mushegian-audit-time-lh-tokens/]
addressWpg::
* https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial,
* A 101 Noob Intro to Programming Smart Contracts on Ethereum
http://consensys.github.io/developers/articles/101-noob-intro/
* http://etherparty.io/ Etherparty is a platform that removes the complexity and management of creating and executing smart contracts
* {2015-10-29} https://medium.com/@ConsenSys/a-101-noob-intro-to-programming-smart-contracts-on-ethereum-695d15c1dab4#.mnbfhharn,
* {2016-07-29} https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d,
description::
Contracts have state and functions.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
description::
The Ethereum Virtual Machine (EVM) is where smart contracts run in Ethereum.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
description::
Well, smart contract development is not a breeze, but it can be made much more efficient by the use of testrpc. Running a full Ethereum client (geth, eth, pyethapp, parity, etc.) can be a drain on a developer's resources, especially if running on an under-powered machine. Also, unless you set up a private network and tweak the settings, you have to wait a while for blocks to be mined before checking the results of your transactions. If you're connected to the main Homestead network you'll also be paying for your development testing with real digital currency. No, it's better to start simply and install ethereumjs/testrpc. Go ahead and follow the instructions in the README file to install it on your local machine.
[http://blog.syrinx.net/the-resurrection-of-lll-part-7/]
description::
Finally, before we get started it is important to know this: Writing smart contracts can be tricky. The transition from normal code writing to smart contract writing is not seamless. The environment in which smart contract code runs is different from that of normal code. The analogy with webservices is good, because it makes smart contracts and systems of smart contracts more tangible, and it makes it simpler to use already existing concepts and tools when working with them, but writing the actual code is still difficult.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
In part 1 of this series I introduced the idea that we may need to change the mindset of smart contract development to emphasize its difference from, well, almost every other type of software development.
[http://blog.syrinx.net/the-resurrection-of-lll-part-2/]
name::
* McsEngl.Entmsmc'creating,
* McsEngl.DcontractEth'creating,
* McsEngl.DcontractEth'writing,
specific::
Contracts can even create other contracts using a special opcode (i.e. they do not simply call the zero address). The only difference between these create calls and normal message calls is that the payload data is executed and the result stored as code and the caller / creator receives the address of the new contract on the stack.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#create]
description::
When contracts are created, a new account is first made, then the code is loaded into a VM which runs the constructor part, initializes fields etc., and then adds the runtime portion (or body) of the contract to the account.
[https://monax.io/docs/tutorials/solidity/solidity_7_updating_solidity_contracts/]
name::
* McsEngl.DcontractEth'adding,
* McsEngl.DcontractEth'deploying,
* McsEngl.DcontractEth'uploading,
addressWpg::
* http://hypernephelist.com/2017/01/19/deploy-ethereum-smart-contract-using-client-signature.html,
description::
Ethereum contracts are stored in special contract accounts, and the contract code is executed when the account is the target of a (successful) transaction.
If I, as a user, want to execute a contract, I first need to find out the address to the account in which the contract is stored, and then transact to it.
The parameters for a transaction are:
The gas-price I want to pay (gasPrice).
The maximum amount of gas that may be spent (gas).
The amount of ether I want to transfer (value).
My account address (from).
The target account address (to).
The nonce (nonce).
The transaction data (data).
Alternatively, it is possible to create the transaction object itself on the caller side, sign it locally, and pass in the signed bytes.
The parameters used above is used when making RPC calls, and the client will then create (and sign) the transaction object for you.
Anyways, if my transaction is valid, the Ethereum client will put that transaction data into a context, along with the current block data and some other things.
It then passes the code of the contract account and the context into a new instance of the EVM, and execute it.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-09-advanced-solidity-I.md#accounts-transactions-and-code-execution]
===
Furthermore, every execution of a smart contract happens in public and, in addition to that, the source code is often available.
[https://solidity.readthedocs.io/en/v0.4.9/security-considerations.html#security-considerations]
===
The popular term “smart contracts” refers to code in a Contract Account – programs that execute when a transaction is sent to that account.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
description::
Introduction
This tutorial series looks at modular systems of smart-contracts, and how to continuously update the code in a reliable way. Most contracts in your application will become obsolete at some point, and will require an update. Same as in other applications. It could be because new features must be added, a bug is found, or because a better, more optimized version has been made. Updating could of course cause problems so it must be done with care. Some of the things one must ensure is that:
- updating is possible.
- the new contract works as intended.
- all the calls made during the replacement procedure was executed successfully.
- replacing the contract has no side-effects in other parts of the system.
The first point may seem obvious but it usually requires a lot of work, because updating is not possible by default; the reason is because of how accounts, code and storage works.
Accounts, Code and Storage
A very important property of EVM contracts is that when a contract has been uploaded to the chain, the code can never be changed. Contracts are stored in special account objects, and these object has references to the contract (byte) code, and a database, and some other things. The database is a key-value store, also known as ‘storage’, and is where data such as the values of contract fields is stored.
When contracts are created, a new account is first made, then the code is loaded into a VM which runs the constructor part, initializes fields etc., and then adds the runtime portion (or body) of the contract to the account. After that is done, there is no way to change the code, and there is no way to update the database except through that code.
But what if you want to change the code? What if a bug is discovered?
The way you solve that is by connecting several contracts. Contract C could call contract D as part of its functionality, and the address to D could be settable in C, meaning it would be possible to change what D is. This is best explained through a series of simple examples.
A simple storage contract
contract Data {
uint public data;
function addData(uint data_) {
if(msg.sender == 0x692a70d2e424a56d2c6c27aa97d1a86395877b3a)
data = data_;
}
}
This simple contract allows a user to add and read an unsigned integer. The only account that is allowed to add data is the account with address 0x692a.... This address is a hex literal, so is added to the bytecode when the contract is compiled.
A potential problem is that we might want to replace this address later, or even the entire validation procedurer, but we can’t because of how code and storage works. A simple way of making the contract more flexible is to store the current owner address in storage instead, and make it possible to change.
contract DataOwnerSettable {
uint public data;
address public owner = msg.sender;
function addData(uint data_) {
if(msg.sender == owner)
data = data_;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
This contract has an owner field (mapped to storage). It is initialized with the address of the account that creates the contract, and can later be changed by the current owner by calling setOwner. The guard inside addData is still the same; the only thing that changed is that the owner address is no longer hard-coded.
Delegation
What if a settable owner is not enough, though? What if we want to be able to update not only the owner address, but the entire validation process? That is possible. We will do it in two steps. First we move the account validation code into a different contract.
contract AccountValidator {
address public owner = msg.sender;
function validate(address addr) constant returns (bool) {
return addr == owner;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
contract DataExternalValidation {
uint public data;
AccountValidator _validator;
function DataExternalValidation(address validator) {
_validator = AccountValidator(validator);
}
function addData(uint data_) {
if(_validator.validate(msg.sender))
data = data_;
}
function setValidator(address validator) {
if(_validator.validate(msg.sender))
_validator = AccountValidator(validator);
}
}
To use this, we first create an AccountValidator contract; it has the owner field now, and that field is automatically initialized with an account address. Then we create a DataExternalValidation-contract and inject the address of the validator through the contract constructor. When someone tries to write to data, it will call the validate function of the current validator contract to do the check rather then storing (or hard coding) the owner address and doing the equality check internally. Everything that has to do with access control is now delegated to the validator contract.
This is very nice, because it is now possible to replace the contract that does the actual check. Not only does it decouple this from the data, but since the AccountValidator is its own contract, we could potentially use that contract in other contracts as well and thus give owner control over more contracts then just one.
One thing remains though. We still can’t replace the code! All we have done is move the validation code out of the contract. The code of the AccountValidator contract can’t be changed anymore then that of the data contract. Fortunately, Solidity provides a very simple and powerful workaround - abstract functions.
Abstract Functions
Using abstract functions, the validator contract could be changed into this:
contract AccountValidator {
function validate(address addr) constant returns (bool);
}
contract SingleAccountValidator is AccountValidator {
address public owner = msg.sender;
function validate(address addr) constant returns (bool) {
return addr == owner;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
With these contracts, the data contract no longer works with a concrete validator contract, but an abstract (interface) representation. This makes sense, because it does not really needs to know what the validate function actually does, it only needs to know the signature.
Interfaces works the same way as it does in most other object-oriented languages, just declare functions without a body and they become abstract.
We still can’t change the code stored in a contract account, but we can change the code that is executed when a function is called, by delegating some functionality to other contract which are allowed to be replaced; all we need to do is change the validator contract to a different contract. For example, if we want to allow more owners then one we could use an instance of this contract:
contract MultiAccountValidator is AccountValidator {
mapping(address => bool) public owners;
function MultiAccountValidator() {
owners[msg.sender] = true;
}
function validate(address addr) constant returns (bool) {
return owners[addr];
}
function addOwner(address addr) {
if(owners[msg.sender])
owners[addr] = true;
}
}
Summary
Proper delegation is an important part of smart-contract systems. It is also something one has to consider from the very start, because the rules for how a set of contracts can be updated is generally contained in the contracts themselves. Also, the more contracts that are in the system the harder they become to manage, and a strategy that makes a small system work may not be suitable for a medium-sized or large one.
Another thing to keep in mind is that modularity comes with a cost, because it requires more code, storage variables and calls. On the public chain, where the gas limitations are quite severe (for obvious reasons), even a small modular system could be hard to deploy and run. Generally, when it comes to scalability vs. efficiency I tend to go with scalability. The large, expensive contracts in an excessively modular system can after all be improved and replaced, but if the contracts are locked down that may not be an option.
In our opinion, it is very important to at least acknowledge that the code is going to need updates, and at some point there must be a good policy for how it can be done. The alternative is to not have a plan and fail. And then maybe fail again, and again, until eventually it becomes clear.
[https://monax.io/docs/tutorials/solidity/solidity_7_updating_solidity_contracts/]
description::
The HelloSystem contract can be deployed as-is without any problems, but once it’s been deployed it will remain on the chain for good. We need a way to remove it. In Solidity, the command for removing (or suiciding) a contract is this: selfdestruct(addr). The argument here is the address to which any remaining funds should be sent. In order to expose this functionality, we need to put it inside a (implicitly public) function. This is what a selfdestruct function could look like in HelloSystem:
contract HelloSystem {
function remove() {
selfdestruct(msg.sender);
}
}
What this would do is to remove the contract when the remove function is called, and it would return any funds it may have to the caller. Needless to say, this is not ideal. Normally when you add a selfdestruct function you want to restrict the access to it. The simplest way of doing it is to store the address of the contract creator when the contract is deployed, and only allow the creator to call selfdestruct on it. Here is how that could be implemented:
contract HelloSystem {
address owner;
// Constructor
function HelloSystem(){
owner = msg.sender;
}
function remove() {
if (msg.sender == owner){
selfdestruct(owner);
}
}
}
Note that msg.sender is not the same in the constructor as it is in the remove function. The constructor is called when the contract is added, so msg.sender will be the contract creator, but in all other functions it will be the address of the account that is calling it.
name::
* McsEngl.DcontractEth'service,
specific::
As you will see, it is possible to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
[https://solidity.readthedocs.io/en/v0.4.9/]
===
Think of a “contract” as a program that provides services such as: voting systems, domain
name registries, financial exchanges, crowdfunding platforms, company governance, selfenforcing
contracts and agreements, intellectual property, smart property, and distributed
autonomous organizations.
[http://mc2-umd.github.io/ethereumlab/docs/serpent_tutorial.pdf]
===
Early work on smart contracts has been done by Szabo[1997] and Miller [1997].
Around the 1990s it became clear that algorithmic enforcement of agreements could become a significant force in human cooperation.
Though no specific system was proposed to implement such a system, it was proposed that the future of law would be heavily affected by such systems.
In this light, Ethereum may be seen as a general implementation of such a crypto-law system.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* ethctp.specific,
* McsEngl.DcontractEth.specific,
specific::
* examples: https://github.com/fivedogit/solidity-baby-steps,
* code.binary-smart-contract,
* code.assembly-smart-contract,
* code.source-smart-contract,
* called-smart-contract,
* caller-smart-contract,
* verified-smart-contract,
* DAO-smart-contract,
* Employment-aggrement-smart-contract,
* Exchange-smart-contract,
* Exchange-value-unit-smart-contract,
* Name-registry-smart-contract,
* Will-manager-smart-contract,
=== INSTANCE:
* EToken of Ambisafe,
specific::
* Binary-program,
* Assembly-program,
* Sourcecode-program,
specific::
There are many different ways to classify contracts, but we’re going to use what I call “the five types model”. It is a simple model where contracts are divided up into five basic categories:
1) Database contracts
These are used only as data storage. The only logic they need is functions that allow other contracts to write, update and get data, and some simple way of checking caller permissions (whatever those permissions may be).
2) Controller contracts
These contracts operate on the storage contracts. In a flexible system, both controllers and databases can be replaced by other, similar contracts that share the same public api (although this is not always needed). Controllers can be advanced, and could for example do batched reads/writes, or read from and write to multiple different databases instead of just one.
3) Contract managing contracts (CMCs)
The purpose of these contracts is only to manage other contracts. Their main tasks is to keep track of all the contracts/components of the system, handle the communication between these components, and to make modular design easier. Keeping this functionality separate from normal business logic should be considered good practice, and has a number of positive effects on the system (as we will see later).
4) Application logic contracts (ALCs)
Application logic contracts contains application-specific code. Generally speaking, if the contract utilizes controllers and other contracts to perform application specific tasks it’s an ALC.
5) Utility contracts
These type of contracts usually perform a specific task, and can be called by other contracts without restrictions. It could be a contract that hashes strings using some algorithm, provide random numbers, or other things. They normally don’t need a lot of storage, and often have few or no dependencies.
The rationale for this division will be laid out after we’ve tried to apply it to the fund manager system, as it will be a lot more clear then.
[https://monax.io/docs/tutorials/solidity/solidity_1_the_five_types_model/]
description::
Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode).
However, contracts are typically written in an Ethereum high level language, compiled into byte code using an EVM compiler, and finally uploaded on the blockchain using an Ethereum client.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
===
Note that in reality the contract code is written in the low-level EVM code;
[https://github.com/ethereum/wiki/wiki/White-Paper#ethereum-state-transition-function]
===
When Ethereum contracts are compiled down to byte-code the convention is not to represent them as binary, but instead to represent them as a single long hex string like the following:
6060604052600a8060106000396000f360606040526008565b00
This is the compiled byte-code for the following solidity contract:
contract Test {
}
[https://ericscrivner.me/2016/07/lets-write-ethereum-virtual-machine-disassembler/]
name::
* McsEngl.DnEth-account'bytecode,
* McsEngl.DnEth-account'code,
* McsEngl.DcontractEth.binary-code,
* McsEngl.DcontractEth.bytecode,
* McsEngl.DnEthvm'contract-bytecode,
description::
Programs are not stored in memory, but instead can be considered to be stored in a separate virtual read-only memory (ROM) that is accessible only through a special instruction – CODECOPY – which copies the program into main memory.
[https://ericscrivner.me/2016/07/lets-write-ethereum-virtual-machine-disassembler/]
description::
A program in EVM is a sequence of opcodes, like this:
PUSH1 0 CALLDATALOAD SLOAD NOT PUSH1 9 JUMPI STOP JUMPDEST PUSH1 32 CALLDATALOAD PUSH1 0 CALLDATALOAD SSTORE
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
name::
* McsEngl.DcontractEth.assembly,
addressWpg::
* https://gist.github.com/anonymous/d3bbdc55159879046345,
* https://etherscan.io/opcode-tool,
name::
* McsEngl.DcontractEth.sourcecode,
description::
Verify and Publish your Solidity Source Code
Step 1 : Enter your Contract Source Code below.
Step 2 : If the Bytecode generated matches the existing Creation Address Bytecode, the contract is then Verified.
Step 3 : Contract Source Code is published online and publicably verifiable by anyone.
NOTES
1. To verify Contracts that accept Constructor arguments, please enter the ABI-encoded Arguments in the last box below.
2. For debugging purposes if it compiles correctly at Browser Solidity, it should also compile correctly here.
3. Contracts that use "imports" will need to have the code concatenated into one file as we do not support "imports" in separate files
[https://etherscan.io/verifyContract]
addressWpg::
* https://etherscan.io/contractsVerified,
* https://etherchain.org/account_verify/
description::
Here is just one example: imagine you own a small business with your friends. Lawyers and accountants are expensive, and trusting a single partner to oversee the books can be a source of tension (even an opportunity for fraud). Complying strictly with a system in which more than one partner oversees the books can be trying and is subject to fraud whenever the protocol isn’t followed exactly.
Using a smart contract, ownership in your company and terms for the disbursal of funds can be specified at the outset. The smart contract can be written such that it is only changeable given the approval of a majority of owners. Smart contracts like these will likely be available as open source software, so you won’t even need to hire your own programmer in stead of an accountant/lawyer.
A smart contract like this scales instantly. A couple of teenagers can split revenue from a lemonade stand just as transparently as a sovereign wealth fund can disburse funds to the hundred million citizens who are entitled to it. In both cases the price of this transparency is likely to be fractions of a penny per dollar.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/web3.html#dao]
whole::
* eth-ereum-dao-dApp,
description::
One example of a smart contract would be an employment agreement: A wants to pay $500 to B to build a website. The contract would work as follows: A puts $500 into the contract, and the funds are locked up. When B finishes the website, B can send a message to the contract asking to unlock the funds. If A agrees, the funds are released. If B decides not to finish the website, B can quit by sending a message to relinquish the funds. If B claims that he finished the website, but A does not agree, then after a 7-day waiting period it’s up to judge J to provide a verdict in A or B’s favor.
[https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/]
addressWpg::
* https://github.com/bokkypoobah/TokenTrader/wiki,
addressWpg::
* EToken of Ambisafe: https://github.com/Ambisafe/etoken-docs/wiki,
description::
Name registry, or “namereg” contracts generally lets people associate a name with an user account address. This is an example of such a contract:
contract Users {
// Here we store the names. Make it public to automatically generate an
// accessor function named 'users' that takes a fixed-length string as argument.
mapping (bytes32 => address) public users;
// Register the provided name with the caller address.
// Also, we don't want them to register "" as their name.
function register(bytes32 name) {
if(users[name] == 0 && name != ""){
users[name] = msg.sender;
}
}
// Unregister the provided name with the caller address.
function unregister(bytes32 name) {
if(users[name] != 0 && name != ""){
users[name] = 0x0;
}
}
}
When this contract is called, it will use msg.sender and a provided name as parameters. msg.sender refers to the address of the account that made the transaction. name is a fixed-length string that the sender includes in the transaction data. If the name is not already taken, it will be written into users.
This is a very basic but useful contract. It lets you refer to users by name instead of having to use their public address. It could be used as a basis for almost anything. It could use some more functionality, such as being able to list all the registered users, and maybe also make it possible to get a name by address, and not just address by name, and other things.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
codeLsol::
contract WillManager {
address public willOwner;
bytes32 public hashOfWill;
function WillManager(){
willOwner = msg.sender;
}
function newWill(string will) {
if (msg.sender != willOwner) throw;
hashOfWill = sha3(will);
}
function checkWill(string willUserIsChecking) constant returns (bool willIsCorrect) {
return (sha3(willUserIsChecking) == hashOfWill);
}
}
lifetime::
Contracts will exist and run as long as the whole network exists, and will only stop if they run out of gas or if they were programmed to self destruct.
[https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial]
name::
* McsEngl.DnEthereum'wallet,
* McsEngl.Ethereum-wallet,
specific::
* Mist-Ethereum-wallet,
* MyEtherWallet,
* Parity-wallet,
* Jaxx-wallet,
description::
Ethereum wallet is a wallet, Mist is a browser.
===
The Mist Browser includes the Ethereum Wallet. The Ethereum Wallet is the Mist Browser with the browser function disabled. If you plan on using contracts use the Mist, else if you're just holding ETH, use the Ethereum Wallet.
[https://www.reddit.com/r/ethereum/comments/53nifc/confusion_should_i_download_mist_or_ethereum/d7undsl/]
name::
* McsEngl.Ethereum-wlt.ethereum-wallet,
* McsEngl.Ethereum-wltMst, {2017-04-02},
* McsEngl.Mist-ethereum-wallet,
* McsEngl.Mewlt,
The data folder for Mist is stored in other places:
Windows %APPDATA%/Roaming/Mist (C:\Users\user\AppData\Roaming\Mist)
MacOSX ~/Library/Application Support/Mist
Linux ~/.config/Mist
[https://github.com/ethereum/mist]
addressWpg::
* https://blog.ethereum.org/2015/09/16/ethereum-wallet-developer-preview/
* https://blog.slock.it/the-ethereum-wallet-an-introduction-for-non-devs-9c530f75c018#.n1jtag8gq,
For updating simply download the new version and copy it over the old one (keep a backup of the old one if you want to be sure).
[https://github.com/ethereum/mist]
description::
A multisig wallet – allows you to add any number of owner accounts and set a daily limit.
Every owner can send money from that account as long as it is under the daily limit. If above you need the signatures of the required other owners.
[https://blog.ethereum.org/2015/09/16/ethereum-wallet-developer-preview/]
Wallet 0.5.2 (Beta 10)
@frozeman frozeman released this 19 days ago · 69 commits to wallet since this release
This release adds some additional log information to the splash screen and adds a feature to send all ether for an account.
Full list of changes:
Added a send-all functionality to the send page.
Add German (thanks to @ColRad) and Portuguese (@alexvandesande) translation for the wallet!
Added log infos to the splash screen, so users can see what the node is currently doing...
Improved ether display precision on the confirmation screen
Added a check with NTP servers to see if the computer time is correct, if not it shows an error
Increased error timeout
If you should notice that your wallet links lead to a white page, please run the following script in the console:
https://gist.github.com/frozeman/ed41008f4d30900da3e8
This changes all your wallet addresses internally back to lowercase (we introduced that by accident).
[https://github.com/ethereum/mist/releases]
description::
Open-Source, client-side tool for easily & securely interacting with the Ethereum network.
Created by kvhnuke & tayvano.
[https://www.myetherwallet.com/]
name::
* McsEngl.Ethereum-MyEtherWallet,
* McsEngl.MyEtherWallet,
addressWpg::
* Help: https://myetherwallet.groovehq.com/help_center,
name::
* McsEngl.Ethereum-human,
* McsEngl.DnEthereum'human,
specific::
=== GENERIC:
* DEVELOPER,
* USER,
* GITTER-COMMUNITY,
* MEETUP-COMMUNITY,
* REDDIT-COMMUNITY,
* STACK-EXCHANGE-COMMUNITY,
=== INSTANCE:
* Alisie.Mihai,
* Buterin.Vitalic,
* Gerring.Taylor,
* Karapetsas.Lefteris,
* Vessenes.Peter,
* Wilcke.Jeffrey,
* Wood.Gavin,
founder::
In 2014, Ethereum founders Vitalik Buterin, Gavin Wood and Jeffrey Wilcke began work on a next-generation blockchain that had the ambitions to implement a general, fully trustless smart contract platform.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
description::
Like in Bitcoin, users must pay small transaction fees to the network.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.DnEthereum'user,
* McsEngl.Ethereum-human.user,
* McsEngl.Ethereum-user,
description::
Gitter Rooms
Gitter is our forum of choice for daily chat. It is the virtual coworking space where devs hang out, so it is where you can get quick help and a bit of handholding in needed.
Gitter uses Github accounts, offers Github integration (notification of pull requests etc), private channels, provides markdown formatting, and more.
Most Gitter channels are organised around particular repositories, or generic topics like research or governance. Please choose the appropriate room and keep discussions on topic.
See the full list of gitter rooms for the Ethereum organisation. Below is the list of active public channels:
go-ethereum - about geth (and tools related to the go implementation)
cpp-ethereum - about eth (and tools related to the C++ implementation)
web3.js - about web3.js, Ethereum JavaScript API library
Solidity - The Solidity Contract-Oriented Programming Language
serpent - The Serpent language for contract development
mist - GUI dapp browser, official wallet app
light-client - about light client and the LES protocol
research - Ethereum research
governance - about dev governance
whisper - anonymous datagram publishing
swarm - decentralised content storage and distribution network
EIPs - discussion of Ethereum Improvement Proposals (EIPs)
ethereumjs-lib - a JavaScript library of core Ethereum functions
devp2p - Π?V’s p2p network protocol & framework
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/community.html#gitter-rooms]
addressWpg::
* http://www.meetup.com/topics/ethereum/
description::
Reddit
The Ethereum subreddit is the most inclusive Ethereum forum, where most of the community discussion is happening and where core devs are also active. This is your forum of choice for generic discussion of news, media coverage, announcements, brainstorming. In general all things Ethereum relevant to the wider community.
Strictly no price discussion.
Also, this is not the ideal place to ask for hands-on help or post questions you expect there are clear immediate answers to (use Gitter Rooms and Stack Exchange for these, respectively).
Read the Ethereum subreddit rules before posting.
Further specialised subreddits:
/r/EthTrader - Ether trading, price and market
/r/EtherMining - Ether mining discussion
/r/Ethmarket - Marketplace for individuals looking to exchange goods and services for Ether
/r/Ethinvestor - News and prospects for Ethereum investors. Following the long term trends in the Ethereum marketplace.
/r/ethereumism/ - a bit more ism, ostic, ical, ist and tinfoil hats, pyramids and crystal ball type of views - the ethereal side of Ethereum
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/community.html#reddit]
description::
Stack Exchange
The Ethereum Stack Exchange is part of the StackExchange network of Q&A communities. StackExchange is a free Q&A site where all the questions and answers are preserved for posterity.
This is the best place to ask technical questions. Help your fellow etherians by answering questions and collect reputation points.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/community.html#stack-exchange]
addressWpg::
* http://ethereum.stackexchange.com/
description::
I was born in 1994 in Russia and moved to Canada in 2000, where I went to school. I went to the Abelard school in 2008 and entered the University of Waterloo in 2012, but quickly left in order to go on a six-month journey around the world and simultaneously engage in cryptocurrency-related projects on a full-time basis. The result of the journey was the idea behind Ethereum, a concept for a generalized cryptoeconomically secured state machine architecture, for which I continue to serve as Chief Scientist.
My primary academic interest consists of studying and exploring the complicated intersection between information theory, cryptography, sociology, epistemology, politics and economics, where mechanisms such as prediction markets, cryptoeconomic state machines (for the layman: "blockchains"), security deposits, consumer protection and reputation systems, multi-key personal security architectures and sampling-and-fallback scalability games sit at the core.
In general, I am trying to move beyond just being "a cryptocurrency person" and acquiring a more holistic and long-tail perspective of what role technology can play in helping to build more secure and trustworthy systems and reduce inefficiency and waste in society; I find that individuals that identify themselves around a particular solution (eg. cryptocurrency, progressivism, authoritarianism, libertarianism, radical decentralization) are likely to be more susceptible to confirmation biases and generally less interesting than people who identity themselves around a problem, and dedicate themselves to the search for a solution to that problem no matter where the search takes them.
I also enjoy learning languages (started Mandarin a year ago) and exploring interesting places like the one that's the background of this screen.
#informationtheory
#economics
#philosophy
#epistemology
#mechanismdesign
[https://about.me/vitalik_buterin]
name::
* McsEngl.Buterin.Vitalik.human,
* McsEngl.hmnBtrn1994!={1994}.Buterin.Vitalik,
* McsEngl.human.{1994}.Buterin.Vitalik,
* McsEngl.human.Buterin.Vitalik.{1994},
* McsEngl.Vitalik-Buterin.human.{1994},
description::
* https://vitalik.eth.limo/,
* https://blog.ethereum.org/author/vitalik-buterin/
* https://medium.com/@VitalikButerin,
description::
Lefteris Karapetsas
Developer located in Berlin. University of Tokyo graduate. #emacs user. #ethereum core developer http://lefteris.refu.co,
===
Lefteris is the Technical Lead of slock.it
After graduating from the University of Tokyo, Lefteris has been developing backend software for various companies including Oracle and Acmepacket. He is an all-around tinkerer who loves to takes things apart and put them back together learning how they work in the process.
He has been part of Ethereum as a C++ core developer since November 2014, having worked on Solidity, the ethash algorithm, the core client and the CI system and is now leading the technical side of things towards revolutionizing the IoT world with the use of blockchains in Slock.it
[https://blog.slock.it/why-we-are-building-the-ethereum-framework-for-ubuntu-core-41b53ba685da]
name::
* McsEngl.human.Karapetsas.Lefteris,
* McsEngl.Lefteris-Karapetsas,
addressWpg::
Twitter: @lefterisjp
contact: lefteris@slock.it
* http://lefteris.refu.co/
* https://blog.slock.it/a-dao-counter-attack-613548408dd7#.s0ebn5fjx,
description::
Peter Vessenes, the global blockchain and smart contracts expert who first drew attention to the vulnerability in The DAO, will be checking ChronoBank’s code to ensure it is secure.
[https://blog.chronobank.io/number-one-smart-contracts-security-expert-to-audit-chronobank-34f1289c9e4?goal=0_c14d97ba45-618679cae7-32550077#.89dwu8sch]
name::
* McsEngl.human.Vessenes.Peter,
* McsEngl.Peter-Vessenes-hmn,
description::
Since my childhood economics and game theory have always interested me, even to the point of co-publishing a strategy board game of my own design. When I first read about Bitcoin in 2011, I was largely uninterested, focusing too much on the currency aspect rather than the technology. However, when I revisited it in early 2013, I began to realise new possibilities opening up between the fields of ITC and game theory, and the inevitable social change to which this would lead. A mutual friend made the introduction to Vitalik in late 2014 and Ethereum has dominated my life since.
I coded the first functional implementation of Ethereum and wrote the Yellow Paper, the first formal specification of any blockchain protocol and one of the key ways Ethereum separates itself from other blockchain-based systems. My original ideas for web three date back to early 2013, but my first post on the topic was in April 2014, later followed by a less-techy version.
Prior to Ethereum, I accrued a masters degree and doctorate in computer science. I consulted for Microsoft Reseach on technical aspects of embedded domain-specific languages, designed and implemented the first truly smart lighting controller for one of London's top nightclubs, designed and implemented most of the world's first C++ language workbench, and built the software systems of OxLegal, a smart text contract-editor.
[http://gavwood.com/]
description::
In 2014, Ethereum founders Vitalik Buterin, Gavin Wood and Jeffrey Wilcke began work on a next-generation blockchain that had the ambitions to implement a general, fully trustless smart contract platform.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
name::
* McsEngl.human.Wilcke.Jeffrey,
* McsEngl.Jeffrey-Wilcke,
name::
* McsEngl.DnEthereum'organization,
* McsEngl.DnEth-ogn,
* McsEngl.Ethereum-organization,
description::
The Enterprise Ethereum Alliance connects Fortune 500 enterprises, startups, academics, and technology vendors with Ethereum subject matter experts.
Together, we will learn from and build upon the only smart contract supporting blockchain currently running in real-world production – Ethereum – to define enterprise-grade software capable of handling the most complex, highly demanding applications at the speed of business.
[http://entethalliance.org/]
name::
* McsEngl.EEA-(Enterprice-Ethereum-Alliance),
* McsEngl.Enterprice-Ethereum-Alliance-(EEA),
addressWpg::
* https://cointelegraph.com/news/ ethereum-alliance-formed-by-microsoft-intel-ubs-secures-support-of-eth-foundation,
description::
Ethcore is the creator of Parity: The worlds fastest ethereum client that integrates directly into your browser.
...
Ethcore is dedicated to helping you get the most out of open source blockchain technology.
We come from a wide variety of backgrounds; computer science, engineering, consulting, finance and law.
We've lived through the expansive growth in capabilities that blockchain has seen over the last few years.
We are the people that brought the world the most advanced blockchain technology to date.
We are the thinkers, makers and coders that can help you realise your blockchain potential.
[https://ethcore.io/index.html]
name::
* McsEngl.Ethereum-core,
* McsEngl.Ethereum-core-ogn,
Dr. Gavin Wood, founder of Parity Technologies and lead developer of the acclaimed Parity Ethereum client
[https://ethcore.io/press.html]
description::
Slock.it UG is a German company building the future infrastructure of the sharing economy. Our first product, the Ethereum Computer, brings blockchain technology to the entire home, making it possible to rent access to any compatible smart object and accept payments without intermediaries. We aim for this product and its ecosystem to be funded by a Decentralized Autonomous Organization (DAO), a type of digital company or trust where token holders benefit financially from the revenue of the products they supported - think of it as a Kickstarter on steroids.
The DAO model is free and open source for anyone to reproduce and study, and our white paper can be downloaded here.
Slock.it UG will soon make the Ethereum Computer proposal to the DAO available to the public. Once ready, it will be posted on this website.
[https://slock.it/faq.md]
===
Slock.it brings the benefits of the Blockchain - transparency, security and auditablity - to real-world objects.
Our technology can be embedded in almost any device and the first prototypes are already in the hands of developers.
[https://slock.it/]
description::
The Ethereum Foundation is a non-profit organization registered in Switzerland, and has the purpose of managing the funds that were raised from the Ether Sale in order to best serve the Ethereum and decentralized technology ecosystem.
Founded July 2014 in Switzerland, Stiftung Ethereum’s mission is the promotion of developments of new technologies and applications, especially in the fields of new open and decentralized software architectures.
It is the aim that decentralized and open technologies will be developed, nurtured, promoted and maintained. A dominating, but not exclusive, focus is set on the promotion of the development of the Ethereum Protocol and the relevant technology to it as well as the promotion and support of applications using the Ethereum technology or protocol. Stiftung Ethereum will additionally support and advocate for a decentralized Internet in a variety of forms.
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-ecosystem/foundation.html]
name::
* McsEngl.Ethereum-Foundation,
* McsEngl.DnEthereum'Ethereum-Foundation,
name::
* McsEngl.DnEthereum'evaluation,
smart-contract::
"Arguably the most important contribution of Ethereum is the real-world implementation and accessibility of smart contracts.
From smart contracts follow decentralized applications or “dApps,” which enable common users to interact with financial and other purposes of the blockchain without necessarily needing to be cryptocurrency savvy"
[https://www.ccn.com/new-protocol-lets-eos-dapps-teleport-tokens-from-ethereum/]
performance::
Nick Szabo @NickSzabo4
Ethereum can solve any problem a computer can solve: but with far greater reliability and security and far less performance and efficiency.
[2016-02-10]
This massive parallelisation of computing across the entire Ethereum network is not done to make computation more efficient. In fact, this process makes computation on Ethereum far slower and more expensive than on a traditional “computer”. Rather, every Ethereum node runs the EVM in order to maintain consensus across the blockchain. Decentralized consensus gives Ethereum extreme levels of fault tolerance, ensures zero downtime, and makes data stored on the blockchain forever unchangeable and censorship-resistant.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]
One issue with Bitcoin, being a hardwired protocol, is that you can’t easily introduce many competing currency models on the same platform, and we know how hard it is to create a new network for each new protocol and a system to easily exchange value between networks, hence why softwired platforms like Ethereum are enticing – sure Ether’s issuance algorithm is fixed, but it is trivial to create almost an unlimited number of alternative easily exchangable currency models on the same platform without incurring the cost of creating a brand new network every time. Exciting times!
[https://www.linkedin.com/pulse/crypto-20-musings-bitcoin-money-creation-alex-batlin?]
addressWpg::
* {2017-05-23} Yo-Banjo, How Etheroll and other Dapps will kill Ethereum, https://medium.com/@yobanjo/,
name::
* McsEngl.DnEthereum'problem,
* McsEngl.Ethereum-problem,
name::
* McsEngl.DnEthereum'scalability,
description::
"The Polkadot system is being built by Parity, the developers of Parity Ethereum client. Parity is a very strong team.
Polkadot will achieve scalability by having one main heartbeat chain, the Relay Chain, with multiple parachains hanging off it. Polkadot is scheduled to launch its Relay Chain mechanism in Q3 2019.
The Polkadot worldview sees ethereum connected as a potential virtual parachain via a bridge.
For any parachain to become attached to the Polkadot Relay Chain, it must be voted in by the holders of dots, the Polkadot system token.
These voters can also choose to pause a parachain, or remove a parachain from the system if it’s deemed to be out of compliance with what the majority prefers.
Effectively this is a permissioned system and whitelisting and blacklisting of entire parachain networks is a core tenet of the governance system of Polkadot.
One can imagine a parachain choosing to be permissionless in allowing anyone to upload a dapp, but ultimately the dot holders might take issue with this as they might be considered by authorities to be responsible. So it would probably be too dangerous of a policy for a parachain to offer.
It is likely that this will be a permissioned and a highly controlled blockchain platform."
name::
* McsEngl.DnEthereum'security,
addressWpg::
* {2017-11-09} Is Your Ether Frozen? Parity Launches Support Website In Wake of Exploit: https://www.coindesk.com/,
name::
* McsEngl.Ethereum-resource,
* McsEngl.DnEthereum'resource-(Ethereum-resource),
addressWpg::
* http://www.ethereum.org/ Main site,
* ETHDEV: https://ethdev.com
* https://github.com/ethereum,
* https://theethereum.wiki/,
=== NEWS:
* https://www.ethnews.com/,
* https://podcast.ethhub.io/: Into the Ether is an EthHub podcast focusing on all things related to Ethereum, the leading blockchain for decentralized applications. This podcast features in-depth discussions with prominent guests in the space hosted by Eric Conner as well as weekly news recaps featuring Anthony Sassano,
* {2018-06-04} James-Martin-Duffy, Ethereum Will Be the Backbone of the New Internet: Loom Network is building our Layer 2 on top of Ethereum, instead of other blockchain platforms — and here’s why, https://medium.com/loom-network/,
* {2018-05-29} Nikita-Savchenko, Ethereum Blockchain in a Real Project with 500k+ Users, https://hackernoon.com/,
* {2018-01-16} Vitalik Buterin Leaves China-Based VC to Focus on Ethereum Development: https://www.ccn.com/,
* {2017-11-14} https://blog.zeppelin.solutions/a-gentle-introduction-to-ethereum-programming-part-1-783cc7796094,
* {2017-11-02} 'A Modest Proposal': Vitalik Unveils Multi-Year Vision for Ethereum: https://www.coindesk.com/,
* {2017-06-27} Accounts, Transactions, Gas, and Block Gas Limits in Ethereum: http://hudsonjameson.com/,
* {2017-03-20} https://medium.com/blockchannel/tools-and-technologies-in-the-ethereum-ecosystem-e5b7e5060eb9,
* https://karl.tech/intro-to-ethereum/
* {2016-06-22} http://cointelegraph.com/news/ethereum-101-from-idea-to-release,
* http://cointelegraph.com/news/ ethereum-to-open-blockchain-research-center-in-russias-silicon-valley,
* yellowpaper: http://gavwood.com/Paper.pdf,
* whitepaper: https://github.com/ethereum/wiki/wiki/White-Paper,
* https://ethereum.gitbooks.io/frontier-guide/content/
* https://github.com/ethereum/wiki/wiki/Glossary,
* https://medium.com/boost-vc/boost-vc-is-now-investing-in-products-built- using-ethereum-79cd72b7bd71,
=== docs
* https://ethereum-homestead.readthedocs.org/en/latest/
* http://ethdocs.org/en/latest/
* https://forum.ethereum.org/
=== developer:
* https://dappsforbeginners.wordpress.com/
=== evaluation:
* http://cointelegraph.com/news/eight-months-since-release-ethereum-is-second-only-to-bitcoin,
name::
* McsEngl.DnEthereum'resource.book,
addressWpg::
* Mastering Ethereum, by Andreas M. Antonopoulos, Gavin Wood https://ethereumbook.info/, https://github.com/ethereumbook/ethereumbook,
* https://leanpub.com/decentralizedapplicationswithethereum,
description::
Ethereum Improvement Proposal. EIPs propose and describe changes made to Ethereum Protocol.
People wishing to submit EIPs first should propose their idea as an issue and then formalize it using a PR. After discussion it will be published here. Having an EIP here does not make it a formally accepted standard until its status becomes Active. For a EIP to become Active requires the mutual consent of the community. An EIP is not finalized until it has been implemented and is in use. Those proposing changes should consider that ultimately consent may rest with the consensus of the Ethereum users.
[https://github.com/ethereum/EIPs]
name::
* McsEngl.Ethereum-EIP-(Ethereum-Improvement-Proposal),
* McsEngl.DnEthereum'resource.EIP-(Ethereum-Improvement-Proposal),
* McsEngl.DnEthereum'EIP-(Ethereum-Improvement-Proposal),
* McsEngl.DnEthereum'Ethereum-Improvement-Proposal-(EIP),
* McsEngl.Ethereum-Improvement-Proposal-EIP,
* McsEngl.EIP-(Ethereum-Improvement-Proposal),
addressWpg::
* The EIP (Ethereum Improvement Proposal) system has been updated
- https://www.reddit.com/r/ethereum/comments/5rp8mr/ update_to_eip_ethereum_improvement_proposal_system/
name::
* McsEngl.Ethereum-ERC-(Ethereum-Request-for-Comment),
* McsEngl.DnEthereum'resource.ERC-(Ethereum-Request-for-Comment),
* McsEngl.DnEthereum'ERC-(Ethereum-Request-for-Comment),
* McsEngl.DnEthereum'Ethereum-Request-for-Comment-(ERC),
* McsEngl.ERC-(Ethereum-Request-for-Comment),
addressWpg::
* https://github.com/ethereum/EIPs/issues/16,
* https://en.wikipedia.org/wiki/Request_for_Comments,
description::
Doing is any internal and as a whole (=service) doing.
[hmnSngo.2017-02-12]
name::
* McsEngl.DnEthereum'doing,
description::
In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.
[https://github.com/ethereum/wiki/wiki/White-Paper#applications]
===
The Ethereum platform itself is featureless or value-agnostic.
Similar to programming languages, it is up to entrepreneurs and developers to decide what it should be used for.
However, it is clear that certain application types benefit more than others from Ethereum’s capabilities.
Specifically, ethereum is suited for applications that automate direct interaction between peers or facilitate coordinated group action across a network.
For instance, applications for coordinating peer-to-peer marketplaces, or the automation of complex financial contracts.
Bitcoin allows for individuals to exchange cash without involving any middlemen like financial institutions, banks, or governments.
Ethereum’s impact may be more far-reaching.
In theory, financial interactions or exchanges of any complexity could be carried out automatically and reliably using code running on Ethereum.
Beyond financial applications, any environments where trust, security, and permanence are important – for instance, asset-registries, voting, governance, and the internet of things – could be massively impacted by the Ethereum platform.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]
name::
* McsEngl.DnEthereum'service,
* McsEngl.DnEthereum'usage,
* McsEngl.Ethereum-service,
specific::
The stated purpose of the Ethereum project is to "decentralize the web" by introducing four components as part of its roadmap: static content publication, dynamic messages, trustless transactions and an integrated user-interface.
Each of these services are designed to replace some aspect of the systems currently used in the modern web, but to do so in a fully decentralised and pseudonymous manner.
[https://en.wikipedia.org/wiki/Ethereum]
description::
The stated purpose of the Ethereum project is to "decentralize the web" by introducing four components as part of its roadmap: static content publication, dynamic messages, trustless transactions and an integrated user-interface.[5]
Each of these services are designed to replace some aspect of the systems currently used in the modern web, but to do so in a fully decentralised and pseudonymous manner.[6]
[https://en.wikipedia.org/wiki/Ethereum]
===
Driving Factors.
There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another.
This may be due to geographical separation, interfacing difficulty, or perhaps the incompatibility, incompetence, unwillingness, expense, uncertainty, inconvenience or corruption of existing legal systems.
By specifying a state-change system through a rich and unambiguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end.
Dealings in this proposed system would have several attributes not often found in the real world.
The incorruptibility of judgement, often difficult to find, comes naturally from a disinterested algorithmic interpreter.
Transparency, or being able to see exactly how a state or judgement came about through the transaction log and rules or instructional codes, never happens perfectly in humanbased systems since natural language is necessarily vague, information is often lacking, and plain old prejudices are difficult to shake.
Overall, I wish to provide a system such that users can be guaranteed that no matter with which other individuals, systems or organisations they interact, they can do so with absolute confidence in the possible outcomes and how those outcomes might come about.
[http://gavwood.com/Paper.pdf]
name::
* McsEngl.DnEthereum'doing.goal,
* McsEngl.DnEthereum'goal,
description::
In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.
[https://github.com/ethereum/wiki/wiki/White-Paper#applications]
specific::
* WeiFund.io,
description::
ENS is the Ethereum Name Service, a distributed, open, and extensible naming system based on the Ethereum blockchain.
ENS can be used to resolve a wide variety of resources. The initial standard for ENS defines resolution for Ethereum addresses, but the system is extensible by design, allowing more resource types to be resolved in future without the core components of ENS requiring upgrades.
[https://ens.readthedocs.io/en/latest/introduction.html]
name::
* McsEngl.ENS-(Ethereum-Name-Service),
* McsEngl.Ethereum-ENS-(Ethereum-Name-Service),
* McsEngl.Ethereum-Name-Service-(ENS),
description::
Whatever you do, join Colony.
Colony makes it easy for people all over the world to build companies together online.
[https://colony.io/]
description::
Many have come to believe that an open, trustless blockchain platform like Ethereum is perfectly suited to serve as the shared “back end” to a decentralized, secure internet - Web 3.0.
An internet where core services like DNS and digital identity are decentralized, and where individuals can engage in economic interactions with each other.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/web3.html]
name::
* McsEngl.evoluting-of-DnEthereum,
* McsEngl.DnEthereum'evoluting,
addressWpg::
* {2019-11-20} https://blog.ethereum.org/2019/11/20/ethereum-istanbul-upgrade-announcement/,
* {2019-09-25} Pooja-Ranjan, https://medium.com/ethereum-cat-herders/istanbul-testnets-are-coming-53973bcea7df,
* {2019-02-28} https://cointelegraph.com/news/ethereums-constantinople-st-petersburg-upgrades-have-been-activated,
* {2019-01-11} https://blog.ethereum.org/2019/01/11/ethereum-constantinople-upgrade-announcement/,
* {2017-10-12} Byzantium HF Announcement: https://blog.ethereum.org/,
* {2017-09-14} V-Buterin: A Prehistory of the Ethereum Protocol: http://vitalik.ca/,
{2019-05-16},
=== Ethereum-2.0 roadmap:
"Consensys published a detailed and revised roadmap for the Serenity phase on May 16, 2019. The new roadmap indicates that the integration of the Beacon Chain and the completion of Phase 0 is scheduled for this year. The further phases will then be implemented at intervals of one year. Ethereum 2.0 is expected to be fully operational in 2022."
[https://medium.com/altcoin-magazine/ethereum-2-0-consensys-publishes-roadmap-to-serenity-e1ce76fa34f2]
{2017-10-16},
=== Hard-fork Byzantium:
5th fork.
At block 4,370,000.
Metropolis is a planned Ethereum development phase that includes two hard forks: Byzantium and Constantinople.
[https://cointelegraph.com/news/ethereum-hard-fork-byzantium-launches-without-a-hitch-ether-price-up]
{2017-12-04},
=== Scalability-problem:
Loveable Digital Kittens Are Clogging Ethereum's Blockchain
[https://www.coindesk.com/loveable-digital-kittens-clogging-ethereums-blockchain/]
{2016.07}
=== Ethereum’s successful hard fork, Coinbase integration
The partial price and market cap recovery can be traced to Ethereum’s successful hard fork. The fork was agreed upon in response to the DAO hack, which resulted in the theft of a large amount of Ether. A proposed hard fork in the currency, isolating the stolen funds and rendering them without value, was readily agreed to by the Ethereum mining community and subsequently implemented, restoring confidence, and with it, value.
Additionally, cryptocurrency exchange/wallet provider/merchant solution Coinbase recently announced Ethereum integration, solidifying the currency’s place as being respected by the cryptocurrency “establishment.”
[https://cointelegraph.com/news/ethereum-shoots-up-as-bitcoin-drops-below-80-market-dominance]
{2015.11}
===
With the widening interest beyond the core Ethereum community, it was time to spread our collective wings to help the rest of the world see the same ideas that many early adopters had. Following a short delay, DEVCON1 was announced to take place in London, England for a week in November 2015. Almost 400 people joined together at this location for an entire week, totaling 80 talks and topics about the Ethereum ecosystem.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{2015-07-30},
=== FRONTIER
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Đapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
{2014.11}
===
Only two months later, in November 2014, the majority of the Ethereum project team was assembled and descended upon Berlin to participate in the first Ethereum conference: DEVCON0. Although many had spoke via Skype, this was a time when most of the project members met for the first time. At this proto-conference, in a modest but beautiful space, developers took turns standing in front of peers explaining their vision for any given segment of the many protocols that would be necessary to develop “Web3”.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{2014.07}
=== ETHER INITIAL ALLOCATION:
Beginning in July 2014, Ethereum distributed the initial allocation of ether via a 42-day public ether presale, netting 31,591 bitcoins, worth $18,439,086 at that time, in exchange for about 60,102,216 ether. The results of the sale were initially used to pay back mounting legal debts and also for the months of developer effort that had yet to be compensated, and to finance the ongoing development of the Ethereum.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/history-of-ethereum.html#the-ethereum-foundation-and-the-ether-presale]
{2014-07-23}::
=== Ethereum presale:
Ethereum Raises 3,700 BTC in First 12 Hours of Ether Presale:
"The presold ether will be created in the Genesis Block around that time; until then, the 7.4 million ETHs already sold are just claims on coins that have yet to be created. The site’s wording is careful in saying that the presold ETH are neither a store of value nor shares in the company, wording that simply keeps the presale on the right side of the law."
https://cointelegraph.com/,
[hmnSngo.2017-09-26]
{2014.04}
===
By April of 2014, Dr. Gavin Wood published the Ethereum Yellow Paper that would serve as the technical bible and de-facto specification for the Ethereum Virtual Machine (EVM).
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{2014-01-25},
===
Ethereum was formally announced on January 25, 2014.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{2013}
Many of these took the form of “alt coins” - separate blockchains with cryptocurrencies of their own which improved on the original bitcoin protocol to add new features or capabilities.
In late 2013, Ethereum’s inventor Vitalik Buterin proposed that a single blockchain with the capability to be reprogrammed to perform any arbitrarily complex computation could subsume these many other projects.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html]
===
Buterin [2013a] first proposed the kernel of this work in late November, 2013.
Though now evolved in many ways, the key functionality of a blockchain with a Turing-complete language and an effectively unlimited inter-transaction storage capability remains unchanged.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
origing::
Ethereum was designed as a smart contract platform. Its origin is actually linked to a critique made by Vitalik Buterin on bitcoin as a very limited smart contract platform.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
description::
"Ethereum’s Serenity upgrade will bring Sharding, Proof of Stake, a new virtual machine (eWASM) and more. It’s important to understand that this upgrade will not take place at a single point in time - instead, it will be rolled out in phases."
[https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/]
===
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015!
Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Đapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
name::
* McsEngl.DnEthereum'2.0,
* McsEngl.DnEthereum'Serenity,
addressWpg::
* https://github.com/ethereum/eth2.0-specs,
* https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/,
description::
"Metropolis is a planned Ethereum development phase that includes two hard forks: Byzantium and Constantinople."
[https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/]
===
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Đapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
description::
Released 16.02.29, hard fork 16.03.14
[https://docs.google.com/presentation/d/1JKKef7NVjgtRZFsTcAteS4VtHG0aYu7TApZhWUENbWQ/edit#slide=id.gf6277fbfe_0_13]
===
Homestead is the second major version of the Ethereum platform and is the first production release of Ethereum. It includes several protocol changes and a networking change that provides the ability to do further network upgrades. The first version of Ethereum, called the Frontier release, was essentially a beta release that allowed developers to learn, experiment, and begin building Ethereum decentralized apps and tools.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/the-homestead-release.html]
===
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Dapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
description::
Frontier (Released 15.07.26, Genesis 15.07.30)
[https://docs.google.com/presentation/d/1JKKef7NVjgtRZFsTcAteS4VtHG0aYu7TApZhWUENbWQ/edit#slide=id.gf6277fbfe_0_13]
===
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Đapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
generic::
* Blockchain-program-blockchain-network,
* Proof-of-work-blockchain-network,
description::
The Morden testnet has been running since the launch of the Ethereum blockchain (July 2015). At that time, concerns about replay-attacks between Morden and Mainnet were addressed by using a nonce-offset. All accounts on Morden used a starting nonce of 2^20 instead of 0, ensuring that any transaction valid on one chain would not be valid on the other.
[https://blog.ethereum.org/2016/11/20/from-morden-to-ropsten/]
===
Morden
Morden is a name for one of the most popular public Ethereum TestNets. It is the same as the Ethereum network, but ETH on Morden is worth nothing. You can get ETH for free on Morden from many Morden "ETH faucets".
[https://karl.tech/learning-solidity-part-1-deploy-a-contract/]
description::
Before the current hard forks, there were already discussions about restarting the test network from a new genesis block in order to make full syncing simpler and less resource intensive. And due to the low difficulty of the testnet, the difficulty bomb was already causing noticeable increases in block times, which would continue to grow if unaddressed. So the time is now right to leave Morden behind and start a new test network.
[https://blog.ethereum.org/2016/11/20/from-morden-to-ropsten/]
name::
* McsEngl.Etc-Net,
* McsEngl.Ethereum.Classic-network,
addressWpg::
* {2016-09-27} https://cointelegraph.com/news/microsoft-supports-ethereum-classic-hosts-meetup-with-charles-hoskinson,
* {2016-07-28} http://www.coindesk.com/ethereum-classic-explained-blockchain/
* {2016-07-24} http://www.coindesk.com/ethereum-hard-fork-creates-competing-currencies-support-ethereum-classic-rises/
name::
* McsEngl.DnEthereum.private,
* McsEngl.DnEthereum.publicNo,
addressWpg::
* http://hypernephelist.com/2016/05/30/deploying-a-private-Ethereum-blockchain.html,
this webpage was-visited times since {2017-05-21}
page-wholepath: synagonism.net / worldviewSngo / dirTechInfo / blockchain-net / DnEth
SEARCH THE-PAGE::
This page uses 'locator-names', names that when you find them, you find the-LOCATION of the-concept they denote.
Type CTRL+F "McsLag4.words-of-concept's-name", to go to the-LOCATION of the-concept.
webpage-versions::
• version.last.dynamic: McsTchInf000018.last.html,
• version.3-0-0.2021-04-09: (2-44) ../../dirMiwMcs/dirTchInf/filMcsDbcnetEth.3-0-0.2021-04-09.html,
• version.2-0-0.2017-11-26.last: ../../dirMiwMcs/dirTchInf/filMcsDbcnetEth.2-0-0.2017-11-26.html,
• version.1-0-0.2017-10-16: ../../dirMiwMcs/dirTchInf/filMcsDbcnetEth.1-0-0.2017-10-16.html,
• version.0-7-0.2017-06-10.split: ../../dirMiwMcs/dirTchInf/filMcsBcnnetEth.0-7-0.2017-06-10.html,
• version.0-1-0.2017-05-21.created: ../../dirMiwMcs/dirTchInf/filMcsBcnnet.0-1-0.2017-05-21.html,