Trustless Decentralized lottery system on Ethereum.
·
Report Bug
·
Request Feature
![Product Name Screen Shot][product-screenshot]
BIBENDUM is a trustless decentralized lottery system, that can be used to nominate and draw lotteries.
The amazing feature of the project is its random lottery draw feature, which is completely trustless and decentralized.
-
Why :A decentralized lottery system that is trustless, is a necessity. This is because lottery should be a zero sum game, but the fact that the organizers profit from it, shows that it is not the case.
In the pre-blockchain age, we had to suffer this tradeoff of fairness, because there was a need of trust in the organizers. But now, a trustless escrow contract can do what the organizers of lottery do, for free. Thus we need to upgrade to adecentralized trustless lottery system. -
How :We make use of escrow contracts, a virtual entity that holds all the money on wage for a particular round of the lottery. The first version requires a moderator, however, it is still a zero sum game, because the moderator has no more stake or chance of winning than any other participant.
npm install
npm install truffle -g- Download GANACHE
This is an example of how to list things you need to use the software and how to install them.
- npm
npm install npm@latest -g
- Clone the repo
git clone https://github.com/vs666/BIBENDUM.git
First we need to run the ganachse server.
./ganache-2.5.4-linux-x86_64.AppImage
The solidity script deployment :
truffle compile
truffle migrate --reset
Now, we need to deploy the frontend ( we use lite-server)
npm run devThe application is a simple web interface that allows you to draw lotteries. The following screenshots from the application explain the usage and shows the interface.
-
This is the homepage of the application that is meant for the explaining of the interface. The left console displays theaccount details, the right console displays thecurrent round of lotteryandactions that can be taken. Further, the middle panel is for information regarding the accounts of the participants of the current round of lottery. -
This image shows the process of buying a ticket using themeta-maskextension.
Now, after multiple people have bought stakes, we have the account details as follows :
The screen looks like this :
Now, the lottery round is closed by the initiator of the lottery, and roll is done by any one of the members. After the draw, the screen goes back to the image similar to (1), and the account details looks as follows:
In future we aim to release subsequent versions with the following changes :
v1.0 The first version is simple, one contract with a need for a controlling authority to decide status of rounds (started, ended, etc).
v1.1 In this, we plan to resolve potential issue of asynchrony in the system. If the controlling authority has closed a round and message delay allows some person to participate in the round, this should bot be allowed.
v2.0 In this version, we plan to make modifications to the architecture to disallow a controlling authority to close rounds. This will solve asynchrony problems.
v2.1 In this version, after true decentralized system, we plan to allow any user to roll out the round.
See the open issues for a list of proposed features (and known issues).
-
Kicking off Blockchain Journey :This was the first time we coded in Solidity, so the biggest challenge was to get a working understanding of the Blockchain (esp. Ethereum). We had to learn how to use the Ethereum client, how to create a contract, how to deploy a contract, how to interact with the blockchain and how to use the web3 js. -
Deciding a winner :The major challenge was that the winner needed to be out of the state, which was challenging. So we devised a clever method. If a person wished to meddle with the winner selection method so that he himself becomes the winner, he would have to increase his stake in the lottery. The proper way to attack would be to find a desired hash value (calculated in the contract) that makes the particular person the winner. So, for this he would have to increase his stake. For n people already in the contract, his chance of being winner will be 1/n. So he would have to keep adding stake (on average around n times), so he is the expected winner. This is after the assumption that other people have stopped betting, and the organizer has not closed the round yet.
Thus, we notice this attack has been heavily disincentivised, and though possible with a low probability, the expected return is very highly negative. -
Asynchronous Nature :This is currently an open problem and the primary reason we have a host for the lottery. While the host himself will have equal expectation of reward, a rational adversary being a host might cause freezing of stakes, and a few related attacks. We have minimized the problem by designing the protocol such that any potentially destructive action will require a high stake.
Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are greatly appreciated.
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
Distributed under a License with specific instructions for commercial use or distribution. See LICENSE for more information.
Varul Srivastava
@VarulSrivastava
Project Link: BIBENDUM