No content

What happened recently? Ethereum Constantinople Hard Fork is coming Tezos launched mainnet ProgPoW 

The Constantinople hard fork is supposed to be one of the final steps before Ethereum moves into the proof-of-stake stage. However, mining will continue for an indefinite period with a reduced reward. The Byzantium fork from October 2017 lowered the block reward from 5 to 3 ETH. 

Ethereum Constantinople Hard Fork • RopstenTestNet • Block #4200000 • 09.10.2018 (midday) EIP 145 - Bitwise shifting instructions in EVM
 EIP 1014 - Skinny CREATE2
 EIP 1052 - EXTCODEHASH opcode
 EIP 1283 - Net gas metering for SSTORE without dirty maps
 EIP 1234 - Difficulty Bomb Delay and Block Reward Adjustment Implementing 

EIP 145 - Bitwise shifting instructions in EVM EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Implementing SHL and SHR using arithmetics cost each 35 gas, while the proposed instructions take 3 gas. Backwards Compatible: The newly introduced instructions have no effect on bytecode created in the past. 

Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts. EIP 1014 - Skinny CREATE2 

This EIP specifies a new opcode, which returns the keccak256 hash of a contract’s code.
 
 The motivation behind this proposal - Contracts can presently do this using the EXTCODECOPY opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. The proposal is to introduce a new opcode, EXTCODEHASH, which returns the keccak256 hash of a contract’s bytecode. EIP 1052 - EXTCODEHASH opcode 

This EIP proposes net gas metering changes for SSTORE opcode, as an alternative for EIP-1087. It tries to be friendlier to implementations that use different optimization strategies for storage change caches. EIP 1283 - Net gas metering for SSTORE without dirty maps 

The average block times are increasing due to the difficulty bomb (also known as the “ice age”) slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately 12 months and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork. EIP 1234 - Difficulty Bomb Delay and Block Reward Adjustment 

ProgPoW Why? - ASIC resistantce When? * ~ eventually june 2019 PoC Drawbacks 

ProgPoW Ethash vs ProgPoW - differences and similarities PROGPOW_SIZE_CACHE data in L1 cache instead framebuffer ProgPoW Parameters 

The DAG is generated exactly as in ethash. The only difference is that an additional PROGPOW_SIZE_CACHE worth of data is generated that will live in the L1 cache instead of the framebuffer. Ethash requires external memory due to the large size of the DAG. However that is all that it requires - there is minimal compute that is done on the result loaded from memory. As a result a custom ASIC could remove most of the complexity, and power, of a GPU and be just a memory interface connected to a small compute engine. ASIC RESISTANT Drawbacks for now: 20x times slower block verification 

Tezos 

Michelson is a strict static typing and stack-based language. It looks like this 

No content

Workshop