[Sequencer] - fake receipt for OOC transaction

0xPolygonHermez / cdk-erigon

Ethereum implementation on the efficiency frontier

GNU Lesser General Public License v3.0

35 stars 39 forks source link

[Sequencer] - fake receipt for OOC transaction #776

Open hexoscott opened 4 months ago

hexoscott commented 4 months ago

If you send a transaction that causes an OOC you are never able to get a receipt for this. We need a mechanism to produce a fake receipt and share it with RPC nodes (or at lease the one that made the initial request), or alternatively check on the eth_sendRawTransaction call for an OOC by executing the transaction based on current state in the RPC before passing it to the sequencer for processing.

Sharonbc01 commented 2 months ago

Hi @hexoscott can you check if this issue still needs to be resolved or if it can be closed now. Thanks

hexoscott commented 2 months ago

Afaik we still need this, or something like this

Sharonbc01 commented 2 months ago

Okay thanks @hexoscott , can you please review with @mandrigin and action. Keen to get any required last features in asap so we can thoroughly test with time on cardona assuming upgrade goes well tomorrow.

I like the approach to check for an OOG scenario earlier—during the eth_sendRawTransaction call itself but of course you guys know best!

kstoykov commented 2 months ago

There is work in progress regarding this one: https://github.com/0xPolygonHermez/cdk-erigon/pull/1016

Sharonbc01 commented 2 months ago

Hi @kstoykov can you provide an ETA on this please?

kstoykov commented 2 months ago

Hi @kstoykov can you provide an ETA on this please?

I'm waiting for more information as mentioned in the PR 1016.

hexoscott commented 2 months ago

Just checking back in on this one @kstoykov @mandrigin. We recently made a change to ensure that an OOC transaction doesn't get automatically rejected the 2nd time it is submitted. With that in mind do we want fake receipts or not? The 2nd submission might not OOC because the world state has changed since the last submission and the TX will have the same hash.

I'm thinking we either don't want fake receipts or we need to make the transaction handling process a little more complex and check for these fake receipts and delete them every time a transaction is submitted if a fake receipt already exists for it.

Sharonbc01 commented 2 months ago

@mandrigin Agreed to removed for mainnet milestone

Sharonbc01 commented 1 month ago

@mandrigin do we require this for RC1?

hexoscott commented 1 month ago

Thoughts on this one:

we don't want to persist these receipts, they are an exceptional case where a single TX can't fit into a batch. Instead we should hold something in memory only and it will be cleared on node restart.
when we manually remove a TX because of this OOC we can mark the TX hash in a map in the pool
when reading a receipt we can check this map to see if it is a problem TX and return an error about counters overflowing instead of the receipt
if a TX is submitted with the same hash as one in the map we immediately remove it from the map. The transaction could be valid on a second run so we always want to clear this map down on re-submission

hexoscott commented 1 month ago

@mandrigin wdyt to the above, smaller implementation and at least gives the end use some kind of feedback to action on. It won't mess with receipts either or give any indication that the TX was handled, just an error with something meaningful.

mandrigin commented 1 month ago

I am descoping this one for now, let's keep the task around but I will remove the milestones