Solidity: The Product Vision

This is the first in a series of 4 essays that analyse the architecture of Solidity. We start off with a description of the vision underlying Solidity and a peek into the future of Solidity.

Aim of the project

Solidity is closely tied to Ethereum, so too does Solidity’s vision build on Ethereum’s.

Ethereum’s vision

As a blockchain technology, Ethereum is a platform with a couple of remarkable properties. In a nutshell, it is one implementation of a distributed ledger, for all practical purposes immutable. It also has a diverse community of both users and contributors, as opposed to being either targeted at one enterprise user or having its development steered by one product owner.

These two reasons explain the variety of visions assigned to it over time, which you can check out below¹:

• Vitalik Buterin, who published the original Ethereum whitepaper, was a founding editor of Bitcoin magazine and very engaged with its development. When VCs started rushing in to fund Bitcoin 2.0, he was frustrated with the isolation of the new projects branching from Bitcoin, akin to having a “separate hardware module for solitaire, […] for Internet Explorer, […] for World of Warcraft”. This led to him developing Ethereum as a platform for wildly different applications, an approach reflect in the name Ethereum, stemming from the concept of Aether, an imperceptible material supposedly filling the universe.
• This vision was further crystallized with the advent of dApps (distributed apps), presenting the Ethereum network as a “world computer” running on gas (users’ computing power).
• Ethereum is also seen as a platform for DAOs (Decentralized Autonomous Organization), which as the name suggests mean to be analogous to real-world organizations, except ownerless.
• Smart contracts are seen as particularly fit for ICOs (Initial Coin Offering), a usage both popular and involving large monetary amounts.
• One of the most visible Ethereum projects ever was CryptoKitties, where the kitties were actually assets stored on the Ethereum blockchain. NFTs (Non Fungible Token) have sizable mind-share with Ethereum enthusiasts.
• The decentralized aspect fed into the narrative of DeFi (Decentralized Finance). A usage this time with the potential of rendering the global economy more efficient, fairer and more stable, in the wake of the 2008 financial crisis it has found wide acclaim as an alternative to central mismanagement of the global economy.

A remarkable feature of Ethereum is its potential to disrupt not only technologically but politically as well.

Solidity’s vision

Solidity’s goal is to promote smart contracts. To do so, it aims to²:

1. Let everyone write smart contracts
2. Let them write secure contracts

End user mental model

Solidity is a programming language for constructing smart contracts. Its end users are programmers who want to implement smart contracts on the Ethereum blockchain. As Solidity is a programming language, all requirements and expectations that would be in place for regular programming languages are also the case for Solidity. The way Ethereum handles smart contracts however introduces additional requirements not seen in regular programming languages.

Code execution costs

Executing code on the blockchain is not free: it costs ETH in the form of gas. Some instructions are a lot more expensive than other ones. At the same time, some instructions are a lot cheaper than one would expect. For example multiplication operations have the same gas cost as division operations, whereas in most languages division is a lot more expensive than multiplication.

Because of these not always intuitive gas costs, one might want the language’s compiler to optimize not only in execution speeds, but also on gas costs. Maybe even on gas costs alone as the smart contract’s programmer does only care about their executing costs, and not the speed. Next to these alternative optimizing goals, Ethereum wants to know the maximum gas a program can use. As these exact gas costs are only known at runtime, an estimation system would be a good component to have.

Solidity contains solutions to both problems mentioned above. Its built-in optimizer performs both usual optimizations but also performs gas-based optimizations. Next to this a system is in place for the end user to calculate the maximum gas costs of their contract.

Key capabilities and properties

A few key capabilities and properties of Solidity can be defined:

• It supports a versioning system where the version in which a contract was written is explicitly mentioned in the contract. Furthermore, tools are supplied with which source code can be transformed to newer versions.
• Solidity is object-oriented and high-level. It supports multiple inheritance and complex type definitions.

Stakeholder analysis

The stakeholders of a software project can be divided into five groups³: end users, the business, customers, domain experts, and developers. Below we will analyse the different groups and their stakes in the project. To keep the analysis concise, we will leave out the business and the domain experts as Solidity is open source and the domain experts are in this case developers.

Stakeholder	Stakes
End users	Programming languages are used solely by programmers, as using a programming language makes you a programmer. Therefore, the group of end users of Solidity is easily identifiable: every programmer that uses Solidity to implement smart contracts. The end users benefit from the features that Solidity offers and that allow them to implement their projects
Customers	The customers of Solidity are essentially its users in a broader sense, ranging from a programmer that uses the language to write its own smart contracts (the end users) to companies that sell smart contract implementations or use smart contracts for their operations. So in a lot of cases the customers of the language are the consumers of the service that the language provides. Therefore, the resulting language is either directly beneficial to them or as part of a product.
Developers	The developers of Solidity are the contributors of the project, i.e. the programmers that develop the Solidity language and its documentation.

The groups of end users and developers intersects, as a lot of developers will use the language themselves. They directly benefit from (positive) changes they make.

From the analysis it follows that all groups overlap. It is nevertheless interesting to distinguish the groups as they are not proper subsets of each other.

Context of the system

Solidity was created by Dr. Gavin Wood as a language explicitly for writing smart contracts with features to directly support execution in the decentralized environment of the Ethereum world computer. Solidity is now developed and maintained as an independent project on GitHub. In this section, we look at the current and future context in which the system operates.

The main Entities or Actors in the Solidity system are:

1. Solidity compiler: The main product of the Solidity project is the Solidity compiler, solc, which converts programs written in the Solidity language to EVM bytecode. The project also manages the important application binary interface standard for Ethereum smart contracts. Each version of the Solidity compiler corresponds to and compiles a specific version of the Solidity language.

2. Ethereum Virtual Machine: At the heart of the Ethereum protocol and operation is the Ethereum Virtual Machine, or EVM for short. It is the part of Ethereum that handles smart contract deployment and execution. At a high level, the EVM running on the Ethereum blockchain can be thought of as a global decentralized computer containing millions of executable objects, each with its own permanent data store.

Product roadmap

This section looks at the product roadmap, laying out the main future directions anticipated for the upcoming years.

Issues

Solidity currently has 678 open issues with 27 labels varying from translations to difficulty levels to bugs to features. Among these, there are 116 open features reported by various authors.

The current sprint-cycle is 2 weeks. There are 2 current open milestones:

1. Sprint 3: Due March 12, 2020 with 11 issues
2. Sprint 4: Due March 26, 2020

The past releases can be found here

Projects

The current bugs and features for the forthcoming releases have been organised into projects.

There are currently 12 open projects:

Project	Description
Natspec	Issues regarding the Natural Specification Format
Wasm/Ewasm	Issues in Ethereum flavored WebAssembly (ewasm)
Reducing Technical Debt	Issues to reduce technical debt in the Solidity code
Sol -> Yul Codegen	Manages tickets related to the effort of compiling Solidity code to Yul code
Emscripten	Issues for Emscripten
Documentation translation	A project to track the progress of Solidity docs translations
Yul	Issues for Yul
Zeppelin Audit	Issues that came up during the audit by Zeppelin
Backlog (breaking)	Breaking changes that the team weakly agreed to implement
Consolidate inheritance rules	Issues to incorporate inheritance rules
SMT Checker MVP	This project is unrelated to release projects and aims to develop the SMT checker towards a minimum viable product.
Backlog (non-breaking)	Non-breaking changes to be made in the code

Development

Solidity is a relatively new language with a fast-pace of continuous development.

The guidelines for development are spelled out here. There are public team calls on Monday at 12pm CET and Wednesday at 3pm CET for interested contributors.