Update kip-162

KIPs/kip-162.md

@@ -52,7 +52,7 @@ def EffectiveGasPrice(header: Header, tx: Transaction):
           maxPriorityFeePerGas = tx.maxPriorityFeePerGas
       else:
           maxFeePerGas = tx.gasPrice
-          maxPriorityFeePerGas = # 0 or tx.gasPrice; TBU
+          maxPriorityFeePerGas = # tx.gasPrice or 0; TBU
       return min(header.baseFeePerGas + maxPriorityFeePerGas, maxFeePerGas)
 
     elif header.number >= MAGMA_FORK_BLOCK_NUMBER:
@@ -184,7 +184,7 @@ In Ethereum, block gas limit is 30,000,000 and the base fee starts to rise when
 
 ## Effective gas price of other transaction types
 
-The "other transaction types" here refers to the ones with `gasPrice` field which includes Type 0 (Legacy), Type 1 (EIP-2930 AccessList) as well as all Types 8 or higher (Klaytn-specific transaction types).
+The "other transaction types" here refers to the ones with `gasPrice` field. They are Legacy (type 0) transactions, EIP-2930 AccessList (type 1) transactions, and Klaytn transaction types (types 8+).
 
 To incorporate those transaction types to the new transaction ordering based on effective gas prices, we must define the effective gas price for them even if those transactions do not specify a `maxPriorityFeePerGas`. There could be Options A and B.
 
@@ -198,41 +198,39 @@ def EffectiveGasPrice(header: Header, tx: Transaction):
             maxPriorityFeePerGas = tx.maxPriorityFeePerGas
         else:
             maxFeePerGas = tx.gasPrice
-            maxPriorityFeePerGas = tx.gasPrice              # Option A
-            maxPriorityFeePerGas = 0                        # Option B
-            maxPriorityFeePerGas = tx.maxPriorityFeePerGas  # Option C (only for Klaytn tx types)
+            maxPriorityFeePerGas = tx.gasPrice    # Option A
+            maxPriorityFeePerGas = 0              # Option B
         return min(header.baseFeePerGas + maxPriorityFeePerGas, maxFeePerGas)
 ```
-- **Option A**. Effective gas price is equal to `gasPrice`. The sender pays the full price as declared in the `gasPrice`. The transactions are reliably included in the blocks because this nonzero priority fee will make the transactions high priority. A side effect is that the senders either pay larger price than before, or has to precisely predict the base fee in order to save the gas fee. This policy is identical to [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md).
+- **Option A**. Effective gas price is equal to `gasPrice`. The sender pays the full price as declared in the `gasPrice`. This policy is identical to [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md).
+  - The transactions are reliably included in the blocks because this nonzero priority fee will make the transactions high priority.
+  - Since the `gasPrice` is usually higher than the recommended priority fee, these transactions are usually positioned on top of the blocks, before the type-2 transactions with lower priority fees.
+  - The senders either pay larger price than before, or has to precisely predict the base fee in order to save the gas fee. Client implementations may assist the prediction through its `eth_gasPrice` API.
 
-- **Option B**. Effective gas price is equal to `baseFeePerGas`. The sender pays the base fee regardless of the `gasPrice` field. The sender gets to pay what she had been paying today. The gas fee is still highly predictable. A side effect is that transactions might be delayed in the event of network congestion because the blocks will be filled with transactions paying nonzero priority fee.
-
-- **Option C (only applicable to Klaytn tx types)**. Add the transaction field `maxPriorityFeePerGas`. Either add an optional field to the existing type or define new tx types. The details are orthogonal to the current proposal.
+- **Option B**. Effective gas price is equal to `baseFeePerGas`, the priority fee is considered zero. The sender pays the base fee regardless of the `gasPrice` field. This policy seamlessly continues on the [KIP-71](https://github.com/klaytn/kips/blob/main/KIPs/kip-71.md).
+  - The sender gets to pay what she had been paying today. The gas fee is still highly predictable.
+  - Transactions are placed at the bottom of the blocks, after the type-2 transactions.
+  - Transactions might be delayed in the event of network congestion because the blocks will be filled with transactions paying nonzero priority fee.
 
 Effective price example. Prices are in 'ston' (1e-9).
 
 | baseFeePerGas | transaction | effectiveGasPrice | effectivePriorityFeePerGas |
 |-|-|-|-|
 | 25 | {type: 0, gasPrice: 51}, **Option A** | 51 | 26 |
-| 25 | {type: 0, gasPrice: 51}, **Option B** | 25 | 0 |
-| 25 | {type: 8, gasPrice: 51, maxPriorityFeePerGas: 1}, **Option C** | 26 | 1 |
 | 25 | {type: 2, maxFeePerGas: 51, maxPriorityFeePerGas: 1} | 26 | 1 |
+| 25 | {type: 0, gasPrice: 51}, **Option B** | 25 | 0 |
 
 
 # Backward compatibility
 
 ## Continued use of other transaction types
 
-Depends on which of the options A,B,C we follow, but either way all transaction types should work.
-
-Legacy (type 0) transactions, EIP-2920 AccessList (type 1) transactions, and Klaytn transaction types (types 8+) will work and be included in blocks. Those transactions have `gasPrice` field but no `maxFeePerGas` nor `maxPriorityFeePerGas` fields.
+Legacy (type 0) transactions, EIP-2930 AccessList (type 1) transactions, and Klaytn transaction types (types 8+) will work and be included in blocks. Those transactions have `gasPrice` field but no `maxFeePerGas` nor `maxPriorityFeePerGas` fields.
 
 - Option A: Those transactions may experience sudden increase in gas costs because previously they only paid `baseFeePerGas` but now they have to pay `gasPrice`. To reduce the impact, `eth_gasPrice` implementations may return a number slightly higher than the `baseFeePerGas`.
 
 - Option B: Those transactions may experience delay in the event of congested network. However, since Klaytn has large block spaces and frequent block time, such a delay should be an exceptional event.
 
-- Option C: SDKs and apps using the old format or existing type may experience delay because those transactions are considered zero priority fee. The ecosystem may upgrade to utilize the priority fee feature in Klaytn tx types.
-
 ## EVM opcodes
 
 The `GASPRICE` (0x3a) opcode is backwards compatible because it had been correctly returning the effective gas price before `DRAGON_FORK_BLOCK_NUMBER`. The `BASEFEE` (0x48) opcode remains the same; returns the base fee per gas of the currently executing block.