Origami Zero-History Blockchain Structure for Peer Scalability (Part 1)
Surpassing Traditional Blockchain Implementations
Note: You can find the original Origami paper here, and a technical paper on a privacy-preserving Origami blockchain (Zero-History Confidential Chains with Zero-Knowledge Contracts: A New Normal for Decentralized Ledgers?) will be published in ESORICS 2022. I recommend you to read this first since these papers can be too technical.
The most common question blockchain enthusiasts receive is, “Why are blockchains so important?”. And the most reliable answer we can give is,
Well, because they provide decentralization, we can build all these cool decentralized systems like decentralized games, healthcare systems, marketplaces, identity management systems, etc.
But in reality, “Privacy” and “Scalability” often outweigh decentralization.
So, if we are to bring blockchain for long-lasting applications, we need techniques to provide “Privacy” and “Scalability”.
In this article, I am going to systemize blockchain scalability into two axioms,
- User Scalability, and
- Peer Scalability,
and explain what Origami is and how it provides higher peer scalability.
User Scalability
Generally, when we talk about blockchain scalability, we mean user scalability or how fast we can modify the blockchains, e.g., the maximum number of transactions per second. Blockchain inherited this axiom from the traditional distributed systems. Mainly, user scalability depends on the consensus mechanism of the blockchains, the number of peers in the blockchains, and the cryptographic metadata we have to include in transactions.
Peer Scalability
“Peers” or “Full Nodes” are special users who maintain, update and verify blockchain without depending on trusted third parties. They are the users who keep the blockchain network secure and up-to-date. Peer scalability addresses the affordability of the blockchain or how much resources they have to spend to maintain and verify a blockchain.
This axiom is rarely discussed (well, I couldn’t find anyone who talks about it) since, in traditional centralized distributed systems, the nodes only keep their data, not anyone else’s. But in blockchains, peers maintain blockchains of mostly someone else’s data, and the incentives they receive should be able to cover their expenses. If not, the number of peers (not users) decreases over time with the growth of the blockchain, and so-called “decentralized blockchains” become “centralized blockchains”. As we all know, then they are not secure anymore.
What is blockchain history?
Let me explain two examples. Think about a novel cryptocurrency. I received 10 coins from the coinbase as a mining reward. I sent 3 coins to you out of my 10 coins. Now, I have 7 coins, and you have 3 coins. So, the state of me having 10 coins is history. Let’s take a file system. I save a file (FILE v.1.0) and then update it into FILE v.1.1 later. Again my file being FILE v.1.0 is the history. The history of blockchain grows every second. For example, more than 80% of the Ethereum blockchain is its history.
Why do peers need history?
The answer is the verification. Peers want to know whether the current blockchain states (e.g. you and I owning coins and FILE v.1.1) are valid or not. Blockchain verification checks if the changes that have been done to the initial state (or null state) are valid and lead to the current state. Different blockchains have their own ways of checking the validity of states, e.g., checking the validity of inputs (my 10 coins and the existence of FILE v.1.0) and whether I consented to change my states to new states via digital signatures. Simply, current blockchains need the history to verify the current blockchain state.
Then How can Origami be zero-history?
Origami is a new cryptographic data structure suitable for blockchains that mitigates the scalability issues of the Merkle-tree-based blockchain structure. Unlike traditional Merkle-tree-based blockchain data structures, e.g., Bitcoin and Hyperledger, it has a new cryptographic data structure that allows deleting while verifying current states. Origami is based on activity proofs or simply activities instead of direct hashes. These are 33 bytes for classical 128-bit security and 49 bytes for post-quantum 128-bit security. We will discuss more activity proofs in the next article.
How does Origami improve peer scalability?
Assume a new peer wants to join. When downloading the blockchain, the peer can get the tiny zero-history blockchain and verify it without trusting anyone. Similarly, a peer who returns after a while can download the tail of the blockchain without intermediate history. Therefore, they spend less memory and less computational power on verification. Also, blockchain syncing is faster with zero-history blockchains. The following figure shows the estimated blockchain sizes for different digital signatures.
What if someone wants the entire history? Or a portion?
If someone wants the entire history, they can just store it. There is nothing prevents them from doing it. Also, most of peers are interested in some historical data. Then they can download the origami blockchain with those historical data, e.g., Jayamine had a FILE v.1.0 in the 10th transaction. Then they can verify whether I had a file or not by verifying the activity proofs. Therefore, deleting history does not mean that we cannot verify the existence of history or forge history. If I have FILE v.1.0, I can prove to someone else that I had a file in the blockchain securely. Therefore, we can only store the history we are interested in without wasting everyone else’s resources in the network.
What is Origami’s consensus mechanism?
As I explained before, Origami is a cryptographic data structure for blockchain alternative to Merkle-tree-based blockchain. Therefore, you can use it with any secure consensus mechanism we use with traditional blockchain. You can find more information about how it works in this paper.
The following article will explain the cryptography behind the activity proofs.
