From b24a4a843bc01444f9dea149d6515d8117fd2029 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Thu, 7 Mar 2024 21:24:35 -0600 Subject: [PATCH 01/17] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index b6ce2d4..0c7cf39 100644 --- a/README.md +++ b/README.md @@ -38,5 +38,5 @@ A linear supply growth was chosen for its simplicity and straightforward predict ## State - [`Bus`](src/state/bus.rs) - An account (8 total) which tracks and limits the amount mined rewards each epoch. - [`Proof`](src/state/proof.rs) - An account (1 per miner) which tracks a miner's current hash, claimable rewards, and lifetime stats. - - [`Treasury`](src/state/treasury.rs) – A singleton account which manages program-wide variables and is the mint authority over the Ore token. + - [`Treasury`](src/state/treasury.rs) – A singleton account which manages program-wide variables and is the mint authority for the Ore token. From ee5ea1f4f40a1464bd5c09314df817c3384099f5 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Thu, 7 Mar 2024 21:25:50 -0600 Subject: [PATCH 02/17] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0c7cf39..293d9ec 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ Ore builds upon the consensus layer provided by Solana and uses it to reimagine ## Supply -Ore provides strong protection and guarantees against runaway supply inflation. The supply growth rate is bounded strictly to a range of 0 ≤ R ≤ 2 ORE / min. In other words, linear. The reward rate – amount paid out to miners per valid hash – is dynamically recalculated every epoch (60 seconds) to maintain a target average supply growth rate of 1 ORE / min. This effectively means if global hashpower dedicated to mining Ore is increasing, the reward rate paid out per hash will decrease, and vice versa. +Ore provides strong protection and guarantees against runaway supply inflation. The supply growth rate is bounded strictly to a range of 0 ≤ R ≤ 2 ORE / min. In other words, linear. The reward rate – amount paid out to miners per valid hash – is dynamically adjusted every 60 seconds to maintain a target average supply growth rate of 1 ORE / min. This effectively means if global hashpower dedicated to mining Ore is increasing, the reward rate paid out per hash will decrease, and vice versa. A linear supply growth was chosen for its simplicity and straightforward predictability, a quality that can only be guaranteed by cryptocurrency. Ore aims to strike a balance between the unpredictable runaway inflation of fiat currencies on one hand and the feudal deflationary systems of alternative cryptocurrencies on the other. Ore holders simultaneously have incentive to loan and spend while also being protected against longterm exponential inflation. From 80a6f9b99db6779db765c84c55aabc22791f7e42 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Thu, 7 Mar 2024 21:26:23 -0600 Subject: [PATCH 03/17] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 293d9ec..8d006be 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ The primary innovation of Ore is to offer mining rewards that are non-exclusive. In traditional proof-of-work systems such as Bitcoin, mining rewards are exclusive. That is, only one miner can win every ~10 minutes, and that miner takes home all the tokens for the round. This has had the longterm effect of starving out casual miners who are simply unable to keep up in the arms race against much larger and well-resourced professional mining firms. -The primary reason Bitcoin is designed this way is that its proof-of-work system serves two roles. It's responsible not only for distributing tokens, but also for coordinating network consensus. This makes sense as the tokens are intended to be rewards for those who dedicate resources to securing the Bitcoin network. However due starvation problems outlined above, it has the unintended consequence of excluding major portions of the global population (>99%) from ever being able to mine. This ultimately limits the number of people who can reasonably acquire the token, and thus contributes to further consolidating the supply. Ore takes a different approach. +The primary reason Bitcoin is designed this way is that its proof-of-work system serves two roles. It's responsible not only for distributing tokens, but also for coordinating network consensus. This makes sense as the tokens are intended to be rewards for those who dedicate resources to securing the Bitcoin network. However due starvation problems outlined above, it has had the unintended consequence of excluding major portions of the global population (>99%) from ever being able to mine. This ultimately limits the number of people who can reasonably acquire the token, and thus contributes to further consolidating the supply. Ore takes a different approach. Ore builds upon the consensus layer provided by Solana and uses it to reimagine proof-of-work purely as a token distribution mechanism. So rather than setting up every miner in a winner-take-all competition against one another, Ore gives each miner their own individual computational challenge. As long as a miner provides a valid solution to their personal challenge, the protocol guarantees they will earn a piece of the supply. Since no miner can be censored from the network and valid solutions are non-exclusive, starvation is avoided. From ab6fb57105a4c371a17bd436dd54b3a2727f601e Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Thu, 7 Mar 2024 21:26:43 -0600 Subject: [PATCH 04/17] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 8d006be..3d40c72 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,7 @@ ## How it works -The primary innovation of Ore is to offer mining rewards that are non-exclusive. In traditional proof-of-work systems such as Bitcoin, mining rewards are exclusive. That is, only one miner can win every ~10 minutes, and that miner takes home all the tokens for the round. This has had the longterm effect of starving out casual miners who are simply unable to keep up in the arms race against much larger and well-resourced professional mining firms. +The primary innovation of Ore is to offer mining rewards which are non-exclusive. In traditional proof-of-work systems such as Bitcoin, mining rewards are exclusive. That is, only one miner can win every ~10 minutes, and that miner takes home all the tokens for the round. This has had the longterm effect of starving out casual miners who are simply unable to keep up in the arms race against much larger and well-resourced professional mining firms. The primary reason Bitcoin is designed this way is that its proof-of-work system serves two roles. It's responsible not only for distributing tokens, but also for coordinating network consensus. This makes sense as the tokens are intended to be rewards for those who dedicate resources to securing the Bitcoin network. However due starvation problems outlined above, it has had the unintended consequence of excluding major portions of the global population (>99%) from ever being able to mine. This ultimately limits the number of people who can reasonably acquire the token, and thus contributes to further consolidating the supply. Ore takes a different approach. From 8db477c0d6677f36254b3bed0326a7cfaaf828f8 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 08:40:52 -0600 Subject: [PATCH 05/17] Update README.md --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 3d40c72..055798e 100644 --- a/README.md +++ b/README.md @@ -5,18 +5,18 @@ ## How it works -The primary innovation of Ore is to offer mining rewards which are non-exclusive. In traditional proof-of-work systems such as Bitcoin, mining rewards are exclusive. That is, only one miner can win every ~10 minutes, and that miner takes home all the tokens for the round. This has had the longterm effect of starving out casual miners who are simply unable to keep up in the arms race against much larger and well-resourced professional mining firms. +The primary innovation of Ore is to offer non-exclusive mining rewards. This means if one miner wins rewards, it doesn't prevent another miner from also winning. In traditional proof-of-work systems such as Bitcoin, mining rewards are exclusive. That is, only one Bitcoin miner can win every ~10 minutes, and that miner takes home all the tokens for the round. This has had the longterm effect of starving out casual miners who are simply unable to keep up in the arms race against much larger and well-resourced professional mining firms. -The primary reason Bitcoin is designed this way is that its proof-of-work system serves two roles. It's responsible not only for distributing tokens, but also for coordinating network consensus. This makes sense as the tokens are intended to be rewards for those who dedicate resources to securing the Bitcoin network. However due starvation problems outlined above, it has had the unintended consequence of excluding major portions of the global population (>99%) from ever being able to mine. This ultimately limits the number of people who can reasonably acquire the token, and thus contributes to further consolidating the supply. Ore takes a different approach. +The primary reason Bitcoin is designed this way is that its proof-of-work system serves two roles. It's responsible not only for distributing tokens, but also for coordinating network consensus. This makes sense as the tokens are intended to be a reward for those who dedicate resources to securing the Bitcoin network. However due starvation problems outlined above, it has had the unintended consequence of excluding major portions of the global population (>99%) from ever being able to mine. This ultimately limits the number of people who can reasonably acquire the token, and thus contributes to further consolidating the supply. Ore takes a different approach. -Ore builds upon the consensus layer provided by Solana and uses it to reimagine proof-of-work purely as a token distribution mechanism. So rather than setting up every miner in a winner-take-all competition against one another, Ore gives each miner their own individual computational challenge. As long as a miner provides a valid solution to their personal challenge, the protocol guarantees they will earn a piece of the supply. Since no miner can be censored from the network and valid solutions are non-exclusive, starvation is avoided. +Ore builds upon the consensus layer provided by Solana and uses it to reimagine proof-of-work purely as a token distribution mechanism. Rather than setting up every miner in a winner-take-all competition against one another, Ore gives each miner their own individual computational challenge. As long as a miner provides a valid solution to their personal challenge, the protocol guarantees they will earn a piece of the supply. Since no miner can be censored from the network and valid solutions are non-exclusive, starvation is avoided. ## Supply -Ore provides strong protection and guarantees against runaway supply inflation. The supply growth rate is bounded strictly to a range of 0 ≤ R ≤ 2 ORE / min. In other words, linear. The reward rate – amount paid out to miners per valid hash – is dynamically adjusted every 60 seconds to maintain a target average supply growth rate of 1 ORE / min. This effectively means if global hashpower dedicated to mining Ore is increasing, the reward rate paid out per hash will decrease, and vice versa. +Ore provides strong guarantees and protection against runaway supply inflation. The supply growth rate is strictly bounded to a range of 0 ≤ R ≤ 2 ORE / min. In other words, linear. The reward rate – amount paid out to miners per valid hash – is dynamically adjusted every 60 seconds to maintain a target average supply growth rate of 1 ORE / min. This effectively means if the global hashpower dedicated to Ore mining increases, the reward rate paid out per hash will decrease, and vice versa. -A linear supply growth was chosen for its simplicity and straightforward predictability, a quality that can only be guaranteed by cryptocurrency. Ore aims to strike a balance between the unpredictable runaway inflation of fiat currencies on one hand and the feudal deflationary systems of alternative cryptocurrencies on the other. Ore holders simultaneously have incentive to loan and spend while also being protected against longterm exponential inflation. +A linear supply growth was chosen for its simplicity and straightforward predictability. Ore aims to strike a balance between the unpredictable runaway inflation of fiat currencies on one hand and the feudal deflationary supply schedules of alternative cryptocurrencies on the other. Ore holders are simultaneously incentivized to loan and spend while also being protected against longterm exponential inflation. ## Program From 6ffd4d0126d3732ac0e25ece1879e8a53e9c8808 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 08:42:31 -0600 Subject: [PATCH 06/17] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 055798e..ab0f76a 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ A linear supply growth was chosen for its simplicity and straightforward predict ## Instructions - [`Initialize`](src/processor/initialize.rs) – Initializes the Ore program, creating the bus, mint, and treasury accounts. -- [`Reset`](src/processor/reset.rs) – Resets the program for a new epoch, resetting the bus accounts and topping up the treasury. +- [`Reset`](src/processor/reset.rs) – Prepares the program for a new epoch, updating the reward rate, resetting bus counters, and topping up the treasury. - [`Register`](src/processor/register.rs) – Creates a new proof account for a prospective miner. - [`Mine`](src/processor/mine.rs) – Verifies hashes provided by miners and issues claimable rewards. - [`Claim`](src/processor/claim.rs) – Distributes claimable rewards as tokens from the treasury to a miner. From ebf188c38a36d51e2ad0e916bb450c6d64a01fc5 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 08:43:06 -0600 Subject: [PATCH 07/17] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index ab0f76a..530c874 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ A linear supply growth was chosen for its simplicity and straightforward predict - [`Initialize`](src/processor/initialize.rs) – Initializes the Ore program, creating the bus, mint, and treasury accounts. - [`Reset`](src/processor/reset.rs) – Prepares the program for a new epoch, updating the reward rate, resetting bus counters, and topping up the treasury. - [`Register`](src/processor/register.rs) – Creates a new proof account for a prospective miner. -- [`Mine`](src/processor/mine.rs) – Verifies hashes provided by miners and issues claimable rewards. +- [`Mine`](src/processor/mine.rs) – Verifies a hash provided by a miner and issues claimable rewards. - [`Claim`](src/processor/claim.rs) – Distributes claimable rewards as tokens from the treasury to a miner. - [`UpdateAdmin`](src/processor/update_admin.rs) – Updates the admin authority. - [`UpdateDifficulty`](src/processor/update_difficulty.rs) - Updates the hashing difficulty. From 756f2451588895d17d3a912d7a0200798e85597f Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 08:45:00 -0600 Subject: [PATCH 08/17] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 530c874..f328b79 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ A linear supply growth was chosen for its simplicity and straightforward predict ## Instructions - [`Initialize`](src/processor/initialize.rs) – Initializes the Ore program, creating the bus, mint, and treasury accounts. -- [`Reset`](src/processor/reset.rs) – Prepares the program for a new epoch, updating the reward rate, resetting bus counters, and topping up the treasury. +- [`Reset`](src/processor/reset.rs) – Resets the program for a new epoch. - [`Register`](src/processor/register.rs) – Creates a new proof account for a prospective miner. - [`Mine`](src/processor/mine.rs) – Verifies a hash provided by a miner and issues claimable rewards. - [`Claim`](src/processor/claim.rs) – Distributes claimable rewards as tokens from the treasury to a miner. @@ -38,5 +38,5 @@ A linear supply growth was chosen for its simplicity and straightforward predict ## State - [`Bus`](src/state/bus.rs) - An account (8 total) which tracks and limits the amount mined rewards each epoch. - [`Proof`](src/state/proof.rs) - An account (1 per miner) which tracks a miner's current hash, claimable rewards, and lifetime stats. - - [`Treasury`](src/state/treasury.rs) – A singleton account which manages program-wide variables and is the mint authority for the Ore token. + - [`Treasury`](src/state/treasury.rs) – A singleton account which manages program-wide variables and authorities. From 9c2ae99ff9226a4914948d0ef09e4b65beb2be00 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 08:48:44 -0600 Subject: [PATCH 09/17] Update mine.rs --- src/processor/mine.rs | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/processor/mine.rs b/src/processor/mine.rs index f3aa88c..203fd2e 100644 --- a/src/processor/mine.rs +++ b/src/processor/mine.rs @@ -98,6 +98,8 @@ pub fn process_mine<'a, 'info>( Ok(()) } +/// Validates the provided hash, ensursing it is equal to SHA3(current_hash, singer, nonce). +/// Fails if the provided hash is valid but does not satisfy the required difficulty. pub(crate) fn validate_hash( current_hash: KeccakHash, hash: KeccakHash, From 9b7da16ec49c581f865b22eec6e076e4312887b3 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 08:58:45 -0600 Subject: [PATCH 10/17] Update update_difficulty.rs --- src/processor/update_difficulty.rs | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/processor/update_difficulty.rs b/src/processor/update_difficulty.rs index 9921364..d47e575 100644 --- a/src/processor/update_difficulty.rs +++ b/src/processor/update_difficulty.rs @@ -13,6 +13,19 @@ use crate::{ /// Safety requirements: /// - Can only succeed if the signer is the current program admin. /// - Can only succeed if the provided treasury is valid. +/// +/// Discussion: +/// - Ore subdivides into 1 billion indivisible atomic units. Therefore if global hashpower +/// were to increase to the point where >1B valid hashes were submitted to the protocol for +/// validation per epoch, the Ore inflation rate could be pushed above the 1 ORE / min target. +/// - The strict limits on bus reward counters guarantee inflation can never exceed 2 ORE / min, +/// but it is the responsibility of the admin to adjust mining difficulty if needed to maintain +/// the 1 ORE / min target average. +/// - It is worth noting that Solana processes well below 1 million real TPS or +/// (60 * 1,000,000) = 60,000,000 hash validations per epoch. Even if ever transaction on Solana +/// were a mine operation, this would still be two orders of magnitude below the boundary +/// condition where Ore inflation targets would be challenged. So in practice, Solana is likely +/// to reach its network saturation point long before Ore ever hits theoretical limits. pub fn process_update_difficulty<'a, 'info>( _program_id: &Pubkey, accounts: &'a [AccountInfo<'info>], From 04dcb00173baa5258b3a0b4557e41474f6708df0 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 08:59:33 -0600 Subject: [PATCH 11/17] Update update_difficulty.rs --- src/processor/update_difficulty.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/processor/update_difficulty.rs b/src/processor/update_difficulty.rs index d47e575..efac504 100644 --- a/src/processor/update_difficulty.rs +++ b/src/processor/update_difficulty.rs @@ -22,7 +22,7 @@ use crate::{ /// but it is the responsibility of the admin to adjust mining difficulty if needed to maintain /// the 1 ORE / min target average. /// - It is worth noting that Solana processes well below 1 million real TPS or -/// (60 * 1,000,000) = 60,000,000 hash validations per epoch. Even if ever transaction on Solana +/// (60 * 1,000,000) = 60,000,000 transactions per minute. Even if ever transaction on Solana /// were a mine operation, this would still be two orders of magnitude below the boundary /// condition where Ore inflation targets would be challenged. So in practice, Solana is likely /// to reach its network saturation point long before Ore ever hits theoretical limits. From 5f0b392e0f8be0a918c58e3e0758e6b5b17232b8 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 08:59:45 -0600 Subject: [PATCH 12/17] Update update_difficulty.rs --- src/processor/update_difficulty.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/processor/update_difficulty.rs b/src/processor/update_difficulty.rs index efac504..b05eb66 100644 --- a/src/processor/update_difficulty.rs +++ b/src/processor/update_difficulty.rs @@ -21,7 +21,7 @@ use crate::{ /// - The strict limits on bus reward counters guarantee inflation can never exceed 2 ORE / min, /// but it is the responsibility of the admin to adjust mining difficulty if needed to maintain /// the 1 ORE / min target average. -/// - It is worth noting that Solana processes well below 1 million real TPS or +/// - It is worth noting that Solana today processes well below 1 million real TPS or /// (60 * 1,000,000) = 60,000,000 transactions per minute. Even if ever transaction on Solana /// were a mine operation, this would still be two orders of magnitude below the boundary /// condition where Ore inflation targets would be challenged. So in practice, Solana is likely From 8b1457a9441de88d003d0eb3d62fd912b910c890 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 09:00:18 -0600 Subject: [PATCH 13/17] Update update_difficulty.rs --- src/processor/update_difficulty.rs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/processor/update_difficulty.rs b/src/processor/update_difficulty.rs index b05eb66..0a0a2c1 100644 --- a/src/processor/update_difficulty.rs +++ b/src/processor/update_difficulty.rs @@ -22,10 +22,10 @@ use crate::{ /// but it is the responsibility of the admin to adjust mining difficulty if needed to maintain /// the 1 ORE / min target average. /// - It is worth noting that Solana today processes well below 1 million real TPS or -/// (60 * 1,000,000) = 60,000,000 transactions per minute. Even if ever transaction on Solana +/// (60 * 1,000,000) = 60,000,000 transactions per minute. Even if every transaction on Solana /// were a mine operation, this would still be two orders of magnitude below the boundary /// condition where Ore inflation targets would be challenged. So in practice, Solana is likely -/// to reach its network saturation point long before Ore ever hits theoretical limits. +/// to reach its network saturation point long before Ore ever hits its theoretical limits. pub fn process_update_difficulty<'a, 'info>( _program_id: &Pubkey, accounts: &'a [AccountInfo<'info>], From 4e9efe6fcafef6c0246069a4696a92fb60080c6c Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 09:11:00 -0600 Subject: [PATCH 14/17] Update update_admin.rs --- src/processor/update_admin.rs | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/processor/update_admin.rs b/src/processor/update_admin.rs index 7815e98..4e0c406 100644 --- a/src/processor/update_admin.rs +++ b/src/processor/update_admin.rs @@ -11,6 +11,20 @@ use crate::{instruction::UpdateAdminArgs, loaders::*, state::Treasury, utils::Ac /// Safety requirements: /// - Can only succeed if the signer is the current program admin. /// - Can only succeed if the provided treasury is valid. +/// +/// Discussion: +/// - The admin authority only has one lever of power: the ability to adjust the global +/// mining difficulty. If the difficulty is too easy, miners will find hashes very quickly +/// and the bottleneck for throughput shifts from local compute to Solana bandwidth. In essence, +/// if the Ore token has value and difficulty is low, mining becomes an incentivized stress +/// test for the Solana network. +/// - At the same time, if difficulty is too hard, miners will have to wait very long periods +/// of time between finding valid hashes. This will bias rewards to well-resourced miners +/// with large compute operations. Keeping a low difficulty ensures casual miners can +/// consistently earn rewards and undercuts some of the advantage of larger players. +/// - Ultimately admin authority should be delegated to a governance mechanism – either +/// democratic or futarchic – to ensure difficulty is kept at a value that represents the +/// interests of ecosystem paricipants. pub fn process_update_admin<'a, 'info>( _program_id: &Pubkey, accounts: &'a [AccountInfo<'info>], From 704b1345d8ce918b43c5261abc6bd181d1ac8000 Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 09:28:43 -0600 Subject: [PATCH 15/17] Update update_admin.rs --- src/processor/update_admin.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/processor/update_admin.rs b/src/processor/update_admin.rs index 4e0c406..499aa9c 100644 --- a/src/processor/update_admin.rs +++ b/src/processor/update_admin.rs @@ -13,7 +13,7 @@ use crate::{instruction::UpdateAdminArgs, loaders::*, state::Treasury, utils::Ac /// - Can only succeed if the provided treasury is valid. /// /// Discussion: -/// - The admin authority only has one lever of power: the ability to adjust the global +/// - The admin authority has one lever of power: the ability to adjust the global /// mining difficulty. If the difficulty is too easy, miners will find hashes very quickly /// and the bottleneck for throughput shifts from local compute to Solana bandwidth. In essence, /// if the Ore token has value and difficulty is low, mining becomes an incentivized stress From 9897808b8fad6532fc8b7f6df41edb370e7cca9a Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 09:29:51 -0600 Subject: [PATCH 16/17] Update update_admin.rs --- src/processor/update_admin.rs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/processor/update_admin.rs b/src/processor/update_admin.rs index 499aa9c..f4bed51 100644 --- a/src/processor/update_admin.rs +++ b/src/processor/update_admin.rs @@ -15,16 +15,16 @@ use crate::{instruction::UpdateAdminArgs, loaders::*, state::Treasury, utils::Ac /// Discussion: /// - The admin authority has one lever of power: the ability to adjust the global /// mining difficulty. If the difficulty is too easy, miners will find hashes very quickly -/// and the bottleneck for throughput shifts from local compute to Solana bandwidth. In essence, +/// and the bottleneck for mining will shift from local compute to Solana bandwidth. In essence, /// if the Ore token has value and difficulty is low, mining becomes an incentivized stress /// test for the Solana network. -/// - At the same time, if difficulty is too hard, miners will have to wait very long periods +/// - At the same time, if difficulty is too hard, miners will have to wait a very long period /// of time between finding valid hashes. This will bias rewards to well-resourced miners /// with large compute operations. Keeping a low difficulty ensures casual miners can /// consistently earn rewards and undercuts some of the advantage of larger players. /// - Ultimately admin authority should be delegated to a governance mechanism – either /// democratic or futarchic – to ensure difficulty is kept at a value that represents the -/// interests of ecosystem paricipants. +/// values and interests of the whole ecosystem. pub fn process_update_admin<'a, 'info>( _program_id: &Pubkey, accounts: &'a [AccountInfo<'info>], From 2303b4f8aea6385546afd8371a40c1dcc8e782db Mon Sep 17 00:00:00 2001 From: Hardhat Chad <155858888+HardhatChad@users.noreply.github.com> Date: Fri, 8 Mar 2024 09:31:19 -0600 Subject: [PATCH 17/17] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f328b79..25ec392 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ Ore builds upon the consensus layer provided by Solana and uses it to reimagine ## Supply -Ore provides strong guarantees and protection against runaway supply inflation. The supply growth rate is strictly bounded to a range of 0 ≤ R ≤ 2 ORE / min. In other words, linear. The reward rate – amount paid out to miners per valid hash – is dynamically adjusted every 60 seconds to maintain a target average supply growth rate of 1 ORE / min. This effectively means if the global hashpower dedicated to Ore mining increases, the reward rate paid out per hash will decrease, and vice versa. +Ore provides strong guarantees and protection against runaway supply inflation. The supply growth rate is strictly bounded to a range of `0 ≤ R ≤ 2 ORE/min`. In other words, linear. The reward rate – amount paid out to miners per valid hash – is dynamically adjusted every 60 seconds to maintain a target average supply growth rate of `1 ORE/min`. This effectively means if the global hashpower dedicated to Ore mining increases, the reward rate paid out per hash will decrease, and vice versa. A linear supply growth was chosen for its simplicity and straightforward predictability. Ore aims to strike a balance between the unpredictable runaway inflation of fiat currencies on one hand and the feudal deflationary supply schedules of alternative cryptocurrencies on the other. Ore holders are simultaneously incentivized to loan and spend while also being protected against longterm exponential inflation.