From 491595270e3adaf80498b37165f1a2ecd34badfa Mon Sep 17 00:00:00 2001 From: Justin Starry Date: Thu, 28 Dec 2023 00:17:18 +0800 Subject: [PATCH] SIMD-0085: Additional Fee Collector Constraints (#85) * SIMD-0085: Additional Fee Collector Constraints * Add more context and address feedback * use consistent terminology * explain why the validator node account alternative isnt used * Update proposals/0085-additional-fee-collector-constraints.md Co-authored-by: Tyera * Update proposals/0085-additional-fee-collector-constraints.md Co-authored-by: Tyera * feedback --------- Co-authored-by: Tyera --- ...85-additional-fee-collector-constraints.md | 94 +++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 proposals/0085-additional-fee-collector-constraints.md diff --git a/proposals/0085-additional-fee-collector-constraints.md b/proposals/0085-additional-fee-collector-constraints.md new file mode 100644 index 00000000..904b1904 --- /dev/null +++ b/proposals/0085-additional-fee-collector-constraints.md @@ -0,0 +1,94 @@ +--- +simd: "0085" +title: Additional Fee-Collector Constraints +authors: + - Justin Starry +category: Standard +type: Core +status: Draft +created: 2023-11-05 +feature: https://github.com/solana-labs/solana/issues/33888 +--- + +## Summary + +Every validator defines a node id which is also used as the validator's +fee-collector account for collecting earned protocol fees. After implementing +this proposal, validator implementations will burn fees if they would otherwise +be distributed into a fee-collector account that violates one of the following +constraints: + +1. Must be a system owned account +2. Must be rent-exempt + +These constraints apply to both transaction fees and rent fees. Note that the +rent-exempt constraint was already added for rent fee collection in +[Feature 30151](https://github.com/solana-labs/solana/issues/30151). + +## Motivation + +1. Fee distribution occurs outside of the transaction runtime because the Solana + protocol mandates that fees are distributed to "fee-collector" accounts at the + end of each block. By restricting fee-collector accounts to be system owned, the + number of account modification edge cases as well as protocol complexity are + both reduced. +2. Prevent new rent-paying accounts from being created since rent collection is + planned to be disabled in SIMD-0084. + +## Alternatives Considered + +### Elide the system-owned constraint + +Restricting fee-collector accounts to be system-owned is perhaps overly +restrictive and limits the amount of flexibility that validator operators have +when managing sensitive accounts with funds. However, the risk of having more +runtime edge cases is too high to allow any program-owned account to collect +fees. The Solana protocol should aim to limit the types of account modifications +that can occur outside of the transaction processor to avoid introducing +loopholes. + +### Introduce an enshrined "validator-node" account + +Rather than restricting fee-collector accounts to be system-owned, a new type of +"validator-node" account could be introduced. Currently, in normal validator +operations, the fee-collector account is also used as the node id as well as +the vote fee payer. Introducing a validator-node account that is owned by a +validator-node program which allows configuring a withdraw authority and +vote fee payer could help increase validator operation flexibility and +increase clarity in how validator keys are used in the protocol. + +This approach requires a migration of all fee-collector accounts as well as +the development of a new on-chain program to manage the new validator-node +accounts. It will be a big effort compared to the proposed constraints in this +SIMD and should be discussed in a new SIMD if this approach is desired. +Furthermore, durable nonce accounts already have a configurable authority field +which can be used to manage fee-collector account funds in a more flexible way. + +## New Terminology + +Fee-Collector Account: The account that receives block and rent fees distributed +by validators. + +## Detailed Design + +At the end of a block, validators MUST ONLY distribute fees to accounts that are +both system owned and rent-exempt. If a fee-collector account does not satisfy +these constraints, the fees MUST be burned by not distributing them to anyone. + +## Impact + +New and existing validators must ensure that their fee-collector account is +rent-exempt and owned by the system program in order to receive fees. Since the +Solana Labs validator implementation currently requires the fee-collector +account to be same account as the fee payer for vote transactions, this is +unlikely to impact any validators unless they run a custom implementation. + +Validators will still be able to collect fees into durable nonce accounts if +they wish. If a validator does not wish to use a hot wallet to have custody +over collected fees, they may use durable nonce accounts which have a +configurable authority address. + +## Security Considerations + +Note that durable nonce accounts are system owned and rent exempt and can +therefore continue to be used for fee collection.