refac: update specs & assets (about Proposer)

specs/batcher.md

@@ -9,7 +9,7 @@
 
 # Batch Submitter
 
-The batch submitter, also referred to as the batcher, is the entity submitting the [L2][g-l2] proposer data to
+The batch submitter, also referred to as the batcher, is the entity submitting the [L2][g-l2] sequencer data to
 [L1][g-l1], to make it available for [validators][g-validator].
 
 [derivation spec]: derivation.md

specs/deposits.md

@@ -10,7 +10,7 @@
 [g-l1]: glossary.md#layer-1-l1
 [g-l1-attr-deposit]: glossary.md#l1-attributes-deposited-transaction
 [g-l2]: glossary.md#layer-2-l2
-[g-proposer]: glossary.md#proposer
+[g-sequencer]: glossary.md#sequencer
 [g-user-deposited]: glossary.md#user-deposited-transaction
 [g-transaction-type]: glossary.md#transaction-type
 [g-validator-reward]: glossary.md#validator-reward
@@ -348,7 +348,7 @@ If the caller is a contract, the address will be transformed by adding
 Solidity `uint160` so the value will overflow. This prevents attacks in which a
 contract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this
 for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
-it possible for users to interact with contracts on L2 even when the [Proposer][g-proposer] is down.
+it possible for users to interact with contracts on L2 even when the [Sequencer][g-sequencer] is down.
 
 #### Deposit Contract Implementation: Kroma Portal
 

specs/differences-from-optimism-bedrock.md

@@ -12,7 +12,6 @@
 **Table of Contents**
 
 - [Nodes](#nodes)
-  - [Sequencer -> Proposer](#sequencer---proposer)
   - [Verifier -> Validator](#verifier---validator)
   - [Compositions](#compositions)
 - [Geth](#geth)
@@ -42,14 +41,6 @@ our decentralization scheme, please refer to
 [this article](https://medium.com/@kroma-network/the-road-to-kromas-decentralization-38f8e46df442)
 on the Kroma blog.
 
-### Sequencer -> Proposer
-
-We use *sequencing* for the inclusion, exclusion and ordering of transactions. Currently, the `sequencer`
-not only performs these functions but also proposes built blocks to Layer 1. In Ethereum PoS, the `proposer` is
-responsible for precisely what the `sequencer` does - building and proposing a block. With this in mind, we have decided
-to rename the actor from `sequencer` to `proposer` and intend to separate the block building capability from the
-proposer in the future. We are comitted to sharing the results of our research with the public.
-
 ### Verifier -> Validator
 
 We utilize the term `validator` to denote a participant who is responsible for submitting the
@@ -68,7 +59,7 @@ The followings are components that are used to run different types of nodes:
 
 | Node        | Components                                                           |
 |-------------|----------------------------------------------------------------------|
-| `Proposer`  | `L2 EL client` + `L2 CL client` + `kroma-batcher`                    |
+| `Sequencer` | `L2 EL client` + `L2 CL client` + `kroma-batcher`                    |
 | `Validator` | `L2 EL client` + `L2 CL client` + `kroma-validator` + `kroma-prover` |
 | `Full node` | `L2 EL client` + `L2 CL client`                                      |
 

specs/exec-engine.md

@@ -9,7 +9,7 @@
 - [Fees](#fees)
   - [Fee Vaults](#fee-vaults)
   - [Transaction Fees](#transaction-fees)
-  - [Proposer Reward (Proposer Reward Vault)](#proposer-reward-proposer-reward-vault)
+  - [L1-Cost fees (L1 Fee Vault)](#l1-cost-fees-l1-fee-vault)
 - [Engine API](#engine-api)
   - [`engine_forkchoiceUpdatedV1`](#engine_forkchoiceupdatedv1)
     - [Extended PayloadAttributesV1](#extended-payloadattributesv1)
@@ -53,7 +53,7 @@ Deposited transactions MUST never be consumed from the transaction pool.
 ## Fees
 
 Sequenced transactions (i.e. not applicable to deposits) are charged with 2 types of fees:
-transaction fees(priority fees + base fees), and proposer reward.
+transaction fees(priority fees + base fees), and L1-cost fees.
 
 ### Fee Vaults
 
@@ -67,7 +67,7 @@ The proxies are backed by vault contract deployments, based on `FeeVault`, to ro
 |------------------------|----------------------------------------------------------------|
 | Validator Reward Vault | [`ValidatorRewardVault`](./predeploys.md#ValidatorRewardVault) |
 | Protocol Vault         | [`ProtocolVault`](./predeploys.md#ProtocolVault)               |
-| Proposer Reward Vault  | [`ProposerRewardVault`](./predeploys.md#ProposerRewardVault)   |
+| L1 Fee Vault           | [`L1FeeVault`](./predeploys.md#L1FeeVault)                     |
 
 ### Transaction Fees
 
@@ -80,11 +80,11 @@ The transaction fee is distributed to two vaults, Validator Reward Vault and Pro
 
 `ValidatorRewardScalar` value is recorded in the [`L1Block`](./predeploys.md#L1block) contract.
 
-### Proposer Reward (Proposer Reward Vault)
+### L1-Cost fees (L1 Fee Vault)
 
 The protocol funds batch-submission of sequenced L2 transactions by charging L2 users an additional fee
 based on the estimated batch-submission costs.
-This fee is charged from the L2 transaction-sender ETH balance, and collected into the Proposer Reward Vault.
+This fee is charged from the L2 transaction-sender ETH balance, and collected into the L1 Fee Vault.
 
 The exact L1 cost function to determine the L1-cost fee component of an L2 transaction is calculated as:
 `(rollupDataGas + l1FeeOverhead) * l1Basefee * l1FeeScalar / 1000000`
@@ -156,7 +156,7 @@ This is equivalent to the `transactions` field in [`ExecutionPayloadV1`][Executi
 
 The `transactions` field is optional:
 
-- If empty or missing: no changes to engine behavior. The proposers will (if enabled) build a block
+- If empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block
   by consuming transactions from the transaction pool.
 - If present and non-empty: the payload MUST be produced starting with this exact list of transactions.
   The [rollup driver][rollup-driver] determines the transaction list based on deterministic L1 inputs.
@@ -197,7 +197,7 @@ However, to not bottleneck on L1 data retrieval speed, the P2P network functiona
 
 - Peer discovery ([Disc v5][discv5])
 - [`eth/66`][eth66]:
-  - Transaction pool (consumed by proposer nodes)
+  - Transaction pool (consumed by sequencer nodes)
   - State sync (happy-path for fast trustless db replication)
   - Historical block header and body retrieval
   - *New blocks are acquired through the consensus layer instead (rollup node)*