Qubic's Unofficial Interim Whitepaper

Why only an interim Whitepaper?

Qubic's mainnet was launched in April 2022 and is since then undergoing continuous development and improvement.  The official final whitepaper will be released once the core development is complete. As the Qubic protocol operates quite differently from any traditional blockchain, it was necessary in the past to reinvent some major components. We believe it is better to release the final whitepaper once the protocol is finished. One major key element that still needs to be added is the integration of Oracle Machines.

“As Qubic is since day 1 complete open source the code can be seen as official whitepaper” -CFB https://github.com/qubic/core

Qubic is a modern crypto using a decentralized quorum consensus model described by Nick Szabo(Quorum Systems) in prehistoric (before bitcoin) times of the last millenium. Lamports paper (The Byzantine Generals Problem) from 40 years ago was instrumental in the creation of Qubic. The first mention of Qubic appears in 2012 on a short bitcointalk thread(Qubic — Quorum-Based Coin). Following that the founder of Qubic, Come-From-Beyond (CfB), created the first purely proof of stake coin called NXT(NXT: descendant of Bitcoin) which also had built in asset support. From there CfB made the first successful DAG implementation with IOTA(IOTA) and it seems the original plan was to build Qubic on top of IOTA but luckily for us, Qubic mainnet was launched on April 2022 as a standalone implementation.

A lot of people just hear that CfB is the creator of Qubic and that is good enough for them to buy some QU (QU = Qubic Unit = native coin of Qubic → to simplify, we will use in the following text our ticker: $QUBIC), however this document is for those that need an objective analysis of Qubic.

Qubic is not a blockchain. It is not proof of stake. It is not a DAG. It is not even directly a proof of work consensus model. To understand Qubic you need to basically forget about all the other crypto implementations as it is unique in almost all aspects.

Qubic has the analogue of blocks in what it calls ticks. Unlike blocks there is no direct linkage of one tick to another, ticks happen within a weekly epoch and currently happen about once every 5 seconds. The tick speed is adjustable and in past epochs ran as fast as once every 0.2 seconds. Every week at noon UTC wednesday a new epoch starts and currently this transition incurs a bit of downtime until things are ticking at normal speed. It is basically a scheduled hardfork upgrade every week! Now you are probably saying “weekly downtime???” and yes it is true for now as Qubic is under rapid development there is about an hour of downtime every week. The community has adapted well to this and other than some people complaining about not able to make transactions during the downtime the effect is minimal. Of course it is important that eventually epoch changes can become seamless and this is planned and there are no significant technical obstacles to achieving it.

The reason for the weekly epoch change is that not only does Qubic run without an OS on baremetal servers, it runs entirely out of RAM. I repeat, Qubic runs entirely out of RAM of the consensus creating nodes without the overhead of an OS. This allows for some incredible performance and we will see other unorthodox choices in Qubic that were made (I think) for the sole purpose of maximum performance. To give a hint of what level of performance is possible, a live test achieved over 40 million transactions per second. Basically orders of magnitude more than any other crypto. To be able to achieve such speed it is important to have finality and Qubic excels in that too with instant finality. There is no worry about a blockchain reorg (there is no blockchain!), there is no possibility of a 51% attack as there is only a single consensus for any given tick that is possible.

There are 676 special nodes called computors, 451 of these are required to be in sync and agree on a tick for it to be valid. There is an arbitrator that makes sure the computers are behaving properly. If a quorum is not reached for whatever reason, we get an empty tick. A tick will contain transactions, which are simply data packets with assigned handlers for various types of transactions.

Unorthodox alert! Qubic transactions do not have any transaction fees, they can also have 1024 bytes of extra data. However, all the transactions are pruned! every epoch change. Only balance change summaries survive epoch change and only if there is a nonzero balance.

Unorthodox alert! A transaction being included in a tick only means that it was properly signed by the sender and included in the tick. It does not mean that the transaction was successful. While any actions indicated by a transaction is processed in the same tick, its inclusion in a tick does not mean it did anything. We are so used to having unconfirmed transactions, mempools, transaction fees, maybe replacing transaction fee to speed it up, confirmed transaction that means it worked, and then to make sure it has enough confirmations and it is not reorged out of existence and possibly double spent. Yes, normal crypto is actually quite a mess and very complex and only has a statisticaly finality. Even BTC, if a very large amount is transacted you would need to wait for many hours to make sure that some large hash rate wont reorg the transaction and double spend it.

Qubic does away with all of that. A large amount of code is needed to handle all of the blockchain logic dealing with reorgs and keeping track of things and this goes against the Qubic ethos of maximum speed. In Qubic you broadcast a transaction you want to make and specify the future tick you want it to be included in. Anything less than 3 ticks in the future has a high chance of not being included, most wallets have a default of 10 ticks in the future. As soon as that tick arrives, if the transaction was included, it was and if not it will never be. That is it! No need to worry about forks, reorgs, txfees, etc. Having to check if the transaction was included and actually did anything is a small price to pay for the instant finality.

Unorthodox alert! Since a transaction can be included in a tick but fail and not have any effect, that means you can send a trillion $QUBIC that you do not have and it will be included in the tick, it is incumbent on the receiver to make sure your transaction is valid. To do that you need to make sure that the balance changed, and because of this there is the restriction that a single id (address) can only have one pending transaction at a time. If you broadcast another transaction to the network before it is included, then it will be replaced. The sender needs to verify that the transaction was included in a tick and if not to resend it. Again, a small price to pay for the performance and eventually wallets will be able to automate such functions so it will not be visible to the user.

Each id has entity info (incomingAmount, numberOfIncomingTransfers, latestIncomingTransferTick, outgoingAmount, numberOfOutgoingTransfers, latestOutgoingTransferTick), which separates out the incoming and outgoing totals, and most recent tick. Theoretically the change in these totals will enable confirmation if a transaction sent funds or not. There is a RAM data structure that is the entity info for all ids called the spectrum file. It is updated every tick and to achieve quorum the hash of this file must match. There is also a universe file which has the info about the asset holdings of each id and the hash of the universe file also needs to match. By making sure that both of these files match across the network is how Qubic assures that the consensus has valid balances. Directly confirming all balances across 676 RAM based baremetal nodes, every tick. No need for lifetime history from the coinbase, much more efficient and with a two thirds requirement on the quorum it is secure, see Szabo paper.

In the case where a single id is receiving funds from many different ids, it becomes much simpler to use a onetime address to transfer funds through. That way you can just check the balance of the onetime address to know the status of the funds transfer and not have to search across multiple ids in case of a failed transaction. Since there is no cost to transactions and there is instant finality the extra cost is just several ticks and having to remember the temporary address. Depending on the usecase it might or might not make sense to use temporary addresses. I found it quite useful in simplifying the error handling and also deal with the case where the balance changes without a transaction!

Unorthodox alert! Yes, that was not a typo, account balances can change without a transaction. This is because of Smart Contracts (SC) that operate directly on balances so there will not be a specific transaction of sending funds from A to B. However, there is a logfile that records all changes to balances so it is possible to scan that log to detect what addresses need to check for balance changes. I recommend that any Qubic service implement balance change based state machines to create reliable error handling and support for payment via SC.

Now is a good time to talk about SC. Currently there are only 3 authorized SC (Qx, Quottery, Random) and only Qx is partially deployed. These are early days and eventually any SC will need to be fully operational before being accepted. SC are compiled directly into the Qubic core code, which is in C++. Any language that can be linked into the C++ codebase can be a SC, but the expectation is that most of them will be written in C++. After a SC is working on testnet, then it would be proposed to the computors to be accepted. If a quorum is reached (451 votes) and it gets majority approval, a SC will be accepted. However, it is quite a bit more exciting as every accepted SC will then conduct an epoch long dutch auction for its 676 shares. The winners of the dutch auction will have their funds burned and that will create a credit account for the SC fees. Once these credits are used up then the SC fees will need to be added to each SC usage and those fees get burned. There are also shareholder fees that exist from the first usage of the SC and they will get distributed to the 676 shareholders proportionally.

There are always exactly 676 SC shares, so there is no inflation (or deflation) at all for SC shares and for those that are concerned with $QUBIC inflation, SC shares might be a good way to diversify. The current core codebase allows for a maximum of 1024 SC, but it will be a simple matter to increase this limit if needed. As the RAM in the computor nodes are increased, the overall capacity of Qubic scales up. Both in terms of the number of SC possible and the number of transactions possible. Bandwidth limits the number of balance changes per tick.

Unorthodox Alert! What this means is that funds spent in the dutch auction do not go to any entity as the winners funds are burned. This also means that all holders of $QUBIC benefit from every SC auction as it is antidilutive. Ultimately it is the SC fees that are burned that will help achieve coin supply equilibrium. Now is a good time to talk about the tokenomics.

Unorthodox Alert! The native coin of Qubic has no decimal point, the assets can specify the display convention of how many decimal places it has. SC shares are a special type of asset with Qubic as the issuer and no decimals. My theory as to why there are no decimals is that it helps performance. When in doubt about a Qubic feature, just ask if it helps performance or not. Not having to deal with floating point numbers and just integers helps performance, so we lose the decimal point. The side effect of this is that the numbers of $QUBIC becomes very large and this tends to freak out many math challenged people. If you see numbers like 1 trillion per week and 1000 trillion max supply without dividing by 100 million, you might think there are just too many $QUBIC. However $QUBIC is the indivisible unit of Qubic, equivalent to satoshis for BTC. There are actually 2100 trillion satoshis for BTC max coin supply and even now after all the halvings about 650 billion satoshis per week being emitted. And BTC has no burning mechanism.

Many have claimed that with 1 trillion new $QUBIC being emitted every week there will be such a selling pressure from miners that the price can never go up. If adjusted to the normal 100 million satoshis per coin, the current supply is 780,000 with 10,000 emission per week or a bit less than 1 per minute and a max of 10 million. Without all the zeros it is much less scary. A direct counterexample for the “1 trillion is too many coins” is DOGE which emits 4000 trillion satoshis per week and has no burning mechanism. Yet its price is not driven down to zero. Another counter example is that $QUBIC price has grown respectably and has had the highest inflation rate during this period. As time passes the inflation rate will come down simply due to there being more $QUBIC against a fixed 1Trl per week emission. Estimates vary when the coin supply will stabilize (auction and usage burns averaging 1Trl per week), some say at the 100Trl, others around 200T. If things go for 20 years or so and we reach the max of 1000Trl $QUBIC, the inflation rate will be 5.2% at the end before it transitions to 0% at the max.

[My estimate is that $QUBIC supply will vary between roughly 150Trl and 200Trl, varying as usage level changes. To me it seems that as the usage (demand) goes up, supply shrinks so the price should go up which will reduce the demand and supply would increase and the price would reduce. Lower prices would increase usage, demand goes up, … With a robust set of SC and active usage, we should enter a supply/demand based equilibrium range. Once this happens there is no net sell pressure from emissions and any incremental demand will directly increase the price.]

Probably you have noticed that I have not mentioned anything about AI until now. Even without any AI aspects, Qubic is the real deal. Ground breaking in so many ways. Qubic is not completed yet, at the moment there is not even an official website, only on a few very small exchanges, SC are just coming alive. Still already a quarter billion marketcap has been achieved as it is clear to anybody that understands the technical underpinnings of Qubic that even without the AI part, it is destined to be one of the top coins.

One final point about decentralization. Some might claim that 676 is too small a number of nodes. However if you look at what each computor node is, it will need to turn into a mining pool to survive the mining battles. BTC has half a dozen pools with majority of hashrate, so arguably the 676 computors are 100x more decentralized. Only the top performing nodes retain computor status and only computors get 1/676 of the weekly emissions. Instead of a static 676 that obtained their spot with a onetime investment, or just being allocated a spot, all 676 are competing every epoch to keep the coveted spot. Also, anybody is able to jump in and start competing for a computor node. This is what makes it decentralized at the weekly level. Within an epoch, the 676 nodes have control over consensus but the arbitrator keeps them in check and I believe there is even a mechanism to replace a misbehaving arbitrator but have not verified that yet. In any case having a single entity watching over a decentralized group of 676 computors that are making the consensus seems fine as recent performance of the computors are above 99% level. The arbitrator over the 88 epochs has accumulated only about 1.4 Trl QUBIC which is at the 2% level, so there is no concentration of $QUBIC issue.

I hope this document is useful for your understanding of Qubic. It is still not being technically completed yet. What Qubic has is the unique tech and tokenomics model built around an AI training infrastructure. This analysis is about what Qubic will become without the AI portion. Of course a successful AI tech will increase the value of Qubic by at least another order of magnitude as spending on AI training is projected to increase exponentially this decade. (Trends in the Dollar Training Cost of Machine Learning Systems)