BSC EVM improvements

High Performance Client EVM Optimization
,
1

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.

Suggestions

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.

New opcode

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.

Advantages

  • 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

Disadvantages

  • 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.

Advantages

  • Gas price of new opcode can be adjusted to cover the oracle costs
  • Integrates other BNB Chain projects with possible revenue

Disadvantages

  • Requires changes to consensus and block creation mechanism
  • Requires more investigation for risk of price manipulation by the validator

Infrastructure changes

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.

Advantages

  • 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.

Disadvantages

  • 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)

Specific Optimisations

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.

Advantages

  • Only adds value to the programmers and doesn’t break the code, once migrated

Disadvantages

  • Difficult to implement
  • Difficult to attract usage
  • Requires detailed analysis
2 Likes
2

Really like the idea, and maybe BSC could provide more elegant developer tools that could help on optimize devOps; or more advanced optimization tools that could help provide unique and best performance for DApps running on top of BSC.

1 Like
3

@sunny2022da do you any ideas in mind or tools from other blockchains or web2 cloud tools?

1 Like
4

I am thinking of bytecode fusion alike tech, which is assumed to be help on gas saving and performence enhancing. The logic is that we can develop a bytecode optimizer, which statically parses the bytecode, combines the most frequently paired bytecodes together, e.g. “Push; JUMP” and hence optmize it to generated a special bytecode such as JUMPR (which looks like the EIP-4200 but only change at bytecode level) . Another similar idea is like using statical analyze to help sum up the static gas consumption ahead of time, which could also help improve perf of runtime gas calculation.

1 Like
5

Moreover, seems there can be lot of things to do if we have bytecode level tools, such as defining the low-gas opcodes that works on BSC specifically, to help reduce gas consumption. Or introducing more bytecode level optmizations such as “jump analysis and inlining”, “tail call” optimizations to help enhance performances.

Nonetheless, the benifit of bytecode level tools is that the smart contract developers don’t need to concern about the compatibility. The bytecode tools only works at deploying time, so generally all smart contract that works for standard EVM could enjoy the gain from BSC, with our bytecode tools being invoked silently.

1 Like
6

Yes, not only blockchain platform but all other platforms would have the intention to keep the projects & users. But developers still have the right to choose the desired platform, based on their own interest.
We can take a look at how traditional platforms do it:

a.Incompatible API
Just like Operation System(Windows, MacOS, Android…). But developer would try to develop different Apps on different platforms, they could also discard support on some unpopular platform(like WindowPhone). And later, some platform independent middleware would come out to make the work easy, such as WebApp, React, JVM…

b. barrier: technical & capital
Like the web browsers, Chrome, Safari, Firefox, Opera… they all share the standard Web APIs, but it is becoming more and more difficult to maintain a web engine. These platforms are not easy to build and needs lots of capital input to follow the standard and guarantee the user experience.

c.eco-system
It would be the big apps, like youtube, facebook, tiktok… These platform already got the leading resource, users will be reluctant to switch platform.

As for BNB Chain, specifically EVM, there could be many things to be improved. The goal should be: deliver better user experience, e.g. easy to use, better performance, economy efficient, new feature to meet user’s demand… while it is not to make it different.

1 Like
7

FWIW, blockchain (especially EVM based) eco-system is young and growing fastly, so compatibility is vital for a platform to live longer and embracing large quantity of apps. At meantime, unique capabilities is important to be attractive and win when new use-cases or scenarios becoming popular.

For BSC, IMHO currently derivative innovation is better as for developer it can easily to do migration, and it is also easy for BSC to adapt to the new scenario when it comes. Destructive innovation usually comes with high risk and incompatibility, which I think is not suitable if the whole eco-system is not that mature.

Take Java as example, the recent GraalVM is kinda like destructive innovation that can hugely improve application performance, but the problem is that it’s close-world restriction makes lots popular java framework incompatible to work with it, which actually makes hurdle for itself to become mainstream in the whole java eco-system. (My own understanding, may not be accurate now as time goes by.)

1 Like
8

How about native-VRF? oracle VRF is very expensive and making it native to BSC will surely provide a lot of value as well as reduce the costs for the projects.

9

native-VRF is good, but we also need to consider the way to implement it. If introducing new opcode, the front-end language (like solidity) may required to change. Or if use the bytecode transfer method, it may need to have the ability to “recognize” the bytecode pattern of random number generation, which is not easy.

An alternative way maybe that BSC has a smart contract deployed on-chain, which could provide the native-VRF functionality, and then other smart contract could call it at runtime. IMO It is ideal if BSC could incubate the native-VRF API standardization, which means that all smart-contract could use same API to generate random number regardless the different EVM it runs on, but they will benefit more when using BSC.

10

As a TWT Stake representative, I appreciate the insightful discussion on EVM-compatible blockchains and their challenges in retaining projects. You’ve highlighted several suggestions to make BSC more attractive, such as introducing new opcodes, native random generators, oracle pricing, infrastructure changes, and specific optimizations. Each idea has its own advantages and disadvantages that need to be carefully considered.

We believe that enhancing the unique features and capabilities of BSC could indeed attract more projects and make it a more appealing choice for developers. However, striking the right balance between innovation and compatibility is crucial. We are excited to see how the BSC ecosystem evolves and will continue to monitor and engage in discussions like this one to stay informed about the latest developments.

Thank you for sharing your thoughts on this important topic!