Introduction, Proof Systems & Audits

The Self-Custody Series, Part I

Introduction

StarkEx, a self-custodial scalability engine, was just launched on Ethereum Mainnet (for more info on general system architecture and flows). StarkEx implements the STARK Zero-Knowledge Proof (ZKP) protocol. The path to a self-custodial solution is an arduous one: custodial solutions are simpler, cheaper, and most importantly, far better understood — the world has been building custodial software systems for decades. “Self-custodial”, or the synonymous “non-custodial”, are used rather liberally. They are used by operators who can — with a click of a button — assume complete custody of their users’ funds: a surprising state of affairs, given that permissionless blockchains were conceived as an alternative to custodial systems. We appreciate the challenges of building a true self-custodial system, and the multi-dimensional design space available to innovators in the space. We also realize that many find it useful to migrate towards an increasingly self-custodial solution over time. This series of posts details the choices we’ve made, and the direction we see ahead for StarkEx, in this regard.

This post is the first in a series highlighting the efforts we’ve taken on multiple fronts to ensure that StarkEx is, and will always remain, a self-custodial solution.

First off, it’s worth defining what “self-custodial” means. In our view, a system may be described as “self-custodial” only if it satisfies the following properties:

1. User funds cannot change hands without their explicit signature.
2. When signing, all information is made available to the user (via wallet UX).
3. Funds can always be withdrawn.
4. The above logic cannot be tampered with by abusing any code upgrade mechanism.

This post will focus on why (1) proof systems are uniquely tailored to support self-custodial solutions, and (2) the audits for StarkEx smart contracts. The following posts in this series will describe the (3) smart contract upgradability mechanisms we’ve put in place, (4) wallets support (the STARK signature scheme and integration), and finally (5) data availability (ranging from the Data Availability Committee supporting our first deployment to the design of a fully trustless off-chain data availability solution).

The self-custodial Holy Grail goes back to the original blockchain vision, epitomized in the saying “not your keys, not your coins”. Early on, because of throughput limitations at Layer-1, this self-custodial ideal was traded off for scalability, and the ensuing liquidity. The poster children of this tradeoff are of course centralized exchanges: they took custody of traders’ crypto assets, and offered them liquidity in return (with a fair bit of counterparty risk). But today, the science and engineering behind ZKP systems in general, and STARKs in particular, have advanced to the point where they’re ready for prime time — the above tradeoff is no longer necessary.

ZKP systems have a beautiful and elaborate history. Remarkably, for permissionless blockchains ZKP systems are able to provide both scalability and privacy in a trustless fashion. A self-custodial solution naturally requires trustless infrastructure. Phrased differently, any trust assumption may easily chip away at self-custody, if not render it altogether meaningless.

ZKP systems are composed of a base layer providing Computational Integrity (CI), with a possible layer on top ensuring zero-knowledge. To support scalability applications, we in fact rely strictly on the CI layer. CI allows for one entity (the prover) to generate a proof off-chain for any computation (or state transition), and allow any number of entities (verifiers) to verify the proof on-chain with minimal computational effort.

Ideally, there are as few trust assumptions as possible. Specifically, for STARKs:

• Prover: There are no trust assumptions in the prover, not in real-time nor with respect to any pre-processing, as STARKs require no trusted setup. Taken to the extreme, even if a prover runs on malicious hardware by an evil organization, they cannot produce valid proofs for false statements.
• Verifier: The verifier runs on-chain, and its source is available.

StarkEx is a scalability engine for exchanges, but STARK could be similarly used to provide scalability for other applications. When using it, some of the application logic is implemented off-chain, while the parts of the logic that interact with on-chain entities (contracts, accounts, etc.) are implemented as an Application Smart Contract (ASC).

The first application to use StarkEx is with our partners at DeversiFi, a self-custodial exchange, which will use it to scale its operations (both trading and transfers). The ASC ensures that user funds cannot change hands without their explicit signature (signatures are validated by a STARK proof). StarkEx requires users to deposit their funds into the ASC, making the latter an obvious target for hackers. The ASC code was audited and extensively tested to ensure its correctness and security. In addition, we plan to make ongoing use of additional tools, such as formal verification, to ensure the correctness and security of our code.

Audits do not a secure system maketh, as its admin can trivially “upgrade” to a new set of smart contracts which render self-custody obsolete. Smart contract upgrades (or, alternatively, migrations) allow bugs to be fixed, and they allow for functionality to be expanded over time. The next post in this series will focus on how we designed our smart contract upgrade mechanism to ensure that StarkEx remains a self-custodial scalability engine at all times.

A note on language: unfortunately, the commonly used term for “self-custodial” is “non-custodial”. We don’t like that term, as it defines by negation. It suggests that custodial systems (such as centralized exchanges) are the benchmark, the point of reference. But custodial solutions go directly against the spirit of permissionless blockchains. Bringing custody back to oneself was the rallying cry for Bitcoin and Ethereum, and that is why we like “self-custodial” much better.

~ Tom Brand & Uri Kolodny