Two transaction models dominate the blockchain world today - Account-based model where transactions are modeled as transfers happening from or to per-user accounts, and “unspent transaction output” or UTXO-based transactions. This post dives into the UTXO model, its design, execution and properties.
I’ve been thinking about a few aspects of smart contracts and blockchain tech - especially public blockchain tech - and I have some lingering doubts that I’d like to capture here for any of you to attack.
(With contributions from Sita Krishnakumar, Vishwas Bhushan and Manoj Kumar)
I am going to write this topic in couple of blogs. So that reader will get complete exposure of oracle services providers, like Oraclize in particular. In my first blog post I will try to give a brief overview of Oracle services. Basically dealing with questions like, What are Oracles? What is Oraclize? What is the use of such services? Etc. In the subsequent blog, we will try to use the Oraclize service with our smart contract and further we will take a deeper look into, how it works under the hood?
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.
Blockchain tech, especially smart contracts, are the hot new “internet”. Post the creation of Bitcoin, we’ve seen the rise of the public smart contract system Ethereum and several “private” systems like The Linux Foundation’s Hyperledger. These distributed ledgers have become the hot new foundation to build apps on top of, leveraging the additional trust that they are supposed to provide by virtue of their distributed nature.