Update kip-162

KIPs/kip-162.md

@@ -51,8 +51,9 @@ def EffectiveGasPrice(header: Header, tx: Transaction):
           maxFeePerGas = tx.maxFeePerGas
           maxPriorityFeePerGas = tx.maxPriorityFeePerGas
       else:
+          # makes EffectiveGasPrice() = tx.gasPrice
           maxFeePerGas = tx.gasPrice
-          maxPriorityFeePerGas = # tx.gasPrice or 0; TBU
+          maxPriorityFeePerGas = tx.gasPrice
       return min(header.baseFeePerGas + maxPriorityFeePerGas, maxFeePerGas)
 
     elif header.number >= MAGMA_FORK_BLOCK_NUMBER:
@@ -75,7 +76,6 @@ def EffectivePriorityFeePerGas(header: Header, tx: Transaction):
         return 0
 ```
 
-
 ### KIP-82 reward scheme
 
 The [KIP-82](https://github.com/klaytn/kips/blob/main/KIPs/kip-82.md) reward scheme is slightly modified. The `get_total_fee` now accounts for effective gas price. Otherwise remains the same.
@@ -182,54 +182,16 @@ The Ethereum's `eth_feeHistory` calculates gasUsedRatio as `block.gasUsed/blockG
 
 In Ethereum, block gas limit is 30,000,000 and the base fee starts to rise when the block gas used exceeds 15,000,000 (`block.gasLimit / ELASTICITY_MULTIPLIER`). Similartly, the Klaytn's initial KIP-71 parameters stipulates that the block gas used is only accounted until 60,000,000 for the purpose of base fee calculation (`MAX_BLOCK_GAS_USED_FOR_BASE_FEE`), and the base fee starts to rise when the block gas used exceeds 30,000,000 (`GAS_TARGET`).
 
-## Effective gas price of other 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.
-
-Recall the effective gas price definition:
-
-```py
-def EffectiveGasPrice(header: Header, tx: Transaction):
-    if header.number >= DRAGON_FORK_BLOCK_NUMBER:
-        if tx.type == 2:
-            maxFeePerGas = tx.maxFeePerGas
-            maxPriorityFeePerGas = tx.maxPriorityFeePerGas
-        else:
-            maxFeePerGas = tx.gasPrice
-            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`. 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.
+# Backward compatibility
 
-- **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.
+## Continued use of other transaction types
 
-Effective price example. Prices are in 'ston' (1e-9).
+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. For those transaction types, their effective gas price is considered to equal to the `gasPrice`. The senders pay 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) and the same as pre-1559 auction market. In this manner, those transaction types pay a nonzero priority fee.
 
 | baseFeePerGas | transaction | effectiveGasPrice | effectivePriorityFeePerGas |
 |-|-|-|-|
-| 25 | {type: 0, gasPrice: 51}, **Option A** | 51 | 26 |
+| 25 | {type: 0, gasPrice: 26} | 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
-
-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.
 
 ## EVM opcodes