Ethereum (ETH) - POW/POS - Ethash
Ethereum Release Geth version 1.8.8 (Coffice)
Geth Coffice (v1.8.8) is a tiny biweekly release, containing countless code cleanup PRs from @kielbarry#16562).
- Fix crash when using an invalid private network genesis (#16682#16716).
- Handle Android signing keys flexibly, hopefully fixing Maven (#16696#16666).
- Support retrieving receipt status codes from the mobile libraries (#16598Geth 1.8.8 release milestone.
Binaries and mobile libraries are available on our download page.
The Swarm Team is pleased to announce the immediate release of Swarm client v0.3, the third proof-of-concept release (POC3) of the Ethereum Swarm client. The POC3 code is now merged into the official go-ethereum repository’s master branch.
Swarm 0.3 has been deployed to the public Testnet, and the Ethereum Foundation is running a 50-node strong cluster of Swarm nodes together with a public web gateway on https://swarm-gateways.net. We welcome everyone to try it out or commit to operate stable nodes.
The past year
It has been a year and a half since the first release of the POC2 series was deployed and the Swarm project launched its public alpha network. Two Swarm summits, two orange papers and forty thousand lines of code later, it is time to take stock.
In the past year the Swarm team has grown in size and is now on fire delivering the vision. We have been busy redesigning the network layer, rewriting the retrieval protocol using a stream abstraction, rewriting connectivity management and the overlay network code as well as developed a sophisticated network simulation framework to test algorithmic correctness, scalability and fault tolerance of various subsystems. POC3 code was finalised just in time for the Swarm Orange Summit in Ljubljana, where we had 80 participants and a very inspiring and creative week (watch this two-minute video hosted on Swarm) of talks and coding. It is inspiring to see a growing number of contributors and companies that want to build on swarm.
Swarm content storage is a lot more than just “bittorrent on steroids”. The technical details can be found in the chapter on architecture in the new and improved Swarm guide. You’ll find a more thorough academic presentation of Swarm’s components in the orange papers or learn more about Swarm through the recorded conference talks.
In an earlier blog post, we introduced the basics of Swarm storage and content distribution.
At its core, Swarm is a service that provides APIs to upload and download content to the cloud and through URL-based addressing offers virtual hosting of websites and decentralised applications (dapps) without webservers, using decentralised peer-to-peer distributed infrastructure. The vision is that of a new internet which is not only fault-tolerant, has zero downtime and offers censorship resistance but is also economically self-sustaining due to a built-in incentive system. By compensating nodes for contributing their bandwidth and disk space, these incentives aim to achieve reliable low-latency scalable retrieval of popular content on the one hand and guarantees persistence of important yet rarely accessed data like archives or backups on the other. For smooth delivery Swarm will use the SWAP protocol (planned for POC3.1) while for storage guarantees it will use a two-tiered insurance system (planned for POC4).
Beyond the basics of data storage and delivery, the POC 3 release includes some new and experimental features.
The online Windows XP simulator runs in a web browser and its operation imitates the operating system. You can use it to prank someone.
The same p2p connections that are used for data storage and delivery can also be used for node-to-node messaging. PSS combines Swarm routing (
bzz) with the Whisper (
shh) encrypted message format (
pss). In short, PSS is a messaging protocol with strong privacy features running on top of the Swarm network. This messaging infrastructure can be the foundation of a whole new system of internode communication services (the email, tweet, newsletter of the future), hence, can be referred to as Postal Service over Swarm.
PSS is fully featured yet experimental on the new POC3 network and dapps can interact with it using a JSON RPC API. We are collaborating closely with companies and projects that want to use pss to build second-layer infrastructure. Mainframe is building a slack-alternative collaborative group communications tool (Onyx) and their web3 SDK, and Status have expressed interest in building it into their mobile chat.
Another experimental new feature in POC3 is the Swarm Mutable Resource. Typical in p2p storage systems, content is addressed by its digital fingerprint (hash) and any changes to the content results in a change of this address. Users of the web, however, are accustomed to mutable resources: when visiting URLs we expect to see the most up-to-date version of the ‘site’. In order to make it easy to access changing content at permanent human-readable addresses, Swarm integrates with the Ethereum Name Service (ENS) on the Ethereum blockchain. This is what allows us to reference Swarm content by names like bzz://theswarm.eth.
Swarm POC3 adds another layer in the form of Mutable Resource Updates (MRU). These allow off-chain updates of content associated with an address at a potentially faster pace than ENS updates on the blockchain could support and without incurring the cost of on-chain transactions.
MRU is an experimental feature in current POC3 testnet and is still undergoing changes.
FUSE enables users to integrate Swarm data directly into their local file systems (only on Linux and Mac). Using this system, users can “mount a Swarm manifest” as if it were a regular directory. It supports file system read and write operations, in which all content is automatically synced with the Swarm. In future, combining FUSE with Swarm Mutable Resources, it should be possible, for example, to sync your entire home folder between devices - the backend to a decentralised storage with a Dropbox-like functionality.
Swarm 0.3 comes with built-in encryption allowing for secure uploads of private data. The way encryption works users can upload a directory privately and still ‘share’ a subdirectory with specific peers.
Access Control Trees (Swarm 0.3.2) will offer an API for users to manage access to content independently of publishing it. Granted access will work across versions of resources.
The year ahead
The year ahead will be both exciting and challenging. As part of the POC3 series we are planning to switch on a revamped SWAP accounting system (Swarm 0.3.1) and enable ‘light’ Swarm nodes (Swarm 0.3.2). Implementing erasure coding, proof of custody, insurance are also on the roadmap. We are on target delivering Swarm POC4 (production beta prerelease) in 2019.
We keep on building a community with our allies who champion the values of web3 and actively collaborate through working groups, building the foundational infrastructure, the backbone of second-layer services such as databases (http://wolk.com), private data management (http://datafund.io), rights and creative works licensing (http://jaak.io), decentralised version control (ethergit, http://epiclabs.io), video transcoding and streaming service (http://livepeer.org), communication and collaboration (https://mainframe.com) and the list is growing.
We welcome your feedback and contribution. Come find us in our gitter channelgithub repository.
We welcome your feedback and contribution. Come find us in our gitter channelgithub repository.
Ethereum Release Wallet and Mist Beta 0.11.0
The Mist team has been working hard on a solution to balance decentralization with user experience.
While running a full node is important to the health of the network, we all know the weight of doing so on a consumer machine. Amazing services, like Infura, can help you get connected immediately but introduces new risks.
From the beginning, Ethereum Wallet and Mist beta have prioritized running a local ethereum node, helping relay blocks and keep the pulse of the ethereum blockchain worldwide.
Today, we are introducing a hybrid solution that brings the swiftness of Infura with the power and security of running your own Geth node. After connecting immediately to a remote node, your local node takes over all subscriptions and filters once it's up to date.
Devcon4 Application Deadlines Coming Soon
Přátelé. Just a quick update today!
Applications for sponsorships, scholarships, student discounts and builder discounts will be up until 11:59PM PST on July 24th.
After that, there will no longer be a way to submit an application for these tracks. Please note that if you’ve already submitted an application or do so before the deadline, it will be processed and responded to by the Devcon team in short order!
As we continue to work toward providing everyone an opportunity to attend Devcon, we’re capping applications in preparation for future waves and to give the general public the chance to join us!
We look forward to receiving your applications soon, and to seeing you in Prague!
Ethereum Release Wallet and Mist Beta 0.11.1 - windows hotfix
We've identified an interface bug on Windows versions of Mist Browser and Ethereum Wallet v0.11.0 releases, leading to a blank screen after startup. This release fixes it.Checksum (SHA256) Ethereum-Wallet-installer-0-11-1.exe
Devcon4 Call for Participation!
When we asked many of you, “What are you most excited for at Devcon4?” most people replied: the people! This is the one time a year we all get together in one place. We don’t want to spend all of our time at Devcon sitting in a dark room, staring in silence at a person on a stage – we want to see, meet and talk with each other.
In that spirit, we’re designing the programming and environment of Devcon4 to provide the time and space for all of us to make new connections – between people and ideas. This is a chance for us to ask each other the most important questions and dive deep into the toughest challenges (and exciting opportunities!) facing Ethereum today.
So we’re going to experiment with more participatory programming at Devcon4 this year!
Here are three ways you can apply to participate in Devcon4:
- Give a presentation: This is self-explanatory. ;) Give a 5-minute lightning talk or a 20-minute presentation on the topic of your choice.
- Lead a workshop: Teach people to do something. Over the course of 2 hours, participants should “get their hands dirty,” whether writing code or learning to tell stories.
- Host a breakout room: Be creative and come up with your own programming for Devcon4! Host dapp design critiques, facilitate a conversation, do live security reviews, [enter your awesome idea here]
When you apply, we ask that you connect your session to one of six core themes:
- Scalability: How can we scale Ethereum in a secure, decentralized, and trustless manner in order to achieve mass adoption?
- Security: How can we ensure the safety of user data and funds?
- Privacy: How can we empower users to be in control of their own data?
- Developer Experience: How can we make developing for Ethereum simple, extensible, and fun?
- UX & Design: How can we create a more intuitive, usable and delightful experience for our users?
- Society & Systems: Why do we BUIDL? How will this technology change our societal systems, and the people within them? (To be clear: this is also a bit of a “catch all” theme for governance, cryptoeconomics, social impact, memes, etc.)
If you want to talk about your specific dapp or protocol, please do so in the context of one of these shared topics. How have you identified or solved a common problem? How can your work benefit the rest of our community?
With ~3000 participants and only so much time, we expect applications for participation to be highly competitive this year. Please buy your tickets ahead of time in the chance that your submission isn’t accepted so that you don’t miss out on getting a ticket to Devcon4! We will process a refund for anyone who purchases a ticket and then qualifies for a complimentary pass.
Please help us create a Devcon4 experience in the spirit of these values:
- Participatory: We are all creating the Ethereum ecosystem together and Devcon4 should reflect that. In addition to educational talks, Devcon4 should provide opportunities for participants to contribute to the broader conversation and share information with one another.
- Educational: As the only EF-hosted event, Devcon4 is a chance for our community to learn directly from the leaders of the Ethereum ecosystem. Participants should learn things they couldn’t learn anywhere else.
- Fun: The number one reason why people come to Devcon is to see one another! Let’s create a uniquely “Ethereum” family reunion for our community.
Visit https://devcon4.ethereum.org/c... to learn more and apply!
Ethereum Foundation Grants Update - Wave 3
Ethereum Foundation Grants Update
We’ve been hard at work getting to know so many amazing people and projects, and are extremely excited to announce the recipients of the Wave 3 of the Ethereum Foundation Grants Program!
We kicked off 2018 with a blog post to galvanize scalability research for first and second-layer solutions. Since then, we’ve committed over $11M to 52 projects dedicated to advancing the Ethereum ecosystem. Grants have funded multiple plasma and state channel implementations, diverse client research, enhanced developer frameworks, security audits, and so much more (find them all in the previous posts: Wave 1 & Wave 2)!
A Look into the Selection Process
Since the Grants Program has picked up, we’ve received feedback requesting greater transparency into our processes and a deeper look into the various types of projects considered. Here’s a funding snapshot and grant process update:
The EF Grant Program provided more than $11M in support to 52 projects since early 2018 (Waves 1, 2, and 3).
Our funding allocation remains true to the program’s original purpose, awarding nearly $7M to scalability projects. After this, security has been granted almost $2M, #buidl projects (projects that improve user experience) received $1.6M, and DevEx projects (projects that improve developer experience) received $744K. While dollar allocation remains heavily focused on scalability, the number of projects funded are more evenly distributed between categories.
Grants Process Update
The EF Grants program is constantly evolving. With this round, we’ve refined our internal processes to ensure timely fund disbursement. We understand how quickly the space moves and believe in the importance of expedient fund dispersal to the front line. Eventually, we aim to award grants on a rolling basis in order to provide more immediate support to the projects and teams leading the charge for decentralization and transparency.
Ideal applicants come with strong technical knowledge, project roadmap, and show a commitment to fostering collaboration within the ecosystem. For more information about applicant expectations and process workflow, please see our Applicant Expectations and FAQs.
With each round, the grants program evolves. Our goal is to effectively grease the wheels for projects building the critical infrastructure of our young community. There are many tracks to lay down before Ethereum “makes it” and it’s been incredible to see all the projects working to lay down these tracks.
The applicant pool for Wave 3 offered a record number of strong teams and innovative ideas. It’s fascinating and humbling to see the diversity of projects from around the world with a shared interest in fostering the development of Ethereum. These are folks spending their free time reading ethresear.ch, developing new libraries and wallet designs, and engaging in communities discussing the latest in DApp usability and security…and we love them for that.
Without further ado…
🎉 We are proud to announce our Wave 3 Finalists! 🎉
StarkWare – $4M with 6K ETH Performance-based Bounties. Development of standards report and production-quality software for optimized STARK-friendly hash functions and tooling
Force Move Game Framework – $300K. Force move games state channel framework
Harmony – $90K. Minimal sharding and random beacon chain
Kestrel Institute – $400K. Formal verification of cryptographic primitives
ICE Center at ETH Zurich – $185K. ICE Center research and tooling development
Pyramid – $30K. Smart contract language
Developer experience (DevEx grant)
Yakindu IDE – $95K. Eclipse-based IDE
Solidity Resolver Engine – $50K. Universal API tool
Etheratom – $45K. Atomized solidity IDE
Building for the end user (#buidl grant)
DappNode – $250K. Mass full node adoption
Uniswap – $100k. DEX framework
Nethermind – $50K. .NET client implementation
thaEth – $20K. Gnosis Safe UI Design
Cryptoeconomics.study – $35K. Buidling a textbook and coursework
Pseudo-randomly selected committees – $10K. Sharding R&D
Etherlinker – $10K. Unreal Engine 4 API for Ethereum
Scalability will continue to be a focus of EF grants, but we also look to fund other critical work. This includes better UX, new clients, high-level languages, better developer tools, and efforts to make Ethereum applications more secure. With Wave 3, we expanded into education and community efforts in order to help bring new talent into the ecosystem.
Want to #BUIDL with us? See the dev wishlist below and follow links to learn more. If you can imagine a project relating to the topics listed, submit an application and talk to us!
Wishlist for the next grant round
More payment and/or state channel implementations 💚💙💜
More plasma implementations 💚💙
More shasper implementations 🔥
A tokenless “Lightning Network” for Ethereum 💙
WebAssembly R&D 🔥
STARKS R&D 🔥
BLS12-381 implementations in new languages 🔥
libp2p Python implementation 🔥
Improve private key management and transacting in Ethereum 💚💙
Alternative wallet / client designs 💙💜
Standards and portability between wallets 💙
Tooling that improves developer experience 💚💙💜
Improved documentation & developer/user education videos 💚💙💜
Tokenless end user products 💜
More security focused high-level languages 💜
Solidity interpreter 🔥
Non-transferable ID tokens 🔥
Smart contract audits 💚💜
Specifically, audits for ERC20, ERC223, ERC721, multisig wallets, vaults 💜
Tooling that prevents vulnerable code 💚💙💜
IDE with a visual debugger 🔥
You already have a job (or school)? No problem! Suggest a problem you want to solve and we’re happy to fund a 10-week $10K externship for your spare-time working on Ethereum. 💚💙💜(Successful projects will be featured at a developer conference. We are also looking to hire and fund from this pool of side projects. If you’re looking for where to start, look at the list above.)
💚– Wave 1\ 💙– Wave 2\ 💜– Wave 3\ 🔥– New to wishlist
For more inspiration…
Read the original DevGrant post.
Read the post that kicked off the current program.
Grant Ops Contest!
With the growing number of applicants, we’ll be needing to create an official website for the Grants Program. Do you have any ideas on how to make the website fun, transparent, and useful to future grant applicants? (mmhmm) Great! Because we will be running a contest and crowdsourcing ideas from all of you. Selected ideas will receive some unicorn love and some ETH. Stay tuned for details on how to participate!
Solidity Bugfix Release
The latest version 0.4.25 release of Solidity fixes two important bugs. Another important bug has already been fixed in version 0.4.22 but it was only discovered recently that the bug existed.
Note that the Ethereum Foundation runs a bounty program for the code generator part of Solidity.
Cleanup of Exponent in Exponentiation
- Likelihood of occurrence: very low
- Exploitability: high
- Discoverability by tests: low
- Fixed in version: 0.4.25
Summary: Using short types in the exponent of an exponentiation operation can lead to invalid results.
The Solidity language allows integer types that are shorter than 256 bits, even though the Ethereum Virtual Machine only knows types of exactly 256 bits. Because of that, higher order bits need to be set to zero from time to time. For many operations, it is not relevant whether those bits are set to zero or not (addition is one example). Because of that, the Solidity compiler delays this cleanup until it is needed in order to save gas.
In the very special circumstance that the exponent of the
**operator has a type that is shorter than 256 bits, but not shorter than the type of the base and contains dirty higher order bits, this can lead to an incorrect result. Note that literal exponents like in
x ** 2as well as the case where the type of the base is
Note that a function parameter can have dirty higher order bits if called by a malicious entity, and the same is true for data returned from functions of contracts deployed by malicious entities.
After having screened a large number of contracts, we deem this bug to affect only a very tiny number of smart contracts, if any at all, because the regular uses of the exponentiation operator do not lead to the bug.
This bug was found by nweller.
Memory Corruption in Multi-Dimensional Array Decoder
- Likelihood of occurrence: low
- Exploitability: medium
- Discoverability by tests: high
- Introduced in version: 0.1.4
- Fixed in version: 0.4.22
Summary: Calling functions of other contracts that return multi-dimensional fixed-size arrays results in memory corruption.
If Solidity code calls a function that returns a multi-dimensional fixed-size array, the returned ABI-encoded data has to be converted to Solidity’s internal representation of arrays. In Solidity, multi-dimensional arrays are implemented as arrays of memory pointers, while in the ABI, the data is encoded inline. The decoder did not take this difference into account with the result that the returned elements are interpreted as memory pointers and thus can cause memory corruption if the return values are accessed. Calling functions with multi-dimensional fixed-size array arguments is unaffected as is returning fixed-size arrays from function calls if they are not used in a Solidity contract. The bug is only in the component that decodes a multi-dimensional fixed-size array that is returned from a function call from Solidity.
This bug was found by jmahhh.
Invalid Encoding of Structs in Events
- Likelihood of occurrence: low
- Exploitability: low
- Discoverability by tests: high
- Introduced in version: 0.4.17
- Fixed in version: 0.4.25
Summary: Structs as event parameters are not handled properly.
Structs were not meant to be supported as event parameters without the new ABI encoder. The compiler did accept them nevertheless, but encoded their memory address instead of their actual value. Even with the new ABI encoder, structs cannot be
Now, structs are properly disallowed for the old encoder and if they are indexed also for the new encoder.