Do only the necessary validation prior to including transaction into a chunk about neps HOT 7 OPEN

I don't understand why this is needed. Which part of the validation is unnecessary today?

from neps.

The reason for the validation before including into the chunk is to only include the valid transactions in the chunk. It decreases the size of the chunk by putting extra effort on the chunk producer, but decreases the load from everybody else who's validating this chunk.

from neps.

It decreases the size of the chunk by putting extra effort on the chunk producer, but decreases the load from everybody else who's validating this chunk.

Size of the chunk can be measured by its size in bytes and CPU time to execute on signer. The idea is to split it and make sure that sender paid at least for transmission. During transaction application, we charge account incrementally action-by-action (like we do it when we create Promises).

In general idea is to make user input opaque to the chain layer and deserialize actions only on a chunk application. So, in a trust-less setting it makes sense to execute user input in accountable environment.

from neps.

The reason for the validation before including into the chunk is to only include the valid transactions in the chunk.

It fact, the proposal simply changes the definition of a "valid transaction", making it more general.

from neps.

@fckt the transaction itself is usually quite cheap. This will allow people to spam with invalid transactions at a relatively low cost.

from neps.

@bowenwang1996
The problem is that right now people can spam block producer with invalid transactions even for free, since this operation (even if we suppose that it's a cheap operation, but still O(2* n) - deserialization + validation) is not accounted.

The idea is to allow (potentially invalid from a state transition function stand point) transactions to join chunk, since account is guaranteed to be charged at least by amount of config.receipt_cost_per_byte * receipt.len() - this means chunk producer guarantees that account will (at least) compensate transaction validation process and will not allow to spam itself with invalid input at all. Since the cost of input deserializing and interpretation is guarantied to be covered, we can allow runtime (state transition function) to interpret user input in a way it want to (as long as interpretation has a linear asymptotic complexity against input).

from neps.

But you still need to pull account and access_key, verify signature and make sure there is enough cost. Then you'll need to pre-charge the account/access key for TX costs first before you start validate transactions.
It doesn't address the DDOS issue at least if the receipt is part of the transaction, because you still need to receive a large transaction, hash it and verify account/access key. The rest of validation right now if fairly cheap. Probably O(n)

from neps.