From 12ab0215cbcddab3ce2d2c2fcbc4819121b2aca7 Mon Sep 17 00:00:00 2001 From: VolodymyrBg Date: Wed, 18 Dec 2024 18:46:26 +0200 Subject: [PATCH] Fix Typos (#317) --- docs/client.md | 4 ++-- docs/utreexo.md | 2 +- packages/consensus/src/types/chain_state.cairo | 2 +- packages/consensus/src/types/utxo_set.cairo | 2 +- packages/consensus/src/validation/transaction.cairo | 2 +- packages/utils/src/hash.cairo | 3 ++- 6 files changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/client.md b/docs/client.md index 8d4197f2..b2830ecf 100644 --- a/docs/client.md +++ b/docs/client.md @@ -4,14 +4,14 @@ In the world of L2s it is a common pattern when a certain computation (e.g. stat - First time to get the result and return it to the user (fast execution backend) - Second time to generate a validity proof (slow execution backend) -The primary reason for compute things twice is that we want to serve users as fast as possible, while a proper verifiable run can be run in the background for a longer time period. On top of that, sometimes we need to look ahead into the future to reduce the complexity of the verifiable program. In practice that means we pass the result of the first (fast) run as arguments of the second (slow) run. +The primary reason for computing things twice is that we want to serve users as fast as possible, while a proper verifiable run can be run in the background for a longer time period. On top of that, sometimes we need to look ahead into the future to reduce the complexity of the verifiable program. In practice that means we pass the result of the first (fast) run as arguments of the second (slow) run. ## What is Raito Having this dual-run model in mind we can now define what Raito is. Raito is a verifiable program that in its turn validates that a given Bitcoin block is valid (full consensus validation). -So it does the very same checks as a Bitcoin Core node but in such a way that its possible to generate a succinct proof of a fact that a particular Bitcoin block is valid. +So it does the very same checks as a Bitcoin Core node but in such a way that it is possible to generate a succinct proof of a fact that a particular Bitcoin block is valid. ## How to use diff --git a/docs/utreexo.md b/docs/utreexo.md index 51a0f5a1..1c880ad8 100644 --- a/docs/utreexo.md +++ b/docs/utreexo.md @@ -54,7 +54,7 @@ More specifically, stump consists of roots and the number of leaves (as we know Note that previously we had either a root or "null" for every row in the forest, but in stump we have to use a different approach to determine to which row a particular root belongs. A simple rule is if the row length is even we skip it, otherwise (odd) the root is added. Another way to see this is to look at the binary representation of the leaves number and for each "1" there should be a root in the according row. -Also it's worth noting that before "null" was indicating a missing roots whereas in stump empty root just means its children are empty too. +Also it's worth noting that before "null" was indicating missing roots whereas in stump empty root just means its children are empty too. ## Batch proof diff --git a/packages/consensus/src/types/chain_state.cairo b/packages/consensus/src/types/chain_state.cairo index 4022fe52..83205483 100644 --- a/packages/consensus/src/types/chain_state.cairo +++ b/packages/consensus/src/types/chain_state.cairo @@ -1,4 +1,4 @@ -//! Chain state is a minimal subset of data required to unambiguosly +//! Chain state is a minimal subset of data required to unambiguously //! define a particular blockchain starting at the genesis. //! //! Chain state alone is not enough to do full block validation, however diff --git a/packages/consensus/src/types/utxo_set.cairo b/packages/consensus/src/types/utxo_set.cairo index 71b77de6..d83e5e69 100644 --- a/packages/consensus/src/types/utxo_set.cairo +++ b/packages/consensus/src/types/utxo_set.cairo @@ -1,7 +1,7 @@ //! Unspent transaction output set contains outputs from the previous blocks //! that can be referenced in the transaction inputs. //! -//! UTXO set is very large hence it is infeasible to pass it entirely as a program input. +//! UTXO set is enormous hence it is infeasible to pass it entirely as a program input. //! Instead we provide only a subset of outputs that are: //! - going to be spent in the validated blocks //! - created in the previous blocks (i.e. are not spent in the same block) diff --git a/packages/consensus/src/validation/transaction.cairo b/packages/consensus/src/validation/transaction.cairo index 63f9127b..4a0e8d01 100644 --- a/packages/consensus/src/validation/transaction.cairo +++ b/packages/consensus/src/validation/transaction.cairo @@ -109,7 +109,7 @@ fn compute_transaction_fee( Result::Ok(total_input_amount - total_output_amount) } -/// Ensures than coinbase output is old enough to be spent. +/// Ensures that coinbase output is old enough to be spent. fn validate_coinbase_maturity(output_height: u32, block_height: u32) -> Result<(), ByteArray> { if block_height < output_height + 100 { return Result::Err( diff --git a/packages/utils/src/hash.cairo b/packages/utils/src/hash.cairo index a7e52c40..263ea856 100644 --- a/packages/utils/src/hash.cairo +++ b/packages/utils/src/hash.cairo @@ -97,7 +97,8 @@ pub impl U256IntoDigest of Into { } } -/// `Into` implementation that converts a `Digest` value into a `u256` type and reverse bytes order. +/// `Into` implementation that converts a `Digest` value into a `u256` type and reverses bytes +/// order. /// `Digest` is little-endian order, while `u256` is big-endian like in explorer. pub impl DigestIntoU256 of Into { fn into(self: Digest) -> u256 {