EVM-compatible blockchains are based on the Ethereum Virtual Machine (EVM), a runtime environment that executes smart contracts on the blockchain. The EVM is designed to be platform-independent, which means that it can run on different blockchain networks that support the EVM standard. However, similarity makes it difficult for BSC to retain projects, which jump between EVM-compatible blockchains in hope for grants and investments.
In order to make BSC more attractive for the new projects and retain existing projects in BSC, there should be added value and optimal user/developer UX, versus other blockchains.
One way that EVM-compatible blockchains can introduce changes to the EVM is by implementing new features or functionalities that are not available on other EVM-compatible networks.
BSC may introduce new opcode instructions or introduce new types of smart contracts that are not available on other EVM-compatible networks. This can create a barrier to migration for projects that rely on these new features or functionalities, as they may need to modify their smart contracts or applications to be compatible with the new blockchain network.
One thing to notice is introducing new opcodes usually need to have lots of adaptive work in frontend compiler such as solidity compiler, or Yul codegen, it seems a little complicated since there needs to be extra work to persuade those comminities.
An other way is to develop a bytecode tool which re-work on those standard one and generate our own version of opcodes, which also seems somewhat complicated.
Native Random Generator
BSC can implement VRF oracle and enable native VRF, accessible through a new opcode.
- Can also be implemented as call to a partner oracle VRF to remove the complexity of implementation
- Gas price of new opcode can be adjusted to cover the costs
- Requires changes to consensus
- Requires more investigation for risk of VRF being predicted and abused
Native Oracle pricing
BSC can implement and embed oracle prices into the block production lifecycle.
All validators will append oracle feed as part of the execution of a block. This then allows for the state machine to utilize this validator posted information as part of the following block. In the context of the BSC oracle, for every asset that a validator posts prices, the state machine can take the mean and then set that value as the “reported price” for the upcoming block. This allows for off-chain data to bypass the mempool, while getting the same byzantine fault tolerance guarantees as the consensus engine itself.
- Gas price of new opcode can be adjusted to cover the oracle costs
- Integrates other BNB Chain projects with possible revenue
- Requires changes to consensus and block creation mechanism
- Requires more investigation for risk of price manipulation by the validator
BSC may increase the EVM runtime limits, which will enable more complex code to be run on BSC EVM.
Increasing runtime stack
When one starts coding smart contracts in Solidity, sooner or later, s/he will hit a very annoying obstacle - the “Stack Too Deep” error. It is easy to fall into this trap, and when that happens, it is often hard to find a way out. The underlying reason is not in Solidity itself, but in the Ethereum Virtual Machine (the EVM), and so will likely affect other languages that compile into EVM (ie LLL, Serpent, Viper), but that is a subtle distinction in the day-to-day job of coding smart contracts.
In general terms, this error seems to be generated when the code needs to access a slot in the stack that is deeper than its 16th element (counting from the top downwards). And given the frequency of the error, increasing stack depth on BSC to a higher level, will cause smart contracts to fail in numerous places, once migrated to other EVM-compatible blockchains.
- Will be very difficult for developers to notice the value, only until they run and see that the complex code doesn’t run on other EVMs, as there is no mention of stack depth during development and they will easily write code that exceeds the standard stack depth
- Enlarge stack limit is a good way to fit “deep call” scenario, we can provide the ability of “adaptive configurable” stack limit in our own version of EVM.
- We can also try to mitigate this kind of “recursive call” issue by leverage compilation optimization such as tail call / function inlining (that is , have our own bytecode optimizer that provide more attractive abilities/optimizations for contracts running on BSC)
BSC can introduce changes to the EVM by optimizing the EVM for their specific use case. For example, BSC may optimize the EVM for high-performance computing or for specific types of smart contract execution.
This can create a performance advantage for projects that use the optimized EVM, but it can also create a barrier to migration for projects that rely on the standard EVM. Projects will experience a performance impediment, once migrated from BSC to the standard EVM.
- Only adds value to the programmers and doesn’t break the code, once migrated
- Difficult to implement
- Difficult to attract usage
- Requires detailed analysis