Adjusting the economic model

[erikzhang]

Adjusting the economic model for gas distribution.

Agreed:

• Allow gas to use the decimal part when being used as sys_fee

Contentious:

• A small increase in the supply of gas every year
• Distributing GAS only to the voting NEO
• Reward consensus nodes

[igormcoelho]

This one I don't get the direction yet... any ideas brother @vncoelho?

[vncoelho]

A naice veri gud.
I think that is could be crossed in time, ma broda, not in terms of blocks. @lerider

If the generation is expected 8 GAS in terms of 15s it should be 0,54 per 1000ms.
We all know that the current code can run much fast block times. Thus, let just adapt/adjust the formula towards that.

In this sense, Ontology and other private blockchains could easily follow this formula and generate GAS accordingly. This would unify the price of gas across different blockchains ecosystems.
Haduken.

[deanpress]

One of NEO's main attracting powers was always that if decentralization would be introduced, consensus nodes can be run by parties without any direct incentives from transaction fees. Consensus nodes would benefit from other factors such as funding/exposure/contributing to ecosystem, and the blockchain fees would be distributed only to NEO holders (not consensus nodes). NEO holders would also be in control deciding over the blockchain's fees.

I'm sure there are many projects that will completely voluntarily maintain high performance consensus nodes, just for the sake of exposure and engagement with the NEO community.

I personally know many projects that are looking to engage with the NEO community who want to dedicate resources to improve the ecosystem.

The game theory behind this model is interesting and refreshing, and it hasn't had a chance to prove itself right or wrong yet, so why would there already be considerations to move to a fundamentally different economic model?

---

Additionally, if the economic model is moving to proof of x + infinite GAS supply, wouldn't it become more similar to Ethereum Casper except with more complexities due to dual-token model (which was not designed for this model) + centrally decided upon fee structure (instead of letting NEO holders vote)? What would be the remaining benefit relative to other platforms in terms of performance/fee ratio?

[ThomasLobker]

A small increase in the supply of gas every year

GAS should be a fixed supply and recycled based on usage. Like we have already. This is a very solid model.

Reward consensus nodes

This is called Network Fee and it's already part of NEO right? A small network fee would be a nice way for the consensus node to be rewarded. It would be nice though if you can still choose to pay no network fee for a low priority transaction.

Make neo divisible

NEO is already divisible by a factor 100,000,000. Why would anyone need smaller amounts of NEO which is a governing token? For payments we already have GAS which is a utility token. This two-token model with an non-divisible governing token is one of NEO's biggest charms.

Allow gas to use the decimal part when being used as sys_fee

That sounds like a good plan!

[erikzhang]

If the economic model is moving to proof of x + infinite GAS supply, wouldn't it become more similar to Ethereum Casper except with more complexities due to dual-token model (which was not designed for this model) + centrally decided upon fee structure (instead of letting NEO holders vote)?

GAS should be a fixed supply and recycled based on usage. Like we have already. This is a very solid model.

In the dual-token model, if neo enters a blackhole address, it causes all of the gas that this part of neo gets lost, and the process, like a real blackhole, will eventually devour all the gas.

[lerider]

A small increase in the supply of gas every year
Reward consensus nodes
I strongly oppose these. The economic model is built upon circulation in a closed system, aligning interest so that both users and CN's have the same motives. Allowing increase in GAS based on for example reward to CN's nodes will create a system where CN's main interest is of economic gain and not for the benefit of users. It will result in a consortium of CN's who manipulate GAS price for their own maximized profit. It may potentially give a short term spike in NEO price when people are hoarding voting power (see EOS), but once hoarding is complete, the CN's will gain most benefit from "stabilizing" the consortium and we are stuck with CN's that never change owner (unless they dump on purpose). There are already dozens of parties who want to carry the cost of a CN (around 500 USD a month) without direct economic gain; I do not see a reason to overhaul the whole economic model.

Make neo divisible
The only thing this would help is to allow distribution of smaller GAS fees. The small benefit does not justify the big risk forced upon token holders.

1. NEO is the governance token and GAS is the utility token. The characteristics of the tokens support this; if you want to fuel a contract with a system asset, then you use the utility token (GAS). This will increase demand on GAS token as the network usage increases, and in turn increase value of NEO when GAS is recycled. Allowing NEO to be divisible create a big risk that dApps choose to fuel themselves with NEO token instead. This may be negative in terms of token price for both NEO and GAS token; as GAS loses demand, the value decrease. As the recycling benefit decreases in value, NEO token may also lose value. This is my personal expectation, and I do not see the big risk for token holders justify the small benefit.
2. Even though high voting participation is beneficial, we would like to avoid random voting as much as possible. Allowing fractional NEO to vote (for reward) will give much power to wallet creators, as they will certainly implement a "vote standard" function (for their own nodes?) to make it easier to vote for users. People who are more invested will have more incentive to vote "properly", and keeping the NEO as indivisible is at least a small barrier for participation in voting (for good and bad).

Allow gas to use the decimal part when being used as sys_fee
I think the "decimal part" refers to decimal part of the NEO token when distributing GAS so that smaller fees can be accepted. I greatly support smaller fees, but think we should try to find another way to allow the recycling rather than making NEO divisible.

In summary, I do not support these changes. It has too much influence on the economic model and there is no reason big enough that justify these changes. Moreover, it has too much impact on both developers and token holders; it creates an uncertainty. Developers and token holders need to know what they can expect in the future, and this overhaul is too big without enough reason to do so.

My biggest objections are against increasing GAS supply and rewarding consensus nodes (more than they already are).

[erikzhang]

@lerider Please see my reason at #285 (comment)

[EdgeDLT]

I agree with @lerider that incentivizing consensus nodes & increasing GAS supply should not be implemented. It disturbs the closed economic model that NEO was created to serve. I also have qualms about divisible NEO, as this is detrimental to the value of GAS and use of a two-token model, although I understand that it is ideal for accessibility as NEO's price increases.

My suggestion about an improved voted mechanism using time-locked voting contracts may prove a useful solution to this issue. It also suggests approval voting, which should drastically reduce the risk of random voting whilst also minimizing the potential vote influence of centralized exchanges. It will also incentivize voting, and could prevent the risk of GAS being lost to a 'black hole' address as @erikzhang has described it, by only distributing some/all GAS to vote-locked NEO.

Please view my proposal here for more information. Review/discuss here.

[BehindYou27]

I strongly oppose these changes. In my opinion, divisible Neo is NOT needed and serves no noticeable reason.
In case you have a point to change this immediately, please point these out.

Gas-Inflation:

I’m not in favor of this at all. This would punish all gas-holders.
In addition (like Malcolm pointed out) CN’s don’t need the additional economical benefit. They will cover their expenses by transaction fees. This has to be enough to make it interesting for these parties.

To be completely candid: I don’t understand the reasoning behind these changes anyway. Neo is right now not that expensive that we would have a liquidity-issue.
Gas price is not that expensive that a inflation is needed to prevent holding.

Why change a running system?

Edit:
Regards the black hole of Gas:
Yes, in an infinite timeframe, this could and probably will happen. But until all Gas is lost, I don’t see a problem. A solution could be dynamic pricing of system fees.
I also really like the proposal of @Edgegasm.

[erikzhang]

@Edgegasm We don't need to worry about gas in the black hole address. But we do need to worry about neo in the black hole address. Because in the current economic model, the gas that is consumed will be given to neo holders. So gas will flow into the black hole address until all gas is gone.

[EdgeDLT]

@erikzhang If GAS is only distributed to voting participants (incentivizes voting), and we use a contract approach as my suggestion, GAS would never flow into a black hole NEO address. The NEO at that address would not ever be placed into a voting contract, so the address would not be eligible for GAS distribution.

As a result, lost NEO would only serve to lower the circulating supply & increase the value for other NEO holders.

[erikzhang]

If GAS is only distributed to voting participants (incentivizes voting), and we use a contract approach as my suggestion, GAS would never flow into a black hole NEO address.

Addresses that lose their private keys can also cause problems.

[EdgeDLT]

In what way? Without access to the private key, you wouldn't be able to send your NEO to the voting contract. Without voting, no GAS will be distributed to the address.

[erikzhang]

I sent neo to voting contract, and then lost private key. So I can never withdraw them back. Does this cause problems?

[ghost]

If neo can enter a black hole address and that causes a problem with the ecosystem, neo transactions should be reversible so they cannot be blackholed.

[EdgeDLT]

That would depend on whether the contract required users to personally withdraw their funds, or whether funds are automatically returned to the holder after the voting period has concluded (after a specific duration/block). I'd suggest the second option is ideal for simplicity, so time-locked contracts.

This would place the NEO back at their origin address (along with the GAS distributed from that voting period), but it would not affect any subsequent voting periods. Each voting period is unique; GAS is distributed only when a wallet participates. Of course we can't do anything about a user losing their private key, but we can prevent it having a negative impact on the rest of the system. If it's not possible to have NEO automatically returned after the voting period (if users must manually withdraw), then the NEO will remain lost in a dead contract (burned).

The end result is the same; losing your private key will mean losing access to your NEO, and the NEO in the contract cannot have any negative effects on the system.

[BehindYou27]

@erikzhang

Can you point out what exactly will be the problem if Gas is locked up in dead wallets?
Is it only the appreciation of Gas?

On what bases would you like to have the inflation?
Some random number like EOS has? A calculated inflation?

There is one thing I could get behind: If the Gas is redistributed to the holders/voters. But it can’t be a random number. I’d propose that the lost gas has to be calculated over a long time. Maybe 22 years after the genesis block.
So you would have to check what wallets didn’t touch the generated gas for 22 years and add this to the Gas-distribution.

The longer the timeframe, the more secure this system becomes for holders.

I still won’t like it but I could deal with it. That would mean in case someone would regain access to the gas that was locked up for 22 years in their wallet, the additional distribution would stop until we have less than 100 Million gas in realistic supply

_{Sent with GitHawk}

[t-ant8]

@lerider @deanpress I think, rewarding consensus nodes was planned from the beginning if I remember correctly. It was written in the first Antshares whitepaper (CN were called "book-keeper" nodes).

I think GAS-incentive makes it more attractive for large businesses (such as KPN) to run a CN node. In the end, running CN is just business for coorporates (IMO)

[EdgeDLT]

@t-ant8 Rewarding consensus nodes was only intended to be done using transaction fees, with the idea that we can keep them low if not zero by competition for the right to participate in consensus.

Goodwill with the NEO community is incentive enough in a lot of cases.

[erikzhang]

@Edgegasm Can you put your solution in a separate issue?

[EdgeDLT]

@erikzhang It's currently up as a NEP pull request. Would you like me to post it as an issue instead?

[erikzhang]

It's currently up as a NEP pull request. Would you like me to post it as an issue instead?

Yes, please post it as an issue so that we can discuss it in the context of NEO 3.0

[BehindYou27]

Hi @t-ant8

But what would be the reason behind this? I don’t think that we will have problems to find enough CNs that are willing to spend this money to run a node.

So we could decide if they get a Gas-Incentive to run it, which would effectively take away value from every gas-holder due to increased supply

Or

CN’s will try to make it efficient by having transaction fees. This would take away gas from people that are using the system.

Which one is fairer?

I know what I think.

_{Sent with GitHawk}

[EdgeDLT]

@erikzhang Issue opened for discussion here.

[erikzhang]

In fact, I don't like to increase gas supply either. If the problem of black hole addresses can be solved, there is no reason to do so.

[EdgeDLT]

Indeed, one of the most widely disliked parts about FIAT currency is inflation. It should be avoided at all costs.

[t-ant8]

@BehindYou27 Please don't get me wrong. I do not support the GAS-inflation idea. If too many GAS are stuck in black hole addresses (if that ever happens) then the pricing model could be adapted. GAS are lost just same as NEO are lost over time.

Concerning "reward CN": Maybe I understood it wrong, but when I read "rewarding CN" I thought it's meant to be the transaction fees which go Consensus nodes, or is it something else? (not increased amount of GAS, just a redistribution)

[EdgeDLT]

@t-ant8 Transaction fees (if enabled) go to CNs. System fees (contract deployment etc) are redistributed to NEO holders.

[vncoelho]

Hi @erikzhang, could you update the post with the ideas more related to the current discussions?

According to our recent meetings with communities and developer, I believe that we most are not supporting:

• Increasing GAS supply
• Make NEO divisible

Thus, the proposal could be kept to:

• Allow gas to use the decimal part when being used as sys_fee
• Distributing GAS only to the voting NEO (maybe)
• Reward consensus nodes (maybe)

[EdgeDLT]

I'm not sure how we can reward consensus nodes without increasing GAS supply. We shouldn't keep letting them take transaction fees, this is a flawed model. It incentivizes the consensus node to drive up transaction fees (e.g. filling free transaction slots in blocks with spam transactions to force users to pay network fees).

[vncoelho]

@EdgeDLT, I still believe in the initial idea that those maintaining the consensus are those interested in running it. Surely, there are many.
In addition, more can come, for example, Universities using Smart Contracts services.
Thus, from my perspective, I do not really think that rewarding consensus node is a necessary mechanism.

[ghost]

@vncoelho your comment is a better phrasing, so i discarded my comment.

[ThomasLobker]

I'm not sure how we can reward consensus nodes without increasing GAS supply.

Each block unlocks 7 GAS at the moment. We could technically let a consensus node take a part of that? But I personally like that idea that the incentive for a consensus node is not directly to make money. Run a consensus node if you have a stake in the network, or just want to sponsor the network.

[EdgeDLT]

I agree @vncoelho, running a NEO consensus node can be its own reward. In a decentralized world, I can imagine reputation goes a long way. Helping safeguard and maintain the blockchain is a good way to build a strong relationship with that network's users (and the market).

[toghrulmaharram]

Hey guys, just popped by to express my opinion. I believe that the approach to the consensus and the cryptoeconomics of the protocol is a bit skewed at the moment. The voting mechanism is yet to be designed and the underlying Proof-of-Stake protocol has no formal proofs (for example, the current iteration of dBFT is vulnerable to "long-range" attacks). I would start by formalizing the voting mechanism, followed by the definition of the Proof-of-Stake and ending with the incorporation of the aforementioned proofs into the dBFT formal proof. Only then you would be able to formalize the cryptoeconomics of the protocol, as otherwise, you're playing a guessing game.

Also, I vehemently disagree with an idea that the consensus nodes should not be monetarily incentivized as this contradicts the game theoretic assumptions of any given economic model, as well as being pro-plutocracy.

I apologize for having no time on my hand to make any concrete input, but I hope that my opinion helps.

[PBSJ]

@vncoelho - when you say "increasing GAS supply" are you talking about introducing an inflationary model?

Would be curious to explore the pros and cons of that.

One pro would be that there would be an incentive to spend GAS.

One con is that it would support the status quo of eternal growth (which, however, may be exactly what is intended for NEO)

Afterthought: perhaps if the inflation rate can be gauged shrewdly then the level of growth could be ultimately sustainable within the limits of our planetary resources. But that would be tricky to judge at this point in time and so the inflation rate would need to be adjustable to allow for future corrections. But that then begs the question: how could the adjustment be decentralised?

[EdgeDLT]

Hey @toghrulmaharramov, good to see you. Could you explain your thoughts on this part for me?

as well as being pro-plutocracy.

I'm not sure how this can be true. Maybe from the perspective that those without funds to operate nodes can't break even, so there's a barrier to entry for noderunners?

We have seen PoS networks where validators receive large incentives for their participation. Since those awarded tokens are also used to vote in these networks, it seems logical to say that this act leads to plutocracy. The longer you are a node, the more voting power you gain to consolidate your rule. Naturally, this would result in cartels.

So, I'm not quite sure why the inverse could be true. Can you correct my thinking here if you have time?

[toghrulmaharram]

Hey @EdgeDLT.

Lack of incentivizations for running a node leads to a decreased number of users being able to afford to run the nodes and plutocracy as a result. Apart from that, the probability of various "bribery" attacks increases when the protocol does not include any incentivization mechanisms. Finally, the security assumptions will have to explicitly define non-Byzantine replicas as honest users rather than economically rational users.

No need to retain the same consensus committees for prolonged epochs, a much better idea is to create medium-length epochs and pseudo-randomly shuffle the committees every epoch (e.g. using Algorand-like VRF sortition or Snow White-like hash extraction).

[EdgeDLT]

Lack of incentivizations for running a node leads to a decreased number of users being able to afford to run the nodes and plutocracy as a result.

From what I figure about how many consensus nodes we will actually have, is this really an issue? The bare minimum cost for running and safeguarding a consensus node doesn't seem so insurmountable. I suppose that would change over time with chain size though.

The real risk of plutocracy really stems from the token distribution, which can't be easily prevented unless we end up all voting through digital identities in a fully digital democracy.

Apart from that, the probability of various "bribery" attacks increases when the protocol does not include any incentivization mechanisms.

Seems like those incentivization mechanisms are the bribery attacks. Example, EOS BPs, Bitcoin/Ethereum pools, etc. Incentive causes centralization. People are always going to follow the money, and those who are best equipped to do so will reap the most rewards.

I think it is better to detach this pursuit of incentive from block validation entirely. It would be much more interesting (and productive) to find a way to incentivize peers!

No need to retain the same consensus committees for prolonged epochs

Agree with you there, I suppose it would allow us to increase our number of nodes.

[vncoelho]

@toghrulmaharramov, it is great to see you here again! :)

Tog, we have been investigating consensus intensively, but I still believe that the current design is quite adequate.
I do not like these ideas of shuffle and dividing the committees. Before doing so, I believe that we should explore more the possibilities of sharding and how the current design can be extended.

The main advantage of the dBFT is its simplicity, being (maybe) the only yet working consensus with 1 block finality able to support f faulty nodes. As you known, it inspired on the pBFT and has a precisely done design for achieving all needs.

About the voting: Voting are working since NEO 2.x early versions and they are a key change on the Delegated strategy. NEO holders have the potential of eliminating CN that do not correspond to the desired needs.
We are currently doing a short-movie for didactically introducing the current system.

[toghrulmaharram]

@EdgeDLT The costs of running the node will increase as the blockchain size increases. For example, Ethereum archival node sizes have already exceeded 1 TB.

Regarding the token distribution, as long as the reward model is designed in a way to incentivize rather than enrich the consensus participants (let's say you get an average annual return of 20% from running a consensus node), the outcome of such a model is highly unlikely to lead to a plutocratic system.

No, an example of a bribery attack would be a "long-range" attack, which EOS and Bitcoin are statistically and probabilistically resistant to respectively. Also, NEO is far more centralized than EOS, let alone Bitcoin/Ethereum (while the mining pool argument is a valid one, the permission-less nature of Proof-of-Work algorithms enables the "honest" (a loose definition in this case) participants of the mining pool to stop contributing their hashrate to the pool).

[toghrulmaharram]

@vncoelho good to hear from you!

The issue is not in the design of the consensus protocol (though there's still room for improvement there, in my opinion), but in the design (or precisely lack thereof) of the underlying Proof-of-Stake protocol. From what I've seen in the Ethereum camp, we're still some time away from a viable sharding proposition (OmniLedger guys might want to argue with that), whereas committee shuffling techniques and reputation modules are already gaining widespread use (including in my own work).

Actually, that is not the case. Algorand and HoneyBadgerBFT have 1 block finality while being able to preserve liveliness and consistency under f Byzantine replicas (though Algorand's fault-tolerance depends on the predefined parameters), as well as DFinity having 2 block finality under f Byzantine replicas. You could also add Tendermint and Hyperledger Fabric to the list.

The issue with the current voting system is that does nothing to improve on the issues that were discussed almost a year ago, which is what I meant when saying that the voting mechanism is yet to be designed (the one currently in use is a trivial one, with all due respect).

[vncoelho]

@toghrulmaharramov, I understand your point, really.
I also would like to make it clear that I am not criticizing Ethereum (I just bought some more these days ago. I think that have their camp and a brilliant future as well), but I would like to say that we are strictly following Istanbul.
I should say that, from my limited perspective, we are currently the pioneers regarding a "PoS" consensus. It was not easy to reach an stable consensus as we have nowadays and preserve 1 block finality, @erikzhang has been as mastermind and a good team has been cooperating for making what we current have reality.
I prefer to see everything just as a multi-agent system in which we should reach consensus.

In this sense, I prefer to leave these other aforementioned projects conduct their own vision. Thus, I strongly motivate all NEO contributors to keep contributing with our current vision, small, simply but efficient and working in practice.

[toghrulmaharram]

@vncoelho A very arguable point regarding "pioneering". If you're talking about the generalized Proof-of-Stake consensus protocols, then Snow White and Ouroboros are way ahead simply because they are the only ones to have complete formal proofs (near-complete in case of Ouroboros and Ouroboros Praos). Unfortunately, both of those belong to a family of chain-based Proof-of-Stake protocols, rather than the family of BFT-based Proof-of-Stake protocols to which dBFT belongs (funnily enough, dBFT resembles SpinningBFT much more than it does PBFT, but I'll leave that argument for another day). Algorand have managed to create the first (what else do you expect when you have Turing Prize-winning Silvio Micali heading the research of the consensus protocol?) permission-less Proof-of-Stake protocol with instant finality while HoneyBadgerBFT is the first efficient asynchronous protocol with instant finality, while protocols such as LinBFT make use of threshold and BLS signatures to create two-phase protocols based on classic BFT (with no accidental forking, unlike dBFT 1.0), so I'm not sure what part of the Proof-of-Stake is NEO pioneering (especially considering the fact that the underlying Proof-of-Stake protocol of dBFT has no formal proofs whatsoever).

[vncoelho]

I will take a lot in the projects you mentioned, @toghrulmaharramov.
As always, you always instigate good discussions.

Turing Prize-winning Barbara Liskov is also one of the heading researchers of pBFT.

HoneyBadger is still a big question to me.
pBFT and HoneyBadger are articles that we read and discussed several times. The question between asynchronous and partially synchronous is an interesting discussion that I believe we gonna see splits in the literature for some more time.

I suggest these readings here:

• Scalable Byzantine Consensus via Hardware-assisted Secret Sharing, Jian Liu, Wenting Li,Ghassan O. Karame, Member, IEEE, and N. Asokan, Fellow, IEEE
• BEAT: Asynchronous BFT Made Practical
• Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults

[toghrulmaharram]

@vncoelho not arguing with the fact that PBFT was revolutionary in 1999, however, it was designed for a different use case and with different computational power in mind (hence why the original paper proposed using MACs instead digital signatures).

In my opinion, HoneyBadger is a sound protocol with the only downside being the threshold signature scheme used and requirement of a relatively stable committee as a result (hence why it is permissioned).

Thanks for the suggestion, read all three of those papers. :D

[vncoelho]

I see your point, Tog.
Science is made everyday...aehuaheau 👍
I consider that the best and pioneer adjustment of the pBFT for consensus in Blockchain scenario is NEO dBFT, this is what I mentioned.

However, I still believe that other ones can still be good (or even better). But they still did not convinced us (and we did not have time to explore these research directions. Science is also a bet. I believe NEO is betting on something solid. We should be open for the future.).

[shargon]

We should add a multiply factor inside policy native contract (1 by default). This could allow us to reduce the price without make a new release if the price go "to the moon"

[vncoelho]

Sounds interesting, @shargon, you mean a variable just for CN to increase (multiplying fees) for a given period?
I believe that we could even set another variable for limit this multiply until X number of blocks.

[lock9]

We should add a multiply factor inside policy native contract (1 by default). This could allow us to reduce the price without make a new release if the price go "to the moon"

I think this is a great idea, I created an issue for you

[erikzhang]

@shargon Are you talking about sys_fee or net_fee?