IOV Weave is a framework for quickly building your custom ABCI application to power a blockchain based on the best-of-class BFT Proof-of-stake Tendermint consensus engine. It provides much commonly used functionality that can quickly be imported in your custom chain, as well as a simple framework for adding the custom functionality unique to your project.
Some of the highlights of Weave include a Merkle-tree-backed data store, a highly configurable extension system that also applies to the core logic, such as fees and signature validation. Weave also brings powerful customizations initialised from the genesis file. In addition there is a simple ORM which sits on top of a key-value store that also has proveable secondary indexes. There is a flexible permissioning system to use contracts as first-class actors, “No empty blocks” for quick synchronizing on quiet chains, and the ability to introduce “product fees” for transactions that need to charge more than the basic anti-spam fees. We have also added support for "migrations" that can switch on modules, or enable logic updates, via on-chain feature switch transactions.
|Cash||Wallets that support fungible tokens and fee deduction functionality|
|Sigs||Validate ed25519 signatures|
|Multisig||Supports first-class multiple signature contracts, and allow modification of membership|
|AtomicSwap||Supports HTLC for cross-chain atomic swaps, according to the IOV Atomic Swap Spec|
|Escrow||The arbiter can safely hold tokens, or use with timeouts to release on vesting schedule|
|Governance||Hold on-chain elections for text proposals, or directly modify application parameters|
|PaymentChannels||Unidirectional payment channels, combine micro-payments with one on-chain settlement|
|Distribution||Allows the safe distribution of income among multiple participants using configurations. This can be used to distribute fee income.|
|Batch||Used for combining multiple transactions into one atomic operation. A powerful example is in creating single-chain swaps.|
|Validators||Used in a PoA context to update the validator set using either multisig or the on-chain elections module|
|Username||Example nft used by bnsd. Maps usernames to multiple chain addresses, including reverse lookups|
|MessageFee||Validator-subjective minimum fee module, designed as an anti-spam measure.|
|Utils||A range of utility functions such as KeyTagger which is designed to enable subscriptions to database.|
Keep an eye out for our IOV Blog to be informed about the latest updates.
Basic Blockchain Terminology
If you are new to blockchains (or Tendermint), this is a crash course in just enough theory to follow the rest of the setup. Read all
Immutable Event Log
If you are coming from working on typical databases, you can think of the blockchain as an immutable transaction log. If you have worked with Event Sourcing you can consider a block as a set of events that can always be replayed to create a materialized view. Maybe you have a more theoretical background and recognize that a blockchain is a fault-tolerant form of state machine replication. Read more
General Purpose Computer
Ethereum pioneered the second generation of blockchain, where they realized that we didn't have to limit ourselves to handling payments, but actually have a general purpose state machine. Read more
Since that time, many groups are working on "next generation" solutions that build on the experience of Ethereum and attempt to build a highly scalable and secure blockchain that can run general purpose programs. Read more
All Proof-of-Work systems use probabilistic finality, where the resource cost of creating a block is extremely high. After many blocks are gossiped, the longest chain of blocks has the most work invested in it, and thus is the true chain. Read more
One interesting attribute of blockchains is that there are no trusted nodes, and all transactions are publically visible and can be copied. Read more
Upgrading the state machine
Of course, during the lifetime of the blockchain, we want to update the software and expand its functionality. However, the new software must also be able to re-run all transactions since its genesis. Read more
UTXO vs Account Model
There are two main models used to store the current state. The main model for bitcoin and similar chains is called UTXO, or Unspent transaction output. The account model creates one account per public key address and stores the information there. Read more
Running an Existing Application
A good way to get familiar with setting up and running an application is to follow the steps in the blog tutorial sample application. You can run this on your local machine. If you don't have a modern Go development environment already set up, please follow these instructions.
To connect a node to the BNS testnet on a cloud server, the steps to set up an instance on Digital Ocean are explored in this blog post.
Configuring your Blockchain
When you ran the
blog tutorial, you ran the following lines to configure the blockchain:
tendermint init --home ~/.blog blog init CASH bech32:tiov1qrw95py2x7fzjw25euuqlj6dq6t0jahe7rh8wp
This is nice for automatic initialization for dev mode, but for deploying a real network, we need to look under the hood and figure out how to configure it manually.
Tendermint docs provide a brief introduction to the tendermint cli. Here we highlight some of the more important options and explain the interplay between cli flags, environmental variables, and config files, which all provide a way to customize the behavior of the tendermint daemon. Read More
Application State Configuration
The application is fed
genesis.json the first time it starts up via the
InitChain ABCI message. There are three fields that the application cares about:
validators. To learn more about these fields Read More
Setting the Validators
Since Tendermint uses a traditional BFT algorithm to reach consensus on blocks, signatures from specified validator keys replace hashes used to mine blocks in typical PoW chains. This also means that the selection of validators is an extremely important part of blockchain security. Read More
Building your own Application
Before we get into the structure of the application, there are a few design principles for weave (but also tendermint apps in general) that we must keep in mind.
The big key to blockchain development is determinism. Two binaries with the same state must always produce the same result when passed a given transaction. Read More
Abstract Block Chain Interface (ABCI)
To understand this design, you should first understand what an ABCI application is and how that abstraction works. ABCI is the interface between the tendermint daemon and the state machine that processes the transactions, something akin to wsgi as the interface between apache/nginx and a django application. Read More
All data structures that go over the wire (passed on any external interface, or saved to the key value store), must be able to be serialized and deserialized. An application may have any custom binary format it wants, although all standard weave extensions use protobuf. Read More