You follow a link to a website on an influencer’s social media channel. The site promises to airdrop some tokens if you own a certain NFT. You pair your wallet with the dapp, sign a transaction to claim your airdrop and … all the assets in your wallet are gone. The influencer’s social media account was hacked, the link sent you to a malicious website and you signed away your assets when doing the transaction.
What can be done? In theory, you could inspect the contract’s code before interacting with it, but who can reliably do that on any reasonable time frame? It’s also easy to obfuscate malicious behavior.
You could rely on trusted lists of safe websites and safe contracts, and those lists could be known to wallets, but this create enormous pressure on the list maintainers to verify and approve contracts.
You could try and simulate what the transaction will do, but a sophisticated attacker will create a contract with a switch to trigger the malicious behavior, and inject a transaction that turns on the switch right before your transaction. The simulation will make the contract appear innocuous, but it will still behave maliciously when the transaction is included in the block.
One solution to this conundrum is to enable postconditions on transactions. Interacting with a smart contract can trigger all sorts of side effects, but attackers primarily care about one: take your assets.
Every transaction in Tezos produces a receipt, which describes the changes to the ledger caused by the transaction. A post-condition would be a bit of Michelson code that is triggered after the transaction as completed and takes the receipt as input. The postcondition can then either succeed or fail. If it fails, the entire transaction is rolled back.
A typical postcondition would be to verify that none of the effects involve an allowance for an asset changing, or an asset changing hands. A dapp that does require an asset to change hand would propose to the wallets a postcondition that relaxes those conditions. The wallet would then be able to warn the user that the dapp has asked to authorize moving up to quantity qa and qb of assets A and B.
This can only be done with a protocol change, it’s not something you can build with just smart-contracts.
I think it would be a nice feature as people would be able to interact with smart-contracts without needing to trust their behavior as much.
This isn’t a silver bullet, there are state changes user care about that might not be caught in the “default” post-conditions. For example, if you have an NFT for sale in a marketplace, a malicious website could trick you into lowering the asking price a lot, and that wouldn’t look like an asset changing hands. It’s also something that would require a fair bit of standardization across wallets to be helpful.
Nonethless, it’s a unique feature that’s not available on any blockchain and that seems to solve a real pain point users are experiencing today.