There’s a lot of exciting things going on in the lead up to the snapshot on October 31st (or later), far too much to cover in one post, but I’ll do my best. Performance of the test net remains excellent having now surpassed its 1.5 millionth block! That means the snapshot is on track and the main net will be launching soon after. In a previous update we had said that there would be at least a month between the snapshot and the main net launch, but we don’t see the need for such a long window.   

The reason for this high degree of confidence is that we have yet to find an issue with Harbinger V4 that would have prevented it from being released as main net! In other words, V4 could have been main net! That’s why we see no technical barriers to releasing main net very soon after the snapshot.

While no consensus changes have been required, we’ve been hard at work improving Koinos to ensure that the main net is as stable and performant as possible. We focused a lot on improving the stability of the p2p microservice and made some minor upgrades to several system contracts, specifically the proof-of-burn, KOIN, resource, and VHP contracts. I say minor because the changes were fairly small, and due to the incredible upgradeability of Koinos, we were able to upgrade the contracts without a hard fork. On any other chain, these changes would have required a hard fork, but on Koinos most people probably didn’t even realize the changes were made :).

With all of these improvements in place, rockstar community developer, Roamin, decided the time was right to throw as many transactions as possible at Koinos, and as you can see in the image below, the blockchain is performing quite well! If you’d like to test Koinos yourself, you can use Roamin’s firehose tool.

As you can see from the image (taken from the amazing block explorer koinosblocks.com by Engrave), Koinos is capable of consistently processing over 450 transactions in a block which, with 3 second block times, puts it right up there with the real performance of any high performance blockchain! But remember, Koinos is not optimized for performance … 

While Koinos is already clearly deserving of the “high performance” title, what really sets it apart from other blockchains is its ability to evolve; its ability to improve at a far more rapid rate than any other blockchain in existence. 

That ability to evolve is dependent on a decentralized governance system functioning, which is why it was so important that we run a governance test. Blockchain Architect, Nathaniel Caldwell, created a simple contract with an implementation that would then be overridden with a new implementation if it acquired sufficient votes through governance. Our amazing community of volunteer block producers cast enough votes for the upgrade to pass, and the upgrade was ultimately applied! While the upgrade was ultimately meaningless, what mattered was that the governance system performed successfully, and exactly as expected!

The beauty of Koinos is that we can defer development of a lot of great features until after main net because the protocol is so insanely upgradeable. One of those features we were planning to do post-main net launch was a naming service (think ENS but on Koinos). However, community developer, Luke Willis (developer of Burn Koin), recently highlighted why this is such an important feature for both dApp developers and blockchain developers in the Koinos discord server. 

In short, on Koinos everything is a smart contract and smart contracts “live” inside addresses which are long strings of letters and numbers, i.e. they’re not “human-readable.” Even the “operating system” is made up of smart contract modules that communicate with one another via their addresses to deliver the behaviors we want to see. For example, the proof-of-burn contract, VHP contract, and KOIN contract all work together to incentivize the behaviors needed to form a decentralized network. Not only do these contracts call one another, but many dApps (user smart contracts) call them as well, like the burnkoin.com dApp by Luke and Kui. 

Koinos is designed for the system to evolve, meaning that the system contracts are meant to be upgraded which can result in their addresses changing. Since contracts are connected by their addresses, any time one address changes, then every contract connected to it needs to be upgraded with the new address. 

Our solution is a simple “name service system contract” which maps names (like “KOIN”) to addresses. For example, this would allow other contracts to reference “KOIN,” instead of an address that would change after an upgrade. Now, an upgrade of the KOIN contract would just include an update to the name service contract and that’s it. The address “behind” the KOIN name would change, but since every other contract is calling out to KOIN (and not the address) they will continue to perform as intended, whether it’s a system contract or a user contract (dApp). 

This change will make upgrading the Koinos system contracts far more simple, but more importantly it will make things a LOT easier for dApp developers … 

This name service contract won’t be an exact analogy to Ethereum’s Naming Service (ENS) because it is part of the “operating system” of Koinos, whereas ENS is a strictly user (i.e. developer) facing solution. However, this system would be a great foundation for a user contract name service.

This highlights the unparalleled composability of Koinos. The name service system contract is all about improving the operating system of Koinos. However, because the name service will be written as a smart contract, any developer looking to implement a more “ENS-style” service on Koinos can simply copy that contract (written by the very inventors of Koinos) and then add the little bit of code needed to deliver the additional functionality needed. 

The number of amazing dApps on Koinos continues to increase. Of particular note are; Burn KOIN, The Dice, Koinos Blocks, Koinos Node, and Julian’s amazing token claiming app which can now be found at claim.koinos.io. 

Burn KOIN is a hybrid between a mining pool and a staking pool (like how proof-of-burn is a hybrid between PoW and PoS). It allows people to earn a stable yield without having to produce blocks themselves. Instead, they burn their KOIN and contribute their VHP to the pool contract which produces blocks and distributes the rewards in a totally decentralized manner to the users of the pool. This makes Koinos even more accessible. https://koinos-burn-pool-ui.vercel.app/

The Dice game demonstrates how dApps can use the VRF (verifiable random function) built into Koinos to leverage randomness inside of applications. Injecting randomness into dApps is exceptionally difficult, but this dApp demonstrates how the Koinos VRF makes this much easier, and provides a template for future dApp developers who need randomness, for example, game developers. https://dice-app-roamin.vercel.app/

Finally, the main net token claiming dApp is something we would have had to develop ourselves which would have meant spending less time on improving Koinos. It’s work like this, the Kondor Wallet (also by Julian), the AssemblyScript SDK by Roamin, and more that has enabled us to accomplish so much with so few resources and is why a section has been added to koinos.io to give credit to the amazing community developers who were absolutely critical to getting us where we are today. 

There’s also a lot going on behind the scenes which we look forward to sharing with you in future updates, so be sure to follow the project on Medium and Twitter.