Verifiable Randomness, DEXs, and tutorials
I’m Andrew Levine, the CEO of Koinos Group, and today I’d like to update you all on the progress we are making on randomness!
In addition to making the KOIN token fast and truly fee-less, we want it to deliver on Satoshi’s original vision of a truly peer-to-peer electronic cash that does not require dedicated hardware. In other words, we want KOIN to be provably egalitarian. Satoshi wanted people to mine Bitcoins with the computers they already used for other purposes so rewards would be distributed evenly across the network. This would allow all people to participate in the process (and be rewarded).
The important point being; the original intent behind Bitcoin was far more focused on accessibility than the current narrative would indicate.
Proof-of-burn is intended to deliver the economics of proof-of-work with the efficiency of proof-of-stake while being provably egalitarian, thereby delivering on Satoshi’s original vision. What that means to us is that anyone, with virtually any hardware set up, should be able to participate in block production and earn their fair share of the block rewards.
In order to fairly distribute rewards among block producers we need a random process — a way for people to “roll the dice” — that selects who gets to produce a block. As in any game-of-chance, it is extremely important that this process be truly random because a non-random process can be exploited.
If a block producer can predict what accounts will get to produce a block, not only would this allow them to position themselves to earn an unfair percentage of the block rewards, it could open the door to a 51% attack!
Needless to say, how we solve randomness is very important.
But randomness in computing is a notoriously challenging problem and randomness on a blockchain adds wrinkles that many teams have spent years ironing out. The key problem being that the process needs to be both deterministic and unpredictable at the same time.
Not only is randomness important for implementing proof-of-burn, it is also necessary for some of the most valuable decentralized applications in operation like play-to-earn games and games-of-chance.
I’m excited to say that we have completed work on a solution that addresses both of these problems at the same time!
Randomness in Proof-of-work
In proof-of-work, producers “roll the dice” by performing computationally difficult, but ultimately meaningless computations (hashing the contents of the pending block and a nonce). If they get lucky and produce a hash with the right number of leading zeroes, the block is considered valid and they earn a block reward. In other words, hashing a block with a nonce is the random process employed by block producers on proof-of-work chains to distribute block rewards in a provably fair manner.
The end result is randomness, but the computational energy spent to get to that result is incredibly high. High energy usage systems aren’t necessarily problematic, so long as you receive increased performance for the cost. But decentralized systems do not increase performance with added energy costs. Instead they increase security in the form of decentralization, but the marginal benefits are exponentially decreasing. Increasing the number of producers from 100 to 200 doubles decentralization (assuming equal hash power) but also doubles energy usage. To double decentralization again now requires 200 additional nodes.
The Koinos consensus algorithm (proof-of-burn) solves this problem by limiting the number of dice rolls available to each block producer. This fundamentally limits the additional energy requirements needed to increase decentralization. Proof-of-stake systems remove the dice rolls entirely, but have to add other systems to ensure security. The additional systems increase the complexity of the algorithm.
Proof-of-burn keeps the core consensus mechanism of proof-of-work, but exchanges energy for time.
Proof-of-burn forces block producers to trade liquidity for the privilege of producing blocks by requiring them to burn their tokens. This is all great, however, actually implementing the randomness is easier said than done. Randomness in computing is difficult and it is even harder in a decentralized system. If the randomness is not done correctly, then it can devolve back into proof-of-work, defeating the entire motivation behind proof-of-burn. This can happen if the seed for the random number generator can be manipulated. If it can, then there is a leak and the leak needs to be plugged.
Verifiable Randomness Function
The “plug” we’re using is called a “Verifiable Randomness Function.”
VRFs help us plug randomness leaks and prevent manipulation. A VRF takes an ECDSA private key (like the ones used in Koinos) and an input message and generates a random number along with a cryptographic proof so that anyone can verify the result.
We need to look at both inputs to the VRF for leaks. The private key can easily be changed, but is now a different account. So long as different accounts are treated differently, which is trivial, this is not a problem. Proof-of-burn solves this by modifying a user’s result by the value of their burned tokens.
The other input to a VRF is the message. The message must be deterministically create via consensus in order to prevent leaks so in Koinos’ proof-of-burn, the message consists of two parts, a time quantum and a random seed. The time quantum will correspond to the block time and allow for continuous block production. By limiting the number of quantum per second, we limit the number of rolls. This is not a leak, but the only intended source of entropy in the system.
The random seed is the last remaining piece of the puzzle, but the solution is elegantly simple. It is the hash of the previous output of the VRF! The security of this system stems from an important property of VRFs; their secrecy. Without knowing the user’s private key you cannot know the outcome of another’s rolls, so when you get a good roll, you are highly incentivized to use the roll. If you don’t, you risk someone else rolling first and beating you.
Burn v. Work
Dividing the hash by the size of the producer’s burn is also what guarantees that the absolutely dominant determining factor in selecting a block producer is the size of their burn and not the amount of computational work they have performed (which will be practically nothing) thereby delivering on the promise of high efficiency.
The end result of this system is that proof-of-burn incentivizes people to perform as little work as possible (and burn as much KOIN as possible) to generate a random outcome because performing any additional work will not increase their chances of producing a block nor interfere with network performance. The only outcome would be a decrease in their profit margins.
Because the VRF is critical to Koinos consensus, it will be producing a random seed every block that can also be used by dApps, thereby giving Koinos developers a turnkey solution to the problem of injecting randomness into their application!
Last week community developer Roamin hosted a livestream on Discord demonstrating how to build a smart contract on Koinos in AssemblyScript. There is a simple tutorial blog post here. The livestream dove a little deeper to explain the CLI and the files that are generated. Roamin also demonstrates how to build the smart contract and deploy it to the Koinos testnet. The recording is on our YouTube.
Koinos DEXs Join Forces
The developer of KoinoSwap announced they were joining forces with the Koindx team to build the best DEX possible!
Developers, Developers, Developers
As you can see, now is the perfect time for developers to begin building their Koinos applications. So tell every entrepreneur and entrepreneurial developer about the Koinos Labs program and that now is the time to start building on Koinos, otherwise they risk missing out on the biggest opportunity since the release of Ethereum!
If you or someone you know is considering building a blockchain-based app but needs help, don’t hesitate to send them to koinos.group where they can book a free consultation with our team.
We’re here to help as many people as possible build insanely great applications and accelerate decentralization through accessibility!