Simplicity, simply

Simplicity is a proposal for a new language for programmable blockchain scripts. It tries to learn from and address the flaws with Script and Solidity, the two dominant languages.

The Simplicity paper can be found here: https://blockstream.com/simplicity.pdf.

Script & Solidity

Script is a Forth-like stack-based language. This means that we push data onto a stack, and whenever we reach an operator, we pull data from the stack to operate on. Script has no awareness of the chain. It only knows about the transaction that contains it. This means Script programs never change their result based on what other people are doing, which is extremely useful. There are very few operations in Script, so there are pretty strict limits on what you can do. We know which operations are expensive, and we know there are no loops or new operations, so we can check in advance how much time a Script program will take to execute.

Solidity is a Javascript-like language that compiles to EVM bytecode. It allows for loops, function definitions, and access to the EVM's memory. Solidity programs are compiled, and stored on the chain in what's called a "smart contract." Because Solidity programs may be complicated, miners never know in advance how much work it'll take to execute one. Or whether it'll just be a never-ending loop. To fix this the EVM requires that you send gas with your transactions to pay miners for running your program. When the gas is used up, the program stops. And because Solidity programs might depend on what else is going on in the EVM, they might have a different result every time you run them.

Simplicity

Simplicity tries to stay fast and chain-state-independent like Script while adding most of the versatility of Solidity. It does this by removing loops and structuring the language to allow easy "static analysis."

In layman's terms, we can skim through a script before executing it and quickly count up how much effort it'll take to execute. In Script, we do this in a hacky way by saying "oh, signature checking is the only expensive thing" and never allowing anything to be added. In Simplicity, we have a small list of operations, and we know the exact cost of each of them. When we build larger structures from them, we know exactly what the larger structures cost too. We just add up the costs of the basic operations we used.

Jets

Once we build up a structure we like, say, the SHA256 hashing algorithm, we can standardize it into something called a "jet." Jets are super cool. We know that the program doesn't depend on anything outside the transaction. This means we know that every structure we build will always behave the exact same way every time. If we know that, we can just skip executing it, and jet right on over to the end state. Jets are shortcuts for common useful structures. Once a jet is built and standardized it becomes fast and cheap because we skip a bunch of intermediary work. We can then add it to our list of basic operations and use it to build new structures and even new jets!

Because jets are always built from the basic operations they don't break static analysis. You can't add loops via jets, or do anything else that was previously impossible. They make useful things faster and easier without breaking anything. Extensibility without risk.

As a side note, jets in special cases are allowed in Solidity. But usually have bad incentives. They must be designed by manually examining each specific contract. And these contracts must be either chain-state-independent or forced to error in a specific way. The easiest EVM jets to create are miner-forced errors. This could be very bad for users and Solidity developers.

MAST

Simplicity is also designed to take advantage of a neat upgrade called Merklized Abstract Syntax Trees (MAST) that has been on Core's roadmap for a long time (see BIP114). MAST lets you build large programs, and then only show the chain the parts you want to execute. This means that less goes on chain, which is good, but also that the rest of the program stays private.

Right now, I can set up a Script program that lets me spend coins after 6 months or lets 3 of 5 friends move the money before that. But when I spend the coins after the time limit, everybody learns who those 5 friends were. Or if they spend the money, everyone learns that I was going to gain access if they didn't. MAST lets me publish only the part that allows me to spend money, and keep everything else private. Simplicity will allow this out of the box, which is a big upgrade in privacy.

Bitcoin integration

Simplicity, when it's ready, can be implemented as a soft fork using script versions. Now that SegWit is active, every program on Bitcoin has a version number that tells nodes how to interpret the script. This means that we can fix bugs in Script and SegWit without invalidating old transactions. It also means that we can add entirely new scripting systems like Simplicity.

As Mark Friedenbach (maaku) pointed out on the bitcoin-dev mailing list recently, the version number can encode not just whether a script is written in Simplicity, but also what jets it needs. However, this doesn't mean that implementation is right around the corner, or even anywhere on the horizon. Greg Maxwell (gmaxwell/nullc) outlined a host of problems to solve before we can even think about soft forking it in.

Conclusion

Simplicity is very promising. It's accompanied by formal proofs of its function, and it solves some very pressing problems in blockchain scripting. It'd be a big upgrade over Script and could provide the safety guarantees that are missing from Solidity. Jets are interesting, But don't hold your breath for a soft fork any time soon.