Address no/low-cost attacks submitting transactions that pass to DA

[mzabaluev]

Discuss a solution for:

• AVM-1 No Gas Gharges for Failed Transactions #409
• PAR-1 DoS Vulnerability Due to Sequencer Not Checking for Sequence Number Too New During Block Packaging #412

Related issues

These may or may not be solved alongside.

• LIB1-1 Multithreading Issue Leads to Transaction Replay Vulnerability #416

Proposed solutions

movementlabsxyz/MIP#6

[l-monninger]

So, for #416, there are a couple of potentially safe quick fixes that are worth implementing.

1. Make the transactions field in our block struct a BTreeSet (again); I suspect I may have accidentally removed that when optimization bullets were flying. Either this or the a programmed sort has to be included for general fairness anyways.
2. Filter committed transactions from blocks before execution.

These are discussed in a little more detail in #416. We could then send these over to @poetyellow and see what he thinks.

To turn on #409, we have to have #416 fairly safe.

As mentioned in #416, there is still the issue of doing a fair amount of work per transaction to prevent these replay attacks thus lending to a DOS. This is where deeper conversations in movementlabsxyz/MIP#6 and movementlabsxyz/MIP#7 may come in.

Without introducing some partially synchronous mechanism for the mempool, you would always have an issue with there being a period where replay transactions are inflight before their validity is agreed upon. That is we need would need to place a BFT system in front of the DA. The question then becomes, can that be less costly to operate than the DA itself?

[l-monninger]

For the filter, I have not found anywhere that the BlockExecutor would actually be applying the same before a block is attempted to be run. So, I think this is valid:

DB-based validation after passing through the DA is safe w.r.t. this issue, but opens up more potential for DOS. We can get the transaction by hash from the AptosDB it will have been called here during execution if the transactions was previously included, we could filter these out of the blocks. I need to double-check if the VM is already doing this, if so, we can just use the BTreeSet to make sure it doesn't happen within a block. The problem is, however, that you're still doing a fair bit of work on every node for this transaction. Per my comment about CP earlier though, I don't think there's a good way around this. The best thing to do would probably be position the mempool for independent scaling. We are also fundamentally accepting a fair bit of DOS risk by using a permissionless, public DA in the first place. So, some tolerance for this risk is presumed.

[l-monninger]

This is from #416 by the way.

[l-monninger]

@mzabaluev

I'm not sure if that addresses the issues, or if our resistance to DoS is made weaker than that provided by Celestia.

So, this does in theory add more load to every node in the network, yes. But, it shouldn't be too terribly concerning. Each one of these filter operations should be equivalent to the load of someone querying chain state over the API without the HTTP connection overhead.

The main point of the filtering, however, is to address the replay vulnerability in #416 . This foremost a risk to accounts on the network as opposed to the a DoS of the network on the whole.

[mzabaluev]

Filed #526 to investigate the aptos-executor behavior.

[mzabaluev]

I'm educated on the way aptos-executor treats this. I favor a DB-based replay check.

[l-monninger]

Just commented on #412 . I think this can also be a quick fix, but we need more information.