Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Blockchain Developers Meetup #03

Blockchain Developers Meetup #03

hack - Blockchain Development and Consulting Agency

We are organizing the Blockchain Developers Meetup in our community in Bulgaria.

#03 - LiveCoding Workshop

Meetup group: https://meetup.com/blockchain-developers-meetup-bulgaria
website: https://hack.bg

Milen Radkov

October 03, 2018
Tweet

More Decks by Milen Radkov

Other Decks in Technology

Transcript

  1. 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.
  2. 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
  3. 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.
  4. 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
  5. 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
  6. 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
  7. 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
  8. ProgPoW Ethash vs ProgPoW - differences and similarities PROGPOW_SIZE_CACHE data

    in L1 cache instead framebuffer ProgPoW Parameters
  9. 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