You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spacemesh is a fair, race-free, permissionless blockchain protocol currently implemented in the open source [go-spacemesh codebase](https://github.com/spacemeshos/go-spacemesh). The protocol implements a decentralized ledger (a DAG structure, known as the _mesh_) with a native cryptocurrency (Smesh, also known as SMH) that anyone is free to mine and transact. What’s more, the protocol is designed in such a way that anyone with free hard drive space and a stable Internet connection can mine from home (by running the [Spacemesh App](https://github.com/spacemeshos/smapp)) and earn guaranteed rewards in the form of SMH coin, a process known as Smeshing in [Spacemesh terminology](https://github.com/spacemeshos/testnet-guide/blob/master/dict.md).
@@ -71,7 +71,7 @@ Note that, unlike full node implementations for certain other blockchain protoco
71
71
72
72
### PoET server
73
73
74
-
PoET stands for “Proof of Elapsed Time.” It’s a core part of the Spacemesh [consensus protocol](consensus_overview.md), where it’s used to prove that a miner has allocated a chunk of hard drive space to the protocol _for some period of time._ PoST, [described below](#post), is used to prove that _space_ has been allocated; PoET is responsible for the _time_ component of space-time.
74
+
PoET stands for “Proof of Elapsed Time.” It’s a core part of the Spacemesh [consensus protocol](consensus_overview.md), where it’s used to prove that a miner has allocated a chunk of hard drive space to the protocol _for some period of time._ PoST, [described below](#proof-of-space-time), is used to prove that _space_ has been allocated; PoET is responsible for the _time_ component of space-time.
75
75
76
76
PoET is implemented as a web service, separate from go-spacemesh, that anyone can run and offer as a service to Smeshers. Many Smeshers can share a single PoET server, and one Smesher may opt to utilize multiple PoET servers for redundancy. Go-spacemesh [includes code](https://github.com/spacemeshos/go-spacemesh/blob/develop/activation/poet.go) to communicate with a PoET server.
77
77
@@ -97,7 +97,6 @@ SVM is the Spacemesh Virtual Machine, a WebAssembly-compatible smart contract en
97
97
98
98
## Mining
99
99
100
-
<aname="post"></a>
101
100
### Proof of Space-time
102
101
103
102
In Spacemesh, a miner establishes eligibility to produce blocks and participate in [consensus](consensus_overview.md) by publishing an [Activation Transaction (ATX)](atx.md), which contains (among other things) a [Proof of Space-time](post.md).
@@ -125,6 +124,7 @@ Once many miners have produced candidate blocks for a given layer, how does the
125
124
Spacemesh employs a two-step process to achieve finality. The first step is the Hare protocol, which each node runs at the end of every layer. It’s a Byzantine agreement protocol that allows the network to quickly achieve consensus on a canonical set of blocks. The output of the Hare allows bootstrapping of the consensus of the Tortoise, which is a slower, vote-based protocol that methodically counts the votes for and against each block, leading to eventual, final consistency. Each node uses the output of the Hare protocol to decide which previous blocks its newly-produced blocks should vote for. See [Consensus](consensus_overview.md) for more information on these protocols.
126
125
127
126
## Beacon
127
+
128
128
The spacemesh protocol generates its source of randomness by running an epoch-long beacon protocol. The purpose is to introduce unpredictability in the eligibility of making proposals and participating in the Hare protocol. This property is important for preventing a concentration attack where adversaries can influence the mesh content by creating a temporary majority at a given layer. See [Beacon](beacon_overview.md) and [Beacon Protocol](beacon_protocol.md) for more information on the beacon protocol.
129
129
130
130
## Networking
@@ -137,18 +137,18 @@ For more information, see [P2P Networking](p2p_overview.md).
137
137
138
138
The basic building blocks of the Spacemesh protocol, and the overall, canonical mesh data structure, are transactions and blocks. Transactions are account-based, and contain a sender, a recipient, an amount, a signature, and a few other pieces of data. Blocks collate zero or more transactions into a discrete set, and contain a block height (layer number), a signature of the miner, a proof of eligibility, and a few other pieces of data. See [Mining](mining_overview.md) for more information.
139
139
140
-
Other relevant data structures include the various types of proof produced and submitted by miners and other services ([PoET](mining/03-poet.md), [ATX](atx.md)), and vote messages exchanged as part of the [Hare protocol](consensus_overview.md#hare).
140
+
Other relevant data structures include the various types of proof produced and submitted by miners and other services ([PoET](poet.md), [ATX](atx.md)), and vote messages exchanged as part of the [Hare protocol](consensus_overview.md#hare).
141
141
142
142
## Learn More
143
143
144
144
The documents contained in this repository are intended to provide a high-level, developer-centric overview of the Spacemesh protocol and the various infrastructure that implements the protocol. For additional resources, see the following:
145
145
146
-
*[Protocol whitepaper](https://spacemesh.io/spacemesh-protocol-v1-0/), which contains a complete description of the entire protocol with accompanying proofs of correctness
147
-
*[Technical whitepaper](https://spacemesh.io/whitepaper1/), which precedes the protocol whitepaper, and is less rigorous
*[Spacemesh protocol overview](https://spacemesh.io/overview/), an even more high-level overview of the protocol intended for a general audience
150
-
*[The Spacemesh Consensus Protocol](https://spacemesh.io/protocol/), a three-part blog post intended for a technical audience that details many of the design decisions behind the protocol
151
-
*[Proof of Space-Time (PoST) with a mesh-based permissionless consensus protocol](https://youtu.be/jvtHFOlA1GI), a talk by Tal Moran, Spacemesh Chief Scientist, at CESC 2018, introducing the protocol
146
+
-[Protocol whitepaper](https://spacemesh.io/spacemesh-protocol-v1-0/), which contains a complete description of the entire protocol with accompanying proofs of correctness
147
+
-[Technical whitepaper](https://spacemesh.io/whitepaper1/), which precedes the protocol whitepaper, and is less rigorous
-[Spacemesh protocol overview](https://spacemesh.io/overview/), an even more high-level overview of the protocol intended for a general audience
150
+
-[The Spacemesh Consensus Protocol](https://spacemesh.io/protocol/), a three-part blog post intended for a technical audience that details many of the design decisions behind the protocol
151
+
-[Proof of Space-Time (PoST) with a mesh-based permissionless consensus protocol](https://youtu.be/jvtHFOlA1GI), a talk by Tal Moran, Spacemesh Chief Scientist, at CESC 2018, introducing the protocol
Miners become eligible to mine in Spacemesh by publishing an Activation Transaction (ATX). The ATX is a Spacemesh-specific data structure that contains a [NIPoST](04-nipost.md), a publicly verifiable, self-contained proof that the miner committed some space-time resources to the protocol.
3
+
Miners become eligible to mine in Spacemesh by publishing an Activation Transaction (ATX). The ATX is a Spacemesh-specific data structure that contains a [NIPoST](nipost.md), a publicly verifiable, self-contained proof that the miner committed some space-time resources to the protocol.
4
4
5
5
The previous documents in this section describe the _theory_ behind a set of independent protocols (PoST, PoET, NIPoST) that form the foundation of the Spacemesh mining construction. With this background in place, we are now ready to see how these building blocks fit together _in practice_ to enable the Spacemesh mining construction in the production network. In particular, we'll see how the NIPoST (which itself contains the PoST and PoET) is wrapped, with accompanying metadata, into an ATX and used in the Spacemesh protocol.
6
6
7
-
8
7
## Epochs and eligibility
9
8
10
9
In Spacemesh, multiple blocks are produced at each block height: the set of blocks produced at a given height is known as a _layer._ Time is divided into _epochs_, where an epoch is a fixed number of layers (unlike protocols like Bitcoin where blocks are produced probabilistically, and thus at random intervals, in Spacemesh the length of time between each layer is perfectly fixed and always the same). Every miner publishes one ATX per epoch, which causes the protocol to consider them “active” in the following epoch.
11
10
12
-
Due to the [race-free nature of the Spacemesh protocol](https://spacemesh.io/race-freeness/), being “active” guarantees a miner eligibility to produce blocks. The reward calculation and total voting weight of the blocks produced by a given miner in the consensus protocol are proportional to the space-time resources attested to by that miner in the NIPoST (contained in their ATX). An active miner is also eligible to participate in Hare consensus protocol[LINK forthcoming].
11
+
Due to the [race-free nature of the Spacemesh protocol](https://spacemesh.io/race-freeness/), being “active” guarantees a miner eligibility to produce blocks. The reward calculation and total voting weight of the blocks produced by a given miner in the consensus protocol are proportional to the space-time resources attested to by that miner in the NIPoST (contained in their ATX). An active miner is also eligible to participate in [Hare consensus protocol](hare_README.md).
13
12
14
13
An epoch is long enough that each active miner should be able to generate at least one block per epoch (and probably many more)—e.g., if there are 100,000 active miners, and 200 blocks per layer, each epoch should be at least 500 layers long. The positions of a given miner’s blocks within layers in the epoch and the participation period in the Hare protocol are selected using a [verifiable random function (VRF)](https://en.wikipedia.org/wiki/Verifiable_random_function), a source of randomness that is verifiable, unpredictable and unbiasable by an adversary. This is necessary to ensure (with high probability) that the majority of blocks in every layer is generated by honest parties.
15
14
16
15
[Consider adding an illustration or animation here to make it clearer how and when ATXs are generated, broadcasted, stored, etc.]
17
16
18
-
19
17
## Construction
20
18
21
-
Unlike the [PoST](02-post.md) and [PoET](03-poet.md) constructions, an ATX is not itself a proof and as such it does not require any additional commitment of resources or complex computation. Instead, like [NIPoST](04-nipost.md), it’s a data structure that wraps the ATX along with relevant metadata. An ATX is a “freestanding” transaction: it does not have to be included in a block to be valid, but can just be gossiped to the network directly.
19
+
Unlike the [PoST](post.md) and [PoET](poet.md) constructions, an ATX is not itself a proof and as such it does not require any additional commitment of resources or complex computation. Instead, like [NIPoST](nipost.md), it’s a data structure that wraps the ATX along with relevant metadata. An ATX is a “freestanding” transaction: it does not have to be included in a block to be valid, but can just be gossiped to the network directly.
22
20
23
21
In addition to the full NIPoST attested to by the ATX, the ATX also contains fields such as the ID of the previous ATX from the same miner, the time when the eligibility for this ATX starts and ends, and the miner’s signature. See [the full protocol specifications](https://spacemesh.io/spacemesh-protocol-v1-0/) for an elaboration of the full contents of the ATX.
24
22
25
-
26
23
## Validity
27
24
28
25
Every valid block [LINK forthcoming] contains a pointer to a valid ATX that authorizes the miner in question to produce a block in the epoch and layer where the block was produced. In order to determine whether a given block is valid, a miner first fetches the ATX that the block points to, and validates that ATX. The ATX is considered valid if it has a valid signature from the miner, if no duplicate ATX was published, if the NIPoST it contains is valid, and if the time indicated by the ATX matches the duration attested to by the NIPoST. These validation rules prevent a dishonest miner from pre-generating ATXs for multiple identities, reusing the same storage space, and publishing them all in a single future epoch. See [the full protocol specifications](https://spacemesh.io/spacemesh-protocol-v1-0/) for a full elaboration of the validation rules for an ATX.
29
26
30
-
31
27
## Conclusion
32
28
33
-
Congratulations, dear reader, on making it to the bottom of this deep, dark rabbit hole! With all of the building blocks in place—PoST, PoET, NIPoST, and ATX—you now fully understand all of the components of the Proof of Space-time protocol underlying the Spacemesh blockchain, and how they fit together to allow miners to prove in a publicly verifiable, self-contained, non-interactive fashion that they’ve committed a certain amount of space-time resources to the protocol. Read on to learn about the [other parts of the protocol](../README.md#repository-contents).
29
+
Congratulations, dear reader, on making it to the bottom of this deep, dark rabbit hole! With all of the building blocks in place—PoST, PoET, NIPoST, and ATX—you now fully understand all of the components of the Proof of Space-time protocol underlying the Spacemesh blockchain, and how they fit together to allow miners to prove in a publicly verifiable, self-contained, non-interactive fashion that they’ve committed a certain amount of space-time resources to the protocol. Read on to learn about the [other parts of the protocol](README.md#repository-contents).
Copy file name to clipboardexpand all lines: beacon_overview.md
+1-7
Original file line number
Diff line number
Diff line change
@@ -2,15 +2,14 @@
2
2
3
3
## Overview
4
4
5
-
The spacemesh protocol requires a source of randomness to introduce unpredictability in the eligibility of making proposals and participating in the Hare protocol. This property is important for preventing a concentration attack where adversaries can influence the mesh content by creating a temporary majority at a given layer.
5
+
The spacemesh protocol requires a source of randomness to introduce unpredictability in the eligibility of making proposals and participating in the Hare protocol. This property is important for preventing a concentration attack where adversaries can influence the mesh content by creating a temporary majority at a given layer.
6
6
7
7
Additionally in the Tortoise protocol, every smesher cast votes on all historical blocks when making proposals. When honest parties cannot decide how to vote on blocks, a weak coin is used to help them vote in the same direction on all undecided blocks in older layers. The generation of this weak coin also needs an element of randomness to prevent the adversary from unduly influencing the votes.
8
8
9
9
For the beacon to achieve its intended purpose, all honest parties must agree on the beacon value, and the value must be both unpredictable and hard to influence. As a result, the value cannot depend on any agreement about history, and needs to be generated recently enough to make it difficult for adversaries to prepare for an attack, yet allow ample time for the network to reach consensus on the value.
10
10
11
11
Spacemesh runs a beacon protocol to generate a random value as the beacon at the beginning of every epoch. A miner (a.k.a smesher in [Spacemesh parlance](https://github.com/spacemeshos/testnet-guide/blob/master/dict.md)) must satisfy all of the following conditions to participate in the beacon protocol in epoch _N_:
12
12
13
-
14
13
* It is online
15
14
* It is synced. i.e. It has all the data in the network up to the current layer and has listened to gossip for at least 2 layers.
16
15
* It has a valid ATX in epoch _N-1_
@@ -19,27 +18,22 @@ The beacon generated in epoch _N_ is declared by every smesher in its first ball
19
18
20
19
The beacon protocol is essentially a simplified Tortoise consensus protocol: each sampled smesher first proposes its own seed of randomness, then all active smeshers cast votes on these proposals repeatedly until consensus is reached. The adversary learns the beacon value after the first round (if there's no attack, then the first round proposals will be exactly the final consensus). The purpose of the voting iterations is to ensure honest miners reach consensus even under adversarial attack, and the number is set such that the probability that they don't reach consensus is negligible. By the time the beacon value is revealed, there won’t be sufficient time for adversaries to take advantage of it in time for the next epoch via key grinding. Key grinding is an activity where malicious parties burn through a large number of keys to find one that gives them favorable future eligibility. Specifically in the Spacemesh protocol, the only way the adversary can "key grind" is by grinding **on their identity**. Once an identity is published, it commits the adversary to all future randomness.
21
20
22
-
23
21
## Uses
24
22
25
23
The beacon is used in the following components of Spacemesh:
26
24
27
-
28
25
### Hare Protocol
29
26
30
27
A smesher is eligible to participate in the hare protocol when its VRF output is valid and passes a certain threshold. The beacon is part of the input to the VRF. If a smesher uses a different beacon value than the rest of the network, its VRF output is deemed invalid by the rest of the network. Its hare messages will be rejected.
31
28
32
-
33
29
### Tortoise Protocol
34
30
35
31
Ballots are how smeshers vote for all historical blocks. The Tortoise protocol counts the votes in these ballots to reach consensus on historical blocks. A smesher must declare a beacon value in their first ballot (a.k.a the reference ballot) of an epoch and will not be able to change it for the rest of the epoch. All its remaining ballots in the epoch point to the reference ballot. The beacon values in these ballots are used to determine how smeshers' votes are counted.
36
32
37
-
38
33
#### Verifying Tortoise
39
34
40
35
In verifying tortoise, votes from ballots with beacon values different than what the verifying node believes is in consensus are not counted because these ballots are potentially malicious.
41
36
42
-
43
37
#### Self Healing
44
38
45
39
During self healing, votes from ballots with incorrect beacons are postponed. This is because in the case of self healing the network may be in the process of recovering from a network partitioning event where each partition has its own beacon value. The network needs to count all ballots, correct beacon or not, to eventually converge on their opinions about historical blocks. When a smesher’s node is in self-healing mode, ballots in layer _N_ with incorrect beacons will only be counted after _D_ layers have elapsed, where _D_ is the number of layers to delay the effects of ballots with the wrong beacon. In this case, their votes only start to matter when the network advances to layer _N+D_.
0 commit comments