RE: Understanding SMT Features
Technically nothing is really changing about STEEM. I think the real answer to your question lies in Resource Credits. I don't think people really appreciate how much Resource Credits fundamentally altered Steem (for the better). RCs essentially guarantee that no matter what anyone does on the Steem blockchain, it benefits all Steem stakeholders. This is slightly simplistic, but essentially the more transactions people perform on Steem, the more RCs are consumed, and the more STEEM needs to be powered up in the aggregate. The RC algorithm ensures that the increase in demand for STEEM won't suddenly deprive people of the ability to transact, and it smooths out the user experience. So the short answer to your question is that STEEM continues doing what it does now; it regulates the consumption of network resources by ensuring that only those who have staked sufficient STEEM are capable of performing transactions. The beauty of this system is that it simplifies our task as a community: create more ways for people to have amazing experiences on Steem. SMTs are just another way of enabling people to have more delightful transactions on Steem.
Thanks for the answer, Andrew.
I guess for the value of STEEM it all comes down to whether we can find enough people, businesses and communities that want to use the network and are willing to pay for it by staking/leasing STEEM.
That leads to one more question I have wanting to ask for a while.
When all the work surrounding SMT's and communities are complete and the features are live. Is finding businesses that want to use these awesome tools something Steem Inc. will pursue or will the focus be on more blockchain development and steemit.com or maybe a combination of both?
This is something we're already doing and would like to do more of. This falls on the non-engineering members of the team and the engineers would still be focused on their products. If anyone has any leads, they can feel free to e-mail me at [email protected]. There's lots more work to be done on Hivemind, SMTs, and Steem core. I expect both Hivemind and SMTs to continue to receive updates for as long as Steem is update-able. As the market discovers new use cases for cryptocurrencies, the features that enable those use cases should be added to the SMT protocol. The potential for Hivemind is unlimited and it can continue to be updated even if Steem were to become un-update-able for whatever reason. This is only one of the reasons why I think Hivemind may be the most potentially disruptive piece of software we've released.
Also, what's your short answer to rumors that Steem shouldn't be the reward token for curators and authors but give space to SMT's to do that?
These aren't rumors as much as one potential option for the future. It's certainly not going to be part of the SMT hardfork (or at least that is highly unlikely). But as far as whether it is included in a future hardfork, that will depend entirely on what the community comes to a consensus on.
The staff seems to be intentionally skirting that question, which might mean that they are considering the idea but don't want to commit to a path on that.
That can be smarter than coming out and saying yes or no on it. If Steem removed the reward pool and SMTs don't perform well the chain is likely going to take such a hard hit to its reputation that it might never recover. On the other hand, if SMTs perform very well, and it seems like removing the STEEM reward pool is a viable path, then it could be a good thing.
Long term, Steem likely needs to remove the reward pool, but doing it too soon can be dangerous.
The reward pool is one of the reasons that the steem blockchain is somewhat less vulnerable to the potential degradation that any DPOS chain can suffer as a result of vote incentivization from blockproducers. That is one of the reasons why I am opposed to eliminating it. @anyx doesn't specifically mention that in his analysis but I think it's a logical conclusion.
https://steempeak.com/dpos/@anyx/how-vote-incentivization-monopolizes-delegated-proof-of-stake
I probably would be ok with a reduction in the percentage that goes to the reward pool but not with eliminating it.
Interesting, but how does it protect against vote monopolization? Also, alternatively, we could solve that problem simply by making witnesses stake STEEM with the potential for it being slashed. DPoS was brilliant in a world where slashed stake did not exist, but at this point in time it might be good for us to take a second look at the witness system and adjust it.
If we changed the witness system we would not need STEEM inflation for posting. Right now we have a system where the top 20 produce blocks and 1 random witness produces blocks but perhaps we could increase the number of random witnesses selected. This could improve decentralization and make the system much more secure against vote monopolization.
In other DPOS chains the majority (if not all) of the inflation goes to the block producers. By offering kickbacks they can ensure that the stake that votes for them grows much faster than the one that does not.
Steem distributes the majority of the inflation to none witnesses thus the block producers have little incentive to offer kickbacks to their voters. After all they need to maintain their infrastructure and the witness pay does not leave much room for such deals (they only get 10% of the inflation).
This does not mean that steem is not vulnerable to such degradation of consensus. It just means that it would take a longer time to playout.
Fair enough, but the risk could also be mitigated by relocating the author/curator/commentor rewards to interest rewards. Currently, author/curator rewards takes up about 72% of the inflation with staked interest at 16.8% and witnesses at 11.2% of the inflation pool.
By cutting the author/curator inflation in half, you could have 35% of it remaining and relocated mostly to interest. If 10% went to witnesses and 25% went to staked interest with 37% eliminated, you could keep staked voters in control while making the witness role more lucrative and thus more secure and competitive.
That would mean interest would receive 41.8% of current inflation while witnesses receive 21.2% of current inflation and a cut in total inflation of 37%. Staking for interest, SP and RC delegations could prove more lucrative for stakers, potentially resulting in an increased demand for the supply.
Reducing or eliminating the posting rewards in favor of staking for interest or RC delegations is not out of the question. However, let's suppose that one or several SMTs are succesful.Wouldn't it prove to be more logical to port that model to steem instead of eliminating the rewards pool? We may need to eliminate the ditribution of steem to content creators sometime in the future but I don't see that happening unless we have something to take it's place.
I don't think it would be for the best. I believe many of us are beginning to see that the POB system is best made for small communities and not as an all-purpose voting system. As a previous Steemit blog article brought up, it is not fair to subject art communities to the stake-weighted voting of a whale that does not appreciate art, while an all-purpose stake-weighted system does this.
Let me put it another way, frequently the people interested in something like a stake-weighted curation system leveraging crypto would be crypto investors. In the case of Bitcoin fans, a very large amount of these members are red meat eating capitalists that might not value vegan recipes. In this case, it would be better if we could separate the vegan fans from the steak-loving capitalists that are only interested in curating moonboy predictions. So, the main solution to this problem is to allow for many smaller, sovereign POB systems.
Does the 'price' of resource credits change with changes in activity levels?
No, RCs have no price
Sure, perhaps I should word that differently. It takes a certain amount of resource credits to perform functions on the steem blockchain, and it takes a certain amount of steem power (SP) to have 'enough' resource credits in order to perform said functions, so my question is, does the amount of SP required to perform the same function change with changes in activity/usage? IE will it ever require more or less SP to perform the same functions as it does right now?
Yes, it is dynamic according to usage.
Will we be able to delegate/lease Resource Credits?
Yes, Resource Credit delegation pools are in the SMT code currently on testnet :)
Awesome 🤘😝
Posted using Partiko iOS
Right?