Ethereum Blog https://ethereumblog.net Promoting a free, decentralized and open future Thu, 14 Sep 2017 14:36:33 +0000 en-US hourly 1 https://wordpress.org/?v=4.6.7 Geth 1.7 – Megara https://ethereumblog.net/2017/09/14/geth-1-7-megara/ https://ethereumblog.net/2017/09/14/geth-1-7-megara/#respond Thu, 14 Sep 2017 14:36:33 +0000 https://ethereumblog.net/?p=3904 The Go Ethereum team is proud to announce the next release family of Geth, the first incarnation focusing on laying the groundwork for the upcoming Metropolis hard forks (Byzantium and Constantinople), consisting of 125+ code contributions for various parts of the project. Byzantium fork The current incarnation of Geth contains all the Byzantium EIPs implemented and […]

The post Geth 1.7 – Megara appeared first on Ethereum Blog.

]]>
The Go Ethereum team is proud to announce the next release family of Geth, the first incarnation focusing on laying the groundwork for the upcoming Metropolis hard forks (Byzantium and Constantinople), consisting of 125+ code contributions for various parts of the project.

Byzantium fork

The current incarnation of Geth contains all the Byzantium EIPs implemented and also features the fork block number 1,700,000 for the Ropsten testnet transition. The block numbers for Rinkeby and the main Ethereum network will be finalized when Ropsten is deemed stable.

You can find details about individual protocol updates at the following locations:

Performance optimizations

Aside from the Byzantium hard fork, the 1.7 release series of Geth is aimed to focus primarily on performance improvements. The first release of the family already packs a heavy punch with two database schema modifications resulting in significant optimizations:

  • Transaction and receipt storage was completely reworked, cutting the data storage requirements of a fast synced node in half, from 26.3GB to 14.9GB at the time of the implementation (#14801).
  • EVM log storage and indexing was completely reworked, cutting the filtering time of the entire chain for contract events by 2-3 orders of magnitude, from minutes to under a second (#14522, #14631).

Some work-in-progress updates that appear in the next releases include:

  • Upgrading the base peer-to-peer protocol used by all Ethereum sub-protocols, cutting the bandwidth needed for a fast sync from 33.6GB to 13.5GB (#15106). This upgrade will improve the general bandwidth requirement of the network as well as light clients too.
  • Introducing a more sophisticated memory caching for state tries, reducing disk IO by a couple orders of magnitude. Exact numbers are pending a final implementation (#14952).

Trezor wallets

About this time last year we introduced support for the Ledger hardware wallet. Due to popular demand, we’ve now expanded on hardware wallet support to include the Trezor (#14885).

Note that the Trezor is more complicated then the Ledger as it requires a PIN-unlock sent from the communicating machine instead of directly input by the user. As such, when a user plugs in a Trezor, Geth will print:

New wallet appeared, failed to open url=trezor://0003:0007:00 err="trezor: pin needed"

The Geth console can be used to unlock the Trezor by invoking personal.openWallet(url), which will request the user to enter the shuffled PIN code and send that over to the Trezor for verification:

> personal.openWallet("trezor://0003:0007:00")

Look at the device for number positions

7 | 8 | 9
--+---+--
4 | 5 | 6
--+---+--
1 | 2 | 3

Please enter current PIN:

INFO [08-10|11:58:06] New wallet appeared url=trezor://0003:0007:00 status="Trezor v1.5.0 'Hi' online"

For details on how to interact with the Trezor from the JSON-RPC APIs, please consult the PR description.

Transaction journal

In the 1.6.x release family of Geth we introduced a new transaction pool to avoid propagation issues due to minimum gas-price requirements. This new pool accepted all transactions regardless of pricing, and always kept the best paying 4K of them, discarding the cheaper ones.

The new pool features a special exemption mechanism for local accounts so that a user’s own transactions are always prioritized over remote ones, even if they are under-priced compared to everyone else’s. This ensures that cheap transactions don’t get flushed out of the network during heavy usage (e.g. ICO) as long as the originating node remains online.

Geth 1.7.0 takes this protective measure a step forward by journaling all locally created transactions to disk, and loading them back up on a node restart. This ensures that even if the originating node goes offline, cheap transactions still have a chance to be included when the node comes back (#14784).

The transaction journal can be an enormous help for node operators during software upgrades by not having to worry about local transactions going missing. Furthermore, the journal also acts as a resiliency mechanism against node crashes, ensuring that no transaction data is lost.

Rinkeby updates

There have been a lot of fine-tuning of Puppeth and Rinkeby over the course of this release, such as better ethstats logging to detect malicious reporters and IP address blacklisting to deny access for them.

The Rinkeby testnet also proved vital in finding and and fixing a transaction pool event race that caused a lot of headaches around lost transactions and/or duplicate nonce assignments. All such known errors have now been fixed (#15085).

Lastly we’re extremely happy to announce that Infura became an active player in the Rinkeby test network by aiding the community both with their own bootnode as well as running an authorized signer node. This should make the Rinkeby network even more robust and resilient.

Closing remarks and important note to users

Geth 1.7.0 contains a lot of bug fixes and we consider it our best release until now, however we urge everyone to exercise caution with the upgrade and monitor it closely afterwards as it does contain non-trivial database upgrades.

Furthermore, we’d like to emphasize that the upgraded database cannot be used by previous versions of Geth. Our recommendation for production users it to sync from scratch with Geth 1.7.0, and leave the old database backed up until you confirm that the new release works correctly for all your use cases.

For a full rundown of the changes please consult the Geth 1.7.0 release milestone.

As always, binaries and mobile libraries are available on our download page.

The post Geth 1.7 – Megara appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/09/14/geth-1-7-megara/feed/ 0
Roundup #5 https://ethereumblog.net/2017/08/23/roundup-5/ https://ethereumblog.net/2017/08/23/roundup-5/#respond Wed, 23 Aug 2017 10:34:51 +0000 https://ethereumblog.net/?p=3896 Development has steadily continued over the last month and a half as we approach the launch of Metropolis. Over a series of core dev calls over the last few months, we have specified and finalized the EIPs for Metropolis, and made the appropriate changes to the Yellow Paper. Metropolis has now been split up into […]

The post Roundup #5 appeared first on Ethereum Blog.

]]>
Development has steadily continued over the last month and a half as we approach the launch of Metropolis. Over a series of core dev calls over the last few months, we have specified and finalized the EIPs for Metropolis, and made the appropriate changes to the Yellow Paper. Metropolis has now been split up into two consecutive forks, named “Byzantium” and “Constantinople”. EIPs for Byzantium (Metropolis part one) are essentially finalized, and the last remaining work to be done has to do with writing tests and making sure that all clients are passing all tests.

The Ethereum network continues to see all-time highs in transaction usage, and the network has maintained stability through this period with consistently low uncle rates.

Research

  • Work on the Casper implementation has continued, and the Casper hybrid fork choice rule is now fully passing its initial test suite. Next steps include further testing, and integration into pyethapp.
  • Work on a sharding implementation in python has started in full force at the sharding repo, as we have added several new developers over the past few months to help with this. See the docs folder for a partial specification of the roadmap.
  • Work has started on a “testing language” which can be used to quickly write and run tests for proof of work, Casper and sharding fork choice rules. This should substantially improve coverage and accelerate testing for both Casper and sharding.
  • A co-authored Plasma whitepaper has been released. Multiple groups in the community have already expressed interest in creating implementations.
  • The research documents have been reorganized somewhat. See papers at https://github.com/ethereum/research/tree/master/papers and the problems list at https://github.com/ethereum/research/wiki/Problems.

Geth

Implemented the following:

Currently working on:

Mist

  • Mist has surpassed two million cumulative downloads for all versions. Version 0.8.10 (of both Mist and Wallet) have had over 830k downloads.
  • Mist 0.9 has been released, with some major features including support for Swarm upload and ENS supported urls.
  • The Ethereum Wallet has also been updated to support ENS on all address fields, including send and contract execution address fields. Tokens are easier to subscribe to by simply typing the three letter symbol.
  • The Mist repo now has over 800 open issues, including 700 new issues in the last few months. We are working on restructuring how to handle issues, as many of them are not individual issues but are requests for tech support.
  • Mist research has advanced, and now enables dapp development within a restricted subset of javascript that would allow running mist in a browser. We are working on releasing more details and a proof of concept in the coming month.

ENS

The weekend of August 11-13 in London was the first community-driven ENS workshop, where representatives of the community at large including representatives of multiple wallets, individuals working on ethereum projects and other ENS stakeholders discussed the current state and future of ENS. A summary post is available here, but here are some highlights:

  • The community is interested in seeing the next version of the ENS registrar focus on providing incentives to release unused domains, while minimising costs for users of ENS.
  • The community set priorities of creating a dispute resolution system as a voluntary second layer solution, and providing safeguards from impersonators and other security features to be built into multiple voluntary second-layer solutions.
  • There is a consensus on how domain owners can give safeguards to subdomain owners.
  • The community felt that some work should be attempted to improve the efficiencies of the domain reselling process.

Web3.js

In the last two weeks, web3.js beta was released and immediately and widely used by the community. A few packages already started integrating the new version into their libraries. Since the first beta release, issues were found and fixed and improvements have been added so that the beta is currently at beta.18.

Once web3.js 1.0 is ready for prime time, a separate blog post will introduce its new features.

To try it out yourself, either clone the 1.0 branch or install it via npm install web3@1.0.0-beta.18

Please add issues and suggested improvements to the GitHub issues.

Light Client

  • New LES/2 protocol version is being prepared.
  • Ultra-fast log history search has been implemented (needs LES/2 to work in light client mode).

C++

  • Metropolis changes are being finalized, and new precompiled contracts are being benchmarked.
  • The Hunter C++ package manager has been integrated into the project to increase portability.
  • A prototype of state snapshot support for C++ client is being prepared.
  • The ethminer was removed from the cpp-ethereum project. The new ethminer repo was created for the mining community. We are helping with the maintenance of the code, and building and distributing the binaries. The miner itself has been improved, and can switch work packages much more quickly.

Solidity

We added support for “experimental” features that can be switched on via a “pragma” statement in the source code. One of these features is the new ABI encoder, which can encode arbitrarily nested arrays! Another experimental feature that will soon be available is the automated verification of assertions and overflow conditions using an SMT solver. We also fixed two bugs in the code generator. Apart from that, we implemented many smaller changes that improve error messages, added new warnings and improved security. Lastly, work has begun on implementing view and pure function specifiers.

Remix

  • We are currently pushing a lot of refactoring and UI/UX changes.
  • In the near future, the master branch will be deployed to https://yann300.github.io/remix instead of remix.ethereum.org, allowing us to fix bugs and polish everything before pushing back to remix.ethereum.org.
  • Important note: Please do not use it for your normal development work as it isn’t stable yet. And feel free to comment it – https://gitter.im/ethereum/remix.

EVMJIT

Metropolis support was added to EVMJIT; all tests were passed. Also EVM-C has been updated to support new features for Metropolis, like support for REVERT and return buffers. The EVM-C interface is evolving slowly, but only VM trace support is missing to mark it as fully functional.

Swarm

While the swarm testnet has migrated to new hardware, the team is busy churning out the new features for our POC3 roadmap planned for after Metropolis. The team has been working on a devp2p network simulation and testing framework for the past nine months, and the module is now ready to merge to go-ethereum. PSS (bzz whispered), our new node-to-node messaging protocol, now fully incorporates whisper’s encryption module and supports remote peer sessions with Diffie-Helmann key exchange for udp-like protocols. The biggest component of our forthcoming release is the complete rewrite of the swarm network layer. As part of this endeavor, the connectivity (kademlia overlay topology) and the discovery (topology bootstrapping) components are ready to merge.

The final missing piece for a proper dropbox backend (to complement FUSE and ENS) is

chunk-level encryption for privacy. We came up with an elegant solution: the Keccak-Feistel blockcypher, which will be included in POC3.

The team has started working on the third orange paper describing generalised swap, swear and swindle games (courtroom contract suite) to drive decentralised services by providing scalable payment, incentivisation and service guarantees. Videos of talks from the Berlin Swarm Summit in June are available on the summit website on swarm http://swarm-gateways.net/bzz:/summit2017.ethersphere.eth/.

Whisper

  • Version 5 released.
  • Proposal for version 6: discussion in progress (EIP#627).

Ewasm

Ewasm itself is close to finished in its current form. Work on Hera, an implementation of Ewasm that is compatible with the VM API using in Ethereum C++, is being resumed since EVM-C interfaces matured significantly.

EthereumJS

Issues with handling large numbers and certain edge cases have been identified and fixed. Implementation of Byzantium changes is ongoing. The most challenging area is the elliptic curve pairing precompiles. To support these precompiles, we will use Zcash’s Rust implementation compiled to asm.js. There is also work being done to support the new tracing format and optimise the VM for speed.

EthereumJ

A team of two developers has started working on bringing EthereumJ up to compatibility with Byzantium in preparation for the first Metropolis hard fork.

Pyethereum

Some bug fixes have been made as well as updated to related libraries (eg. rlp.hex_decode and rlp.hex_encode in pyrlp). Metropolis EIPs are essentially implemented, and Byzantium state and block test compliance are continuing to improve.

Py-EVM

Py-EVM is a new implementation of the EVM written in python. The library is heavily influenced by the existing Pyethereum library, with the key difference being a more modular architecture.

Recent development includes:

  • Expansion of the test suite beyond the JSON-fixture based tests.
  • Implementation of EIP150 for rules.
  • Implementation of the DAO Fork rules.
  • Support for pluggable ECC signing backends.
  • Support for pluggable database backends.

Web3.py

Recent improvements to the library include:

  • New Middleware API.
  • Bug fixes related to string encodings.
  • Better error messaging for contract calls against non-existent contracts.
  • Validation of contract ABI.
  • Validation of ERC55 checksummed addresses.

Security

We have received numerous bug bounty submissions, and have awarded Juno Im with 5000 points for a Mist-vulnerability. A Solidity-bug regarding ecRecover has been patched (see https://github.com/ethereum/solidity/releases/tag/v0.4.14).

We are continuing to improving testing, using Hive and as well as fuzzing the various raw VMs, with internal state inspection after each opcode. See Testing (below).

New opcodes and precompiles in Metropolis are being benchmarked for finalization of gas costs.

Testing

We made a number of infrastructure improvements:

  • General Blockchain tests execute blockchain test cases on all fork rules.
  • General State Tests are convertible into blockchain tests in order to run on hive.
  • Blockchain tests can now be generated 20% faster.

Work in progress includes:

  • The consensus test suite ethereum/tests is almost up-to-date with the Metropolis EIPs. Only the two most recent changes remain to be applied (#684 preventing overwriting contract/contract collision and #649 Metropolis difficulty bomb).
  • Test format validator is finding many mistakes in json tests files, gradually applying looser rules to stricter rules.

We are also exploring more advanced techniques and closer collaboration with the community:

  • Fuzz tests research has progressed.
  • Random test generation in progress is already discovering issues between clients.
  • The test contributor program has resulted in community contribution to the tests repository.

Viper

Viper has seen substantial progress over the last month and a half, and contributions from outside contributors are increasing. New security features such as payable and internal modifiers have been added, along with more tests, and the language now also has support for accepting and returning fixed-size lists as inputs and outputs.

See the https://github.com/ethereum/viper/blob/master/README.md and commit history for a changelog.

Bamboo

Bamboo is a programming language for Ethereum contracts.  At the end of July, the first release of Bamboo became available in the OCaml package manager opam install bamboo.  Bamboo is now capable of implementing a simple payment channel and an ERC20 token. Moreover, a few contributors have started working on both enhancements and as well as documentation.

Eth-Isabelle

Eth-Isabelle specifies the Ethereum Virtual Machine for theorem provers such as Isabelle/HOL and Coq. The project received substantive pull-requests. Separation logic tactics from @seed shortens many proofs by half. The proof that a non-owner cannot harm a wallet is more structured than ever. An independent JULIA interpreter by @mrsmkl serves as an executable specification of JULIA (an intermediate language in the Solidity compiler). It would be fruitful to test this interpreter against the implementation. This interpreter can also be used as a basis for a proven-correct compiler from JULIA to EVM.

For testing eth-isabelle with BlockchainTests, ECDSA recover was needed in OCaml, so @pirapira made a contribution.

Yellow Paper

The pull-requests for Metropolis are up-to-date although the pull-requests need to be classified into two phases: Byzantium and Constantinople.

The post Roundup #5 appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/08/23/roundup-5/feed/ 0
Statement Objecting To EME as a W3C Recommendation https://ethereumblog.net/2017/08/21/statement-objecting-w3c-publishing-eme-recommendation/ https://ethereumblog.net/2017/08/21/statement-objecting-w3c-publishing-eme-recommendation/#respond Mon, 21 Aug 2017 13:59:58 +0000 https://ethereumblog.net/?p=3855 The Foundation believes Encrypted Media Extensions (EME) should not be published as a W3C Recommendation, and we are now making public the formal objection the Ethereum Foundation submitted to the W3C opposing the recommendation of EME. As a member of the W3C, the Ethereum Foundation contributes to the standards-making process and votes on matters such as the […]

The post Statement Objecting To EME as a W3C Recommendation appeared first on Ethereum Blog.

]]>
The Foundation believes Encrypted Media Extensions (EME) should not be published as a W3C Recommendation, and we are now making public the formal objection the Ethereum Foundation submitted to the W3C opposing the recommendation of EME.

As a member of the W3C, the Ethereum Foundation contributes to the standards-making process and votes on matters such as the EME recommendation. Many developers and researchers at the Ethereum Foundation conduct security research and build software that use web technology, and from that perspective, we have objections to EME as well as Digital Rights Management (DRM) in general. Most if not all people who use web browsers are affected by EME.

The direct result of EME’s success up until now, is that browser developers have already installed potentially insecure DRM technology since there were no options to disable it in any of the major browsers. Even though EME was only recently approved as a recommended standard, closed-source DRM implementations have been present in our browsers, even open-source browsers such as Firefox, for many years.

As developers, researchers and community members, we have already been subjected to objectionable DRM implementations and we believe efforts should be made to stem further adoption. In other words, we feel the recommendation of EME as a standard is a move in the wrong direction as it inhibits the Open Web, and is inconsistent with the core values, mission and design principles of W3C. The statement published below sets out the reasons for Ethereum Foundation’s objections and why we feel the W3C should not continue with a recommendation of EME as a W3C standard.


The following statement was submitted to the W3C with a Formal Objection on April 13, 2017. Please note that edits have been made for clarification and legibility purposes.


The Ethereum Foundation respectfully opposes publishing Encrypted Media Extensions (EME) as a Recommendation and requests that this effort be discontinued.
The Ethereum Foundation aims to build a more globally accessible, more free, and more trustworthy Internet. We cannot work to fulfill our mission without objecting to EME. If recommended by the W3C, EME and the Content Decryption Module (CDM) implementations it sanctions, will reduce accessibility, curtail freedom on the Internet, undermine security research, and even erode trust among users and developers in the greater Internet community. If recommended, EME will also violate many important aspects of W3C’s own mission statement and design principles.

Problem: EME addresses use-cases outside of the domain of the Open Web.
The W3C has historically provided Recommendations for the Open Web platform. However, W3C’s specification of this manner of interaction, such as the one with DRM, is unprecedented and poses a concern, especially as it supports an opaque, non-open technology. What policies are in place to limit this expansion of the W3C’s Recommendations into the non-open web? Software that is both outside of the W3C mission and also highly objectionable to large numbers of W3C members should not be addressed by W3C Recommendations.

Problem: EME-specified DRM impedes legitimate use, with little gained as a result.
We believe that the benefits gained by owners of media from DRM implementations are not worth the limitations experienced by users. DRM does not offer much to hinder copyright infringement. Copyright infringers will not likely evade DRM if the media they want is widely available through alternative sources. While offering few copyright protection benefits, DRM denies users valuable functionality including extending, commenting on, annotating, modifying content for artistic reasons, or modifying content to enable access for people with disabilities. All of these uses, normally held in high regard in the W3C Recommendation process, are blocked by DRM.

We feel W3C Recommendations should not specify, even if indirectly through EME, the implementation or enabling of software that blocks legitimate functionality for users.

Problem: EME does not grow the web.
We believe that the long-term growth referred to in the mission statement of the W3C largely refers to the potential for the web to be used in new and unforeseen ways. EME’s contribution to growth only benefits non-extensible, non-interoperable, non-open web content, which does little for network effects. The growth mission of the W3C is therefore not served if EME becomes a Recommendation.

Problem: EME undermines security.
In order to maintain a secure Open Web, security researchers must be able to perform their work in both a technical and a legal sense. By officially making a Recommendation, W3C compels security researchers to perform security analyses of all major implementations of that Recommendation. In recommending EME, the W3C is therefore exposing legitimate security researchers in the community to potential legal liability and even prosecution in the United States.

We understand and appreciate the serious efforts made by members of the HTML Media Extensions Working Group to address the exposure of security researchers. However, consensus could not be reached about an Electronic Frontier Foundation (EFF) proposed covenant in which W3C members and their affiliations would agree to “non-aggression” with respect to bringing 17 U.S.C. § 1203 actions against security researchers.

If anything, now is a time the W3C should take a stronger position to defend legitimate security research when Internet users around the world feel less secure and less protected than ever.

Problem: EME constrains the web to follow specific existing business models rather than to enable new forms of interaction.
The outcome of implementing DRM in web browsers would essentially set as a standard, the current proprietary systems and the related ways they interact with users and sell media. EME would inhibit potential models of a future decentralized web where blockchains and decentralized technologies could enable new business models and property rights management.

By recommending EME, the W3C is encouraging browser vendors to install software that lacks transparency and disclosure to the user, which is counter to the tradition of the Open Web and what many people hope the next generation of technology will bring.

The W3C must be guided by its mission, design principles, and values.
A Recommendation by the W3C carries a lot of weight. We feel the organization should therefore not specify nor guide technologies such as DRM that do not conform to the W3C’s core values as expressed in its mission and design principles, especially when the technology in question undermines security, limits legitimate use, and offers little potential for expanding the web.

The post Statement Objecting To EME as a W3C Recommendation appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/08/21/statement-objecting-w3c-publishing-eme-recommendation/feed/ 0
Roundup Q2 https://ethereumblog.net/2017/07/08/roundup_q2/ https://ethereumblog.net/2017/07/08/roundup_q2/#respond Sat, 08 Jul 2017 00:03:25 +0000 https://ethereumblog.net/?p=3851 Thanks to all the developers and team leads who contributed to the sections on their projects In the last month and a half, the Ethereum network went through a rapid growth in usage, to the point that it now processes as many transactions per second as Bitcoin. To accommodate the increased load, which has on […]

The post Roundup Q2 appeared first on Ethereum Blog.

]]>
Thanks to all the developers and team leads who contributed to the sections on their projects

In the last month and a half, the Ethereum network went through a rapid growth in usage, to the point that it now processes as many transactions per second as Bitcoin. To accommodate the increased load, which has on a few occasions reached the network’s full capacity for hours at a time, the community independently came together and miners voted to increase the gas limit to 6.7 million. We at the Foundation have been rapidly putting additional resources toward increasing the efficiency of the network, alongside planning longer-term changes that will greatly increase the network’s scalability.

Research

The pyethereum client has seen a substantial revamp, and version 2.0 has been released. See https://pypi.python.org/pypi?:action=display&name=ethereum&version=2.0.4 for download; in Ubuntu you can also do “sudo pip install ethereum”. Additionally, we have implemented experimental versions of:

Metropolis testing

Metropolis testing is rapidly moving forward. We are actively seeking additional help with finishing testing. See:

We have started a substantial cross-client benchmarking effort to identify places that are in greatest need of performance improvement. See some preliminary results for opcode benchmaking in geth here: https://gist.github.com/holiman/7b157e4074707f6ba3196d46ad3745af

Ethereum core developer meetings #15-#19 took place. Notes and audio/video of the meetings can be found here: https://github.com/ethereum/pm/tree/master/All%20Core%20Devs%20Meetings

Mist team

In May-June, the Mist team had a team meetup: for one week the team had face to face meetings, some members for the first time, in which we sat together to share details on projects we were working on and to talk about the current codebase and future roadmap. While we have a long list of features we are working on, we realized that most of the issues reported on github were related to two main issues: slow synchronization and lost account private keys/passwords. We outlined features that we could implement to help prevent user errors and other related issues, including more options for node switching (including Infura support) and better options for account management (including HD wallets and mnemonic seeds – but with a twist).

  • Many of those new issues require some changes on how the signing process is done to make Mist more independent of Geth, which is being worked on as a standalone signer.
  • We have also done some research on refactoring parts of the Mist codebase to make it more modular and easier to maintain.
  • Victor Maia presented some research on how to make apps load quicker and be more reliable and we are currently testing some of these concepts as either pieces of the main codebase and/or an alternative web-based product.
  • Progress has been made on ENS integration: we have added ENS support to our address component, meaning that any of the apps we have built in meteor (wallet and ens registrar app) will accept a name in any field where it would usually expect an ethereum address. We are also working on making a web component for generic input types for ethereum addresses, so any webapp developer can use an input field with support for ENS, checksum and ethereum identicons. With swarm now using the main net registrar, it also means that Mist will accept ENS addresses on the url as soon as the swarm branch is merged..
  • Swarm integration has been tested and is a lot more stable than it has been even a few weeks ago. We predict it will finally be ready to release soon.

Web3.js

Web3.js is  coming along well. The new whisper API was recently added to the old 0.x.x and the new 1.0.0 version. Whisper v5 is currently only available in geth and needs to be started using –shh.  We are currently adding swarm.js and finishing the JavaScript account management. If everything goes well, an alpha release will happen soon.

You can already test the new web3.js 1.0 here: https://github.com/ethereum/web3.js/tree/1.0, and read the new docs at http://web3js.readthedocs.io/en/1.0/

Security

We have received several bounty submissions for vulnerabilities in EthereumJS, Solidity and Cpp-ethereum. See the leaderboard for the current stats.

We now have pyethereum on board on the cross-client blackbox consensus testing in Hive, which continuously performs over 10K tests on each client. See http://hivetests.ethereum.org. As a lightweight alternative to Hive, we’ve also started a project to perform fuzz testing directly on the virtual machines, starting with Geth, Parity and Python. In the same vein, we’ve also set up an automated AFL-based fuzzing of Solidity.

In preparation for Metropolis, a benchmarking suite for the Geth EVM has been implemented to ensure that the gas prices for new opcodes and precompiles are within reasonable bounds, so as to not constitute DoS-vectors at a later point.

EVM 1.5

The “EVM 1.5” proposals are now EIP drafts for “Subroutines and Static Jumps for the EVM #615,” and “SIMD Operations for the EVM #616”.  Discussion and critique are welcome at the https://github.com/ethereum/EIPs/issues/615 and https://github.com/ethereum/EIPs/issues/616 conversations.

EthereumJS

The ethereumJS team is still looking for community contributors to help the Ethereum Javascript client reach Metropolis compatibility. A video walkthrough “Intro to Core Development with Ethereumjs-vm” has been released.

Light Client

New algorithms have been designed and implemented in order to improve log searching performance in the next version of the LES protocol. Promising R&D work has been done toward achieving quick and trustless initial syncing without hardcoded checkpoints. We have put some efforts into finalizing the topic discovery protocol, which helps clients to find suitable LES servers as it is currently a somewhat weak point in the experimental light client service.

Remix

The main Remix feature in the last month is the alpha release of Remixd: https://github.com/ethereum/remixd

Formal Verification

The progress in the eth-isabelle project was mostly from external contributions. In particular,  the better separation logic tactics, which were externally contributed allow much shorter proofs about Ethereum contracts.

  • Better separation logic tactics (contributed)
  • Coq build fixed, and added in the continuous integration
  • Removing unmaintained files, and `Annotation` structure not needed anymore (PR pending)
  • Running Blockchain Tests (in progress; ecdsa recover implementation in OCaml wanted).

Bamboo

  • The compiler is generating bytecode for all initial examples
  • Syntax perfection following community feedback
  • End-to-end testing of the compiler (in progress)

Solidity

The Solidity project has been quite active in the last months, although most of the updates is not yet directly visible on the user side. We saw a lot more engagement by the community and now have volunteers regularly contributing both to the core code as well documentation including translation, mainly into Spanish.

 

We added a feature that allows export of the full abstract syntax tree with all type annotations, which makes it much easier to write tools that would otherwise need a custom-made parser. The next feature will be to also re-import this data after potential modifications, which would allow things like mutation testing.

We extended the inline assembly language with structured elements (for, switch and functions) and deprecated manual jumps. This new inline assembly language will become a new intermediate language (together with type information), which allows Solidity to be more transparent in its compilation, more efficient (we will be able to add much more sophisticated optimizer routines) and more portable (it can already compile to EVM, EVM1.5 and some eWASM). We are currently rewriting the ABI encoder in this intermediate language which will include structs and nested dynamic objects.

Finally, we are adding an automated compile-time overflow and assertion checker which will also feature an SMT solver for the more complicated cases. Oh and of course, we have worked on tons of bugfixes and smaller features.

Swarm

The swarm team has onboarded new members and held an in-person Swarm Summit in Berlin in June, 2017. The week-long event brought together Ethereum team members, community contributors andspecial guests representing projects and companies interested in swarm. More than twenty talks and tutorial sessions were recorded. The edited videos will be published soon on the swarm summit website. Our public alpha test saw a great community response allowing us to gather more information on prospective user base needs and what the typical usage patterns might be. The high churn of nodes requires an explicit distinction between nodes that can and cannot commit to being available for a longer period of time to provide sufficient storage and bandwidth resources for the network. To support noncommiting nodes and mobile clients, swarm will offer various light modes of operation.

We have developed a suite of example applications highlighting the architectural and implementational peculiarities of Swarm-hosted distributed web applications that are quite a departure from the traditional client-server model. In particular, the building blocks of a distributed functional equivalent of dropbox are being developed, such as a web-interface providing a file-system view of swarm-hosted volumes, ENS integration, Mist-integration, FUSE mounting of swarm-volumes and privacy protections.

We added a new protocol, pss (bzz whispered) allowing internode messaging with deterministic routing based on the relaying kademlia network topology of swarm. The protocol uses whisper envelopes and offers udp-like protocol communication between nodes that are not directly connected.

Furthermore, we have developed a network testing and simulation framework in which we can model and benchmark a broad range of scenarios emerging from the interaction of a potentially large number of  nodes. This framework includes both scripting and visualization capabilities.

In cooperation with the Remix team, the implementation of a fully distributed integrated contract development environment is underway.

The next major release, POC 0.3 is scheduled to come out around Metropolis and will include  obfuscation support for plausible deniability, a rewrite of the swap peer-to-peer accounting for bandwidth incentivisation among other things.

The post Roundup Q2 appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/07/08/roundup_q2/feed/ 0
Roundup Round III https://ethereumblog.net/2017/05/24/roundup-round-iii/ https://ethereumblog.net/2017/05/24/roundup-round-iii/#respond Wed, 24 May 2017 15:04:21 +0000 https://ethereumblog.net/?p=3844 Over the last month and a half we saw vigorous ongoing research and development on all sides of the Ethereum roadmap, and progress is rapidly starting to translate into real results that can be run and verified inside of an Ethereum client. On Metropolis: Agendas for core dev meetings 15 and 16 here: https://github.com/ethereum/pm/issues/13 and […]

The post Roundup Round III appeared first on Ethereum Blog.

]]>
Over the last month and a half we saw vigorous ongoing research and development on all sides of the Ethereum roadmap, and progress is rapidly starting to translate into real results that can be run and verified inside of an Ethereum client.

On Metropolis:

  • Agendas for core dev meetings 15 and 16 here: https://github.com/ethereum/pm/issues/13 and https://github.com/ethereum/pm/issues/14
  • List of accepted EIPs here: https://github.com/ethereum/EIPs/blob/master/README.md (mostly agreed on, though we are still going back and forth on details such as gas costs)
  • Most of the EIPs have been implemented in C++ and Python and are being implemented in other clients; tests are being actively written and added here https://github.com/ethereum/tests/tree/develop/GeneralStateTests (see the various branches for different tests)
  • Clients that have not implemented GeneralStateTests could provide a docker image for   Hive testing (contact Martin Swende). All GeneralStateTests are being converted into BlockChainTests and run on Hive.
  • A release date has still not been finalized; the general consensus is to wait until all tests are passing on major clients before setting one. Because of the rapid increases in block difficulty, the ice age continues to be delayed; current prognosis assuming no further increases (arguably a very pessimistic estimate) is that block times will not exceed 20s until July 12, and will not exceed 30s until Sep 12.

The Ethereum blockchain has hit several new all-time highs:

  • Difficulty (450 TH) and hashrate (28.5 TH)
  • Transactions per day (187115, or ~2.16 per sec)
  • Gas usage per day has not yet reached the all-time high of Jun 18, when the blockchain was heavily spammed as part of the DAO attack and various counterattacks, but is nearing it with an 11-month high of 10.7 billion per day. That’s 1991878 gas per block, or ~45% full blocks for the day (reminder: gas limits are dynamically adjusting, so congestion with rapidly increasing fees is not likely) . Uncle rate on that day was only ~7.4%.

On various side projects:

  • ENS has been deployed, and auctions are ongoing.
  • Whisper is getting a proper API, which is in alignment with our general RPC, the API should be ready soon and a workable whisper version will be released.
  • Swarm has made a number of significant improvements, including (i) supporting directory upload and download via the http interface, (ii) full FUSE support, (iii) a new protocol pss for node-to-node messaging, (iv) replacing the chunk hash with a Merkle tree hash to enable more efficient data inclusion proofs. Progress toward POC3 is going at full steam.

Pyethereum development has picked up quickly:

  • Jan Xie and his team have successfully synced a pyethapp node to the most recent block on the mainnet.
  • Several bugs in the implementation have been fixed, and the client is now passing all state tests and most pre-Metropolis blockchain tests. Work to find the remaining issues is ongoing.
  • Most Metropolis EIPs have been implemented, including the four new precompiles.
  • The tester module has been revamped so that it is fully based on the Chain module, and a new and more convenient interface has been added, including functionality such as creating state tests.

Casper research is now in the process of fine-tuning the incentives for liveness, and implementing the logic inside of pyethereum. This includes:

Other research stuff:

Geth development:

  • Removed the artificial 20 shannon minimum gas limit from the transaction pool, enabling Geth nodes to accept and relay arbitrarily priced transactions. This should help enable a real gas market.
  • Identified a sync regression for HDD users, resulting in a heavy rewrite of fast sync code, making it much more robust and stable.
  • Identified and fixed a few EVM bottlenecks, causing complex contracts to execute up to 60% faster doing up to 95% less memory allocations.
  • Polishing the light client and its mobile bindings in collaboration with Status, Walleth and others. Preliminary proof-of-concept done for light client event retrievals.
  • Working on a new filtering mechanism, with very promising results, reducing the time required to filter the entire blockchain for contract events from minutes to seconds.
  • Investigating a new mining strategy, which should move transaction processing for miners completely parallel to mining, hence reducing the overhead of transaction inclusion to 0. This should permit miners to lower fees without transactions impacting the probability of finding blocks and/or having them included.
  • Slowly adding minor polishes to Puppeth, Clique and Rinkeby, such as a tiered faucet for Ether withdrawals, configurable gas dynamics for private network miners and automatic ENS integration.
  • An external security-audit has been performed by Truesec AB. No critical issues were found.

C++ development:

  • the monitoring node achieved a full sync to the mainnet
  • metropolis EIPs are almost complete
  • work on fast sync and snapshot sync has begun
  • Testeth tool has new option –statediff for debug information on a praticular test case as well as new test format  GeneralStateTests (enhancement of the old statetests) [4074]

Remix:

  • almost finished a new static analysis module that can detect reentrancy bugs (externally contributed by “soad003”) [508]
  • added a folder view to show open files inside folders – files imported via e.g. import “github.com/ethereum/solidity/std/StandardToken.sol”; are now visible in the folder view [449]
  • debugger can now display mappings [498]
  • rearranged tabs to provide better overview [496]

Solidity:

  • we released the unified standard json interface to interact with the compiler [1639]
  • added “interface contract” feature[1688]
  • added some more safety checks: statements without effect, and unary plus and unused variables [2139, 2152, 2199]
  • further work on the new intermediate language including web assembly and EVM1.5 backends [2129 and lots more]
  • almost finished work on exporting and especially also importing the AST (this will allow mutation testing and lots of other extensions) [1810 and others]

Mist:

  • Decouple geth specific hard-coded node and network handling, allow for arbitrary nodes and networks defined by local or remote clientBinaries.json
  • Refactor of the settings backend in preparation for a settings UI
  • Added macOS and Windows Code-Signing, preparing github/swarm based auto-updater
  • Many of the audit findings will incorporated in the coming releases

Changes to the provider will make Mist and other Projects like MetaMask and status.im more future proof, as developers don’t need to depend on high level libraries not changing over time. There will be a few announcements concerning the new provider. Discussion about that is happening at https://github.com/ethereum/interfaces/issues/16

Web3.js

  • We are currently adding generation and signing with private keys right into web3.js. So that you can easily create wallets and sign messages in your dapps. You can find the current experimental docs here: http://web3js.readthedocs.io/en/1.0/web3-eth-accounts.html
  • The next steps will be adding @maiavictor’s swarm library and the new whisper API and the new web3.js should be ready for test drive by the community.

The post Roundup Round III appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/05/24/roundup-round-iii/feed/ 0
Solidity optimizer bug https://ethereumblog.net/2017/05/03/solidity-optimizer-bug/ https://ethereumblog.net/2017/05/03/solidity-optimizer-bug/#respond Wed, 03 May 2017 13:21:57 +0000 https://ethereumblog.net/?p=3831 A bug in the Solidity optimizer was reported through the Ethereum Foundation Bounty program, by Christoph Jentzsch. This bug is patched as of 2017-05-03, with the release of Solidity 0.4.11. Background The bug in question concerned how the optimizer optimizes on constants in the byte code. By “byte code constants”, we mean anything which is […]

The post Solidity optimizer bug appeared first on Ethereum Blog.

]]>
A bug in the Solidity optimizer was reported through the Ethereum Foundation Bounty program, by Christoph Jentzsch. This bug is patched as of 2017-05-03, with the release of Solidity 0.4.11.

Background

The bug in question concerned how the optimizer optimizes on constants in the byte code. By “byte code constants”, we mean anything which is PUSHed on the stack (not to be confused with Solidity constants). For example, if the value 0xfffffffffffffffffffffffffffffffffffffffffffffffe is PUSHed, then the optimizer can either do PUSH32 0xfffffffffffffffffffffffffffffffffffffffffffffffe, or choose to encode this as PUSH1 1; NOT;.

An error in the optimizer made optimizations of byte code constants fail for certain cases by producing a routine that did not properly recreate the original constant.

The behavior described in the reported bug was found in a contract in which one method ceased functioning when another – totally unrelated – method was added to the contract. After analysis, it was determined that a number of conditions must exist at once for the bug to trigger. Any combination of conditions that would trigger the bug would consistently have the following two conditions:

  1. The constant needs to start with 0xFF... and end with a long series of zeroes (or vice versa).
  2. The same constant needs to be used in multiple locations, for the optimizer to choose to optimize this particular constant. Alternatively, it needs to be used in the constructor, which optimises for size rather than gas.

In addition to the two conditions above, there are further, more complicated conditions that are required.

Analysis

This bug is present in all released versions of Solidity from at least as far back as summer 2015 to the present. Although the bug has been present since 2015, it seems very hard to trigger by “random” code:

We performed a static analysis of all contract code deployed on the blockchain, and found no occurrence of such an invalidly generated routine. Note, the fact that we have not found a bug in all the contract code does not guarantee the absence of such occurrences.

Improvements

In order to provide better transparency and increased awareness of bugs in Solidity, we have started exporting information about Solidity-related vulnerabilities as JSON-files in the Solidity code repository(1,2). We hope that block explorers will integrate this information along with other contract-related information.

Etherscan has already implemented this, which can be seen here and here.

Concerning the bug itself, we added a mini-EVM to the optimizer which verifies the correctness of each generated routine at compile time.

Furthermore, work has already started on a fully-specified and more high-level intermediate language. Future optimizer routines on this language will be much easier to understand and audit and it will replace the current optimizer.

The post Solidity optimizer bug appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/05/03/solidity-optimizer-bug/feed/ 0
Geth 1.6 – Puppeth Master https://ethereumblog.net/2017/04/14/geth-1-6-puppeth-master/ https://ethereumblog.net/2017/04/14/geth-1-6-puppeth-master/#respond Fri, 14 Apr 2017 11:19:30 +0000 https://ethereumblog.net/?p=3791 Cramming in a lot more goodies than originally anticipated, the Go Ethereum team is proud to finally deliver the first incarnation of the 1.6 Geth release series! Glimpsing through the commit list, this is going to be a monster post! Toml configuration files For a very long time now, people were requesting that we support […]

The post Geth 1.6 – Puppeth Master appeared first on Ethereum Blog.

]]>
puppethCramming in a lot more goodies than originally anticipated, the Go Ethereum team is proud to finally deliver the first incarnation of the 1.6 Geth release series! Glimpsing through the commit list, this is going to be a monster post!

Toml configuration files

For a very long time now, people were requesting that we support configuration files to aid in switching between different public and pirate chains. We didn’t focus much on private networks, so we’ve always pointed people towards using shell scripts in those cases. Although they are suitable for many scenarios, shell scripts aren’t portable across different operating systems, especially Unix and Windows.

By popular demand, we’ve reworked the entire configuration and flag handling for Geth 1.6, finally landing support for this much requested feature. The configuration file uses the TOML format and the fields that can be set map one-to-one to the config structures go-ethereum uses internally. Certain fields have been omitted to prevent sensitive data circulating in configuration files.

Figuring out how to create a “proper” config file for your node with all the correct fields set up just the way you’d like it – whatever the field names even are – can be daunting. Instead, Geth 1.6 ships with a command that you can invoke to print the exact config file you’ll need based on your custom invocation flags (geth --your-favorite-flags dumpconfig). This dump can then be loaded up via geth --config yourfile.toml. We’re also planning to allow embedding the genesis configurations, but that needs a bit more thought to finalize.

Pure Go ethash

Since the very beginning, Ethereum had a C ethash implementation, shared between the various clients. This helped reduce maintenance efforts while the algorithm was evolving, at the expense of adding a big chunk of non trivial C code to go-ethereum.

This began to hurt more and more as time progressed. Without C knowledge on the Go Ethereum team, we couldn’t properly handle performance issues and inherently couldn’t implement optimizations essential for mobile devices. The design of the C ethash prevents it from running on big endian processors that would require invasive redesign. Lastly, depending on C code significantly hurts our portability and maintainability.

Starting with Geth 1.6, we’ve deprecated our use of the original C ethash and reimplemented it fully in Go. This permits us to generate mining DAGs concurrently on all available CPUs, rotate old mining DAGs out instead of storing them indefinitely, use memory mapped verification caches essential for fast mobile startup times, and run on any platform Go supports. For details, performance numbers and CLI flags, please consult the pure Go ethash PR.

Router CPU compatibility

We’ve always taken pride in supporting the go-ethereum codebase on a variety of exotic platforms, which were severely limited by the weight of a full node. However, with the light client slowly maturing, it makes more and more sense to expand our platforms towards previously unfeasible directions.

With the 1.6 release family of Geth, we are further pushing the envelope by introducing support for MIPS CPUs, most commonly found in consumer router devices. Geth 1.6 runs on both 64 bit and 32 bit MIPS CPUs in both little endian and big endian mode (courtesy of our new ethash code). You can find pre-built stable and develop binaries for these MIPs CPUs on our downloads page from now on.

Although we’ve successfully put a consumer router on the mainnet, there’s still much to do make the experience smooth. The most notable bottleneck is the memory hardness of ethash, requiring non-negligible amounts of storage and memory capacity… one more reason to switch to PoS! 😉

Plugable consensus engines

Over the last few releases we’ve been slowly working towards abstracting consensus related concepts in our codebase, with the long term goal of preparing for Casper and proof-of-stake. It was a lower priority feature as there were so many other tasks hanging around. Priorities changed when the Ropsten testnet was spammed to an unusable state.

The root cause of the attack’s success was that a proof-of-work network is only as secure as the computing capacity placed behind it. Restarting a new testnet from zero wouldn’t solve much, since an attacker could mount the same attack over and over again. The time seemed ripe to put some effort into the consensus model within go-ethereum and allow using alternatives to proof-of-work for smaller networks, where a different security model is more suitable.

The result is that Geth 1.6 features a plugable consensus model where developers, wanting to roll their own fork of Ethereum with wildly different ways of agreeing on block validity, can now do so by implementing a simple Go consensus engine interface. The current ethash backed proof-of-work consensus model is also “just” another implementation of this interface.

Clique PoA (proof-of authority) protocol

With the old Ropsten testnet down the drain, different groups scrambled to create a new testnet that would suit them, but may or may not suit others much. These efforts gave birth to a reverted Ropsten testnet from the Parity team (relying on custom soft-fork code, bootnodes and blacklists) and the Kovan testnet from a Parity conglomerate (relying on a then undocumented Parity consensus engine). Both solutions lock out other clients.

Our solution was to propose a cross client proof-of-authority consensus engine called Clique (EIP 255). The main design considerations behind Clique were simplicity (i.e. minimize the burden of adding to different clients) and compatibility (i.e. support existing sync techs in all clients). The proposal was accepted by all client developers on the 17th of March, 2017.

With our 1.6.0 release, go-ethereum also features a full implementation of the Clique proof-of-authority consensus engine. In addition to all the consensus related functionality, the engine also supports customizable block times for private network scenarios. As to how you can create your own Clique network… 😉

Puppeth network manager

Do you like setting up a private network? Don’t answer that! Truth be told, if you’ve ever tried to set up your own private Ethereum network – whether for friendly fun, corporate work, or hackathon aid – you’ll certainly know the pain it takes to do so. Configuring a genesis block is one thing, but when you get to bootnodes, full nodes, miners and light clients, things start to wear thin fast… and we haven’t even talked about monitoring, explorers, faucets, wallets. It’s a mess.

Geth 1.6 ships a new tool called puppeth, which aims to solve this particular pain point. Puppeth is a CLI wizard that aids in creating a new Ethereum network down to the genesis, bootnodes, signers, ethstats, faucet, dashboard and more, without the hassle that it would normally take to configure all these services one by one. Puppeth uses ssh to dial into remote servers, and builds its network components out of docker containers using docker-compose. The user is guided through the process via a command line wizard that does the heavy lifting and topology configuration automatically behind the scenes.

Puppeth is not a magic bullet. If you have large in-house Ethereum deployments based on your own orchestration tools, it’s always better to use existing infrastructure. However, if you need to create your own Ethereum network without the fuss, Puppeth might actually help you do that… fast. Everything is deployed into containers, so it will not litter your system with weird packages. That said, it’s Puppeth’s first release, so tread with caution and try not to deploy onto critical systems.

Rinkeby test network

As mentioned in this post already, the Ropsten testnet fell apart a few months back. There are ongoing efforts to revive it as it’s a valuable component of the Ethereum ecosystem. That said, we find it essential to provide developers with a network they can rely on, one that cannot be attacked so easily. One such network is the second half of the EIP 255 proposal, the Rinkeby testnet.

On the 10th of April we launched the alpha version of Rinkeby, a new proof-of-authority testnet based on the Clique protocol. Rinkeby is currently upheld by three (3) Foundation signing nodes, but we eagerly look forward to promote external entities too, so that the network’s resiliency may be furthered. The network also features a public GitHub authenticated faucet that is accessible to everyone under the same conditions. As to why it’s an alpha version, Rinkeby is the first live incarnation of Clique and we have yet to see how it fares under global load.

So, how can you access it? Being alpha, we didn’t yet add a flag for it into Geth 1.6, however we went out of our way to make it beyond trivial do connect and use it… via it’s own website at https://www.rinkeby.io/! Dashboard, ethstats, faucet and connectivity tutorials for Geth, Wallet/Mist and Android/iOS! If you’re wondering how we made all this, Puppeth of course! This is what Puppeth was born for, and you can have the same for your own private networks too!

Mounting swarm data

If you’ve used our experimental swarm implementation before, you’ll know that operating with files is easy enough, but when it comes to working with entire folders – possibly nested – it can become cumbersome. Fine for a program, but less so for manual user interaction.

To try and address this shortcoming, the Swarm implementation shipped with our current release features a few milestone features, notably the ability to upload and download entire directories via tarball streams in the HTTP interface, as well as mounting an entire folder into your local filesystem via FUSE! This should make Swarm a lot more viable both for file backup purposes as well as for easily exploring complex directory structures.

Apart from these neat features, Swarm saw various stability improvements and bugfixes, gained the ability to manipulate manifests via the command line, as well as to create listings/sitemaps out of them.

64 bit gas calculations

The Ethereum Yellow Paper specifies that gas included with transactions can be an arbitrary value up to the ludicrous amount of 2^256 (which could cover almost as many transactions as the number of atoms in the known universe). As such, the go-ethereum EVM was implemented to work with these insanely large numbers for gas calculations, causing equally large performance penalties while running every transaction.

As there is simply no meaningful reason to use big-number arithmetic for gas calculations, Geth 1.6 switched over to working with 64-bit values, which is a native hardware-supported type on any modern CPU. If you are wondering whether this would pose any limitation, a single block with a gas limit of 64-bits could fit in 44 times more transactions than the number of red blood cells in the human body. I think we’re safe for the foreseeable future.

Regarding performance improvement, we don’t have an exact number, but it is safe to say that shaving off hundreds of memory allocations per every single transactions can’t be a bad thing.

Closing remarks

Besides all the highlighted features mentioned above, a numerous number of bug fixes have also been merged in, ranging from ethstats reporting, to singleton miner networks, star topology propagation fixes and more. Please check the Geth 1.6.0 release notes for a condensed rundown.

Other smaller features include constant improvements to the light protocol, heavy development in the Whisper protocol (getting very close to a public v5 release), and we’ve even swapped out our entire logging system to a much nicer and more robust version.

As always, you can install Geth via your favorite package manager, or download a pre-built binary for a variety of supported platforms.

Happy puppetheering! The go-ethereum Authors.


IMPORTANT NOTICE

Given the nature of this release, which includes heavy rework around gas calculations in the Ethereum virtual machine and heavy refactors around plugable consensus engine split, we ask production users to exercise caution and care when upgrading. We consider Geth 1.6 as a pre-release until large scale stability is confirmed.*

It is important for all production users to understand the risks involved in new releases such as this one. There may be undetected bugs and unexpected consequences that could lead to loss or other unwanted results. This release is for sophisticated production users who understand the Geth platform, the impact it may have on the users and the risks that new releases of this nature involve.

The post Geth 1.6 – Puppeth Master appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/04/14/geth-1-6-puppeth-master/feed/ 0
Ethereum Dev Roundup: Q1 (Boring Edition) https://ethereumblog.net/2017/04/07/ethereum-dev-roundup-q1-boring-edition/ https://ethereumblog.net/2017/04/07/ethereum-dev-roundup-q1-boring-edition/#respond Fri, 07 Apr 2017 09:30:17 +0000 https://ethereumblog.net/?p=3785 The last one and a half months have seen great progress for Ethereum research, and we are excited that the protocol is moving closer and closer to the point where it is ready for mainstream adoption. Progress on consensus algorithms, privacy, zero knowledge proofs and formal verification is happening at increasing speed, and our research […]

The post Ethereum Dev Roundup: Q1 (Boring Edition) appeared first on Ethereum Blog.

]]>
The last one and a half months have seen great progress for Ethereum research, and we are excited that the protocol is moving closer and closer to the point where it is ready for mainstream adoption. Progress on consensus algorithms, privacy, zero knowledge proofs and formal verification is happening at increasing speed, and our research and development teams are expanding substantially.

A large amount of progress has been made on Casper. You can find a few Medium posts describing the algorithm here:

And a few blog posts from Yoichi formally proving correctness:

And on “Vlad Casper”:

And it’s not just theory:

More progress on Casper and sharding will continue to be published once it stabilizes to the point where it makes sense to write the ongoing work up in a document; the high-level details are now close to finalized, current discussions have more to do with the finer details of the design of the Casper contract.

And some other blog posts from Vlad:

Some bugs were discovered in the ENS code leading to a delay of its launch. A security audit was commissioned, and the audit is now complete, bringing us a step closer to the final launch day:

Updates on formal proving:

Metropolis is continuing to progress, and the core development teams are continuing to make progress toward fully agreeing on the specification. Tests for some of the EIPs are already available, and more tests are continuously being written.

The post Ethereum Dev Roundup: Q1 (Boring Edition) appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/04/07/ethereum-dev-roundup-q1-boring-edition/feed/ 0
Ethereum Dev Roundup: Q1 https://ethereumblog.net/2017/04/01/ethereum-dev-roundup-q1/ https://ethereumblog.net/2017/04/01/ethereum-dev-roundup-q1/#comments Sat, 01 Apr 2017 00:55:28 +0000 https://ethereumblog.net/?p=3775 The last one and a half months have seen great progress for Ethereum research, and we are excited that the protocol is moving closer and closer to the point where it is ready for mainstream adoption. Progress on consensus algorithms, privacy, zero knowledge proofs and formal verification is happening at increasing speed, and our research […]

The post Ethereum Dev Roundup: Q1 appeared first on Ethereum Blog.

]]>
The last one and a half months have seen great progress for Ethereum research, and we are excited that the protocol is moving closer and closer to the point where it is ready for mainstream adoption. Progress on consensus algorithms, privacy, zero knowledge proofs and formal verification is happening at increasing speed, and our research and development teams are expanding substantially.

  • After three years of trying to find solutions to the “nothing at stake” and “stake grinding” attacks, we have decided that the problem is too hard, and secure proof of stake is almost certainly unachievable. Instead, we are now planning to transition the Ethereum mainnet to proof of authority in 2018. To that end, we have launched two new testnets, Qinghuadongluxikou and Hongqiao Airport Terminal 2, to test our latest proof of authority specification.
  • A third testnet will be released based on Proof of Transaction, which will be called PoTcoin.
  • We have decided to expedite the implementation of the “Proof of Vitalik” transaction reversion algorithm, which allows any transaction or contract that has an undesirable result to be quickly reverted. We are pleased to announce our cooperation with the government in Pyongyang, which will work with us to identify transactions that promote American imperialism or are otherwise not in the interest of our Dear Leader or the Juche idea, so that they can be efficiently scheduled for reversion. Expect the reversion feature to become enabled as part of Metropolis.
  • To make up for ETC’s deeply immoral failure to fully refund DAO token holders’ ether, we intend to redirect 20% of the block reward for the first 200000 blocks after metropolis (ie. a total of 200000 ETH) to an additional DAO withdrawal contract, so that DAO token holders can be fully made whole.
  • An additional 10% of the block reward starting from Metropolis will be directed to our shareholders at AXA and the Bilderberg group. This change is permanent.
  • In the interest of maintaining protocol immutability, the current 4 million gas limit will be set in stone and no longer changeable through miner voting. However, we will add an opcode, OP_SEGREGATED_EXECUTION, which allows users to execute any desired piece of code at 1/4 the normal gas cost. Any state changes made by code executed through this mechanism will be saved in a secondary state separated from the main Ethereum state, and a soft-forking change is added which requires the r value of the signature of the first transaction in any block to be equal to the trie root hash of this secondary state. This is simpler and safer than raising the gas limit to 16 million directly because…. reasons.
  • We will allow miners to specify the block reward that they want to pay themselves, and allow users to specify in their clients the maximum block reward that they are willing to consider valid. If a user sees a chain containing blocks with rewards larger than their maximum accepted block reward, they will not accept the chain at first, though if such a chain becomes 12 blocks longer than the longest chain that the user does accept then the client will automatically increase its maximum accepted block reward to accept the new chain. This allows for a more fair, market-based and democratic way of setting the issuance rate.
  • Another opcode will be added in Metropolis, OP_VERIFY_PROOF_OF_DEATH, which verifies that a person with the legal name that is passed in from the stack as a zero-byte-left-padded UTF8-encoded byte string is deceased. This will be very useful in enabling use of the Ethereum blockchain for… err…. umm….. life insurance. Those individuals interested in exempting themselves from this opcode should promptly change their full name to something exceeding 32 characters in length.
  • We have uploaded 100 megabytes of alt-right propaganda, Falun Dafa texts, military secrets, copyright-infringing materials and comments making fun of Donald Trump’s hair onto the Ethereum blockchain, with the goal of getting the blockchain banned in as many countries as possible. We believe that by forcing mining and full nodes underground, and encouraging governments to go after services that become too prominent, we can make the Ethereum ecosystem more decentralized and reduce the risk of attracting interest from malevolent institutions such as banks and large enterprises.

Finally, last but not least, Devcon3 has been moved to Pyongyang.

The post Ethereum Dev Roundup: Q1 appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/04/01/ethereum-dev-roundup-q1/feed/ 1
Ethereum JS Ecosystem Updates https://ethereumblog.net/2017/03/21/ethereum-js-ecosystem-updates/ https://ethereumblog.net/2017/03/21/ethereum-js-ecosystem-updates/#comments Tue, 21 Mar 2017 01:11:39 +0000 https://ethereumblog.net/?p=3752 It’s been a fairly busy for the last couple of months for the Ethereum javascripters. To start with, there was a really great hackathon with IPFS. You can read Dan Finlay’s excellent write up here. Also, during this time Aaron Davis (Kumavis) made some excellent progress towards a JS light client by utilizing IPFS’s libp2p to build a in-browser […]

The post Ethereum JS Ecosystem Updates appeared first on Ethereum Blog.

]]>
It’s been a fairly busy for the last couple of months for the Ethereum javascripters. To start with, there was a really great hackathon with IPFS. You can read Dan Finlay’s excellent write up here.

Also, during this time Aaron Davis (Kumavis) made some excellent progress towards a JS light client by utilizing IPFS’s libp2p to build a in-browser mesh network and IPLD to provide the merklization layer. This will be important work in the future for building pure in-browser clients. Also Casey Detrio worked on a standard json RPC test suite, which you can see the results of here.

After the Seattle Meetup, we (Axic and Wanderer) sat down for a week long hackathon in Budapest to hash out some details of ewasm. Elsewhere in JS world, Fabian is doing a huge refactor of Web3.js for the 1.0 release, while Nick Dodson has been busy with ethjs. The rest of this post will be charting the various projections that this technology could provide as well as going into some details about each individual project. All these projects are all open source and encourage community participation, so if you are interested please check them out, say hello and send in a PR if you have time! 

EWASM

Ewasm’s goal is to research and replace the EVM with Webassembly and secondarily, implement a client for the current system which can be efficiently JITed (or transcompiled) to WebAssembly.

A major piece of evaluating WebAssembly for blockchain usage will be create a test network and this year the focus of the Ewasm team will be bringing that test network to life. The testnet work will:

  • enable hands-on work with ewasm for a wider audience
  • enable related work, such as experiments with casper to be done by providing a flexible platform for experimentation

The ewasm track is dedicated to ewasm research and development, while the client integration track will be dedicated to developing the network and bring full and light clients into existence. But there are many shared components to these two tracks. The Ewasm project is being broken down into two main components: the Kernel Layer, which handles IPC and manages the state, and the core VM. This should enable us to use the same framework for different VM implementations.

So to recap, the major tasks for ewasm are:

  • Build an ewasm test network
  • Creating a reusable “kernel” module
  • Revamp ethereumjs-vm
    • Use ewasm-kernel for the message passing
    • Implement the latest EIPs
  • Ewasm integration tools
  • Solidity-ewasm integration (upcoming effort for the solidity hackathon!)

Please come join the implementation effort! We have semi-weekly meetings on Tuesdays. Our communication channel is on Matrix at prima:matrix.org (or #ewasm on IRC or at gitter)

Networking

There are several reasons to have an Ethereum networking implementation in JS. For one, it would allow us to implement a full and light Ethereum JS node. These light clients would run both in a node.js environment and in a browser. A prerequisite for an in-browser light client is “bridge” nodes. These nodes might also act as signaling servers for the webrtc network that the browser light clients would use to relay  messages from the RLPx network to the webrtc network. This work is being spearheaded by Metamask using IPFS’s libp2p. Also the RLPx implementation was recently revamped by fanatid.

IPLD

Ethereum’s blockchain and on-chain state can be understood as a graph of hash-linked data. IPFS/IPLD is proposed as a generic system to describe and distribute hash-linked data. Therefore we can describe Ethereum as an application layer on top of the hash-linked data availability platform. As a proof of concept, Kumavis implemented IPLD resolvers for the Ethereum data formats that define where hash-links are encoded inside the canonical Ethereum formats (e.g. block and state trie node). This, combined with other generic features of libp2p (IPFS’s generic p2p networking stack), enables the creation of minimal Ethereum clients that focus on the consensus protocol and state transition mechanism. One advantage of this approach is that the networking layer is transport-agnostic and can be used in environments that don’t have access to tcp/udp (such as the browser) that the standard Ethereum clients require. This project is still in the research phase. MetaMask hopes to use this approach to implement a browser compatible Ethereum light client via a secondary network, bridged by hybrid nodes.

Web3.js 1.0 incoming!

A new version of web3.js is in the making. It is the biggest refactor of the codebase since the inception of the popular Ethereum library. It will have a lot of convenience features like confirmation and receipt event on transactions, a nice subscription API, and checksum checks on address inputs.

The API is still not yet finalized, but if you are eager to have a look you can check out the docs here.

The new version will also have quite a few breaking changes, but those updates are necessary to get the new API right and remove some some deprecated methods along the way, like synchronous calls. 1.0 will only have promises and in some events “PromiseEvents” to better reflect multiple events on a transaction’s execution. For those who are thinking of transitioning their apps to the new web3, there will be a migration guide upon launch to help make the transition from 0.x.x as easy as possible.

In Mist there will be no web3 exposed by default anymore, as this encourages the bad habit of relying on the Mist-provided web3, which makes breaking changes disastrous for dapps. Instead, there will be an “ethereumProvider”, which libraries like web3 can use to talk to the underlying node. Web3.js will automatically detect any given provider and expose it on its API for easy instantiation.

For those who can’t wait and want to try it right now, checkout the 1.0 branch in the web3.js repo. Be aware there might be dragons!

Ethjs

Ethjs is a new highly optimised, light-weight JS utility for Ethereum geared to working with the json RPC, much like web3.js but lighter, async only and using bn.js. The current ongoing activity includes:

  • Adding the ABI methods for decoding logs in ethjs-abi
  • Having fixed a small decoding bug in ethjs-abi (handling 0x addresses)
  • Merged new schema for personal recover and sign ethjs-schema
  • Looking for help making ethjs-filter stateless (infura ready)
  • Bug fixing in ethjs-contract
  • Documentation updates all around
  • Upcoming ethjs version 0.2.7 release!

TestRPC

Working on the 4.0.0 release! This release will include:

  • Database persistence. Now you can create a test chain and save that data, just like any other private chain!
  • Clean up of how data is stored in memory, which should reduce memory issues significantly. Although there will be a slight cost in some performance, which mostly be unnoticeable unless you’re making thousands of transactions, it will bring a huge increase in stability.
  • Bundling for the browser (provider only).
  • Easier installs on Windows, and possibly other platforms.

We’ll be moving the TestRPC to the Truffle github organization since it’s primarily maintained by Truffle developers. There are significant new TestRPC add-ons coming. And we’re investing significant energy in documentation and branding that unifies it under the Truffle brand. Any feedback on this move is appreciated.  Lastly, the TestRPC needs a new name that exudes everything it can do. If you have an idea let us know!

Community

The Ethereum JS community is an exciting and wonderful thing to be a part of. There are many great projects happening. If you are interested in plug in we have weeklyFriday meetings at 3:00 EST / 10:00 PST / 18:00 UTC. Watch our gitter channel for the chat link. Also, we are organizing an upcoming hackathon. Let us know if you are interested.


ADDENDUM [Mar. 22, 2017]: Note that some of the projects in this post are not directly supported by Ethereum Foundation, but have been included as they are relevant to the overall Ethereum JS ecosystem update by the author.

The post Ethereum JS Ecosystem Updates appeared first on Ethereum Blog.

]]>
https://ethereumblog.net/2017/03/21/ethereum-js-ecosystem-updates/feed/ 1