[Amsterdam] Devconnect 2022

I'm writing this from the lounge in the airport, unexpectedly. My flight back got cancelled — supposedly a common occurence in immediate post-covid travel context — and so I'm waiting for a different flight to a different city. I'll be home one day later which does not change anything except I'll do something unplanned: write this blog post in extra time in the airport, hotel and bus.

I find this approach useful in general: when something unplanned and rather unpleasant happens I try to only be worried for a brief moment and then I strive to find something or do something that negates the potentially negative effects plus upgrades the entire situation into a net positive (sometimes it takes minutes, other times days or even years).

This post will not be a detailed review of Devconnect which is going to last for more than a week with almost one hundred (!) big or small events. I only visited two events and I'll try to sum up what I got from these two events. I plan to watch recordings and other developments from most of the rest of this distributed / emerging conference.

Before going more concretely into my takeaways from two events, namely Solidity Summit and Modular Summit let me try to paint the current blockchain landscape the way I perceive it.

~ The Evolving Blockchain Landscape ~

Blockchains are still very mysterious and intricate (for everyone, including people building them), the reason for this is because they are scientifically and socio-technologically a novel and complex construct. They are also largely invisible, they are mostly software. Blockchains are not new buildings made of bricks or a new type of fast train or anything else resembling already known things that can in addition be touched, felt and experienced directly. They are a new type of system. You cannot see these systems. You have to think, observe and make a mental model from the observable effects. Everyone is building a slightly different mental model for themselves about whatever is currently happening (and this is fine). In addition we now have a complete cambrian explosion of different types of blockchains as well. A few of these major "Layer ones" will survive, most won't ... but there is also this new school of thought called Cosmos which believes there will be millions and millions smaller app-specific chains. Go figure! Amazing... and complex to wrap your head around. Fo' sure!

Blochains are only slowly — relatively speaking — catching on but we have to remember the saying "Slowly, then suddenly". I believe we are on the verge of shifting to Blockchains suddenly going mainstream. This process may still take a decade but in grand scheme of things this is just a blip. We are talking about re-architecting the world, after all.

This is truly the most interesting time for the emerging Blockchain space. It has evolved just enough so that there are no existential or viability questions and still so far from any endgame that almost nothing is set in stone in regard to details of the final outcome (in the form of dynamic equlibrium since there will be no "final outcome"). Blockchains are not going anywhere, they cannot be uninvented at this point. Train has left the station for better or worse. Don't listen to anyone claiming to know where exactly this is going or not going... they just don't know because nobody does. We could call it natural progress though. Axiom number zero is that autistic and non-autistic developers are not going to stop building these systems and they themselves plus many others are going to use these systems. These systems are also undestroyable. Conclusion again is that with proper security models many different blockchains will stay around forever. So they will continue bringing change. What type of change exactly is to be seen... or not, maybe just intuitively felt because some effects may indeed be very sublime.

As is the word decentralization so is the word blockchain very much an overloaded concept. Without detailed study one stands no chance of being able to parse different meanings and how they might fit together on the other side of this decade's flux. This is the main reason I'm closely observing the cryptosphere from a broad perspective. I want to understand what parts constitute this upcoming industry and I try to avoid maximalism if at all possible when in that mental frame. Maximalism of any type warps reality. Also it was more useful in previous years, now things are how they are, they are evolving almost independently from the influence by any individual or even bigger sub-groups of individuals.

Most current big ideas will exist from now on and they will have to co-exist with other big ideas altough not always 100% philosophically/technologically compatible. Some will fail spectacularly but mostly they won't fail because of anything any imagined competitors will do to them but because of some kind of fundamental design issues (or just bad luck at unfortunate moments).

Solidity Summit

Ethereum has brought upon the revolution in programmable blockchains.

Before Ethereum blockchain(s) were minimally programmable and certainly did not support any type of general purpose (eg. "turing-complete") programming.

Solidity is the most widely used programming language that runs on Ethereum and on other chains that are EVM (Ethereum Virtual Machine) compatible. Examples include Fantom, this thing called BSC, parts of Avalanche, parts of Cosmos and Solana ecosystems (soon) and more.

EVM is the processor for Smart Contracts, it translates smart contracts written in Solidity and other supported languages into immutable autonomous agents (Smart Contract instances) running on the distributed Blockchain system.

EVM is the execution engine (more on this in next section — report from the Modular Summit). In traditional monolithic architectures (like pre-rollup Ethereum) execution part is tightly bundled with the consensus part of the system. Consensus is the thing that enables everyone in the system to agree on the same global shared state. If Smart Contract was running on just one machine then it would not be called Smart Contract and it would also not need the consensus system, such things are called normal programs. What is especially important in blockchain systems is the notion of permissionless consensus. Other type of consensus is permissioned consensus which also allows for distribution and globally shared state but everyone participating needs special permission from central entity operating such permissioned distributed system.

I'll go more into Solidity, the programming language part now and I feel that this intro and placement into context does not distract too much from almost entirely separate concept of Solidity programming language design.

Most people still say that Solidity resembles JavaScript but consider reading this section from the docs. Here is the relevant part:

In the early days of the language, Solidity used to be partly influenced by JavaScript. This was due to function-level scoping of variables and the use of the keyword var. The JavaScript influence was reduced starting from version 0.4.0. Now, the main remaining similarity to JavaScript is that functions are defined using the keyword function. Solidity also supports import syntax and semantics that are similar to those available in JavaScript. Besides those points, Solidity looks like most other curly-bracket languages and has no major JavaScript influence anymore.

In the intro section of documentation you can grasp the most important parts of language design:

Solidity is an object-oriented, high-level language for implementing smart contracts. Smart contracts are programs which govern the behaviour of accounts within the Ethereum state.
...
Solidity is statically typed, supports inheritance, libraries and complex user-defined types among other features.
...
With Solidity you can create contracts for uses such as voting, crowdfunding, blind auctions, and multi-signature wallets.

I first got to know Solidity when it looked like this:

pragma solidity;

contract StringConcater {

  function concatStringsOldWay() public pure returns (string memory) {
    string memory hiMom = "Hi Mom, ";
    string memory missYou = "miss you.";
    return string(abi.encodePacked(hiMom, missYou));
  }
}

It had no COLORS!

I decided to add some, first for SublimeText editor and

later also for use on GitHub (this just happened because my repo was selected for this purpose by relevant people who figured it might be good enough even then), like so:

Credits to Patrick for this snippet. I found it cute and will also use this to demonstrate something else (part of my ongoing job). Before going there I'd just like to mention that you can download and use Ethereum Syntax Highlighting in your SublimeText instance through SublimeEthereum package. If you've ever read any Solidity code on GitHub then you already see how SublimeEthereum syntax highlighting for Solidity on GitHub works. Between 2015 and 2021 it was around 80% accurate / satisfactory (it had some quirks in edge cases and usage of non-optimal coloring) and now it should be nearly 100% accurate. I'm very happy with current result.

As the language evolves further — and it is very much still evolving (this is one of my most important realization from the summit in Amsterdam) — it will have to be kept up to date with changing and evolving syntax and new features, keywords, constructs etc of Solidity Smart Contract programming language.

One very small and subtle example to illustrate the point is here:

Consider current GitHub state of things on this front:

Do you notice anything strange? Anything that can be improved? If not, there is no problem, such small individual omissions don't matter or do they? From my perspective they actually matter a lot because they compound.

The inconsistency is in the following:

abi.encodePacked is an example of a built in function on the magically provided object called abi. The concat function on string built-in type is also an example of such function and so it should be colored blue as well. And guess what, it will be colored blue on the next global GitHub syntax highlighting update (via the linguist project) because I implemented this change (along with some more improvements and updates).

The question if these things should be magically provided is a separate topic:

... so I won't go into this topic for now (maybe sometimes later). The point is that I still take care of such small improvements until there are bigger improvements to syntax highlighting that need to be taken care of. It takes quite some focus for me but it's far from really fundamental work on Solidity language design... it takes quite some mental effort because I really want it to be perfect and cover all possible edge cases as good as theoretically possible. It also takes some real decision making about what colors should actually be applied. In general it is more about persistence, caring and ability to make some (hopefully) good decisions than actual deep science. I think I got into this because since forever I was fascinated with programming languages but was much too shy to actually design one of my own (I don't regret that, that would be just too much long-term work).

I think this is actually a perfect contribution to the wider Ethereum ecosystem for me because I've always been a bit "spread too thin" – with a lot of different interests and so I couldn't handle more complex parts of contribution to the space, I think. I'd also like to be more capable in basic cryptography and fundamental distributed systems design but since I'm not (for now or ever), at least I feel like I'm doing something here... in addition to just exploring and learning as much as I can about as many parts of this tectonic shift. Maybe I'll be able to contribute more at some later point and on the distributed apps level, not more fundamental crypto/consensus parts of the story. It is possible I'd have some o.k. ideas about Solidity design down the road too if I manage to invest more time into actually using the language with all the features.

Modular Summit

... [ Will add this section a bit later or make it a separate blog post, somewhere on the way a) I lost focus b) realized I need some more deep reading to get to the gist of what is really going on here ]

Conclusion

Not saying that a cancelled flight is a catastrophe but in general it may be a bigger problem — if this happened on my way to Amsterdam I might have missed the exact thing because of which I went there in the first place. I'd still try to find something positive about it then but it might have been harder. I do expect a lot more unpredictable and unexpected things happening in this decade and further. Seems like such response has properties of antifragility and this is certainly a very useful trick and a design property that can be built into technological systems as well. Blockchain space is permeated with antifragile design. This type of design assures progress and resemblance of stability in unpredictable and challenging circumstances. We won't have any lack of such circumstances in years to come.

PS: Later I found out that the flight was cancelled because of personnel strike (consequence of covid shortage of staff and increased work during holidays) and many more people had problems in following days. So it basically confirms my theory that current situation is turbulent and maybe the entire future of the world looks more turbulent than ever before. Exciting! Maybe troubling as well but maybe this is the wrong frame of mind. These are just facts and we have to adjust and be even smarter / adjust our views, expectations and immprove our science of designing resilient sociotechnological systems.