Add activity idea to 4.3 Censor transactions

[JoshOrndorff]

The idea behind this activity is to show that the transaction pool operates off chain and there is no consensus over it. That means that an individual node can run alternate code in the transaction pool while still producing valid blocks and verifying others' blocks correctly.

As a bonus, the code that needs to be changed is in the runtime (block builder api) which foreshadows the runtime apis discussed in section 4.4.

cc @shawntabrizi because I see you are the instructor for this unit.

[JoshOrndorff]

I made a rough sketch of something like this in moonbeam-foundation/moonbeam#261

[sacha-l]

Cool! I think it's a solid activity to understand where this is happening and pretty straight forward to do. I think it would be nice to extend your proposed activity here and break it up into two parts: (1) censor a tx by upgrading the actual runtime (like in your proposed example) and (2) censor a tx by modifying the node (client side). This way we can also build on the Substrate architecture lecture (lecture 1 of module 4), where a lot of the learning is about how Substrate is split between client and runtime. If you like this (cc @shawntabrizi), I'll follow-up with a more fleshed out activity write-up and solution.

[JoshOrndorff]

@sacha-l Glad you like the activity :)

My proposal is not to upgrade the runtime on chain like your # 1. Doing that would mean the chain's governance agreed that all nodes should censor such transactions. Although, perhaps that is instructive too. If you think so I'm fine adding that.

My proposal is more like your # 2 where individual nodes do the censoring. But client-side code is not actually the thing you want to hack to make just your node censor transactions. The client-side transaction pool doesn't know anything about the transactions it is getting. They are just opaque Vec<u8>s. Instead the pool calls into the runtime to ask it to validate and prioritize the transactions. That is why this hack has to happen in the runtime. The attacker can then perform this attack by executing their node with the --wasm-runtime-overrides flag to use this attack runtime.

I had the same conversation with Alex Popiak on my original moonbeam PR moonbeam-foundation/moonbeam#261 (comment). I think this subtlety is evidence that this is a good exercise that does "build on the Substrate architecture lecture" as you said.

[sacha-l]

I probably am missing some practical knowledge here so please bear with me! So IIUC the only way to "censor" a transaction would be by modifying the TaggedTransactionQueue runtime API ? In practice would I really be able to run a malicious runtime with this modified runtime API implementation though?

I guess what I was assuming was that there is a way to have a node detect a specific transaction and reject it from entering the pool, without calling into the runtime using something from the sc_transaction_pool module, for example submit_and_watch. But I may be of by a long shot!

[shawntabrizi]

@JoshOrndorff sure, this exercise seems fine.

Although I feel you are getting pretty deep pretty quickly with such an exercise. I am not sure how comfortable people will be to program and modify the runtime at this stage.

Also, it would be good to have really clear take aways from such an exercise, since we really are not trying to encourage people to do this kind of thing on their networks.

But yeah, seems interesting.

[JoshOrndorff]

not sure how comfortable people will be to program and modify the runtime at this stage

Yeah, good point.

[shawntabrizi]

I think if you can make it really dead simple, like copy and paste blocks, it should work out.

Especially if the takeaway is more conceptual than procedural.

[kianenigma]

Looks very interesting ✅

Will we prepare the answer to this exercise ourselves as well? would love to help review that too if it exists.

[JoshOrndorff]

@kianenigma I sketched a solution here moonbeam-foundation/moonbeam#261 It is quite minimal, but I believe it works.

We would need to port it to a node template or some better starting point.

[kianenigma]

The only problem with this is that it requires a bit of FRAME knowledge, aka knowing what Call is.

Perhaps we can move it to #154.

[kianenigma]

I will directly add this to the lecture.