Difference between EVM Bytecode and Tezos Michelson

Question

Solidity compiles into Bytecode.

Smart Contract languages on Tezos compile into Michelson.

Ethereum uses EVM(Ethereum Virtual Machine) as the system, smart contract code written in high-level languages needs to be compiled into EVM bytecode and Contract ABI to be run. EMV Bytecode is an executable code on EVM and Contract ABI is an interface to interact with EVM bytecode. For example, if you want to call a function in a smart contract with your JavaScript code, ABI plays a role as an intermediary between your JavaScript code and EVM bytecode to interact with each other.

This diagram shows the architecture of Contract ABI, EVM bytecode and outside components(dApp and network). The left side is a process of compiling and the right side is interacting.

Source

But how exactly does this work in Tezos with Michelson? Michelson makes sure that everything is executed as it should before modifying the storage. Solidity will modify the storage. Is this the big advantage over Solidity and the Bytecode?

Answer 1

I'd say the left-hand side of your diagram would be as follows on Tezos:

For the right-hand side, one can retrieve contract's code or storage via RPCs or high levels libs&tools like Taquito, Tzfunc or Factori.

As for the interaction with the smart contract and the execution model:

• When a user emits a smart contract call on the chain, the contract's code is read, and the call's parameter is type-checked against it, before any effective execution.
• During the execution of a/the called entrypoint,
  • the modifications made on the storage are not directly persisted onchain
  • any internal transaction emitted is meant to be executed at the end of the current EP call (or at the end of internal calls which are themselves waiting to be evaluated)
• At the end of a/the entrypoint called, a list of operations alongside a new contract storage is returned, and
  • the new contract's storage is semi-persisted(*)
  • the emitted operations (if any) are executed in a DFS style.

By semi-persisted, I meant that the new version of the storage is available for subsequent calls if any (and persisted on disk in case of success), but everything is reverted in case of failure/error/exception. Note BTW that exceptions cannot be caught by the user in Michelson.

So, I'd say that these are the main features that make Michelson different from EVM, in addition to how contracts are compiled/stored:

• Static strong type-checking;
• Execution model (in particular for internal calls);
• Forbidding exceptions catching (for safety reasons).