[x] Use grammarly to check for grammar and spelling errors. I found a few in the document.
[x] Follow https://www.rfc-editor.org/rfc/rfc2119 to use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the document.
[x] Prefer the term "token" to "money" in the document.
[x] In section 1, the use of the word "yearns" is awkward.
[ ] In section 1, it is disingenuous to say that Casper needs additional transaction throughput at this time, given the low usage of the network.
Please suggest an alternative motivation
[x] powerful is consistently misspelled as powerfull
[ ] Naked [tag: FXX] expressions in the text are unconventional
Tags are not unconventional. If you refer to the format, I need it to be compatible with tagref
[x] In section 2.2.1, I suggest changing "Deposit money into L2 system" to read "Deposit Tokens Into the L2 System". In general, CSPR is not a money system, it is a token system.
[x] In section 2.2.2, "Deposit money from L2 system" should read "Deposit Tokens From the L2 System". In general, CSPR is not a money system, it is a token system.
[ ] In section 2.2.4, "Anyone should be able to query any L2 account balances at any given time through a CLI. In particular, users can also query their personal L2 account balance." should read "Users should be able to query their personal L2 account balance at any given time through a CLI. In particular, users should be able to query their personal L2 account balance."
Balances should be publicly available, therefore I would argue that the phrasing is good the way it is.
[ ] The beginning of section three has a spurious comma. "Based on the product overview given in the previous section, this section aims to describe testable, functional requirements the system needs to meet." should read "Based on the product overview given in the previous section, this section aims to describe testable functional requirements the system needs to meet."
Grammarly says no.
[x] In section F00-02, "A user depositing any valid amount to its" should read "A user depositing any valid amount to their"
[x] In section F00-03, "A user depositing any valid amount with a proper signature to another users account should fail" should read "A user depositing any valid amount with a proper signature to another user's account should fail"
[x] In section F00-04, it should read more succinctly as "Deposit requests cannot be replayed"
[x] In section 3.1.2, everywhere "users L2 account balance" should read "user's L2 account balance"
[x] In section 3.1.2, "Withdrawing an amount of tokens, where users L2 account balance >= tokens > MIN_AMOUNT should be accounted correctly" should read "Withdrawing an amount of tokens, where user's L2 account balance >= tokens > MIN_AMOUNT, should be accounted correctly"
[x] In section 3.1.6, With respect to "These are qualitative requirements, such as “it should be fast” and could be benchmarked.", it would be better to provide times and avoid the use of the word fast altogether.
[ ] In Section 4, the diagram has the prover running batchVerify, which doesn't make any sense. The prover should be running batchProve only.
[x] In 4.1.2, there's a strange forward tick in this sentence: "State transitions of the account balances are verified and executed on-chain, requiring the node to create respective transactions on L1 using the L1′s software development kit (SDK)." Use an apostrophe instead of a forward tick.
It is an apostrophe in the source. In the PDF it looks weird though
[ ] In 4.1.3, this violates separation of concerns: "The Prover is a separate service that exposes a batchProve and a batchVerify endpoint, which will mainly be utilized by the L2 node (Section 4.1.2) to prove batches of transfers". The prover should not be exposing a batchVerify endpoint. The prover should only be exposing a batchProve endpoint. The node itself should implement a batchVerify procedure.
[x] In section 4.1.5, "The important thing is that the state update only happens if the updated state was verified successfully beforehand." should read "State update only happens if the updated state was verified successfully beforehand."
[x] Section 4 starts with a sentence fragment. "To give the reader an idea of what a system defined in the previous sections might look like. This section proposes a possible architecture." should read "To give the reader an idea of what a system defined in the previous sections might look like, this section proposes a possible architecture."
[x] In section 4.2.1., why is get_balance snake case but getTransfer camel case? Similarly for submitTransaction. It is recommended to use Rust conventions: https://doc.rust-lang.org/1.0.0/style/style/naming/README.html (ie, Pascal case for types, snake case for field names)
[x] In section 4.2.1, UnsignedINT is sometimes monospace and sometimes not.
[ ] In section 4.2.1, The following has inconsistent capitalization and quotation: "Returns the status of a given transfer: Cancelled, ZKP in progress, batch proof in progress, or “posted on L1 with blockhash X”"
[x] public_nputs should read public_inputs
[x] In section 4.2.1, successfull should read successful
[x] In section 4.2.3, cointains should read contains
[ ] In sections 4.2.2 and 4.2.3, I don't understand how deposit/verify_deposit and withdraw/verify_withdraw are secure. How does the L2 stay in sync with the L1? For instance, if I deposited 100 tokens in the contract, waited for the L2 to update, withdrew my 100 tokens and then "transferred" my tokens before the L2 had updated, wouldn't I be able to double spend my tokens?
[x] In section 4.3, instead of "The following two sequence diagrams show how these individual components interact together to process a user’s deposit and transfer request." say "Figures 2 and 3 show sequence diagrams for processing a user's deposit and transfer requests, respectively."
[x] In section 4.3.1, there's another strange forward tick: "This Deploy needs to be signed by the user before submitting, this is achieved by making use of the L1′s SDK on the client-side."
It's an apostrophe in the source.
[ ] In Figure 2, subscribe(OnDeployProcessed) opens the L2 Node to MITM attacks, as well as dropped events from the event stream. It would be better to have the L2 Node poll for the event with a light client.
Original can be found here https://gist.github.com/xcthulhu/fa6a0823b2a8acd4ab2bebee76088f73