Seedom is an Ethereum decentralized application (DAPP) for raising awareness and Ether for altruistic causes while rewarding a single participant for their contribution and support. It takes the efficiency, security, and transparency of the traditional single-room raffle and re-invents it with trustlessness and crowd-sourced selection into an entirely new type of fundraiser that scales to the entire world. While there are many gambling DAPPs in this space, there are none that give the majority of funds towards a cause.
To allow our Dapp to function at this scale, the Seedom team needed to create the most secure deterministic pseudorandom number generation method, using as many forms of entropy as possible, while avoiding strategies easily manipulated by miners.
Ethereum is a Turing complete deterministic world computer with many mining nodes assisting in its progress. Individual mining nodes cannot generate globally available random numbers as they would never be able to reach consensus. Many Ethereum pseudo-random number generation (PRNG) schemes exist that are resistant to miner tampering, each having various pros and cons. Seedom avoids the usage of current block variables as a source of entropy as it is a flawed approach given a miner’s ability to manipulate all of those values.
For Seedom, we want a method that runs on-chain, requires only a single participant transaction and generates a random number that is globally available to all participants. On-chain implies that most, if not all, of the calculation of the random number is done transparently within the Ethereum Virtual Machine (EVM). A participant should not have to go through multiple steps when participating, and should only need to submit a single transaction. Seedom runs for ten days at a time, and a winner is selected just after each run.
Existing Randomization Techniques
The future blockhash method locks the contract to a specific block number in a first transaction and requires a second transaction, within 256 blocks, that pulls the blockhash of this block number, creating one source of entropy. This method is susceptible to miner manipulation of the blockhash of the first block if a miner has enough computational power to do so.
Commit-reveal implementations, such as the RANDAO, collect user-generated secrets but then require a revelation phase, where users reveal many or all of these secrets on-chain. However, miners can ignore and reorder transactions, and avoid broadcasting blocks entirely. Miners may be able to receive many additional chances of winning, especially towards the end of the revelation phase, even with deincentivization mechanisms.
Any use of an external oracle requires a participant to trust the availability and validity of such service. The participant must trust all of the oracle’s underlying infrastructure and trust that the oracle has not tampered with the results. Moreover, a technique known as front-running allows an attacker to observe pending transactions for a response from an oracle and insert their own response ahead of the oracle’s response using a higher gas price.
Signidice uses a cryptographic signature between two parties to generate a secure random number using this signature. It is not useful when more than two parties are involved. BLS threshold signatures allow for a similar random number generation process that is not limited to two parties. The necessary functions for BLS do not yet exist in Solidity, but Seedom may begin using threshold signatures as they become available.
Finally, sequential proof of work, or RANDAO++, involves the computation of multiple successive hashes over a small range of blocks using the blockhash of the first block and values submitted by several users. These hashes are then XORed to produce a final random number. It is not possible to compute the hashes quickly enough to determine what the iterated hashes of the other submitted values are, making the random number impossible to manipulate. Unfortunately, due to their complexity, these hashes must be produced off-chain, which then requires user security deposits and punishments for cheating.
Seedom’s Randomization Technique
The Seedom approach involves a combination of some of these methods to receive combined benefits. It begins with receiving two secrets, or hashed messages, guaranteed to be from Seedom and the cause as part of a commit-reveal. Once these secrets store on-chain, the collection of public messages from participants can occur during the participation phase.
After the participation phase ends, the cause reveals their secret message first and saves the block number of this revelation transaction on-chain. Seedom then reveals their secret message in a future block, using the future blockhash of the reveal transaction block number as an additional source of entropy. Both secret messages are verified using this simple formula.
The two revealed messages and the future blockhash are then used to calculate a first random number using the following formula, which is modded with the total number of entires to obtain a random entry number. The entry number is subsequently used to find a first random participant.
With a random entry number, the corresponding participant is found using a binary search into a dynamic array of Seedom funding instances constructed during the participation phase. These fund instances represent each participation and raising of entries. The array of funds is structured as a cumulative density function (CDF) of new entries by participant, in order of contract funding time. The following figure displays this search process visually, for a random entry number of 42.
This process loops a set amount of times, as defined by the entropy number supplied during Seedom fundraiser contract deployment, using the participant’s message at each step as part of the seed for the next random number. Here is the formula used for this next random number.
Our random number generation method creates a random path through a subset of the immutable participants and their corresponding messages to add additional entropy to the participant selection process. The last participant on the random path is the participant selected for reward and is stored in the fundraiser contract, completing the fundraiser. Anyone can validate this entire deterministic process using data stored in the contract. Here is another visualization of the overall method, where the dashed lines represent nextRN calculations using the formula above.
Summary
Thank you for making it this far and let us know if you see any glaring flaws in our method. Our full whitepaper can be found here.
We just launched our first beta on the Ethereum Mainnet on May 1, 2018, at Seedom.io, and it runs until May 11th, supporting a project near and dear to our hearts: Giveth! Bimonthly or roughly every two weeks, a new altruistic cause is chosen, with the help of our community. If you have a cause in mind and want us to support it in an upcoming round, please let us know at team@seedom.io.
❤
References
Arseny Reutov. “Predicting Random Numbers in Ethereum Smart Contracts”. In: (2018). URL: https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620.
Solidity: Units and Globally Available Variables: Block and Transaction Properties. URL: http://solidity.readthedocs.io/en/v0.4.21/units-and-global-variables.html#block-and-transaction-properties.
RANDAO: A DAO working as RNG of Ethereum. URL: https://github.com/randao/randao.
Antonio Salazar Cardozo. “Threshold Signatures”. In: (Dec. 2017). URL: https://blog.keep.network/threshold-signatures-ff2c2b98d9c7.
Vitalik Buterin. I’ll throw out my latest ”RANDAO++” idea. June 2016. URL: https://www.reddit.com/r/ethereum/comments/4mdkku/could_ethereum_do_this_better_tor_project_is/d3v6djb/.
Security Considerations. URL: http://solidity.readthedocs.io/en/develop/security-considerations.html.
Kris Decoodt. “What is the Giveth DApp?” In: (2017). URL: https://medium.com/giveth/what-is-the-future-of-giving-d50446b0a0e4.
David Ernst. “Hard Problems in Cryptocurrency”. In: (2017). URL: https://github.com/ethereum/wiki/wiki/Problems.
gluk256. “The Signidice Algorithm”. In: (Jan. 2017). URL: https://github.com/gluk256/misc/blob/master/rng4ethereum/signidice.md
