The DIV Kernel, A weed that has found fertile ground
I
have not been entirely idle recently, but I have not been getting a lot of sleep, which is slowing me down.
However, I tend to find that when I have the urge to be awake and creative at this time, it's usually for a good reason.
I'm not sure if this is just my natural state, or if I simply do not sleep when there is light to alarm my hypersensitive endocrine system, or, maybe, that I have a very important task to do, and, quite simply, big parts of the early phases require the 3AM Eternal:
3AM Eternal by The KLF
So, I haven't quite yet fully placed this concept into the DIV Whitepaper, but my excuse will be that I had to spend most of today tweaking my miners for optimal operation. In the process, I discovered that these new AMD stock CPU coolers are quite dangerous to poke your fingers into. My left ring fingertip was fairly neatly torn open and it's making it hard for me to type the letter "o" and "q" (dvorak layout). Not impossible, but it's slowing me down.
The miners are all up and running now, and tomorrow when there is sunlight again, and hopefully, I will have caught some more nap time, I'll be posting up a photo set and story about my new noisy cohabitants next to the kitchen area.
So, to the topic at hand:
The DIV Kernel is the name I am giving to the first and probably biggest bit of coding work I will be doing in this process, at least, for a while. I'm really better at writing documentation than coding, but, I'll design the scheme, and we'll see how much value others really do think it has, when they are part of the operation.
The DIV Kernel is basically, a cobbled togethter, quick, distributed self-hosted blockchain. It will be built using Tendermint and the Tendermint Basecoin plugin. These are a toolkit for blockchain development that was introduced to me by @faddat, and indeed, he may help me in this stage also, and notably, https://ark.io (who I suspect were @faddat's former comrades in the first iteration of Dawn) are going to be using it in their content monetisation blockchain.
Well, I don't intend to run a full on production distributed database with such a rudimentary and simplified replication protocol, however, for the DIV Kernel, it is a perfect bootstrap.
What is the DIV Kernel?
The DIV Kernel is a self-hosted blockchain code repository with a consensus peer rewards allocation logic.
It is basically taking the concept of Steem, and it's incredible potency in inducing competition in social networks, and turning that energy towards the development of the chain itself.
It is not, by its nature, simply a popularity contest, as Steem is, with its' focus on really the least valuable part of the system, and the endless, eternal cash-out that is the Prisoner's Dilemma of Steem. Instead, by using reputation scores, combined with stake (and at least for a time, there will be no way to buy stake), and a very basic post submission protocol, which is a derived subset of Git's protocols, and basically forming a wrapper around a Git repository.
Users will be able to both host the chain themselves (there will be no witness reward type payment to start with), contribute changes (the DIV Kernel equivalent of making a post, or comment, essentially no difference between them), and create side-branches where the developers can test operational testnets with altered codes, and then submit a 'merge request', which will be the equivalent of Steem's Witness Activated Hard Forks. If 2/3rds of users, active within the previous week, agree, then the 'master' branch is merged with the 'testing' branch.
There will of course be multiple branches in development, and before a merge can occur, the Kernel will require eliminating conflicts first before the merge can be put to the vote.
When a merge is successful, according to the votes upon the changes, combining stake and reputation, and the total byte-size of submitted changes by a given user, rewards will be paid out to all who contributed.
There has to also be a separate, but related scheme involving documentation, that does not concern the size of the code changes, but only the votes applied to it.
The integration with Git and devising the schemes and interfaces to make the system live are not big, or complicated, really, and they don't have to exceed the ease-of-use level that a developer would expect. A simple web interface that shows the repository, similar to github, with the addition of the ability to vote on changes, and on the post-side, a simple CLI command that speaks the DIV protocol to the other DIV nodes to have a new change distributed amongst all nodes.
Obviously, also, the ledger, which is mostly already built, which has its own schema for preventing double-spends, aka conflicting operations on the same object.
When does this get started?
Well, I am just done with getting my miners in order, and I still have to catch up on my sleep a bit, but I will have a github repository open for business soon, and I will be making regular reports on progress here on Steem.
Why is this a big deal?
Basically, because it is very obvious how potent turning any human activity into a game is at increasing productivity. Even if that might just be gaming a system to milk the market cap, this is still a competitive human activity.
The DIV Kernel aims to leverage this power towards building the DIV network, itself, bypassing all the issues with in-crowds and dictatorships like Linux Torvalds has over Linux (which is not a bad thing because he does generally live up to the moniker 'benevolent dictator for life'), or Steemit has over steemd, which obstruct the ingress of talent, act as a bottleneck for user feedback (and this is even doubly exacerbated with Steem because of the structure of the witness game).
So, instead, it essentially is a game, where the objective is to out-do your competitors at governing the code that runs the system. And you get paid, in accordance with the evaluation of your competitors.
As the system grows, and more parts are added, there will of course be more casual, end-user people in the system, who are simply contribututing their user experience. I did not mention this, but this is another aspect of the DIV Kernel - user feedback will be aggregated in a specific section of the database, and users will have the opportunity to then include this in the development process, and likewise, the voting/rewards system will apply to the feedback system, so those who first start issues that get a lot of interest, will also thereby get paid in tokens for doing this essential work, as will those who pick up this data, and then use it to guide their work on the code, which will include building the cross-references that link feedback to relevannt code snippets and algorithms where the error or issue is located.
Nobody has done this before, and Github, and other CVS based collaborative development platforms tend to implement a hierarchic, non-monetised scheme for the labor, the programmers, if they are paid, are paid outside of the hosting system. This brings the two things together, and if it works according to the theory, those who jumped in early, before there was a way to sell the tokens, will get paid very well, once such a facility is provided.
It should be more lucrative than working for even a large coporation like Google, in the long run. The goal is to make the HR of all these evil corporations sweat bullets, because, though I am positioning this as a 'blockchain' project, I have discussed at some length in the past how I intend to make this become a whole operating system, network server hosting file storage database services, game, media distribution, and eventually, juridical and government system.
I really have no idea what you are talking about and it sounds like I will be left out of the main part (developing code) but might be able to participate in the user experience area. It sounds like you have big plans for this and I wish you success. Unfortunately, it is all over my head.
What does self-hosting mean? As far as I know, there must be some servers somewhere to store the data used to host a site.
Yesterday I started making a policy of voting only 4x per day at 100%, with both of my accounts, you are number 2 today for asking good questions.
Yes, initially it will be focused on platform development. I realised a couple of days ago that this is not an after-thought, but completely primary. It is basically a way to combine governance and development into a single unit, leveraging the gameification process as a meritocratic method of compensating the most important part of any social network system - the code, and embodied in the code, the rules of the society it creates.
Once this part is operational, obviously next is to monetise operating servers, both validators and providers of data retrieval services (the back end that finds the data to show you a web page). Then, the interface, and that is when average people join the game.
I want to build a platform that has all the dynamic, DIY energy of Open Source software, but includes everyone, and pays everyone for the value they contribute.
Self hosting means that all servers that run the DIV network also host the code that it is built from, and even, ideally not long afterwards, even build and upgrade themselves automatically when a hard fork vote passes and new code is switched on across the network.
Please do ask for further clarification if you need it. I am currently away from my workstation, shopping for some health supplies.
Thanks elfspice!
Your plan makes perfect sense to me, despite not understanding what it takes to make such a system work. Of course you need to have a serious amount of code and working software running on hardware to begin with. Contributors should be compensated for doing this work and providing the hardware. I will be looking forward to the day that I can become involved as a user and perhaps offer suggestions for making the user interface better.
May I ask why just 4 votes per day? That would leave 6 votes wasted, would it not?
It's funny that you have decided to implement this just after I had decided to use my 10 votes for upvoting those that actually contribute to my own posts. I want to encourage participation and have thus decided that to heck with looking for stuff to curate and make a few cents off of. Instead I will be voting on comments to encourage them. Seems there are a few of us that are all thinking the same way. The only difference is that my votes only generate 2 cents at this time. They did give 4 cents just after HF19, but that was only for a short while. Eventually mine will generate a bit more.
I do it this way because after 4 votes, there is 80% remaining and it takes 24 hours to regenerate 20%, so, this way I give maximum possible rewards to who I vote on. So you may also find the same occurs if you limit it to 4x 100% votes.
Also, I will be looking out for good new stories from my followers, as I follow them back to open the opportunity to reciprocate their interest in my work. But once I give out 4 votes in a day, that's it, sorry if you are in the wrong time zone, I wake up early, usually at or around dawn. So that's afternoon in asia and late night in the americas.
Yes, there is a fair bit of work to do, but Tendermint and its Basecoin plugin allow me to focus on the actual database structures and consensus rules for the rewards pool and voting, and integrating Git into a controlling database, and, of course, there does have to be a forum, just like this one!
The difference there also is I will also for this be using largely off the shelf components to build this. For simplicity it will be a bog standard default simple Markdown editor - there is a very nice interface side editor for this that I can adapt, which is WYSIWYG (!), and the base system will be together. From that point on, the idea will be that the system itself does the hosting for itself, and all the rest that is extraneous to the primary functionality can be built, using that primary functionality.
I was under the belief that 10 votes per day would drain only 20% (hence the account is back to 100% after 24 hours). I don't actually count my votes, but I'm generally not lower than around 80% even after giving out my daily votes (around 10 of them).
Since you know so much about Steem, I was wondering if you knew off hand how the reward pool is generated? Specifically, what I wish to know is: If there is just 1 person posting 1 article per day, is the reward pool the same size as if 100 people posted 100 articles in a day. And, if there is a larger pool for more content, is that reward pool growth linear? Essentially, what I'm after is; Is it harder to earn rewards with more Steemians participating than it was a year ago when there were far less Steemians.
I agree that re-inventing the wheel is a waste of time. Why create totally new software when perfectly good software already exists! The idea is to integrate the various software into a seamless experience for the end user. Ultimately, the end user expects to be able to intuitively begin using a product without the need to read a manual or learn new tricks. This is where Steemit falls down in its clunkyness.
The rewards pool is essentially the daily allocation (or weekly, in this case) refilled on a moment to moment basis that is the supply rate of new steem (or, in this case, to be precise, VESTS, which are allocated into steem, SBD and SP).
So basically, at every block, a witness calculates the rewards to be given out to the pending and due rewards, makes the payouts in the chain, calculates the correct refill (it has to vary up and down in a short time window because of the constant variance of how much rewards are given out in a block). The rewards are based on the sum of the VESTS tied up in SP, divided over the amount of rewards pool in time, which is tracked and kept towards an average.
I think the off the shelf components are servicable, but would not work in the long run, because the design I have in mind goes beyond simple blockchain, and uses new models that you can find examples of in 'Byzantine Fault Tolerant' database systems. In fact, I may end up using one of those, there is about 6 major projects I can dig up that I have read about. The thing is though, the latest stuff from Eric Freeman, which involves using gossip protocols to prevent forking of the chain, is much much much faster than the standart blockchain chatter protocols and confirmations system like you see with bitcoin and also to some extent with Steem and others. This methodology sees zero forks and sub 1 second clearance, and a 1 minute max total time to 100% confirmation.
So, while I will use the more old-strategy replication protocol built into Tendermint, and its basecoin for the ledger, I intend that as quickly as possible we get to implementing these more advanced techniques.
I think that, to build an incentivised self-hosting development platform at the centre, first, enables us to more rapidly find and make use of developmennt talent, and ideally, even, so much so that we are taking from the pool of blockchain type development people because our rewards are better and more motivating than any deal a corporation could offer.
Between what you wrote and what the Whitepaper says, it seems that Steem is growing at 100% per year (based on the original vests held). 90% of that is re-distributed to content creators. So if I am correctly interpreting what I have read, the answer to my question is that if 1 person contributes posts the 1st year and 2 people contribute post in the 2nd year, then the reward pool has grown proportional to the number of contributors and the rewards will be about the same in each year. However, if the number of contributors outstrips the growth rate of Steem, then as the number of contributors grows, the rewards will be proportionately less for each contributor.
Without fully understanding your new ideas, it does sound like you are looking at building a superior system that will take advantage of all the best things available. Have you seen any interest from prospective developers yet?
The whitepaper has not been updated. The interest rate is now about 9.3% (issuance rate).
Yes, this problem of crowding of the pool has been an issue all the way along. This is partly why I have designed into DIV a contrary rate issuance that lowers issuance rate as user activity accelerates beyond a certain point, or in other words, reduces the pay rate when there is too many users to share out evenly, and vice versa, when there is not enough, the rate increases
This is designed to front-run the network utilisation so that where as it does here, in a lagging fashion at first everyone gets less and less when there is too many, and then with the excess tokens dumped on the market, the effective value of the earnings are reduced, after a period of congestion, and then causing a sharp drop-off in users, and this again causing a lagging reaction in the price.
By lowering the rewards as activity accelerates, it naturally will brake the activity before the excess supply hits the market, allowing the price to remain more stable, and vice versa, as activity slows, the rewards are suddenly a lot higher per capita, and this will naturally draw more users to compete for it (which will then slow the rate down). This, combined with zero liquid rewards, and a daily 1% drawdown, should see the outflows of capital dramatically much more stable than with Steem, which will make it much more attractive as an investment.
Without using a stupid hedged instrument, complicating the monetary system like is necessary with Steem, where VESTS have a rate against Steem and a rate against SBD, this will just have 1 token, and a deposit contract with a random interest payout with a transaction volume driven issuance rate for interest on the contract built from necessary change operations (this sounds like a mouthful, but it is based on the property-registry token model called Refractory Token Ledger). Initially, using basecoin it will not operate quite like this, but eventually this token will be phased out once the RTL is implemented, and converted (I haven't cooked up the scheme for this.
I hope that the combination of a monetisation system for peer reviewed code and documentation writing, and the clear advantages of the architecture, all derived from observing the operation of Steem, that indeed, there will be a flood of developers and what took a year for people to build for steem will be done in 3 months.
:)