User:Dbabbitt/Sandbox

From Wikipedia, the free encyclopedia

I feel like it is time for us to collect up all of the issues and decisions on Ethereum Economics that need to be made, catalog all possible solutions and start narrowing down and fixing design choices. This is an attempt to put together a skeleton of what needs to be done and decided.

I will introduce various issues one-at-a-time for comment. Even if you have no detailed comment, it would be valuable to see a yea or nay on each issue.

Please feel free to add issues.

I will collect and summarize discussion.

The first issue I would like to address is the general approach to design and development.



Approach and Design Principles

Agility: Start Simple and Build Layers of Complexity as Needed

Designing the mechanisms and operating rules of an economy (a chaotic, complex, dynamical system) to guarantee predictability and stability, from a top down perspective, is an intractable problem. A bottom up, constructive, iterative approach is the only feasible method of development.

Ethereum Economics should begin with simplest possible mechanisms and settings and evolve more sophisticated, layered mechanism over time as warranted. For example:

Transaction fees can be initially be fixed and determined by estimates of costs of network transmission, data storage, and data processing (facilities costs, hardware and electricity). During the initial period in which transaction fees are fixed, they will initially be very small to encourage use of the Ethereum network. As soon as possible, transaction fees will be made variable with price levels being set by market mechanisms.

Experimental Approach

While we are building a set of protocols and services and businesses, Ethereum will remain, in part, a research project for quite some time.

Experiments should be performed, both in simulation as well as well as within the actual system. A sort of A-B testing protocol can be developed for the latter approach.

Every Activity on the Network Should Have an Economic Consequence

One possible design principle would be that every operation on the network that has a cost, should be paid for. Sending a block to another node should have an economic consequence: perhaps the receiving node which requests the block should pay the sending node. Perhaps when a block is verified, the miner that solved the block should have to pay out a fee of decaying size to miners that provide confirmations of block solutions and, separately, confirmations of computation.

Modular Design with Loose Coupling

The different aspects of Ethereum Economics (Issuance Model, Security Model, Transaction Fee Model, Computation Fee Model, …) should be, as completely as possible, loosely-coupled, individual modules. Modularity will enable us to more easily fix bugs with fewer side-effects on other modules, and it may enable us to upgrade each module on its own schedule. So, for instance we could upgrade the Security Model with an improved hybrid proof-of-work/stake algorithm when warranted, with no direct effect on the Computation Fee model.

Loose coupling can be achieved in different ways. It could imply the operations in one module are orthogonal to operations in others. It could imply queued message passing between modules instead of direct calls.


Terminology

Ether - Ether (ETH) is the token used on the Ethereum network as a unit of account. It can be considered the cryptofuel that powers the Ethereum Application Engine.

Ether Address - An ETH or Ethereum Address is a string of characters that ETH can be sent from and to in the Ethereum Network. It represents the public key of a cryptographic private/public key pair.

      • We may choose to call this an account rather than an address.***

Ether Address Balance - Unlike the Bitcoin network, balances are stored for each address, reducing the processing required to determine a balance.

Contract. A contract represents the executable program (sequence of computational instructions) that is associated with each Ether address.

Eth-ASM. A low-level language consisting of a set of op codes with RPN-based syntax for programming Ethereum contracts. Contracts are carried as a payload by transactions and specified in this language. Ethereum Nodes compile and execute the contracts. (This used to be called EtherScript.)

Eth-LLL. A higher-level LISP-Like Language (LLL) for programming Ethereum contracts. Ethereum Nodes compile and execute the contracts. This language will likely evolve greater and greater functionality over time.

Eth-HLL. A high-level Python-like language for programming Ethereum contracts. Ethereum Nodes compile and execute the contracts. This language will likely evolve greater and greater functionality over time.

Ethereum Virtual Machine -

Economic Actor. An economic actor is a person, company, organization, bot, or contract (autonomous or controlled) that possesses an Ether address and corresponding private key.

Transaction - A Transaction represents the transmission of ETH from one address to another address. Transactions may carry additional payload in the form of messages or contract code. Transactions update address balances.

      • Should we allow an address to send to itself??? ***
      • Should we rename transaction to “message?”

Block - A Block is a structure that binds together a set of zero or more transactions.

Node - A Node is a client on the Ethereum network that minimally receives and forwards transactions. Nodes may have various degrees of complexity from bare bones wallet-only functionality to a full processing and archiving node. A single code base is maintained in each implementation language that may be configured to implement a sliding scale of Node features.

Wallet Node - A Wallet Node is a client on the Ethereum network that receives and forwards transactions. It shows balances related to a set of relevant addresses. It does not represent contract state.

Lightweight Node - A Lightweight Node is a client on the Ethereum network that receives and forwards transactions. It shows balances related to a set of relevant addresses and though it does not perform and contract computation in can receive and present contract state from other nodes that have done the computation.

Non-Mining Full Node - In addition to receiving and forwarding transactions, a Non-Mining Full Node processes all contracts and stores data for solved blocks from the genesis block in perpetuity. Some block data that is no longer necessary for processing future transactions may be pruned. This type of node does not perform any mining work, but it may perform validation of block solutions.


Full Node - In addition to receiving and forwarding transactions, a Full Node processes all contracts and stores data for solved blocks from the genesis block in perpetuity. Some block data that is no longer necessary for processing future transactions may be pruned. This type of node performs mining work to find block solutions and to verify block solutions found by other nodes.

Archiving Node - In addition to receiving and forwarding transactions, an Archiving Node processes all contracts and stores all data for all solved blocks from the genesis block in perpetuity.

Blockchain - The blockchain is a mostly sequential, time-organized, graph of blocks. It has a single, sequential chain structure as its backbone in which blocks are linked serially to their single parent block all the way back in time to the first block, called the Genesis Block. There may be one or more child blocks linked to a parent, but there will only be one child for each parent that ends up as part of the “Main-Chain.” Other branch chains may grow but will ultimately be abandoned. These other chains constitute subtrees of the parent block and perform the valuable function of further securing the ancestry of the block that extends the Main-Chain beyond the parent block.

Blockchain Tree - The Blockchain Tree is a tree graph of blocks routed at the Genesis Block.

Blockchain Heads - A Blockchain Head is the set of all leaves of the Blockchain Tree.

Main-Chain

Difficulty

Miner/Refiner - refine electricity into ether

Mining/Refining Pool

Sub-Tree

Uncle Block

Cousin Block

Patricia-Merkle Trie

Distributed Application (DApp)

Tx Pool

State (utxo set)



Main-Chain Block Creation Rate

To be written.


Calculation of Difficulty

To be written.


Transactions and Computation Fee Model

Transaction fees and computation fees are different notions and both are present in the system. Transaction fees should be separate from computation fees since there may be many transactions that have no associated contract triggered.

Fees in the system are not burned (destroyed) but redistributed to miners, since miners are the ones who are paying the expenses for processing transactions and contracts.

Transaction fees will initially be fixed and determined by estimates of costs of network transmission, data storage, and data processing (facilities costs, hardware and electricity).

During the initial period in which transaction fees are fixed, they will initially be very small to encourage use of the Ethereum network. Even below cost transaction fees will likely be acceptable to miners since they will be making the bulk of their revenue on block rewards and they will likely be supportive of initiatives that support growth of the Ecosystem.

As soon as possible, transaction fees will be made variable with price levels being set by market mechanisms. Miners will choose what fees they are willing to accept for processing a given transaction based on the nature of the transaction and economic actors will decide what size fees they are willing to pay for processing a given transaction. These two forces will converge on a dynamic, market clearing price.

It may be prudent to divide transaction fees into transaction relay fees (transaction forwarding or broadcasting fees) and mining fees (incentive fees for miners to include transactions in a block).

Computation fees will initially be fixed and determined by estimates of costs of data storage, and data processing (facilities costs, hardware and electricity).

During the initial period in which computation fees are fixed, they will initially be very small to development of DApps on of the Ethereum application platform. This will enable DApps to have artificially low costs of doing business in the early stage of their endeavor, and may enable them to develop in a less expensive environment so that if/when computation costs grow, they will be more mature businesses with greater chance of maintaining viability. Even below cost computation fees will likely be acceptable to miners since they will be making the bulk of their revenue on block rewards and they will likely be supportive of initiatives that support growth of the Ecosystem.

Eventually computation fees will be variable with price levels being set by the market.


Block Creation Model

Miners will be free to choose which transactions to include in their block solutions based on a combination of transaction fees and computation fees. Ideally policies will be loose during the early stages system operation and will grow tighter and more competitive over time. During the “easy acceptance” period, the Ethereum Core and/or the Ethereum Accelerator Group can maintain a set of miners with very inclusive policies.

New main-chain blocks will be created at a target rate of one per minute.


Ether Issuance Model

Ether will be continually issued at a target rate of YYY per main-chain block.

Issued ether, transaction fees and computation fees will be distributed to the miner that solves the main-chain-extending block, as well as to uncles and cousins in that block's parents sub-tree. 2/3 of the block reward will go to the solving miner and 1/3 will be distributed evenly among the uncles and cousins that were in existence at the time the solution was broadcast.

Issued ether, transaction fees and computation fees will not be mature and spendable for 120 blocks after the creation of the block in which the are found.


Security Model

The Security Model will be modular. For each block miners will execute one or more hybrid Proof-of-Work/Proof-of-X algorithms from a predefined selection of algorithms. The algorithm(s) to be used for each block will be determined far (120 blocks) in advance of when block processing begins so all miners are using the same criteria. Ethereum can begin with a single proof-of-work algorithm and upgrade the Security Model to add selections over time.


Verifying Proof of Work

Should all nodes be paid for verifying proof of work done for a solved block?


Blockchain Extension Algorithm and Blockchain Network Topology

It has been shown (Accelerating Bitcoin’s Transaction Processing -- Fast Money Grows on Trees, Not Chains, Yonatan Sompolinsky, Aviv Zohar) for Bitcoin, that greater transaction processing rate can be achieved with increased security if shallow subtrees are built as branches off the main-chain and allowed to contribute confirmations. This is the Greedy Heaviest-Observed Sub-Tree (GHOST) Protocol. A modified version of this protocol will be used for the Ethereum blockchain. As described by Sompolinsky and Zohar, uncles and cousins are not rewarded for contributing to the security of the ancestry of the main-chain block to which they are related. It may prove useful to reward uncles and cousins in Ethereum’s version of GHOST.


Computation Model

Should all miners have to run all computations in a solved block? There should be a way to limit the percentage of miners that have to do the full computations. Or should we treat the computations themselves as part of the proof of work?

Could verifying the computations of the most recently solved block be included as part of the proof of work for the current block. In this case, all miners, even the miner that solved the block, should have to redo the computations, checkpointing the state several times along the way based on a random number derived from the block solution. This latter requirement would ensure that the miner that solved the block would have to redo the computations along with every other miner, for fairness.

Should miners focus first on proof of work and once a block solution is found, then the winning miner must execute all triggered computation and broadcast this as well, in order to get the block reward. Some mechanism would have to be crafted to verify the computation and could involve the uncles and cousins if they have a stake in verifying the current block. There should be punishment for computations done by the winning miner that cannot be validated by the uncles and cousins (and others should no uncles or cousins exist). One side effect of having the miner do computational work after the block is solved is to make it less likely that that miner will solved the next block. And forcing the uncles and cousins to verify the block computations, even while all other nodes are busy working on solving the next block, will make it unlikely that an uncle or cousin will be involved in the solution of the next block.


Mining Algorithm

Create a mining algorithm that makes the development of pooled mining inefficient, except for p2pool-type mining.


Mining Difficulty Adjustment

TBW


Relation of Computational Work to Mining Work

[2/28/14 8:50:09 PM] Vitalik Buterin: > what are the other reasons for keeping computation such a low % of hashing? [2/28/14 8:50:15 PM] Vitalik Buterin: blocks must be easy to verify

[2/28/14 9:04:24 PM] Robert Sams: Right. So I'm coming round to the view that fees aren't a public good problem after all, but an economy of scale problem (a node with higher hashing then average has a lower equilibrium marginal fee, so he forces the average node to compute unprofitably). Problem made negligible by making comp small. So we need to set minimum fee high enough to achieve that. So that's our goal? Target comp as a% of pow?


To ASIC or not to ASIC?

Should we try to develop an ASIC-hard security model, or should we assume that ASICs are good (and maybe inevitable) in that they reduce power consumption and increase computational efficiency. It may become important to have very fast nodes to accomplish all of the computation required on Ethereum without introducing transaction processing delays.

Under the pro-ASIC scenario the Ethereum Core (EthCore) can pay to design an optimized, open source ASIC and the Ethereum Accelerator Group (EAG) can possibly manufacture and sell these without a large markup. The issue then becomes: How does the EAG distribute them fairly? Open sourcing the designs enables multiple fabs to build and sell them, turning them into a commodity (especially if Ethereum is manufacturing them and selling them without attention to maximizing profits).