Scroll

Categories

Tags

Monthly Archives

Keyword

Back

2018.04.04

# 2. 问题的形式化论述

In this section we describe a generic framework for reasoning about the security and scalability properties of cryptocurrency protocols. Generally, in our framework, a cryptocurrency protocol speciﬁes two sets of instructions – the mining protocol, regarding the creation of blocks and formation of the block ledger, and the TxO protocol, interpreting the ledger and extracting from it a consistent subset of valid transactions. Since transactions in the protocol are accepted with increasing probability as time goes on, users additionally run the Robust TxO protocol, to quantify the robustness of an accepted transaction – a bound on the probability that it will ever be reversed, when a malicious attacker attempts to do so (Bitcoin transactions for example, can be reversed if the attacker manages to produce a longer alternative chain on which they are not present – this event occurs with decreasing probability as time passes). Next, we present our framework in the abstract sense, so as to keep it as general as possible. In Section 4, we present a protocol that meets the requirements and uses a block DAG to do so. We defer the speciﬁcs of the solution and the mining protocol, till then. We will use our framework to make clear the sense in which SPECTRE avoids the security-scalability trade-off that Bitcoin suffers from.

### Transactions

A transaction is typically denoted $tx$. $inputs (tx)$ is the set of transactions that must be accepted before $tx$ can be accepted; these are the transactions that have provided the money that is being spent in $tx$. Two different transactions $tx 1$ and $tx 2$ conﬂict if they share a common input, i.e., they double spend the same money; we then write $tx 2 ∈ conflict (tx 1 )$ (this is a symmetric relation).

### Mining protocol

We denote by $\mathcal{N}$ the set of nodes, aka miners. Miners maintain and extend the ledger, by adding transactions to it and propagating messages, according to the mining protocol. The propagation time of a message of size B KB to all nodes in the system is assumed to be under$D = D(B)$ seconds. For now, we regard the mining protocol as an abstract set of rules that miners must follow. We denote by honest the set of nodes that always follow the protocol’s instructions, and by malicious the complementary of this set.

### 挖矿协议

In the family of protocols we focus on, miners possess computational power and perform proof-of-work (PoW). We denote by α the attacker’s relative computational power. Formally, it is the probability that the creator of the next PoW in the system belongs malicious; this is well deﬁned, as PoW creation is modeled as a memoryless process [13], [18], [17].

## Formation of ledger

The result of the mining protocol is an (abstract) public data structure G containing transactions (to be instantiated later, in our solution proposal, as a block DAG), aka the ledger. Nodes replicate the ledger locally. As they might hold slightly different views of the ledger (e.g., since blocks take time to propagate to all nodes), we denote by $G_t^v$ the state of the ledger as observed by node v at time t; we write $G_t$ when the local context is unimportant.

## TxO protocol

Given a public ledger $G$, the TxO protocol extracts a consistent subset of transactions from $G$, denoted $TxO(G)$. Every transaction in this set must have its inputs in it as well, and cannot conﬂict with another transaction in the set.

## Robust TxO protocol

Users of the system must get assurances regarding their payments. Basically, we want to guarantee that transactions will be accepted by all users, and that they will remain so forever. Given $G_t$, the RobustTxO protocol speciﬁes a subset of $TxO(G_t)$, denoted $RobustTxO(G_t^v)$, which represents the set of accepted transactions that are guaranteed to remain so forever, up to an error probability of $\epsilon$. RobustTxO takes as input $G_t^v$ (the local replicate of $v$), and the values of $D, \lambda, \alpha, and \epsilon$ (^1). A $tx$ in (Robust) TxO is said to be (robustly) accepted.

## 鲁棒TxO协议

The “weakness” of the Liveness property corresponds to the fact that we do not guarantee (though it is still hard for an attacker to prevent) a resolution in case conﬂicting transactions were published soon one after the other. Contrast this to traditional consensus protocols, where all conﬂicts are required to be decided in ﬁnite time, a property usually referred to as Liveness. Observe, however, that an honest user of the system will never publish conﬂicting transactions, and will transfer money only after he robustly accepted the original funds (the inputs) himself; payments of honest users are thus guaranteed to meet the conditions formalized in Weak Liveness, and to be robustly accepted. On the other hand, an attacker trying to defraud must keep his attack secret before publishing the conﬂict, until the victim robustly accepts; but then the victim is guaranteed that w.h.p. his transaction will not be reversed. Therefore, these two properties together ensure that payments of honest users will be robustly accepted in constant expected time, and that they remain robustly accepted forever, w.h.p.

In this work we set out to design a protocol that can support a large throughput, and achieve fast conﬁrmation times, while maintaining a high security threshold.

(^1) For the sake of clear exposition, we regard here these values as known. However, we emphasize that SPECTRE does not assume that nodes know or agree on the precise values of these parameters. See Section 3.

(^1) 为了清楚说明，我们将这些值视为已知。 但是，我们强调SPECTRE不会假设节点知道或在这些参数的精确值上达成共识。 参见第3节

Top