Not only do we get ordering based on block height, but also inner-block indexing of transactions! This tape is all we need to build fully Turing Complete Applications on top of Bitcoin.
Planaria Security Model
1. Consistency/Availability: All servers running the application code can die for an arbitrary period of time and still recover later on by scraping from the last seen block. This means application providers can gracefully fall off and come back online with no risk to consistency. Availability is dependent on the economic incentive of serving the application to users.
2. Validation: Anyone can boot up an application server and validate the current state. A validator starts by fetching the application code, and scraping from the first block the app was seen until the current block height. This is a linear time validation scheme equivalent to mining nodes on the core network, but with only a single application subset of the blockchain state.
3. Law: If API providers are spoofing with false contract state, it becomes trivial to catch them, and provide evidence in court if necessary. Since everything derives from the on-chain tape, there is no way to “cook the books” and get away with it.
Current Planaria based apps such as twetch and bicomedia are essentially hard drive extensions to Bitcoin. Such apps are able to scrape and serve static content on a DB or filesystem from op_return events.
The goal of GearSV is to allow for an unbounded amount of CPU and Memory to also be added to Bitcoin. What if you could do complex validation and arbitrary manipulation of the data with the same properties as the storage apps? Let’s go Turing complete!
Virtual Machines abstract over the underlying hardware allowing computation to run uniformly over a variety of CPU architectures. This is really useful for smart contracts that need to run for a long periods of time on many different machines. You never know, ARM servers may be the norm in 5 years!
You can write stateful class based programs much like the Solidity contract counterparts. Here is the header file for an ERC20ish port:
- Compile contract to generate Bytecode and ABI.
2. Deploy contract byte code in an on chain op_return.
Similar to other smart contract platforms, we then “deploy” the contract by storing the Bytecode on chain in an op_return output. The contract identifier is determined by transaction hash using the
All writes are on chain transactions using higher level semantics specifying the contract, method, and input parameters in an op_return. Planaria nodes scrape the event log and simply run the method calls in order as they appear on-chain.
Developers can easily use commodity hardware or virtual CPUs available on cloud platforms to get going.
With a purely WASM based contract, the constraining factor is memory. For a token contract using a c++
std::map with a 20 byte address to 32 byte unsigned int, we can around 200 million balances on a 16 GB machine. To get around the memory limit, we can mount the Web Assembly MemFS to the underlying OS, and start utilizing hard drives!
Unlike platforms such as Ethereum, where all contracts are run by a single VM, Bitcoin smart contracts are already completely sharded 1 VM per contract. In fact, you can run an unlimited number of VM’s per contract continuing to increase the availability to end users as desired.
Not only can you write smart contracts for Bitcoin, but it is far more scalable and simple to do so.
The number one proven use case for contracting is tokens. Strict op_return frameworks like Tokenized seem too rigid to fit the wide variety of use cases tokens offer. With full programmatic flexibility, you can specify vesting schedules, dutch auctions, check approvals and much more.
Much of the inspiration for my new project was from watching this presentation by Clemens Ley.