Source: diyhpluswiki/ transcripts/ scalingbitcoin/ stanford-2017/ using-the-chain-for-what-chains-are-good-for, Andrew Poelstra

General requirements of blockchain-based scripts⌗

  • Everyone downloads a copy of the blockchain

  • Everyone validates the blockchain

  • It’s not possible to compress the current state of the system due to its Kolmogorov complexity.

  • Script transactors must ensure their scripted transaction has sufficient confirmations to avoid becoming "un-confirmed"

    • This is a poisson process

    • You never have perfect finality

  • Contracts in scripts must adhere to rules that everyone needs to agree operations

    • Disagreement is a consensus failure and == to a chain split

    • Adding additional rules is slow and difficult for this reason

  • Details of the script must persist forever

    • Validators will need the data in the future to validate

    • This appears to mean that script data is inherently public (which might include sensitive data)

  • Miners that can see contract details become a target to government and external systems and they might not want that liability.

    • We don’t want them to be able to see that data, because it’s a censorship risk, and it’s a liability to the miners which they don’t want to have.

What’s the blockchain’s role in script execution?⌗

Essentially:

To get an immutable ordering of what order the transactions happen in.

All that they really care about is that the transaction is not reversed and not double spent. This is the core competency of bitcoin blockchain.

This means that all the data required to be (stored forever) on the blockchain does not actually include the script data. In the extreme it should just be inputs and outputs, plus a small amount of data that does not have to inlclude what the (script) commitments are.

Validation and Execution⌗

There’s a distinction between validation and execution. We see this in two places. In general in computer science, when you talk about turing machines in the context of Post’s Theorem, which shows that it’s strictly easier to validate the execution than it is to execute the script itself, because you can simply provide a witness which shows execution instead of executing the script.

In crypto we talk about validation vs execution. In computer science it’s about how much expressiveness is required. Verification of something can be done in zero knowledge where the helper data is not revealed to everyone, but through the magic of cryptography everyone can verify that the extra data existed and it was correct.

In addition to execution vs verifiability distinction, there’s verifiability vs public verifiability:

  • Blockchain verifiers must check that coins are only spend with correct authorisation, and only once.

  • They don’t ncecessarily need to know what "correct authorisation" means, they just need to agree on it.

  • Consider moving coins to a multisig output, where multiple distrusting signers check external conditions before signing to move them to their final destinations (Gibson 2017)

The blockchain verifiers care about the state of the system like where the coins are, how many coins there are, what they are assigned to and so on. When they see a transaction, they want to know that the transaction is authorized and that they agree. But they don’t care too much what it truly means. When you’re transacting, you care about faithful execution and the rules you want to enforce. But everybody else doesn’t care- only that the rules were followed and that whoever owned the money before was somehow okay with it moving. This is much more nebulous thing than what the transactor probably cares about.