PIP-0027: final edits, spelling/grammar fixes.

PIP/PIP-0029.md

@@ -19,64 +19,64 @@ PascalCoin currently allows users to own accounts (PASA) and send/receive operat
 
 Operations in PascalCoin mutate account states in various ways (e.g. balance, name, key, data, etc) and follow strict consensus rules enforced by all nodes. Every time an account state is changed, it's prior state is lost from the SafeBox. Much in the same way that an individuals bank account history of transactions is important and useful, the history of PASA states (and transitions) is likewise fundamentally important and useful. However, since PascalCoin nodes only need/keep the last 100 blocks, the account history after 100 blocks is essentially lost (not currently the case, but expected in a global adoption scenario).
 
-In order to know more than 100 blocks of history, the user must track these operations manually, or request them from an archival node. A dillema arises here in that without the blockchain, there is no way for the user to determine if the history is forged, corrupt, invalid or valid. The user is left with a trust-model. In a trust-free scenario, such a history is essentially useless since no decision can be made by any decentralised party as the history has no intrinsic security. Only the blockchain can validate the history, and this is impractical in global adoption scenario where the full blockchain is beyond storage of an ordinary node.
+In order to know more than 100 blocks of history, the user must track these operations manually, or request them from an archival node. A dilemma arises here in that without the blockchain, there is no way for the user to determine if the history is forged, corrupt, invalid or valid. The user is left with a trust-model. In a trust-free scenario, such a history is essentially useless since no decision can be made by any decentralized party as the history has no intrinsic security. Only the blockchain can validate the history, and this is impractical in global adoption scenario where the full blockchain is beyond storage of an ordinary node.
 
-This PIP proposes a small upgrade to the account struture and all operation mutation rules so that the resulting account history is made cryptographically verifiable and intrinsically secure. With this feature, a user would only require the current SafeBox to verify an accounts history, **not** the blockchain. This is achieved by including a hash-based link between PASA state-transitions, much in the same way to how blocks link in a blockchain.
+This PIP proposes a small upgrade to the account structure and all operation mutation rules so that the resulting account history is made cryptographically verifiable and intrinsically secure. With this feature, a user would only require the current SafeBox to verify an accounts history, **not** the blockchain. This is achieved by including a hash-based link between PASA state-transitions, much in the same way to how blocks link in a blockchain.
 This link, called the Account Seal (or PASA Seal) is simply a hash commitment to the accounts prior state and the mutating operation which led to the current state. This seal is a 20-byte field within the Account itself.
 
 Since each state links to the prior state, and that prior state links to it's prior state, an Account Seal commits to the entire preceding history of that account. Therefore, a user possessing an account history can easily validate that the history is valid by re-calculating the seals in chronological order ensuring the final seal matches the current SafeBox seal. 
 
 This opens the door to the following use-cases:
 
-### PASA as a Decentralised Consensus-Ledger
+### PASA as a Decentralized Consensus-Ledger
 
-Since a PASA history of state-transitions, and the set of operations which created that history, can be independently verified by an individual node, the history can be re-purposed by users as a decentralised-consensus ledger.
+Since a PASA history of state-transitions, and the set of operations which created that history, can be independently verified by an individual node, the history can be re-purposed by users as a decentralized-consensus ledger.
 
-Under this interpretation, a PASA history is a ledger of chronologically ordered statements made by parties to a contract that cannot be forged or altered by those parties and which is independently verified by an arbitrating party, should a dispute arise.  No trusted 3rd parties or notaries are required whatsoever.
+Under this interpretation, a PASA history becomes a ledger of chronologically ordered statements made by parties of a contract which cannot be forged, altered or tampered with by those parties. Should a dispute arise between the parties, an arbitrating party can independently retreieve the ledger and cryptographically verify it. No trusted 3rd parties or notaries are required whatsoever.
 
 Such a ledger lends itself to many use-cases including:
-- Proof-of-Audit solutions between contractual parties 
-- Supply-chain notarisation solutions 
+- Proof-of-Audit solutions between adversarial parties (i.e. consortiums of competitors, or enforcing treaties between adversarial governments)
+- Supply-chain notarization solutions 
 - Version-control system for documentation and manufacturing
-- Any legal-contract execution workflow
+- Any legal-contract execution work-flow
 
 ### PASA as an Embedded-Chain
 
 Since each account state links to it's previous state similar to how blocks link in a blockchain, accounts can be used to secure "embedded side-chains" (or **embedded-chains** for short). 
 
-Under this interpretation, the chain of account states (or a PASA-Chain) is used to embed a blockchain that is then consumed by a layer-2 network to determine a decentralized consensus for a layer-2 application. Since the ledger of messages is reliable, layer-2 nodes need only process the messages that comply with layer-2 consensus rules and ignore the ones that don't. All layer-2 nodes will always remain in consensus with each other, yet be independent of each other, since they only depend on the validity of the track of mesages stored in the PASA-Chain.
+Under this interpretation, the chain of account states (or a PASA-Chain) is used to embed a blockchain that is then consumed by participants of layer-2 network to determine a common consensus between themselves for a layer-2 application, in a trust-less and decentralised manner. Since the ledger of messages is reliable, layer-2 nodes need only process the messages that comply with layer-2 consensus rules and ignore the ones that don't. All layer-2 nodes will always remain in consensus with each other, yet be independent of each other, since they only depend on the validity of the track of messages stored in the PASA-Chain.
 
-In essence, PascalCoin's Proof-of-Work is enough to secure millions of blockchains (1 for each account) at no extra financial or computational cost. An astonishing result, and the first of it's kind for any cryptocurrency. 
+With this change, the SafeBox becomes a **Blockchain Container** capable of securing millions of blockchains (1 for each account) where one Proof-of-Work secures them all.  An astonishing result, and the first of it's kind for any cryptocurrency. 
 
 See [Embedded Chain Specification](#embedded-chain-specification) for more details.
 
-### PASA as a Decentralised Finite-State-Machine
+### PASA as a Decentralized Finite-State-Machine
 
-With the introduction of [DATA operations][4] in V4, a historical sequence of DATA operations can serve as a state-transition audit-log of any programmatic workflow.
+With the introduction of [DATA operations][4] in V4, a historical sequence of DATA operations can serve as a state-transition audit-log of any programmatic work-flow.
 
 For example:
 - **Decentralized Voting**: Account history used to tally votes such that decentralized consensus is always achieved.
-- **Tokens**: Account history used as financial ledger entries of a token issuance, token burns & token transfers. Any protocol-complying wallet can tally all token balances from the history independently of any other wallet. Network always arrives to uniform consensus yet totally decentralised.
-- **Decentralized Poker**: Account history serves as sequence of player actions in a poker game, where consensus on the winners/losers is uniformly derived in a total decentralised manner.
+- **Tokens**: Account history used as financial ledger entries of a token issuance, token burns & token transfers. Any protocol-complying wallet can tally all token balances from the history independently of any other wallet. Network always arrives to uniform consensus yet totally decentralized.
+- **Decentralized Poker**: Account history serves as sequence of player actions in a poker game, where consensus on the winners/losers is uniformly derived in a total decentralized manner.
 - **Decentralized Exchange**: Account history serves as a ledger of user deposits/withdrawals on a DEX, used by Layer-2 network to make decisions on other blockchains.
 
 From an abstracted perspective, under this interpretation, a PASA history can serve as a state-transition log for **any** finite-state-machine (FSM), where the "current state" of the FSM can be determined by any party, independently, securely with uniform network-wide consensus. 
 
-Since almost anything and everything can be modelled as an FSM, in combination with PascalCoin's next-generation scaling and throughput capabilities, this feature serves as a foundation for next-generation Layer-2 smart-contracts and dapps (that scale).
+Since almost anything and everything can be modeled as an FSM, in combination with PascalCoin's next-generation scaling and throughput capabilities, this feature serves as a foundation for next-generation Layer-2 smart-contracts and dapps (that scale).
 
 ### Light-wallet Full Account History
 
-In addition to the above beneits, more mundane benefit includes ability for mobile-wallets and light-clients to:
+In addition to the above benefits, more mundane benefit includes ability for mobile-wallets and light-clients to:
 - Retrieve account history from any untrusted peer and independently verify correctness.
-- Not require any blocks whatsoever, only the SafeBox and PASA history for accounts they carea about.
+- Not require any blocks whatsoever, only the SafeBox and PASA history for accounts they care about.
 - Dramatical UX improvement in a global-adoption scenario.
 
 
 ### Long-term solution for "State-Attack"
 
-As outlined in the WhitePaper, SafeBox introduces a new attack vector called State-Attack which enables an attacker to forge a SafeBox with invalid account data "before last 100 blocks". Although this attack requires tremendous hashpower and is not feasable with current network (due to archival and long-history nodes that can easily thwart this attack), it could pose an issue in a global adoption scenario (even if for causing short-lived/local SafeBox disruptions).
+As outlined in the WhitePaper, SafeBox introduces a new attack vector called State-Attack which enables an attacker to forge a SafeBox with invalid account data "before last 100 blocks". Although this attack requires tremendous hash-power and is not feasible with current network (due to archival and long-history nodes that can easily thwart this attack), it could pose an issue in a global adoption scenario (even if for causing short-lived/local SafeBox disruptions).
 
-With this PIP, a PASA history could be used to detect forgeries and thwart a State-Attack. Current block/SafeBox validation workflow would require some alternation, but conceivably, Account Seals validation can compliment existing Proof-of-Work validation when deciding on valid SafeBox.
+With this PIP, a PASA history could be used to detect forgeries and thwart a State-Attack. Current block/SafeBox validation work-flow would require some alternation, but conceivably, Account Seals validation can compliment existing Proof-of-Work validation when deciding on valid SafeBox.
 
 Since this is not a concern now, nor will it be until far into the future, the investigation and development of this feature is relegated to a future PIP.
 
@@ -139,7 +139,7 @@ In order to prove an prior account state is valid, the user needs a copy of that
       return false;
    end
 
-   function IsValiProofChain( Proof : TAccountProof ) : Boolean;
+   function IsValidProofChain( Proof : TAccountProof ) : Boolean;
    begin
       // validate in reverse
      for i := Length(proof) - 1 downto 1 do begin
@@ -149,14 +149,14 @@ In order to prove an prior account state is valid, the user needs a copy of that
      return true;    
    end;
    
-   function CalculateSeal(proofLink : TStateProof ) : TBytes[32]
+   function CalculateSeal( proofLink : TStateProof ) : TBytes[32]
    begin
       return RIPEMD160 ( SHA2_256 ( Array.Join( SerializeAccount ( proofLink.AccountState ) , proofLink.OPID  ) ) );
    end
 
    function SerializeAccount(account : TAccount) : TBytes;
    begin 
-     // ... as per network protocol
+     return ...; // as per network protocol
    end
 ```
 
@@ -182,9 +182,13 @@ Some differences between embedded-chains vs traditional blockchain are:
 
 #### Spam Attack 
 
-Embedded chains are susceptible to "spam-attack" scenario where a malicious actor attempts to flood the embedded-chain with invalid blocks (at cost). This attack would simply comprise of sending many operations to the target account which are not valid layer-2 embedded blocks, but which alter the account state. This is not a big issue if layer-2 nodes have a mechanism to rapidly detect and reject these invalid opeations/embedded blocks. This is a concern for layer-2 protocol designers but specifically, but general solutions which can be employed include:
-1. Use of data operations for declare embedded blocks, instead of other operations. The type field can be used to filter accidental/malformed transactions and for rapid block number sequencing.
-2. For malicous spam operations, merkle-proofs can be employed to detect and reject large invalid embdded-blocks (similar to "big block" scenario for traditional UTXO blockchains).
+Embedded chains are susceptible to "spam-attack" scenario where a malicious actor attempts to flood the embedded-chain with invalid blocks (at cost). This attack would simply comprise of sending many operations to the target account that are not "valid layer-2 embedded blocks", but which alter the account state nonetheless. This is not a major concern if layer-2 nodes have a mechanism to rapidly detect and reject such invalid layer-1 operations / layer-2 embedded blocks. Although this is a concern for layer-2 protocol designers specifically, general solution approaches include:
+1. Use of data operations for declaring embedded blocks, allowing rapid filtering of other unrelated operations/transactions.
+2. Use of ```Type``` and ```Sequence``` fields in the Data operation for rapid filtering and validation. 
+
+Both (1) and (2) basically solves for unintentional/accidental spam scenario. For malicious spam-attacks,
+
+3. Bootstrap layer-2 block content with self-verifying merkle-proofs that can be used for on-the-fly error detection and block rejection of (large) invalid blocks. Such approaches are also applicable to "big block attack" scenarios in traditional UTXO blockchains.
 
 ## Rationale