crypto-org-chain/ethermint

Cronos is the Crypto.org EVM Chain aims to massively scale the DeFi ecosystem. It is powered by Ethermint, a scalable and interoperable Ethereum, built on Proof-of-Stake with fast-finality using the Cosmos SDK.

ethermint's Issues

[EPIC] too many memory allocations in tx execution

Proposal: reduce memory allocations in tx execution

Current behavior:

When benchmark parallel EVM execution, memory allocation, and GC seem becoming a bottleneck.

And there are indeed many unnecessary allocations in both SDK and ethermint

Desired behavior:

Pick some low hanging fruits first:

• big int and legacy decimals
• unnecessary conversions between different representations (protobuf <-> go-ethereum).

Use case: [Why is this important (helps with prioritizing requests)]

Requests may be closed if we're not actively planning to work on them.

Tracking

• #454
• #471
• avoid gas kv construction, we don't need gaskv in eth tx execution
• #469
• reduce duplicated GetAccount calls
• reduce big.Int copy during bank operations

Problem: state overrides are not supported

Proposal: support state overrides in multiple json-rpc calls

Current behavior: [What currently happens]

Desired behavior: [What you would like to happen]

Use case: [Why is this important (helps with prioritizing requests)]

Requests may be closed if we're not actively planning to work on them.

[EPIC] block-stm integration

• crypto-org-chain/cosmos-sdk#206
• #447
• #448
• crypto-org-chain/go-block-stm#5
• Optimize Has operation in go-block-stm
• #456
• #450

Problem: inefficient transaction format

the MsgEthereumTx protobuf message is quite inefficient because we do lots of conventions with the go-ethereum types to reuse the code there. Since ethereum tx already has a solid binary format, with the custom type feature in gogoproto, we can embed the ethereum binary format within the protobuf message.

Update to geth 1.13

Proposal: Update to geth 1.13

Current behavior: geth 1.11

Desired behavior: geth 1.13

Use case:

• Users can deploy contracts using the latest Solidity compiler. One example is the MCOPY opcode, which is available starting from Cancun.
• Inco Network uses https://github.com/zama-ai/fhevm-go, which uses geth 1.13.5's Golang API.

For our (Inco Network) use cases, our testnet already uses geth 1.13 but on SDK 0.46. I just created a PR to update to geth 1.13.5 with on top of your 0.50 code: Inco-fhevm#1. If it's useful for you, I can create a PR on this repository too.

If this is not on your roadmap, we can also close this issue for now.

Problems

It seems like you're using your own fork of go-ethereum, and added some custom APIs like DefaultActivePrecompiles. My PR removes usage of those custom APIs, and is built on top of unmodified geth 1.13.5.

Happy to collaborate on this!

Bug: `etherminttypes.NewTx` detect wrong type of ETH tx

Current behavior: Transactions without AccessList are treated as Legacy Tx with highest priority
Correct behavior: Transactions with tx.GasTipCap != nil && tx.GasFeeCap != nil is Dynamic Tx, that needed to priority

ethermint/x/evm/types/msg.go

Lines 108 to 145 in 2c2d539

	switch {
	case accesses == nil:
	txData = &LegacyTx{
	Nonce: nonce,
	To: toAddr,
	Amount: amt,
	GasLimit: gasLimit,
	GasPrice: gp,
	Data: input,
	}
	case accesses != nil && gasFeeCap != nil && gasTipCap != nil:
	gtc := sdkmath.NewIntFromBigInt(gasTipCap)
	gfc := sdkmath.NewIntFromBigInt(gasFeeCap)
	txData = &DynamicFeeTx{
	ChainID: cid,
	Nonce: nonce,
	To: toAddr,
	Amount: amt,
	GasLimit: gasLimit,
	GasTipCap: &gtc,
	GasFeeCap: &gfc,
	Data: input,
	Accesses: NewAccessList(accesses),
	}
	case accesses != nil:
	txData = &AccessListTx{
	ChainID: cid,
	Nonce: nonce,
	To: toAddr,
	Amount: amt,
	GasLimit: gasLimit,
	GasPrice: gp,
	Data: input,
	Accesses: NewAccessList(accesses),
	}
	default:
	}

Problem: edge case of indexer causes it won't work

Currently, indexer if not able to fetch a block result, it will retry infinity so on a prune-node, there is an edge case that indexer is turned-off at the past, the data on db is exists, LastIndexedBlock returns positive number but that block is already pruned and the indexer can not back to work.

@yihuang can you confirm?

If that is correct, shall we force the lastBlock variable to node's earliest/latest height?
The missing gap is not important because the indexer in any node prune will be missing txs the same as it is.

if lastBlock == -1 {
	lastBlock = latestBlock
} else if lastBlock < status.SyncInfo.EarliestBlockHeight {
	lastBlock = status.SyncInfo.EarliestBlockHeight // or latestBlock
	// kinda unsafe, but we don't have a better way to do this
}

Problem: sender address recovery is heavy

• Require the client set the From field in MsgEthereumTx when sending the transaction
  • so we can decouple the sender address validation from the tx execution which use the From field directly.
• Validate the From field against the signature somewhere
  • the transactions can be validated in parallel, because the logic is stateless.
  • it could be done in FinalizeBlock or in ProcessProposal.

Problem: roadblocks for parallel transaction execution

Proposal: Clear the roadblocks for parallel transaction execution

Current behavior:

We are trying block-stm parallel transaction execution and have identified a few roadblocks.

The main thing would be the three accumulating states in the transient stores: tx index, log size, block bloom, total gas used.

Desired behavior:

Each transaction should not unnecessarily share states, we can't control what account and contract state the transaction want to access, but other than that, we should have zero shared states.

Use case:

To have better performance in block-stm parallel execution.

Design

• total gas used is easy to change, we only want to accumulate the gas used within the current tx in the first place, so we'll simply append the tx index to the key, and we can even remote the ResetTransientGasUsed, cleaner than before.
• block bloom is also fine, we append the txindex/msgindex to the key, then iterate and combine them in end-blocker.
• log size, iterate the tx results after all executed, re-assign the log index in the rsp.Logs
• tx index, iterate the tx results after all executed, insert the tx index event