0
I want to know whether or not bitcoin checks for the existence of transactions in the mempool as one of the many validation rules it performs for new blocks.
If a transaction most exist in the mempool when a new block is received, how is this rule applied for blocks received during block synchronisation with peers, considering transactions in older blocks will not exist in the mempool?
5
A transaction that has been included in a block does not need to be in a node's mempool in order for that node to validate the block. Each block contains the transactions, so by downloading and validating a block, the node will have received a copy of all transactions in it (so that it can validate the transactions, as part of validating the block).
As you mentioned, there would otherwise be problems syncing old blocks, because the transactions in those blocks would be invalid if you tried to add them to the mempool today (because their inputs have already been spent!).
Further, a miner can include a transaction in a block, without having ever broadcast that transaction to the network otherwise. So in that case, no other node would ever have included the miner's transaction in their mempool!
Note that compact blocks (BIP 152) is an improvement to the block-relaying process, that allows nodes to compare a new block's transactions to their local mempool, and thus avoid having to re-download transactions they already know about.
A rule that a transaction must exist in the mempool for a block to be considered valid would be a disaster. That would mean there would be no way to guarantee that honest nodes ever agree on which chain is the longest, valid chain because there is no mechanism to make nodes agree on which transactions go in the mempool. Malicious users could trivially cause chain splits just by sending conflicting transaction to opposite sides of the network causing mempools to disagree and thus honest nodes to disagree on which blocks are valid. Disaster! – David Schwartz – 2018-12-23T06:24:08.587