We’ve just launched Scrypto – the first asset-oriented smart contract language that makes DeFi dApps both easier and safer to build. One question we’ve sometimes heard in response is this: “maybe it’s easy and safe - but is Scrypto Turing complete?”

The short answer? Yes, Scrypto is Turing complete.

But if you’ll stick with me, I think there’s a much more interesting answer.

Why does Turing completeness matter?

Usually when people ask if a smart contract language is Turing complete, what they’re really asking is “is the language highly flexible and expressive – will I be able to write whatever I want with it?”

This is because Turing completeness is a classic computer science term that is applied to a language (running within a certain computing environment) that has a certain set of properties that make it theoretically possible to perform any computation. The great majority of general purpose programming languages (and their computing environments) that you’ve probably heard of are Turing complete.

There are, however, some languages, often created for specific purposes, that are not Turing complete. They may be useful for certain tasks, but they are limited in some way. Sometimes these languages are extremely limited – only intended to do a few things very easily or very securely – sometimes they are general purpose enough that you might not even realize they are formally Turing “incomplete”.

And this is where smart contracts on blockchains enter the picture. When Ethereum introduced the EVM (Ethereum Virtual Machine) and the Solidity language for it, it was designed to be a “world computer”, and it was rightly hailed as a breakthrough for blockchain that Solidity was Turing complete running on the Ethereum network. In theory, any computation could now be performed on a decentralized platform!

So when we say that Scrypto makes DeFi smart contracts much easier and safer to build, it’s natural for people to wonder “oh, is Scrypto Turing incomplete? Is it good for a few things, but ultimately more limited than Solidity and EVM?”

The answer is no. Scrypto leverages Rust and the Rust compiler and inherits its Turing completeness. But that’s an incomplete picture without understanding how Scrypto’s computing environment – Radix Engine v2 – keeps all the flexibility of EVM while also truly making DeFi dApps much easier and safer to build.

Scrypto and the Radix Engine Resource FSM

Ethereum’s EVM is certainly flexible, in that somebody can write and run a smart contract that can do just about anything (at least given enough gas…). However, talking to developers we discovered that because everything must be implemented in smart contract logic on Ethereum, a large amount of common functionality is complex and very difficult to do safely.

In particular, the very concept of assets themselves (such as tokens, stablecoins, or NFTs) must be implemented over and over as independent smart contracts. And every time a smart contract wants to interact with assets (which is basically every transaction), it has to do a lot of very careful and fiddly interaction with multiple other smart contracts.

This was a problem we wanted to completely solve with Radix Engine v2 – Radix’s alternative to the EVM - and the Scrypto language that runs on it.

Our solution is not to limit what you can write with Scrypto or run on Radix Engine. Instead, we add something new. Radix Engine v2 natively understands the concept of assets, ownership of assets, and all of the ways that assets intuitively should be able to change ownership. Instead of representing assets within thousands of separate smart contracts, they are represented universally within Radix Engine v2 as something we call “resources”.

The Radix Engine rules of resource ownership operate separately from regular Scrypto smart contract logic. They are managed by special logic called a “finite state machine” (or FSM). You may have heard us talking in the past about how FSM logic is used in places like nuclear power stations where absolute predictability of results is what matters. In short, this logic defines a definite set of “states” that the system can be in, and a set of rules for how one state can transition to another – such that bad states aren’t just avoided, they simply aren’t possible.

This is exactly what we want for resource-based assets: absolute certainty that tokens, NFTs, and other assets will behave according to predictable rules that match our physical intuition of how physical ownership in the real world works. For example, it should be impossible for an asset to be accidentally created or destroyed – it should only be possible for it to change hands like a physical asset.

So about now, you might be able to guess: FSM logic is not Turing complete! It trades away the ability to compute anything for perfect predictability.

However this doesn’t at all compromise the Turing completeness of Scrypto and Radix Engine. The resource FSM just adds a special-purpose system that a developer can choose to use when they want to do asset things. All of the “Turing complete” flexibility the developer desires is still there outside the FSM, but they get to lean heavily on FSM-based resources to avoid all of the complexity and risk typically associated with interacting with assets on Ethereum and other smart contract platforms. As one of our community developers put it, “Radix Engine has your back”.

The new syntax, functions, and data types that Scrypto adds to Rust then are all about making it really simple to interact with resources. It lets you “take” resources out of storage “vaults”, and pass them around in “buckets” that all behave safely and as expected. In fact our unique new transaction model also derives its power from the ability to intuitively interact with assets. Behind the scenes, Radix Engine’s resource FSM is clicking along making sure assets are handled correctly.

A Game Engine for DeFi

For DeFi developers, this makes Radix Engine’s resource FSM similar to a game engine framework like Unreal Engine or Unity for game developers. If you're building a game with one of those engines, it doesn't limit what you can build - it just means that you get access to a lot of very common functionality that is difficult to do correctly, like physics, graphics, etc.

The emergence of game engines created a tipping point for the game industry. Suddenly game development didn’t require expertise in physics or graphics, which created a huge influx of new developers into the field. Smaller teams, or even individuals, could create many more games because the bar to entry was so much lower. Larger teams could build much bigger games, creating the AAA game class where most effort is spent on crafting enormous compelling worlds. And overall, games just got better because the really hard (and common) problems that could make a game feel quirky, unconvincing, or just broken were already solved. The game industry exploded.

This is what Radix Engine v2 and Scrypto are about: providing a game engine for decentralized finance. Scrypto is Turing complete – but more importantly, its flexibility comes with powerful and reliable asset management functionality that can lead to an explosion of DeFi dApps that are more numerous, more featureful, and more secure at the same time.

—

To learn more about Scrypto and Radix Engine, read our 4-part series starting here.

If you’re a developer and want to start building with Scrypto, get started on our developer’s hub.