Cryptocurrency Market Update: Bitcoin breakdown to $6,000 awaiting confirmation, Ethereum and Ripple in consolidation
The cryptocurrency market is facing heightened volatility after a four-week winning streak culminated in a bearish momentum over the week. At the time of writing, the bulls who dominated the market during the Asian hours are slowly being ousted and sellers taking over. Expanding volatility, especially for the major cryptos points at a major drawback is around the corner.
BTC/USD is trading at $6,846 after adjusting from $6,862 (opening value). During the Asian session, Bitcoin buyers stamped down their feet as they pulled the price towards $7,000. However, a high reached at $6,832 marked the end of the bull-run. Looking at the 4-hour chart, BTC/USD is dancing below a bearish pennant pattern whose support was shattered over the weekend following the retreat from $7,500 to $6,575. Unless Bitcoin bulls pull above $7,000, a bearish cloud will continue to hang above BTC and threaten to have support at $6,000 retested. For now, the price is dancing between the 100 SMA support and the 50 SMA resistance.
ETH/USD continues to struggle with increased selling activities at $160. Little progress has been made northwards from $156.77 (opening value). Instead, ETH/USD is trading at $156 amid a bearish trend and expanding volatility. It is apparent that Ethereum has to break the resistance at $160 to be able to forge another breakout above $170.
XRP/USD happens to be the worst-hit among the top three cryptos. It has lost over 2% on its value on the day. Ripple has a market value of $0.1842 after adjusting from $0.1880 (opening value). While support at $0.1800 is still in place, resistance at $0.1900 is proving to be an uphill task. However, another break above $0.20 will give the bulls a fighting chance towards $0.30.
The Chinese government has released the list of members making up its blockchain committee. The committee is tasked with coming up with industrial blockchain standards. It is made up of 71 members and interestingly, executives members from Chinese tech firms been included such as Baidu and Tencent, and Huawei. The committee is chaired by the country’s Ministry of Industry and Information Technology (MIIT) deputy minister Chen Zhaoxiong assisted by five vice presidents.
EF-Supported Teams: Research & Development Update
From our team to you and yours, we hope everyone and their families are well and keeping safe during these complicated weeks. To help pass some time while we’re all stuck in doors, it’s time again to update the community on progress made by some of the EF-supported projects not covered in last week’s ESP Allocation Update. While the last Winter edition in this series was posted only a few months ago, we’ve all come a long way since the launch of the Istanbul network upgrade, and many teams have news to share.
As always, these updates focus on EF-supported teams and efforts whose members are working to grow and improve Ethereum as a whole. Included in this edition are updates from many teams highlighted in the previous report, and other new and rotating news.
Authored by Paweł Bylica
In December 2019, the 1.8.0 version of Aleth was released. It contains a number of fixes and improvements related to a variety of aspects of how this C++ Ethereum node functions. In particular, we made improvements to the RPC interface, blockchain sync and network protocol, and testing tools (testeth, aleth-vm). See CHANGELOG for more details.
This release also contains substantial work related to the consensus mechanism:
Aleth 1.8.0 is the last planned version. From now on, we are only committed to basic maintenance of the code, Pull Request review and fulfilling the remaining needs of testing and EIP reviews. At this point I’d like to thank all Aleth contributors, especially Nils-Erik Frantzell who put a lot of effort in the project in the past year.
It is also worth mentioning maintenance releases of sibling projects:
Last but not least, we have published an article on Efficient gas calculation algorithm for EVM, later included in Devcon 5 presentation Optimization techniques for EVM implementations.
Authored by Koh Wei Jie and Kobi Gurkan
The Applied ZKP team works to bridge the gap between cutting-edge research in zero-knowledge proofs, and application development on Ethereum.
In September 2019, we launched the Perpetual Powers of Tau ceremony (PPOT). PPOT aims to benefit the zero-knowledge ecosystem, particularly zk-SNARK projects built on Ethereum, by partially easing the burden of trusted setup ceremonies. Every zk-SNARK project requires two phases of parameter generation, and PPOT replaces the first phase, which can be shared by all circuits. Individual teams can choose any contribution from the ceremony to branch out and perform their own phase 2 setup.
This ceremony supports circuits up to 2 ^ 28 constraints, which means that each contribution requires a 97G download, a 1-day computation, and a 49G upload. At the time of writing, we collected 29 contributions from 28 unique individuals, and all contribution files can be downloaded and independently verified against a public ceremony transcript.
Semaphore is Applied ZKP’s flagship project, initiated in mid-2019. It is a generic privacy gadget which enables use cases such as mixers, anonymous login, and anonymous voting. One use case of Semaphore, developed by Chih-Cheng Liang, is Semaphore Authentication, which enables anonymous logins with protection against Sybil attacks. We encourage readers to check out this explanatory blog post to understand what Semaphore is and how it works.
We engaged ABDK Consulting to perform a security audit of Semaphore’s zk-SNARK circuit code and Solidity contracts. We fixed the issues they uncovered, and released the final source code. We have included in the audit many components from the circom standard library, thus providing a greater set of tools to be used by the wider community of SNARK developers that use circom.
At the time of writing, we are performing a circuit-specific multi-party trusted setup ceremony. The process we are following is documented here. We collaborated with Supranational, a member of the VDF Alliance, to run a verifiable delay function (VDF) on a pre-announced Ethereum block hash, and applied the output of said VDF onto challenge file #25 from the Perpetual Powers of Tau ceremony (see below), and kicked off the circuit-specific ceremony on the 6th of April 2020.
Thanks to excellent work by Brian Gu, we were able to repurpose Aztec Protocol’s Ignition ceremony software for our ceremony. Please check out more details about this ceremony by reading its participant guide.
Feel free to discuss in the Semaphore Society Telegram chat group.
Semaphore RLN provides a way to perform rate-limiting in a P2P setting – instead of relying on an on-chain nullifier map to prevent double-signaling, we use Shamir Secret Sharing to expose shares of the broadcaster’s private key. Multiple published shares from the same broadcaster can be used to reconstruct the private key, opening up the possibility for the original holder of the private key to be slashed.
Originally proposed by Vitalik Buterin in an ethresear.ch post, systems built with MACI make collusion among participants difficult, while retaining the censorship resistance and correct-execution benefits of smart contracts. Although MACI can provide collusion resistance only if the coordinator is honest, a dishonest coordinator can neither censor nor tamper with its execution.
In late 2019, we started work on a technical specification and implementation and we are nearing completion of a minimal viable product.
MiMC has become a popular cryptographic hash function in SNARKs due to its great performance. While it is the oldest of the bunch in the “hash functions with low multiplicative complexity” family of functions, we felt it should receive more critical attention. We initiated a bounty for collision finding in MiMC, which we also plan to extend to Poseidon.
Optimistic Rollup allows greater layer 2 scalability with the use of on-chain data availability and fraud proofs. The Hub chain further allows for easy mass migrations between different rollups. The hub allows for easy mass migrations.
ZK Optimistic Rollup builds upon the same idea but for anonymous transfers. Instead of having all the transaction metadata in the clear, each transaction in the rollup is a 2-to-2 anonymous transfer.
PeekABook allows two users to privately match orders, such that no user can discover more information about an order made by another user unless they have an order that would fulfill it.
On April 1 we posted the ESP Allocation Update, where we shared some of the work we’ve been doing to improve our processes as well as a list of the projects that received financial support in 2019. Watch the blog for more updates, and follow us on Twitter (@EF_ESP) to keep up with the latest on the projects we support!
Authored by Alex Beregszaszi
Since the last update in December, the team has continued to work on Eth 2.0 Phase 2 and started to take a more active part in Eth 1x research as well.
Our intuition is that certain parts of research are needed by both and can be shared between the two efforts.
In a stateless model, it is not expected that everyone keeps a copy of the entire state of the blockchain. Instead, each block comes with a proof (the so-called witness) of the part of the state affected. The optimal creation, distribution and verification of witnesses becomes a crucial component of this new stateless system. The challenge of creation and verification is what interests our team most.
There exist various ideas for reducing block witness size, some of which Paul has collected in a survey. Given our background in instruction sets, the first problem we had a look at is reducing code size. This is important, because code also needs to be included in the witness. Two approaches come to mind: compression and merklization. An early phase experiment suggests we can cut down the amount of code transferred as part of the block witness by 40-60%.
We further plan to explore options to
It must be noted, since the execution model of Eth 2.0 is also stateless, the work done as part of Eth 1x becomes applicable here too.
Without the ability to efficiently transfer Ether (and potentially other tokens), payment for execution and transactions becomes a complicated matter. Last year a variety of models emerged, including receipts with accumulators, queues and balance maps. Casey has proposed an alternative called EthTransfer objects.
In addition to Ether transfer, contracts may want to be able to communicate with other contracts on different shards, and potentially perform atomic operations. All of this leads to a vast design space for Phase 2, which we’ve been exploring so far.
As an experiment, starting a few weeks ago, we have been working on Eth1x64. This reduces the design space and should allow for quick iterations of different designs.
Under Eth1x64 each shard is homogenous and is running an instance of Eth 1.x, with shard 0 being the current Eth 1.0 mainnet. We are working on multiple small proposals, all of which focus on various ways to accomplish cross-shard communication.
This work will give an idea of the complexity of introducing sharding into Eth1, allowing us to gather wider feedback from Dapp developers, and we can take the results into refining the WebAssembly-based Phase 2 designs.
Zero-knowledge protocols are becoming increasingly important. It must be ensured they can be efficiently supported on Eth 2.0. An optimized implementation in AssemblyScript of the SNARK-friendly MiMC hash function and a zkSNARKs-based token example have been developed. This example works well as an Execution Environment. Benchmarks show that both can achieve comparable performance to compiler engines and EVM-based (precompile aided) implementations. See Jared’s summary for numbers.
This work also guided further reviews of the big integer API, which is an important element of a powerful and safe, WebAssembly-based execution.
The last few months have been a fruitful time for WebAssembly with the release of the stable 1.0 version of the specification. A number of new promising interpreter projects have been announced and/or released. We are keeping a close eye on these and intend to include them in our benchmarking report.
In January we began working on Fizzy, a new Webassembly engine. Features such as integer-only support (no floating point operations) and interpreter-only execution make it well-suited for blockchain use cases. In addition, a clean codebase written in modern C++17 and the goal of easy embeddability aim to make Fizzy a viable, modular component for Eth 2.0 client implementations. By the time of this update, Fizzy is able to pass almost all official test cases (with the exception of Wasm validation, which is not yet implemented) and compares very well on speed benchmarks.
Authored by Leo Alt and Martin Lundfall
Act is a simple and effective specification language to write formal specifications. It is being developed with input from several groups, and we hope that in the future it will be common to use Act to specify smart contracts.
By allowing properties to be expressed on different levels, the main goal for Act as a tool is to enable modular verification. The specification can be verified as a standalone document, where contract invariants can be checked from the specified function’s pre/post conditions, and the post conditions can be checked from a function’s storage updates. Ideally this modular verification will make it much easier for other tools to verify that the source code/bytecode are correct.
We are currently working on three proof backends for the intermediate proofs:
Each one of the backends has its own pros and cons, and we hope to achieve good performance and coverage by developing all fronts at the same time.
We hope to release a prototype of each proof backend and study how to express loop invariants until June 2020.
We will soon release a detailed technical post about Act. Contributions to the repository are always welcome!
The SMTChecker is a model checking based static analysis module in the Solidity compiler that tries to verify source code assertions in compile-time. Last year a new engine based on Constrained Horn Clauses was added. This engine’s main feature is that it can automatically find inductive invariants that are used to prove assertions, enabling support for loops and state properties.
We recently added internal function calls to the engine and keep improving support for the Solidity language. In the next 3 months we will keep working on increasing language support, counterexample generation/presentation and external function calls, which will hopefully start to transition the SMTChecker from experimental into a useful and powerful tool.
In the future we also want to:
We are collaborating with ConsenSys R&D who are working on a verified ABI encoder/decoder using Yul-Isabelle. The idea and discussions started at Devcon V, and since then, good progress was made and we are close to a prototype.
Initially we intend to use it together with the Solidity Fuzzer to find bugs related to optimization and ABI encoding/decoding. Our final and slightly ambitious dream is to use the verified ABI encoder/decoder as part of the Solidity compilation process. This would imply that a substantial part of code generation is verified!
We have continuously supported Runtime Verification in maintaining the KEVM formal semantics and verifying the deposit contract and beacon chain specs. The deposit contract is also one of our main benchmarks when developing Act. We would like to provide an alternate specification for the deposit contract and proof for the incremental Merkle tree properties via Act by July, when we also intend to study Eth2 Phase 1 and Phase 2 properties that must be proved.
Going forward we will be exploring extending hevm with symbolic execution capabilities. This would make it possible to use hevm to formally verify EVM bytecode.
Authored by Péter Szilágyi
Over the past quarter the Geth team has been busy with network plumbing and laying the groundwork for future releases. This post will only enumerate a few of the major features; for a detailed bullet point view please consult our release notes.
A feature we’ve specced out about 2 years ago and shipped last quarter is DNS-based peer discovery. Going forward, Geth v1.9.11+ nodes have two independent mechanisms to find peers. The DNS lists serve as a fallback mechanism when peers cannot be found through the DHT. They might also end up being the starting point for a Tor integration.
DNS-based discovery is a centralized mechanism, but we have tried to make the operation of this mechanism as transparent and permissionless as possible. The public lists used by default are generated by crawling the discovery DHT. Nodes running any Ethereum client which implements EIP-868 and EIP-2124 will appear in the public lists automatically. If you want to create a DNS-based node list for your private or public network, please check out our DNS Discovery Setup guide.
At this time, there are ~1150 publicly-routed Ethereum mainnet nodes in the default list; and our public lists also serve the Ropsten, Goerli and Rinkeby test networks. Currently the network generates 8 million DNS queries per day to this discovery mechanism.
For a couple years now, most of the network bandwidth used by Ethereum nodes was shuffling transactions around. Unfortunately, this mechanism was never optimized since its inception, so it was very wasteful. Over the last quarter, we’ve spec’d out an update to the eth protocol (EIP 2464) which enables transactions to be announced between nodes and only transferred upon request.
This new protocol was released in Geth v1.9.11, is already implemented by Nethermind and in progress for Open Ethereum too. Since only about 30% of the network supports it, the amount of bandwidth saved globally is still a question, but running an eth/64 vs. eth/65 bootnode experiment with 250 peers has promising results.
Based on last week’s traffic, eth/65 is capable of reducing transaction propagation bandwidth by about 75%. For a bootnode of ours with 250 full node peers, that’s 750KB/s saved, or roughly 1.8TB of bandwidth per month. We are certain there is still room for improvement, but let’s take it one step at a time.
Apart from eth/65, Geth shipped support for larger than 32KB transactions back in January (courtesy of StarkWare), with a soft limit originally at 64KB and soon raised to 128KB (higher limits heavily rely on how eth/65 performs globally).
A large bottleneck in running the EVM and doing an initial sync revolve around the state representation in Ethereum: the Merkle Patricia trie. Since all the state data is laid out in a tree format, accessing any account takes about 6-8 random disk lookups currently on mainnet. During fast sync, the same random intermediate trie nodes need to be downloaded one by one to get to the actual data.
A feature we’ve been working on actively for half a year now is dynamic state snapshots: in short, creating a flat acceleration structure on disk which allows any account or storage slot to be loaded with 1 disk lookup. This is similar to Open Ethereum’s fatdb layout, except this one is dynamic: the snapshot mechanism in Geth is capable of keeping the acceleration structure updated live as the chain progresses (including the mini forks).
One benefit of the dynamic snapshots are O(1) EVM state reads. Although this might sound like a holy grail, it is not. Most contract executions don’t go crazy with disk reads, so the benefit is limited, and most contracts also do lots of writes, which still need to be pushed into the Merkle trie. The dynamic snapshots, however, do allow eth_call operations to be blazing fast and they do make DoS transactions significantly harder to pull off.
A much more interesting feature enabled by the dynamic snapshots is a new synchronization protocol, which we’ve been trying to pin down for 2 years now (originally called leaf sync). The protocol is still a work in progress, but if our hunches are correct, it should allow syncing the Ethereum state significantly faster.
The initial version of the next-gen discovery protocol was implemented in Geth, albeit it is not yet enabled. Whilst the spec and implementation is still fluid, syncing with the Eth 2.0 requirements, it is a huge milestone to have a working version in the live codebase.
Authored by: Holger Drewes, Philipp Langhans
Last quarter was exciting for the team. For the first time we came together in person early March during EthCC in Paris, deepened relationships and discussed team cooperation, possible collaborations and future plans. Expect to hear more on that once things start to bear fruits.
After being the main maintainer for the Web3.js library for more than a year, Samuel has decided that it is now time to go on with new adventures (thank you Samuel for all your great work! ♥️). We enjoyed a last being-together in the days around EthCC. Library development will now be taken over by other team members on a shared basis.
For the moment we have a strong focus on ensuring a steady release process and we are working on familiarizing ourselves with the tech stack and procedures since Samuel was the No. 1 expert here. Please bear with us that we are therefore very selective on adding new features in the near term. For the moment – and for the same reasoning – we also won’t do development on the 2.x branch (currently released as an alpha version of the library.
We moved the EthereumJS VM to a monorepo, combining structurally related libraries (tx, block, blockchain, HF configuration (common)) under one roof. This will significantly ease VM development in the future and allow for integrated PRs. There is a v5 release of the VM based upon this new structural basis planned to be released soon which will introduce several breaking changes. Feel free to drop in and join (and shape) the discussion.
Thanks to the great work of dryajov we now also have a working TypeScript implementation of the devp2p stack. A release on this is imminent.
Ethereum Grid was split into two parts: the desktop application and a core module that can provide binary management outside of the Electron context e.g. on CLI or in other tools like test runners or IDE’s (Remix, VSCode). The goal of the core is to provide an engine that itself is very small but can be extended via plugins. The necessary mechanisms that allow a secure and stable extension without having to modify Grid in the future have been implemented. This was the main goal of the refactoring and a transition towards a finalized product.
Grid can be extended with small scripts, called workflows, that interact with binaries. A variety of them have been created and demoed at EthCC: Grid Workflows
Authored by Piper Merriam
The Web3.py library has continued work on incremental improvements and stability. Thanks to some third party contributions, we expect to have preliminary support for mnemonic phrase and HD accounts released in the near term future. We also continue to work towards full async support, though there is still a decent bit of foundational work to be done on this front.
The Trinity client continues work across both the 1.x and 2.0 fronts. Work continues on the Trinity Eth2 client as we get closer to having stable, longer lived public testnets. On the Eth1.x side we continue to work towards a functional mainnet client. One of the biggest things to come out of our work over the last two years is the “Stateless Ethereum” effort which is shaping up to transform the Ethereum mainnet over the next 18-24 months.
The EthPM team is working with the Solidity team to incorporate the packaging standard such that the compiler is able to compile the resources in a package, produce packages of the compiled resources, and use the EthPM spec for metadata/contract source verification.
David aka @ioedeveloper joined the team recently and is working on E2E testing and the Remix IDE, aiming to consolidate our release process.
Authored by Griffin Hotchkiss
The set of upgrades to the existing Ethereum protocol dubbed “Eth1.X” have coalesced into a more unified effort by researchers to implement and transition to “Stateless Ethereum”. The upgrades and topics of inquiry are not just relevant to improving scalability and resilience of the current chain, but are also relevant and in many ways complementary to engineering and design challenges being tackled by Eth2 research teams.
Following EthCC in Paris, there was a Stateless Ethereum research Summit, regarded by attendees as seminal and wildly successful by all accounts.
Updates about the Stateless Ethereum initiative have been chronicled by Griffin Ichiba Hotchkiss in an ongoing series called “The 1.X Files”, which in addition to summarizing and digesting monthly calls, dives deep into the core concepts being researched and the road ahead.
Authored by EF Team
Danny Ryan, Carl Beekhuizen and the Eth2 research team have continued regular series like ‘Eth2 Quick Update’ and ‘Validated: Staking on Eth2’ here on the EF Blog. For the latest news and progress as we draw nearer to the launch of Phase 0, check out the latest posts below!
Authored by Martin Holst Swende
The health of the Ethereum Mainnet is the top priority, and we have investigated and published an EIP proposing penalties for state trie misses.
The Go-Evmlab repository has been updated to better integrate with Geth and help out during analysis of chain operations, as well as creating custom evm-fuzzers.
We have also had two external audits done on the upcoming Discovery version 5 protocol. One was performed by Least Authority, and another by Cure53. They are both accessible here. The protocol is implemented (but not activated) in Geth already – see below.
Authored by Franziska Heintel, Daniel Kirchner and Christian Reitwiessner
Since the last update, the Solidity team has released version 0.6.0. Apart from the abundance of features already announced in our previous post, this also includes “try/catch” as high-level syntax to handle failure conditions for external calls. In the meantime, the 0.6 series has stabilized in multiple minor releases and early planning for the next major release 0.7 has started (a future blog post will announce the features to be expected).
A notable new language feature within the 0.6 series is support for immutable variables. Starting from version 0.6.5 of Solidity state variables can be declared “immutable”. Immutable variables can be assigned once during contract creation and be cheaply read from runtime code. The constructor code will directly insert the values specified for the immutables during construction into the runtime code, so that the runtime cost of an access is merely that of a single PUSH.
The Yul optimizer continues to be improved; most notably we are introducing the Yul Phaser. The phaser is a tool that employs a genetic algorithm to find the best sequence of optimizer steps – in the future it could also be possible to use it on individual contracts if you want to spend more time compiling and get a cheaper contract.
The SMTChecker module continues to increase its support to Solidity, as well as improving its verification techniques. The new CHC engine now also supports internal function calls and multi-transaction counterexamples (unreleased), showing exactly how each transaction must be called in order to break an assertion. We are currently working on support to external functions and as usual, supporting more features of the Solidity language.
Finally, we are looking forward to the Solidity Summit, which will take place online on April 29-30. The Solidity Summit is an interactive forum with discussions and short talks about Solidity, Yul, language design and tooling. We aim to have useful discussions that result in improvement proposals and pave the way for actual implementations. Furthermore, we want to foster communication between teams working on similar topics and identify needs for the smart contract ecosystem for Ethereum. For information about registration, agenda and the livestream please visit the Solidity Summit website.
For regular updates, you can follow the Solidity team on Twitter or check out more Solidity-related content like feature deep dives, release announcements and bug reports on the recently launched Solidity blog!
Authored by Jacob Eberhardt
As part of this effort – and to better support programmatic interaction with ZoKrates – a new version of the ZoKrates ABI was developed. It is now capable of exposing complex data types in the same style Solidity does through ABI specifications.
To increase efficiency, we added further optimization techniques to the ZoKrates compiler: memoization of function calls, detection of unconstrained variables, and more. These optimizations are under review and subject to testing and we hope to bring them to you in the next release.
Native verification – a feature commonly requested by our users – is implemented as a prototype and currently undergoing testing.
Finally, the introduction of unsigned integers in ZoKrates which benefit from automatic optimizations is progressing. This is particularly useful when using widespread hash functions such as SHA256 and implementing algorithms that inherently use binary representations.
Author: Ethereum Foundation
Ethereum – MoneyBeat
MoneyBeat provides up-to-the-minute analysis of the news that shapes markets, deal-making and finance around the world. MoneyBeat is led by Chelsey Dulaney and Ben Eisen.