Proof of work consensus protocol used in modern cryptocurrencies like Bitcoin and Ethereum consumes a lot of energy and requires participants to use their CPUs for mining instead of other useful work. But exactly this cost is why it is works to prevent Sybil attacks. One cannot participate in the selection of the next block without paying this cost, which makes the issue of puppet participants trying to influence block selection irrelevant, because they also have to do the work, and pay the cost.

In recent Intel CPUs a new set of instructions is available, SGX, which allows one to run code inside a special environment where even operating system cannot change its execution. In the paper we published (arXiv, Cryptology ePrint Archive) we explore consensus protocol designs using the Intel SGX technology, with the goal of making blockchain participation energy efficient, with low CPU usage, and to democratize mining so that participants can participate again with their general purpose computers (with Intel CPUs) instead of only with specialized ASICs.

Proof of luck is an example of such a Intel SGX based consensus protocol where all participants select a random number (luck) and one with the highest number wins (luckiest). The luckiest block is then used as the next block in the blockchain. Because random number selection happens inside an SGX environment one cannot fake it. Each CPU can choose only one random number per block.

We made a blockchain implementation based on the proof of luck. Instead of reimplementing lower layers needed for a blockchain we built it on top of IPFS. It is written in JavaScript and uses a NPM module to run JavaScript inside SGX environment. Because it is build on top of IPFS, its transactions can reference any other object stored in IPFS, whole files, large or small, and other linked data structures.

Two main properties we want from a blockchain is liveness and persistence. Liveness means that transactions submitted into a blockchain cannot be prevented from being added to a blockchain. One could ignore a particular transaction in their block, but because somebody else’s block might win instead, they cannot really prevent that winning block to include the transaction. And even if their block wins this time, the next winning block might include the transaction instead.

Persistence is the one we commonly associate with a blockchain. Once a transaction is committed into a blockchain block, an attacker should not be able make the transaction or the block be removed later on from the blockchain. Effectively this means that the attacker should not be able to convince all other participants to switch to a blockchain version with that block removed (or changed to not include the transaction). In our blockchain participants switch to a new blockchain when the new blockchain is luckier as a whole (sum of all blocks’ numbers) than the old blockchain. But an attacker would have to create an alternative chain with many blocks luckier than those in the original chain, and this is harder and harder as the chain is getting longer, because all other participants are choosing the luckiest block among all of their block candidates, and the attacker would have to surpass them all.

All this is currently at a prototype stage and not everything is yet properly implemented, or even designed, but try it out and contribute to its development. Moreover, you can now use SGX in your node.js app, too.