feat(specs): language changes

specs/README.md

@@ -27,9 +27,10 @@ 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
   seconds.
-- **Scalable:** It should be possible to handle an enormous number of transactions per second which
-  will enable us to charge low fees. V1.0 will enable us to scale up to and even past the gas limit
-  on L1. Later iterations will scale much further.
+- **Scalable:** It should be possible to handle an enormous number of transactions 
+  per second which will enable the system to charge low fees.
+  V1.0 will enable Optimism to scale up to and even past the gas limit on L1.
+  Later iterations should scale much further.
 - **Modular:** Our designs will use modularity to reduce complexity and enable parallel
   contributions. Coming up with good conceptual frameworks & composable atoms of software enables us
   to build extremely complex software even when any one person cannot hold that much in their brain.
@@ -41,8 +42,9 @@ Our aim is to design a protocol specification that is:
   our software to avoid creating a system no one wants to use.
 - **Clear and Readable:** The specs we write are written to be read. So tight feedback loop with the
   systems team consuming the spec is also key!
-- **Secure:** This is self-evident. We cannot lose money and in a system where even a bit of
-  downtime can result in loss of funds this means everything we build must be incredibly secure.
-- **Decentralizable:** Everything we build must have a clear path towards decentralization. Today
-  Optimism relies on OptimismPBC to function, but eventually it will be managed by a DAO and even in
-  that decentralized future our system must thrive.
+- **Secure:** This is self-evident.
+  User’s assets are at stake. Every component of the system must be incredibly secure.
+- **Decentralizable:** Optimism must be designed to avail itself of the security and 
+  censorship-resistant guarantees achieved by a decentralized system.
+  Currently centralized components of the system should have a clear path towards decentralization.
+  Already decentralized components of the system should be protected and preserved.

specs/exec-engine.md

@@ -48,8 +48,10 @@ Deposited transactions MUST never be consumed from the transaction pool.
 
 ## Engine API
 
+<!--
 *Note: the [Engine API][l1-api-spec] is in alpha, `v1.0.0-alpha.5`.
 There may be subtle tweaks, beta starts in a few weeks*
+-->
 
 ### `engine_forkchoiceUpdatedV1`
 

specs/introduction.md

@@ -91,9 +91,11 @@ At the heart of the network are users (us!). Users can:
 
 ### Sequencers
 
-The sequencer is the primary block producer. There may be one sequencer **or** many using a consensus protocol. For
-1.0.0, there is just one sequencer.  In general, specifications may use "the sequencer" to be a stand-in term for the
-consensus protocol operated by multiple sequencers.
+The sequencer is the primary block producer.
+There may be one sequencer **or** many using a consensus protocol.
+For 1.0.0, there is just one sequencer (currently operated under the oversight of the Optimism Foundation).
+In general, specifications may use "the sequencer" to be a stand-in term 
+for the consensus protocol operated by multiple sequencers.
 
 The sequencer:
 
@@ -125,21 +127,21 @@ provide context when diving into any particular component specification.
 
 ### Depositing and Sending Transactions
 
-Users will often begin their L2 journey by depositing ETH from L1. Once they have ETH to pay fees, they'll start
-sending transactions on L2. The following diagram demonstrates this interaction and all key Optimism
-components which are utilized:
+Users will often begin their L2 journey by depositing ETH from L1.
+Once they have ETH to pay fees, they'll start sending transactions on L2.
+The following diagram demonstrates this interaction and all key Optimism components which are or should be utilized:
 
 ![Diagram of Depositing and Sending Transactions](./assets/sequencer-handling-deposits-and-transactions.svg)
 
 Links to components mentioned in this diagram:
 
-- Batch Inbox (WIP)
+<!-- - Batch Inbox (WIP) -->
 - [Rollup Node](./rollup-node.md)
 - [Execution Engine](./exec-engine.md)
-- Sequencer Batch Submitter (WIP)
+<!-- - Sequencer Batch Submitter (WIP) -->
 - [L2 Output Oracle](./proposals.md#l2-output-oracle-smart-contract)
 - [L2 Output Submitter](./proposals.md#proposing-l2-output-commitments)
-- Fault Proof VM (WIP)
+<!-- - Fault Proof VM (WIP) -->
 
 ### Withdrawing
 

specs/predeploys.md

@@ -108,12 +108,11 @@ permissionlessly removed from the L2 supply by calling the `burn()` function.
 
 Address: `0x4200000000000000000000000000000000000002`
 
-The `DeployerWhitelist` is a predeploy that was used to provide additional
-safety during the initial phases of Optimism. It is owned by the
-Optimism foundation and defines the accounts that are allowed to deploy contracts to the
-network.
+The `DeployerWhitelist` is a predeploy that was used to provide additional safety 
+during the initial phases of Optimism.
+It previously defined the accounts that are allowed to deploy contracts to the network.
 
-Arbitrary contract deployment has been enabled and it is not possible to turn
+Arbitrary contract deployment was subsequently enabled and it is not possible to turn
 off. In the legacy system, this contract was hooked into `CREATE` and
 `CREATE2` to ensure that the deployer was allowlisted.
 
@@ -263,9 +262,9 @@ have the ability to upgrade any of the other predeploy contracts.
 
 Address: `0x4200000000000000000000000000000000000011`
 
-The `SequencerFeeVault` accumulates any transaction tips and is the value of
-`block.coinbase`. When enough fees accumulate in this account, they can be
-permissionlessly withdrawn to an immutable L1 address.
+The `SequencerFeeVault` accumulates any transaction priority fee and is the value of
+`block.coinbase`.
+When enough fees accumulate in this account, they can be withdrawn to an immutable L1 address.
 
 To change the L1 address that fees are withdrawn to, the contract must be
 upgraded by changing its proxy's implementation key.
@@ -300,7 +299,7 @@ Address: `0x4200000000000000000000000000000000000019`
 
 The `BaseFeeVault` predeploy receives the basefees on L2. The basefee is not
 burnt on L2 like it is on L1. Once the contract has received a certain amount
-of fees, the ETH can be permissionlessly withdrawn to an immutable address on
+of fees, the ETH can be withdrawn to an immutable address on
 L1.
 
 ## L1FeeVault
@@ -311,4 +310,4 @@ Address: `0x420000000000000000000000000000000000001a`
 
 The `L1FeeVault` predeploy receives the L1 portion of the transaction fees.
 Once the contract has received a certain amount of fees, the ETH can be
-permissionlessly withdrawn to an immutable address on L1.
+withdrawn to an immutable address on L1.

specs/proposals.md

@@ -26,7 +26,8 @@ proving any piece of data captured by the outputs.
 Proposers submit the output roots to L1 and can be contested with a fault proof,
 with a bond at stake if the proof is wrong.
 
-_Note_: Although fault proof construction and verification [is implemented in Cannon][cannon],
+_Note_: Fault proofs on Optimism are not fully specified at this time. Although fault proof construction and verification 
+[is implemented in Cannon][cannon],
 the fault proof game specification and integration of a output-root challenger into the [rollup-node][g-rollup-node]
 are part of later specification milestones.
 
@@ -50,7 +51,7 @@ The proposer may also delete multiple output roots by calling the `deleteL2Outpu
 index of the first output to delete, this will also delete all subsequent outputs.
 
 > **Note regarding future work:** In the initial version of the system, the proposer will be the same entity as the
-> sequencer, which is a trusted role. In the future proposers will need to submit a bond in order to post L2 output
+> sequencer, which is a trusted role. In the future proposers may need to submit a bond in order to post L2 output
 > roots, and some or all of this bond may be taken in the event of a faulty proposal.
 
 ## L2 Output Commitment Construction

specs/rollup-node.md

@@ -55,8 +55,8 @@ For a complete specification of the L2 block derivation, refer to the [L2 block
 
 ## L2 Output RPC method
 
-The Rollup node has its own RPC method, `optimism_outputAtBlock` which returns the
-a 32 byte hash corresponding to the [L2 output root](./proposals.md#l2-output-commitment-construction).
+The Rollup node has its own RPC method, `optimism_outputAtBlock` which returns a 32 
+byte hash corresponding to the [L2 output root](./proposals.md#l2-output-commitment-construction).
 
 [SSZ]: https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md