From 28101be1b788390a5a8a04726cd9a06ef510b6aa Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 31 Jan 2023 23:33:11 +0100 Subject: [PATCH] Fix: typos Fix: typos --- documentation/en/architecture/architecture.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/en/architecture/architecture.md b/documentation/en/architecture/architecture.md index 64914d539..9e78fa650 100644 --- a/documentation/en/architecture/architecture.md +++ b/documentation/en/architecture/architecture.md @@ -81,7 +81,7 @@ Note: The API refers to these stages as `StageHeaders` and `StagePersistHeaders` We proceed in the sync process by requesting block headers from the peer, moving back from their head, until we reach a tipset that we have in common -(such a common tipset must exist, thought it may simply be the genesis block). +(such a common tipset must exist, though it may simply be the genesis block). The functionality can be found in `Syncer::collectHeaders()`. If the common tipset is our head, we treat the sync as a "fast-forward", else we must @@ -126,7 +126,7 @@ If all validations pass we will now set that head as our heaviest tipset in We already have the full state, since we calculated it during the sync process. -FIXME (aayush) I don't fuilly understand the next 2 paragraphs, but it seems important. Confirm and polish. +FIXME (aayush) I don't fully understand the next 2 paragraphs, but it seems important. Confirm and polish. Relevant issue in IPFS: https://github.com/ipfs/ipfs-docs/issues/264 It is important to note at this point that similar to the IPFS architecture of addressing by content and not by location/address (FIXME: check and link to IPFS docs) the "actual" chain stored in the node repo is *relative* to which CID we look for. We always have stored a series of Filecoin blocks pointing to other blocks, each a potential chain in itself by following its parent's reference, and its parent's parent, and so on up to the genesis block. (FIXME: We need a diagram here, one of the Filecoin blog entries might have something similar to what we are describing here.) It only depends on *where* (location) do we start to look for. The *only* address/location reference we hold of the chain, a relative reference, is the `heaviest` pointer. This is reflected by the fact that we don't store it in the `Blockstore` by a fixed, *absolute*, CID that reflects its contents, as this will change each time we sync to a new head (FIXME: link to the immutability IPFS doc that I need to write). @@ -149,7 +149,7 @@ encapsulated in the [`StateTree`](https://github.com/filecoin-project/lotus/blob and accessed through the [`StateManager`](https://github.com/filecoin-project/lotus/blob/master/chain/stmgr/stmgr.go). The state at the chain's head is thus easily tracked and updated in a state root CID. -(FIXME: Talk about CIDs somewhere, we might want to explain some of the modify/flush/update-root mechanism here.)) +(FIXME: Talk about CIDs somewhere, we might want to explain some of the modify/flush/update-root mechanism here.) ## Calculating a Tipset State