Author: Ricardo Geraldes

The Kowala development team has been hard at work building Kowala’s core features and functionalities, and today’s update will provide more information regarding some of the features the development team is working on over the last few weeks.

For those readers who have not followed our project up until this point, Kowala has become the very first algorithmic stablecoin to win public platform support from Ledger to use their hardware wallets and whose flagship project is a dual-token blockchain that relies on a combination of algorithms, oracles and smart contracts to maintain price equilibrium. Additionally, the team is working towards cryptocurrency mass adoption by focusing on technology capable of providing extremely cheap transactions and very fast payment confirmations (~1 second) by using a different class of consensus protocols, proof-of-stake, and by modelling our product after day-to-day banking products/processes which are familiar to most users.

Team Member Spotlight

· Adrian Hetman joined as Smart Contract Developer. Adrian is passionate about Ethereum technology and blockchain in general. Adrian started learning about Bitcoin in 2015 and immediately saw its incredible potential. Adrian likes to share his blockchain knowledge with others, has written articles and spoken recently in Poznań, Poland. Currently working on a client tool to update the network core contracts (#810).

Features

It’s been yet another busy month and our team has continued their focus on Kowala core features and functionalities. These include:

· Fixed Compute Fee (#740)

- Makes it possible for users to know upfront the fee required to submit a simple transaction.

- The team has decided to remove the “gas” concept from Ethereum since it’s confusing for the average

person (here’s what that term means if you’re not familiar with it:

https://ethereum.stackexchange.com/questions/3/what-is-meant-by-the-term-gas)

- Now simple kCoin transfers do not require any gas related information.

- Kowala does not support transaction prioritization — first come, first served.

Note that this feature could open room for spam attacks (network congestion) — A faster kUSD network amplifies this expense for the attacker because we expect the network can accommodate thousands of transactions per second, raising the bar for the amount of spam required to attack and thereby raising the expense by several hundred fold for the attacker.

· Authenticated Data Feed System — Oracle Service (#627)

The end goal of Kowala’s authenticated data feed system is to incentivize network oracles to provide the exchange prices in a decentralized and timely manner in order to keep the price feed reliable in return of rewards. In the previous month, we’ve completed the oracle service implementation which includes the Intel SGX implementation, the service implementation and a contract that serves as the oracle registry. This item is pending further tests and reviews (+60000 lines of code).

· Stability Fee (#764)

The transaction fee includes an additional amount called stability fee whose purpose is to raise the price of kUSD by reducing the coin supply when the price of kUSD is below $1. In the previous weeks, we have completed the first implementation of the stability fee.

Additionally, the team is working on several items that will improve the overall development experience such as improving the debugging process/test coverage/test infrastructure.

· Automatic client updates (#377)

Keeping mining clients up to date is a significant challenge any cryptocurrency network. While we don’t want to centralise the software or tell anyone what clients they must run, we have created a reliable method of updating client software. This allows us (or anyone else) to publish new versions of the client and let the users update quickly and easily, if they choose to.

Research

· P2P Layer (#827)

Figure 1 — Publisher/Subscriber model

The team has been using Ethereum’s DEVp2p (network overlay) for some time now but we got to a point it does not suit our use cases: we want to able to jump in and out of the miner pool extremely fast as well as limit certain messages to certain services without increasing the implementation complexity.

With DEVp2p it takes a long time to connect to the miner’s overlay network which is an issue given the need to rate peers based on their availability. Participating in several protocols at the same time is also quite costly bandwidth-wise and the implementation is usually more complex.

We’ve started the process of implementing the p2p layer with libp2p framework using their pubsub libraries. Libp2p is a modular and extensible networking stack which solves many challenges of peer-to-peer applications and it’s actively maintained. The Ethereum team is also exploring the same problem for their proof-of-stake/sharding solution.

Figure 2 — PubSub System (Sharding)

The planned architecture is similar to the present blockchain sharding solution: every node subscribes to a global channel that is used as a link to sync the blockchain state and the miners subscribe to messages whose topic corresponds to their overlay network (beacon chain — sharding spec).

Stress Testing

Until we complete stress testing, we will not have certainty about the exact maximum capacity of the network, how many validators can be supported simultaneously while retaining a fast block time, and how many transactions per second can be processed over a sustained period.

Tendermint, the original model for kCoin’s Konsensus, was able to demonstrate a high throughput of transactions with 64 validators while keeping a minimal block time. While it’s tempting to assume our system will be equally performant, it’s not a perfect comparison because our use case is quite different, and the underlying Ethereum code is considerably more complex than the Tendermint application.

To get specific answers for these questions, we’re designing a sandbox network which we can expand and monitor in both size and transaction throughput until the system reaches maximum capacity. This network is very nearly ready, and tests will begin soon.

Whitepaper

The stability rewards mechanism (NOTE, this is distinct from Stability Fees, which are outlined in section “Stability Mechanism 2: Stability Fee” of the v2.0.22 whitepaper) has been removed. The burn amount is now the sum of the stability fee given a set of transactions included in block b — previously, the burn amount was just half of this. As a result, the price equilibrium happens much faster then before. Instead of splitting the stability fees between burning and rewards, we now use burning only. We believe this approach is easier to understand and test. This change will be reflected in the next version of the whitepaper to be published imminently.

Figure 3 — Burn amount formula

Events

Kowala dev team members will attend the Malta Blockchain Summit — Devs & Technology Conference — on the 2nd of November.

Join our Community

Kowala is an open source project. If you feel you can help us grow our community in other ways, we’d love to hear your ideas. Visit us at Telegram and get in touch. You can also tweet at us, like our facebook or subscribe to the Kowala sub-Reddit.

Telegram: https://t.me/kowalaofficial

Twitter: https://twitter.com/kowalaTech

Reddit: https://www.reddit.com/r/Kowalaofficial/

Facebook: https://www.facebook.com/kowalatech/

Medium: https://medium.com/@kowala

References

1. POC of Ethereum sharding p2p layer on a pubsub system in libp2p

2. libp2p