EOSIO Deprecations #7597
Comments
|
Why deprecate Dockerfile? I think EOS in docker is much easier to run. |
Do you think it is easier to use compared to binaries? With Docker image, you have to ssh into the docker container to access your files |
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. |
|
history plugin is still used by the majorities, including many bp nodes, so don't deprecate it, our small team can add filters, and that doesn't cost too much memory, and helps us because it doesn't depend on a database other than state-history-plugin. |
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. |
ndcgundlach
added
documentation
|
Removing the "documentation" label since it was clear from the discussions that it was preferred to continue to maintain this content within github, separate from the developer portal docs. |
lparisc
removed
the
documentation
Table tracking significant deprecations in EOSIO software
read-onlymodeAdditional notes on some deprecated features
history_plugin and mongo_db_plugin
The
history_pluginwas deprecated on August 12, 2018. The mongo_db_plugin was deprecated on April 29, 2019. Both of these plugins are still available in EOSIO software, but they are not recommended for use. Instead one can use a history solution built on top of thestate_history_pluginwhich became stable on June 28, 2019.eosiocpp
The original WASM compiler for EOSIO smart contracts was called
eosiocpp(not to be confused with the newereosio-cppcompiler). The compiler along with the libraries to help with smart contract development were initially kept in the EOSIO repository. The compiler and the smart contract libraries were improved upon and moved into a separate repository containing the tools needed for EOSIO smart contract development: eosio.cdt. The old WASM compiler and smart contract libraries were removed from the EOSIO repository in v1.7.0. Contract developers are now expected to use the eosio.cdt to build smart contracts.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
RAM_RESTRICTIONSprotocol feature was added which, when activated, makes the restriction an official part of the protocol but also enables flexibilities in how RAM usage can change during contract execution.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
RESTRICT_ACTION_TO_SELFprotocol feature was added which, when activated, changes the EOSIO protocol to remove all authorization bypasses that exist in the base protocol.Deferred transactions
Contract authors are encouraged to not use deferred transactions. Those interested in migrating to newer design paradigms can consider the options presented in the EOSIO Specifications Repository.
WAVM runtime
The WAVM WebAssembly runtime is not recommended for use on live nodes on public EOSIO networks. You can consider using WAVM to speed up replays until EOS VM becomes stable, at which point the tier-up solution of EOS VM Optimized Compiler should be considered as a replacement for WAVM.
read-mode = read-only
The database
read-modeoption ofread-onlyis deprecated. The same functionality is now provided by the combination of options:read-mode = head,p2p-accept-transactions = false, andapi-accept-transactions = false. The new options provide better control and more clearly define usage.cleos get code wast output
cleos get codebefore returns the code in wast format unless--wasmoption was used. Going forward the--wasmwill be implied and the only supported output format. Users can use standard WebAssembly tooling for conversion to wast.The text was updated successfully, but these errors were encountered: