Wei Tang @wei@that.world

Dealing with the problem of governance inactivity -- a new #Neatcoin council design that is kept alive. https://github.com/neatcoin/neatcoin/discussions/3

Our current performance bottleneck is on GRANDPA, but not on BABE. By separating the validator set of those two, it is indeed practical to accomplish 10,000+ validators. https://github.com/neatcoin/neatcoin/discussions/2

I un-broke the chain! #Polkadot

We were made aware of a security issue affecting SputnikVM -- possible denial of service on EVM execution due to memory over-allocation. Please update your crate versions immediately! https://rustsec.org/advisories/RUSTSEC-2021-0066.html

Ideas of a universal basic income (UBI) project on #Kulupu. https://github.com/kulupu/coordination/discussions/14

A draft proposal for version 3 of Kulupu's PoW engine. The goal is to make it more light client friendly and to further improve syncing speed. https://github.com/kulupu/coordination/discussions/12

Polkaregistry is live! https://polkaregistry.org/docs/procedure/

Towards a common-good identity parachain for #Polkadot! https://polkaregistry.org/docs/vision/parachain/

In this sense, on-chain governance may not be perfect, but in most cases, including for base-layer blockchains, it is better than hard fork governance, because you can always improve the rules and draw a much larger opinion sample to reach an enforceable decision. (7/7)

Hard fork governance is like having a ruler that you cannot change. For the majority of time, the ruler will act according to people's will, because he wants to stay in power. However, the only way to replace that ruler, is to throw by force. (6/7)

On one hand, it makes hard fork relatively stable in that you always know who'll continue to "be the original coin". On the other hand, every controversial hard fork becomes a mess because the implicit "agreement process" will always be doubted by everyone, including devs. (5/7)

Many of the past hard fork dynamics are depicted as coin holders vs. miners, but if you look closely, a more accurate assessment would be developers vs. an opposing party. (4/7)

This is why in the past hard fork dynamics, Bitcoin2x didn't happen; Ethereum Classic, as well as Bitcoin Cash and later Bitcoin SV have to resort to different tickers. You can also use the same guideline to predict the outcome of the "EIP-1559 vs. miners" war. (3/7)

What is the most common thing that a decentralized community share? The software they're running! It's often no problem for people to download software upgrades from the same developer, but there are a lot of issues (trust, coordination, etc) for people to switch repos. (2/7)

I think this can actually explain a lot of past hard fork dynamics. Without an explicitly agreed process for agreement, people have to predict the implicit process that others are most likely to agree on and resort to. (1/7) https://social.that.world/@wei/106336302936496207

What I think Vitalik missed, is that people need to agree on the process for agreement. Hard fork governance has enough coordination to quantify whether people agree on things, but a decentralized community requires people to also agree on the means to agree on things. (8/8)

Having been in #Ethereum-style hard fork governance for a long time, and later having been in Polkadot-style on-chain governance, I must say that at this moment, I think VitalikButerin's arguments on opposition to on-chain governance is flawed. (7/8) https://twitter.com/VitalikButerin/status/1297812850140839937

Don't get me wrong. I like EIP-1559 Fee Market. Besides, nearly all #Substrate-based chains (Polkadot, Kusama, Kulupu, etc) already implement fee market in production. However, for Ethereum, a good specification does not do much itself without the community agreeing on it. (6/8)