diff --git a/next/content/algorithms/block_sync.md b/next/content/algorithms/block_sync.md index 2f30aebcf..cf1ecfeaf 100644 --- a/next/content/algorithms/block_sync.md +++ b/next/content/algorithms/block_sync.md @@ -4,14 +4,13 @@ weight: 5 --- # BlockSync +--- {{< hint info >}} **Name**: Block Sync **Protocol ID**: `/fil/sync/blk/0.0.1` {{< /hint >}} - - The blocksync protocol is a small protocol that allows Filecoin nodes to request ranges of blocks from each other. It is a simple request/response protocol. The request requests a chain of a given length by the hash of its highest block. The `Options` allow the requester to specify whether or not blocks and messages are to be included. diff --git a/next/content/algorithms/crypto/_index.md b/next/content/algorithms/crypto/_index.md index 0c3071914..b501fa89f 100644 --- a/next/content/algorithms/crypto/_index.md +++ b/next/content/algorithms/crypto/_index.md @@ -8,6 +8,9 @@ entries: - randomness --- +# Cryptographic Primitives +--- + - Merkle tree/DAG - Vector commitment scheme - zkSNARK diff --git a/next/content/algorithms/crypto/randomness.md b/next/content/algorithms/crypto/randomness.md index 6cc515e99..787d79c3f 100644 --- a/next/content/algorithms/crypto/randomness.md +++ b/next/content/algorithms/crypto/randomness.md @@ -1,24 +1,13 @@ --- title: "Randomness" +weight: 3 --- # Randomness --- -{{< hint danger >}} -Issues with labels and readfile throughout -{{< /hint >}} - - -{{< hint danger >}} -Issue with label -{{< /hint >}} - - -{{}} - Randomness is used throughout the protocol in order to generate values and extend the blockchain. -Random values are drawn from the [Ticket Chain](\missing-link) and appropriately formatted for usage. +Random values are drawn from the [Ticket Chain](storage_power_consensus#the-ticket-chain-and-drawing-randomness) and appropriately formatted for usage. We describe this formatting below. ## Encoding On-chain data for randomness @@ -32,11 +21,11 @@ objects that can then be CBOR-serialized according to their algebraic datatypes. Further, we define Domain Separation Tags with which we prepend random inputs when creating entropy. All randomness used in the protocol must be generated in conjunction with a unique DST, as well as -certain [Signatures](\missing-link) and [Verifiable Random Function](\missing-link) usage. +certain [Signatures](signatures) and [Verifiable Random Function](vrf) usage. ## Drawing tickets for randomness from the chain -Tickets are used as a source of on-chain randomness, generated with each new block created (see [Tickets](\missing-link)). +Tickets are used as a source of on-chain randomness, generated with each new block created (see [Tickets](storage_power_consensus#tickets)). A ticket is drawn from the chain for randomness as follows, for a given epoch `n`, and ticket sought at epoch `e`: ```text @@ -61,12 +50,8 @@ In plain language, this means: This ticket is then combined with a Domain Separation Tag, the round number sought and appropriate entropy to form randomness for various uses in the protocol. -{{< hint danger >}} -Issue with readfile -{{< /hint >}} - See the `RandomnessSeedAtEpoch` method below: -{{}} +{{}} ## Forming Randomness Seeds @@ -83,7 +68,7 @@ The drawn ticket digest is combined with a few elements to make up randomness fo While all elements are not needed for every use of entropy (e.g. the inclusion of the round number is not necessary prior to genesis or outside of leader election, other entropy is only used sometimes, etc), we draw randomness as follows for the sake of uniformity/simplicity in the overall protocol. -In all cases, a ticket is used as the base of randomness (see [Tickets](\missing-link)). In order to make randomness seed creation uniform, the protocol derives all such seeds in the same way, using blake2b as a hash function to generate a 256-bit output as follows (also see [Tickets](\missing-link)): +In all cases, a ticket is used as the base of randomness (see [Tickets](storage_power_consensus#tickets)). In order to make randomness seed creation uniform, the protocol derives all such seeds in the same way, using blake2b as a hash function to generate a 256-bit output as follows: In round `n`, for a given randomness lookback `l`, and serialized entropy `s`: @@ -104,8 +89,8 @@ GetRandomness(dst, l, s): Issue with readfile {{< /hint >}} -{{}} -{{}} +{{}} +{{}} ## Entropy to be used with randomness @@ -128,4 +113,4 @@ Currently, we distinguish the following entropy needs in the Filecoin protocol ( - SealRandomness: requires MinerIDAddress - InteractiveSealChallengeSeed: requires MinerIDAddress -The above uses of the MinerIDAddress ensures that drawn randomness is distinct for every miner drawing this (regardless of whether they share worker keys or not, eg -- in the case of randomness that is then signed as part of leader election or ticket production). \ No newline at end of file +The above uses of the MinerIDAddress ensures that drawn randomness is distinct for every miner drawing this (regardless of whether they share worker keys or not, eg -- in the case of randomness that is then signed as part of leader election or ticket production). diff --git a/next/content/algorithms/crypto/signatures.md b/next/content/algorithms/crypto/signatures.md index 4847cce69..ba508a61b 100644 --- a/next/content/algorithms/crypto/signatures.md +++ b/next/content/algorithms/crypto/signatures.md @@ -1,14 +1,11 @@ --- title: "Signatures" +weight: 1 --- # Signatures --- -{{< hint danger >}} -Issue with readfile throughout -{{< /hint >}} - Signatures are cryptographic functions that attest to the origin of a particular message. In the context of Filecoin, signatures are used to send and receive messages with the assurance that each message was generated by a specific @@ -22,15 +19,15 @@ Filecoin uses signatures to verify the authenticity of the following objects (no exhaustive list): - Messages: Users authenticate their transactions to the blockchain. -- Tickets: Miner authenticates its ticket (see [Storage Miner](\missing-link)). +- Tickets: Miner authenticates its ticket (see [Storage Miner](filecoin_mining)). - Blocks: Block leader signs over all data in the block. ## Messages -To generate a signature for the [Message](\missing-link) type, compute the signature over the message's CID (taken as a byte array). +To generate a signature for the [Message](message) type, compute the signature over the message's CID (taken as a byte array). **Note**: for each specific use of a signature scheme, it is recommended to use a domain separation tag to treat the hash function as an independent random oracle. These tags are indicated in the relevant places throughout the specs. -Read more about this in [Randomness](\missing-link). +Read more about this in [Randomness](randomness). ## Signature Types @@ -42,11 +39,7 @@ Filecoin currently uses two types of signatures: Both signature types fulfill the `Signature` interface and each type have additional functionality as explained below. -{{< hint danger >}} -Issue with readfile -{{< /hint >}} - -{{}} +{{}} ### ECDSA Signatures @@ -58,15 +51,11 @@ useful functionality as well: to recover the public key from a given signature. This feature can allow space to be saved on the blockchain by extracting the public key locally from the signature rather than specifying an ID of the public key. -{{< hint danger >}} -Issue with readfile -{{< /hint >}} - -{{}} +{{}} **Wire Format**: Filecoin uses the standard secp256k1 signature serialization, as described below. For more details on how the Filecoin `Signature` type is -serialized, see [Signature](\missing-link). +serialized, see [Signature](signatures). ``` SignatureBytes = [0x30][len][0x02][r][indicator][s][indicator][recovery] @@ -91,12 +80,8 @@ SignatureBytes = [0x30][len][0x02][r][indicator][s][indicator][recovery] Filecoin uses the [BLS signature scheme](https://datatracker.ietf.org/doc/draft-boneh-bls-signature/) over the [BLS12-381](BLS12-381](https://electriccoin.co/blog/new-snark-curve/) group of elliptic curves. You can find the default Rust implementation in [Filecoin's repo](https://github.com/filecoin-project/bls-signatures/). -{{< hint danger >}} -Issue with readfile -{{< /hint >}} - -{{}} -{{}} +{{}} +{{}} **Choice of group**: The BLS signature requires the use of a pairing-equipped curve which generally yield three groups: G_1, G_2 and G_T. In the BLS signature diff --git a/next/content/algorithms/crypto/vrf.md b/next/content/algorithms/crypto/vrf.md index 17f76e345..bb6d91ae4 100644 --- a/next/content/algorithms/crypto/vrf.md +++ b/next/content/algorithms/crypto/vrf.md @@ -1,17 +1,11 @@ --- title: "Verifiable Random Function" -weight: 10 +weight: 2 --- # Verifiable Random Function --- -{{< hint danger >}} -Issue with label -{{< /hint >}} - -{{}} - Filecoin uses the notion of a [Verifiable Random Function](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Pseudo%20Randomness/Verifiable_Random_Functions.pdf) (VRF). A VRF uses a private key to produce a digest of @@ -19,18 +13,14 @@ an arbitrary message such that the output is unique per signer and per message. Any third party in possession of the corresponding public key, the message, and the VRF output, can verify if the digest has been computed correctly and by the correct signer. Using a VRF in the ticket generation process allows anyone to -verify if a block comes from an eligible block producer (see [Ticket Generation (Tickets)](\missing-link) for more details). +verify if a block comes from an eligible block producer (see [Ticket Generation](storage_power_consensus#tickets) for more details). BLS signature can be used as the basis to construct a VRF. Filecoin transforms -the BLS signature scheme it uses (see [Signatures](\missing-link) into a +the BLS signature scheme it uses (see [Signatures](signatures) into a VRF, Filecoin uses the random oracle model and deterministically hashes the signature (using blake2b to produce a 256 bit output) to produce the final digest. -These digests are often used as entropy for randomness in the protocol (see [Randomness](\missing-link)). - -{{< hint danger >}} -Issue with readfile -{{< /hint >}} +These digests are often used as entropy for randomness in the protocol (see [Randomness](randomness)). -{{}} -{{}} \ No newline at end of file +{{}} +{{}} \ No newline at end of file diff --git a/next/content/algorithms/expected_consensus/_index.md b/next/content/algorithms/expected_consensus/_index.md index 826f552dc..4b80f2733 100644 --- a/next/content/algorithms/expected_consensus/_index.md +++ b/next/content/algorithms/expected_consensus/_index.md @@ -8,20 +8,16 @@ weight: 1 ## Algorithm -Expected Consensus (EC) is a probabilistic Byzantine fault-tolerant consensus protocol. At a high level, it operates by running a leader election every round in which, on expectation, one participant may be eligible to submit a block. EC guarantees that this winner will be anonymous until they reveal themselves by submitting a proof of their election. The miner can submit a number of such proofs per round and will be rewarded proportionally. Each proof can be derived from a `Challenge Ticket` produced by the [Election PoSt](\missing-link). All valid blocks submitted in a given round form a `Tipset`. Every block in a Tipset adds weight to its chain. The 'best' chain is the one with the highest weight, which is to say that the fork choice rule is to choose the heaviest known chain. For more details on how to select the heaviest chain, see [Chain Selection](\missing-link). +Expected Consensus (EC) is a probabilistic Byzantine fault-tolerant consensus protocol. At a high level, it operates by running a leader election every round in which, on expectation, one participant may be eligible to submit a block. EC guarantees that this winner will be anonymous until they reveal themselves by submitting a proof of their election. The miner can submit a number of such proofs per round and will be rewarded proportionally. Each proof can be derived from a `Challenge Ticket` produced by the [Election PoSt](election_post). All valid blocks submitted in a given round form a `Tipset`. Every block in a Tipset adds weight to its chain. The 'best' chain is the one with the highest weight, which is to say that the fork choice rule is to choose the heaviest known chain. For more details on how to select the heaviest chain, see [Chain Selection](expected_consensus#chain-selection). At a very high level, with every new block generated, a miner will craft a new ticket from the prior one in the chain appended with the current epoch number (i.e. parentTipset.epoch + 1 to start). While on expectation at least one block will be generated at every round, in cases where no one finds a block in a given round, a miner will increment the round number and attempt a new leader election (using the new input) thereby ensuring liveness in the protocol. -The [Storage Power Consensus](\missing-link) subsystem uses access to EC to use the following facilities: +The [Storage Power Consensus](storage_power_consensus) subsystem uses access to EC to use the following facilities: -- Access to verifiable randomness for the protocol, derived from [Tickets](\missing-link). -- Running and verifying [Secret Leader Election](\missing-link) for block generation. -- Access to a weighting function enabling [Chain Selection](\missing-link) by the chain manager. -- Access to the most recently finalized tipset (see [Finality in EC](\missing-link)) available to all protocol participants. - -{{< hint danger >}} -Issue with readfile -{{< /hint >}} +- Access to verifiable randomness for the protocol, derived from [Tickets](storage_power_consensus#tickets). +- Running and verifying [Secret Leader Election](expected_consensus#secret-leader-election) for block generation. +- Access to a weighting function enabling [Chain Selection](expected_consensus#chain-selection) by the chain manager. +- Access to the most recently finalized tipset (see [Finality in EC](expected_consensus#finality-in-ec)) available to all protocol participants. {{}} {{}} @@ -37,18 +33,13 @@ Tickets are used to achieve the following: In practice, EC defines two different fields within a block: -- A `Ticket` field — this stores the new ticket generated during this block generation attempt. It is from this ticket that miners will sample randomness to run leader election in `K` rounds (see [Tickets](\missing-linkn)). +- A `Ticket` field — this stores the new ticket generated during this block generation attempt. It is from this ticket that miners will sample randomness to run leader election in `K` rounds (see [Tickets](storage_power_consensus#tickets)). - A set of winning `ChallengeTickets` — this stores a proof that a given miner has won a leader election using the appropriate ticket generated by the election PoSt process with randomness `K` rounds back. It proves that the leader was validly elected in this epoch. -{{< hint danger >}} -Issue with readfile -{{< /hint >}} - {{}} {{}} -``` -But why the randomness lookback? +**But why the randomness lookback?** The randomness lookback helps turn independent ticket generation from a block one round back into a global ticket generation game instead. Rather than having a distinct chance of winning or losing @@ -66,15 +57,10 @@ How is K selected? - On the one end, there is no advantage to picking K larger than finality. - On the other, making K smaller reduces adversarial power to grind. -``` -{{< hint danger >}} -Issue with readfile -{{< /hint >}} -{{/*