3. Smart contracts
5. Development environment
6. Consensus mechanism
8. To sum up
The purpose of Byteball is to be a highly scalable payment and smart contract platform.
Byteball native tokens, namely bytes and blackbytes, where mostly distributed in a fair way on Christmas day 2016 via an airdrop to bitcoiners that proved ownership (either via transaction or via signed message). There were multiple subsequent airdrops during the first half of 2017 that delivered primarily to byte holders (though a small part still went to bitcoiners). This proved to have an unfortunate negative pressure on the byte/BTC rate, so airdrops got entirely canceled and the last third of tokens are being distributed to the ecosystem, mainly as cashback on merchant and platform adopters. There has been no ICO or other types of sale, and the founder has reserved only 1% for himself.
Byteball is, in practice, a blockchain defined by a selected chain of transactions, called "main chain", and its related branches. This slight generalization is presented as a directed acyclic graph (DAG), albeit it is still a very specific type of DAG (concretely, it is a DAG with total ordering instead of partial ordering). Consensus is fully externalized to a set of 12 validators, called "witnesses". Those validators are key in establishing what DAG path constitutes the main chain, and so what would be the consensus-accepted order of transactions (i.e., total ordering). It is in that sense that validators not only check the structural validity of transactions, but also determine which transaction goes first (=> accepted) and which go later (=> rejected) in cases where they are mutually conflicting.
The protocol requires that transactors have an overlap of 11 (out of 12) witnesses, so this ensures that 6 witnesses can determine the chain state entirely, with no need to internal considerations (contrarily to most other blockchains that use biggest block height, with some weighting).
Smart contracts are defined in a safe, Turing incomplete declarative language (for reference, the Prolog paradigm). This choice is supposed to permit smart-contract developers to write the contract logic directly in the base script language, and defer most of the complex logic to on-chain oracles. This has a huge advantage compared to alternatives like EVM (Ethereum virtual machine), WASM (web assembly, used in EOS) or Blockstream-proposed Simplicity, for which smart contracts are supposed to get coded unsafely in a high-level language (while trying to minimize the impossibly avoidable impact of undefined behavior) and then transpile that code to the base script of the platform.
Other innovation is in "black" bytes (and other, optional, confidential assets). They give access to fully blinded (instead of obfuscated) payments. Each coin is individually transacted; instead of amounts, coins exist in different denominations; details of their transactions are not public, only the TXO hashes, so a potential receiver can always determine the spent or unspent status of a coin. The weakness of the scheme reduces to that of the hashing function (something known as the random oracle model). This makes its privacy strong and quantum safe, but it is, unfortunately, an extremely inefficient and unscalable approach.
Byteball is open to contribution, and indeed has a handful of active contributors. However, it must be noticed that most commits are either directly merged or merged with no public discussion. This is in rather sharp contrast with bigger, more collaborative projects. Its Github page:
Just like with EOS, the option that makes possible massive scalability seems to be backed by deferring validation to a restricted set of nodes. What is unfortunate is that there is a state of the art for such an approach, but both Byteball and EOS avoid it and propose their own homebrew construct. With different trade-offs, there is the historical foundation in the Paxos protocol, and its different spins and refinements as done in the Stellar Consensus Protocol or in Tendermint or, relatedly, in Hashgraph, and then alternatively there is also the Blockstream Liquid federation approach. In the case of Byteball, an overlap of 11 out of 12 witnesses is required by the protocol. This ensures strong consensus as long as 6 of these stay honest, but offers no margin to organic replaceability and it seems that, in practice, the default list is almost all that matters.
Transactions have a fixed fee-rate, for which the price in terms of the base currency, bytes, corresponds to the transaction size too. This lack of adjustability may apparently look risky, as it necessarily couples the exchange rate of bytes with the fee-market rate of its transactions, and at a factor determined at launch and unchangeable. However, it must be noticed that it avoids a major headache and cause of headache and cause of governance drama that affected many blockchain projects.
Also, in practice, if as adoption grows, fees appeared to be still too small to keep spam at bay, nodes can apply traditional rate-limiting and spam prevention mechanisms (while still not directly censoring anyone), or they could even demand out-of-band fees. If, contrarily, price booming makes fees become too onerous, witnesses can pay-back them to transactors. Indeed, there is currently a communitybacked witness that does exactly this.
To sum up
Byteball has set up a solid foundation with nice innovation gems, with fair distribution, and with avoiding "blockchain hype" marketing. The project is tiny but easily maintainable at the same time. Its limited ecosystem is committed and ungreedy which, in other words, means robust to changes in the crypto-economic cycle. The current bull run favors bigger projects in detriment of Byteball, but a big crypto-depression like that of 2014-2015 (which nearly killed big-expense Ripple) could make it have greater survivability than its competitors.