The first time I wrote a smart contract was almost a decade ago when the only apparent use case in blockchain was tokenisation. I wanted to show that other use cases were possible.
Prior to working in finance and technology, I had been a student of science so I decided to see if an experiment could be run on-chain. My goal was to run a global experiment where anyone could contribute data and the results would be available for anyone to verify.
The experiment I chose was to measure pi through the cumulative rolling of dice. I absolutely love reading about the history of mathematics and while doing so I came across Buffon’s experiment.
Buffon’s experiment is centuries old and was tested by US civil war prisoners of war to pass the time. The experiment was originally to throw a matchstick on a lined piece of paper and could the number of times it crossed a line; the civil war prisoners did not use paper but instead would throw a match on the floor and count the number of times it crossed two planks.
By counting the total number of throws as well as the number of times the match crossed a line, pi could be calculated in a formula based on the probability of the match landing across a line. After about a thousand throws, the calculated value of pi would be correct to a few decimal places. Obviously prisoners of war had a lot of time on their hands.
Rather than have participants throw matches on a lined piece of paper, I decided to have them roll a pair of dice instead. The difficulty with having them throw matches is that the formula to calculate pi depends on the length of the match as well as the distance between lines on the page. Rolling a pair of dice does not depend on the size of the dice or the material they are made of.
When rolling a pair of dice, there are 36 possible outcomes that sum to values between 2 and 12. Of those 36 combinations, only one combination gives 2 while there are six combinations that add up to 7. When the different combinations are mapped out as a histogram, they follow a shape similar to the bell curve. My hypothesis was that the frequency of rolling a 7 would match its probability. By substituting the frequency of rolling a seven into the probability function of the normal curve and treating pi as the unknown, I could calculate pi.
The smart contract (0x16FA8DF7F16f9E41B7C5522Cc12a22053A2a776F on MainNet) had three functions. One was a transaction to submit a die roll that accepted two integer values between 1 and 6; this function emitted an event upon success. The events enabled a record of all rolls. The other two functions were read only and provided the total number of rolls submitted as well as the number of times a submitted roll equalled 7.
At first, I was a little lazy and calculated the mean and standard deviation based on a scenario of 36 rolls providing every possible outcome. Then I started using the data I accumulated to instead calculate the mean and standard deviation and found that this actually improved the accuracy. After about 2700 rolls, the calculated value was within 1% of pi.
At the time, I had a website where anyone could contribute die rolls and I would pay for the transaction on their behalf. Then the price of gas ballooned to over 400 and transactions became a lot more expensive; so I shut down the website. By that time, there were over 6000 rolls submitted.
Since then, I have considered how I would rewrite the contract as well as possible applications of the logic. The original contract only tracked the total number of rolls and the number of times a 7 was rolled to minimize costs and not use too much storage.
If I were to rewrite it, I would instead use an array to track the counts for all the possible combinations. The frequency of rolling a 2, 3 or 4 is the same as the frequency of rolling a 7 since there are a total of 6 combinations to do so. Alternatively, someone could choose to use the frequency of rolling 8 instead. By storing the counts for every combination, there are more ways to calculate pi instead of just through rolling sevens. Using an array also makes it possible to calculate the mean and standard deviation within the smart contract.
The other change I would make would be to add an interface and make the contract an abstract contract. That way, anyone can branch off their own copy of it and track their rolls separately from the global community.
The reason I would want to enable anyone to track their rolls separately is so that they can effectively measure whether they are cheating or not. The abstracted contract would still contribute the to the global count while also maintaining a local count.
The ability to calculate pi is based on the assumption that all of the submitted rolls are random. As more and more data is included, the calculated value of pi should become accurate to more decimal places. If, however, someone cheats by not rolling dice but instead always submitting sevens, the frequency then changes and the calculated value of pi should diverge from the true value of pi instead of converging.
By tracking the rolls submitted by an individual and comparing them against the community, the calculated value of pi after a submitted roll should be more accurate than before they had submitted the roll. If it becomes less accurate, then it suggests that they did not submit a random value.
I have simplified it quite a bit here. In reality, I would probably require the individual to submit a number of rolls and compare the value of pi before and after the inclusion of those rolls.
This can then be taken further to validate the randomness of values submitted to a contract on chain. For example, if a random set of bytes need to be verified for randomness, a sample of the values could be used to generate a die roll combination. A byte is typically represented by two hexadecimal values. One hexadecimal digit can have a value between 0 and 15; if you add one, discard anything over 12 and then take the remainder after dividing by 6, you have a die roll (if you do not discard anything over 12 then the frequency of 5s and 6s will be less than the other numbers) . Two hexadecimal numbers could then be converted to two die rolls.
The values do not even need to be converted to a die roll, the contract could be written to use two hexadecimal values instead; the sum of two hexadecimal values can be anywhere between 0 and 30. It does not even need to be two numbers, the system could use three or four numbers instead of two.
By tracking the values submitted by different entities and comparing against the community, the entities not providing random values should soon become apparent. As the dataset grows, so should its accuracy in detecting fraudulent entries.
Why does this matter? This matters because cryptography relies on randomness. Although the newer post-quantum cryptographic methods are computationally difficult to crack, they rely on randomly generated values for their keys.
One of the bigger risks in a post-quantum world is that devices generating the keys may not be able to generate sufficiently random enough values. A possible attack vector would be to emulate the system’s creation of keys where the same “random” values are provided. This is why strong cybersecurity requires some form of auditing the logic that generates the keys.
Ultimately, the security of a system requires proof of its randomness.
Calculating Pi to Verify Randomness was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
