Skip to content
Official Rust implementation of the Purple Protocol
Rust Other
  1. Rust 99.2%
  2. Other 0.8%
Branch: master
Clone or download

README.md

Purple Protocol

Build Status AppVeyor Discord _pdf whitepaper

Welcome to the official Rust implementation of the Purple Protocol!


Purple is an advanced, experimental open blockchain protocol that has been designed from day one with an emphasis on scalability and complete decentralization. Its aim is to provide a performance that is greater or at least equal to the payment processor VISA, which can in peak times achieve up to 50.000 transactions per second, but in a decentralized scenario.

In order to achieve this, a new consensus mechanism has been devised from scratch by starting from the latest distributed systems and cryptocurrency research. The result is an extension of the Nakamoto Consensus Scheme present in Bitcoin and other cryptocurrencies.

The name of this mechanism is Semi-Synchronous Proof of Work, or SSPoW for short, because of the asynchronous extension it provides over traditional Proof of Work based consensus which is inherently synchronous.

Rationale

In traditional Proof of Work systems, the ledger is updated by one randomly chosen "master node" which decides the next state of the ledger. The problem is that this is limited by the current block time which cannot be less than a few seconds.

SSPoW maintains the same scheme of choosing a node by it requiring to provide a valid PoW. The difference is that after a node has been chosen, it can decide more than once the next state of the ledger, without waiting for another valid proof.

In fact, in SSPoW, multiple nodes can do this at the same time by forming a validation pool and executing a second consensus algorithm which is inherently asynchronous and is thus much faster.

If too many corrupt nodes enter the validation pool, the asynchronous algorithm will blow up. The trick is that in combination with the first step, the entry rate to the pool can be adjusted by lowering or raising the block time interval.

At the same time, the amount of sets a node is allowed to validate while being in the pool can also be adjusted. In this way, with the right parameters, the system can in theory achieve equilibrium and thus remain operational even in case of attacks such as the dreaded 51% attack.

For more information on the consensus mechanism, take a look at the introduction page on the wiki.

Warning

All of this is still highly experimental and awaiting to be stress-tested on a large network. Many things can and possibly will still change.

If you want a clear description of the progress so far you can look at the milestones section of the repository.

USE AT YOUR OWN RISK!

Building

Building the project requires cmake, clang/llvm and the CUDA toolkit. After all dependencies are installed, run:

cargo build

Using docker

A Purple node can also be run from a docker container:

docker build .

Running

To run the node in development mode with all logging enabled:

Set permission to run the script
chmod ug+x ./run_debug.sh
Run node
./run_debug.sh
You can’t perform that action at this time.