I Just Wrote a Stellar Smart Contract

In 1996, the same year I was born 😊, Nick Szabo first coined the term “smart contract” in his paper Smart Contracts: Building Blocks for Digital Free Markets:

“A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises.”

22 years later, the term “smart contract” is synonymous with Ethereum’s Turing complete Solidity and is responsible for everything from cryptographic cat auctions to provably fair Fate Channels. So when I needed to implement a logic-based payment funnel, it seemed Solidity was the best choice — the quality of developer support available rivals none. But as Herb Brook famously said “I’m not looking for the best one, I am looking for the right one.”

The Problem

Here is an overview of what I looked to solve.

Let’s say Bob owns a house construction company and Charlie and Diego work for Bob. Alice is looking to build a house and she only owns cryptocurrency. Lucky for her, Bob’s construction company is willing to accept her crypto. So, Alice goes to Bob and says “Bob, will you build me a house?”

Bob responds “yes I will, but under one condition. If we fail to build the house, we will only refund part of your payment.” (Bob and Charlie must be paid, but Diego should only be paid if the house is successfully built)

Alice responds “ok, I agree. I will draft a smart contract dictating these terms and get back to you tomorrow.”

So what should Alice do?

Ethereum != Right Choice

My first instinct:

npm install -g truffle
cd ~/smartContract
truffle init

For those who are unfamiliar with the Truffle framework, I highly recommend checking it out.

With Truffle up and running, I began constructing a proof of concept Ethereum smart contract. Ultimately I came up with a distributor contract that acted as an escrow between Alice and Bob and then distributed funds based on a binary outcome; Alice gives Bob the funds for the service and once the service is complete, Bob distributes the funds accordingly. This came out to be 100+ lines of code and several days of battling through the intricacies of the Solidity programming language. As a novice smart contract engineer, I can say with certainty, this code was not error free and was very likely insecure.

Yet for weeks, this was the contract I tested, refactored, and considered the best possible solution.

That all ended when I came across this article.

Stellar Smart Contracts… Yes I Just Wrote That

Stellar smart contracts. WHAT?!?!? I had to test this out and see if it was real. Starting from scratch, I reconsidered the problem at hand.

Essentially, my problem boiled down to this:

IF HOUSE BUILT --> pay Bob, Charlie, Diego
ELSE --> pay Bob, Charlie

Easy, eh? With a clearer understanding of the simplicity of the problem I sought to solve, I began reading through Stellar’s documentation and honed in on their definition of a transaction. I came across the following properties:

a) composed of operations — in the world of Stellar, a transaction is a series of operations that are grouped together and signed by each of the acting accounts

b) atomic — the transaction succeeds or fails; there is no middle state

c) sequence number — each transaction is assigned a sequence number, allowing the transaction constructor to determine the order of transaction execution. On the Stellar network, sequence numbers must be strictly increasing — after the N transaction is executed, the next valid transaction is N+1… a transaction with N or N+2 will fail.

Using these three simple properties, I created a “smart contract”:

PROBLEM:

Consider the user A who seeks to pay B,C,D for a service. If the service succeeds, B,C, and D are paid. If the service fails, only B and C are paid. B is a trusted party, capable of determining whether the service succeeds or fails.

SETUP:

A
balance: 9 XLM
sequence #: 3A constructs two transactions:

‍TX A:
Sequence #4
Pay B 3 XLM
pay C 3 XLM
Pay D 3 XLM

‍TX B:
Sequence #4
Pay B 3 XLM
pay C 3 XLMA signs both these transactions and gives them to B.

EXECUTION:

IF SUCCESS: B broadcasts TX A
ELSE: B broadcasts TX B

Boom… a minimal logic-based payment funnel implementable in under 20 lines of code (and I can even use javascript 😍).

Note: in both cases I trust B to act honestly and determine the outcome of the services.

So Is This a Smart Contract?

Let’s go back to Szabo’s original definition of smart contract:

“A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises.”

promises: Alice will pay Bob,Charlie, and Diego based on the outcome of the service.

specified in digital form: pick your favorite language.

within which the parties perform on these promises: Bob, Charlie, and Diego attempt to build the house, with the guarantee that success will result in payment.

So is this a smart contract?!?

So What, Who Cares?

Sure CryptoKitties may require a Turing complete smart contracting language. Sure Fate Channels probably can’t be implemented using a combination of Stellar’s 11 operations. Sure Stellar’s smart contracts are not a replacement for Solidity. However, in certain situations, Stellar’s transaction construction capabilities may offer a simpler, more effective smart contract solution (and with 10000x less fee’s).

Disclaimer: While I am a current employee of Stellar.org, these views represent my own and not those of SDF. These conclusions were developed while experimenting during my free time and were not necessarily influenced by my daytime occupation.

Disclaimer continued: While I stand by my words, I am a novice smart contract programmer and may be incorrect in my assumptions. If so, please comment below — this is an open project and I am looking for feedback.