Update kip-162

KIPs/kip-162.md

@@ -1,8 +1,9 @@
 ---
-kip: 999
+kip: 162
 title: Priority Fee Mechanism
 author: Ollie (@blukat29), Sawyer (@2dvorak), Aidan (@aidan-kwon)
 status: Draft
+discussions-to: https://github.com/klaytn/kips/issues/161
 type: Standard Track
 category : Core
 created: 2024-03-20
@@ -28,27 +29,51 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
 
 ### Effective gas price and effective priority fee per gas
 
+The effective gas price and effective priorirty fee per gas of a transaction at given block are calculated as follows. The effective gas price is the actual price of gas paid by the sender.
+
 ```py
-def EffectiveGasPrice(block: Block, tx: Transaction):
-    if tx.type == 2:
+def EffectiveGasPrice(header: Header, tx: Transaction):
+    if tx.type == 2:  # EthereumDynamicFee type
         maxPriorityFeePerGas = tx.maxPriorityFeePerGas
         maxFeePerGas = tx.maxFeePerGas
     else:
         maxPriorityFeePerGas = tx.gasPrice
         maxFeePerGas = tx.gasPrice
 
-    return min(block.baseFeePerGas + maxPriorityFeePerGas, maxFeePerGas)
+    return min(header.baseFeePerGas + maxPriorityFeePerGas, maxFeePerGas)
 
-def EffectivePriorityFeePerGas(block: Block, tx: Transaction):
-    effectiveGasPrice = EffectiveGasPrice(block, tx)
-    return effectiveGasPrice - block.baseFeePerGas
+def EffectivePriorityFeePerGas(header: Header, tx: Transaction):
+    effectiveGasPrice = EffectiveGasPrice(header, tx)
+    return effectiveGasPrice - header.baseFeePerGas
 ```
 
-### Transaction ordering
+### KIP-82 reward scheme
 
-Transactions are ordered by (1) descending effective gas price and (2) ascending arrival timestamp.
+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.
 
-TBU
+```py
+def get_total_fee(header, txs, receipts):
+    if header.number >= DRAGON_BLOCK_NUMBER:
+        totalFee = 0
+        for i in range(len(txs)):
+            totalFee += EffectiveGasPrice(header, txs[i]) * receipts[i].gasUsed
+        return totalFee
+    elif header.number >= MAGMA_BLOCK_NUMBER:
+        return header.GasUsed * header.BaseFee
+    else:
+        return header.GasUsed * config.UnitPrice
+```
+
+### EVM opcodes
+
+- The `GASPRICE (0x3a)` opcode returns the effective gas price of the currently executing transaction.
+- The `BASEFEE (0x48)` opcode remains the same. Returns the base fee per gas of the currently executing block.
+
+## Transaction ordering
+
+Transaction ordering depends on client implementation as the ordering is not checked by block validators. However, under the KIP-82 reward scheme, a proposer should prioritize high priority fee transactions for maximum proposer reward.
+
+Block proposers are recommended to order transactions with descending effective gas price, and the same effective gas price are sorted by transaction arrival time. This discourages the transaction spamming where a sender sends many transactions hoping that at least one is included in the block. Instead, the sender would pay a higher priority fee to ensure the transaction be included in the block.
 
 ## JSON-RPC API
 
@@ -121,11 +146,19 @@ Returns historical gas information for a range of blocks.
 
 # Rationale
 
-TBU
+## A KIP-71 parameter is used in place of block gas limit
+
+The Ethereum's `eth_feeHistory` calculates gasUsedRatio as `block.gasUsed/blockGasLimit`. But Klaytn does not have hard limit of block gas. Instead, Klaytn's MAX_BLOCK_GAS_USED_FOR_BASE_FEE is analogous to Ethereum's block gas limit.
+
+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, in the Klaytn's initial KIP-71 parameters the block gas used is only accounted until 60,000,000 (`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`).
 
 # Backward compatibility
 
-TBU
+## Other transaction types
+
+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. The transaction's `gasPrice` will be fully paid because `effectiveGasPrice = min(baseFeePerGas + gasPrice, gasPrice) = gasPrice`.
+
+These 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`. 
 
 # References