This is part 2 of 4 from a series about Byteball. Part 1 covers the why of Byteball, so if you missed it, read that first and then come back to this one.
Rather watch a video than read a story? Then watch the YouTube link below. If not, just keep on reading.
With Byteball you can make safe contracts that will be executed exactly as agreed upon. Even with total strangers, you don’t have to trust anybody. It works in circumstances where the other methods don’t work. And even if they do work then Byteball is still orders of magnitude cheaper, faster, and more certain.
But don’t just take my word for it, let’s dive a little deeper into the technology that makes it all possible.
Byteball is a distributed ledger without blocks. There are several reasons why getting rid of blocks is worthwhile.
First, if we have blocks and transactions, we have two basic entities in our technical design. Having only one would make it simpler. Simpler is almost always better.
Second, there are too many variables in blockchain design, such as what is the right block size, what is the right time between blocks, and to make it even worse nobody seems to agree which values are right.
Third, and most important, in blockchains there is somebody who creates the blocks, and these entities have the power to decide what gets into the block. I would rather have a system without those kind of gatekeepers.
That’s why we have chosen DAG. In Byteball, transactions are not grouped into blocks, instead they are connected directly: each new transaction references 1 or more previous transactions.
Let’s illustrate this with a picture:
In a DAG you don’t have a theoretical limit on transaction throughput. You don’t have to serialize transactions in blocks, whose size is limited, and put them all on a single lane. In a DAG you can have a bunch of transactions in parallel and the degree of parallelism adapts dynamically to the current load. It’s much more flexible that way.
Another important point: besides not having blocks there is also no PoW. PoW is very expensive and eventually somebody has to pay for that. The cost of this environmental impact will inevitably be priced in, while we want to make the system as affordable as possible. We want the system to produce value for the outside world rather than to help destroy it.
So how does it work then if there are no blocks and no PoW?
On a DAG, once a new transaction is added, it becomes visible to peers…
… those peers can add their child transactions on top of this new one. In a DAG, a new transaction receives some form of recognition from peers very fast!
These child transactions quickly get their own child transactions.
All of those confirmations grow like a snowball.
This explains the ball in byteball.
But these confirmations are only confirmations of existence, not a proof that the transaction is not a doublespend. So we need a way to resolve doublespends.
We already have a partial order in the DAG. So if there are two conflicting transactions and one is reachable from the other through directional parent-child links, we can immediately reject the later one.
But what if there is no partial order between them?
To resolve such conflicts, we need some special users, called witnesses, who are trusted to post their transactions only in order, like this.
But they never post transactions without partial order.
This allows us to order other transactions, even when there is no partial order between them. To be able to do that we draw a special chain through the DAG, called the Main Chain.
This Main Chain gravitates to transactions posted by witnesses, which are always trusted to be in order. The Main Chain is updated every time a new transaction is added.
Then, for each transaction that is not on the Main Chain, you can draw the shortest path that leads to the Main Chain. We call that the position of the transaction on the Main Chain.
Now, if there is a doublespend, the conflicting transaction which appears earlier on the Main Chain is deemed valid and the other is deemed void. However, the void transaction still exists on the DAG but the movements of coins that it attempted to produce are ignored.
So these witnesses are very important for the security of Byteball. Let’s take a closer look:
You can compare Witnesses with checkpointing authorities known from other cryptocurrencies like IOTA or Peercoin. They are basically trusted to select the right version of the transaction history. But while other currencies have only one checkpointing authority, run by the developers I might add, which makes them have a single point of failure, Byteball has 12.
By now you understand how important Witnesses are for the reliable ordering of transactions. So we have to design some rules around them to minimize the chances of failure.
I already talked about how they are trusted to only post serially. Another very important point to raise is that the witnesses are chosen by the community and they can be replaced one by one should they lose their trust somehow. One of the most unique features of Byteball is that when they misbehave they will lose something in the real world, not just in the Byteball economy!
This way we can make sure that the security of the system is supported by value from the real world. Look at it like a security bond. Let’s say you have a successful business in the state of New York selling insurance products, but you are also a Byteball witness. Now if you misbehave in the Byteball economy you will not only lose your reputation there but also lose most of your business in the real world and you could go bankrupt!
A huge benefit of this is that Byteball isn’t dependant on the size of the internal economy.
Of course the witnesses do have something in the internal economy, they earn a portion of the transaction fees, but that is quite insignificant compared to what they stake outside the system, in the real world.
Compare that with what we have in PoW or PoS systems where the incentives and decision making power of block producers are in the internal economy only.
Let’s imagine that we have a native currency and some tokens. The block reward is in the native currency or the staking power is in the native currency. But what if the native currency is cheaper than a token? Or cheaper than the sum of tokens? We will run into some problems then! Such a system will only reliably run within a certain safety range!
Only if the native currency captures the majority of the value such an architecture can be secure. So the utilty of a native currency is very important. It should do something really useful to be able to capture most of the value.
Byteball, as you have come to expect about now, has a very elegant way of solving this problem.
If you use the system you gain value because you secure your payment data or contract data on the ledger. The system makes sure that the payments you receive and send will be stored and verified by multiple independent peers and that there can be no misunderstandings about your definite and final balance.
The system also makes sure that the execution of any contracts you make on the ledger is also verified and enforced by the same peers. This is something so valuable, that people will be prepared to pay for it.
Now to make it fair the amount paid for these services should be roughly proportional to the amount of resources the system uses.
The most easy and straightforward estimate of used resources is the size of the data that represents transactions, contracts, or any other data you would like to store. So the size is measured in bytes. That’s exactly why the currency is called Bytes, and 1 Byte is precisely the cost of storage of 1 byte of data. And to finish it off: the transaction fee is equal to the size of the transaction in bytes.
This explains the byte in byteball.
One nice consequence of this is that the currency cannot freely move all over the place, rather it is bound to its consumptive value. Because there are real fundamentals behind it.
1 byte is exactly the amount you pay for storing 1 byte of data in a global, secure, decentralized database, permanently.
And this data secures your money, your contracts. How much that kind of utility is worth in fiat currencies, depends on the demand for the service the network provides. So we’ll see what that amounts to in the coming years.
Also read the other 3 parts of this series:
Introduction to Byteball — Part 1: Why?
Introduction to Byteball — Part 3: Smart Contracts
Introduction to Byteball — Part 4: Adoption
