A Whaleshares Fork... Part One - Rough Draft, Community Outreach
Below I'm going to share my "whitepaper" for a blockchain I've been working on, a fork of whaleshares. I'd like to state a few things before and after, so this may come out looking strange, it's nowhere near a finished edit, and it will not include the usual 30 pages of technical details, these are well known at this point.
Looking at it now this will have to be two parts :joy:
This is a prediscussion, before building began. Some of this is included. Some of this is not. All is open to discussion. More to come, but I don't want to overload people, it's alot.
Many names were discussed. Name is currently being held private. App will be referred to anonymously for the duration of this writeup. Sorry but I've already had two domains stolen from me, not taking chances :D
- Increase Witnesses Schedule to 51.
- Minimum Validators to run chain: ⅔ + 1
- Integrate Block Production Score into Block Production Schedule.
(Could this be an attack factor? dos a validator to lower their position?)
- Integrate Vote Count into production schedule
- No need to increase block size at the current time.
Increasing the number of witnesses allowed to participate in block production will provide a fairer chance for all parties, and perhaps inspire a larger number of witnesses altogether. Increasing total witnesses does however increase required witnesses. Perhaps not viable. These changes were not included.
A block production score of sorts could be introduced to the witnesses, in that they receive a punishment apon missing blocks, either through the form of monetary deduction, or lowering in the witness schedule. Furthermore, scoring witnesses on a ranking of stake/voters will provide a more equally distributed vision of what the community as a whole wants. These changes are discussed below.
How to solve limitations.
- What is the problem that limits solve? only spam?
The main purpose of bandwidth is due to the free nature of the blockchain. Blockchains “cannot” be free, as they are expensive in data. Do to this, all chains have either a fee or bandwidth system in place, allowing a user either a certain amount of total transactions, or total transactions within a given time limit.
Another effect of this, is that users are able to receive rewards on content, and therefore users will be inspired to use as much bandwidth as they can in efforts to earn more and more. A soft cap must be in place. These changes are discussed below.
No need for a decentralised muting feature.
Options for a decentralised community powered mute were discussed, and turned down. The following is proposed, but not implemented.
Make mute automatic when a user’s reputation reaches 0. At this point the user will need to pay a fee to rebalance their reputation and regain posting capabilities. The fee should compound each time a user’s reputation is dusted. This is decentralised enough. Users caught abusing the system will have the wrath of the community to deal with. This can be used as a punishment as much as it can be an attack.
Open to discussion
Multiple New Reward Pools
community users, content creators, trend setters, celebrities.
All of these roles are voted on, using content votes.
Developer role introduced; similar in function to witness/devfund, but voted on by community.
The current ecosystem of one large pool which we all drink from was a very refreshing change, however I propose several smaller subsets of pools. A main content pool for the general community, say 20%. A Content Creators pool with a higher reward value of 40%, and a celebrity role of say 20% which can be claimed by both Content Creators as well as General Community members. These changes have not been included.
Community Pool is dedicated to run of the mill community members, sharing tweets, microblogging, etc. Users who perform under a limit will be entitled to claim from this pool.
Content Creation Pool
Content Creation Pool is dedicated to users who put out content regularly, and receive regular interactions on their posts. These creators are the ones writing blog articles, tutorials, drawing in crowds and creating interaction on the platform. Perhaps a weekly claim would be better for this.
Celebrity pool is dedicated to risers who have the most followers. Users with the most followers will automatically be entitled to claim from this pool, with or without creating content on a regular basis.
The Developers pool will be explained below under Decentralised Development Funds.
It is my belief that these adjustments will provide a more enjoyable experience which inspires content creation, while still allowing this platform to be viable for smaller social media users.
Not all of these pools may be necessary, ie celebrity pool may turn out to be more confusing for users than it is worth the reward to them, however I do find the idea interesting to play with. Enables users to vie for affection on platform.
Open to discussion
Accounts with 3+ years inactivity have content garbage collected. Content Creators, Trend Setters, content remains locked from 1-14 days, can only be edited.
In efforts to assist with the issue of “spam”, content should be able to be removed when a user no longer wants it displayed. Not being able to edit a blog page is a huge set back as well. To retain value over content, users who claim from the “content creators” pool will have their content locked for X days. This is not implemented, but I am very open to the idea of allowing content to be removed.
Decentralised development funds.
I propose to decentralise development funds from the whaleshares team, by introducing a role similar to witness, called developer. Users with the “developer” role will be able able to make claims from the developers pool, providing they fall within the active developers limit.
Limit will be decided by witnesses, developers will be determined by community stakeholders. These changes are discussed below.
How to handle the reward pools?
Honestly, in the previous system there would be no need to “handle” anything. Being able to claim once daily has worked well in the past, and will work even more effectively in the future if my goal is achieved in that regard. With that said, introducing multiple reward pools bring forward the idea of autoclaiming.
Instead, I suggest we keep the current motive the same for the original “daily”/”community” fund, and instead simply autoclaim the separate funds for users who achieved the goals put out. Ideally a notification would be provided. These changes have not been included.
In further effort to fight ever growing inflation, a tax could be applied on each blog article. Nothing that would ever stop a normal user from posting, far less than is generated in a single day, however enough that bots would need to practice control. All content fees from taxes will be burnt.
Content taxing was not included. If needed, inflation should be fought as well as bandwidth in terms of follow/friend/other operations that are more optional and can be done over time for free.
New chains require longer staking lengths in order to keep customers from dumping all together, this can hurt market, investors, and platform. These chains are often limited by the fact that they have just created and distributed millions of tokens to hundreds of thousands of users. Thankfully this will not be our case at all. Ideally I would like to reduce staking to a 1 week powerdown, 7 payments over 7 days. This should be more than enough notice for investors watching the markets. This will be discussed in Part 2
Inflation base: 5%.
Initial Supply: 5,000,000 Tokens allocated for inflation and account creation ONLY. No initial tokens or early bonuses will be provided to anyone in any situation. Accounts may be airdropped.
Many situations were discussed in terms of inflation. I have removed them all, and will discuss the best below. Originally, only 1 million tokens were created, however those numbers were too low to work with a large user base. This will be discussed in Part 2
The idea of implying a fee on voting attributes to several factors.
New Users will not waste bandwidth voting, or time getting to know the witnesses or the intricacies of the system.
Users will need to truly care about the system in order to spend their tokens on manipulating in.
Fees being burnt will contribute to fighting the natural systems inflation over the years, which is a high priority of this project.
These changes were included, and will be discussed again in part 2
Bandwidth changes were implemented in order to allow more interactions from all users, and to scale out richer users to a maximum bandwidth while providing averagely invested members a quality experience.
- Post Interval: 55 Seconds
- Comment Interval: 10 Seconds
- Bandwidth Window: 1 Day
- Base Bandwidth: 4 Posts in 1 Day(Bandwidth Window)
Current bandwidth stats:
- Post Interval: 5 Minutes
- Comment Interval: 20 Seconds
- Bandwidth Window: 1 Day
- Base Bandwidth: 2 Posts in 1 Day
Previous stake-bandwidth ratios.
More than 1 Billion WLS - 1024kb Daily Bandwidth More than 100 Million WLS - 512kb Daily Bandwidth More than 10 Million WLS - 256kb Daily Bandwidth More than 1 Million WLS - 128kb Daily Bandwidth More than 100,000 WLS - 64kb Daily Bandwidth More than 10,000 WLS - 32kb Daily Bandwidth More than 1,000 WLS - 16kb Daily Bandwidth More than 100 WLS - 8kb Daily Bandwidth More than 10 WLS - 4kb Daily Bandwidth More than 1 WLS - 2kb Daily Bandwidth Less than 1 WLS - 1kb Daily Bandwidth
Proposed stake-bandwidth ratios.
More than 1 Billion WLS - 8192kb Daily Bandwidth More than 100 Million WLS - 8192kb Daily Bandwidth More than 10 Million WLS - 8192kb Daily Bandwidth More than 1 Million WLS - 8192kb Daily Bandwidth More than 100,000 WLS - 3584kb Daily Bandwidth More than 10,000 WLS - 768kb Daily Bandwidth More than 1,000 WLS - 320kb Daily Bandwidth More than 100 WLS - 128kb Daily Bandwidth More than 10 WLS - 48kb Daily Bandwidth More than 1 WLS - 16kb Daily Bandwidth Less than 1 WLS - 2kb Daily Bandwidth
These changes were included, and will be discussed again in part 2
User Registration Thoughts (Needs discussion)
Private experience? One user can invite X new users per month. X can be variable on users age, stake, and reputation? Should these operations cost the user? No use burning tokens on creation, as the idea is to inflate on creation. Bring back reputation? These changes were included, and will be discussed again in part 2
A Truly Decentralised System
No user, not the creator, not the developers, not the witnesses, and certainly not scammers, should have undeserving priority over another. Those who earn their stake fairly, they will have power as the system is designed, however there should be no location in which any user gained any sort of unfair early access reward. It is my opinion this is what kills these systems.
In a standard decentralised system so far, the first users to join are awarded the most, and it is an ever reaching cycle of those who joined first selling to those who joined later. It is my hope that this can be avoided through the following methods.
There should be little no to Initial Tokens created.
As the developer, it was both difficult and tempting when deciding how tokens should be arranged in the beginning. Inflation must start somewhere, and it should of course start in good hands.
Especially as many of us are coming from previous platforms and all have our own individual previous balances, I don’t want to get into many situations where people attempt to relocate their previous statuses into the new system, though to be clear some are under consideration in minor regards.
Where will inflation begin then?
Inflation should begin with the account creation account. These tokens can be used to pay for the initial accounts, and will be distributed at the will of users just as in a normal system, though at a slightly higher rate. This will continue until all tokens have been spent, and are sitting in development funds. At this point the chain will be opened to the public.
The initial days of this project will be to give those a chance who started on older, more irreparable graphene blockchains to begin the migration to this new one. It is my hope that both users and developers of all chains will see value in this project, if only even to update or inspire their own code.
What about initial development?
With no starting whales, how will initial project activities such as promotion, marketing, and development be maintained? It is my beliefs that the foundation laid above will provide a solid breeding ground for a healthy user base with solid “tokenomics”.
Enabling an inspired community with a healthy market and prominent interaction and discussion will be vital in attracting developers, marketers, and all sorts of promoters. This system should not “spread like wildfire”, in fact, it was designed to grow at a controlled exponential rate.
Initially, I will be more than fine covering the efforts needed for development, however to be honest with everyone, when speaking long term, without mainstream attraction the product will likely fall off. Many of us have been through this before and know that money dictates the way of the world.
It is my hopes that this being the first system to truly have no sense of early reward, no sense of priority or favor, and one which is active, and eager to move forward will be enough to inspire others to join in the fun.
Share your thoughts with me. If this all sounds like crap, let me know, it's a valid opinion. If you love the ideas, let me know too. Even better, if you love the system and have some ideas of your own to contribute, share below or ask how you can help out!
Notes by the Developer
Source will be made available immediately upon release. It is not my goal to maintain any semblance of control over this project, I feel that is the most harmful attribute to projects such as these. Those who wish to work on the project need simply create an issue, suggest a fix, or otherwise gather the community's attention and deploy the fixes.
This system should always be completely manageable by the community through the use of witness platforming. Strengthening witness numbers could enforce equality in the future, however 21 will be fine to start. The only user who should have more power than another, is one who has earned it through time, progress, or investment.
The majority of the work done in this project comes from previous platforms, and developers of varying skill levels, from simple helpers, to mad geniuses. If credit should arise from this project, it should be to the ones who spent massive man hours developing graphene software.
The technology has been forked various times to various degrees, and a happy upsight to this all is that many of us have been there to watch the issues that arise in platforms like these. This entire document outlining the details of the first hard fork, is detailing the many issues that I myself have discovered, and immediate early response factors to cut them out of the equation.
With that being said, I’m certain there are issues that have not yet been solved, or that some of the ideas said above may not be the absolute best way to solve the problems they set out too. If you think you have something worth contributing, though I have said it before, this project is completely open source and not only will it benefit from, but it requires minds of all kinds to look at all angles of the problem.
Thank you for your time.