Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
EOSIO Deprecations #7597
Table tracking significant deprecations in EOSIO software
Additional notes on some deprecated features
history_plugin and mongo_db_plugin
The original WASM compiler for EOSIO smart contracts was called
RAM billing within notified contracts
The base EOSIO protocol allows contracts executing within a notification context to bill RAM to users included in the authorizations attached to the action they are notified of. This feature ultimately proved to be undesirable because of the burden it placed on users and contract developers to protect the RAM of their accounts from being consumed by malicious contracts. In v1.2.3 of the reference EOSIO software, an optional subjective mitigation (enabled by default) was added to restrict contracts from billing RAM to other accounts when executing within a notification context. Furthermore, this behavior was deprecated with the plan to eventually enforce the restriction objectively in a future protocol upgrade. In v1.8.0, support for the
Send-to-self authorization bypass
The base EOSIO protocol affords contracts an authorization bypass for actions that sent to itself (either via inline actions or deferred transactions). However, this authorization bypass had a flaw that enabled a privilege escalation enabling a contract to bill RAM usage to arbitrary EOSIO accounts. Therefore, in the v1.4.5 and v1.5.1 security releases of EOSIO (released on December 13, 2018), the authorization bypass behavior was severely restricted through a subjective mitigation. There was one exception allowed to minimize the impact of the restriction on existing contracts: an inline action sent by a contract to itself could carry forward an authorization included in the parent action.
However, all authorization bypasses (including the one exception made in the subjective mitigation) were announced as deprecated along with the releases on December 13, 2018 with the plan to enforce the restrictions objectively in a future protocol upgrade. In v1.8.0, support for the
Also, a lot of the community lost their keys by accidentally losing their docker container where they were created and stored. The devs at B1 started to have to support docker instead of focusing on improving the EOSIO code and issues related to it.
Do not think support dockerfile has much work. Instead, docker is much friendly to new users. And also, running in docker has many advantages such as restrict CPU, Memory Usage. As I know, there were terrible memory leak in some old EOS releases and I had to restrict the memory usage of EOS to protect other processes in my server.
docker: when we published docker images we were flooded with docker support questions. New users were getting confused by drive mappings, port mappings, shell aliases. They were struggling with Docker while at the same time learning eosio.
We released binaries and dropped docker to try to improve the new user experience.
People who really understand docker can still use it. It's really easy for these users to write their own dockerfiles which download and install the binaries we release. I'm concerned about giving dockerfiles to people who don't understand how to do even that.
history plugin: it's very buggy and its design isn't fixable. It places too high a load on nodeos. It corrupts nodeos's database. It skips some transactions while filling its database. There was a never-ending backlog of requests for more sophisticated filtering which would slow down nodeos even futher. We deprecated it a long time ago.
One of those sentences should have grabbed your attention. It drops some transactions while storing them. This is a problem we've mentioned in the past, but the message doesn't seem to get to everyone who needs to hear it.
The community has created several history solutions that use the state history plugin, plus history-tools is under development.