Giter Club home page Giter Club logo

lucky's Introduction

Luckychain

Luckychain is a blockchain layered on top of IPFS. It uses Intel SGX capabilities of modern CPUs for Proof of Luck consensus algorithm which allows energy efficient mining. Transactions can reference arbitrary data of practically unlimited size. A new block is mined on average every 13 seconds. It is written in JavaScript and uses a NPM package which allows running JavaScript in SGX enclaves.

Warning: This is a prototype. Do not use it yet for anything important.

Current implementation uses mock SGX implementation without any of the security assurances of the SGX platform. Help finalizing the NPM package with full SGX support is welcome.

Build guide

This library has the following system dependencies:

After installing the aforementioned system dependencies, install the node dependencies in the root of this repository:

$ npm install

Start

Initialize IPFS the first time:

$ ipfs init

Start the IPFS daemon:

$ ipfs daemon --enable-pubsub-experiment

Lastly, start the application:

$ npm start

Open the web interface at http://localhost:8000.

Docker

You can use Docker to run Luckychain:

docker run -d -p 4001:4001/tcp -p 4002:4002/udp -p 8000:8000/tcp --name luckychain luckychain/luckychain:master

Whitepaper

The whitepaper describing Proof of luck consensus protocol and Luckychain blockchain was published in SysTEX '16 Proceedings of the 1st Workshop on System Software for Trusted Execution, DOI 10.1145/3007788.3007790.

Available at:

Abstract:

In the paper, we present designs for multiple blockchain consensus primitives and a novel blockchain system, all based on the use of trusted execution environments (TEEs), such as Intel SGX-enabled CPUs. First, we show how using TEEs for existing proof of work schemes can make mining equitably distributed by preventing the use of ASICs. Next, we extend the design with proof of time and proof of ownership consensus primitives to make mining energy- and time-efficient. Further improving on these designs, we present a blockchain using a proof of luck consensus protocol. Our proof of luck blockchain uses a TEE platform's random number generation to choose a consensus leader, which offers low-latency transaction validation, deterministic confirmation time, negligible energy consumption, and equitably distributed mining. Lastly, we discuss a potential protection against up to a constant number of compromised TEEs.

You can cite it as:

@inproceedings{Milutinovic2016,
 author = {Milutinovic, Mitar and He, Warren and Wu, Howard and Kanwal, Maxinder},
 title = {Proof of Luck: An Efficient Blockchain Consensus Protocol},
 booktitle = {Proceedings of the 1st Workshop on System Software for Trusted Execution},
 series = {SysTEX '16},
 year = {2016},
 isbn = {978-1-4503-4670-2},
 location = {Trento, Italy},
 pages = {2:1--2:6},
 articleno = {2},
 numpages = {6},
 url = {http://doi.acm.org/10.1145/3007788.3007790},
 doi = {10.1145/3007788.3007790},
 acmid = {3007790},
 publisher = {ACM},
 address = {New York, NY, USA},
 keywords = {Blockchain, Consensus Protocol, Intel SGX, Trusted Execution Environments},
} 

lucky's People

Contributors

howardwu avatar mitar avatar sunnya97 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lucky's Issues

TODOs before release

@mitar:

  • integrate SGX node module
  • Docker image
  • installing 4 permanent SGX nodes
  • add command line options:
    • --no-sgx to disable SGX module (and use dummy attestation)
    • --blockchain-id the ID of the blockchain to use (overrides the default)
  • infinite scrolling/loading of transactions

@sunnya97:

  • remove tree view
  • remove react-tools from package.json
  • show a list of transactions for each block
  • add a show data for a transaction button and link to gateway.ipfs.io
  • make sure that when a block is expanded, it stays expanded as more blocks are coming in
  • make transaction commit form accept direct data payload, or an IPFS address
  • display network view of peers and be able to click on them to open their web interface

@howardwu:

  • provide API for fetching data for a transaction
  • make a program which fetches data from Bitcoin and Ethereum networks and add them to our blockchain

There are occasional race conditions happening

With the latest code, I can observe occasional errors which should not happen (Error: now < roundTime + ROUND_TIME, Latest's block parent link is not the same as round's block parent link). It seems there are some race conditions or assumptions which occasionally get broken. We should find a way to stress test the system and discover why are those errors happening.

Pin small transactions

Currently we pin (in IFPS) only block, so everyone participating in the blockchain will have a copy of all blocks. But if data pointed to by transactions is not available (disappears from the network), then this makes the blockchain itself less useful. We do not want to simply duplicate everything anyone references from a blockchain, but we could maybe have some small limit and all transactions which are smaller that the limit could be pinned by everyone. (We can know how bit is data pointed to by transactions so we can check that easily.) We could even allow users to decide what is this limit. And for other bigger data, we could have less duplication across the network, with less redundancy. Maybe people could participate in byteswap for those larger transactions.

Do not rely on sleeping after mining for security properties

When a block is mined, enclave does not release it until some short time based on the lucky number. The idea is that luckier block candidates should be sent out sooner than less lucky, so that potentially less lucky do not have to be sent at all. In this way we optimize network traffic.

But currently it seems that we have to rely on this also for security properties, and not just for network performance.

One way to test this is to make afterSleep setTimeout to use 0 timeout (and disable validation inside the enclave). If you have a network of two parties, and one sets it to 0, then currently more or less that one always wins. The reason for that is that when chain is prolonged, miners switch to mine on this longer chain, even if their block might otherwise win in previous chain.

One check we currently have is that after a block is mined, the enclave releases immediately the lucky number, but not the block itself. So the check can then see if we receive a block A with less lucky number than our own B, which should come after our own block B, so something strange is happening. And we currently ignore such blocks which come to soon. And when we then release our own block B (at expected time), the network switches to it. Also, because everyone else probably started mining on that other block A, that work is not lost, because both A and B share the same parent, which serves as round block.

The issue is that this works only after a block has been mined (and node can compare its lucky number with incoming block). Currently, should wait at least one second before releasing their block, to allow for everyone to mine their block before that, but we are not yet checking for that.

Another issue is that occasionally it seems that current code trigger "Received new luckier latest block out of order, ignoring" error even for well behaving nodes.

But main issue is that even if we ignore block A, the malicious miner will win the next block after that, because they could start mining on a followup block C immediately. And even if A does not win and B wins, C will be ready before everyone else even start mining (before 10 seconds, because everyone else slept at least one second more), and because A and B share the same parent, C will be seen as a valid continuation. We should somehow penalize a malicious user so that they cannot win the next block.

In general anyone who is able to mine a block every 10 seconds, and not 13 (on average, because they are not sleeping) will through time have an advantage and more chances of winning with their blocks.

Retry pending transactions if they are not included in the winning block

If a node was mining on a set of pending transactions and its block has not won, what to do if there are any transactions which were not included in the winning block. Because we allow same transactions to appear in multiple blocks, and because we do not want to keep in memory all transactions to check if there are duplicates, it seems tricky what exactly to do.

One option would be to find a common ancestor in chains of both blocks and see which transactions are in losing chain, but not in winning, but only from that common ancestor up to the newest blocks. And then reinclude them into pending transactions.

The question is also how should that happen. By reincluding locally only by a node, or by full retransmission over the whole network.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.