This Monday I presented the following article. It discusses blockchains shortcomings. Even if it has been written in 2018, it is still very up-to-date… What follows here is a very opinionated piece. As such it reflects the journey I did in blockchains over the past 6 years. And I’m sure I missed out a lot 😉
The article Why Blockchain Is Not Yet Working goes over six points – for most of these points, research papers exist. For some of them test networks exist. Only one or two are solved in active main networks. Lets look at the points:
- Scalability Issues
Ah, the famous scalability. The most often cited number is VISA level transaction. This number is growing each year. In 2015, articles tried to reach 6000 transactions per second (tps). In 2021 it should be 24’000 tps. Counting China, this should probably be 100’000 tps.
There is no production blockchain that reaches this number. And by blockchain I mean public, decentralized, openly governed blockchains. So I don’t consider HyperLedger/Fabric and others which are more like databases with some hashing.
The fastest production blockchain that I consider a blockchain is Avalanche. They claim something like 5’000-10’000tps. Even if the current network chugs along at 0.33tps.
On the research side, OmniLeger claims up to 100ktps if there are not too many adversaries (5%) and enough nodes (500). AT2 also has around 50ktps, but with much more adversaries (33%), but a little less nodes (100).
Also, my idea of a blockchain doesn’t stop at asset transfers. Ideally, a blockchain would give rise to the Web 3.0. But for this you need more than asset transfers. You need smart contracts (like Ethereum), secret management (like Calypso), storage (like FileCoin), Ecosystem (like Cosmos / Polkadot), and probably a lot more.
Which will put the required tps into the millions, if not billions. The current most used proposition is to use level 2 protocols. This refers to a protocol above blockchains. Like the lightning network for Bitcoin. But the ones I saw created more problems than they solved.
- Lack Of Intuitive Private Key Management
Well, this is an issue. But as the article states, the key management is only one thing. You can use a password manager, and you’re done.
What is harder is key recovery. I think this is the missing issue.
One solution is to use DARCs, which lately got extended with a threshold signature component. So you can define a set of accounts which are allowed to recover your key. But only if 2/3 of them agree.
Our solution is working in our testnet. I recover keys for people once or twice a month. I logged in to wordpress using this system. It is of course possible to implement this in smart contracts. There must be some wallets out there supporting this.
But there should to be a standard. The current DID from the W3C has some recovery options. But not flexible enough, I think.
- Contract Security
I think this is one of the main reasons people are afraid of blockchains. Somebody described it as launching a rocket into space. After ignition, everybody in the world has full access to all systems. They can send any command they want. But the rocket should go to space anyway… That describes very well the state of smart contracts on public blockchains.
Of course you can use formal verification, better languages, but it will still fail.
Should there be some kind of rollback system? More easy than doing a hard fork? More research needed here 😉
- Consensus Algorithms Are Wack
Yes, PoW is bad, with bitcoin consuming as much power as all other data-centers in the world. Proof-of-Stake seems to be the way to go for the moment. But it doesn’t solve the problem for easy engaging in the blockchain. To do anything useful, you need to buy tokens.
There are other proposals, like using Proof-of-personhood to protect the consensus algorithm against sybil attacks. But they barely exist as research subjects. Even though the idea does gain momentum.
Also, still unsolved. “Bitcoin is like Twitter for your bank account” is a nice quote. ZCash and Monero do a bit better for private transactions. For storing data, Calypso has a solution that is decentralized. Private smart contracts exist in centralized blockchains like HyperLedger/Fabric. But ZCash’s implementation is still not usable by the big public.
- Price Volatility
Well, unsolved, but is it really a problem? I would more say that participating in the blockchain is still too expensive, besides the volatility. Be it Bitcoin (100$ for a transaction), Ethereum (50$ for a transaction), even Avalanche, which is very cheap (some cents for a transaction) – you still need to cash out money.
Currently I know of no system that allows the user to just join a blockchain in an easy manner, mint some coins, and launch some smart contracts. And using a test network doesn’t count. I mean on a main network.
So, out of the 6 points, none is really solved in a main network. The fast, cheap, easy-to-join, usable by everybody, web-3.0 blockchain is still in the future. Advanced research exists for about half of the points. But no implementations yet.
One of the consequences I see a lot are projects that try to use blockchains. But after some time they see that they have one or more of the above problems. And then they use a blockchain for timestamping their internal, private, centralized database. Which defeats the goal of the blockchain as bringing the web 3.0 to the people…
Let’s see how it will look in 2022 😉
Concurrent programming is one the oldest and hardest issues in the Computer Science Book. For years, we have been using locks, big threads sharing the minimum, using optimistic reasoning for “how data will be updated”. And we are still stuck with the same issues of some part of the code “failing” to use the updated object, dead and soft locks with hard-to-see origins, and many many crashes.
Some languages found some means around it. Rust uses reference ownership to ensure no-concurrent write-access to some object. Haskell (and other purely functional languages) uses persistent/immutable data-structures. immutable.js takes the second approach.
By having immutable datatypes, many operations are safer, as you can pass collections around without defensive copies and you can expose these publicly without having to ensure that the user can modify its state. As you are unable to “update” such an object, you’ll have to think about how state is updated throughout the code. It can be weird at first, but it enforces a well defined separation between producers, transformers and consumers of data. It results in clearer programs, easier to dig into and less likely to crash.
This library is quite simple in essence. It exposes the usual suspects: Map, List & Set. You can add and remove a value on an instance, yielding a new collection each time. Each of them is based on ECMAScript classical interfaces, but functionally oriented: you can map, filter, zip as wanted. To avoid the cost of creating a new collection every time, it tries to reuse most of the originating collection. Equality check is also faster on average, as it doesn’t need to check the whole chain of values, but stops at the first common reference found. It might be a bit cumbersome at first, because it forces to check for nearly all corner-cases, such as an empty list (`get` returns `T|undefined`), but it ensures that no exception happens at runtime. Overall, it reduces the potential for error directly at the type level.
We’ve been looking at the very nice
and played around with it. Instead of having a fixed view of all participants, you can walk around and ‘meet’ different persons in gather.town. You can edit the space your liking. It looks very much like a very old-school Zelda:
What I liked a lot about it is the following:
- private rooms – you see only the videos from the people in that room
- nearby videos – only the people around you can see you
- interactive objects – from whiteboard to games, and simple URLs, you can make your space interactive
As a fun-note, it has been rejected to be used for our daily zoom-coffee discussion because: “if somebody leaves an ongoing discussion, this might indicate too harshly to the person talking that they are not interesting”. Well, that was my point. But my diplomacy is known to be quite low…
Another similar tool, much nicer drawing, but lesser functionality, is https://topia.io/.
The management of IT infrastructure is a constantly evolving topic. A very interesting concept that emerged in the last decades is the idea of infrastructure as code: instead of configuring servers in an artisanal fashion, the process is formalized into definition files, which are then automatically “executed”. There are multiple advantages, notably:
- The files always reflect reality, avoiding “undocumented last-minute patches”
- Versioning the files gives us a history of the changes
- Reusing the configurations across multiple machines gives us uniformity (e.g. same version of tools everywhere)
- Rebuilding a server in case of a crash requires only spawning a new one and reapplying the configuration
Ansible is one of the more popular tools in this domain, along well-known others such as Puppet, Chef or Salt. Many admins choose it because it is easy to use, yet at the same time very powerful. It is also very well documented. If you are reluctant to adopt such a tool because you fear the benefits do not justify the complexity, Ansible might convince you otherwise: you can start managing a single service, moving on to a whole server when comfortable, perhaps extending to dozens or thousands of them when the need arises.
At the C4DT factory, we manage a few servers with multiple services. We have started to move from manual configuration to using Ansible, and the results are very encouraging. If we have piqued your curiosity, jump in and have a look at the quick start!
Code formatting is the most known instance of bikeshedding: everyone has a different opinion on it and nobody is willing to compromise. Do you remember the hours-long discussions on using tabs versus spaces? Where to add empty lines? Alignment of fields? For some years now, many languages provide their own code formatter, Go has
gofmt, Rust has
cargo fmt, some have a standard-by-usage, Python has
black, Scala has
scalafmt, but nothing was appropriate for the web languages in general.
prettier, a newcomer in the formatting world, aimed at precisely theses languages.
One of the most interesting features it has, is that it doesn’t compromise: you can’t (much) configure it. As such, no more endless discussion on it, just use it™©®! It has many advantages, such as splitting a function call when too many arguments are passed. Or merging an object initialization if it is small enough.
Overall, formatting is not though anymore, just done.
I use it in my new web projects, where it’s really easy to integrate. First, set it up in your code-editor, then make a first pass with (at project root) (it will only format known files):
npx prettier --write .
As your branch will be quite hard to rebase, do merge other PRs before that and sync with your team as when it is best to apply this new coding guideline. You’ll also need to add the next line to your CI:
npx prettier --check .
And you’re done, formatting is done by editors directly, checked by the CI, and everyone can read it.
Now, get on with more interesting programming tasks than dealing with how to format code, and don’t argue with it anymore.