Authors:
(1) Bennet Yee, Oasis Labs;
(2) Dawn Song, Oasis Labs;
(3) Patrick McCorry, Infura;
(4) Chris Buckland, Infura. Authors: 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 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 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 Key Concepts 2.1 Append-Only Log and 2.2 Virtual Machine State 2.1 Append-Only Log and 2.2 Virtual Machine State 2.3 Transactions As Curried Functions 2.3 Transactions As Curried Functions 2.4 Natural Names of State 2.4 Natural Names of State 2.5 Ground Truth 2.5 Ground Truth 2.6 Efficient Representations of State 2.6 Efficient Representations of State 2.7 Checkpoints 2.7 Checkpoints 2.8 Execution Parameters: callData 2.8 Execution Parameters: callData 2.9 Execution Ordering 2.9 Execution Ordering 2.10 Deciding on the Correct State 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 Ideal Layer 2 Design Ideal Layer 2 Design 3.1 VM Job Queue and Transaction Order Finality 3.1 VM Job Queue and Transaction Order Finality 3.2 Data Availability and Garbage Collection 3.2 Data Availability and Garbage Collection 3.3 State Finality 3.3 State Finality 3.4 Checkpoint Finality 3.4 Checkpoint Finality Conclusion and References Conclusion and References Conclusion and References A. Discrepancy Detection Security Parameters 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. naming transaction order finality state value finality 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. This paper is available on arxiv under ATTRIBUTION 4.0 INTERNATIONAL license. This paper is available on arxiv under ATTRIBUTION 4.0 INTERNATIONAL license. available on arxiv available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

What Happens After You Hit ‘Send’ on Blockchain

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Ways to Measure Privacy Risks in Text Data

How Blockchain Defines ‘Truth’

Making Sense of Blockchain Execution and Transaction Order

Understanding CallData in Blockchain Transaction Execution

Blockchain Consensus Mechanisms, Once and For All: PoW, PoS, and Rollups

The Components of an Ideal Layer 2 Rollup Design

5 Ways to Measure Privacy Risks in Text Data

How Blockchain Defines ‘Truth’

Making Sense of Blockchain Execution and Transaction Order

Understanding CallData in Blockchain Transaction Execution

Blockchain Consensus Mechanisms, Once and For All: PoW, PoS, and Rollups

The Components of an Ideal Layer 2 Rollup Design

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps