diff --git a/KIPs/kip-162.md b/KIPs/kip-162.md index b8c56bc8..083ce6d3 100644 --- a/KIPs/kip-162.md +++ b/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. + ```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` is 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 60,000,000 and the base fee starts to rise when the block gas used exceeds 30,000,000 (`block gas limit / 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