Dev:
Came across this article regarding Solidity.
https://medium.com/@Hibryda/why-solidity-isnt-solid-3341af77fc1cThis is not about etheraffle, but about Ethereum's Solidity. Was wondering about this statement from the whitepaper "Provably Fair Everything occurs in the public domain." I know this is not my first encounter of "provably." There are other projects with such a claim. But with etheraffle having completed so much work, I thought you maybe in a better position to answer this question. Have you carried out proving the fairness of etheraffle? Is the "provability" based on analysis of theorem prover or based on the fact that all the transactions are recorded on the blockchain?
I know this question may go beyond the scope of this project, but it may be directly related due to the fact this project is based on Ethereum.
Thanks for your time and info.
Hi
Sjyi!
With regards to provability, ours comes from the fact that the entire of the raffle functionality takes place on chain. This, in addition to the transactions also being etched in to the chain where our fairness comes from. Not only can you see how our random numbers are generated (by lightning no less!) but also how they are stored, how a users numbers are compared to the winning numbers, and how in the event of a win the prizes are calculated using the
actual odds which are baked into the smart-contract. You can literally read the code that's running on chain and see what it's doing. We are hiding nothing.
Better still, because of the recursion in the smart-contract, you can see that none of the above requires
any any human involvement at all. All the other blockchain lotteries out there obfuscate these processes, and or require a person (and so a centralized, single source of failure) to make happen. We do not. It's all laid out there, in the contract, for anyone to go and look at.
I know setting up the development/test environment could take an effort, but if you're willing to take on remote test, I'm willing. I'm starting to work with truffle.
Very interesting! How familiar are you with Solidity development?
As it happens, we don't use the Truffle/Ganache frameworks due to the large overhead. The current contract re-write that the update hinted at earlier is now in a far more functional programming style (which strictness lends itself to blockchain security). And so because much of the contract has now been converted to "pure" or "view" functions they are much simpler to unit test directly in Solidity itself (or in Go when automating). Those functions remaining that do have side affects (mainly pertaining to Oraclize) are also simpler to unit test directly in Oraclize's forked Remix compiler.