Risks of executing messages in BeginBlock

The PEP module executes arbitrary user-controlled messages, including CosmWasm contract execution, in BeginBlock, which is non-standard. Since the usual Cosmos SDK transaction execution mechanism, runTx, is not used, the BeginBlock handler is responsible for limiting gas, handling panics and errors within individual transactions, and replicating the effects of what would normally be handled by AnteHandlers and PostHandlers, including checking that transactions are signed, deducting fees (or refunding fees, due to prepayment), and checking that transaction nonces are used in the expected order (which is the reason that runTx cannot be used in BeginBlock with the same AnteHandler stack as the rest of the application as encrypted transactions use an independent stream of nonces from regular transactions). This incurs maintenance overhead, as if additional AnteHandlers or PostHandlers are added, or if new mechanisms are added to runTx by upstream Cosmos SDK, the BeginBlock handler must be manually kept synchronized with these changes.

Additionally, CosmWasm contracts can execute submessages, which allows users to execute multiple messages atomically and respond to failure of a subset of them, so long as the total gas costs of executing submessages are within the prepaid limits. While this should be fine, since normal transactions allow the atomic execution of multiple messages, and thus message handlers are expected to handle this properly, this may be contrary to expectations for encrypted transactions, as decryptAndExecuteTx limits the top-level encrypted transaction to one message.