Ethereum Protocol Fellowship 3rd week update

Self Introduction

I’m a PhD student in Syracuse University in Blockchain security area, and now working on the Ethereum Mempool Attack Detection&Defence. Very excited joining in the fellowship and make some contribution to the Ethereum Portocol.

Process

Mempool reconstruction

After analyzing the code from go-ethereum, we add two instructions in the txpool part which let us log the transactions when they just arrived in the mempool and when they are admitted by the pending pool/queued pool.

For the mempool, when adding transactions who just arrived in the mempool, the func (pool *TxPool) add(tx *types.Transaction, local bool) will be called. This func add validates a transaction and inserts it into the non-executable queue for later pending promotion and execution. If the transaction is a replacement for an already pending or queued one, it overwrites the previous transaction if its price is higher.

when the transactions are admitted by the pending pool, the func (pool *TxPool) promoteTx(addr common.Address, hash common.Hash, tx *types.Transaction) will be called. This func promoteTx adds a transaction to the pending (processable) list of transactions and returns whether it was inserted or an older was better.
Note, this method assumes the pool lock is held!

Evaluation

To test whether or not those instructions work well, we run the make geth and run it on the mainnet and testnet goerli.
We successfully catch the transactions when we send some valid transactions to the mempool after using the modifying go-ethereum code.

Result

As for now, the part of the detection is complete, we will refine the code a little bit. We reconstructed a close to complete mempool before the transactions are mined to the chain.
After a while, we will ask the Geth team regarding the mempool tx handling for advice if it is an production code and try to push it on to real world mainnet.

Next step

After discussing with my labmates, we want to make some defense on the DETER Attack which we discovered before happening in the mempool transaction admission rules.
There are four situations here that resulted from the bad transaction adding in or replacement:

Simple Explanation>>

• First, there are some valid txs already in the mempool, then some latent overdraft tx(s) replace some of the valid tx(s).
• Second, there are full of valid txs in the mempool, the coming tx(s) make some valid tx(s) turning into future tx(s).
• Third, there are full of valid txs in the mempool, then after some future tx(s) which is tx(s) in the queue pool replace the valid tx(s) before.
• Forth, similar to the second situation, but it is latent overdraft tx(s) instead of the future tx(s).

By making the rules more strict(Add-on defense), we want to build a better geth environment that can avoid these situations.