You are viewing a single comment's thread from:

RE: Future optimizations (speculation)

in HiveDevs2 years ago

Very much enjoyed reading, thanks for taking the time to share all these future possibilities.

It seems to me that decentralization will have a much larger importance than scalability. We can always reduce our usage of the blockchain by keeping it only for things of high social importance, and we can find temporary storage elsewhere and put only the high-level summary of it on the blockchain. If we implement optimizations that sacrifice any aspect of decentralization, for the sake of improved efficiency, it seems like a huge net loss to me. Design improvements that increase both efficiency and decentralization (e.g. by making it less expensive to run a node) seem like what we'd want to pursue, and I think you had a variety of them.

Another point. There is an effect that has been studied, where making optimizations to a resource so as to make it more affordable and available leads to a highly increased usage and squandering of that resource. As we make the blockchain a more and more available resource, perhaps we have to equally protect it from being squandered by all sorts of meaningless bots and similar, which can completely negate the gains of optimization and thus make the blockchain not affordable to the common folk. Let us learn from this past experience which engineers have encountered for centuries. Here is a quote from the book "Energy and the Wealth of Nations: An Introduction to Biophysical Economics":

We are besieged nearly daily by many different "green" plans that promise, usually through some kind of technology or improvement in efficiency, sustainability, or at least progress in that direction. There is a certain logic and appeal of such plans because they offer indefinite "sustainability" with less impact on the Earth or the supplies of its critical resources.

Unfortunately, we believe that most such technologies are in fact counterproductive because of some manifestation of Jevons' paradox. Stanley Jevons originally believed that given the ultimate depletion of England's coal it was necessary to make the machines that used it more efficient. [24] But, in fact, he found that in the past such efficiency improvements made the use of steam engines cheaper so that more uses were found for them and technical changes designed to save coal actually ended up causing more coal to be used. More recent examples are that more efficient automobiles have led to more miles driven, more efficient refrigerators to larger refrigerators, more insulation to larger houses, and so on. Even cheap solar energy, should that be obtainable, allow the continued exacerbation of all the global problems given in Figs. 23.4 and 23.5. While we do think that efficiency improvements of many sorts certainly do have their place, they must be implemented within the context of constraints of total use, or they are likely to be counterproductive.
Sort:  

I wrote about possible optimizations because I think we have to be proactive in that field. For example recently I've heard about the idea to introduce custom authorizations (like in EOS). Such customization is great and really useful, however it introduces potential source of a lot of long term memory consumption, so we need to reduce current usage in order to make space for new feature. Also, let's say someone comes to Hive and says "I have a service that will bring 10 million new users with it." We should be ready to answer "Not a problem" rather than "That's tough. We need a year to fix our code so we can accommodate that many users."

I understand the concerns about making resources more affordable that could lead to their wasteful overuse for activity that does not bring value. But we are using RC to express "cost" of those resources. As flawed as that system is, making code consume less real life resources does not automatically mean it will be reflected with lesser RC cost.

I can't disagree more with the quote on efficiency being counterproductive. It is only counterproductive to the narrow goal of making people consume less resources. I think the opposite is true. Only cheap resources can be wasted, the damage is especially evident when those resources are subsidized, precisely because in such environment there is no need to invest in efficiency. However when you are making some process more efficient, you free scarce resources to be used elsewhere, providing opportunity to spark more innovation, more productivity, more value for the same cost. And yes, that leads to even more resources being consumed. But that is natural. People will want to consume more and will strive towards goal of being able to afford more consumption - efficiency is one of the means to achieve that goal. Trying to artificially limit people in that field is to go against human nature and is doomed to failure. :o)

Thanks for replying, and I certainly appreciate that you write and think about optimizations to make, they are absolutely needed.

As flawed as that system is, making code consume less real life resources does not automatically mean it will be reflected with lesser RC cost.

Great to hear.

I can't disagree more with the quote on efficiency being counterproductive.

Perhaps we understood it differently. I don't think the goal is to make people consume less resources. Let's take plastic bags (and all sorts of plastic wrappings) as an example. In previous times, people used re-usable containers for things, the containers lasted a long time and people would bring home beverages and all sorts of other things in those containers, then clean them and re-use them. With greater efficiency, plastic bags became ultra cheap, and that led to people buying them, using once and throwing them away, which has resulted in unimaginable pollution and loss of wildlife. People were not drinking and eating less before, when they used containers. It was just a re-usable more expensive container, whereas later there were ultra cheap throwaway bags.

As you are saying that efficiency gains won't necessarily result in cheaper RC costs, maybe we are good. I just thought it was an important point to mention. I do want millions (and eventually billions) of people to freely use our blockchain, and I don't want it to be clogged up by bots with bad intentions (like the commons typically can be ruined by people who don't care about others), and I don't want abuse to make it more difficult to scale and remain affordable such that we'd have to choose between scalability and decentralization. But if none of this is a problem, then great.