From 0a6a045cef7824fc767fdc818ca93d6f936803ba Mon Sep 17 00:00:00 2001 From: Pavel Zaborskii Date: Tue, 26 Nov 2024 02:03:55 +0100 Subject: [PATCH] Update docs for higher accuracy and quality of information (#648) * actions.md * lookup-tables.md * retry.md * state-compression.md * confirmation.md --- docs/advanced/actions.md | 10 +++++----- docs/advanced/confirmation.md | 2 +- docs/advanced/lookup-tables.md | 2 +- docs/advanced/retry.md | 2 +- docs/advanced/state-compression.md | 10 +++++----- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/advanced/actions.md b/docs/advanced/actions.md index f0f5e2d2e..d6bd51e61 100644 --- a/docs/advanced/actions.md +++ b/docs/advanced/actions.md @@ -510,7 +510,7 @@ export interface ActionParameter { The `pattern` should be a string equivalent of a valid regular expression. This regular expression pattern should by used by blink-clients to validate user -input before before making the POST request. If the `pattern` is not a valid +input before making the POST request. If the `pattern` is not a valid regular expression, it should be ignored by clients. The `patternDescription` is a human readable description of the expected input @@ -592,7 +592,7 @@ user input elements are also supported: - `textarea` - equivalent of HTML [textarea element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea). - Allowing the user provide multi-line input. + Allowing the user to provide multi-line input. - `select` - equivalent of HTML [select element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select), allowing the user to experience a “dropdown” style field. The Action API @@ -971,7 +971,7 @@ clients in one of the following ways: UI with the included Action metadata, but will not allow the user to execute further actions. -If no `links.next` is not provided, blink clients should assume the current +If `links.next` is not provided, blink clients should assume the current action is final action in the chain, presenting their "completed" UI state after the transaction is confirmed. @@ -1070,7 +1070,7 @@ The following table outlines the syntax for path matching patterns: ### Rules Examples -The following example demonstrates an exact match rule to map requests requests +The following example demonstrates an exact match rule to map requests to `/buy` from your site's root to the exact path `/api/buy` relative to your site's root: @@ -1210,7 +1210,7 @@ associated with the Action Provider in a multi-step process: 3. Verify the specific transaction is the first on-chain occurrence of the `reference` on-chain: - If this transaction is the first occurrence, the transaction is considered - verified and can a safely attributed to the Action Provider. + verified and can be safely attributed to the Action Provider. - If this transaction is NOT the first occurrence, it is considered invalid and therefore not attributed to the Action Provider. diff --git a/docs/advanced/confirmation.md b/docs/advanced/confirmation.md index b26144204..35d4df0bb 100644 --- a/docs/advanced/confirmation.md +++ b/docs/advanced/confirmation.md @@ -153,7 +153,7 @@ processed transactions. ### Other blockchains -Solana's approach of prevent double processing is quite different from other +Solana's approach to prevent double processing is quite different from other blockchains. For example, Ethereum tracks a counter (nonce) for each transaction sender and will only process transactions that use the next valid nonce. diff --git a/docs/advanced/lookup-tables.md b/docs/advanced/lookup-tables.md index 354d72004..e88f26e52 100644 --- a/docs/advanced/lookup-tables.md +++ b/docs/advanced/lookup-tables.md @@ -147,7 +147,7 @@ utilize the onchain lookup capabilities. Just like older `legacy` transactions, you can create all the [instructions](/docs/terminology.md#instruction) your transaction will execute onchain. You can then provide an array of these instructions to the -[Message](/docs/terminology.md#message) used in the `v0 transaction. +[Message](/docs/terminology.md#message) used in the `v0` transaction. > NOTE: The instructions used inside a `v0` transaction can be constructed using > the same methods and functions used to create the instructions in the past. diff --git a/docs/advanced/retry.md b/docs/advanced/retry.md index 4af07b82c..eb650a099 100644 --- a/docs/advanced/retry.md +++ b/docs/advanced/retry.md @@ -142,7 +142,7 @@ transaction submission if developers enable ![Transaction dropped via an RPC Pool](/assets/docs/rt-dropped-via-rpc-pool.png) -Temporarily network forks can also result in dropped transactions. If a +Temporary network forks can also result in dropped transactions. If a validator is slow to replay its blocks within the Banking Stage, it may end up creating a minority fork. When a client builds a transaction, it's possible for the transaction to reference a `recentBlockhash` that only exists on the diff --git a/docs/advanced/state-compression.md b/docs/advanced/state-compression.md index 786c16237..b0cc2e34a 100644 --- a/docs/advanced/state-compression.md +++ b/docs/advanced/state-compression.md @@ -32,9 +32,9 @@ These _trees_ are created in this "_deterministic_" process by: - taking any piece of data - creating a hash of this data -- storing this hash as a `leaf` the bottom of the tree -- each `leaf` pair is then hash together, creating a `branch` -- each `branch` is then hash together +- storing this hash as a `leaf` at the bottom of the tree +- each `leaf` pair is then hashed together, creating a `branch` +- each `branch` is then hashed together - continually climbing the tree and hashing adjacent branches together - once at the top of the tree, a final `root hash` is produced @@ -94,7 +94,7 @@ In high throughput applications, like within the [Solana runtime](/docs/core/fees.md), requests to change an on-chain _traditional merkle tree_ could be received by validators in relatively rapid succession (e.g. within the same slot). Each leaf data change would still be -required to performed in series. Resulting in each subsequent request for change +required to be performed in series. Resulting in each subsequent request for change to fail, due to the root hash and proof being invalidated by the previous change request in the slot. @@ -175,7 +175,7 @@ We must use a `maxDepth` of `14` to ensure we can store all of our data. The `maxDepth` value will be one of the primary drivers of cost when creating a tree since you will pay this cost upfront at tree creation. The higher the max -tree depth depth, the more data fingerprints (aka hashes) you can store, the +tree depth, the more data fingerprints (aka hashes) you can store, the higher the cost. ### Max buffer size