From 12b86d00ae643a14746a2c03a30993d036b65520 Mon Sep 17 00:00:00 2001 From: Tao Zhu Date: Tue, 23 May 2023 11:37:47 -0500 Subject: [PATCH 01/15] increase prioritization fee --- proposals/0050-increase-prioritization-fee.md | 91 +++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 proposals/0050-increase-prioritization-fee.md diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md new file mode 100644 index 000000000..204ceb370 --- /dev/null +++ b/proposals/0050-increase-prioritization-fee.md @@ -0,0 +1,91 @@ +--- +simd: 0050 +title: Increase Prioritization Fee +authors: + - Tao Zhu +category: Standard +type: Core +status: Draft +created: 2023-05-22 +feature: #31453 +--- + +## Summary + +Cost of prioritizing should be a meaningful portion of transaction base fee. + +## Motivation + +Prioritization fee is intended to be used sensitively during congestion, +provides advanced users a tool to access particular resources when contented +with a meaningful fee, while other users may opt to delay access to avoid +paying extra fee. When used properly, it helps to reduce network congestion. + +`Prioritization_fee = compute_unit_limit * compute_unit_price`, +where compute_unit_price has unit of microlamport. + +The small unit of compute_unit_price manifests into: +1. Prioritization_fee is proportionally insignificant to base fee; +2. Therefore, some payers set priority even there is no contention, potentially + leaves other users at a disadvantage; +3. Little consideration was given to compute_unit_limit when setting priority; +These are being documented in https://github.com/solana-labs/solana/issues/31755. + +To encourage prioritization fee to be used as intended as congestion control +tool, it propose to regulate `compute_unit_price` by rounding down to its +nearest lamports. The effect is user should set `compute_unit_price` in +increment of 1_000_000 microlamports. Transaction has less then 1_000_000 +`compute_unit_price` will have no priority nor be charged a priority fee. + +## Alternatives Considered + +1. to change `compute_unit_price` unit from microlamports to lamport. This +approach will require a new version of compute_budget instruction that uses +`lamport` as unit, to coexist with existing instruction, later to be deprecated +when users migrate to new instruction. + +## Detailed Design + +- No change to compute_budget instruction APIs; +- No change to how prioritization fee is calculated; +- No change to how banking_stage prioritization works; +- Add feature gated function to round user specified `compute_unit_price` down + to its nearest lamports. +- The rounded `compute_unit_price` will be used by leader in prioritizing, and + used by bank to calculate prioritization fee. + +### Implementation +#31469 + +## Impact + +- To vote transactions, no impact; +- To transactions don't set `compute_unit_price` (which is 90+% of non-vote + transactions) , no impact; +- To transactions set `compute_unit_price`, user need to reevaluate strategy + of when to use priority, and how much. Specifically, + - user might want to set `compute_unit_price` only when block or account + contention increase; + - when setting `compute_unit_price`, it is advised to set in increment of + 1_000_000 microlamports (eg 1 lamport); + - When setting `compute_unit_price`, it is important to also evaluate + value for `compute_unit_limit` to avoid paying too high prioritization fee. + +### Examples + +- 31.27% non-vote transactions in mainnet-beta set `compute_unit_price` when + both block and account CUs are below 75% of limit (eg., not congested). + They are + currently paying insignificant amount of prioritization fee; With this + proposal, the payers of these transaction would have to consider only + paying prioritization fee when truly needed. + +- about 6% non-vote transactions in mainnet-beta that set `compute_unit_price` + but either not setting `compute_unit_limit` or setting it _above_ Max 1.4M. + with this proposal, payers of these transactions would have to consider + setting accurate/reasonable `compute_unit_limit`. + + +## Backwards Compatibility + +No breaking changes. From c83f78bdfbff8cb6f5078d14e0d900fc79914250 Mon Sep 17 00:00:00 2001 From: Tao Zhu Date: Tue, 23 May 2023 17:38:36 -0500 Subject: [PATCH 02/15] fmt --- proposals/0050-increase-prioritization-fee.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index 204ceb370..58d57bfc3 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -25,6 +25,7 @@ paying extra fee. When used properly, it helps to reduce network congestion. where compute_unit_price has unit of microlamport. The small unit of compute_unit_price manifests into: + 1. Prioritization_fee is proportionally insignificant to base fee; 2. Therefore, some payers set priority even there is no contention, potentially leaves other users at a disadvantage; @@ -55,7 +56,8 @@ when users migrate to new instruction. used by bank to calculate prioritization fee. ### Implementation -#31469 + +PoC https://github.com/solana-labs/solana/pull/31469 ## Impact From 2cd22190da2c3bc4d042d8768b3a4caefb141222 Mon Sep 17 00:00:00 2001 From: Tao Zhu Date: Sun, 4 Jun 2023 16:11:32 -0500 Subject: [PATCH 03/15] changed to 1_000 micrlamports as new unit --- proposals/0050-increase-prioritization-fee.md | 27 ++++++++++++------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index 58d57bfc3..e38c20ced 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -28,14 +28,14 @@ The small unit of compute_unit_price manifests into: 1. Prioritization_fee is proportionally insignificant to base fee; 2. Therefore, some payers set priority even there is no contention, potentially - leaves other users at a disadvantage; + distorts local fee market, leaves other users at a disadvantage; 3. Little consideration was given to compute_unit_limit when setting priority; These are being documented in https://github.com/solana-labs/solana/issues/31755. To encourage prioritization fee to be used as intended as congestion control tool, it propose to regulate `compute_unit_price` by rounding down to its -nearest lamports. The effect is user should set `compute_unit_price` in -increment of 1_000_000 microlamports. Transaction has less then 1_000_000 +nearest 1_000 microlamports. The effect is user should set `compute_unit_price` in +increment of 1_000 microlamports. Transaction has less then 1_000 `compute_unit_price` will have no priority nor be charged a priority fee. ## Alternatives Considered @@ -51,7 +51,7 @@ when users migrate to new instruction. - No change to how prioritization fee is calculated; - No change to how banking_stage prioritization works; - Add feature gated function to round user specified `compute_unit_price` down - to its nearest lamports. + to its nearest 1_000 microlamports. - The rounded `compute_unit_price` will be used by leader in prioritizing, and used by bank to calculate prioritization fee. @@ -62,16 +62,25 @@ PoC https://github.com/solana-labs/solana/pull/31469 ## Impact - To vote transactions, no impact; -- To transactions don't set `compute_unit_price` (which is 90+% of non-vote +- To transactions don't set `compute_unit_price` (which is ~32% of non-vote transactions) , no impact; -- To transactions set `compute_unit_price`, user need to reevaluate strategy - of when to use priority, and how much. Specifically, +- To transactions set `compute_unit_price`, user needs to reevaluate strategy + of when to use priority, and how much. Specifically: - user might want to set `compute_unit_price` only when block or account contention increase; + + User can do that by either check RPC endpoint `getRecentPrioritizationFees` + for minimal fee to block or specific accounts when constructing transaction; + + User can also continuously pull RPC endpoint to built up prioritization + fee historical stats locally, then generate adquent prioritization fee + algorithmically when constructing transactions. - when setting `compute_unit_price`, it is advised to set in increment of - 1_000_000 microlamports (eg 1 lamport); + 1_000 microlamports (eg 0.001 lamport); - When setting `compute_unit_price`, it is important to also evaluate - value for `compute_unit_limit` to avoid paying too high prioritization fee. + value for `compute_unit_limit` to avoid paying too high prioritization fee; + especially for ~50% non-vote transactions currently not setting + `compute_unit_limit` at all. ### Examples From 03367f20f860ac17c62ab87cfcbca6d3f2a9f68d Mon Sep 17 00:00:00 2001 From: Tao Zhu Date: Tue, 6 Jun 2023 11:12:55 -0500 Subject: [PATCH 04/15] fmt --- proposals/0050-increase-prioritization-fee.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index e38c20ced..60805eab5 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -34,8 +34,8 @@ These are being documented in https://github.com/solana-labs/solana/issues/31755 To encourage prioritization fee to be used as intended as congestion control tool, it propose to regulate `compute_unit_price` by rounding down to its -nearest 1_000 microlamports. The effect is user should set `compute_unit_price` in -increment of 1_000 microlamports. Transaction has less then 1_000 +nearest 1_000 microlamports. The effect is user should set `compute_unit_price` +in increment of 1_000 microlamports. Transaction has less then 1_000 `compute_unit_price` will have no priority nor be charged a priority fee. ## Alternatives Considered @@ -70,7 +70,8 @@ PoC https://github.com/solana-labs/solana/pull/31469 contention increase; User can do that by either check RPC endpoint `getRecentPrioritizationFees` - for minimal fee to block or specific accounts when constructing transaction; + for minimal fee to land to block or write lock specific accounts when + constructing transaction; User can also continuously pull RPC endpoint to built up prioritization fee historical stats locally, then generate adquent prioritization fee From 6b5b3255ad532d0c99bc8046469abe7a8c8e1cb9 Mon Sep 17 00:00:00 2001 From: Tao Zhu Date: Mon, 12 Jun 2023 16:50:44 -0500 Subject: [PATCH 05/15] updated motivation and alternative --- proposals/0050-increase-prioritization-fee.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index 60805eab5..748035f1e 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -19,7 +19,8 @@ Cost of prioritizing should be a meaningful portion of transaction base fee. Prioritization fee is intended to be used sensitively during congestion, provides advanced users a tool to access particular resources when contented with a meaningful fee, while other users may opt to delay access to avoid -paying extra fee. When used properly, it helps to reduce network congestion. +paying extra fee. When local fee market functions as designed, it provides +economic incentives to reduce congestion. `Prioritization_fee = compute_unit_limit * compute_unit_price`, where compute_unit_price has unit of microlamport. @@ -40,10 +41,13 @@ in increment of 1_000 microlamports. Transaction has less then 1_000 ## Alternatives Considered -1. to change `compute_unit_price` unit from microlamports to lamport. This -approach will require a new version of compute_budget instruction that uses -`lamport` as unit, to coexist with existing instruction, later to be deprecated -when users migrate to new instruction. +1. to change `compute_unit_price` unit from microlamports to milli-lamport. +This approach will require a new version of compute_budget instruction that +uses `milli-lamport` as unit, to coexist with existing instruction, +later to be deprecated when users migrate to new instruction. It requires +significantly more work on rolling out the change. + +Current approach avoid changing API, nor introducing an additional terminology. ## Detailed Design From b4f88e56e00c4cec96d7b18118c3045e4997dec8 Mon Sep 17 00:00:00 2001 From: Tao Zhu Date: Wed, 21 Jun 2023 15:03:00 -0500 Subject: [PATCH 06/15] lint --- proposals/0050-increase-prioritization-fee.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index 748035f1e..f102016b4 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -1,5 +1,5 @@ --- -simd: 0050 +simd: '0050' title: Increase Prioritization Fee authors: - Tao Zhu @@ -49,6 +49,10 @@ significantly more work on rolling out the change. Current approach avoid changing API, nor introducing an additional terminology. +## New Terminology + +None + ## Detailed Design - No change to compute_budget instruction APIs; From c48197873cade6a028c6f4ecb24915c12b6a7d91 Mon Sep 17 00:00:00 2001 From: Tao Zhu Date: Wed, 21 Jun 2023 15:06:03 -0500 Subject: [PATCH 07/15] lint --- proposals/0050-increase-prioritization-fee.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index f102016b4..80620ee7f 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -105,6 +105,9 @@ PoC https://github.com/solana-labs/solana/pull/31469 with this proposal, payers of these transactions would have to consider setting accurate/reasonable `compute_unit_limit`. +## Security Considerations + +None ## Backwards Compatibility From 5817d27b74c388ab6b7f49b7264b246e03e0b5d4 Mon Sep 17 00:00:00 2001 From: Tao Zhu <82401714+taozhu-chicago@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:07:56 -0500 Subject: [PATCH 08/15] Update proposals/0050-increase-prioritization-fee.md Co-authored-by: Andrew Fitzgerald --- proposals/0050-increase-prioritization-fee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index 80620ee7f..24da57f23 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -29,7 +29,7 @@ The small unit of compute_unit_price manifests into: 1. Prioritization_fee is proportionally insignificant to base fee; 2. Therefore, some payers set priority even there is no contention, potentially - distorts local fee market, leaves other users at a disadvantage; + distorting local fee market, and leaving other users at a disadvantage; 3. Little consideration was given to compute_unit_limit when setting priority; These are being documented in https://github.com/solana-labs/solana/issues/31755. From b8185d976ade72c18d5acfa49a5f75329743b986 Mon Sep 17 00:00:00 2001 From: Tao Zhu <82401714+taozhu-chicago@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:08:13 -0500 Subject: [PATCH 09/15] Update proposals/0050-increase-prioritization-fee.md Co-authored-by: Andrew Fitzgerald --- proposals/0050-increase-prioritization-fee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index 24da57f23..f113dc8f5 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -36,7 +36,7 @@ These are being documented in https://github.com/solana-labs/solana/issues/31755 To encourage prioritization fee to be used as intended as congestion control tool, it propose to regulate `compute_unit_price` by rounding down to its nearest 1_000 microlamports. The effect is user should set `compute_unit_price` -in increment of 1_000 microlamports. Transaction has less then 1_000 +in increments of 1_000 microlamports. Transaction with less than 1_000 `compute_unit_price` will have no priority nor be charged a priority fee. ## Alternatives Considered From d194a664fcf1fcb4ea74a6b13d57bec5e4ea7100 Mon Sep 17 00:00:00 2001 From: Tao Zhu <82401714+taozhu-chicago@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:08:45 -0500 Subject: [PATCH 10/15] Update proposals/0050-increase-prioritization-fee.md Co-authored-by: Andrew Fitzgerald --- proposals/0050-increase-prioritization-fee.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index f113dc8f5..e08d74dc2 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -77,9 +77,9 @@ PoC https://github.com/solana-labs/solana/pull/31469 - user might want to set `compute_unit_price` only when block or account contention increase; - User can do that by either check RPC endpoint `getRecentPrioritizationFees` - for minimal fee to land to block or write lock specific accounts when - constructing transaction; + Users can do that by either checking the RPC endpoint `getRecentPrioritizationFees` + for the minimum fee to land in a block, or specific write locked accounts when + constructing the transaction; User can also continuously pull RPC endpoint to built up prioritization fee historical stats locally, then generate adquent prioritization fee From 0058e956cf0c9a6df65d05ef33333a4edf65c51b Mon Sep 17 00:00:00 2001 From: Tao Zhu <82401714+taozhu-chicago@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:08:55 -0500 Subject: [PATCH 11/15] Update proposals/0050-increase-prioritization-fee.md Co-authored-by: Andrew Fitzgerald --- proposals/0050-increase-prioritization-fee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index e08d74dc2..810acbf06 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -82,7 +82,7 @@ PoC https://github.com/solana-labs/solana/pull/31469 constructing the transaction; User can also continuously pull RPC endpoint to built up prioritization - fee historical stats locally, then generate adquent prioritization fee + fee historical stats locally, then generate adequate prioritization fee algorithmically when constructing transactions. - when setting `compute_unit_price`, it is advised to set in increment of 1_000 microlamports (eg 0.001 lamport); From 4c486568a31693e0831120bc03a4fb8c9a5a73d6 Mon Sep 17 00:00:00 2001 From: Tao Zhu <82401714+taozhu-chicago@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:09:18 -0500 Subject: [PATCH 12/15] Update proposals/0050-increase-prioritization-fee.md Co-authored-by: Andrew Fitzgerald --- proposals/0050-increase-prioritization-fee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index 810acbf06..ad0cd4a02 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -96,7 +96,7 @@ PoC https://github.com/solana-labs/solana/pull/31469 - 31.27% non-vote transactions in mainnet-beta set `compute_unit_price` when both block and account CUs are below 75% of limit (eg., not congested). They are - currently paying insignificant amount of prioritization fee; With this + currently paying an insignificant prioritization fee; With this proposal, the payers of these transaction would have to consider only paying prioritization fee when truly needed. From f34ee6088596038c128b62f897f8b4a065dca307 Mon Sep 17 00:00:00 2001 From: Tao Zhu <82401714+taozhu-chicago@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:09:25 -0500 Subject: [PATCH 13/15] Update proposals/0050-increase-prioritization-fee.md Co-authored-by: Andrew Fitzgerald --- proposals/0050-increase-prioritization-fee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index ad0cd4a02..d84f8a42d 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -97,7 +97,7 @@ PoC https://github.com/solana-labs/solana/pull/31469 both block and account CUs are below 75% of limit (eg., not congested). They are currently paying an insignificant prioritization fee; With this - proposal, the payers of these transaction would have to consider only + proposal, the payers of these transactions would have to consider only paying prioritization fee when truly needed. - about 6% non-vote transactions in mainnet-beta that set `compute_unit_price` From 6a0d454bbe580fa76f7565e294b7d5d8206c3c7b Mon Sep 17 00:00:00 2001 From: Tao Zhu <82401714+taozhu-chicago@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:09:41 -0500 Subject: [PATCH 14/15] Update proposals/0050-increase-prioritization-fee.md Co-authored-by: Andrew Fitzgerald --- proposals/0050-increase-prioritization-fee.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index d84f8a42d..54573a99e 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -100,10 +100,10 @@ PoC https://github.com/solana-labs/solana/pull/31469 proposal, the payers of these transactions would have to consider only paying prioritization fee when truly needed. -- about 6% non-vote transactions in mainnet-beta that set `compute_unit_price` - but either not setting `compute_unit_limit` or setting it _above_ Max 1.4M. - with this proposal, payers of these transactions would have to consider - setting accurate/reasonable `compute_unit_limit`. +- about 6% of non-vote transactions in mainnet-beta that set `compute_unit_price` + are either not setting `compute_unit_limit` or setting it _above_ Max 1.4M. + With this proposal, payers of these transactions would have to consider + setting an accurate/reasonable `compute_unit_limit`. ## Security Considerations From 069f866612660d45678eb3d075ad3d52acc14676 Mon Sep 17 00:00:00 2001 From: Tao Zhu Date: Wed, 21 Jun 2023 15:12:36 -0500 Subject: [PATCH 15/15] fix --- proposals/0050-increase-prioritization-fee.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/0050-increase-prioritization-fee.md b/proposals/0050-increase-prioritization-fee.md index 54573a99e..b16dcda39 100644 --- a/proposals/0050-increase-prioritization-fee.md +++ b/proposals/0050-increase-prioritization-fee.md @@ -28,8 +28,9 @@ where compute_unit_price has unit of microlamport. The small unit of compute_unit_price manifests into: 1. Prioritization_fee is proportionally insignificant to base fee; -2. Therefore, some payers set priority even there is no contention, potentially - distorting local fee market, and leaving other users at a disadvantage; +2. Therefore, some payers set priority even if there is no contention, + potentially distorting local fee market, and leaving other users at a + disadvantage; 3. Little consideration was given to compute_unit_limit when setting priority; These are being documented in https://github.com/solana-labs/solana/issues/31755. @@ -81,7 +82,7 @@ PoC https://github.com/solana-labs/solana/pull/31469 for the minimum fee to land in a block, or specific write locked accounts when constructing the transaction; - User can also continuously pull RPC endpoint to built up prioritization + User can also continuously poll RPC endpoint to built up prioritization fee historical stats locally, then generate adequate prioritization fee algorithmically when constructing transactions. - when setting `compute_unit_price`, it is advised to set in increment of @@ -95,8 +96,7 @@ PoC https://github.com/solana-labs/solana/pull/31469 - 31.27% non-vote transactions in mainnet-beta set `compute_unit_price` when both block and account CUs are below 75% of limit (eg., not congested). - They are - currently paying an insignificant prioritization fee; With this + They are currently paying an insignificant prioritization fee; With this proposal, the payers of these transactions would have to consider only paying prioritization fee when truly needed.