What is a stateless blockchain and what is Purplecoin/XPU
In earlier blockchain technology, nodes would have to store all the history of transactions in order to validate new transactions. In a stateless blockchain we don’t have to.
Every block header contains a cryptographic accumulator that represents the state. A good example of a cryptographic accumulator are merkle trees. They allow us to tell if an element is in a specific set without knowledge of the set itself.
In the same way, we can leverage cryptographic accumulators to validate the state of a blockchain. A merkle tree is a static accumulator (the set elements cannot change). We employ a dynamic cryptographic accumulator, where elements can be inserted or deleted. More specifically, we use the RSA dynamic accumulator, invented by IBM, to represent the state. This is a ~32 byte field in the block header.
As such, full nodes are no longer required to store the state in order to validate incoming transactions. Everyone is responsible for storing their state instead.
Stateless validation
How does a stateless blockchain validate blocks/transactions? We must first understand the definition of a stateless blockchain. To put it simply, a stateless blockchain validates a new block and its transactions, without any information other than the previous block header.
All required information to perform consensus is sent over the wire along with the new transactions in a block. In a stateless blockchain, in theory, all other block headers besides the latest one can be pruned and block validation can be performed identically as a full-node. In practice, we store the latest 50 headers to handle potential forks. After 50 confirmations, a block is considered final.
This is in stark contrast to all other blockchain protocols, which require validating all transactions from genesis or a checkpoint and store a database of transactions which grows over time.
While headers can be pruned, the UTXO set (transaction log) in case of Bitcoin which at the time of writing is 3gb, cannot be pruned or else it would break validation. It is the same case with Ethereum's state trie, which is around 130gb. In our case, a node would have to store 20mb of headers in order to validate new blocks.
This means the initial sync is more or less instant. When using a bridge, further syncs are also instant.
How spending assets works in Purplecoin/XPU
In Bitcoin, we have to keep our private keys secure and our assets are found on-chain. In Purplecoin, the user is responsible for keeping the private keys secure and the assets.
How does this work in practice? Assets cannot be spent without private keys but they can be stored in multiple places for safety.
Bridge nodes and the sharded UTXO set
The rule of thumb is that in Purplecoin, everyone is ultimately responsible for storing their UTXO set. This can be done in the following ways:
- Running a personal bridge. The caveat is that a personal bridge should be online at all times in order to update the witness set.
- Relying on a public bridge. A public bridge might for example manage the entire UTXO set of a single asset as long as it isn’t too large. Or one asset can be split among different public bridges. The caveat is that this relies on the goodwill of others as running a bridge can become expensive.
- Using a private bridge. A private bridge is a business which offers to manage the UTXO set of private clients in exchange of a fee. For example, in the future banks might offer such services. A private bridge can either only store the UTXO set of a client, part of their keys in a multi-sig setup, or entirely manage their private keys.
Example setup
Alice stores 10 XPU on her local computer and the cloud. If her local copy gets lost, she can download them back from the cloud. If the cloud shuts down or loses the assets, she has her local copy.
State is stored off-chain and decentralisation at the state level is achieved via “not keeping your eggs in one basket”.
Ultra light nodes
In this way we can run ultra light nodes which can even run on a hardware wallet. Once the wallet has internet connectivity it can download the assets from somewhere and spend them using the keys stored on the device.
Not keeping your eggs in one basket
Ultimately, it is up to the user to choose how they manage their UTXO set, in the same way as it is up to them to choose how they manage their private keys. While this is inconvenient when compared to Bitcoin, as it adds another type of data the user is required to manage besides private/public keys, it is the caveat of scalability.
Another way to explain it is that in Purplecoin, the UTXO set is stored off-chain while the only thing that is kept on-chain is the cryptographic accumulator of the UTXO set.
Users should store their UTXO set in multiple places to avoid loss.
Learn more
- Website — https://purplecoin.io/
- Whitepaper — https://github.com/purpleprotocol/purplecoin_whitepaper/blob/main/whitepaper.pdf
- README — https://github.com/purpleprotocol/purplecoin/blob/main/README.md
- Crowdsale info — https://github.com/purpleprotocol/purplecoin/blob/main/doc/crowdsale.md
- Technical roadmap https://github.com/purpleprotocol/purplecoin-core/blob/main/ROADMAP.md
- Source Code — https://github.com/purpleprotocol/purplecoin-core
- Github — https://github.com/purpleprotocol
- Reddit — https://www.reddit.com/r/purplecoin
- Twitter — https://twitter.com/xpu_official
- Discord — https://discord.gg/5ZVZnKd
- Telegram — https://t.me/purplecoin_io
- ANN — https://bitcointalk.org/index.php?topic=5417004.0
- Merch — https://merch.purplecoin.io/
