The distributed ledger protocol used by blockchains has resulted in systems where we do not have to place trust in particular parties involved in maintaining these ledgers. Moreover the ledgers are programmable with “smart contracts” - transactors whose state changes are recorded and validated on the blockchain. A collection of smart contracts describes a system that is expected to ensure certain invariants relevant to the domain are upheld. For example, an election system is expected to maintain voter confidentiality. While the code that describes these “smart contracts” is open for anyone to read, those who’re participating in the systems run by these smart contracts are not in general competent to evaluate them, with the OSS community being the sole eyes on the contracts being deployed. In this post, I examine how these smart contracts can provide “warranties” that are easier to ratify and describe clear and automatic consequences of violating the warranted properties.
In an earlier post, I’d written that blockchain apps must be closed systems. Since the specific sense in which I’d used the words “closed” and “system” didn’t quite manage to get through to readers, I’d like to explain them a bit in this post.