It is my honor to present to you the proposals and polls which will lay the foundation for the Gridcoin Research 4.0 development roadmap! This document has been compiled from issues and proposals posted on github and discussed among the community over the past several months. Work has been put in during this time by @barton26, @caraka, The Earl of Annandale, @jringo, quezacoatl, @skcin, and @tomasbrod. This article and the results of the polls it proposes are meant to provide the groundwork for actionable discussions and will serve to inform the Gridcoin Roadmap going into 2018. You will see that there are some topics we can easily summarize in a few sentences as they are mainly bug fixes. Others are bigger, structural tasks that have been a matter of discussion for some time. Most of these proposals require mandatory updates. For these proposals, a valid poll is one which is verifiably created by one of the individuals involved with compiling this article. Furthermore, only polls which reach at least 15% of the available vote share by their closing will be valid. All valid polls will be used to inform the Gridcoin 4.0 Roadmap for 2018.
The implementation timeline works to group updates based on priority and efficiency while minimizing the number of mandatory updates. A draft can be found in the form of a github project board here:
In the process of these discussions, we ask that everyone remember that we are all here to enjoy and contribute to the Gridcoin adventure and we all seek the continued growth and development of Gridcoin, for science!
First of all, here are our goals:
- Simplify BOINC reward logic and pay more often
- Secure blockchain
- Create an accurate and fair rewards distribution
- Remove or reduce the barrier for low balance researchers to earn their rewards
- Stable and secure superblocks
- Secure beacons or account associations
- Remove Team Requirement
- Combine mandatory updates into as few updates as possible
And here is the timeline for between now and when the polls close:
This proposal includes a timeline spanning 6 weeks of discussion before any decisions are made. During this time, there will be a Gridcoin Hangout every Saturday at 7pm UTC. All hangouts will be available to stream within 24 hours of ending.
- November 3rd - This article is posted
- November 4th: Proposal Focused Hangout - General discussion and questions regarding this article, its creation, its intent, and its content
- November 11th: Regularly Scheduled Hangout - The focus for this article's segment will be on Constant Block Reward proposals
- November 16th - Constant Block Reward proposal preliminary list is posted
- November 18th: Proposal Focused Hangout - Discussion regarding Constant Block Reward proposals, and questions regarding other proposals in this article.
- November 19th - Final Constant Block Reward proposals list posted
- November 20th - All polls are made.
- November 25th: Regularly Scheduled Hangout
- December 2nd: Proposal Focused Hangout
- December 9th: Regularly Scheduled Hangout
- December 16th - Polls close at 7:00pm UTC
- December 16th: Regularly Scheduled Hangout - Results Announced. Party. Hangouts return to their regular bi monthly schedule.
- January 1st, 2018 - 2018 Roadmap released. Happy new year!
Let's dive right in
- Stats and Magnitude gathering - "Superblocks"
- Reward Calculation - Research and Staked
- Research Reward Payouts
- Account association - "Beacons"
- Sharedrop and Switching code base
- Additional Improvements and How to Help
- Proposal dependencies and implementation difficulty estimate
1. Stats and Magnitude gathering - "Superblocks"
Recent Average Credit is a project specific algorithm that calculates credits earned in relation to time. Credits are the BOINC reward units distributed to users for completed and verified work units. Superblocks are the mechanisms that gather stats from BOINC projects. Magnitude determines GRC earned through research and is currently determined largely by RAC. We propose replacing the use of RAC for magnitude calculation with a Total Credit Delta system. We also propose a new way of forming Superblocks called Dynamic Witness Participation.
Total Credit Delta
The RAC algorithm serves as a smoothing function, a tool to reduce the effect of volatility in a system. RAC is notoriously difficult to estimate and the RAC to magnitude relationship is even trickier. Total Credit Delta seeks to solve this difficulty while providing other enhancements at the expense of the smoothing properties of RAC.
Total Credit Delta would use the difference in a users credit between superblocks to calculate "TCD". TCD would then translate into Magnitude. This change paired with the update outlined in the section "Reward Calculation" will simplify the earnings prediction processes and open the door for simple earnings calculators. Without a smoothing function, Total Credit Delta will bring us closer to a direct Compute to GRC relationship, though the calculation of credits will remain a subject for further exploration. The lack of a smoothing function also introduces increased reward volatility. Users will no longer be guaranteed rewards when they are not actively researching. This solves the RAC exploit where a user can charge their RAC through a short period of intense crunching and reap the rewards as their RAC slow decays. It also removes the charge time required for new users to reach their full reward potential, a common complaint.
The poll will look something like this:
[ ] RAC - No change
[ ] TCD
@jefpatat has been running an experiment exploring RAC, take a look:
Dynamic Witness Participation
Gridcoin currently forms a superblock by having all nodes request data from each whitelisted project simultaneously. This process causes high network and server load and does not scale. Additionally, a failed project might invalidate an entire superblock, delaying updates for all projects until the next accepted superblock.
Dynamic Witness Participation intends to increase stability and speed of superblock creation on the Gridcoin network by solving these issues. Dynamic Witness Participation will serve to replace the stats gathering aspect of what is now called the "Neural Network" with a new C++ iteration integrated directly into the client, making the network cross-platform.
Dynamic Witness Participation will inherit the dynamic selection of delegate nodes. Only the delegate nodes download the necessary data from the project servers and work on creation of the superblock. The algorithm will run independently on different projects to reduce network load and to prevent one project from negatively affecting the statistics collection of other projects.
Any node willing to serve as delegates in the creation of a superblock will indicate such in a staked block. When too many nodes are willing to serve as delegate, the network chooses a subset through a dynamic selection process. This limits the number of active connections and decreases stress on BOINC project servers. Once selected, all delegate nodes download the project stats data, process it into a sharable form and place a vote for their version. Delegate nodes then form a consensus on the data set to be used in the superblock. Finally, a delegate node with the agreed upon data set is randomly chosen to create the superblock and end the process.
Honest delegate nodes will be rewarded with extra GRC for creating the superblock and voting. The bonus DWP rewards are meant only as a minor additional incentive and gamification tool, not as a primary source of GRC mint. Details on reward are in the next section, "Reward Calculation".
Details of this processes can be found here:
The poll will look something like this:
As we are continuing to explore this and other potential options, this poll will serve as an opinion poll.
[ ] Continue exploring DWP
[ ] I do not think DWP holds potential
2. Reward Calculation - Research and Staked
There are two major issues with current reward calculations. First, the calculation of magnitude is unecessarily complex and the total research reward calculations have been failing. To solve these issues, we propose setting a new standard for GRC production by directly relating magnitude to GRC produced by research per day. Second, Gridcoin's interest payment system does nothing to encourage a user to contribute large staking balances to the blockchain. To solve this issue, we propose replacing interest with a Constant Block Reward protocol which rewards a set number of GRC to the staker of a block. Constant Block Reward has the added benefit of synergizing with Dynamic Witness Participation (detailed above) and potential future developments, such as Sidestaking (detailed in the section "Additional Improvements").
Constant Block Reward with Magnitude and Supply Readjustment
Gridcoin rewards GRC for researching with BOINC and for staking blocks for its blockchain.
Gridcoin's current logic of BOINC research payments is quite complex. A combination of a 14-day "kitty" plus the magnitude unit are in charge of GRC production. Right now we have 115,000 overall magnitude and a dynamic magnitude unit of about 0.2-0.25. This means that 1 magnitude produces 0.2-0.25 GRC / day. This leads to a reduced GRC production via research payments. On average, 27,103.08 GRC per day has been produced via research rewards in blocks 1,020,000 to 1,059,000. This is little more than half of the intended 48,000 GRC per day. To simplify and correct this structure, we propose setting the magnitude unit to 1. This basically makes magnitude equivalent to GRC produced through research per day: 48,000 magnitude = 48,000 GRC produced by research per day. To implement this change, the community will need to choose an overall magnitude.
Gridcoin provides a transaction fee reward for staking a block. As a result, many users with large balances do not contribute to securing the blockchain. They do this because Gridcoin promises 1.5% interest on all GRC in circulation so long as the GRC stakes a block. This means that a GRC coin can be kept offline indefinitely, and as soon as it is brought online it receives all interest it is owed. If you receive benefits regardless of how much you help secure the blockchain, and the reward for staking a block is negligible, why would you help secure the blockchain? Gridcoin suffers vulnerability to forks and other blockchain disruptions due to this economic model which separates reward from service.
We propose removing interest earned and replacing it with Constant Block Reward. Essentially, each block staked will reward the staking node with a set number of GRC. This will stop rewarding idle coins, forcing investors to stake in order to earn idle profit, which in truth will no longer be idle profit. The increase in blockchain security is good for all of Gridcoin as it provides stability and brings more trust to the Gridcoin network. To implement this change, the community will need to choose a GRC value to serve as block reward. It is also possible, though not necessary, to reward superblock creators with extra GRC along with delegate nodes outlined in the Dynamic Witness Participation section above.
While these two updates are not dependent on one another, we believe they are both necessary and as they constitute the foundation of the Gridcoin Network's economy, are implemented best when tied together.
To implement these changes we propose the community vote on all reasonable combinations put forward in the 3 week period following the posting of this article. Proposals can be posted on Steemit, reddit, slack, irc, or cct. We will post a preliminary list on steemit on November 16th, two days before the hangout on November 18th. Any proposals wishing to be added after the preliminary list is posted must add their proposals in the comments of that steemit thread. Reasonable proposals from that thread will be added to the poll up to 24 hours before the poll is made on November 20th. To be considered, a proposal must at least contain information regarding the following aspects along with reasoning. These proposals will help define the GRC economy for at least the next year, so be as detailed as possible.
- GRC minted by Research per Day (equals to total magnitude)
- GRC minted by Research per Year (total magnitude * 365)
- GRC minted by CBR per Day (GRC reward per block * 960 blocks)
- GRC minted by CBR per Year (GRC reward per block * 960 blocks * 365)
- Differences between the proposal's economics and the current interest economics - as detailed as possible.
- Overall economic effects and predictions of the proposed values (Magnitude and CBR)
- Bonuses for DWP Superblock creators and delegates (in case we implement DWP)
The recently added getblockstats RPC command might prove useful in your calculations:
If your proposal is similar to another one, we encourage you to team up and compromise in order to help consolidate the number of poll choices.
The poll will look something like this:
[ ] Proposal 1: 50,000 overall magnitude with 15 GRC per block + X superblock reward + Y delegate reward
[ ] Proposal 2: 50,000 overall magnitude with 15 GRC per block no extra reward
[ ] Proposal 3: 50,000 overall magnitude with 10 GRC per block + X superblock reward + Y delegate reward
[ ] Proposal 4: 26,000 overall magnitude with 10 GRC per block no extra reward
[ ] Proposal 5: 26,000 overall magnitude with 0.5 per block no extra reward
[ ] Proposal 6: ...
[ ] ...
[ ] maintain current protocol: 115,000 mag, dynamic mag unit, kitty and current DPoR output persist
[ ] Search for alternatives
House Keeping - "Trapezioid" Bug Fix
Currently, a slightly different formula is used when the time between rewards crosses 20 days. The formula basically requires all blocks to be scanned on startup in order to work properly. This makes the process for a user receiving their first reward, or when the previous reward was more than 6 months old, incredibly complicated, often resulting in significant reward losses. We want to replace this calculation to a more accurate one which will reward users fairly for all the work they do. This proposal would require a mandatory update.
This update will not require a poll.
3. Research Reward Payouts
Research reward payouts are currently bound to PoS payments which are bound to block creation. To create a new block and collect both rewards, a miner must find a valid PoS kernel. Depending on the miner's balance, this can take a very long time. This is a common and very reasonable complaint of users without high balances. Joining an external pool helps a lot, but pool users can't vote with mangintude and their BOINC work is logged under the pool's name, not their own.
There are three proposals to improve the current system of distributing research reward.
Manual Rewards Claim
Manual Rewards Claim intends to provide an alternative to CoinStake and pool staking with the intent to increase accessibility to owed research rewards for non-staking balance users. Additionally, Manual Rewards Claim adds an economic tool to the Gridcoin ecosystem in the form of Manual Claim Fees.
Manual Rewards Claim works much like the rewards claiming of steemit. At any time, a user would have the option to manually claim their earned research rewards in an upcoming block. This claim system would function as an alternative to standard staking and pools, which would remain unaffected. To prevent spam, a fee similar to a transaction fee would be required to manually claim your rewards. This is the Manual Claim Fee.
It is possible, though not immediately necessary, to distribute Manual Claim Fees to an array of entities such as: stakers, The GRC Foundation, BOINC projects - to subsidize server costs and security, charities, relief efforts, causes and crowd-sourcing, or fees could be burned to help combat inflation. There would need to be an extended conversation after the implementation of Manual Rewards Claim to determine a future path. For simplicity of implementation it might make most sense to treat Manual Claim Fees as transactions fees: They are to be added to blocks as rewards for staking.
Manual Rewards Claim acts as a bridge between pool use and solo use. Pools are a critical part of the Gridcoin ecosystem, and the cryptocurrency world in general. Their purpose with Gridcoin is to help users with entry level balances stake and receive their research rewards more often. Currently, when a user earns enough GRC to stake on their own they choose to stay with or to leave the pool. With Manual Rewards Claim, when a user has enough magnitude to earn more than the cost of the Manual Claim Fee, they can choose between continued pool use, or paying the fee.
If we agree to implement Manual Rewards Claim, we might need to have a second poll to determine how the Manual Claim Fee is calculated.
Stake V8 removed researchers from the process of securing the blockchain. This was done for security reasons, however it presented an interesting question: Do we want the blockchain to be secured solely by PoS, or do we want Research involved by reintroducing a Proof of Research protocol?
Beacon Mint is a moderately secure block creation scheme that weights stakers not only by their mature GRC balance, but also by the amount of rewards that they are owed. This alternative gives Researchers part of the responsibility of securing the blockchain.
In short, Beacon Mint splits block creation into two fields: Standard PoS blocks and Beacon Mint blocks. To prevent age bunkering attacks, there will be a required number of PoS blocks created between Beacon Mint blocks. Beacon Mint blocks are created by keeping track of the research rewards owed to a specific beacon. As this number rises, so does the Researcher's likelyhood to stake through the Beacon Mint mechanism. This number continues to rise until the beacon creates a block, at which point the process resets. It might be possible to impliment Beacon Mint with Manual Rewards Claim, however more research is required to determine the economic implications.
The details and security of Beacon Mint can be found here:
Super Block Payout
Another alternative is to pay all rewards in superblocks. The upsides are frequent payouts for everyone, including new users. On the downside, there is no incentive to hold mined coins. The large volume of transactions would also mean that the block size limit would likely have to be lifted for the size of these superblocks.
The poll will look something like this:
[ ] No Change
[ ] Manual Rewards Claim
[ ] Beacon Mint
[ ] Super Block Payout
[ ] Search for alternatives
4. Account Association - "Beacons"
Currently what binds your wallet to a BOINC CPID is called a beacon. The beacon system is not entirely secure and not entirely stable... it has been a fix a long time coming. Users are complaining about split CPIDs, unexpected CPID changes, and bad beacon keys. The new system may stop using CPIDs altogether and use the Account IDs instead, as CPIDs are both not very secure and can change unexpectedly. Additionally the current system requires the user to supply an email address for their wallet, which is something we're hoping to do away with.
There are two proposals. Both of them deprecate CPIDs and require either automatic or manual registration of each project account separately into the Gridcoin reward system.
BrodSAA alternative requires the user to copy a string from their wallet into their BOINC project account (name or url,...), then register the project in their wallet. In the background the Gridcoin network (the DWP nodes) will process and verify the registration against the project server. The extra text can be removed after the registration is complete. This all works without modification of the BOINC server software.
CM-SAA alternative involves a special page on the BOINC project website where the user must copy a string from their wallet and then copy the response back to the wallet to complete the registration. Creating that custom page does involve modification to core BOINC software. BOINC maintainers are against any crypto-currency related modifications plus there are projects running outdated software versions, it will take years for them all to upgrade. On the other hand these registrations are much faster to verify.
The poll will look something like this:
This section is intended to spread awareness and initiate a discussion regarding a long standing issue. We intend to explore and develop these and other possible improvements to the BOINC-Gridcoin interface and hope to present an actionable poll some time within the coming 6 month Gridcoin Foundation payment block. We encourage anyone interested in learning more to read the wiki linked in Further Reading where additional options are being presented. Beyond that, let's get thinking.
There is no poll for this section.
5. Sharedrop and Switching Codebase
This protocol extends on the idea by @cm-steem to transfer Gridcoin to a new codebase and blockchain. It was recently shown by Martin Grothe that some private information can be recovered from the blockchain and since we can't just change data in a blockchain (a Hash List) we need a way to transfer the account balances to a new chain. This protocol aims to do this process securely; that is without a single entity governing the process. Instead, the users of Gridcoin will have a share on validating the whole transition.
Two chains will run in parallel for some time. The new chain will start with a Genesis block as coins usually do. But the mint mechanism on the new chain will be an absolutely new thing. Not PoW, not PoS, but blocks on the new chain will be secured by blocks from the old. Sharedrop is a process of translating unspent transactions from the old chain into the new blocks. Since the old chain continues to run, both historic and new transactions must be translated and gradually included in blocks. The challenge is that transactions on new chain will have different hashes than on old. Eventually Proof of Stake and research rewards will be enabled on this new chain to complete the transition and split for good.
Up to the point of final splitting, the operation will be mostly silent for average user. Users will not be required to update unless they are large investors and want to help.
Switching to a new and clean codebase involves porting a lot of code. The work done implementing the proposals in this article on the old codebase would have to be duplicated for the new. Spending time and money on the complex changes twice does not make sense. Some of the proposals, however, are important for security of the blockchain or easy to do. The decision, which changes to implement now and which after the switch, will be made by developers.
The poll will look something like this:
[ ] Yes
[ ] No
[ ] Search for alternatives
Martin Grothe Post:
6. Additional Improvements and How to Help
These are improvements and issues we are currently exploring and hope to see developed or addressed within a year. If you would like to contribute to these or any of the proposed developments in this article, or if you have other potential improvements, we encourage you to reach out through any active community channel which can be found at https://gridcoin.us. Approved developer work is paid hourly from the Gridcoin Foundation. Details regarding payment can be found at:
Cold Staking: A mechanism that allows whales to leave significant balance(s) in cold storage, while a wallet kept online stakes on behalf of the cold keys. This would encourage whales to keep a wallet always online without fear of getting their balance hacked. Whales could potentially vote from such a wallet, representing their whole balance without having to crack open cold storage.
Sidestaking: A mechanism that distributes funds to a wide array of possible entities and projects. This can be implemented in the staking rewards structures, transaction fees structures, and/or the Manual Claim Fees structures. Sidestaking might present a fair and secure way to fund BOINC projects, Gridcoin marketing campaigns, bounty based developments, faucets, general research, charities and relief efforts, personal projects, and other endeavors. Fund distribution could be manual, automatic, static, dynamic, or a combination, and could be tied into the network and its economic requirements. For example, a portion of fees could automatically and dynamically be allocated to a burn sidestake address or to block creation rewards based on the measured needs of the network.
The Greylist: A mechanism which helps on-board new BOINC projects while providing automated maintenance to the active whitelist. The Greylist could serve as a temporary stop for projects wishing to be whitelisted. This would allow time for project vetting, while giving researchers time to learn about the project and adjust their crunching as desired. Additionally, the Greylist could automatically assume contact responsibilities with projects which go down, fail to distribute work units, or whatever we choose. Projects would then automatically be rewhitelisted when they fix the issue. After a certain time on the greylist, the project would be removed from the greylist and would have to go through the whitelist process again from the beginning. This would encourage project maintenance and communication while reducing work required for superblock formation.
Reduce memory usage, load time and fork-stability: https://github.com/tomasbrod/Gridcoin-Research/commits/acceptance
Reduce blockchain space usage by implementing better serialization format and merging the Coinbase and Coinstake special transactions
Improved user experience, and wallet graphical interface
7. Proposal Dependencies and Implementation Difficulty Estimate
- Constant Block Reward -> done
- Mag Unit change -> easy
- Beacon Mint -> easy
- Manual Rewards Claim -> moderate
- CM-SAA -> moderate
- RAC to TCD -> moderate, better with DWP
- BrodSAA -> after DWP easy, without it hard
- Trapezoid fix -> easier said than done due to current code structure
- DWP -> hard
Thank you for taking the time to involve yourself with the growth and development of Gridcoin. All of us are eager to see Gridcoin excel and look forward to the coming discussions.
The Steem rewards from this article will be translated into GRC on Bitshares and used to pay for editing the hangouts.
A Personal Note from Myself
Every time someone comes into the community and asks for a lead dev, 2 things happen:
- People explain that there are no lead devs. We are open source submission.
- People list who they would consider a lead dev.
@ravon is one person who is on everyone's list as a lead dev. It should be noted that he has not yet signed on to this article and these proposals. This is not because of subversion or cliques or any of that FUD. He is simply a busy man. He is aware of this article and all of us look forward to hearing his thoughts. At the same time, if we want to get a 2018 Roadmap out by 2018, these discussions need to start in an "official" capacity immediately. There is plenty of time and opportunity for discussion before polls are made.
Also, seeing the work put into this by so many people is inspiring. From the bottom of my heart, thank you to everyone for everything you do, and thank you for the coming discussions.
Now, let's get this done.
Find the edited recordings of the first discussion here: