1 of 25

Experimental Solidity

Daniel Kirchner (ekpyron)

2 of 25

The Current State of Things

  • No Generics
  • Assortment of Hard-Coded Language Features
  • Inferior Extensibility
  • No Formal Semantics
  • High Cost and Risk for introducing new Features
  • Lack of Features

3 of 25

Path A

Path B

  • Keep extending the language with compiler-hardcoded builtin functionality
  • Further increase language complexity
  • Quick Gains; High Risks
  • Reduce language complexity
  • Target a small lean core language
  • While making safe extensibility a first-class priority
  • Move Feature Development to a Standard Library
  • Long-Term Path

4 of 25

Path A

Experimental Solidity

  • Keep extending the language with compiler-hardcoded builtin functionality
  • Further increase language complexity
  • Quick Gains; High Risks
  • Reduce language complexity
  • Target a small lean core language
  • While making safe extensibility a first-class priority
  • Move Feature Development to a Standard Library
  • Long-Term Path

5 of 25

Experimental Solidity

  • pragma experimental solidity;
  • No stability and security guarantees.�**DO NOT USE IN PRODUCTION**
  • Fast and breaking iterations towards a final design.
  • Allow Early Feedback
  • Ultimately transition to standard solidity�in a breaking release (multi-year plan)

6 of 25

Design Goals

  • Simple Core Language�Long-term: formal semantics!
  • No hardcoded builtin functionality
  • Features and Types implemented in a Standard Library

7 of 25

Simple Core Language

  • Hindley-Milner-Style Type System�with Polymorphic Functions; no Let-Polymorphism
  • Simple Type Classes (Rust term: traits):�single-parameter type classes with associated types
  • Small set of primitive types:�word + Ingredients for Algebraic Data Types
  • Definition of Types / Type Constructors in-language
  • Decidable Type Inference and Principal Types
  • Inline Assembly

8 of 25

Features and Types in Standard Library

  • Base Cases in Inline Assembly
  • Composition to more complex structure
  • Categorization of Types using Type Classes
  • Inductive Constructions on Types
  • Complex language features become self-specifying

9 of 25

Language User View

Implementor &

Library Author

View

  • Breaking Syntax Changes with Upgrade Path
  • Some new restrictions (e.g. no implicit conversions)
  • New functionality
  • Fast and safe language extensions
  • Feature implementations are written in Solidity
  • Advanced features to construct new types
  • Features become auditable and verifiable
  • stdlib can be shared between compiler implementations
  • stdlib can be extended by a proposal mechanism

10 of 25

Syntax Surprises: Postfix types

function double(x:uint256) -> uint256 {� let doubleX:uint256 = x * x;� return doubleX;�}

// Complex type expressions become parsable.

let f:(uint256,bytes32|bool)->int;

11 of 25

Syntax Surprises: Type Classes & Quantifiers

forall type:Multipliable.

function double(x:type) -> type {� let doubleX:type = x * x;� return doubleX;�}

12 of 25

Syntax Surprises: Type Inference

forall type:Multipliable.

function double(x:type) -> type {� let doubleX = x * x;� return doubleX;�}

13 of 25

Syntax Surprises: Type Inference

function double(x) -> _ {� let doubleX = x * x;� return doubleX;�}

Every expression (including functions) has a unique most general type (principal type) that can be inferred by the compiler.

14 of 25

class self:Multipliable {� function mul(x:self, y:self) -> self;�}

type uint256 = word;

instantiation uint256:Multipliable {

function mul(x:uint256, y:uint256) -> uint256 {

let x_rep:word = uint256.rep(x);

let y_rep:word = uint256.rep(y);

let r:word;

assembly { r := mul(x_rep, y_rep) }

return uint256.abs(r);

}

}

15 of 25

class self:Multipliable {� function mul(x:self, y:self) -> self;�}

type uint256 = word;

instantiation uint256:Multipliable {

function mul(x, y) -> _ {

let x_rep = uint256.rep(x);

let y_rep = uint256.rep(y);

let r;

assembly { r := mul(x_rep, y_rep) }

return uint256.abs(r);

}

}

16 of 25

trait Multipliable {� function mul(x:self, y:self) returns(z:self);�}

type uint256 is word;

implement Multipliable for uint256 {

function mul(x, y) returns(_) {

let x_rep = uint256.unwrap(x);

let y_rep = uint256.unwrap(y);

let r;

assembly { r := mul(x_rep, y_rep) }

return uint256.wrap(r);

}

}

17 of 25

How far can this be taken?

  • All high-level language features become definable.
  • Including data locations:

type memory(a) = word;

  • Loading from/writing to memory/storage/calldata can be implemented as type class instantiations.
  • ABI Encoding becomes a Type Class
  • Dispatch Generation becomes a Higher-Order Function

18 of 25

How far can this be taken?

  • Source of Truth lies in Inline Assembly Implementations
  • Code Generation becomes�Monomorphization + Type Unfolding (yielding Yul)

​

  • Usable generic abstractions over, and encapsulations of, assembly become possible.
  • In experimental Solidity, think of assembly�as Rust’s unsafe.

19 of 25

Syntax Sugar

  • Achieving parity in Usability and Readability:�Need Syntax Sugar!
  • Example: contract definitions as sugar over dispatch and storage layout generation (both definable in-language!)
  • Two options:
    • Syntax sugar close to current Solidity
    • Opportunity to improve syntax and change paradigms

-> Decision based on community feedback

20 of 25

A Guess of a Timeline

  • Q1 2024: prototype with only value types and single-parameter type classes without associated types
  • Later in 2024: reference types and full type classes
  • End of 2024: kickoff of stdlib development
  • No Syntax Sugar in 2024!

21 of 25

A Guess of a Timeline

  • 2025:
    • stdlib proposal process
    • stabilization of the type system
    • work on syntax sugar
  • 2026:
    • experimental Solidity becomes stable

22 of 25

The Future of Solidity Feature Development

  • Feature Request
  • Standard Library Improvement Proposal
    • Implementation of the Feature in-language
    • Definition of required syntax sugar
  • Feedback Process -> Final Draft
  • Auditors and Formal Verification experts verify the Proposal
  • The Proposal is validated and shipped as part of the compiler standard library.

23 of 25

The Future of Solidity Feature Development

  • Core language changes become very rare.
  • If necessary at all, they originate from�Standard Library Improvement Proposals�(in case the core language lacks expressivity)

-> The core language stabilizes

-> Community demand for features can still be met as collective effort of the community in Standard Library Development, Auditing and Verification.

24 of 25

The Future of Solidity Feature Development

  • Possibly multiple variant of a Standard Library
  • Checked Arithmetic and Unchecked Arithmetic Types
  • Stable and validated standard stdlib vs�funky optimizooor stdlib
  • stdlib variants for L2s

25 of 25

Thursday,

Nov 16, 2023

Istanbul, Türkiye