This document discusses smart contracts in the Σ-State language used by the Ergo Platform. It begins by describing some limitations of Bitcoin scripting and Ethereum's approach. The Σ-State language uses zero-knowledge proofs to enable more powerful cryptographic capabilities like ring and threshold signatures. Programs in the language combine these cryptographic statements with predicates over the transaction context in a simple logical formula. This approach allows for applications like crowdfunding, demurrage currencies, and more while ensuring verification time remains bounded.

1. Smart Contracts in
the Σ-State Language
Alexander
Chepurnoy
Ergo Platform

2. Cash money: no protection!

3. Cryptocurrencies: Protection!
pubkey_A

4. Bitcoin Transaction

5. Bitcoin Script
• Output is an object created by an user
• Protected by a script
• Interpreter is to be run by anyone (against
non-interactive proof to be included into the
blockchain)

6. Authentication Language
object
program
Context
Interpreter
Proof
+ Public inputs
True/False

7. Bitcoin Script
• A program is in stack-based language
• Proof is in the same language too
• Context is some meta-info on spending
transaction & blockchain
• Cryptographic statements:
OP_CHECKSIG, OP_CHECKMULTISIG,
OP_HASH256 (and few others)

8. Bitcoin Script
Output script (proposition):
OP_DUP
OP_HASH160 <pubKeyHash>
OP_EQUALVERIFY
OP_CHECKSIG
Input script (proof):
<sig>
<pubkey>
Output: true if no failure during execution and
top stack element is non-zero, false otherwise

9. Bitcoin Script Problems
• High-level cryptographic statements are fixed
(to add ring or threshold signatures, hard-fork is
needed)
• Limited support for cryptographic protocols
• The language was designed with no systematic
approach, very limited, but many instructions were
found problematic (DoS attacks / security issues) and
switched off

10. Smart Contracts

11. Ethereum
“Decentralized World Computer” => “Replicated Programmable Calculator”
Replicated over thousands of
machines!

12. Motivation
• More powerful language than the Bitcoin Script
• Still simple
• Efficiency: only parts of the blockchain which can be
queried should be queried
• Safety guarantee: verification time for any script must
be no more than predefined constant C

13. Related Work
• Simplicity
• More safe “Turing-complete” languages
(Plutus, Michelson, IELE etc)

14. Zero-Knowledge Proof-of-Knowledge
• “For publicly known value x, I know
secret w, such as R(x, w) holds”
• “For publicly known value x, I know w
such as x = gw
”
• w/out showing w

15. ERGO Approach (Σ–State)
• Native cryptographic protocols
• Efficient execution (lean state, prover pays if
something above a trivial thing is needed)
• Simple model
• Safety guarantee: if honest prover is able to
redeem an output on his side, no problem on
blockchain also then; strict upper bound for
execution time

16. Generalized Schnorr Proofs
• subclass of Σ-protocols for dlog statements
• composable (OR, AND, k-out-of-n)
• possible to turn into signatures by using
Fiat-Shamir
• efficient (Schnorr signature scheme in a
simplest case)

17. Theory Behind
● Ivan Damgard „On Sigma Protocols“
● Yehuda Lindell, Carmit Hazay „Efficient Secure
Two-Party Protocols: Techniques and
Constructions“ (Book)
● Yehuda Lindell „Sigma Protocols and Zero
Knowledge“
http://www.youtube.com/watch?v=nwsmG3S9wIc

18. Compound Statements
/ (AND)
/ (OR)
k-out-of-n
A compound statement is also a Σ-protocol

19. Generating a signature
object
Context Secrets
(Priv. Key)
program
Prover
Proof (Signature)

20. Verifying:
object
program
Context
Interpreter
Proof
(Signature)
True/False

21. Σ–State
• simple predicate logic consists of cryptographic
statements and context predicates as well as / , / , k-
out-of-n connectives
• context description and predicates over it could be
different
• 2-phase interpretation on both prover/verifies sides: first
the composite logic formula to be reduced to one
contains only connectives and cryptographic statements
by evaluating state predicates, then prover generates a
proof for the cryptographic formula, verifier checks it
• In non-interactive setting (e.g. blockchain) the roof is to
be turned into a signature by using Fiat-Shamir

22. Bitcoin on Steroids: An Easy Way
Bitcoin: state is just about spending transaction bytes,
block height & timestamp (for CLTV) + prover arguments
Enhancing the context: height, outputs the spending
transaction spends and creates, UTXO snapshot root
hash, prover arguments
An output has additional data registers.

23. Example 1:
• height > 100 / dlog_g x
“if height of a block to which a spending transaction
is included > 100, output is spendable by anyone,
before that output is spendable to a party presenting
(zero-knowledge) proof a knowledge such w that
gw
=x”
• (height > 100 / dlog_g x1) / (dlog_g x1 / dlog x2)
“output could be spent anytime by proof of
knowledge of both x1 and x2, after block#100 it
could be also spent by proof of x1 knowledge”

24. ∧ ∧
∨
h < 5 dlogg
x1
h ≥ 5 dlogg
x2
h=4
dlogg
x1
Example:
(h < 5 / dlog_g x1) / (h >= 5 / dlog x2)

25. Crowdfunding Example
• outputs
• (height >= 100 / dlog_g x1) /
(height < 100 / exists(outputs,
amount >= 100000 / proposition = dlog_g x2)
“output could be spent by a crowdfunding
transaction if it pays at least 100000 tokens to x2
public key holder raising funds before block #100,
or getting back to x1 after that”

26. Demurrage Currency Example
self is an output to be spent
regular_script is a user’s script
dem_period is demurrage period
dem_cost is demurrage cost (per period)
regular_script ∨
(height > (out.height + dem_period)
∧ exists(outputs,
value >= (out.value−dem_cost) / script=self.script))

27. Cryptography
• Ring and threshold signatures for free, but may be not
efficient(sig size is linear to size of the ring/group)
• We can include special efficient Σ-protocols (e.g. Groth-
Kohlweiss ring signatures from EuroCrypt’2015)
• To have ability to update cryptographical statements set,
languages like ZKPDL (Meiklejohn et al. USENIX’2010)
could be used

28. All Bitcoin Script Applications Are Possible:
• Atomic swaps
• Payment channels
• Zero-Knowledge Contingent Payment protocols
(Pay-to-Sudoku etc)
• Bitcoin mixers

29. And More Applications:
• Crowdfunding and demurrage examples
• Oracles (w. authenticated UTXO set)
• Better mixers

30. Safety guarantees:
• Every tree node is associated with a cost
• We calculate initial cost
• If we replace a node with a new node or a subtree, we
add cost of the latter, abort if limit is exceeded
• Cost estimations are the same for the prover and the
verifier, no abort here.

31. Questions?