aakoshh
commented
1 year ago Apparently the reason this isn't an immediately looming problem on the mainnet is that currently users can only use the FEVM and the FEVM does not expose IPLD as part of the syscalls, so Ethereum smart contracts are fine.
There needs to be separate instances so the IPLD blockstore that gets bytes written to it for reasons other than transaction execution are not visible to the FVM actors.
In the FVM SDK we can open an IPLD block by CID and it looks it up in the blockstore. I note that there's a TODO about reachability there.
In Forest, when we create a new VM we pass it the blockstore of the StateManager which it shares with the ChainStore. This has the same DB as everything else, and is shared with the Libp2pService, where it's given for example to the Bitswap manager as well.
Fendermint also uses the same DB, although at the moment nothing other than block execution affects it, because the chain state is in Tendermint. But when we add the IPLD resolver this will change.
What happens if an actor is asking for a CID to be looked up, a CID it received from the outside world and didn't put into the store itself, and some nodes have it (courtesy of Bitswap), while others do not. They would have a different view of the world and calculate a different result from the same parent blocks.
In a BFT consensus like Tendermint, it would be a consensus failure that validators cannot back out of, it would split the chain.
We should use a semi-transparent block store here: the IPLD resolver should see state that the actors have written, but the actors should not see state only written by the IPLD resolver. It can be the same RocksDB but using different namespaces, and an abstraction over them. (Forest doesn't use namespaces but Fendermint does).
Luckily because Tendermint is forward only, at least we don't have to worry about cleaning up after orphaned blocks.