Abstract: Byteball is a new kind of crypto currency platform based upon a Directed Acyclic Graph. Byteball can handle simple transfers of value but also smart contracts, Oracle, P2P payment in chat, ICO bot and is being developed by its founder Anton Churyumov. There are many good things and nice features in Byteball. Although being a quite impressive amount of work, intelligence and innovation, honestly delivered from a single man, the project does suffer some design flaws when we look at how it does (not) decentralize. Those flaws should be addressed to get a fully decentralized and resilient platform or it will not turn mainstream. In this paper we will suggest ideas for improving Byteball or, should the changes being too disruptive, start thinking about new platform based upon a Byteball code evolution. These ideas are very much open to discussion.

Introduction:

There are several problems in the Byteball project design that should be addressed in order to get a fully distributed resilient platform.

Hubs and network resilience: in Byteball only hubs hold the data and share it with all others devices (others hubs, full wallets and light wallets). Hubs bear fiat hosting cost and are not rewarded in the protocol under the current implementation. We will propose a mechanism to reward hub to counterbalance their fiat cost and turn running a hub into a profitable business.

Witnesses: in Byteball 12 witnesses, supposed to be ‘reputable users with real-world identities’ guarantee there is no double spent. We do not believe that any real world identity (well known person or billion dollars company) is willing to risk his mainstream reputation to guarantee the proper functioning of an independent computer code platform. We will propose to switch to a Proof of Stake witnesses mechanism.

Fee structure: the fee structure is not pertinent and should reward all actors that participate in the network health (hubs and witnesses). We will propose to amend the fee structure.

Spam: as shown in an earlier paper the fee are not high enough to prevent the network being attacked and DOSed by a single wallet. We will propose a mechanism to prevent the spamming of the network.

Distribution: the distribution method should be set in the stone of the code and benefit to those that run the network. Decentralization concerns start as soon as you look at the distribution scheme. It must be ruled from within the code so that the rule is known from the beginning and does not vary. As for Bitcoin we will propose a distribution based upon time regression but at no effort to encourage early and broad adoption.

1 — Hubs and network resilience:

The network resilience relies ONLY upon hubs. One would think the protocol should impel to run a hub. It is not.

In Byteball several kind of devices coexist, hubs, witnesses, light wallets, full wallets and relays. Looking at the technical background hubs are full wallets with a layer of service that allows others wallets (light and full) to connect to the network (they also handle the chat messaging services). The main important thing is: only hubs hold the data and share it with the others devices.

Light wallets do not hold the database, full wallets and witnesses do hold it but only for their own selfish behaviour and do not listen for incoming connections (they do not share the data with others devices). Relays are supposed to hold and share the data but, although the code has been implemented to run a relay, nobody has ever ran one.

As a result data security, redundancy, and availability relies on hubs only.

However, under the current implementation, there is no impel running a hub, no reward at all. Worst than that, it is being repulsive running a hub to the long term being understood that the hub operators are bearing all operational cost in fiat money with no counterpart at all (no reward out of tx fees) from the network end users.

We propose a change in the fee structure. Hubs would advertise a service commission amount they require to handle a transaction. Wallets would automatically switch to the cheapest hub or have their favorite hub whatever the fee (depend the quality of service they require and if they require a stable messaging service). Thus we create a true market with supply and demand. As any market it will reach an equilibrium where hub operators will get their fiat expenses compensated by their commission amount or the network will die. If the fiat cost to run a hub gets balanced — and beyond — by the service commission charged to end users, running a hub may become a profitable business, having in mind that the competition among all hubs operators guarantees that the hubs commissions do not rocket to the moon. If the hubs can not recoup their fiat cost, it would just mean that the network deserves to die (and it would) because the service rendered to all end users at the whole network level does not pay enough for the whole network fiat cost (I do not believe it will).

First proposal: a fair fee market among hubs, protocol embedded, for an healthy distributed network.

2- Witnesses:

From reputed users to anonymous Proof of Stake witnesses

Witnesses are supposed to “have a lot to lose (material and/or nonmaterial) in case of misbehavior. The loss is your business (outside Byteball) and/or reputation”. As told in the forewords, except main dev, we do not believe any real world entity (either well known person or a billion dollars company) is willing to risk its mainstream reputation to guarantee the functioning of an independent computer code platform. Why would they take such risk? Because they use the platform? At least they should, but is it a reason to gamble their others pre-existing mainstream incomes by running the risk of their real world reputation just on the platform (think about an exchange such as Bittrex for example, why would they challenge their reputation at a whole for a single coin)? Anything else? To earn witnessing fees? We are talking about small commissions, and anyway, do we want greedy witnesses? At least the code should be peer reviewed. Anything on the map for a peer review or a challenge bounty program?

We propose to switch from “well reputed users having a lot to lose” to anonymous Proof of Stake witnesses. Being understood that witnesses do not perform any specific operation (they do not validate nothing, they just post serially in the background), a pool of witnesses candidate is now established by looking at the top x funded full wallets posting in the background. Among those x automatic witnesses candidates the top y are chosen as effective witnesses. We get rid of the witnesses choices by end users, real world reputation, the useless voting system, the centralized default list and the +1 mutation rule which is not functional for decentralization. Our goal is to achieve immediate and true decentralization. All wallets have the same witnesses list which is dynamically adjusted function of the most funded full wallets being alive.

An attacker should hold more than the cumulative value of the y/2 top funded witnesses to cheat the network. Top funded wallet are motivated to become witnesses to secure their funds and get witnessing commission (we do love greedy witnesses now).

Hubs, as any full wallet, can be witnesses now (and it is likely they will). We have no more specific entity for witnesses and we have achieved decentralization.

Second proposal: move to anonymous Proof of Stake witnesses.

3 — Fee structure:

No more header fee. Hubs handling fee and witnesses fee.

Both the fee structure and fee price in Byteball have no real counterpart in the reality and do not reward those who maintain the network health. From the Byteball white paper “… everyone is allowed to add a new unit provided that he signs it and pays a fee equal to the size of added data in bytes”. There is no real point to link the size of the computer bytes data weight of a transaction and the same amount of Bytes as a currency to pay to the network. Also we have seen above that the only devices storing and sharing the computer bytes, the hubs who bear the “load” of the DAG, are doing such service at the expense of their own fiat money and that they do no receive any portion of the Bytes fee (currency speaking now) in return. Computer bytes and Bytes-as-a-currency value are fully disconnected from real fiat costs and those who maintain the network health are not rewarded.

Matter of facts end users do not pay their Bytes to the right devices and arbitrary saying that the load equivalent of each transaction in bytes is the only price to be paid for an immutable and forever storage is not pertinent.

Let those who carry the load and those who pay for it decide the price in a free market (we introduced in proposal N°1 the suggestion that hubs would advertise a service commission amount they require to handle a transaction). Under the current implementation the network is externalizing its operational costs to the hub operators (as a car manufacturer externalize the cost of the pollution to the planet) and they do not receive nothing in return, this is not sustainable to the long term in a decentralized network

Now the free structure itself:

From the WP: “The commission is split into two parts: headers commission and payload commission. Payload commission is equal to the size of messages; headers commission is the size of everything else. The two types of commissions are distributed differently.”

The tx fees are split in two. The payload fee and the header fee. The payload fee is proportional to the size of the post (the computer bytes data load of the tx) and goes to the witnesses. There is a misleading representation in the fee structure of the witnesses effective role. First of all, witnesses are seen as immaculate reputed persons from the real world, however the protocol rewards their honesty at a price superior at their cost. If Byteball is so mainstream for the witnesses that they are willing to risk their real world reputation, why is the protocol motivating them by profit perspective? Second question: why should the witnesses be rewarded proportionally to the load? There is a true misleading view here. A heavy unit does not “cost” more to a witness than a light one, it is just the same cost. Remember that the witnesses do not perform any special operation, they do not validate nothing, no Proof of Work here. They just post serially in the background, that’s all. The witnesses should be able to recoup their cost, no more. A witness post costs 600 Bytes and should be rewarded 600 Bytes. But, as told above, we do not believe in this view of witnesses from the outside world anyway.

Now the header commission. The header commission goes to the daughter unit (the unit which comes after yours on the DAG). The header commission motivates the selection of the most recent units as best parent to keep the DAG narrow. Most of the users do not even realize they get commission on their unit and the commission is so low that it has no real meaning or appeal anyway. A hard coded function based on some weight per most recent unit would do the same.

We propose to suppress the header fee and to replace the header commission mechanism by a hard coded function to keep the DAG narrow. Although being disconnected from any technical reality, we keep the witnessing fee in an intentional purpose to motivate top funded wallets being live 24h a day (we do love greedy witnesses now) thus becoming our proof of stake witnesses pool.

Third proposal: amend the fee structure by removing the header fee and introduce a hub service fee.

4 -Spam and DOS:

Secure funds if you want to post.

As shown in an earlier paper the tx fees are not high enough compared with the total Bytes “money supply” to prevent the network being attacked and DOSed by a single wallet. There are so many Bytes in circulation that, even if 1 GByte would cost $1 billion, some users already having Tera Bytes in pocket could afford to DOS the network at no relative cost. The price of the GByte on the fiat market is not — and will never be — a protection against DOS or spam.

We have to find a decentralized consensus to prevent DOSing, being understood that the level of fee is now handled by the “hubs handling fee market” and that we can not manipulate that market (it is ruled supply and demand).

We can easily have as a pertinent figure being the number of not yet stable units a wallet has on the DAG, an other figure being also the total of not yet stable units on the DAG.

Again, let’s call for help a Proof of Stake mechanism. The idea would be that any full wallet (hub included) willing to post to the DAG would have to secure previously a certain amount of Bytes on a smart contract. The “amount” of a non confirmed post to the DAG would grow exponentially against the contract.

Example: a full wallet has secured in a smart contract 1,500 Byte of “right of posting”. The wallet owners decides the smart contract is in force between main chain index 100 and main chain index 110.

After MCI 110 the wallet owner is not allowed to post anymore but he can claim its 1,500 Bytes back. Before MCI 100 the wallet owner can not post.

Between MCI 100 and 110 the wallet owner can have non stable units at the price of 10exp x Bytes against the contract where x is the number of his non stable posts. As a result, with such contract, he can have no more than 3 unconfirmed posts to the DAG at the same time between mci 100 and mci 110 because 1x10exp1 + 1x10exp2 + 1x10exp3 = 1,110 Bytes < 1,500 Bytes (this is just an example, the 10expn function being to explosive as a matter of fact for an effective implementation).

We can also globalize the function at the whole network level by introducing the total amount of unconfirmed units (y) to reach a global consensus function.

RequiredPoS(x,y) = ExpFuncMyUnstable(x)+ExpFuncGlobalUnstable(y)

A wallet (or a hub) may have several contracts into force at the same time to adjust its posting power. Of course a major player would secure many GBytes at once up to a main chain unit very much far away in the future, that is to say high on main chain (an interesting ancillary benefit of this anti-spam policy is that we can get a measure of how much a device is involved in the network and how long it projects itself in the future).

At the end of each contract the wallet owner can claim back the secured funds.

With such mechanism, even a TBytes wallet could not flood the network anymore and we can keep a free market for effective transaction fees.

Fourth proposal: implement an anti-spam mechanism.

5 — Distribution

The distribution should benefit to those that run the network and be set in the stone of the code.

The distribution method should be set in the stone of the code. Decentralization concerns start as soon as you look at the distribution scheme. As for Bitcoin we propose a distribution model based upon a regressive amount over the time. The proposed distribution scheme is aimed at encouraging skilled early adopters and then switch to a “no effort model” to encourage a large base of end users.

After an initial period where we encourage only specific devices to emerge, all devices being up at some defined main chain levels would receive an equal portion of the currency supply at no effort. The distributed portion is decreasing with the time (main chain index).

In others words, to bootstrap the network we start reward hubs and full wallets only and, at some pre-defined point on the main chain, we start rewarding light wallets too.

Let see how all that should evolve. At the beginning we need hubs and full wallets (bots and end users) so we reserve the distribution to hubs and full wallets. Greedy early adopters set up as many hubs and full wallets as possible.

Once the network has been boostraped and the hubs are rich enough to secure funds to the anti-spam mechanism we start rewarding light wallets too in order to grow quickly our user base.

From that point newcomers runs mainly light wallets (easier, no hosting cost, rewarded the same than all other devices) and get distributed coins at no effort. Some end users still decide to run a hub or a full wallet because they need it (a bot for example).

Light wallets connect to the hubs, therefore the “hubs fee market” starts to emerge and the hubs are getting handling fees on top of their own distribution reward. Some early adopters move their coins to a light wallet and turn down their initial hub/full wallet.

As the time goes the network concentrates to fewer hubs, some full wallets (mainly bot wallets) an a lot of light wallets.

The reward has decreased, as hubs are mainly from very early adopter they are rich enough to be stable and strong witnesses and they earn money from their handling fee so they can provide a good service to the light wallets. The market laws ensure that the hubs handling fees do not rocket to the moon. Our user base it quite large to the form of many light wallets.

We have reached an equilibrium and a healthy network.

Fifth proposal: set the distribution rule in the stone of the code.

Conclusion:

We have discussed what we consider some design flaws in Byteball when we look at decentralization, but the whole of the tech is honestly there, quite functional, and has very much interesting features. We have proposed some ideas to address those flaws. The chapter regarding the distribution has been written in the mind of bootstrapping a brand new network but it could be regarded with the current distribution concern since 40% of the GBytes are still to be distributed as we speak and early adopters are already in. “Distribution at no effort” was done to Bitcoin holders, why not distribute to wallet owner on a timely manner to spread the coin? From now the distribution shall be set in the stone of the code. Some of the others ideas may be seen unrealistic, too difficult to implement or too disruptive. It is essential to get a free market for the hubs and get rid of the arbitrary fee structure.

Of course there is way much work from ideas on a paper to a functional code implementation. This paper is only intended as an open base for further discussion in a collaborative effort to improve the existing or fork to a new.

A non decentralized platform is unlikely to become mainstream when your name is not Google, Apple, Facebook, or Amazon and when many others skilled competitors play the same game around you.

2018–02–25

Did you find this article useful? Consider an anonymous donation by throwing:

a few GBytes at VXPRGNFBEWXTA7LH7CB23TIDP2NXO3AZ

or a few BTCs at 1292iSvBFXMHWbEdjCZyMMBcgufRLj9NEp

or a few BCHs at qqx8ecnlfzcpzjht7k5hkld6kj3242cwwg2tjf22qz

or a few ETHs at 0x5b5963a4F62CED34cBE22Ab85fAa1DB1FaCE2665

Thank you!