Are you aware of the fact, that the bp cartel

is one of the biggest criticism of EOS, Luka?

Figured it out, yet? 😜 What do we have to do to inspire and encourage you and a band of mad engineers to architect the evolution of dPoS?

I certainly haven’t figured it out. I think the only way one would even know if they figured it out is if some change was put into practice and we observed that it achieved better results according to whatever metrics were pre-agreed upon by the community as important. As it stands, it’s not clear there is even consensus on what are the clearly measurable objective metrics the EOS community would like to see improved in governance. It is all so hand-wavy and subjective, allowing those who want to be negative to be remain negative and FUD and those who like the status quo to say it is working fine. I do personally think things can improve, but I also don’t think the actual functioning of EOS governance is hindering anything important that I would consider it a major priority to “fix” compared to so many other things that are critical priorities to address ASAP (which are being taken on now by various people/teams funded by the ENF and/or the EOSIO+ coalition). That said the perception of governance deficiencies by the wider crypto community may be more of an issue (as opposed to the reality of the governance). But when it comes to matters of perception and marketing, I’m really not sure what would work anyway. Personally, based on some analysis of the economic incentives but mostly just intuition, I do think the EOS consensus mechanism needs to be a little more like other traditional PoS systems at least in the sense of having time-locked funds to give influence (in a one token one vote manner) over finalization of blocks and for those locked funds to come with the risk of slashing due to act of confirming conflicting blocks (whether delegated in a staking pool or not). The lack of this structure has not been an actual issue for EOS so far (in terms of causing finality violations), but I would love to see the set of block finalizers grow (partially for added security and partially as a way to combat the negative perception of the EOS consensus mechanism by others) which may necessitate strong protections than relying on a smaller number of BPs who care about their reputation. That said, I believe it is still valuable to have a smaller selected subset of block proposers who would be given the same block production powers of today’s block producers (though not necessarily the msig powers), and these could be selected through alternative stake based mechanisms (such as approval voting) as well potentially hybrid methods that involve non-stake based preference aggregation. One option would be to select a committee through a combination of stake-weighted voting and something more democratic like an Eden style election (assuming it shows it can remain Sybil resilient even as the stakes increase). There would also be a set of block finalizers who get into their role as block finalizers simply by locking a sufficient number of tokens. Then the committee can simply select a subset of the block finalizers who meet certain additional requirements to be trusted with the additional powers of block proposers. However, the msig powers would not lie with the block finalizers or block proposers, it instead would only be held by the committee. Anyway, those were just thoughts circulating in my head when I like to spend some time thinking about this sort of stuff. To be clear, there is no current effort (that I know of) to actually officially brainstorm and take on designs like this.

making stake exchange pools onchain would be a good start

In my idea above, there would be an on-chain mechanism to pool your stake to be a block finalizer, and that mechanism would also encumber your stake with the pool operators actions. So if the pool operator violates slashing conditions, your stake is also slashed.

i am talking about people who don't run their bp

"Then the committee can simply select a subset of the block finalizers who meet certain additional requirements to be trusted with the additional powers of block proposers." That's where myvoteeos.com kicks in. To serve as a self-regulatory body for block producer/finalizers(?), keeping them accountable by actual human beings monitoring actual human beings who operate BPs.

I think the key thing is to figure out what is it that should be monitored for each of the different roles, how objective can that be (some roles will be inherently objective), and who is empowered with the influence to contribute their judgment on the performance of the actors within these roles. So, a block finalizer has a very simple role. They need to finalize valid branches of the blockchain in a reasonable time without finalizing two conflicting blocks. We could automate detection of two finalized conflicting blocks in users' clients and can have contracts objectively evaluate whether two conflicting blocks were confirmed by the same block finalizer and if so to then punish that block finalizer in some pre-agreed upon way. We can even monitor who contributed towards finalization in the recent blocks of a finalized branch and use that as a mechanism to deliver rewards for the job of block finalization. There is still subjectivity in determining whether a block finalizer is confirming blocks in a "reasonable time". But that is a very limited form of subjectivity. So given how objective and automated the role of block finalizer can be, I think it can be reasonable to require a mechanistic way to determine whether someone is eligible to be a block finalizer. The economic incentives should be aligned though since block finalizers can collude to carry out a blockchain revision attack for profit (e.g. via a double spend attack). That is where time-locked staking and slashing comes in. To compensate for the liquidity and slashing risk, it makes sense to provide a return proportional to the locked up stake over time. Block proposers involve a lot more subjectivity in evaluating the performance of their job. They also have additional powers that it may not be wise to give to just anyone without a good reputation as determined by the aggregation of preferences by a broad base of users that have an interest in the health of the network. Block proposers can selectively censor transactions; it is true that if enough block finalizers collude, they can also hold the chain hostage by blocking finality advancement until they get their way, but this is a very visible, overt action they are unlikely to take (out of risk of being forked out), whereas block proposers can censor in covert ways and at least to some extent have plausible deniability to hide behind as an explanation for why certain users' transactions are not getting onto the blockchain. Block proposers can also play other subtle games like reordering transactions in their pending block to their economic advantage (e.g. front running). Finally, in EOSIO specifically, due to subjective billing, block proposers also act as oracles for the official CPU costs of a transaction (though that can be bounded above to a reasonable limit by the transaction author). It is difficult to monitor the choices made by the block proposers regarding these matters of possible selective censorship and malicious transaction reordering, or of unfair deviations of CPU bill from what it was reasonably expected to be. And it is not feasible to have the judgment of these be automated into protocol code. So given the more subjective nature of the role of block proposers, I think it makes sense for them to be selected based on reputation by a mechanism aggregating preferences from parties that ultimately are (hopefully) aligned with the interests of the network, particularly as it relates to this limited scope of: fair CPU billing, no censorship of transactions other than due to pre-agreed upon resource availability rules, and no special logic to order transactions in a block other than due to node arrival time and pre-agreed upon resource availability rules (effectively a principle analogous to net neutrality for the blockchains). But even with this limited scope, there will already be significant disagreement on who should have the influence and how their preferences for block proposer selection should be aggregated.

Finally, we have the entities that are empowered to collectively make decisions about the chain. This can get very fine-grained and sophisticated, but for now let's assume that all chain-level governance decisions are made by a two-thirds super-majority of equal-weighted participants in something I will call the committee. In EOS as it stands now, the block finalizer set is equivalent to the block proposer set which is equivalent to the committee set. But there is no reason it needs to be this way; and, there may be benefits in separating these roles out. Regardless, there is a need for a committee that at least has the powers to deploy upgrades to system-managed contracts (e.g. the contract on the eosio account, or the eosio.token contract), as well as to trigger activation of consensus protocol upgrades built into the node software. It is a matter of debate whether this committee should take on more responsibilities than this (e.g. helping with recovery of stolen funds, directing inflation funds, etc.). Some think that even deploying upgrades to system-managed contracts should require each node to opt-in to the change in order to follow along that branch of the blockchain (thus making each of those contract deployments hard forking changes); I have written about the mechanisms for how that could work at https://forums.eoscommunity.org/t/idea-mechanisms-to-address-concerns-regarding-ease-with-which-changes-can-be-made-on-general-programmable-blockchains-like-eosio/2587/2. Because this committee can potentially be trusted with enormous power over the chain and the nature of their decisions are extremely subjective (do they accept an upgrade/change or not, do they act to combat an "attacker" or not, do they change the inflation rate and where is that inflation directed, etc.), there is even stronger debate over who is given the influence to pick this committee and through what mechanism (or in fact whether this committee should even be given this power in the first place). My interest as it relates to governance at this time is more focused on advocating for a separation of those three roles and providing mechanisms in the code to allow both more flexibility in the changes the committee can execute without requiring a consensus protocol change (aka hard forking change) as well as more restrictions (if desired) in what the committee can do (e.g. making it so that updates to a special list of privileged system-managed contracts require the nodes to explicitly opt-in to the change by adding a hash representing that particular change into their config.ini file). I am also a bit opinionated in that I believe the block proposers should be selected from the set of block finalizers through a consensus decision by the committee, and I have specific ideas for how the economics should work for staking to become a block finalizer. But I don't really have much of a view on what is the best way to select the committee in the first place. I just believe that the goal should be to select the committee in a manner that aligns their interests to the benefit of the overall network and their users (which I admit is completely hand-wavy and isn't saying much).

I'd be a lucky man to have half this vision and intellect. Thank you for the insightful words.

trying to follow along. what's the size of block finalizer set. is it that anyone plug their machine and stake tokens to be part of finalizer set? thanks.

you register then ask stake exchange pools to include you in their proxies

are stake exchange pools equivalent to current day proxy?

They way I imagine it, it would be configurable in a few different ways. For example, there could be a minimum EOS amount (M) that must be staked towards a particular block finalizer candidate for them to even be considered. But there could also be a cap on the total number of block finalizers (C). Then the system could select as the block finalizer set the top N (<= C) block finalizer candidates ranked by the amount they have staked towards them, where N would be strictly less than C in the case where the tokens staked towards the (N+1)th block finalizer candidate is less than M. Each member of the block finalizer set would be given a weight (to be used as part of the finalization consensus) that is roughly proportional to the amount they have staked towards them (rounded down to whatever granularity is supported). Stake rewards directed towards a staker behind a block finalizer would be proportional to the amount that they have staked towards that block finalizer, but they would only receive those rewards if the block finalizer had recently contributing towards finalizing blocks. And yes there would be a pooling aspect in which many different stakers could stake towards a block finalizers such that their aggregate stake is what counts towards the ranking and selection process described above.

And I think it would be wise to have a periodic refresh transaction (maybe once every few days) to reaffirm a staker's existing stake delegations. (This would just be as a safeguard to act as an automatic vote of no confidence in case of capture and censorship by the set of block finalizers.) So a program could run on the staker's machine to do this (though it could also easily be done manually as well). But that is the extent to which the staker needs to do anything after setting up the staking. They wouldn't need to actually run nodeos themselves. The actual registered block finalizers would of course need to run nodeos with appropriate finalization plugins and take part of the time-sensitive finalization consensus process. But these would be akin to staking pool operators, not the members of the pool.

the refresh can easily be outsourced, so why have it?

I'm trying to better model the nice property of PoW where even if the mining pool operators are censoring the blockchain, you can still switch which mining pool you delegate your hash power to (since that is an action that lives outside of the blockchain). But with PoS, the mechanism you use to switch your delegation is a transaction to the blockchain which could be censored. So having a sort of dead-mans-switch (not where the person is actually dead, but where their delegation change transactions are being selectively censored) acts to automatically lead to a state of no-confidence over time if the set of block finalizers were captured in that extreme way. However, that may open up other games that can be played via that mechanism. It is a bit half-baked. Would need to think about it more deeply.

Thanks for detailed explanation. on the block proposer side. assuming that the proposer set is subset of finalizer set, would proposers receive additonal rewards? trying to figure out if there are incentives to run proposer plugin.

Yeah. I think the staking rewards makes the existing vpay unnecessary. But there can still be a bpay to pay block proposers for each block they produce just like how the current active block producers get paid.

Sir, does EOS have a deflationary plan, it has been sleeping for 5 years, and does EVM have a snapshot airdrop plan, EOD must come out of the downturn, I hope you and others can better lead the community development.