I like things with extreme simplicity, from inside to outside, both technology and interface, and I do stuffs by keeping simplifying the concepts, all because I have a very simple belief that simplicity is fast.

Simplicity is not inferior. To build something, time is a critical factor, you must deliver something to the market at a proper time window. You can’t have unlimited resources in a limited time, both human and capital would restrict what you can do. With these limited resources, you can craft them better if you spend time on deciding the most important features of a product and build fewer things, without wasting time on endless meetings. Simplicity also makes team members more efficient because they know the exact mission of the project and have a clear roadmap since the day one. People tends to move faster when they know the destination.

In past 2 years, I spend almost all my time on Mixin, both the Kernel and Messenger. As soon as we started the project, we had known our mission is to secure digital assets and messages on Mixin, by building open source software that always puts security, privacy and decentralization first. They were not some random thoughts flashing around my brain, I knew the mission because I had had the faith in security and privacy for a long time, mostly inspired by the open source movement. The mission is clear, so the feature set was also frozen since the very beginning, we build the Kernel as a distributed graph to transfer digital assets by making use of the UTXO model, and we decide the Messenger should only have the interfaces of making digital assets transactions and delivering end-to-end encrypted messages.

I have written a lot about Mixin Messenger, but not so much on how the Kernel works, so here I will try to explain how simplicity makes the Kernel special. Mixin Kernel is blazing fast, not because of magic inventions, but its limited functionalities focusing on assets transferring, no not so smart contracts. The unspent transaction output model used by Bitcoin is so smart a creation that make it possible to do concurrent transactions without locks on an account balance. To make precise transactions on a traditional account model we need some pseudocode like below.

// transfer 5 from account A to B
mutex.Lock()
var from = accountA.Balance()
var to = accountB.Balance()
if from < 5 {
    throw "balance not enough error"
}
accountA.SetBalance(from - 5)
accountB.SetBalance(to + 5)
mutex.Unlock()

So the program needs to wait on the locks of both account A and B for the most basic transaction, furthermore if smart contract is in, then things would get exponentially complicated, the locks will prevent parallel execution and slow down the program. However with UTXO, account locks are not a thing, each virtual account has its own UTXO set and is able to make a conflict-free transaction before submitting it to the Kernel. This is also the drawback of the UTXO model, which makes it more difficult to make the wallet.

Only UTXO is not enough, Mixin Kernel also defines strict restrictions on double spending, no UTXO should be used in more than one transactions. In the Bitcoin network, you may include an UTXO as the input to different transactions and let the miners decide which transaction to include to the longest chain. But it is not the case in the Kernel, the wallet should carefully ensure that no UTXO is used twice, because no reason to do that as the Kernel will ensure all transactions submitted executed. The reason to allow Bitcoin UTXO reuse may be most likely the transaction fee, sometimes people want to make their transactions included to the block faster so they building another transaction, but all transactions in the Kernel are free. This mechanism allows the Kernel node to truly validate UTXO concurrently by denying the second transaction with a previous input.

With UTXO, all free transactions, and restrictions on double spending, it’s possible to make a directed acyclic graph. Each node has its own chain, very similar to the Bitcoin blockchain. Whenever a transaction is submitted to Mixin Kernel, some nodes may validate its inputs to deny double spending, then include it to their own chains independently to each other. All nodes equal to each other at all time, no leader, they build their own chains and reference others’ to build a total graph. This true concurrency both in inputs validations and chains building make the Kernel possible to finalize transactions within a second, and possible to handle thousands of transactions concurrently and easily.

Keep it simple and stupid. Simplicity is superior.