In which mayday mayday we are syncing about*

Don’t trust, terrify!

The “don’t trust, verify!” slogan is beyond my comprehension. I board airplanes without verifying anything about the pilot or the aircraft; I visit restaurants and foolishly eat – without verifying what will be transmitted to my blood; I take medicines without verifying the supply chain. Why would I protect my money with measures I am not taking to protect my life?!

This reminds me of Jacob, the forefather of Israel, who crossed the Jordan river some 35 hundred years ago, back to his homeland. Albeit, he forgot a few small pitches (think of dust UTXOs), so we are told by later Talmudic Rabbis, and so he went back to the eastbank, in the middle of the night, alone, to fetch the pitches. This was apparently unsafe, and he met a mysterious figure who wrestled with him, a battle from which he came out with a limp, a divine blessing, and a new name - Israel. The Talmud concludes:

“From here it is derived that the possessions of the righteous are dearer to them than their bodies. And why do they care so much about their possessions? It is because they do not stretch out their hands to partake of stolen property.”

I hope the connection between this story and SPV sync mode based on multiplicative-hash UTXO-commitments is self explanatory but, just in case, do note that verifying by yourself the proper functioning of all external systems which you rely on is infeasible, unscalable, and anticivil – civilization is the scaling up of function and trust – whereas doing so only with respect to money is peculiar and will cause you to limp.

Why not fiat?

Because fiat supply is inflated unpredictably; because the political printing of money is corrupting the democratic sphere, positing the political debate on allocation of money instead of creation of wealth; because regulators are attempting to control financial transfers, eliminate cash, restrict economic freedom.

We reiterate cryptocurrencies’ golden traits – predictable issuance and censorship resistance. In contrast, the property “no fraudulent transaction ever occurred in this currency system” is not the something (or at least: main thing) users should/care about. Consequently, when joining a cryptocurrency system, checking its issuance and its decentralization is far more important than checking the historical validity of transactions.

Yes, we go so far as to say that users do/should not care about historical corruption. For the user is interested in knowing that the state of her node is the one that is most likely to prevail by the economic majority, not that the state of her node is the valid one in some abstract sense. The primary goal of consensus systems is facilitating agreement, not enforcing consistency. And if the economic majority happens to follow and maintain a ledger to which an invalid transaction entered at some point in history, so be it, the system can still serve its purpose of facilitating agreement even if its constitution was breached at some point in time. Indeed, if code rules, the constitution, are violated time and again, or even not extremely rarely, the wise user should definitely refrain from joining said network. Users are therefore protected from unsafe networks as long as they can safely assume the existence of efficient ways to communicate and diffuse information on such mishaps. This novel way to diffuse information is called The Internet, or its manual predecessor – Civilization.

As with airplanes and restaurants, users rightly assume that they arrived at a functioning system, and that information on past security breaches would have reached them in the conventional information channels. These information channels are typically reliable thanks to highly-staked, ideological, or philanthropic whistleblowers that continuously verify the ledger – or by previous users that have been harmed by the system’s malfunctioning – granting the system its herd immunity. Running full nodes are thus very important for the ledger’s society, however, the marginal utility is rapidly decreasing.

To summarize: If you are going to join IOTA network, google it first.

Why not Bitcoin?

Initial Blockchain Download (IBD) is the process by which new nodes join the network. Since Bitcoin core devs’ ethos is “don’t trust, verify!”, the default behaviour of the new node is to download and verify the entire history of the Bitcoin ledger. Consequently, Bitcoin’s throughput is deliberately limited to enable fast IBD—indeed, processing too many transactions per second today would make it difficult for a user joining in 2040 to verify that today’s transactions were valid. I kid you not.

Back in 2013 my advisor sent me a paper titled “Bitcoin: a p2p electronic cash system”. The new narrative seems to have changed into “Bitcoin: an electronic store of value” coupled with “the attempt to create a p2p electronic cash coin is a scam”. An interesting development that is.

Why Kaspa?

First, to make Satoshi great again. PHANTOM is really a neat generalization of Nakamoto Consensus (when k=0 PHANTOM coincides with the longest chain rule), it follows the same principles just with support for concurrency. It is Satoshi at its best, and the only path to fulfil His electronic cash vision. We make DAGs because we know how to and because no-one else does. We implement PHANTOM because we want to ping with “send txn” and be ponged “txn mined” in the same manner we get the results of a google search or send an email. We picked up this challenge in the same way Bitcoin core devs chose to work on Taproot – it is cool and not entirely useless.

Secondly, to make myself rich.

Third, because we need a base layer whose tradeoffs are centered around the crypto-informed user’s needs and asks. This implies, in particular, and according to the worldview I suggested above – implementing the default node to skip historical verification, making it an optional operation, one that relies on the fewer archival nodes that some entities choose to maintain and make available (this is the same situation as in Bitcoin, since most Bitcoin full nodes are pruning the data necessary for syncing newcomers, but be advised to not share this info with Bitcoiners, it’s gonna ruin their day and by implication your week). Importantly, these archival nodes maintain the ability to prove to newcomers that a certain transaction was fraudulent, by providing the Merkle witnesses for inclusion in the blocks involved in the claimed collusion.

Accordingly, Kaspa nodes prune block data by default, and new nodes by default do not request historical data, rather, they sync in SPV mode, i.e., by downloading and verifying only block headers. I reiterate that this is not a stronger trust assumption than a history-verifying node, rather a different requirement. The node then requests the UTXO set from untrusted peers in the network, and verifies it against the UTXO commitment embedded inside the latest received header (technically, this is done against the latest pruning point). If those do not match, the node bans the sending peers, requests the UTXO set from new untrusted peers, and repeats the process. If those match, the node verifies that no unexpected inflation occurred by comparing the sum of UTXOs to the specified minting schedule, a comparison for which block headers suffice.

Make Satoshi Great Again

My not-novel suggestion to scale up Nakamoto Consensus: /*:

• Latency constraint on Consensus – move from longest-chain to PHANTOM, which is tolerant to and compatible with any predetermined upper bound on the latency.

• CPU consumption – process few transactions per second on L1, while supporting large payloads, which are cheap CPU-wise, and which enable easy and healthy L2 (e.g., SN/TARK proofs for ZKRUs).

• Bandwidth consumption – design sharding of data and data availability proofs, similar to Eth 2.0 stopped after phase 1 (see Ethereum’s rollup-centric revisited roadmap); this is an open research question, since PoW has no native identities to serve as the basis for sharding.

• Memory consumption and disk I/O – implement class group based accumulators that require no trusted setup, and which allow to prune the UTXO set and run as a stateless client. Challenges include: UX of storing and updating the witnesses; weighing memory save against higher CPU consumption.

• Storage – prune block data, reducing storage requirement from O(block header size)*O(num of blocks in history) + O(block size)*O(size of history) to O(block header size)*O(num of blocks in history) + O(block size)*O(size of pruning window); additionally, consider pruning block headers, further reducing the requirement to O(block size)*O(size of pruning window). Pruning block headers is an open research question, since it is then unclear how a new node will be guaranteed it is syncing to the consensus state and not to a stale or malicious branch. However, arguably, any system with (deterministic) finality enjoys/suffers/relies on weak subjectivity, and therefore reading the entire history of PoW might be redundant.

• IBD time – implement DAG-adapted version of FlyClient to reduce the cost of syncing a new node from O(num of blocks in history) to O(log(num of blocks in history)). This does not reduce the storage at the syncer, but does allow the syncee to sync w/o downloading the entire history of block headers.

*/

What are you syncing about?

Concluding today’s topic. Kaspa is PoW on steroids. It is optimized for the informed users, not for the ideologs. Its throughput ought be constrained by real time performance considerations, not by the performance of downloading and verifying the historical ledger, which is an auxiliary trust gateway, but not the primary pillar of trust in the system.

Kaspa should reach 100 blocks per second, and to that end, Kaspa nodes should be pruning data by default. When new nodes join the network, they should sync against the heaviest PoW DAG, as it is the one with max likelihood to represent the current consensus view. Node operators should take measures to connect to sufficiently many peers so as not to be eclipsed from the network (as in Bitcoin), so that they hear about historical mishaps, e.g., invalid blocks, finality violations, etc., which are recorded and propagated by full nodes to ensure that new nodes know what they are syncing about.

I’m reminded of the very best ad in the history of ads. Pardon my associative memory. The ad is picturing a coast guard trainee on his first day on the job. He’s apparently not too well versed English-wise, which is unfortunate for the desperate pilot trying to communicate with him that the plane is …

See the ad in the title reference below.

Notes

* Title reference