diff --git a/specs/experimental/fault-proof/fault-dispute-game.md b/specs/experimental/fault-proof/fault-dispute-game.md index e8c0f52a4..6e32a568d 100644 --- a/specs/experimental/fault-proof/fault-dispute-game.md +++ b/specs/experimental/fault-proof/fault-dispute-game.md @@ -317,7 +317,7 @@ proposal in the `PreimageOracle`. This involves: The challenger then submits this data to the `PreimageOracle`, where the post state leaf's claimed input is absored into the pre state leaf's state matrix and the SHA3 permutation is executed on-chain. After that, the resulting state matrix -is hashed and and compared with the proposer's claim in the post state leaf. If the hash does not match, the proposal +is hashed and compared with the proposer's claim in the post state leaf. If the hash does not match, the proposal is marked as challenged, and it may not be finalized. If, after the challenge period is concluded, a proposal has no challenges, it may be finalized and the preimage part may be placed into the authorized mappings for the FPVM to read. @@ -337,7 +337,7 @@ Uncontested claims are likely to result in a loss, as explained later under [Res Every claim in the game has a Clock. A claim inherits the clock of its grandparent claim in the DAG (and so on). Akin to a chess clock, it keeps track of the total time each team takes to make moves, preventing delays. -Making a move resumes the clock for the disputed claim and puases it for the newly added one. +Making a move resumes the clock for the disputed claim and pauses it for the newly added one. A move against a particular claim is no longer possible once the parent of the disputed claim's Clock has exceeded half of the `GAME_DURATION`. By which point, the claim's clock has _expired_. diff --git a/specs/glossary.md b/specs/glossary.md index 2d834efff..1e9440f10 100644 --- a/specs/glossary.md +++ b/specs/glossary.md @@ -648,7 +648,7 @@ head][safe-l2-head] a block forward, so that the oldest [unsafe L2 block][unsafe In order to perform consolidation, the node verifies that the [payload attributes][payload-attr] derived from the L1 chain match the oldest unsafe L2 block exactly. -See the [Engine Queue section][engine-queue] of the L2 chain derivatiaon spec for more information. +See the [Engine Queue section][engine-queue] of the L2 chain derivation spec for more information. [engine-queue]: ./protocol/derivation.md#engine-queue diff --git a/specs/plasma.md b/specs/plasma.md index b2ecf9f88..01b2bf395 100644 --- a/specs/plasma.md +++ b/specs/plasma.md @@ -35,7 +35,7 @@ chain derivation must be reset, omitting the input data when rederiving therefor ## DA Storage Input data is uploaded to the storage layer via plain HTTP calls to the DA storage service. -This service is horizontally scalable and concerned with replicating the data across prefered storage layers +This service is horizontally scalable and concerned with replicating the data across preferred storage layers such as IPFS or any S3 compatible storage. Input data is content addressed by its hash in the request url so responses are easily cachable. @@ -231,6 +231,6 @@ the challenge. In addition, the reward is not net positive for the [fisherman](https://arxiv.org/abs/1809.09044) who forced the release of data by challenging thus preventing money pump vulnerability while still making challenging affordable to altruistic fishermen and users who desire to pay -to guarrantee data availability on L1. +to guarantee data availability on L1. Lastly, if needed a `resolver_refund_factor` can be dialed up such as `resolver_refund_factor * resolving_cost` is refunded to the resolver (where `0 <= refund_factor <= 1`) while the rest of the bond is burnt. diff --git a/specs/root.md b/specs/root.md index 3972aa108..150e823fb 100644 --- a/specs/root.md +++ b/specs/root.md @@ -48,7 +48,7 @@ Specifications of new features in active development. Our aim is to design a protocol specification that is: - **Fast:** When users send transactions, they get reliable confirmations with low-latency. - For example when swapping on Uniswap you should see that your transaction succeed in less than 2 + For example when swapping on Uniswap you should see that your transaction succeeds in less than 2 seconds. - **Scalable:** It should be possible to handle an enormous number of transactions per second which will enable the system to charge low fees.