Koinos Update: Enhanced Proof of Burn
I’m Andrew Levine, CEO of Koinos Group, the creators of Koinos and in this update I’ll be focusing on important changes we are making to proof of burn! But first, a brief update on Harbinger (the Koinos testnet).
Two weeks ago we released the 3rd version of the testnet which has been performing flawlessly. We have yet to uncover a single bug in the blockchain framework. This is all the more impressive since we have more participation in the testnet than ever before. There are more people running nodes and more people testing smart contracts, thanks in large part to the awesome AssemblyScript SDK created by Roamin (a community developer). One user even tried blasting the blockchain with as many transactions as they could (“firehosing”) which is a fantastic stress test. The network handled the load flawlessly and the initial performance results that could be gleaned from this test are very promising.
Most importantly, the stability of the testnet has allowed us to focus almost entirely on planning the remaining work for mainnet, refining our designs, and beginning the work on the necessary system smart contracts.
If you’d like to help test Koinos and begin playing with fee-less smart contracts, you can be running a node and producing blocks in no time by going here.
Enhanced Proof of Burn
Even as we were finalizing the proof of burn whitepaper we were already thinking about how we might improve the algorithm, but before committing to any changes we wanted to 1. Finalize the framework, 2. Solicit as much feedback as possible and 3. Actually begin working on smart contracts to better understand the limitations and potential of the infinitely flexible framework we have created.
The feedback we received from technical advisors and community members like Luke Willis (host of the Koin Press Podcast) validated one direction we had been considering and as we began to work with Koinos smart contracts we discovered that we could significantly improve the design in accordance with the following objectives;
- Conserving blockchain state
- Maximizing liquidity for block producers
- Allowing block producers to exit their positions at will, a huge improvement over PoS
Virtual Hash Power
The key distinction between our new implementation of PoB and the one outlined in our whitepaper is the move from using Non-Fungible Tokens to represent virtual miners, to using Fungible Tokens to represent “Virtual Hash Power.” In addition to maximizing liquidity, replacing NFTs with FTs effectively eliminates the problem of conserving state.
In the new design, when KOIN tokens are burned, the blockchain distributes a fungible token to the block producer that can be used to mine a block. As an account produces blocks and earns block rewards, their virtual hash power (VHP) is reduced. Since VHP decreases over time, block producers must burn more KOIN to get more VHP and continue producing; effectively simulating how PoW miners need to continuously reinvest in new hardware.
This new design makes it simple to ensure that block producers earn a guaranteed return on their burn by fixing the amount of VHP that is gained per KOIN burned, and fixing the amount of KOIN acquired through block production in proportion to their VHP. For example, if the amount of KOIN earned per VHP were fixed at 10% then the block producer who burned 10 KOIN would be guaranteed to get 11 KOIN back. As in the original design, what is not guaranteed is how fast they’d get it back. Depending on how much competition there is, the block producer could get their 10% in a month, or a year.
In proof-of-work, the block producer is effectively “rolling the dice” by performing computationally difficult, but ultimately meaningless computations. In KPoB, the block producer will roll based on some information unique to the block producer combined with their VHP.
Just like in proof-of-work, the more hash power you have, the more likely you are to produce a block. Someone with twice as much VHP as another would, on average, produce twice as many blocks. In this way, the algorithm incentivizes securing the blockchain by replicating the user experience of PoW while still allowing for its intended use-case; efficiently powering decentralized applications.
One of the features we think has great potential is mining pools. On PoW blockchains, mining pools are a threat to decentralization because they incentivize concentrating capital in the hands of those who control the most computing power. Because PoB gives no advantage to those with the more hardware (it actually disincentivizes excess hardware acquisition), this is not a concern.
Instead, we see the potential for mining pools to increase decentralization and participation in governance. We even see opportunities in promoting application development. While running a Koinos node and participating in block production is already incredibly accessible, we see mining pools as a means for non-technical users to allocate their capital to more technical users who can guarantee more uptime and provide a more stable rate of return to those users.
Since mining pool operators won’t be able to compete based on hardware, and the rate of return they will be able to deliver will be fairly limited, mining pool operators will need to compete in other ways. One of the ways they could compete is with their voting preferences. If mining pool operators express which upgrades they would vote for or against, users can contribute to the pools that most accurately reflect their voting preferences thereby maximizing their impact on governance. This adds a representative component to Koinos governance without the addition of any system level code or limitation on the freedom of users to influence governance whatever way they see fit. Since they will be able to remove their VHP from a pool at will, there will be a strong incentive for pool operators to vote appropriately.
Funding DApp Development
Upgradeability & Simplicity
Of course, the upgradeability of Koinos means that no matter our implementation, we can always modify it, or even replace it entirely, without having to restart the testnet (and its soak time). This simpler design should also be faster to implement, so we can get a smart contract up and running on the testnet sooner and begin the process of iterative improvement.
As we begin releasing more details of our mainnet designs, it is important to bear in mind that because of the fundamentally different architecture of Koinos, our objective is never to design the perfect system with all the right bells and whistles (which can never be changed), but to start from the simplest solutions that can be infinitely enhanced through upgradeable smart contracts that aren’t even part of the system.
Now that we are working on smart contracts instead of complicated system design, things are already progressing far more rapidly, so we have a lot more exciting developments that I will do my best to share with you in future updates. So be sure to stay tuned.
Developers, Developers, Developers
Don’t forget that now is the perfect time for developers to begin building their Koinos applications. The best time to launch a dApp to maximize attention and adoption will be with the release of mainnet, and the more great dApps we have at launch, the more valuable the platform will be to new users.
So tell every entrepreneur and entrepreneurial developer 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 come across anyone who 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 that accelerate decentralization through accessibility!