The wrong lessons of a supply chain crisis

Whenever humans are involved, complex systems are never amenable to “easy” models, if only due to second order effects 1. Supply chains are no exception, and yet these models are prevalent 2, leading to all sorts of inefficiencies such as inventory write-offs, waste, delays, unused capacity, poor customer service, etc. Yet, these inefficiencies are not the biggest problem associated with simplistic models, the biggest problem is that they prevent people in charge from even considering what could eventually become proper remedies.

Large scale reuse of FFP2 and N95 masks

The French version of this document. Synthesis: this document proposes the reuse of FFP2 masks on a large scale thanks to the pre-existing sterilization and decontamination infrastructure in France. This initiative aims to avoid the amplification of the Covid-19 health crisis due to a shortage of masks for medical personnel, which would lead to additional contamination from the medical personnel themselves. Within a week, this initiative would allow the reuse of 1 million masks per day for a cost of less than 4€ per mask from the first masks treated.

Réutilisation de masques FFP2 à grande échelle

The English version of this document. Synthèse : ce document propose la réutilisation des masques FFP2 à grande échelle grâce à l’infrastructure pré-existante en France de stérilisation et de décontamination. Cette initiative a pour but d’éviter l’amplification de la crise sanitaire Covid-19 due à une pénurie de masque des personnels médicaux eux-mêmes, qui aboutirait à des contaminations supplémentaires via les personnels médicaux. Cette initiative permet la réutilisation - sous une semaine - de 1 million de masques par jour pour un coût inférieur à 4€ par masque dès les premiers masques.

ABC is Bitcoin's biggest asset, a CEO's perspective

As a follow-up to the article Bitcoin Cash is Bitcoin that I published 2.5 years ago, let’s revisit the Bitcoin community’s state of affairs. In particular, let’s have a closer look at the infrastructure players involved, as the future of BCH basically depends on the quality of the people steering this currency. Who am I to do this assessment and why? I am the CEO and main shareholder of a midsize software company (profitable, growing, non-crypto and no VC on board), I have been following Bitcoin since 2011, I have done various technical contributions such as proofreading the Avalanche code.

On choosing the right block size for Bitcoin

The Bitcoin community has been debating the right size of a block for almost its entire existence. Two years ago, these debates lead to the split between Bitcoin Cash - opting for larger blocks - and Bitcoin Core - opting for 1MB-forever blocks 1. Yet, while many members of both communities appear to have firm opinions on the matter of choosing the adequate block size, I have casually observed a lot of misconceptions concerning this topic.

Metadata subtree for Bitcoin

The block header of Bitcoin has a couple of flaws; some of them being in the way of highly desirable innovations such as UTXO commitments. Unfortunately, fixing those flaws isn’t an easy task because most “easy” solutions end up not only breaking backward compatibility with most of the software ecosystem, but also end up bricking most mining devices. Hence, those “easy” solutions aren’t exactly on the table. Yet, a simple solution is needed, because complexity is the enemy of both security and scalability in a project like Bitcoin.

Merklix tree for Bitcoin

Last summer, I had the opportunity to meet with the Bitcoin ABC folks, and we revisited the pain points which needlessly complicate on-chain scaling for Bitcoin. The Merkle tree flavor as originally implemented in the Satoshi’s codebase comes with its own complications, some of them clearly accidental - as they do introduce unintended vulnerabilities. The Merklix tree angle addresses the scalability challenge as well as fixing the unintended complications of the original design.

Salient bits of CashDB

Designing CashDB has been an interesting task, and beyond pure performance benchmarks, I would like to share some of the most salient aspects that went into its design. Choosing C#/.NET: CashDB is implemented in C#/.NET. This might appear as a surprising choice for a high performance project, however, .NET Core is performant, surprisingly so, even. High quality C# implementations (eg xxHash) basically exhibit performance aligned with C. Then, productivity-wise, C# - just like Java or Python - is plainly superior to C++.

Alpha release of CashDB, high-perf backend for UTXO storage

The alpha version of CashDB has been released. CashDB is a fork and the successor of Terab which has unfortunately been discontinued. CashDB is an effort (disclaimer: this is not a regular open source project, there is a BCH restriction, check the license) of Lokad to support the on-chain scaling of Bitcoin. It’s a blockchain-centric key-value store specifically tailored for the UTXO set of Bitcoin - the set of unspent transaction outputs.

The Sozu table, a blockchain-centric data structure for the UTXO dataset of Bitcoin

The UTXO dataset is the set of unspent transaction ouputs in Bitcoin. This dataset represents who own’s what, and it is the only part of the blockchain that actually need to be persisted to keep Bitcoin working (well, almost, block headers are needed too, but they are much smaller). Earlier this year, when I started to work on the UTXO challenge challenge, I realized that generic key-value stores were not exploiting all the angles that could be leveraged in the specific context of Bitcoin.