Koinos Blockchain v0.3.0 Released: Fee-Less Blockchain Enters The Fray

I’m Andrew Levine, the CEO of Koinos Group, and we are very excited to announce the release of v0.3.0 of Koinos, a/k/a testnet V3! V3 is the culmination of nearly 2 years of hard work by the blockchain engineering team to complete the first truly fee-less blockchain framework with infinite upgradeability and universal programming language support built atop a microservice architecture.

Fee-less Blockchain Ecosystem

The Koinos blockchain framework (KBF) is the core technology that will serve as the foundation for an entire ecosystem of fee-less and infinitely upgradeable public, private, and hybrid blockchains.

Thanks to its modular upgradeability, any blockchain built on the KBF will be able to improve itself at a far more rapid rate than any other blockchain out there, allowing them to iterate to greatness!

We will demonstrate this capability on V3 by replacing the proof of work consensus algorithm with proof of burn and then adding a governance system all without ever disrupting the operation of the blockchain! In this way the V3 will evolve into the ultimate layer 1; Koinos main net.

The Journey

The KBF is designed to be the most simple blockchain imaginable, containing primarily the cryptographic primitives necessary to construct a blockchain and the right “system calls” that allows for the widest range of behaviors to be added in-band (without a hard fork) through the uploading of a smart contract.

The benefit of this design is infinite upgradeability, but the cost is that it makes getting the system calls right all the more important. Missing a system call or designing it incorrectly would mean having to deal with an otherwise avoidable hard fork.

This is what made versions 1 and 2 of the test net so important; they helped us understand what system calls were necessary, and which were not.

It has been a grueling journey, but we are now confident that we have the right system calls, microservices, and overall architecture in place and properly functioning which means that Koinos blockchains like mainnet will be free to rapidly adapt to the ever-changing needs of developers and their end-users!

DApp Developers

In short, V3 marks the completion of the Koinos blockchain, which means smart contracts that work on V3 will also work on mainnet so dApp developers can now dive head-first into building their Koinos dApps knowing that no breaking changes should be made to the blockchain from here on!

Harbinger

What makes V3 special is not that it has some flashy new features, but that it has everything necessary to evolve into the main net. This might sound abstract, but it has very real consequences.

Even though Koinos does not yet have the final versions of its consensus algorithm or governance system, because nothing in the blockchain will be changing after V3, this marks the beginning of the testing period (“soak time”) for the main net!

For these reasons, we will now be referring to the Koinos testnet as … HARBINGER.

Run Harbinger

View the docs

View the release notes

Payer/Payee Semantics

Koinos is all about accelerating decentralization through accessibility which means supporting the free-to-use experiences people have come to expect from their applications. V3 now contains the flexibility necessary to allow smart contract developers to specify whether they, or someone else, will provide the mana being consumed by a user.

These deceptively simple semantics will not only allow people to begin using the blockchain without having to buy any KOIN, but it will give large KOIN holders a powerful tool for deploying their capital without sacrificing any of their tokens.

Each transaction must explicitly specify an address of a payer for the transaction, and optionally a payee. The payer’s mana is spent and the payee’s account nonce is updated. If there is no payee set, the payer is used for both. The combination of these features allows a smart contract to specify a payer for its mana costs.

New System Calls

The key to Koinos is the system calls and we have added 3 new system calls that allow for some very powerful use cases. Those calls are: get_transaction, get_transaction_field, and get_block_field.

Get_transaction_field simplifies the framework by replacing get_transaction_payer, get_transaction_signature_ and

get_transaction_rc_limit

Get_transaction_field

get_block_field

However, a contract may be interested in the entire transaction or block, and the overhead of calling the system multiple times is too much. This is where `get_transaction` and `get_block` are useful.

Koinos Authority System

Koinos V3 now has the most flexible authority system of any blockchain! The authority system allows smart contracts to override the default authority (a single private key mapping to the address).

Once overridden, the user’s contract will be called on a special entry point when authorizing from a contract, using mana (or “rc” in the case of the Koinos Blockchain Framework), and/or uploading a contract. It’s a simple and elegant solution that maximizes developer freedom with respect to how they implement authorities.

This gives users (primarily dApp developers) full control and customizability of exactly how they want to secure their account now, and into the future.

Quantum Resistance and Bridges

We have also generalized the DSA (digital signature algorithm) related system calls. Currently, only secp256k1 is supported, but the calls are designed for new algorithms to be added later; first upgraded in-band as smart contracts, but later optimized via hard fork with native implementations. The combination of features means that Koinos is prepared for the future of cryptography and allows users to upgrade as they see fit.

Another DSA that might prove incredibly valuable in the future are Boneh–Lynn–Shacham signatures (“BLS”). These cryptographic signature schemes allow users to verify that a signer is authentic which is useful in inter-blockchain bridges.

Stack Management

In Koinos-based blockchains, basically, everything is happening in smart contracts either in user smart contracts (“dApps”) or “system contracts.” System smart contracts contain the behaviors we want from the blockchain (”L1”) like consensus, governance, and resource management.

In other words, you have different kinds of smart contracts, with different privileges, interacting with one another and with the blockchain. There were a number of subtle bugs with V2 of the testnet that have been fixed through simplification of the implementation along with a comprehensive test suite of this crucial aspect of the framework.

Extend Genesis Data Capabilities

Koinos mainnet will launch using a snapshot of the KOIN ERC-20 to set the initial balances on the new blockchain. This means that the moment the blockchain is “born” (or “at genesis”) the blockchain needs a way of knowing about the snapshot.

Instead of simply trying to figure out how to add the snapshot to genesis (which would only help us), we developed a more general solution that would allow a blockchain engineer to launch a Koinos-based chain with ANY kind of data added to its database at genesis. If you’re a developer interested in learning more about how this was done, you can view the story here.

Handle Failed Transactions

We addressed a number of issues that were causing a node to “brick.” We wanted to make sure that no matter what transaction was sent to a node it would remain functional, or in the worst-case scenario at least be recoverable.

Events and Receipts

Events are a new communication primitive that changes how pieces of software (like microservices) can interact with smart contracts. Events are intended as machine-readable messages that are pushed from a smart contract.

Any smart contract can create an event through the event system call and events are returned in block and transaction receipts. Furthermore, events are also broadcast over AMQP (the message queueing protocol that organizes messages within a node) so that custom microservices can react to specific events from smart contracts.

Events are sent over MQ

`koinos.event.${SMART_CONTRACT_ADDRESS}.${EVENT_NAME}`

This allows for the creation of microservices that listen for any kind of event a dApp developer can create, but two obvious examples are token minting and transferring events.

State Verifiability

Byzantine Fault Tolerance is an important feature of a blockchain and that’s precisely what the state verifiability work accomplished!

Byzantine Fault Tolerance is accomplished when a blockchain user can verify that any changes to the ledger (or “state”) made by their node are “in consensus” with every other node on the network. Ethereum does this by referencing the entire blockchain state in its “state root” which requires storing data in a patricia trie data structure, which is not how Koinos stores data.

The database primitive Koinos uses is called a “state delta.” Instead of storing old values of objects (“undo states” which are used in Bitcoin, Steem, and EOS), Koinos stores new values of objects, and projects those new values across multiple undo states (state nodes in StateDB vernacular) to present the consensus state at a given block.

Long term, the deltas are blocks. Short term, they are transactions. In order to verify the state we can calculate a merkle root of only the database writes of the block (and not the entire state like Ethereum) which represent the state transition for the block and which can be verified by all nodes.

Algorithmically, this is more efficient with a complexity of O(nlogn) < O(nlogm). And cryptographically speaking, a full state root could still be calculated from the proof of the state transition root.

Run Harbinger

View the docs

View the release notes

Developers, Developers, Developers

With the blockchain framework finalized, now is the perfect time for developers to begin working on their Koinos dApps so that they can be ready to go live on mainnet which is now our next major milestone!

If you’re a developer or entrepreneur interested in building on Koinos you can connect with us on the Koinos discord server, telegram channel, or by e-mailing [email protected].

As always, thank you for being a part of the Koinos community and helping to accelerate decentralization through accessibility!

Andrew Levine, CEO of Koinos Group