Consensus problems with initial eosio ABI

[tbfleming]

controller_impl::create_native_account uses this to set an initial ABI on the eosio account:

https://github.com/EOSIO/eos/blob/1418543149b7caf8fc69a23621e3db7f3c6d18ad/libraries/chain/controller.cpp#L870

There are several problems with this approach which may lead to consensus issues. The foundational problem is that this ABI isn't a version-independent constant:

• It silently changes whenever there are changes to abi_def and related structs. This happened with the ABI 1.0 to 1.1 upgrade.
• It will silently change if eosio_contract_abi.cpp changes. There's no indication in eosio_contract_abi.cpp of this danger. In fact, there's a TODO in that file which encourages future change: // TODO add ricardian contracts

By itself, this wouldn't create a consensus problem since ABIs aren't currently available to contracts. However:

• ABI storage affects RAM charges; this does affect consensus.
• Even though we have rejected making ABIs available to contracts, it's feasible that future maintainers could add this capability as a hard fork.

Speaking of RAM charges: this code fails to charge RAM for the ABI. This creates an inconsistency in RAM billing.

• Replacing the ABI could cause nodes to disagree on the current amount of RAM charged to eosio.
• Clearing the ABI could cause charged RAM to go negative.

We do not believe this issue causes production networks which run 1.7.x or 1.8.x to be vulnerable to attack:

• It's been a while since abi_def or eosio_contract_abi.cpp has changed. 1.7.x and 1.8.x agree on the initial ABI.
• We doubt any production networks have cleared out eosio's ABI or replaced it with a smaller one.

Mitigation:

• Both existing and new chains should not clear eosio's ABI or replace it with a smaller one. Replacing it with a larger ABI is ok.
• Chains which fork nodeos should avoid touching ABI-related code within nodeos.

Potential fixes:

• Since it affects consensus, the initial eosio ABI should be forced to be a constant across time. This means replacing the runtime-computed value with a hard-coded binary value which matches what 1.7.x and 1.8.x currently produce. This doesn't prevent chains from replacing the ABI using setabi. They should, however, still be mindful of the first mitigation above.
• A hard fork could correct the missing RAM charges. We don't see a strong reason to implement this at this time.
• To prevent future chains from dealing with this, a pre-genesis hard fork could do one of the following. This would not help existing chains:
  • Not set an initial ABI, or
  • Charge RAM correctly for it.

[aclark-b1]

In order to focus our efforts on issues that are currently creating difficulty for the community we are closing tickets that were created prior to the EOSIO 2.0 release. If you believe this issue is still relevant please feel free to reopen it or create a new one. Thank you for your continued support of EOSIO!