Differences between Kakarot and Ethereum

Although Kakarot is Ethereum-compatible and aims to support the latest features of Ethereum (e.g. Cancun new opcodes), it still has some edge case behaviors.

EVM opcodes

The below opcodes differ in behavior between Ethereum and Kakarot:

Item	Ethereum	Kakarot
BLOCKHASH	Get the hash of one of the 256 most recent complete blocks	The last 10 blocks are not available, and 0 is returned instead
BLOBBASEFEE	Get the current data-blob base-fee	Return 0 as there are no blobs on Kakarot
BLOBHASH	Get blob versioned hashes at index	Return 0 as there are no blobs on Kakarot

EVM precompiles

The below precompiles differ in behavior between Ethereum and Kakarot:

Item	Ethereum	Kakarot
ecAdd	Point addition (ADD) on the elliptic curve alt_bn128	Not supported
ecMul	Scalar multiplication (MUL) on the elliptic curve alt_bn128	Not supported
ecPairing	Bilinear function on groups on the elliptic curve alt_bn128	Not supported
Point evaluation	Verify p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. Also verify that the provided commitment matches the provided versioned_hash.	Not supported

EVM State computation

The below state computation differs in behavior between Ethereum and Kakarot:

Item	Ethereum	Kakarot
Block hash computation	keccak256(RLP.encode(Block Header))	pedersen(Starknet Block Header)
State root computation	Root of state keccak-MPT	poseidon(root of contract pedersen-MPT, root of contract class pedersen-MPT)
Transaction receipt	Transaction receipt is available once a transaction is mined	Transaction receipt is available once a transaction is processed and guaranteed to be mined. This means that blockhash field of the receipt is optional and will be non-null only once the transaction is mined.

Transaction reversion

In Ethereum, a transaction can be reverted if validation parameters are incorrect, if it runs out of gas or if it fails on the contract level. Since Kakarot is a layer 2 solution, additional revert reasons can occur during the transaction. We have currently identified the below issues which can cause some problems with the traditional EVM tooling:

• Cairo VM out of steps: in Kakarot, we execute the EVM as a Cairo program, which can run out of execution steps. This causes the Cairo program itself (and not the EVM) to run out of "gas", causing a reversion of the transaction. This is a discrepancy with Ethereum's behavior, causing tooling such as cast run TRANSACTION_HASH to give a different result than the outcome on Kakarot.