Make nodeos fail to start if eos-vm-oc-enable = true and producer-name = something

[matthewdarwin]

Since Block.one specifically recommends not running eos-vm-oc-enable = true when signing, then nodeos should fail to start if it is going to be signing. Could detect possibility of signing if producer-name = is set.

That would catch non-recommended behavior.

[spoonincode]

The primary reason EOS VM Optimized Compiler isn't recommended for BPs on public networks is because it can be much faster than even EOS VM JIT. So if BPs are running OC it can effectively force all other nodes on that chain to be running OC or they will be left in the dust. For public chains it is difficult to ensure this wide acceptance; particularly when, for example, there are still many nodes running pre 2.0, or we have supported platforms where OC doesn't even run yet (macos).

However, private blockchains don't suffer from those deployment woes: it's possible to ensure all nodes are running with OC enabled. Private blockchains are certainly a use case of EOSIO that even Block.one makes use of, so IMO I don't believe this is something that should be outright forbidden.

[matthewdarwin]

The main reason I was suggesting the change is that @arhag wrote in telegram back in January:

As a strategy to mitigate the risk posed by likely differences in behavior between the EOS VM variants while it is still young, we are suggesting that it would be wise to not use eos-vm-oc-enable=true on producing nodes and to just use eos-vm-jit by itself.

[cppfuns]

Is it still a problem if all BPs enable eos-vm-oc-enable at the same time?

[heifner]

It is not recommended for public network BPs to use eos-vm-oc-enable at this time.

[cppfuns]

It is not recommended for public network BPs to use eos-vm-oc-enable at this time.

If I build my own private chain, all BPs have eos-vm-oc-enable enabled, is there any problem? Or is it because the BP node has not been tested enough after it is turned on, is it uncertain whether it is stable?

[heifner]

Private chain where you control trxs you can run eos-vm-oc-enable on your BP signing node. You will also need to run it on all nodeos in the entire network for them to keep up. Also history may be difficult to maintain if running at full speed.

[cppfuns]

Also history may be difficult to maintain if running at full speed.
Sorry, don't understand why history is affected due to fast running

[heifner]

The bigger the blocks that nodeos produces (in terms of cpu billed size) the more data in terms of action data and state deltas and action traces are created that are stored in history solutions.

[cppfuns]

In other words, because eos-vm-oc-enable is enabled, the node processing speed is faster, and TPS will grow a lot, resulting in more data stored in each block, but I remember that each block has an upper storage volume limit. I can't remember, maybe 1MB or 2MB. For the maximum amount of data processed in each block of the chain, that is, each block is full, does it mean that it will only affect the query based on the chain layer, and will not affect the stability of block generation?

[heifner]

The block size on EOS Mainnet is currently set at 1MB. However, that controls incoming transaction size. A very small transaction can have a loop that generates a huge number of inline actions. These inline actions are stored in many history solutions. So a 1MB block of incoming transactions could potentially generate many MBs of action trace data. Depending on speed that might even be measured in GBs.

[cppfuns]

That is, at present, eos-vm-oc-enable is still waiting for the chain to make some adaptations to the VM before it can be used on the BP node. If this is the case, I would like to ask, what is the time when the plan is completed?

Thank you for your dedication and warm answer

[heifner]

Sorry we do not discuss release dates or timelines outside normal announcements.

[cppfuns]

Thank you, expect eos-vm-oc-enable to be used in BP production environment earlier