From 451f47c181d18dff425a7698059a02718c275317 Mon Sep 17 00:00:00 2001
From: Blockiosaurus <blockiosaurus@gmail.com>
Date: Fri, 22 Nov 2024 13:14:51 -0500
Subject: [PATCH 1/4] Proposal to create a cluster sysvar.

---
 proposals/XXXX-create-cluster-sysvar.md | 73 +++++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 proposals/XXXX-create-cluster-sysvar.md

diff --git a/proposals/XXXX-create-cluster-sysvar.md b/proposals/XXXX-create-cluster-sysvar.md
new file mode 100644
index 000000000..0fb80bb68
--- /dev/null
+++ b/proposals/XXXX-create-cluster-sysvar.md
@@ -0,0 +1,73 @@
+---
+simd: '0183'
+title: Skip Rent Rewrites
+authors:
+  - brooks@anza.xyz
+category: Standard
+type: Core
+status: Accepted
+created: 2024-10-04
+feature: https://github.com/solana-labs/solana/issues/26599
+---
+
+## Summary
+
+Do not rewrite accounts *that are unchanged* by rent collection.
+
+## Motivation
+
+Rent collection checks every account at least once per epoch.  This process
+loads *and stores* accounts, regardless if the account has actually changed or
+not.  All accounts now must be rent-exempt, and there are zero rent-paying
+accounts on mainnet-beta.  Thus, almost every account stored due to rent
+collection is unchanged, and storing unchanged accounts is useless work.
+
+Worse, storing accounts incurs all the downstream costs on the accounts
+database: computing the various accounts hashes on extra accounts unnecessarily,
+tracking/cleaning/purging the new and old versions of accounts, plus it bloats
+the incremental snapshots with accounts that haven't meaningfully changed.
+
+## Alternatives Considered
+
+We could remove rent collection entirely, and that is already planned
+(see SIMD-0084).  Skipping rewrites is a smaller, less complex change, which
+can allow rollout and activation sooner.
+
+## New Terminology
+
+"Skipping rewrites" means to not store accounts that are unchanged by rent
+collection.
+
+## Detailed Design
+
+If rent collection has *not* changed an account, the account must not be
+stored/written back in that slot.
+
+An important note, rent collection updates an account's `rent epoch` in addition
+to its balance.  If rent collection does not collect rent (i.e. the account's
+balance is unchanged), but *does* change the account's `rent epoch`, the
+account must still be stored.
+
+To state another consequence explicitly, since these accounts will not be
+rewritten, they will no longer be part of the accounts delta hash nor the
+incremental accounts hash.
+
+## Impact
+
+Validators will see performance improvements:
+
+* Fewer accounts will need to be stored per slot.
+* Fewer accounts will need to be hashed for the various accounts hashes.
+* Fewer accounts will need to be included in incremental snapshots.
+
+## Security Considerations
+
+Having all accounts rewritten due to rent collection results in all accounts
+being included in at least one bank hash per epoch.  Since the bank hash is
+part of what is voted on for consensus, this means every account is verified by
+the network at least once per epoch.
+
+By skipping rewrites, we lose this security property.  This is OK because the
+Epoch Accounts Hash (EAH) was added to directly address this issue.  See the
+[EAH proposal](https://docs.solanalabs.com/implemented-proposals/epoch_accounts_hash)
+for more information.

From 6566ac97b0a8925109471a37e25aeb49ec9e8e28 Mon Sep 17 00:00:00 2001
From: Blockiosaurus <blockiosaurus@gmail.com>
Date: Fri, 22 Nov 2024 13:17:53 -0500
Subject: [PATCH 2/4] Renumber and fix typo.

---
 proposals/0201-create-cluster-sysvar.md | 62 +++++++++++++++++++++
 proposals/XXXX-create-cluster-sysvar.md | 73 -------------------------
 2 files changed, 62 insertions(+), 73 deletions(-)
 create mode 100644 proposals/0201-create-cluster-sysvar.md
 delete mode 100644 proposals/XXXX-create-cluster-sysvar.md

diff --git a/proposals/0201-create-cluster-sysvar.md b/proposals/0201-create-cluster-sysvar.md
new file mode 100644
index 000000000..721664b62
--- /dev/null
+++ b/proposals/0201-create-cluster-sysvar.md
@@ -0,0 +1,62 @@
+---
+simd: "0201"
+title: Create Cluster Sysvar
+authors:
+  - keith@metaplex.foundation
+category: Standard
+type: Core
+status: Draft
+created: 2024-11-22
+feature:
+---
+
+## Summary
+
+There should be a natively accessible Sysvar (like Rent or Clock) that provides Cluster details in order to determine the specific SVM environment.
+
+## Motivation
+
+It is currently not possible to determine which cluster a Solana program is executing on from within the program itself. This makes dynamic behavior based on different SVM environments difficult without requiring multiple builds of a single protocol. Native determination of the SVM cluster would improve DevEx and diminish opportunities to introduce bugs by allowing more dynamic program execution.
+
+## Alternatives Considered
+
+- **SDK Abstraction** - It would be possible but difficult to maintain separate SDKs per cluster or dynamic resolution based on genesis hash
+
+## New Terminology
+
+**ClusterDetails** - The sysvar structure which provides the relevant details for a program to determine which cluster it's executing on.
+
+## Detailed Design
+
+The following Cluster type and ClusterDetails struct would provide sufficient details for a program to properly determine the environment on which it's executing. String tags are included because using genesis hash alone is insufficient for clusters that don't guarantee permanence such as devnet, testnet, or roll-ups.
+
+```rust
+/// The cluster type, usually the first three with an optional named
+/// field for more diverse clusters (alt-devnets, roll-ups).
+#[repr(C)]
+pub enum ClusterType: {
+    mainnet,
+    devnet,
+    testnet,
+    other(String),
+}
+
+#[repr(C)]
+pub struct ClusterDetails {
+    /// The genesis hash for the cluster, guaranteed for mainnet but
+    /// possibly variable for other cluster types.
+    pub genesis_hash: Hash,
+    /// A named tag for the SVM chain on which the program is executing.
+    pub blockchain: String,
+    /// Cluster Type
+    pub cluster_type: ClusterType,
+}
+```
+
+## Impact
+
+Dynamic determination of cluster would allow programs to perform better validation of cluster-specific feature such as variable protocol fees, irreplicable PDAs or derivations, or variable features across different blockchains.
+
+## Security Considerations
+
+Certain named fields could be invalidated due to changes to the underlying SVM runtime. Program developers should be sure to validate and fail gracefully if unexpected changes occur.
diff --git a/proposals/XXXX-create-cluster-sysvar.md b/proposals/XXXX-create-cluster-sysvar.md
deleted file mode 100644
index 0fb80bb68..000000000
--- a/proposals/XXXX-create-cluster-sysvar.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-simd: '0183'
-title: Skip Rent Rewrites
-authors:
-  - brooks@anza.xyz
-category: Standard
-type: Core
-status: Accepted
-created: 2024-10-04
-feature: https://github.com/solana-labs/solana/issues/26599
----
-
-## Summary
-
-Do not rewrite accounts *that are unchanged* by rent collection.
-
-## Motivation
-
-Rent collection checks every account at least once per epoch.  This process
-loads *and stores* accounts, regardless if the account has actually changed or
-not.  All accounts now must be rent-exempt, and there are zero rent-paying
-accounts on mainnet-beta.  Thus, almost every account stored due to rent
-collection is unchanged, and storing unchanged accounts is useless work.
-
-Worse, storing accounts incurs all the downstream costs on the accounts
-database: computing the various accounts hashes on extra accounts unnecessarily,
-tracking/cleaning/purging the new and old versions of accounts, plus it bloats
-the incremental snapshots with accounts that haven't meaningfully changed.
-
-## Alternatives Considered
-
-We could remove rent collection entirely, and that is already planned
-(see SIMD-0084).  Skipping rewrites is a smaller, less complex change, which
-can allow rollout and activation sooner.
-
-## New Terminology
-
-"Skipping rewrites" means to not store accounts that are unchanged by rent
-collection.
-
-## Detailed Design
-
-If rent collection has *not* changed an account, the account must not be
-stored/written back in that slot.
-
-An important note, rent collection updates an account's `rent epoch` in addition
-to its balance.  If rent collection does not collect rent (i.e. the account's
-balance is unchanged), but *does* change the account's `rent epoch`, the
-account must still be stored.
-
-To state another consequence explicitly, since these accounts will not be
-rewritten, they will no longer be part of the accounts delta hash nor the
-incremental accounts hash.
-
-## Impact
-
-Validators will see performance improvements:
-
-* Fewer accounts will need to be stored per slot.
-* Fewer accounts will need to be hashed for the various accounts hashes.
-* Fewer accounts will need to be included in incremental snapshots.
-
-## Security Considerations
-
-Having all accounts rewritten due to rent collection results in all accounts
-being included in at least one bank hash per epoch.  Since the bank hash is
-part of what is voted on for consensus, this means every account is verified by
-the network at least once per epoch.
-
-By skipping rewrites, we lose this security property.  This is OK because the
-Epoch Accounts Hash (EAH) was added to directly address this issue.  See the
-[EAH proposal](https://docs.solanalabs.com/implemented-proposals/epoch_accounts_hash)
-for more information.

From cd36c5f5963a9480d9e7ee65b64f412adccd4351 Mon Sep 17 00:00:00 2001
From: Blockiosaurus <blockiosaurus@gmail.com>
Date: Fri, 6 Dec 2024 11:26:23 -0500
Subject: [PATCH 3/4] Fixing lint errors.

---
 proposals/0201-create-cluster-sysvar.md | 27 ++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/proposals/0201-create-cluster-sysvar.md b/proposals/0201-create-cluster-sysvar.md
index 721664b62..b43dfeab4 100644
--- a/proposals/0201-create-cluster-sysvar.md
+++ b/proposals/0201-create-cluster-sysvar.md
@@ -5,30 +5,41 @@ authors:
   - keith@metaplex.foundation
 category: Standard
 type: Core
-status: Draft
+status: Review
 created: 2024-11-22
 feature:
 ---
 
 ## Summary
 
-There should be a natively accessible Sysvar (like Rent or Clock) that provides Cluster details in order to determine the specific SVM environment.
+There should be a natively accessible Sysvar (like Rent or Clock) that provides
+Cluster details in order to determine the specific SVM environment.
 
 ## Motivation
 
-It is currently not possible to determine which cluster a Solana program is executing on from within the program itself. This makes dynamic behavior based on different SVM environments difficult without requiring multiple builds of a single protocol. Native determination of the SVM cluster would improve DevEx and diminish opportunities to introduce bugs by allowing more dynamic program execution.
+It is currently not possible to determine which cluster a Solana program is
+executing on from within the program itself. This makes dynamic behavior based
+on different SVM environments difficult without requiring multiple builds of a
+single protocol. Native determination of the SVM cluster would improve DevEx and
+diminish opportunities to introduce bugs by allowing more dynamic program execution.
 
 ## Alternatives Considered
 
-- **SDK Abstraction** - It would be possible but difficult to maintain separate SDKs per cluster or dynamic resolution based on genesis hash
+- **SDK Abstraction** - It would be possible but difficult to maintain separate
+SDKs per cluster or dynamic resolution based on genesis hash
 
 ## New Terminology
 
-**ClusterDetails** - The sysvar structure which provides the relevant details for a program to determine which cluster it's executing on.
+**ClusterDetails** - The sysvar structure which provides the relevant details
+for a program to determine which cluster it's executing on.
 
 ## Detailed Design
 
-The following Cluster type and ClusterDetails struct would provide sufficient details for a program to properly determine the environment on which it's executing. String tags are included because using genesis hash alone is insufficient for clusters that don't guarantee permanence such as devnet, testnet, or roll-ups.
+The following Cluster type and ClusterDetails struct would provide sufficient
+details for a program to properly determine the environment on which it's
+executing. String tags are included because using genesis hash alone is
+insufficient for clusters that don't guarantee permanence such as devnet,
+testnet, or roll-ups.
 
 ```rust
 /// The cluster type, usually the first three with an optional named
@@ -55,7 +66,9 @@ pub struct ClusterDetails {
 
 ## Impact
 
-Dynamic determination of cluster would allow programs to perform better validation of cluster-specific feature such as variable protocol fees, irreplicable PDAs or derivations, or variable features across different blockchains.
+Dynamic determination of cluster would allow programs to perform better
+validation of cluster-specific feature such as variable protocol fees,
+irreplicable PDAs or derivations, or variable features across different blockchains.
 
 ## Security Considerations
 

From 6db2b9ac5b6a903ac1e7c3557935364746b7c124 Mon Sep 17 00:00:00 2001
From: Blockiosaurus <blockiosaurus@gmail.com>
Date: Fri, 6 Dec 2024 11:27:17 -0500
Subject: [PATCH 4/4] Fixing lint errors.

---
 proposals/0201-create-cluster-sysvar.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/proposals/0201-create-cluster-sysvar.md b/proposals/0201-create-cluster-sysvar.md
index b43dfeab4..823786e3a 100644
--- a/proposals/0201-create-cluster-sysvar.md
+++ b/proposals/0201-create-cluster-sysvar.md
@@ -72,4 +72,6 @@ irreplicable PDAs or derivations, or variable features across different blockcha
 
 ## Security Considerations
 
-Certain named fields could be invalidated due to changes to the underlying SVM runtime. Program developers should be sure to validate and fail gracefully if unexpected changes occur.
+Certain named fields could be invalidated due to changes to the underlying SVM
+runtime. Program developers should be sure to validate and fail gracefully if
+unexpected changes occur.