fix: fix links and formatting in algorithms section (#978)

Co-authored-by: Hugo Dias <mail@hugodias.me>

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.

next/content/algorithms/crypto/_index.md

@@ -8,6 +8,9 @@ entries:
   - randomness
 ---
 
+# Cryptographic Primitives
+---
+
   - Merkle tree/DAG
   - Vector commitment scheme
   - zkSNARK

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 >}}
-
-
-{{</* label randomness */>}}
-
 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:
-{{</* readfile file="../struct/chain/chain.go"  lang="go" */>}}
+{{<embed src="/systems/filecoin_blockchain/struct/chain/chain.go" lang="go">}}
 
 ## 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 >}}
 
-{{</* readfile file="/docs/actors/actors/crypto/randomness.go"  lang="go" */>}}
-{{</* readfile file="/docs/systems/filecoin_blockchain/struct/chain/chain.go"  lang="go" */>}}
+{{<embed src="/docs/actors/actors/crypto/randomness.go"  lang="go">}}
+{{<embed src="/systems/filecoin_blockchain/struct/chain/chain.go" lang="go">}}
 
 ## 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).
+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).

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 >}}
-
-{{</* readfile file="signatures.id"  lang="go" */>}}
+{{<embed src="signatures.id" lang="go">}}
 
 ### 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 >}}
-
-{{</* readfile file="ecdsa.id"  lang="go" */>}}
+{{<embed src="ecdsa.id" lang="go">}}
 
 **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 >}}
-
-{{</* readfile file="bls.id"  lang="go" */>}}
-{{</* readfile file="bls.go"  lang="go" */>}}
+{{<embed src="bls.id" lang="go">}}
+{{<embed src="bls.go" lang="go">}}
 
 **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

next/content/algorithms/crypto/vrf.md

@@ -1,36 +1,26 @@
 ---
 title: "Verifiable Random Function"
-weight: 10
+weight: 2
 ---
 
 # Verifiable Random Function
 ---
 
-{{< hint danger >}}
-Issue with label
-{{< /hint >}}
-
-{{</* label vrf */>}}
-
 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
 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)).
 
-{{</* readfile file="vrf.id"  lang="go" */>}}
-{{</* readfile file="vrf.go"  lang="go" */>}}
+{{<embed src="vrf.id" lang="go">}}
+{{<embed src="vrf.go" lang="go">}}