Study Block-STM, FEVM internals and understand Yann’s code

[sergefdrv]

Notes about Block-STM:

• Block-STM may have to be enhanced to support nested transactions
  • Perhaps, we can tackle this by treating FVM's call manager, instead of individual invocation containers, as a single unit in Block-STM

[sergefdrv]

Notes about Block-STM implementation in Diem:

• Block-STM in Diem is old, limited, and not wired to the main code base, but it is simple and generic
  • Was implemented in Aug 2021
  • Has a decent modular Rust interface
• Parallel execution code is under language/diem-vm/parallel-executor
• Overestimated write set approximation is required for correctness; unexpected reads are fine.
  • See task::ReadWriteSetInferencer::infer_writes and errors::Error::UnestimatedWrite

[sergefdrv]

Notes about Block-STM implementation in Aptos:

• Parallel execution engine is located under aptos-move/block-executor.
• In general it looks well-designed, with nice interfaces.
• There are some parts specific to Aptos, e.g. task::Transaction defines the key type specific to Aptos notions of account address and access path; therefore, the implementation would need to be adjusted for FVM.
• Notable interfaces that need to be implemented:
  • task::Transaction - defines the Key and Value types,
  • task::TransactionOutput - execution result of a single transaction,
  • TStateView - read-only snapshot of the global state,
  • task::ExecutorTask - single-threaded transaction executor.

[sergefdrv]

Notes about FMV/FEVM:

• The EVM actor's state schema is like follows:

/// DAG-CBOR tuple-encoded.
pub struct State {
    /// The EVM contract bytecode
    pub bytecode: Cid,
    /// The EVM contract bytecode hash keccak256(bytecode)
    pub bytecode_hash: [u8; 20],
    /// The EVM contract state dictionary.
    pub contract_state: Cid,
    /// The EVM nonce used to track how many times CREATE or
    /// CREATE2 have been called.
    pub nonce: u64,
    /// Possibly a tombstone if this actor has been self-destructed.
    pub tombstone: Option<Tombstone>
}

EVM storage (state dictionary, u256 => u256 map) is backed by a Filecoin HAMT with special optimizations to be more mechanically sympathetic to EVM read and write patterns. SLOAD and SSTORE opcodes map to reads and writes, respectively, on this HAMT, and ultimately to ipld syscalls.

• IPLD syscalls are interesting: there is a notion of a “reachable set”