Bitcoin was published in 2009 as a purely peer-to-peer electronic cash. While the idea was successful, it was functionally limited due to the constraint of being, essentially, just a map of balances with a limited set of transactions. Decentralized economic interactions often require complex rules to be enforced, and Bitcoin was incapable of doing that at protocol level, re-introducing the need for trust. This limitation resulted on the creation of a vast amount of application-specific decentralized networks such as Namecoin, for name registering, or Monero, for built-in privacy. This scenario was wasteful, since competing platforms couldn't interact nor exchange values with each-other.
Years later, Ethereum was developed with the purpose of generalizing Bitcoin by embedding a Turing-complete scripting language on the blockchain. This allowed the protocol to be arbitrarily extended by users through smart-contracts. In an ideal scenario, Ethereum would eventually incorporate most specific use-cases, allowing decentralized applications to coexist and interact in the same network. Sadly, this scenario is prevented by its lack of efficiency. Emulating computations like linked ring signatures or zk-snarks on its virtual machine is prohibitely more expensive than using application-specific blockchains. To solve Ethereum's scalability issues, alternative smart-contract blockchains were developed with different designs and proposals.
The problem is that every new crypto-currency or smart-contract that is developed comes with a set of built-in features that 1. make it less efficient for those who do not care about them, 2. are faded to be obsolete. For example, if someone is only interested in publishing proofs of existence, then everything else is wasteful: signatures, accounting, virtual machines. Yet, when he makes a transaction on Bitcoin or Ethereum, he is indirectly paying for those things. Basically, the more features a blockchain has, the less efficient and attractive it becomes, so having a fully-featured virtual machine ends up achieving the opposite effect.
Unilog attempts to solve the same problem of Ethereum, i.e., implementing a decentralized smart-contract platform, by taking the complete opposite route: instead of extending Bitcoin with a bunch of new features and a fully-featured virtual machine, it just removes all its existing features to the point there is only the blockchain left. That is, Unilog removes the "coin" from Bitcoin, leaving us with only the bits: a boring, coin-less, data-only chain of blocks. The idea is that, by doing so, we gain an small performance bump, which, in turn, makes it a great smart contract platform.
To understand why, one needs to realize that blockchains are nothing but interpretation functions on top of a decentralized stream of ordered events. Take Namecoin, for example. Instead of making a whole new blockchain, its users could just agree on a transition function, say, namecoin(tx, state), which, given an array of transactions, would compute the state of the network. They could then embbed their namecoin transactions on Bitcoin, using it as a stream of events. And done: as long as users are happy to pay Bitcoin fees, Namecoin can live "on top" of Bitcoin. Unilog is promoting that idea, except that, instead of using Bitcoin itself, we do it in a less bloated, data-only blockchain.
The advantage of building decentralized applications on top of Unilog is that it extremelly future-proof. Cryptocurrencies and smart-contract platforms are faded to become obsolete because developers find better ways to implement the same features. Ethereum, for example, has a huge set of sub-optimal opcodes that will be changed on its next version. The problem is that protocol changes require forks, which split a blockchain in two. If Ethereum was, instead, an interpretation function on top of Unilog, then, changing the protocol would only require users to agree on a new "interpretation function". If they disagree, there would still be a fork, but it would be a logical one, since both interpretation functions would still read from the same stream of events.
And that is the main appeal of Unilog, and the reason it is faded to grow. It goes like this: since Unilog doesn't have any "bloat", it is arguably the least expensive way to publish ordered, decentralized events. Since that is the essence of decentralized applications, people are incentived to create platforms as interpretation functions on top of Unilog. If a platform decides to fork, then its users will download different interpretation functions, but, since Unilog is the least expensive way to publish transactions, they're incentived to still use the same blockchain. In other words, Unilog forks don't fork the blockchain, making it a snowball that only gets bigger. The only reason to fork the blockchain would be if one found a cheaper way to publish transactions, which, in a PoW setting, is impossible, because you can't optimize something that does nothing.
Once you understand the motivations for Unilog, there isn't much to be written about its technical aspects. Unilog isn't innovative: it is, literally, just Bitcoin without the coin, for a small efficiency gain. It consists of a chain of blocks, where each block cointains a set of transactions / events, which are just blobs of bits, i.e., they contain no structure, signature, amounts, inputs nor outputs. Every X minutes, a block is mined by proof-of-work. The miner includes as many transactions as possible on the block header by taking the merkle root of the transaction set. The difficulty is adjusted every Y blocks. There will be a block size limit, but possibly much larger than what Bitcoin is currently capable of. And so on. This raises one obvious questions: if there is no coin, what incentives miners have to keep mining?
Unilog will be used to implement decentralized applications, currencies, smart-contract platforms. Users of those applications naturally want them to keep operating. As such, those applications will have built-in mechanisms to pay the miners. As an example, suppose there is a MMORPG running on Unilog. Once the game starts getting popular, its items, assets and in-game currency will naturally appreciating in value. If Unilog suddenly stops being mined, then the game will freeze. Users of the game will be worried about their lost values, so they will be incentived to pay miners to keep running Unilog. Eventually, applications and games inside Unilog will have built-in features to facilitate those payments. So, while there isn't a "built-in" coin, there will still be forms of currency "living inside Unilog", and miners can and will collect those.
Another question could be: how can one implement smart-contracts? As you may have noticed, different interpretation functions can't communicate with each-other, despite living on the same blockchain. They're completely separate worlds. As such, the idea of smart-contracts, i.e., applications that can talk to each-other, is still very important. But how can one implement smart-contracts on top of a data-only blockchain? Specially, if there is no criteria for accepting transactions, what prevents someone from publishing an never-ending loop?
Phos will be a smart-contract platform where contracts are just Formality programs. That gives us a very good cost model: a graph rewrite is the unit of cost. That is, since FM-Net graph rewrites are quick, constant-time operations with roughly the same cost, we don't need a "gas table", as if 1 graph-rewrite = 1 gas. This makes Phos naturally resistent to underpriced opcode attacks, which are used to DDOS networks such as Ethereum once the "gas table" gets out of sync with the real cost of some opcode. But this doesn't answer the question: how do we charge for computations if there is no native coin?
There are many solutions, but what I want to do is the simplest thing that works: just have a constant limit on the number of graph rewrites per transaction. That is, every mined transaction is "granted" with the right to do some computations. A limit of, say, 10k graph rewrites would be big enough to implement arbitrary program logic, while still being small enough so that the work required to compute the final state of Phos stays realistic, and we can easily estimate it as a function of the current date:
time_to_compute_pos_state(current_time) = (current_time - begin_time) * unilog_tx_per_sec * phos_rewrites_per_tx / fmnet_rewrites_per_sec
So, for example, if Phos started on 2020, Unilog had a blockchain size limit that allowed 100 transations per second, Phos allowed 10k rewrites per transaction, and an average implementation of FM-Net performed 500m rewrites per second (~10x more than currently), then, by 2030, it would take (311040000 * 100 * 10000 / 500000000) seconds, or 7 days, to compute the final state of the blockchain, assuming full blocks and that every transaction uses as much rewrites as allowed.