why blocks could contain failed transaction

Question

After building and running substrate-node-template i started the local node with --dev flag :

./target/release/node-template --dev

i opened https://polkadot.js.org/apps/#/extrinsics and selected the sudo pallet with bob account and sent the setKey extrinsic and it it throws an error(because only alice could do such action) like this:

however if i go to the explorer and select the most recent block after the transaction failed its still included and the block is imported with a failed transaction:

1. why the extrinsic passed the validation pipeline and was included in the transaction pool if its not valid?
2. isn't the default behavior to reject the block because it contains faulty transactions? and a malicious proposer could bloat the chain with invalid transactions that take space for no reason?

Answer 1

1. why the extrinsic passed the validation pipeline and was included in the transaction pool if its not valid?

See the code of the function set_key, inside the function it has some checks like the one is failing:

ensure!(Self::key().map_or(false, |k| sender == k), Error::<T>::RequireSudo);

To throw this error RequireSudo, the extrinsic set_key has to be executed, therefore included in the Block, even if the output is an Error.

2.Isn't the default behavior to reject the block because it contains faulty transactions? and a malicious proposer could bloat the chain with invalid transactions that take space for no reason?

To fix this Polkadot (And most of Blockchains) uses Transaction Fees.

Transaction fees prevent individual users from consuming too many resources. Polkadot uses a weight-based fee model as opposed to a gas-metering model. As such, fees are charged prior to transaction execution; once the fee is paid, nodes will execute the transaction.

Answer 2

Why not?

If you really want to reject a transaction, you can use SignExtension to reject it in the transaction pool or let this call panic (be careful with this).

To my understanding:

• an error could help users/developers to debug/figure out what happened

• although this part failed, other parts might still work

  e.g. receiving the transaction fee to maintain the network

If you fail locally, some infrastructure won't work anymore, and they might be hard to design. I think this might make things complicated.

Answer 3

Adding on to the answers given to your first question, because TMO it is a very good one. The checks that are done before entering the tx pool are defined in the SignedExtension, in the substrate-node-template to be found here.

The logic of most the SignedExtensions can be found here. The only one that is missing is the pallet_transaction_payment::ChargeTransactionPayment<Runtime> that can be found in the pallet-transaction-payment. Look for the SignedExtension implementation and the fn validate function.

If you go through all of them you will notice that the extrinsic's logic is not executed and therefore the sudo check will only be noticed after it is added to a block.

This can be modified by adding a new SignedExtension.

The lifecycle of an extrinsic validation is given here.