Solidity Core Will Keep Compiler Devs Happy. What About Us?
My feedback on the proposed evolution of the language.
The Solidity team shared The Road to Core Solidity, a plan for how to evolve the world’s most popular smart contract programming language.
In short, they are proposing:
A split of the language into Core Solidity and Classic Solidity;
Core Solidity would introduce a better type system with generics, first-class functions and algebraic data types;
It will also have a built-in standard library (presumably with some overlap to OpenZeppelin).
As someone who has been using Solidity since 2018 and written in 20+ other programming languages, I have some thoughts.
HOW TO THINK ABOUT THE PROBLEM
It’s tempting to jump in immediately and offer suggestions about what language features I'd like to see but that’s what the developer survey is for.
The best place to start is instead to work out how to prioritize changes in general.
Solidity is not Haskell.
Solidity is not a language that gets to be opinionated in an effort to appeal to a specific subset of developers. It’s literally *the* platform language of Ethereum, its L2s and by extension all the parasitic Real World Asset chains that will be independent L1s but claim to be “Ethereum-compatible”.
Evan Czaplicki spoke about the dichotomy of a Platform Language and Productivity Language in Lambda Days. Productivity languages should be opinionated but Platform languages don't get to run off and become Productivity languages overnight.
The resources dedicated to improving Solidity are highly limited.
There haven't been enough resources to tackle the most fundamental issues that get repeatedly mentioned in the survey such as gas efficiency and stack-too-large errors (Vyper now has a reputation of being more gas efficient despite a slow start; I know, I personally submitted a couple Vyper compiler optimizer bugs back in the day!).
These could be resource constraints or political constraints but that doesn’t really change the conclusion.
LLMs are changing programming.
Even though we now have 10 years of learning of how people want to write Solidity, I'd argue that the first 9 years have limited information value. Maybe only the last 6 months are really useful.
Most developers are shifting to writing a lot less code and spending more time reviewing it. Smart contract languages require more care and may be the last domino but they will fall.
All successful generically typed languages like Rust were built for a very different type of programming workflow, it may not be right to make a big bet now that is inspired by how these languages are designed.
Developers don't decide how to write Solidity, auditors do.
If you get an audit from a reputable auditor and they flag that you should do things differently for safety you generally do.
Smart contract development is so plagued by the possibility of critical exploits that it actually makes sense to optimize the way you write Solidity around safety and accuracy.
With that in mind, here’s my priority list.
1. AGREE WHICH COMPILER WE SHOULD USE
Right now it’s not even obvious what version & optimization configurations are valid:
Which version? Auditors have at times criticized using Solidity versions that are too recent. Other auditors only recommend the latest versions of Solidity.
To via-ir or not? Enabling
via-irreduces gas consumption and get under stack-too-deep errors (sometimes), however, it makes builds impossibly slow and also is highly non-deterministic.Custom runs? Sometimes you need to add runs just to go under the 24KB limit.
Core or Classic? Is this another choice we’ll have to make now? When will Core be “safer”?
I don't even care which configuration, but it would be nice to agree on one that:
Is universally approved by auditors,
Helps avoid stack-too-deep errors (or eliminates them entirely),
Is efficient,
Can be reliably tested in development through fast build times (it’s OK if final build times are slower).
I kind of agree with Georgios here, these are the most important issues.
Stack-too-deep errors is not just a skill issue, we run into them repeatedly in the Aera project and it’s always obvious how to fix them (bearing in mind that sometimes they get triggered by changing unrelated parts of the codebase) but it’s also always annoying because the compiler is effectively forcing the developer to do a rewrite pass step.
2. IMPROVE GAS EFFICIENCY
I'm really impressed by Notion’s team. Despite many exciting things they could have worked on for the last 5 years, they maintained an obsessive focus on performance and offline.
They did this knowing very well that no matter how much they improve performance for things like tables, people would just use Notion even more until it broke again and would keep complaining about performance.
They did this knowing that the work only gets more tedious over time. As soon as you exhaust the low-hanging fruit, you have to keep measuring and experimenting with less and less results. Yet they persevered.
For smart contracts, compiler performance is even more important, it literally equates to money and adoption.
Gas efficiency is also not a skill issue. In Aera, we’ve had to write several parts of the codebase in assembly which ideally could have been handled in Solidity. We didn't celebrate this, we tried to avoid it as much as possible. Here are some functions to look at.
Adding constructs that remove the need to write assembly would do more to increase safety and reduce auditing costs than helping people rewrite reasonable Solidity code into code that is protected by more advanced types.
3. MAKE COMPILER DEVS HAPPY
Surely Solidity compiler developers control over 90% of the bytecode that ends up onchain? That’s huge financial impact.
It’s important that this team has high morale and can attract and retain high quality talent.
Do rewrites make sense? No, they almost never do. There are always gradual refactoring paths that incrementally introduce features while leveraging existing tests and code.
There is always a prioritization that maximizes short-term impact from that refactoring.
It took the StarkWare team 1-2 years to fully rewrite the Cairo compiler and they are some of the most productive developers in the industry. They also had the added benefit of Cairo 1 being incredibly verbose and much easier to throw away than a language that is widely loved, understood and used in production by many teams.
Indeed the rewrite probably doesn't make sense here from a purely rational lens.
Does Solidity desperately need generics? I've argued in the past that there are real drawbacks to not having them:
Solidity was developed quickly and inspired by JavaScript and C++. As a result, the type system falls short of modern expectations. Not only does Solidity lack enums, generics, and other type safety features, but it also tries to compensate for these missing pieces in ad hoc ways, like by introducing user-defined value types. As a result, inheritance is highly risky because instead of composing property-checked composable code, Solidity simply appends imperative code.
As a result, Solidity libraries are very “flat” (this is also often recommended as necessary from a security perspective) and usually use OpenZeppelin contracts, maybe an ERC template, and write everything else from scratch rather than building on existing abstractions.
In general, Solidity could definitely benefit from “zero-cost” abstractions as a way to help create more safe and widely reusable library code, but I'm not sure it is worth it if the cost is building an entirely new compiler project and not working on the pressing optimization issues mentioned above.
However, the biggest benefit of letting the Solidity team cook on generics AND move beyond the legacy codebase is that it is fun!
Compiler devs love to build build fancy languages. They love to do specs (via fun tools like Lean), they love to build type systems from scratch and they love thinking about syntax. All these things are much more fun than optimizing gas consumption and therefore should be properly weighted as a way to retain the team.
4. MAINTAIN OR IMPROVE READABILITY
Nick Mudge made a good point in the forum: the new compiler features need to enable code that is simpler, easier to read and understand.
This is crucial both from the perspective of security and also from the perspective of how software development is changing with LLMs.
If I were to make changes to syntax, I'd focus on changes that improve the life of auditors and code reviewers, not those writing the code. Unfortunately this is harder to copy from other languages and requires some exploration. Enabling some of that exploration to happen in libraries is probably a good thing.
Of course the priorities above are not the priorities reflected in the blog post, but here’s my optimistic read of the update:
Working on fun things like generics, traits and other functional programming elements will make devs happy. That’s why I don't think pushing back on these changes is very constructive;
By doing so the team will hopefully rewrite the existing compiler pipeline in a way that improves gas efficiency (MLIR is pretty cool as far as compiler infrastructure is concerned). Maybe stack-too-deep gets fixed too;
Maybe Solidity Core builds around a narrower set of valid compiler configurations and is developed in closer collaboration with auditors;
Still plenty of time to pull the plug or steer course on syntax changes down the road as we learn more about LLMs.
And I really like some of the procedural changes here such as allowing more open community feedback on the new language, inviting other teams to build against the same spec, etc.
Overall, it’s exciting to see a new vision and energy around Solidity even if it’s not 100% aligned with what would improve our experience the most working on Aera.