Skip to content

Commit

Permalink
formatting
Browse files Browse the repository at this point in the history
  • Loading branch information
mj850 committed Apr 22, 2024
1 parent ddf86ce commit 764cbca
Show file tree
Hide file tree
Showing 3 changed files with 399 additions and 129 deletions.
27 changes: 18 additions & 9 deletions pages/differences-with-ethereum.mdx
Original file line number Diff line number Diff line change
@@ -1,41 +1,50 @@
# Differences with Ethereum

While Sei features full EVM compatibility, there are some differences between Sei's EVM and Ethereum itself.

## EVM Differences
Sei uses Shanghai version EVM, unless Ethereum mainnet which is on Cancun for its execution layer. What that means is that features like blob transactions are not supported on Sei.
Unlike Ethereum mainnet which is on Cancun for its execution layer, Sei uses the Shanghai version of EVM. This means that features like blob transactions are not supported on Sei.

## Opcode Differences

### PREVRANDAO

Since Sei doesn’t rely on the same pseudo-randomness way of determining the next validator like PoS Ethereum does, it doesn’t really have the `RANDOM` artifact that can be set as `PREVRANDO`'s return value. In Sei `PREVRANDAO` is set to return the hash of the current block time. For strong randomness guarantee needs in contracts logic, it’s advised to use external verifiable oracles (as is advised on Ethereum itself)
Since Sei doesn’t rely on the same pseudo-randomness way of determining the next validator like Proof of Stake (PoS) Ethereum does, it doesn’t really have the `RANDOM` artifact that can be set as `PREVRANDO`'s return value.
In Sei `PREVRANDAO` is set to return the hash of the current block time. For strong randomness guarantee needs in contracts logic, it’s advised to use external verifiable oracles (as is advised on Ethereum itself).

### COINBASE

Coinbase address on Sei is always sets to (the EVM address of) the global fee collector.
Coinbase address on Sei is always set to (the EVM address of) the global fee collector.

## State Root

Since Sei uses AVL-tree instead of MPT for data storage, Sei doesn’t have per-account state root. The global state root is the AVL-tree root which is also not equivalent to Ethereum’s overall state root (which is a MPT root)
Since Sei uses AVL-tree instead of Merkle Patricia Trie (MPT) for data storage, Sei doesn’t have per-account state root. The global state root is the AVL-tree root which is also not equivalent to Ethereum’s overall state root (which is a MPT root)

## Block Hash

Block hash on Sei is computed based on block header in Tendermint data format, and as a result is different than Ethereum’s block Hash
The block hash on Sei is computed based on the block header in Tendermint data format, and is different from Ethereum’s block Hash as a result.

## Base Fee & Tips

Sei supports all transaction types. However Sei does not fluctuate base fee based on block congestion. In fact base fee will always be 0 on Sei, meaning all fees will go to the validators (i.e. tips) and none will be burnt.
Sei supports all transaction types. However Sei's base fee does not fluctuate due to block congestion. Base fee will always be 0 on Sei - all fees will go to the validators (i.e. tips) and none will be burnt.

## Block Limit

Sei has a gas limit of 10M on pacific-1, compared to Ethereum’s 30M. In addition, Sei also has a byte size limit of 21MB, whereas Ethereum doesn’t have byte-denominated limits.
Sei has a gas limit of 10M on pacific-1, compared to Ethereum’s 30M.

In addition, Sei also has a byte size limit of 21MB, whereas Ethereum doesn’t have byte-denominated limits.

## Non-EVM Transactions

On Sei there exists non-EVM transactions which may update states accessible by EVM transactions. Simplest example would be bank balances, which may be updated by both native Cosmos bank send transactions and EVM send transactions. As a result, if certain offchain applications only parse EVM transactions, they may find certain state changes unattributable to any EVM transaction.
On Sei there exists non-EVM transactions which may update states accessible by EVM transactions. The simplest example would be bank balances, which may be updated by both native Cosmos bank send transactions and EVM send transactions.
As a result, if certain offchain applications only parse EVM transactions, they may find certain state changes unattributable to any EVM transaction.

## Finality

Sei has instant finality, meaning that commitment levels of “safe”, “latest”, “justified”, and “finalized” on Ethereum are all the same thing on Sei.

## Pending State

On Ethereum the block proposer would execute its proposed block first (and update its local state) before broadcasting the proposal to others (the updated state would be marked “pending” until the node is accepted by other nodes), whereas on Sei the block proposer would broadcast first and only execute the proposal if it’s accepted (i.e. every node would execute the block at roughly the same time), so Sei does not really have a window when “pending state” exists.
On Ethereum the block proposer would execute its proposed block first (and update its local state) before broadcasting the proposal to others (the updated state would be marked “pending” until the node is accepted by other nodes).

However, on Sei, the block proposer would broadcast first and only execute the proposal if it’s accepted (i.e. every node would execute the block at roughly the same time), so Sei does not really have a window when “pending state” exists.
Loading

0 comments on commit 764cbca

Please sign in to comment.