I Just Wrote a Stellar Smart Contract Pt. 2: Let’s Dig a Little Deeper

Rob Durst
Rob Durst
Apr 8, 2018 · 7 min read
Image for post
Image for post

A little over a month ago, I wrote part 1 of this multi-part series, detailing my journey into the world of Stellar Smart Contracts (SSC’s).

Since then, I have received some wonderful feedback, compliments, doubts, concerns, etc.

Many of these concerns were valid and today, with a completely free schedule, a warm cup of coffee, and a fully-charged computer, I sat down and looked to build off of the basics I described in pt. 1.

Concepts

Sequence Number:

Operation:

Threshold:

Signer:

Signers can be added and removed with ease, allowing for the trivial creation of n-of-m multi-signature accounts.

There are three different types of signers that can be added to an account — account id (public key), pre-authorized transactions, and Hash(X). In this article, we will ignore Hash(X)

Adding a New Tool to Our Toolbox

Technology is nothing. What’s important is that you have a faith in people, that they’re basically good and smart, and if you give them tools, they’ll do wonderful things with them. — Steve Jobs

So yeah in the spirit of Steve Jobs and innovation, let’s venture into the weeds and begin to use some of Stellar’s lesser known features.

Pre-authorized Transactions:

Well it gets better!

This pre-authorized transaction can be added as a signer to an account. If the correct weight is given to this signature, this allows you to broadcast a transaction without any other signatures. Here is an example:

Account A
balance: 9
sequence #: 3
low threshold: 1
med threshold: 1
high threshold: 1
TX A:
Sequence #5
Pay B 5 XLM
(NO SIGNATURE NEEDED)
TX B:
Sequence #4
Set Options:
Signer: HASH of TX A
Signer_weight: 1
Now:
1) Account A submits transaction B
2) Account A, or anyone with transaction A, can submit transaction A without needing an additional signature

Note: Once transaction B has been submitted, it will be removed as a signer from Account A.

Still not cool yet?

No worries, the usefulness of this tool will be obvious soon :)

Improving Upon My Previous Example

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.

And here is the solution from last time:

Account A
balance: 9 XLM
sequence #: 3
A 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 XLM
A signs both these transactions and gives them to B. Once the service is finished, B submits TX A or TX B depending on the success of the service.

However, note one of the major flaws I did not address in the previous example (thanks to Alexander for the comment):

Alice [A in the example above] could just issue another transaction that increases the sequence number

Unfortunately, yes she could.

So how can we lock these funds and prevent Alice from spending the money she has set aside to pay B, C, and/or D?

To do this, we will use our new tool: pre-authorized transactions.

Let’s jump right in.

Setup:

A creates an account E with her 9 XLM and sets all thresholds to 1.Account E
balance: 9 XLM
sequence #: 1
low threshold: 1
med threshold: 1
high threshold: 1
B constructs two transactions, just like A did last time, except this time B will set the sequence number to be sequence number+2:TX A:
Sequence #3
Pay B 3 XLM
pay C 3 XLM
Pay D 3 XLM
TX B:
Sequence #3
Pay B 3 XLM
pay C 3 XLM
A will construct a third transaction with the hashes of the transactions given to her by B:TX SETUP:
Sequence #2
Master Key weight: 0
Add TX A HASH as a signer w/ weight: 1
Add TX B HASH as a signer w/ weight: 1
A signs TX SETUP with Master Key E and submits it to the network.

Woah, woah, woah, what just happened?!?!

We now essentially have the same setup as before, but this time, the 9 XLM are locked — A has no way of accessing her funds. Even more important, since A cannot access account E, TX A and TX B are both guaranteed to be valid until one of them is spent. As a bonus, since B constructed both transactions and only sent the hashes to A, only B has the power to submit the final transaction.

As per one of the comments on pt. 1 (thanks to Xavi):

It would be interesting if you implemented time-bounds to those operations for when transaction A and transaction B can be sent by Bob (e.g. after 30 days, the house should be built).

A can construct a third transaction, TX C, that will refund her the 9 XLM if B doesn’t submit either transaction before a certain date. Here is the edited setup:

A creates an account E with her 9 XLM and sets all thresholds to 1.Account E
balance: 9 XLM
sequence #: 1
low threshold: 1
med threshold: 1
high threshold: 1
B constructs two transactions, just like A did the last time, except this time B will set the sequence number to be sequence number+2:TX A:
Sequence #3
Pay B 3 XLM
pay C 3 XLM
Pay D 3 XLM
TX B:
Sequence #3
Pay B 3 XLM
pay C 3 XLM
A will construct a third, refund, transaction that is only valid after X days:TX C:
Sequence #3
Pay A 9 XLM
Time bound: X days
A will construct a fourth transaction with the hashes of the transactions given to her from B and from her own refund transaction:TX SETUP:
Sequence #2
Master Key weight: 0
Add TX A HASH as a signer w/ weight: 1
Add TX B HASH as a signer w/ weight: 1
Add TX C HASH as a signer w/ weight: 1
A signs TX SETUP with Master Key E and submits it to the network.

Conclusion

  • We must trust B to make the correct judgement

Yep, that is about it…

Consider the alternative in Ethereum, NEO, EOS, etc. At some point, you would need to introduce trust into the system — someone has to make a final judgement on whether or not the service has been completed.

Thus, for a simple, binary operation like this, where we are distributing payment based on an observable (but not necessarily programmatically observable) outcome, we can use a Stellar Smart Contract.

SO BOOM! You now have a pretty complex smart contract implementable in JavaScript, Go, C#, Ruby, Python, Scala, Swift, and (soon to be) Rust, deployable for an affordable 0.00001 XLM/operation.

THE CODE: Here is a basic example of adding a pre-authorized transaction as a signer written in JavaScript.

Disclaimer: While I am a current employee of Stellar.org, these views represent my own and not those of SDF. That being said, these conclusions were developed while experimenting during my free time and are based on real code rather than personal biases.

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 — I am always looking for feedback.

HackerNoon.com

#BlackLivesMatter

Sign up for Get Better Tech Emails via HackerNoon.com

By HackerNoon.com

how hackers start their afternoons. the real shit is on hackernoon.com. Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Rob Durst

Written by

Rob Durst

Lumenaut. Mule. Software Engineer.

HackerNoon.com

Elijah McClain, George Floyd, Eric Garner, Breonna Taylor, Ahmaud Arbery, Michael Brown, Oscar Grant, Atatiana Jefferson, Tamir Rice, Bettie Jones, Botham Jean

Rob Durst

Written by

Rob Durst

Lumenaut. Mule. Software Engineer.

HackerNoon.com

Elijah McClain, George Floyd, Eric Garner, Breonna Taylor, Ahmaud Arbery, Michael Brown, Oscar Grant, Atatiana Jefferson, Tamir Rice, Bettie Jones, Botham Jean

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app