Show newer

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)

Show thread

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)

Show thread

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) social.that.world/@wei/1063363

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)

Show thread

Having been in -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) twitter.com/VitalikButerin/sta

Show thread

Don't get me wrong. I like EIP-1559 Fee Market. Besides, nearly all -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)

Show thread

The lack of self-consistency primarily hurts community trust. A pressing question is -- how do you expect the mining community to trust ACD's decisions on EIP-1559 Fee Market, when ACD often contradicts itself? (5/8)

Show thread

This was not the only example. Similar thing happened in EIP-1344, which was included despite some technical objections in its design. On the other hand, many of us thought EIP-2315 was doing well addressing its technical issues, until the last minute when it was rejected. (4/8)

Show thread

Probably the most worrying thing is self-conflicting ACD decision makings. Remember ProgPoW? It was rejected nearly purely because many devs think it's controversial. While in EIP-1559 Fee Market, it's included despite its controversy in the miner community. (3/8)

Show thread

It's really hard to point at a clean example on an ACD decision where I can say -- the governance process is working really well. It's really easy to find many many examples on ACD decisions where people can easily say -- the governance process is broken. (2/8)

Show thread

I can't help but echo the comments from greg_colvin, peter_szilagyi and others, regarding the "nastiness" of ACD decision making on EIP-2315. (1/8)

We're not there yet, but close. There are still some framework-level code to be written. If successful, we may be able to generalize this to be suitable for other types of blockchains, besides -like ones!

Show thread

I'm actually quite excited about this. Right now, most users utilize the EVM execution and RPC compatibility layer, but not so much the wrapper block layer. This proposal will be the first time we try wrapper block in production. github.com/ellaism/meta/discus

Really happy to see NEARProtocol using SputnikVM for its execution engine!

New unified EVM runner for Frontier!

In the past, users of Frontier have to compromise between compliance (the "stack" runner), and interoperability (the "builtin" runner). The compromise is no more!

github.com/paritytech/frontier

Basic documentation for Frontier is up. The Ethereum compatibility layer for Substrate! paritytech.github.io/frontier/

Show older
Mastodon

Wei's Mastodon server, at That World!