Scroll

Categories

Tags

Monthly Archives

Keyword

Back

2018.07.25

# INTUITION AND EXAMPLES

In this section we provide some basic explanations and intuitions regarding the operation of SPECTRE. We focus primarily on explaining the ideas underlying Alg. 1 that is at the core of the protocol. We later go on to present examples for simple attacks that shed some light on how resilience is achieved.

Intuition 1 (Vote in favour of visible blocks). If a block x is known by honest participants, their blocks will include it in their past. Given that blocks vote in favour of blocks in their past (over other unknown blocks), and given that honest nodes publish their blocks quickly, hidden attacker blocks lose votes.

Intuition 2 (Majority ampliﬁcation). Given blocks x, y that contain potential conﬂicts, blocks that are generated by honest participants after their publication reference both of them in the DAG. According to Alg. 1, these new blocks adopt the vote of the sub-DAG in their past with regards to x and y . Thus, if block x precedes block y , additional votes that support this decision are added, and the attacker will ﬁnd it more difﬁcult to reverse the vote.

Intuition 3 (Referencing recent blocks is beneﬁcial). Blocks from the past vote according to their future. Thus if an attacker creates a block that does not reference recent blocks, it is at a disadvantage compared to other blocks that do (it loses votes from recent blocks it did not reference and did not “convince”).

Intuition 4 (Votes from the past counter pre-mining attacks). Consider an attacker that creates a block y , withholds it, and constructs many blocks on top of it over an extended period of time. After a long while, a conﬂicting transaction is released to the network, and eventually ends up in some block x. Block y has many blocks (built by the attacker) that reference it. Thus, if only votes from the future are counted, block y would prevail even if x is allowed to accumulate some votes. In SPECTRE, blocks that were created by honest nodes while y was withheld, look to their future for their votes. These will usually vote in favour of x and will usually outnumber the attacker blocks that were created when y was withheld (an example of pre-mining appears in Fig. 3).

Fig. 2: SPECTRE coincides with the longest-chain rule when it is applied to “simple” chains of blocks. In the depicted DAG, the chain ending at block 8 is longer and would be selected in the longest chain protocol. In SPECTRE each one of the blocks 5,6,7,8 precedes each of the blocks in 9,10,11. Consider for instance blocks 6 and 10 and the pairwise vote that involves them. Blocks 6-8 vote strongly 6 ≺ 10, as they see block 6 in their past but not block 10. Block 5 is a weak voter, as it sees neither 6 nor 10 in its past, hence it votes as the majority of its future (thus voting 6 ≺ 10 as well). For similar reasons, blocks 9-11 all vote 10 ≺ 6. Block 4, at the fork of the two chains, is a weak voters as well, as it sees neither 6 nor 10 in its past; it therefore votes according to the majority of future blocks. As block 4 sees four votes in favour of 6 ≺ 10, and three votes in favour of 10 ≺ 6, it will vote in favour of 6 ≺ 10. Blocks 1-3 similarly vote according to their future, and see an increasing number of votes for 6 ≺ 10, adding their own vote to the result. Thus, the end result is that 6 precedes 10.

## A. 等效于最长链规则

We now demonstrate how SPECTRE coincides with Bitcoin’s longest-chain rule, in the case of a “simple” fork between two chains. Consider the DAG illustrated in Fig. 2. In Bitcoin, the longer chain would be selected. Similarly, in the pairwise ordering of SPECTRE, each of the blocks in the longest chain 5,6,7,8 would precede each of the blocks in the shorter one 9,10,11. To see why this is true refer to the caption of the ﬁgure.

We now turn to examine two different attack scenarios, which we name double-spending, and censorship. Recall the requirement from our miner protocol: each miner is required to (i) reference recent blocks, and to (ii) publish his blocks immediately. Each attack is basically a violation of one of these requirements. In the double-spending attack, the attacker delays the publication of a set of blocks (that includes a conﬂicting transaction), and in the censorship attack he publishes blocks but “ignores” a certain block and transactions inside it, hoping to convince nodes that it did not secure enough votes, and thus cannot be accepted.

## B. 双花攻击的例子

Fig. 3 depicts an (unsuccessful) double-spending attack. The attack is composed of three main phases: 图3描述了一次（不成功）的双花攻击。 攻击由三个主要阶段组成：

Phase I: Pre-mining. In phase I, the attacker begins building blocks and withholding them from the network. The ﬁrst block that is constructed (named block y ) contains a transaction that will later conﬂict with the transaction sent to the honest nodes. Blocks built by the attacker ideally form a chain, and due to the voting rules in SPECTRE, will all vote y ≺ x (blocks y ,13,14). Blocks built by the honest node are unaware of y (and also of x that is yet to be created), and will eventually vote according to the majority of future votes. During this phase, attacker blocks reference honest blocks that are built (in hopes of later convincing them to vote y ≺ x). After some time, the attacker transmits the transaction to the network, and proceeds to phase II.

Fig. 3: An example of the voting procedure on a DAG in which a double-spending attack is (unsuccessfully) attempted. Block x and blocks 6-8 vote strongly x ≺ y as they only see x in their past, and not y . Similarly, block y and blocks 13-19 vote strongly y ≺ x. In the DAG which is the past of block 11, each of the blocks 1-5 sees more x ≺ y voters in its future than y ≺ x voters, hence each of them votes x ≺ y . Block 11 votes (as the virtual block of its past votes), according to the majority in its past, thus it too votes x ≺ y . A similar argument goes for the the vote of 11 and 12. Finally, aggregating the vote of all blocks in the DAG, x got more votes hence x ≺ y .

Notice that at the exact time that phase I ends, the attacker has more blocks above block 4 than honest nodes have, so it starts at an advantage: it will more easily sway the vote of block 4 towards y ≺ x (this advantage later disappears as honest nodes typically build blocks faster than the attacker).

Phase II: Waiting for acceptance. The attacker now continues to build blocks in secret. If he publishes his blocks, then his conﬂicting transaction will be visible to all, and the double-spend will be detected. Instead, he waits for block x to receive sufﬁcient weight (in the form of blocks built on top of it) so that the recipient of the transaction in x accepts it, and provides the attacker with some service or product. During this phase, attacker blocks that are created (blocks 15-17) vote y ≺ x, as the attacker is careful to have them reference only his secret chain, and never indirectly reference block x. Honest blocks created during this phase will typically vote x ≺ y since y is hidden from them. Some small number of blocks (created before x propagated to the whole network – block 5 in this example) do not reference x, and so will vote according to the result of future votes.

Phase III: Race to overtake. Once x was accepted by the victim, the attacker wishes to publish his secret blocks in hopes of causing his conﬂicting transaction in y to precede x. In this case, the transaction in x will be considered rejected, and the payment will be canceled (leaving the attacker with an item he did not pay for). He publishes his secret chain (which from this point on is referenced by honest nodes), and continues to build upon it. Blocks that he builds, again do not reference x, and so they vote y ≺ x, supporting his goal. New honest nodes are for the ﬁrst time exposed to the conﬂicting transaction y , and thus vote according to the result in the sub-DAG in their past.

Why the attack fails. First, notice that the attacker in the above example creates fewer blocks in each phase than the honest nodes. This will usually be the case if attackers have less computational power than all honest nodes. “Poisson bursts” in block creation by the attacker are possible, and this will allow him to overtake the network, but these are less likely if the attack lasts for a long period of time. The defender can control the length of phase II by waiting a long while before accepting the transaction, which decreases the probability of such bursts. If phase II is long enough, x will have more votes in this period than y . Weak blocks in the past of x will then vote in favour of x, according to this majority. Such blocks that look at their future begin a cascade: each block further in the past adds a vote that agrees with the majority of future blocks and thus strengthens the decision. The greater the majority obtained in Phase II, the less likely it is that the attacker will be able to catch up from behind in Phase III. The attack therefore depends heavily on successfully swaying the votes of blocks that were created just before x (e.g., block 4).

It is important to note that an attacker that creates more blocks in expectation than the honest network will succeed in carrying out this attack. The blocks voting y ≺ x would outnumber those who vote to the contrary. Hence the 50% threshold in Theorem 3.

## C. 审查攻击的例子

Fig. 4 depicts an (unsuccessful) censorship attack. The attack is composed of a single main phase during which an attacker creates his own blocks, publishes them instantly, but also ignores (and does not reference) recent blocks created by the honest network. The ﬁgure depicts (in stage I on the left side) the current state of the blockchain (where all blocks are published at this point). An honest participant that then observes the network and wishes to tell if a transaction in block x is secure, can see a large number of blocks that do not reference x. These blocks are not guaranteed to vote in favour of x. An attacker may later insert a conﬂicting transaction y and add blocks atop it (this projected attack is depicted on the right-hand side of the ﬁgure). These may potentially sway previously created attacker blocks to vote against x.

The main risk from the censorship attack is that merchants, upon seeing the attacker’s blocks, will consider transactions in block x not sufﬁciently secure. This could potentially delay the acceptance of transactions forever. Our analysis of SPECTRE shows that even in this case the merchants accept transactions quickly (and securely).

Fig. 4: An example of the voting procedure on DAG in which an unsuccessful censorship attack is depicted. The left side depicts the current state of the block DAG. The right-hand side depicts its likely future development. Blocks 12-16 do not add strong votes to x. Can they be convinced to vote for block y when it appears? Will they further sway other blocks in their past? The vote of each block in this projected future are depicted: Blocks 2-9 vote strongly for x as they see it in their past (but not y ). Blocks 17-18 similarly vote strongly for y . Block 16 is indeed convinced to vote for y as more blocks in its future vote for y than for x. Blocks 1, 12-15 vote for x. They each see more votes in favour of x than votes in favour of y in their future. Blocks 10-11 see more x ≺ y voters in their past when they make a recursive call.

Top