[Call for feedback] The Long-term Solidity Roadmap

Feedback
1

We have just published the first introductory blog post in a series called “The Road to Core Solidity“, through which we will share our direction for the language.
→ The Road to Core Solidity | Solidity Programming Language

Our goal with the series is to show the community how we see the project’s long-term roadmap shaping up. While we are confident about the general direction, there are parts about the future of the language that we would like to invite our user community to discuss and provide constructive feedback on.

We are starting this forum thread to facilitate such open discussions on the upcoming parts of the series. We request readers to take the time to go through the overview shared in the blog post above and get involved in the process going forward by sharing their thoughts below this thread.

:memo: Note: The Solidity team hosts weekly language design discussions to provide a channel for our community to meet with us and contribute to the future of Solidity. If you have issues or pull requests to discuss, or are interested in hearing what the team and contributors are working on, you can join our public team call every Wednesdays at 3PM CET/CEST. The call takes place on Jitsi: https://meet.solidity.org

Feel free to drop in and help us shape the future of Solidity.

Sincerely,
The Solidity Team

2

Hi,

First, I want to say thanks for writing the blog post and providing the community with updates on the roadmap.

I have a couple of questions (mostly out of curiosity):

How far are you on the YUL refactoring? Regarding the move toward an SSA + CFG-based IR, are you planning to have two “YUL” IRs, with one for inline assembly and one for the compiler’s internals (assuming you would translate the “human-readable YUL → compiler’s YUL”), or do you plan something different?

One of the main complaints from the developer community is around the speed of compilation. Do you have any plans to improve the speed from a design standpoint (e.g. with incremental compilation or similar techniques)?

1 Like
3

Hello! Thanks for giving it a read.

Re: your curiosity about the status of Yul refactoring, we plan to keep the inline assembly around for the time being and the SSA-CFG IR is actually internally derived from Yul. Currently, we have implementations for a compilation pipeline that optimizes Yul code with the current optimizer, transforms it to SSA CFG form, and further performs codegen on the result.

Additionally, we will move data-flow heavy optimization passes to the point where we are already in SSA-CFG form, integrate stack-to-memory moving at the point of stack layout scheduling, and finally stabilise and fuzz this implementation. The experimental version of this pipeline will be made available soon for the users to try out and give us feedback on.

With this, the SSA-CFG upgrades should already help with reducing compilation times in the IR pipeline. Re: speeding up compilation from the perspective of design, we are considering incremental compilation and parallelisation further down the road. Although items such as incremental compilation are on our long-term roadmap wishlist that we will be publishing soon as part of this new series, we do not have a concrete timeline for them yet.

1 Like
4

I am working with a group of developers to create a new general smart contract library called Compose. One of our design objectives is to make the smart contract code within the library itself very readable and easy to understand. We feel it is a good thing (for a number of reasons) for the users of our smart contracts (other smart contract developers) to be able to quickly and easily read and understand our smart contracts.

To simplify, and make our contracts easier to read and understand, we limit what Solidity features can be used within the contracts in our library. For example we don’t allow inheritance in our contracts, we don’t allow modifiers, we don’t allow using for syntax, we don’t allow public or private functions, and we have other restrictions. Just limiting the number of features used simplifies the code and helps keep it consistent. Keep in mind these restrictions apply to the code within the library, they do not apply to the code written by users that use our library.

We believe that good software is software that can be understood, and that the difference between a good programmer and a bad programmer is understanding. And so we write our smart contract code in a way that is meant to be easily understood by others. And we have a thought about the future. In ten, thirty or one hundred years, how easily will people be able to read the source code of our deployed contracts?

I am wondering how some of the new features proposed for Core Solidity can help us write code that is easier to read and understand, than what we have now.

The Solidity blog post mentions these core features of Core Solidity:

  • Generics / parametric polymorphism
  • Traits (a.k.a. typeclasses)
  • Hindley-Milner type inference (known from languages such as Rust or OCaml)
  • First-class and anonymous (a.k.a. lambda) functions
  • Algebraic data types
  • Pattern matching with exhaustiveness checking

I am interested in future blog posts from the Solidity blog to explain and show examples of how these features can help us write code that is simpler, easier to read and understand, than what we have now.

Onchain Composability

Another core aspect of Compose is that it is designed for onchain composability. It uses EIP-2535 Diamonds for the creation of diamond contracts that can utilize and reuse already deployed facet contracts. Any number of diamond contracts can potentially mix and match with different onchain facet contracts. Facets are like onchain lego pieces that can be attached to various diamond contracts.

I would like to know if there are ideas or plans in Core Solidity, or aspects or ways to leverage Core Solidity for onchain composability, or make EIP-2535 Diamonds easier to implement, etc.

5

Well, two main things are the custom storage layouts and a delegatecall mechanism.

Layouts (beyond the rudimentary support we already shipped) are work in progress. The implementation part is easy, the main blocker is still the time needed to properly design it to address all use cases. Depending on the demand, that feature may still ship in Classic Solidity (more details will come with the roadmap wishlist).

As for delegatecall - that’s a tough one. We’ve long been dissatisfied with libraries and planning to drop them in the transition. The problem is that a replacement mechanism is still an open question that we’ll have to figure out.

1 Like
6

@cameel Thanks for letting me know the status of these things.

In case it is useful, for custom layout locations we are currently using EIP-8042 Diamond Storage, which works quite well, and that pattern has been in use for 5 years.

I like Solidity libraries when using them for their internal functions. Using them is very explicit and nice. However I do not use Solidity libraries with delegatecall (external functions), which is what I think you were referring to.

7

Hi Everyone,

Very excited about solidity core, especially generics and new features. I would like to see if we can partner more closely with Solidity language team on this.

Few touch points:

1/ I am reading lectures on solidity at Invisible Garden - 3 weeks Solidity/Blockchain/Cryptography bootcamp in Buenos Aires. I would like to pack as much as possible knowledge about upcoming features to students, so any additional documentation is very welcomed.

This also is non-profit activity, students get education for free, hence any support is super welcomed.

2/ We have started working on Ethereum Distribution System and ERC7746 hooks a while ago. the big problem with those initiatives is that solidity lacks generics.

The industry feedback was that lack of generics make this initiative senseless - we need to be able properly resolve types for abi.encode / abi.decode and ideally meaningful runtime errors.

It seems like solidity core can open up way for these projects becoming really well adapted.

Very excited to see your work and roadmap,

If you want to get in touch please hit me up on X (@iampeersky) or Git (@peersky)

PS> sorry cannot include links in this post.

8

Will Core Solidity still have Solidity libraries for internal functions or something equivalent to this?

Solidity libraries with internal functions are extremely useful for utility functions and other uses. The smart contract library I am working on, Compose, does not use inheritance, and so entirely relies on Solidity libraries with internal functions to share functionality between contracts.