Check transactions TZIP

TZIP
1

Request for Comments for the A New Check Transactions Opcode TZIP.

2

The Michelson details in the TZIP seem to be incorrect.

IS_TX_INCLUDED :: key : nat : 'S -> bool : 'S

and

IS_TX_INCLUDED int 5;

should read:

IS_TX_INCLUDED :: operation_hash : 'S -> bool : 'S

and

IS_TX_INCLUDED;

based on the draft MR?

An interesting side effect of this, I think, is that it will enable smart contracts to verify a “proof” of the block hash which is the branch of the operation, providing a workaround for the absence of BLOCK_HASH. This in turn enables proofs of the context hash, and so also any data in the context.

3

Thank you @tom for the feedback.

Indeed, the TZIP needed the update as per the implementation. Just made the changes.

4

This instruction would be really useful for Flashbake.

Flashbake currently registers bakers on chain, and users trust that bakers are honest. If we had a way to prove a transaction was (or wasn’t included) then:

  • Flashbake could require bakers to lock a security deposit when registering in the registry smart contract
  • Flashbake could be modified to have bakers provide proof of receipt of transaction hash when a tx is submitted to them
  • A new entrypoint on the registry could be implemented: slash(operationHash, proofOfReceipt). It would penalize a baker for providing a proof of receipt but not including the transaction.

There are probably some edge cases to think about around this system (particularly, network latency or uncle blocks) but having this instruction would enable us to make flashbake a lot more trustless.