Mining
Pages 145
- Home
- [Chinese] Ethereum TOC
- [Chinese] Ethereum 白皮書
- [English] Patricia Tree
- [English] White Paper
- [French] Ethereum TOC
- [German] Clearinghaus
- [German] Ethereum TOC
- [German] RLP
- [German] White Paper
- [Italian] Ethereum TOC
- [Italian] Impostare il proprio ambiente di sviluppo Ethereum
- [Italian] Introduzione allo sviluppo su Ethereum
- [Italian] Libro Bianco
- [Japanese] Ethereum Development Tutorial
- [Japanese] Liscence
- [Japanese] Cryptocurrency Current Problems
- [Japanese] Design Rationale (設計原理)
- [Japanese] Ethereum TOC
- [Japanese] HPOC_2015
- [Japanese] Javascript API
- [Japanese] Patricia Tree
- [Japanese] RLP
- [Japanese] Solidity Tutorial
- [Japanese] Whisper (ウィスパー)
- [Japanese] White Paper
- [Japenese] Ethereum TOC
- [Korean] White Paper
- [Persian] Ethereum TOC
- [Persian] White Paper
- [Portuguese] White Paper
- [Romanian] Cuprins
- [Romanian] Limbajul de programare Serpent
- [Romanian] Patricia Tree
- [Romanian] RLP
- [Romanian] White Paper
- [Romanian] Wire Protocol
- [Spanish] Ethereum TOC
- [中文] RLP
- [中文] Serpent指南
- [中文] 以太坊Wiki目录
- [中文] 以太坊开发计划
- [中文] 以太坊术语表
- [中文] 以太坊白皮书
- [中文] 网络状态
- [日本語版]ホーム
- Adaptive Message IDs
- Adaptive Peer Time
- Bad Block Reporting
- Bad Chain Canary
- Benchmarks
- Block Protocol 2.0
- Blockchain import and export instructions
- Brain Wallet
- Chain Fibers Redux
- Client Version Strings
- Contract metadata
- Contract Metadata Docs (NatSpec, ABI)
- Dapp Developer Resources
- Dapp using Meteor
- Default Extra Data Standard
- Design Rationale
- Deterministic_Wallet_Spec
- Distributed Preimage Archive
- enode url format
- Ethash
- Ethash C API
- Ethash DAG
- Ethash DAG Disk Storage Format
- Ethash Design Rationale
- Ethereum Chain Spec Format
- Ethereum Contract ABI
- Ethereum Development Tutorial
- Ethereum Natural Specification Format
- Ethereum Wire Protocol
- eπ Programme
- FAQ
- Geth Dapp loading proposal
- Gitter Channels
- Glossary
- HPOC_2015
- ICAP: Inter exchange Client Address Protocol
- IPv6
- JavaScript API
- JSON RPC
- JSON RPC Error Codes Improvement Proposal
- Kademlia Peer Selection
- libp2p Whitepaper
- Licensing
- Light client protocol
- Middleware and Dapp Project Ideas
- Mining
- Mist Troubleshooting Guide
- Mix Features
- Mix improvement proposal
- Mix: The DApp IDE
- Morden
- NatSpec Determination
- Natspec Example
- Network Status
- newBlockFilter Improvement Proposal
- Node discovery protocol
- Open positions & Schemes
- Parallel Block Downloads
- Patricia Tree
- Poll for token proposal EIP 20
- Problems
- Proposal: Extend GetBlockHashes with target hash
- Proposal: NewBlockHashes
- Proposal: Reversion Notification
- Proposal: Transaction Proxy Hooks
- Raspberry Pi instructions
- Registrar ABI
- RLP
- RPC Testing
- Security Categorization
- Security Issue Process
- Serenity_Wishlist
- Serpent
- Serpent_3.0
- Solidity
- Solidity Changelog
- Solidity Features
- Solidity standard library
- Solidity Tutorial
- Solidity, Docs and ABI
- Standardized_Contract_APIs
- Subtleties
- Swarm Hash
- The Solidity Programming Language
- URL Hint Protocol
- Useful Ðapp Patterns
- web.js 0.9
- Web3 Secret Storage Definition
- What is Ethereum
- Which Client?
- Whisper
- Whisper Overview
- Whisper PoC 2 Protocol Spec
- Whisper PoC 2 Wire Protocol
- Whisper Wire Protocol
- White Paper
- ÐΞVp2p Wire Protocol
- Руководство по Solidity
- شركة المنارة
- Show 130 more pages…
Basics
Ethereum Clients
ÐApp Development
- ÐApp Developer Resources
- JavaScript API
- JSON RPC API
- Solidity
- Solidity Features
- Useful Ðapp Patterns
- Standardized Contract APIs
- ÐApp using Meteor
- Ethereum development tutorial
- Mix Tutorial
- Mix Features
- Serpent
- LLL
- Mutan
Infrastructure
- Morden Testnet
- Chain Spec Format
- Inter-exchange Client Address Protocol
- URL Hint Protocol
- NatSpec Determination
- Network Status
- Raspberry Pi
- Exchange Integration
- Mining
- Licensing
ÐΞV Technologies
- RLP Encoding
- RLPx Node Discovery Protocol
- ÐΞVp2p Wire Protocol
- ÐΞVp2p Whitepaper (WiP)
- Web3 Secret Storage
Ethereum Technologies
- Patricia Tree
- Wire protocol
- Light client protocol
- Subtleties
- Solidity, Docs & ABI
- NatSpec Format
- Contract ABI
- Bad Block Reporting
- Bad Chain Canary
- Extra Data
- Brain Wallet
Ethash/Dashimoto
Whisper
Misc
Introduction
The word mining originates in the context of the gold analogy for crypto currencies. Gold or precious metals are scarce, so are digital tokens, and the only way to increase the total volume is through mining it. This is appropriate to the extent that in Ethereum too, the only mode of issuance post launch is via the mining. Unlike these examples however, mining is also the way to secure the network by creating, verifying, publishing and propagating blocks in the blockchain.
- Mining Ether = Securing the network = verify computation
So what is mining anyway?
Ethereum Frontier like all blockchain technologies uses an incentive-driven model of security. Consensus is based on choosing the block with the highest total difficulty. Miners produce blocks which the others check for validity. Among other well-formedness criteria, a block is only valid if it contains proof of work (PoW) of a given difficulty. Note that in Ethereum 1.1, this is likely gonna be replaced by a proof of stake model.
The proof of work algorithm used is called Ethash (a modified version of Dagger-Hashimoto involves finding a nonce input to the algorithm so that the result is below a certain threshold depending on the difficulty. The point in PoW algorithms is that there is no better strategy to find such a nonce than enumerating the possibilities while verification of a solution is trivial and cheap. If outputs have a uniform distribution, then we can guarantee that on average the time needed to find a nonce depends on the difficulty threshold, making it possible to control the time of finding a new block just by manipulating difficulty.
The difficulty dynamically adjusts so that on average one block is produced by the entire network every 12 seconds (ie., 12 s block time). This heartbeat basically punctuates the synchronisation of system state and guarantees that maintaining a fork (to allow double spend) or rewriting history is impossible unless the attacker possesses more than half of the network mining power (so called 51% attack).
Any node participating in the network can be a miner and their expected revenue from mining will be directly proportional to their (relative) mining power or hashrate, ie., number of nonces tried per second normalised by the total hashrate of the network.
Ethash PoW is memory hard, making it basically ASIC resistant. This basically means that calculating the PoW requires choosing subsets of a fixed resource dependent on the nonce and block header. This resource (a few gigabyte size data) is called a DAG. The DAG is totally different every 30000 blocks (a 100 hour window, called an epoch) and takes a while to generate. Since the DAG only depends on block height, it can be pregenerated but if its not, the client need to wait the end of this process to produce a block. Until clients actually precache dags ahead of time the network may experience a massive block delay on each epoch transition. Note that the DAG does not need to be generated for verifying the PoW essentially allowing for verification with both low CPU and small memory.
As a special case, when you start up your node from scratch, mining will only start once the DAG is built for the current epoch.
Mining Rewards
Note that mining 'real' Ether will start with the Frontier release. On the Olympics testnet, the Frontier pre-release, the ether mined have no value (but see Olympic rewards).
The successful PoW miner of the winning block receives:
- A static block reward for the 'winning' block, consisting of exactly 5.0 Ether
- All of the gas expended within the block, that is, all the gas consumed by the execution of all the transactions in the block submitted by the winning miner is compensated for by the senders. The gascost incurred is credited to the miner's account as part of the consensus protocoll. Over time, it's expected these will dwarf the static block reward.
- An extra reward for including Uncles as part of the block, in the form of an extra 1/32 per Uncle included
Uncles are stale blocks, ie with parent 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. 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 allowed per block.
Ethash DAG
Ethash uses a DAG (directed acyclic graph) for the proof of work algorithm, this is generated for each epoch, i.e every 30000 blocks (100 hours). The DAG takes a long time to generate. If clients only generate it on demand, you may see a long wait at each epoch transition before the first block of the new epoch is found. However, the DAG only depends on block number, so it CAN and SHOULD be calculated in advance to avoid long wait at each epoch transition. geth implements automatic DAG generation and maintains two DAGS at a time for smooth epoch transitions. Automatic DAG generation is turned on and off when mining is controlled from the console. It is also turned on by default if geth is launched with the --mine option. Note that clients share a DAG resource, so if you are running multiple instances of any client, make sure automatic dag generation is switched on in at most one client.
To generate the DAG for an arbitrary epoch:
geth makedag <block number> <outputdir>
For instance geth makedag 360000 ~/.ethash. Note that ethash uses ~/.ethash (Mac/Linux) or ~/AppData/Ethash (Windows) for the DAG so that it can shared between clients.
The Algorithm
Our algorithm, Ethash (previously known as Dagger-Hashimoto), is based around the provision of a large, transient, randomly generated dataset which forms a DAG (the Dagger-part), and attempting to solve a particular constraint on it, partly determined through a block's header-hash.
It is designed to hash a fast verifiability time within a slow CPU-only environment, yet provide vast speed-ups for mining when provided with a large amount of memory with high-bandwidth. The large memory requirements mean that large-scale miners get comparatively little super-linear benefit. The high bandwidth requirement means that a speed-up from piling on many super-fast processing units sharing the same memory gives little benefit over a single unit.
Formal Requirements
TODO: Content from formal requirements doc.
Design Decisions Taken
TODO: Content from design decisions doc.
Infrastructure Overview
Mining will be accomplished in one of two ways: either on CPU (and possibly the GPU, to be confirmed) with the Mist client or on the GPU though a combination of the Ethereum daemon and sgminer.
An sgminer module for Ethash is expected to be released at some point during, but not necessarily before the Frontier Genesis.
JSON-RPC
Communication between the external mining application and the Ethereum daemon for work provision and submission happens through the JSON-RPC API. Two RPC functions are provided; eth_getWork and eth_submitWork.
These are formally documented on the JSON-RPC API wiki article.