Authors:
(1) Bennet Yee, Oasis Labs;
(2) Dawn Song, Oasis Labs;
(3) Patrick McCorry, Infura;
(4) Chris Buckland, Infura.
Table of Links
Abstract and 1. Introduction
-
Key Concepts
2.1 Append-Only Log and 2.2 Virtual Machine State
2.3 Transactions As Curried Functions
2.4 Natural Names of State
2.5 Ground Truth
2.6 Efficient Representations of State
2.7 Checkpoints
2.8 Execution Parameters: callData
2.9 Execution Ordering
2.10 Deciding on the Correct State
-
Ideal Layer 2 Design
3.1 VM Job Queue and Transaction Order Finality
3.2 Data Availability and Garbage Collection
3.3 State Finality
3.4 Checkpoint Finality
-
Conclusion and References
A. Discrepancy Detection Security Parameters
Abstract
Blockchains combine a distributed append-only log with a virtual machine that defines how log entries are interpreted. By viewing transactions as state transformation functions for the virtual machine, we separate the naming of a state from the computation of its value and reaching consensus on that value. This distinction allows us to separate the notion of transaction order finality from state value finality. Further consideration of how blockchain governance handles catastrophic common-mode failures such as zero day exploits lead us to the notion of checkpoint finality.
Consensus on the transaction order determines the ground truth. Everything else—computing the value of a state or handling catastrophic failures such as bugs / zero-day based attacks—are just optimizations.
1 Introduction
The core ideas behind smart contracts and blockchain systems are straightforward, based on a distributed, decentralized append-only log and how we interpret the meaning of those log entries using an abstract virtual machine (VM).
While the basic idea is simple, there are many design choices that need to be made before the full blockchain system is specified, implemented, and becomes usable, e.g., the format of messages that can be logged and their meaning, the VM state machine semantics, etc. These design choices can have important implications on how the resultant system behaves.
While practitioners understand the nuances, explicating these notions can make it easier for their impact to be discussed and for alternative design choices to be investigated. This paper attempts to use some basic ideas and notation from programming languages, semantics, and group theory to help model smart contract systems as a way to guide how we look at these design choices, the security issues that arise, and their scaling implications.
We introduce the following distinct flavors of finality:
• log finality, when an entry has been irrevocably appended to the blockchain log.
• transaction order finality, when a transaction’s effect on the VM state is irrevocably determined, without necessarily first computing it.
• state value finality, when the computed state value is determined as an efficiently accessed data structure. This is irrevocable except for recovery from critical infrastructure failures (determined by governance), e.g., an adversary exploits a bug in code used by all participants or an adversary was able to violate a security assumption, such as bribing an above-threshold number of committee participants.
• checkpoint finality, when the computed state value can no longer be changed by hard forks and thus becomes truly irrevocable.
We argue that transaction order finality, built using log finality, is the key to reasoning about a blockchain system. State value finality and checkpoint finality are nonetheless important optimizations: they respectively enable application for which independent private state determination is too expensive and permit the storage layer to reclaim storage.
In the next section, we present the ideas, notations, and terminologies that we use to analyze blockchain properties and use them to discuss some well-known blockchain systems and their properties. Then, in Section 3, we discuss what we think are “ideal” rollup properties and attempt to sketch what such a system would be like. Finally, we present concluding remarks in Section 4.
