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 implements a form of native account abstraction (a.k.a., account unification): all accounts are smart contract-based accounts. There are no keypair-based "externally owned accounts" (EOAs) as in Ethereum.
8
+
Spacemesh implements a form of native account abstraction (a.k.a., account unification): all accounts are smart
9
+
contract-based accounts. There are no keypair-based "externally owned accounts" (EOAs) as in Ethereum.
9
10
10
-
An account has an address (24 bytes long, typically expressed as a [bech32](https://en.bitcoin.it/wiki/Bech32) string starting with `sm1` for mainnet and `stest1` for testnet), a template address, a nonce, a balance, and state. The template contains the smart contract's code; as of now there are no user-deployed smart contracts and no code stored inside account objects, there's only a short set of hardcoded "precompiled" templates (see [below](#accounts-1)).
11
+
An account has an address (24 bytes long, typically expressed as a [bech32](https://en.bitcoin.it/wiki/Bech32) string
12
+
starting with `sm1` for mainnet and `stest1` for testnet), a template address, a nonce, a balance, and state. The
13
+
template contains the smart contract's code; as of now there are no user-deployed smart contracts and no code stored
14
+
inside account objects, there's only a short set of hardcoded "precompiled" templates (see [below](#accounts-1)).
11
15
12
-
A "stub" account has only a balance, no template, nonce, or state. This is simply an account that's received one or more inbound transactions but hasn't been spawned yet. The "spawn" operation occurs when the owner of the account reveals the template address and immutable state used to generate the address (i.e., the account preimage). A simple or multisig wallet must be spawned (i.e., the Spawn method must be called) before funds can be spent (i.e., before the Spend method is called).
16
+
A "stub" account has only a balance, no template, nonce, or state. This is simply an account that's received one or more
17
+
inbound transactions but hasn't been spawned yet. The "spawn" operation occurs when the owner of the account reveals the
18
+
template address and immutable state used to generate the address (i.e., the account preimage). A simple or multisig
19
+
wallet must be spawned (i.e., the Spawn method must be called) before funds can be spent (i.e., before the Spend method
20
+
is called).
13
21
14
-
Any account with a balance can pay for any transaction. The account that pays for a transaction is known as the "principal" of the transaction. Typically a wallet account serves as the principal for its own transactions, but more complex arrangements are possible including multisigs and applications that pay for user transactions.
22
+
Any account with a balance can pay for any transaction. The account that pays for a transaction is known as the
23
+
"principal" of the transaction. Typically a wallet account serves as the principal for its own transactions, but more
24
+
complex arrangements are possible including multisigs and applications that pay for user transactions.
Copy file name to clipboardExpand all lines: docs/learn/atx.md
+18-5Lines changed: 18 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,19 +3,32 @@ id: atx
3
3
title: ATX
4
4
---
5
5
6
-
After successfully generating the PoST, the smesher creates an Activation Transaction (ATX) and submits it to the network. This transaction includes the smesher’s PoST, their wallet address (to which rewards will go), and some other data. The ATX is then used to calculate the smesher's eligibility to participate in the rewards. For all subsequent epochs, the PoET service uses ATXs as the challenge value instead of the initial PoSp. As such, after the smesher’s first epoch, only a single PoSp (the later PoSp) is required per epoch.
6
+
After successfully generating the PoST, the smesher creates an Activation Transaction (ATX) and submits it to the
7
+
network. This transaction includes the smesher’s PoST, their wallet address (to which rewards will go), and some other
8
+
data. The ATX is then used to calculate the smesher's eligibility to participate in the rewards. For all subsequent
9
+
epochs, the PoET service uses ATXs as the challenge value instead of the initial PoSp. As such, after the smesher’s
10
+
first epoch, only a single PoSp (the later PoSp) is required per epoch.
7
11
8
12
## Weight
9
13
10
-
Every ATX also has a weight. Since multiple smeshers contribute to the same block, it is important to reward them accordingly. The absolute weight is calculated by multiplying the SUs allocated by a smesher by the number of PoET ticks for those allocated SUs (Space Units * PoET ticks). Put simply, the allocated space is multiplied by the time (measured by PoET ticks) that the special data was kept on the disk.
14
+
Every ATX also has a weight. Since multiple smeshers contribute to the same block, it is important to reward them
15
+
accordingly. The absolute weight is calculated by multiplying the SUs allocated by a smesher by the number of PoET ticks
16
+
for those allocated SUs (Space Units * PoET ticks). Put simply, the allocated space is multiplied by the time (measured
17
+
by PoET ticks) that the special data was kept on the disk.
11
18
12
-
Once the ATX’s absolute weight is derived, its relative weight (ATX weight / weight of all ATXs in the epoch) is calculated. This is the ATX’s weight in proportion to the total weight of all ATXs. Based on this relative weight, the number of block proposals a smesher is eligible to publish can be calculated.
19
+
Once the ATX’s absolute weight is derived, its relative weight (ATX weight / weight of all ATXs in the epoch) is
20
+
calculated. This is the ATX’s weight in proportion to the total weight of all ATXs. Based on this relative weight, the
21
+
number of block proposals a smesher is eligible to publish can be calculated.
13
22
14
23
## Block Proposals
15
24
16
-
Smeshers who submit a valid ATX during an epoch become eligible to publish block proposals in the following epoch. A block proposal is a set of data that includes transactions from the smesher’s mempool, the smesher’s signature, and some data that proves that this smesher is eligible to publish a block proposal in this layer.
25
+
Smeshers who submit a valid ATX during an epoch become eligible to publish block proposals in the following epoch. A
26
+
block proposal is a set of data that includes transactions from the smesher’s mempool, the smesher’s signature, and some
27
+
data that proves that this smesher is eligible to publish a block proposal in this layer.
17
28
18
-
Currently, the protocol targets 50 block proposals per layer and there are 4032 layers per epoch, with each layer lasting 5 minutes. The absolute weight of an ATX is divided by the number of block proposals that the smesher is eligible for to determine the weight of each of those block proposals.
29
+
Currently, the protocol targets 50 block proposals per layer and there are 4032 layers per epoch, with each layer
30
+
lasting 5 minutes. The absolute weight of an ATX is divided by the number of block proposals that the smesher is
31
+
eligible for to determine the weight of each of those block proposals.
Copy file name to clipboardExpand all lines: docs/learn/blocks.md
+36-11Lines changed: 36 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,18 +3,43 @@ id: blocks
3
3
title: Blocks and Transactions
4
4
---
5
5
6
-
In traditional blockchains such as Bitcoin or Ethereum each block contains a "backwards pointer" to the previous known block (i.e., the previous chain head). In this way it's not possible to replace a single, historical block without replacing every block that came after.
7
-
8
-
Due to its mesh design, Spacemesh doesn't work this way. Spacemesh blocks are freestanding, i.e., each individual block is deemed valid or invalid on its own right by the consensus mechanisms, Tortoise and Hare. The protocol allows for zero or more valid blocks in a given layer. The vast majority of layers are expected to have a single valid, effective block. Empty layers may occur from time to time when certain assumptions are violated, e.g., when many miners are offline and the Hare consensus mechanism fails.
9
-
10
-
There can only be multiple valid blocks in a given layer when security assumptions are temporarily violated, e.g., when the network temporarily loses synchrony or > 1/3 of miners act dishonestly. In this case the protocol dictates that a single block be deterministically chosen as the only _effective_ block for the layer. Over time the network's self-healing mechanism ensures that all honest nodes reach consensus on the canonical set of valid, effective blocks, zero or one per layer.
11
-
12
-
In practice this means that a _single historical block_ and its contents may be reorg'ed in or out of the canonical chain. When a historical change occurs, the state rolls back (i.e., reorgs) to the point of change and all subsequent canonical state (i.e., all transactions in the new canonical chain) is replayed from that point forward. This could mean that transactions in the canonical chain that were previously effective now become ineffective, or vice versa. It may also mean that the same transaction (uniquely identified by its transaction ID) may appear in multiple blocks, in the same layer or in multiple layers. When this happens, only the first instance of the transaction in the canonical chain is considered effective; later instances are ignored.
13
-
14
-
A layer contains zero or more blocks. Most layers contain exactly one block, but it's possible for a layer to have zero blocks (when the network is under attack, or during times when many miners were offline or otherwise acting Byzantine) or more than one block (e.g., after a network partition-and-rejoin). In rare cases of multiple blocks, the network will establish consensus on a single block as canonical; transactions in other blocks will not be included in the canonical mesh nor processed. A block may thus be _valid_ or _invalid_ and there may only be one _valid_ block per layer.
6
+
In traditional blockchains such as Bitcoin or Ethereum each block contains a "backwards pointer" to the previous known
7
+
block (i.e., the previous chain head). In this way it's not possible to replace a single, historical block without
8
+
replacing every block that came after.
9
+
10
+
Due to its mesh design, Spacemesh doesn't work this way. Spacemesh blocks are freestanding, i.e., each individual block
11
+
is deemed valid or invalid on its own right by the consensus mechanisms, Tortoise and Hare. The protocol allows for zero
12
+
or more valid blocks in a given layer. The vast majority of layers are expected to have a single valid, effective block.
13
+
Empty layers may occur from time to time when certain assumptions are violated, e.g., when many miners are offline and
14
+
the Hare consensus mechanism fails.
15
+
16
+
There can only be multiple valid blocks in a given layer when security assumptions are temporarily violated, e.g., when
17
+
the network temporarily loses synchrony or > 1/3 of miners act dishonestly. In this case the protocol dictates that a
18
+
single block be deterministically chosen as the only _effective_ block for the layer. Over time the network's
19
+
self-healing mechanism ensures that all honest nodes reach consensus on the canonical set of valid, effective blocks,
20
+
zero or one per layer.
21
+
22
+
In practice this means that a _single historical block_ and its contents may be reorg'ed in or out of the canonical
23
+
chain. When a historical change occurs, the state rolls back (i.e., reorgs) to the point of change and all subsequent
24
+
canonical state (i.e., all transactions in the new canonical chain) is replayed from that point forward. This could mean
25
+
that transactions in the canonical chain that were previously effective now become ineffective, or vice versa. It may
26
+
also mean that the same transaction (uniquely identified by its transaction ID) may appear in multiple blocks, in the
27
+
same layer or in multiple layers. When this happens, only the first instance of the transaction in the canonical chain
28
+
is considered effective; later instances are ignored.
29
+
30
+
A layer contains zero or more blocks. Most layers contain exactly one block, but it's possible for a layer to have zero
31
+
blocks (when the network is under attack, or during times when many miners were offline or otherwise acting Byzantine)
32
+
or more than one block (e.g., after a network partition-and-rejoin). In rare cases of multiple blocks, the network will
33
+
establish consensus on a single block as canonical; transactions in other blocks will not be included in the canonical
34
+
mesh nor processed. A block may thus be _valid_ or _invalid_ and there may only be one _valid_ block per layer.
15
35
16
36
Blocks contain zero or more transactions. Blocks are uniquely indexed by their block hash.
17
37
18
-
Transactions are uniquely indexed by their transaction ID. The same transaction may be included in multiple blocks, but not in multiple blocks on the canonical chain (i.e., multiple _valid_ blocks). A transaction has a _state_ that may be `pending` (i.e., not processed yet), `mempool` (successfully added to the mempool but not yet mined into a block), or `applied` (successfully mined into a block).
38
+
Transactions are uniquely indexed by their transaction ID. The same transaction may be included in multiple blocks, but
39
+
not in multiple blocks on the canonical chain (i.e., multiple _valid_ blocks). A transaction has a _state_ that may be
40
+
`pending` (i.e., not processed yet), `mempool` (successfully added to the mempool but not yet mined into a block), or
41
+
`applied` (successfully mined into a block).
19
42
20
-
A transaction that was successfully `applied` can still fail if, e.g., the principal account doesn't have enough funds to pay for its gas: we call this an "ineffective" transaction. This is not currently captured cleanly in the API. Implementing transaction receipts is still a work in progress.
43
+
A transaction that was successfully `applied` can still fail if, e.g., the principal account doesn't have enough funds
44
+
to pay for its gas: we call this an "ineffective" transaction. This is not currently captured cleanly in the API.
45
+
Implementing transaction receipts is still a work in progress.
Copy file name to clipboardExpand all lines: docs/learn/coin.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,5 +4,7 @@ title: Spacemesh Coin
4
4
---
5
5
6
6
## Basic Units
7
+
7
8
-`Smesh` (SMH) is the name of the Spacemesh native cryptocurrency. 1 Smesh equals 10^9 (1 billion) Smidge.
8
-
-`Smidge` (SMIDGE) is the basic unit of accounting of the Spacemesh platform. It is used mostly by developers in smart contracts code and by users and for transaction fees. One billion (10^9) Smidge equals to one Smesh.
9
+
-`Smidge` (SMIDGE) is the basic unit of accounting of the Spacemesh platform. It is used mostly by developers in smart
10
+
contracts code and by users and for transaction fees. One billion (10^9) Smidge equals to one Smesh.
Copy file name to clipboardExpand all lines: docs/learn/crypto.md
+13-5Lines changed: 13 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,20 +3,28 @@ id: crypto
3
3
title: What Is Cryptocurrency?
4
4
---
5
5
6
-
A cryptocurrency is a digital currency that is secured by a cryptographically-encrypted ledger called a blockchain. In turn, this ledger contains an immutable record of every transaction that has ever occured using the cryptocurrency.
6
+
A cryptocurrency is a digital currency that is secured by a cryptographically-encrypted ledger called a blockchain. In
7
+
turn, this ledger contains an immutable record of every transaction that has ever occurred using the cryptocurrency.
7
8
8
9
## What Makes Cryptocurrency Important
9
10
10
-
The move to digital currency has been happening since the dawn of the Internet. But these are just digital representations of existing fiat currencies, and are not a true shift from the existing status quo of our financial and monetary systems.
11
+
The move to digital currency has been happening since the dawn of the Internet. But these are just digital
12
+
representations of existing fiat currencies, and are not a true shift from the existing status quo of our financial and
13
+
monetary systems.
11
14
12
15
Banks and governments still control these assets.
13
16
14
17
But cryptocurrency is something new: a decentralized, purely digital currency that no single entity or group controls.
15
18
16
-
It is also fully anonymous. Transactions are recorded on the public ledger, but the identities of the parties involved are not revealed.
19
+
It is also fully anonymous. Transactions are recorded on the public ledger, but the identities of the parties involved
20
+
are not revealed.
17
21
18
-
This represents a paradigm shift from our existing system, especially in the realm of financial inclusion. Cryptocurrencies can be used by anyone with an Internet connection, which gives them the potential to reach populations that are unbanked or underserved by traditional financial institutions.
22
+
This represents a paradigm shift from our existing system, especially in the realm of financial inclusion.
23
+
Cryptocurrencies can be used by anyone with an Internet connection, which gives them the potential to reach populations
24
+
that are un-banked or under-served by traditional financial institutions.
19
25
20
26
## Digital Gold
21
27
22
-
One of the key features of cryptocurrencies is that they are not fiat currencies. That is, they are tied to a another commodity and must be "mined", meaning that they can't be printed at will. So, like currencies tied to hard commodities like gold, they are inflation-resistant because they cannot be printed at will by central banks.
28
+
One of the key features of cryptocurrencies is that they are not fiat currencies. That is, they are tied to a another
29
+
commodity and must be "mined", meaning that they can't be printed at will. So, like currencies tied to hard commodities
30
+
like gold, they are inflation-resistant because they cannot be printed at will by central banks.
0 commit comments