EOSIO 1.0

EOSIO v1.0 Release Notes (since Dawn 4.2)

With the release of EOSIO v1.0 we’ve got a few small changes from Dawn 4.2. Below is a summary of the more interesting updates since our last release.

Introducing bnet Plugin

This release introduces an alternative P2P network protocol based upon boost::beast websockets and enables multi-threaded networking and faster syncing.

This net plugin works side-by-side with the existing net plugin, though it will only talk to other bnet_plugins on the network. It is entirely independent / optional. To get up and running with the new plugin, simply include eosio::bnet_plugin in your config file or through the command line.

Bug Bounty

Early this week, Dan Larimer announced the bug bounty program which drew significant attention from the community. We’ve since launched the EOSIO Bug Bounty Program in partnership with the leading ethical hacker-powered security platform, HackerOne. This on-going program will harness the collective intelligence and capabilities of the Block.one Engineering team and leading security researchers via HackerOne’s user-friendly interface.

To submit a report, please visit https://hackerone.com/eosio

Whitelist/Blacklist

Nodes may want the ability to blacklist or whitelist certain contracts from executing on their node under the context of producing a block (either speculatively or as the real block producer that will then sign the block).

Such an ability, particularly whitelisting, will be quite handy early on in the first bootstrapping process of an EOSIO blockchain to provide confidence that the core functionality of the chain (system contract, token contract, multisig contract, and native actions) are all working together properly prior to opening up the chain to arbitrary user-submitted contracts which greatly increase the attack surface.

A whitelist or blacklist can be provided just like other nodeos options (in config.ini or via command line arguments) for contracts and actors (i.e. the authorizing accounts of a transaction).

To support this feature, four new options were added to the chain plugin via nodeos. They are “--actor-whitelist”, “--actor-blacklist”, “--contract-whitelist”, and “--contract-blacklist”.

For the full details, please visit the GitHub issue: #3376

Out-of-process Block Signing Private Keys (Experimental)

This release introduces basic support for connecting a producing nodeos process to a keosd process for the purpose of removing sensitive data (the block signing key) from the the process running untrusted smart contract code. Additionally, this feature paves the way for future support of Hardware Security Modules (HSM).

Connections between keosd and nodeos can be secured by TLS; and the two processes can be hosted in different containers, virtual machines, or even remote endpoints.

Other Notable Updates

Require wallet password when revealing private keys
Some small changes to RPC endpoints and cleos options. Any command that would reveal a private key now requires the wallet’s password. “/v1/wallet/list_keys” now requires two parameters, the name of the wallet and the wallet’s password. There is a new command in cleos, “private_keys”, that maps directly to the “/v1/wallet/list_keys” endpoint. Furthermore, the existing command “keys” now only returns public keys.

Expose runtime options in the producer api plugin
Two new endpoints have been created to expose and update runtime parameters in nodeos. The command “/v1/producers/get_runtime_options” takes no parameters and returns a json object of producer plugin specific config.ini and command line parameters in use. A second command “/v1/producers/update_runtime_options” takes a json payload to set corresponding parameters. Each field is optional, so you don’t have to set all options, you can use it sparsely. The settings will take effect immediately.

“genesis-json” option no longer supported in the config file
Following the changes from the Dawn 4.2 release around the genesis.json file, we’ve removed the “genesis-json” option from the config.ini file as a valid parameter. This can only be passed in from the command line and should only happen on a fresh node without blocks prior to synchronizing with the network.

New config option p2p-max-nodes-per-host
Added a new config item, “p2p-max-nodes-per-host”, to limit the number of client connections accepted from any one host IP address. This defaults to 1.

keosd no longer started for operations where it isn't necessary
We have disable the launch of keosd for get, version, net, and create key subcommands.

Changed the default port for cleos actions from port 80 or 443
Sets the default port to the expected value based on the URL scheme if you pass in a custom URL. The default value is still “http://localhost:8888” if nothing is passed in.

Changed the default “max-irreversible-block-age” to unlimited
The default for “max-irreversible-block-age” is now unlimited. You can set the value to unlimited explicitly by passing “-1” to the option in the config or the command line. Block producers should set this to a reasonable number in the config.ini file.

Creating a new account now requires a buy RAM command
In order to create a new account, you are now required to either “--buy-ram”, which takes tokens as a parameter, or “--buy-ram-kbytes”, which takes the amount of RAM you want to buy in kilobytes.

EOSIO Dawn 4.2

EOSIO Dawn 4.2 Release

With EOSIO version 1.0 right around the corner, today we have tagged a Dawn 4.2 release of the EOSIO software. A couple of small features worked their way into the code, but as you’ll see below, we’ve been focused on bug fixes and stability improvements.

Notable Updates

Segregated EOSIO.SYSTEM Funds

To ensure the allocation of system funds is clear we’ve decided to segregate system funds as follows:

• implemented a 1% fee on all RAM buying and selling
• all RAM trading fees sent from user to eosio.ramfee
• all proceeds from selling RAM sent from eosio.ram
• all staked tokens sent to eosio.stake
• all unstaked tokens sent from eosio.stake
• all account name auction proceeds sent to eosio.names
• unallocated inflation sent to eosio.saving
• producer block pay sent to eosio.bpay
• producer vote pay sent to eosio.vpay

See contracts/eosio.system/producer_pay.cpp for details.

Chain Plugin

We’ve seen a little confusion in the community about some of the data stored on disk and options available to users that are running nodes, and have attempted to make things clearer via the following updates.

We renamed the "shared_mem" directory to "state" and changed a few of the plugin options:

• "--block-log-dir" renamed to "--blocks-dir"
• "--checkpoint" shorthand alias "-c" was removed
• "--shared-memory-size-mb" renamed to "--chain-state-db-size-mb"
• added "--reversible-blocks-db-size-mb" to change default size of reversible blocks DB
• "--resync-blockchain" renamed to "--delete-all-blocks" to discourage the use of this option
• “--contracts-console” prints contract output to console and is also available via config.ini now
• added “--hard-replay-blockchain” to move block logs and data into a backup directory and construct a new “blocks.log” file and will then continue as if “--replay-blockchain” was used
• added “--force-all-checks” to force checking authorizations on input transactions, inline actions, and contract-generated transactions
• added “--fix-reversible-blocks” to allow nodeos to try to recover from the “reversible” blocks database and then immediately exit
• updated “--hard-replay-blockchain” to attempt to recover and replay as many reversible blocks as possible from the “reversible” block database, even if it is left in a dirty state
• added “--genesis-json” to specify file to read genesis state from
• added "--genesis-timestamp" to override the initial timestamp in the Genesis State file
• added "--print-genesis-json" to extract genesis state from blocks.log as JSON and print to console
• added "--extract-genesis-json " to extract genesis state from blocks.log as JSON and write to specified file

Producer Plugin

We added a command line argument (--max-irreversible-block-age) that will cause a node to automatically stop production when the last irreversible block time is older than N seconds, an indication that there are not enough producers confirming blocks for the chain to continue forward. This option prevents producers from producing an excessive number of blocks that will need to be rationalized upon resuming production once enough producers rejoin the network.

We added the ability to pause node production on demand. The goal is to allow producers to coordinate during bad situations to resume/pause the chain without having the variability of replay/resync time etc.

For reference:
POST /v1/producer/pause - pause production
POST /v1/producer/resume - resume from paused production
POST /v1/producer/paused - return true/false depending on whether the node is currently paused

Genesis JSON File No Longer Created By Default

genesis.json is no longer expected to be in the config directory and will not be automatically generated. Here’s what you’ll need to do:

nodeos --extract-genesis-json <genesis filename>

Modify the file, change the timestamp, change the initial producer key and any other parameters that you normally change. Share the file as you’ve done in the past.

nodeos --delete-all-blocks --genesis-json <genesis filename> to initialize a new blockchain (on all nodes)

On subsequent launches, do not specify --genesis-json, nodeos will pull the genesis state from the block log, and of course do not --delete-all-blocks either.

If nodeos does not restart cleanly, --replay-blockchain and if that does not work --hard-replay-blockchain.

The resync option has been renamed to --delete-all-blocks to indicate what it is actually doing.

BIOS Boot Process Tutorial Updates

We made improvements to the BIOS boot tutorial including producers claim pay, proxy voting, eosio account resigning, producers use eosio.msig contract to replace eosio.system contract and some bug fixes. Please note that we moved the tutorial support files from the “programs” directory to a new “tutorials” directory.

Other Updates

As was mentioned last week in the “Quality Name Distribution & Namespaces” (#3189) proposal, the name auction has been implemented though it will not become active until two weeks after the network unlocks (15% votes).

Producers can now only increase RAM size and never decrease. This was done to prevent potential manipulation of the RAM market by block producers.

We’ve updated the version of the Boost library that we build against from 1.66 to 1.67.

The “data/shared_mem” directory has been renamed to “data/state”.

The “block-log-dir” config.ini option has been renamed to “blocks-dir”.

Changed the “set_active_producers” intrinsic to “set_proposed_producers” to more accurately reflect the intention of the function which is to propose a new, active producer schedule.

Following last week’s change to the token symbol, we added the ability to specify the core token symbol in the Dockerfile. We also switched to Ubuntu 18.04 LTS for the Docker builder image.

The chain ID is now the SHA256 digest of the genesis state configured when initializing a chain. Unless overridden using --genesis-json, nodeos will use the default genesis state built into the software. The default genesis state's initial root key can be changed using the EOSIO_ROOT_KEY CMake option.

We noticed, and fixed, an unexpectedly high rate of mini forks on producer handoff, especially with high network latency between producers.

Block producers may now change blockchain parameters via the system contract by using the newly added “setparams” action.

Several testnets noticed that the grace period for inactivating recently voted in producers was too strict. The grace period has been changed from roughly four minutes to seven hours. A few other corner cases for deactivation were addressed as well.

We greatly reduced the memory usage of the history plugin by reducing the tracked actions to only those that match explicit filter rules. There is now no way to track all actions since that is susceptible to filling shared_mem.

We discovered, and corrected, an infinite recursion bug with various, malformed abi definitions.

We changed producer deactivation logic to prevent block producers from being removed from the production schedule improperly. We now update the producer field “time_became_active” every time a producer gets voted in as opposed to the first time only. If it's the first time or it's been over a day since a producer was last voted in, we don't check their “last_produced_block_time” and we don't deactivate them. Otherwise, the logic stays the same. This way we don't penalize a producer for not producing blocks after getting voted out.

Patroneos

We introduced Patroneos last week, and it is now available to the community via the EOSIO GitHub repository, https://github.com/EOSIO/patroneos.

As a reminder, Patroneos provides a layer of protection for EOSIO nodes designed to protect against some of the basic Denial of Service attack vectors.

Dawn 4.2 on GitHub

EOSIO Dawn 4.2 is available on GitHub here (https://github.com/EOSIO/eos/releases/tag/dawn-v4.2.0) so that developers and block producer candidates can continue testing their applications and networks.

Community Support

As a reminder, we love hearing from our community and are dedicated to helping them run EOSIO successfully. Our EOSIO Stack Exchange (https://eosio.stackexchange.com/) beta is going well and we encourage questions about how to use the software on Stack Exchange. Please continue to report any potential bugs you may see in GitHub and include the following information:

Testnet:
EOSIO git version: <”nodeos -v” output>
config.ini: attach your config.ini file
genesis.json: attach your genesis.json file
Command line: your full nodeos command line
Console output: attach console debug output around the error that you are seeing (ok to paste into the description if it is small)

Future Releases

We’re on target for the EOSIO Version 1.0 release on June 1st. You can follow the issues that we are committed to working on over the next few weeks by observing the Version 1.0 milestone (https://github.com/EOSIO/eos/milestone/10) in GitHub.

EOSIO Dawn 4.1

EOSIO Dawn 4.1 Release

As we continue the march towards our 1.0 release, today we have tagged a 4.1 release of the EOSIO software.

Notable Updates

We continue to squash bugs and improve stability. We’ve fixed issues relating to general network stability, duplicate transactions spamming the network, nodes failing to propagate transactions in some instances, and others.

Bringing a Failed Node Back Online

We have enhanced nodeos to persist accepted but reversible blocks (#3140). This greatly improves the startup time for nodes to come back online and resync.

Command Line Tool Improvements

The command line tool cleos is now able to output the full list of producers (#2933). Note that you can paginate results and that they’re sorted by vote.

Quality Name Distribution & Namespaces

Of particular note in this release is the restriction of account names to exactly 12 characters with no periods/dots (“.”). This is change is in an attempt to discourage name squatting. Dan is requesting community feedback for his proposal regarding name distribution via GitHub (#3189).

Renaming of the Core Token

Please be aware that we have changed the name of the token symbol from “EOS” to “SYS”. If you would like to change the name to something different, check CORE_SYMBOL_NAME in the “CMakeLists.txt” file.

BIOS Boot Process Tutorial

There is now a script that demonstrates the steps necessary to boot an EOSIO network along with a detailed tutorial (https://github.com/EOSIO/eos/tree/master/programs/bios-boot-tutorial). We will be adding additional steps to this script and tutorial in the coming week related to upgrading the eosio.system and eosio.token contracts via the producers using multi-sig.

Testnets

Our internal testnets are running strong. We’ve been happily watching multiple community testnets and we are proud of the work that we see there. Of particular note is the EOS Jungle Testnet (http://dev.cryptolions.io) which has been running an earlier build (DAWN-2018-05-16) for the last few days and has participation from over 70 nodes. Watch for more updates on the EOSIO Community Testnet (https://t.me/CommunityTestnet) Telegram group.

Patroneos

We are preparing a new tool for protecting RPC-API endpoints from abuse. We are calling it Patroneos because it keeps the Dementors soul sucking spammers at bay. Behaviors that we’re currently watching out for are things such as repeated, invalid JSON payloads, signature spam, blacklisted contracts, and oversized transaction payloads.

We’ve been developing this tool in-house and will be releasing more information to the community in the near future. Keep an eye out for this one.

Dawn 4.1 on GitHub

EOSIO Dawn 4.1 is available on GitHub here (https://github.com/EOSIO/eos/releases/tag/dawn-v4.1.0) so that developers and block producer candidates can continue testing their applications and networks.

Community Support

We love hearing from our community and are dedicated to helping them run EOSIO successfully. Our EOSIO Stack Exchange (https://eosio.stackexchange.com/) beta is going well and we encourage questions about how to use the software on Stack Exchange.

Please continue to report any potential bugs you may see in GitHub and include the following information:

Testnet: what testnet you are reporting the issue on
EOSIO git version: nodeos -v output
config.ini: attach your config.ini file
genesis.json: attach your genesis.json file
Command line: your full nodeos command line
Console output: attach console debug output around the error that you are seeing (ok to paste into the description if it is small)

Future Releases

We plan one more pre-release (Dawn 4.2) next Friday May 25th and we’re on target for the EOSIO Version 1.0 release on June 1st. You can follow the issues that we are committed to working on over the next few weeks by observing the Version 1.0 milestone (https://github.com/EOSIO/eos/milestone/10) in GitHub.

EOSIO Dawn 4.0

This is the latest pre-release of EOSIO software.

For more info:
https://medium.com/eosio/introducing-eosio-dawn-4-0-f738c552879

https://medium.com/@bytemaster/eosio-dawn-4-0-release-b25661a49ac2

EOSIO Dawn 3.0

Block.one is excited to announce the first feature-complete pre-release of EOSIO, Dawn 3.0. This pre-release represents a major milestone on the road to EOSIO 1.0 targeted for release in June 2018.

For more details see our blog: https://medium.com/@bytemaster/eosio-dawn-3-0-now-available-49a3b99242d7

DAWN-2018-01-31-ALPHA

DAWN-2018-01-31-ALPHA

STAT-2017-12-21

Merge pull request #988 from EOSIO/p2p-stat-271-gh916-5

fix for failure to start producing blocks #916

STAT-2017-12-13

Adds the ability to connect via remote eosd

STAT-2017-12-12

Reverts primary genesis.json to local testnet version.

Incorporates fixes for the following:

• STAT-272 ⁃ Fix wiping of ./tn_data problem when eosd is run from launcher with no args #927
• STAT-263 ⁃ Create a configurable "Fetch" parameter #881
• STAT-261 ⁃ Investigate and solve reported activity that causes EOSC to crash #876
• STAT-237 ⁃ Update the max-clients = 25 parameter #865

EOS.IO Dawn v2.0 - Pre-Release

EOS.IO Dawn 2.0 is the second pre-release of the EOS.IO SDK (Software Development Kit).

The Dawn series of EOS.IO software releases represent early alpha- and beta-quality software suitable for use by those looking to get a head start on the EOS.IO ecosystem. These releases are focused on providing developer APIs and a productive developer environment.

Table of Contents

1. Who This Release is For
   • Minimum Configuration
2. Features Included in this Release
   • Features Not Included in this Release
3. Differences Between Public and Private Testnets
4. Known Open Issues
   • Benchmarking
5. Disclaimer

Who This Release is For

Whether you are an experienced C++ developer interested in blockchain or a seasoned blockchain expert, you are welcome to experiment with this second pre-release. Familiarity with Linux/C++ is highly recommended. Experience with smart contracts is not a prerequisite -- you'll get that here.

If you are unfamiliar with both Linux and C++, please wait for a more end-user friendly release. The current release is for experienced developers.

Minimum Configuration

Currently EOS.IO has been tested on Ubuntu 16.10 and Mac OS Sierra. EOS.IO nodes run well on a minimum hardware requirement of Core i7 CPU, 16GB RAM. Some users have reported success with 8GB RAM, but this configuration is not supported at this time.

Features Included in this Release

Note that, as of this release, we are evolving away from the previously released Roadmap. We expect to publish a revised roadmap in Q4, 2017.

General Features

• Configurable block time (previously hard coded at 3 seconds)
• P2P code hardened with improved node sync
• Developer API with standardized coding style
• Wallet to set up and maintain accounts that use the API
• Contract Security and Authorization
• Simple Rate and Database Limiting
• Github repository with tutorials, code, documentation and sample Smart Contracts
• Single-threaded, so expect between 500 to 1000 Transactions Per Second (TPS) on private testnets and standalone deployments

Features Unique to the Public Testnet

• Two (2) second block time
• Simulates the eventual EOS Production environment that will be available mid-2018
• 21 block-producing nodes, 1 per host
• Genesis block for registered EOS token holders
  • Developers who do not have tokens in the Genesis block can request them via our Faucet facility. Contact Developer Support via Telegram for further instructions.
• For the 04-Dec-2017 Public Testnet launch, performance is throttled down to 30 transactions per second. This is because there are known attack vectors for which we have unimplemented solutions. For example, compilation of new contracts for the first time can take up to 34ms, which if exploited could cause the network to fragment at transaction rates over 30 TPS. When the solution is implemented this restriction is expected to be lifted for at least some operations.

Programs

• A standalone node eosd that produces blocks and adds them to the blockchain
• A client eosc that provides a command line interface
• eos-walletd provides a client-side local wallet server
• A launcher that configures and optionally starts a local or distributed multi-node testnet

Scripts

• build.sh to install dependencies and build eos
• eoscpp for smart contract developers to build contracts

Example Contracts

• Native contracts,
  • native currency
  • staking
  • producer voting
  • code updating
  • permission updating
• Example contracts
  • dice
  • exchange
  • simpledb
  • social

Documentation

• Virtual machine API
  • deferred / inline messaging
  • user-local storage for contracts
  • 3 built in database types
• Basic developer documentation (at https://eosio.github.io/eos/)
  • installation and setup
  • build and deployment
  • tutorials for blockchain commands
  • Doxygen based API reference

Utilities and Other Features

Genesis Block Generator

• We have a tool in pre-release that allows for generation of a custom genesis.json file, i.e. a Genesis Block, that includes our Genesis Snapshot of ERC20 tokens already registered. This tool is not yet supported and you use it at your own risk. Access it at https://eosio.github.io/genesis/

Features Not Included in this Release

Not included in this release are:

• Advanced resource usage and rate limiting
• Inter-blockchain communication
• Hacked account recovery
• These native contracts:
  • producer proxy voting
  • EOS.IO Storage
  • feature upgrade voting (hard forks)
  • stake delegation (renting and leasing tokens)

Differences Between Public and Private Testnets

No producer voting in Public Testnet

The public testnet has had producer voting disabled. You can enable this on your private testnet with minor code changes -- look at the tags prior to 01-Dec-2017 for the non-disabled code.

Throttling of Public Testnet

As noted above, at time of release the public testnet is being rate-limited to 30 transactions per second. Private testnets will not be limited in this fashion. This is a configuration setting and code downloaded from GitHub will be unthrottled.

Known Open Issues

Multi-Signature Wallet #867

Multi-sig wallets will not behave correctly in some cases

MongoDB

At the time of release, mongodb was not up yet on the Testnet; this may change very quickly so check in with developer support via the EOS Developer channel on Telegram

Connection to Testnet via eosd #864

eosc can connect, but eosd cannot connect to the Testnet yet

max-clients setting #865

Max-clients parameter is for external eosd connections and is currently limited to 25; it must be a larger number to support significant numbers of external eosds connecting to the Testnet

Genesis file generator #861

• The genesis file generator at https://eosio.github.io/genesis/ omits " EOS" in the liquid balance of new accounts it adds.
• The "initial_timestamp" is set for a time in the future rather than the current time.
• The "initial_parameters" should have numeric values that are UNQUOTED but they are in fact double-quoted.

Launcher creates empty config.ini #842

In some circumstances the launcher generates a config.ini that is empty.

Other open issues

A list of open issues can be found here:

• https://github.com/EOSIO/eos/issues

Benchmarking

We have tools that have enabled us to benchmark the code at over 10,000 TPS per second under certain controlled conditions, but it remains too early for anyone to reliably reproduce benchmarks and/or interpret the results for a number of reasons:

• you must operate a multi-node network and push transactions to multiple different nodes
• block production algorithm does not currently time-bound generation which means benchmarks do not properly capture "backlog" or generation bottlenecks
• the HTTP interface is currently a bottleneck in submitting transactions to the network
• the signature verification is not yet multi-threaded

This release is designed to help developers build their applications. It does not provide a robust performance benchmarking toolkit.

Those wishing to attempt their own benchmarking, or who wish to generate traffic on their private testnets for other reasons, may choose to look at the code underlying the eosc benchmark transfer command, which serves as an example. It was developed internally to simulate user traffic.

Disclaimer

block.one is a software company and is producing the EOS.IO software as free, open source software. This software may enable those who deploy it to launch a blockchain or decentralized applications with the features described above. block.one will not be launching a public blockchain based on the EOS.IO software. It will be the sole responsibility of third parties and the community and those who wish to become block producers to implement the features and/or provide the services described above as they see fit. block.one does not guarantee that anyone will implement such features or provide such services or that the EOS.IO software will be adopted and deployed in any way.

*All statements in this document, other than statements of historical facts, including any statements regarding block.one’s business strategy, plans, prospects, developments and objectives are forward looking statements. These statements are only predictions and reflect block.one’s current beliefs and expectations with respect to future events and are based on assumptions and are subject to risk, uncertainties and change at any time. We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from those contained in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements contained herein include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions. Any forward-looking statement made by block.one speaks only as of the date on which it is made and block.on...