Reject calls/transfers between FVM and AVM

[aionbot]

Issue created by yulongaion (on Tuesday Sep 04, 2018 at 20:16 GMT)

Idea 1: different block type for different VM transactions Idea 2: split the block into different sections.

At this stage, let's assume no cross-VM call is allowed, either value-transfer-only or a failure.

[aionbot]

Comment by jeff-aion (on Wednesday Sep 05, 2018 at 13:49 GMT)

Regarding why we currently want to assume no cross-VM call is supported: AVM and FVM depend on different components to handle transactional semantics (FVM depends on the DB, purely, while AVM does most of this in-memory, related to how it implements hot DApps).

This becomes increasingly complicated when re-entrant calls are made: how do we handle rollback/commit of specific transactions when A(AVM)->B(FVM)->A(AVM)?

[aionbot]

Comment by jeff-aion (on Wednesday Oct 24, 2018 at 14:29 GMT)

If possible, we probably want to detect and fail any cross-call attempts, instead of just making the balance transfer with no code execution (since many applications probably wouldn't be expecting something like that to happen).

If we do want to support cross-calls, in the future, or continue to support Solidity (or just EVM bytecode), I suspect that the real solution is to build an EVM runtime (including storage/hash emulation) and EVM->AVM deployment transformer (much like how AVM already uses a Java->AVM transformer). In such a world, cross-calls would be commuted into a question of how to adapt ABIs between the different environments as the more difficult problems, such as how to manage reentrant calls and transactional nesting would be implicitly solved.

This approach could also be extended to support a sort of eWASM->AVM transformation. It is worth noting that the reverse is not possible as the power of the underlying JVM is greater than eWASM (no support for portable floating point, automatic memory management, or type-safe on-heap data structures).

Precompiled contracts would need to be re-implemented to obey the underlying realities of the AVM storage model, etc. In AVM, we would ideally expose these as native API calls on the BlockchainRuntime but, on the EVM side, we would need to detect these special contract addresses within the runtime we would create for that environment.

It is also worth noting that creating such a translation/emulation environment would also enable parallel execution of EVM contracts, since now they would fit within the model of AVM.

[aionbot]

Comment by jeff-aion (on Wednesday Nov 14, 2018 at 16:41 GMT)

Note that, while it technically possible to support the cross-call transactional semantics (although incredibly complicated), a point of far more absolute contention is concurrency. FVM cannot run multiple contracts concurrently while the AVM defaults to assuming that it can.

Even if we exposed a call to FVM as an implicit data hazard, this would require that we add this "abort" mechanism to the FVM and/or stall for long periods of time until AVM can resume control.

Despite being a very complex change, touching many components, it might also produce the ability for someone to attack the system by exploiting these rough/slow paths.

By this point, it would probably take far less time, and be far more reliable, to just build the EVM->AVM transformer and emulate the EVM semantics, in entirety.

[jeff-aion]

While we will eventually need to build some kind of FVM-on-AVM story (either an interpreter or a cross-compiler on deployment), the scope and risk of that project are quite large. Therefore, our tactical solution to this problem will just be to reject any call or transfer attempts from one of these VMs to the other.

[aionick]

Note that I've also added a blurb about this in issue #336, where this is also being tracked. That issue just has a larger scope than this one.