Announcing Fae: a Scalable, Functional Smart Contract System for Ethereum

A “lazy” method to develop high-performance blockchains by using the programming language Haskell.

I am excited to introduce a new smart contract system, called Fae because it is a functional allegory for Ethereum, as well as a fantastic accessory to Ethereum. These fanciful puns dress up the simple fact that Fae is a standalone platform for smart contracts, designed from the ground up to facilitate scalability, and that Ethereum can, without modification, benefit from this scalability. By attaching to the Ethereum blockchain, Fae can synchronize its own transactions with Ethereum’s and provide cross-platform interaction and economics. Yet, by remaining separate from the Ethereum virtual machine, Fae can spare its users from spending their money on gas and their time on other people’s computations, without sacrificing any of the consensus that Ethereum provides.

Read on below for more information, or visit Fae’s website to get another introduction, documents, tutorials, and Docker images.

What can Fae do?

Abstractly speaking, anything: like the EVM, Fae provides a Turing-complete computational model for smart contracts, so decisions of any complexity can be encoded in its transactions.

Concretely speaking, Fae is not like the EVM because it is not a virtual machine. It is actually an interpreter that executes contract and transaction code directly on the host machine — inside a tightly controlled environment, of course. And because Fae is not a VM, it can use Haskell, an existing high-level programming language, which is one reason I say that Fae is “functional”. Fae actually only provides a fairly small Haskell library to express the concepts of adversarial contract specification, which still leaves a huge language to express the contracts’ terms, guarantees, and evolution.

What is “adversarial contract specification”? It is the style of authoring that makes a contract safe and reliable when mutually mistrusting parties are signatory to it. Adversarial contract specification is control over the disposition of valuables, management of evolving contract state, protection of the parties’ identities, and restriction of the creation of successor contracts. Fae provides a handful of functions and one environment that can express any of these concerns in a manner smoothly consistent with ordinary Haskell.

Programming aside, Fae promises that any computation, no matter how ambitious or excessive or (sadly) malicious, can be placed in any transaction; it also promises that no computation, no matter how malicious or excessive or ambitious, needs to be executed by users who lack the hardware to tolerate it (or perceive it to be unsafe under any circumstances). All Fae clients are “light” clients, whose exact contents are determined by their operators based on personal interest in the results of transactions.

By making this guarantee, Fae transactions can run without the economic disincentive of gas to limit the burden on its participants. Gas exists to protect innocent bystanders: validators who need to execute every transaction regardless of interest in the outcome. Fae relieves each user from having to run all the transactions, and so removes the need to protect them from the ones that they may not want or even be able to validate.

How does Fae do it?

Sparing the technical details, Fae is based on just one principle: laziness. This is a way of structuring programs so that code is executed on demand — code such as transactions and the contracts they invoke. Fae transaction messages are up-front about the contracts they depend on, which allows Fae to maintain an organized storage of contract states in which each dependency can be pinpointed without observing anything else.

Fae uses Haskell as an implementation language because it is inherently lazy, with the difficult job of deferring and scheduling computations already achieved by dedicated researchers and developers. Laziness as a concept demands a functional style of programming because it rejects a concrete execution order, just as Fae rejects a concrete ordering of transactions.

Fae recognizes that scalability of a blockchain is synonymous with lazy execution of its transactions. For this reason, as well as the use of Haskell for contract programming, Fae is and must be functional.

Symbiosis: Fae + Ethereum = Faeth

Everything I’ve said above makes Fae out to be distinct from Ethereum, but through a simple mechanism, Fae can actually become part of Ethereum. When embedded in this way into an Ethereum transaction, a Fae transaction can use parameters such as the sender and recipient addresses, ether value, and data (contact call argument) as preconditions for its execution by Fae. This establishes a synchronized causal relationship between Fae and Ethereum transactions, by which parties can express negotiated exchanges and therefore transfer value and work between the two systems without the need for extra gas fees.

This symbiosis, called Faeth, both augments Ethereum’s meta-transactional logic to include a scalable component, and also augments Fae by providing it with a blockchain. Thus enabled, the nature of Fae’s storage immediately guarantees that all participants on the Ethereum network receive the same Fae transaction messages, and find the same outcomes when they choose to run them.

Why try Fae?

There is something for a lot of different people in Fae.

Designers of large contracts can explore a new way to economize gas;

Casual users with small, infrequent transactions can execute them with less resource overhead;

Contract language enthusiasts will find thought-provoking ideas in Fae’s language and abstractions;

Futurists (more than any Ethereum user is already futurist) will probably just find the whole thing exciting.

Check it out: https://sites.google.com/consensys.net/fae