The disruptive success of blockchains in the cryptocurrency space and the exciting prospect that this technology promises in other fields has garnered the interest of entrepreneurs from various domains. Over the last couple years, this interest has led to more than $1B USD investment in innovative blockchain solutions targeting traditional industries. The current tendency towards increased adoption of blockchains for custom purposes shows no signs of fading in the near future. It has become de rigeur for entrepreneurs to want to put every single kind of asset on a blockchain. Some suggestions for "X on the blockchain" that we have heard to date are:
The list goes on. And it raises the obvious question: when all these things are "on blockchain," whatever that means, where exactly are they going to go? How is this going to happen?
It turns out that there are only two options: one can create a dedicated blockchain for each asset class, or one can try to coalesce all of these assets onto an existing chain such as Bitcoin's. These two options induce a seemingly irreconcilable tradeoff between the scalability of independent blockchains and the security of monolithic ones.
Approaches that rely on building dedicated blockchains suffer from lack of mining power to secure the infrastructure. In the event such independent chains succeed and we get a strongly-backed chain per asset class, the result is costly and environmentally unfriendly. Otherwise, the chains are insecure by definition, open to all kinds of attack on the valuable assets stored on them through investment in relatively cheap mining equipment.
To avoid such costly, environmentally unfriendly, and insecure approaches, some developers opt for layering their services on an existing blockchain that embodies sufficient mining power to withstand attacks. A common technique that has been experiencing a rapidly increasing adoption rate is aggregating such service-specific data via OP_RETURN transactions on top of an existing blockchain, such as Bitcoin's. This has the downside of cluttering up the Bitcoin blockchain -- in fact, the incredibly popular OP_RETURN was a controversial feature that was resisted by many core developers for this reason. People who want to use Bitcoin solely as a store of value or a payment system still need to process the (from their perspective) irrelevant OP_RETURN transactions related to land and deed records. With Bitcoin having a difficult time of scaling just for payments, it is unlikely to scale well to timestamping multiple such chains representing blocks from other chains.
In this post, we provide a new scheme called Aspen for what we call Service-Oriented Sharding. Aspen enables users to secure multiple chains, in parallel, efficiently and securely. The details are now available as a white paper, while the following text describes the intuition behind the system.
Sharding is a technique that distributes contents of a database across nodes in a network to achieve high scalability. The key insight behind Aspen is to distribute transactions to blocks with respect to services, in a manner that enables functionally distinct transactions to remain on different chains, but for the chains to get connected together at certain blocks. To understand why this solution is novel and effective, let's look at the requirements a blockchain sharding protocol ought to possess:
The following figure shows the structure of Aspen's blockchain:
Aspen's blockchain consists of individual threads called channels. Each channel is a chain that shares the same genesis block (drop) and checkpoints (valves). It contains a set of transactions that belong to a specific service (buckets with the same symbol). For example, a service for domain name resolution would have a specialized channel to store custom transactions in the form of DNS resource records. These records are stored in blocks that are not shared with other channels. This ensures that distinct services are loosely coupled and resilient to changes in one another. Miners distribute such transactions to designated blocks -- i.e. corresponding buckets -- and they secure them via checkpoints, which require proof of work to be generated. Hence this technique utilizes the combined mining power of miners to secure all channels.
The system relies on payment and registration channels to help bootstrap the system. The payment channel facilitates the service for exchanging funds between users, and the registration channel enables users to dynamically introduce services or update the existing ones. The syntax for each transaction type, the relationship between intra-channel transactions, as well as the size, frequency, and format constraints for blocks that keep such transactions are defined by protocols specific to each service. Users store, process, and propagate transactions on channels only for the relevant services. An integration protocol defines global properties such as the security, reward structure, valid service numbers, the genesis block, and the inter-channel communication between the payment channel and the other channels.
While service-oriented sharding is applicable to any existing blockchain protocol, such as Bitcoin or Ethereum, Aspen is instantiated on Bitcoin-NG, which provides much higher transaction throughput than Bitcoin with a fraction of its consensus latency. The following figure shows the blockchain structure of Aspen with example channels.
Shading indicates blocks generated by a specific miner.
Existing blockchain protocols try to achieve a consensus on a single main chain that commingles all transactions. In contrast, Aspen separates out unrelated transactions by asset class, and thereby enables clients to only follow the chains related to their interests, while securing the entirety of the chain set with the same mining power.
Specifically, Aspen separates independent transactions into a series of microblock chains that are conjoined at common key blocks. Each channel contains the same genesis block, all key blocks (blocks with a key symbol), and a specific set of microblock (circles) chains containing custom transactions (buckets with the same symbol). Key blocks combine the chains together. Details such as the reward structure, how to dynamically introduce new services, and how to update existing ones are discussed in the white paper.
An interesting aspect of Aspen's design is that it's possible to view the existing Bitcoin network as an instantiation of Aspen. This enables one to build Aspen as a subsuming blckchain around Bitcoin, encapsulating the existing blockchain structure and amending it with new blocks that enable multiple asset classes to be threaded together.
Overall, Aspen provides a new approach to scaling up to the demands of different asset classes for secure representation on a blockchain.
Dr. Gencer is a researcher at LinkedIn. His thesis research focused on improving the scalability of blockchain technologies. more...
Hacker and professor at Cornell, with interests that span distributed systems, OSes and networking. Current projects include HyperDex, OpenReplica and the Nexus OS. more...
bitcoin / security / ethereum / hyperdex / release / nosql / selfish-mining / blocksize / dao / surveillance / privacy / mongo / broken / weaver / nsa / meta / leveldb / blockchain / 51% / voting / smart contracts / graph stores / decentralization / bitcoin-ng / vaults / snowden / satoshi / philosophy / mt. gox / mining pools