This is a really thorough and understandable explanation. Helped me fill in lots of gaps I had.
One thought it does raise in my mind, though - this is complicated.
Bitcoin is simple. The rules are simple. Simple is really good when it comes to securing a currency.
This, in comparison... I mean, oof. I get the high-level "proof of stake" idea, which (in my mind) has a similar mental complexity to Bitcoin's. But all the algorithms that need to work to support it... it introduces the idea in my mind that somewhere in one of those algorithms is a small oversight. Even if that's not the case, the thought is there.
My opinions on proof-of-stake hasn't changed (seems much better than PoW in real-world use for so many reasons) but it does seem to erode the beautiful simplicity of proof-of-work.
That complexity distracts you from the fact that proof-of-stake is self-referential and is not resilient to the kind of hard fork that Ethereum has already experienced.
Someday there will be another doctrinal conflict with a near 50/50 split in the community. Probably for the same reason - some DAO hack too massive to ignore. In a proof-of-work world, we can evaluate the health of each fork by measuring the scarce physical resources allocated to each.
In a proof-of-stake world, each fork can have a valid voting majority of stakers. There's no actually-scarce resource to split, so no external mechanism to decide which fork is the "real" one.
I wouldn't bet a potential future world monetary system on this scheme.
Are you referring to the “nothing at stake” problem? Ethereum’s PoS is designed to protect against validators signing transactions across multiple forks of the same network. The Gasper “finality” and “fork choice” rules ensure that one chain is always selected by the validator set to be the “real” canonical chain for the network.
What might eventually happen is that some % of the validators exit Ethereum mainnet and enter their deposit into an another blockchain, perhaps giving it a different name and set of features and tradeoffs.
I think they're referring more to a scenario like a contention in which chain constitutes ETH Mainnet in the first place. Like fork split like the following:
45% of validators sign on fork A
45% of validators sign on fork B
10% of validators sign both A and B (coincidentally such that they get evenly slashed between the two)
That is, there question of what "Ethereum Mainnet" is will not be clear-cut and depending on who you ask.
This seems like a false problem. The state you are describing is not stable, as validators have an incentive
1) to validate, instead of just sitting doing nothing
2) to choose the chain with the most likely chance of being the next main, otherwise they will be slashed
As soon as even the slightiest imbalance appears between the two forks, it will bias validators to choose one against the other and thus exponentially make it the preferred fork.
> and that external incentives don't outweigh enclosed ones.
I think this is actually the most commonly overlooked assumption. The protocol seems very robust, *assuming* perfect information (aka all incentives are known to the system).
I encountered this problem a few years back when trying to design a protocol for a decentralized prediction market. It's very hard to account for hedges or huge bets on other markets.
In this scenario, the 10% would be forced to exit as their deposit would be slashed, and would drop below the required minimum for a security deposit. So within a short period, you would end up with 50% signing on A, and 50% signing on B.
These would have to have different network or chain IDs to avoid slashing events. One of them, presumably B, would have had to actually change this number from whatever the previously standard/agreed-upon chain ID is.
I could imagine this scenario happening in a contentious split or attack, but it would create two very clearly different blockchains with different goals and needs, like what happened with Eth and EthClassic, or Eth and EthPoW.
That's a good thing. Cryptocurrencies are supposed to operate by consent, and that includes the ability to separate when consent for a ruleset can no longer be maintained. One of the main problems with PoW is that those who support the stronger fork can attack those who support the weaker fork if they are willing to expend the resources. Ethereum's PoS solves that and ensures that every user has an equal technical ability to withdraw their consent and take their money to a chain with rules they support.
The key is in the fact that violating the rules on Ethereum's PoS causes you to lose Ether, which means you eventually lose all your Ether and can no longer sabotage the chain. This is in contrast with PoW systems, where your mining hardware doesn't deteriorate any faster just because you are mining empty or invalid blocks, so you can do that forever and effectively shut down a chain that is small enough relative to your computer power. The only defence a PoW fork has against such an attack is to switch to a different algorithm that is less compatible to the attacker's hardware, but that harms non-attacking miners just as much. PoW has an element of "might make right" while PoS is completely consensual.
There is a special type of node called slasher that can submit proof of your voting on a different chain (your vote is signed by you, so it could be verify that you sign something not on the current chain), then you lose your stake on the chain. Supposedly both chain should have their own slasher nodes, so eventually you will lose your stake on both chains.
Don't cite me on the details, but that is the idea
Your stake is locked for a non trivial amount of time. Right now you can't even get them out, in the future after withdrawing stake is implemented, the locked out time is something like 12 months or more (I think).
You're correct which is why I don't stake on ETH. Until the powers that be decided on the rules I won't participate. Until then most of my coins are in PoW.
In order to automatically destroy the stake, I presume a majority of stake holders need to agree though? And if people think the stakeholders aren’t acknowledging it, they can just do another fork? Hrm…
Any block proposer can submit a whistleblower report. There is a pretty significant bounty if you discover a slashable offence, so there is strong incentive to include these in any proposed blocks.
But you still need a majority to acknowledge the report
> Slashing is triggered by the evidence of the offence being included in a beacon chain block. Once the evidence is confirmed by the network, the offending validator (or validators) is slashed.
It is a powerless mechanic if the majority of validates don’t want to play along.
There may be other solutions or defence mechanisms, but one solution would be to fork again and remove the Ether those validators have staked from your chain as part of your fork.
A chain is defined by a set of rules that everyone on the chain agrees to abide by. Braking the rules damages the economic utility of the chain, so the Ether on the chain where the validators colluded to break the rules would be worth less, as a result of their actions. The validators are locked on that chain (as they can't prevent a fork from excluding them), so they have a strong incentive against harming the chain. Ethereum is not majoritarian. I don't have to abide by the will of the majority. I only need to come to a consensus about the rules and state of the chain with the people with whom I want to share the chain.
PoS makes it much easier to escape a malicious majority compared to PoW where the hashing power majority can follow the minority anywhere unless the minority is willing to switch to a different hashing algorithm. Even then, the majority could sell their mining equipment and buy new equipment that will work on the new chain on the same terms as that chain's honest minority can. With PoS, the malicious majority would need to buy new Ether from the honest minority who can then just fork again after having made a profit on the attack, and can continue to do that until the malicious majority runs out of resources or realizes that they cannot censor a fork in Ethereum's PoS system.
> Braking the rules damages the economic utility of the chain, so the Ether on the chain where the validators colluded to break the rules would be worth less, as a result of their actions.
So you’re going to create a new fork, remove the money from the majority of the wealthy stakeholders who are governing the system, and expect this one to be be seen as legitimate? The one that is explicitly giving the finger to the wealthy?
I don't think legitimacy is a meaningful concept in this context. I would use the chain with the greatest utility, which is determined by whether I like the rules, whether the rules are consistently and predictably enforced, and whether other people I want to interact with are using that chain. Whether the people who use the chain have more Ether or more computer power compared to the people who use a competing chain doesn't affect utility.
While I don't think it's meaningful to say that one chain is more legitimate than another, if I was forced to make such a deamination in this case, I would consider the chain where the rules are consistently and predictably enforced in a way that leads to predictable outcomes more legitimate than a chain where validators have colluded to arbitrarily subvert the enforcement of the rules.
Do you have a source for this? As I understand from the spec[1], any block proposer can submit a slashing report while including their block in the chain, and the protocol (ie: the client software that everybody runs) will reward them automatically if the slashing conditions are satisfied.
The majority of validators could perhaps block this by all running forks of the various consensus client software, with some code changed to set the reward to zero, but why would they do that?
Anyone can include a slashing report in their block, but it does nothing unless the block is approved by a majority.
If we imagine a 90/10 split of opinions that leads to a hard fork, the 90 majority can either be satisfied and with their fork and be nice or they can stonewall the 10% fork and refuse to approve any blocks that supports the idea that they deserve to be slashed. Because the only thing that can punish the majority is the approval of the majority. And because allowing another fork to exist reduces the value of the other forks. And because it would just be nicer if instead of having two forks we just kicked out all those annoying validates we don’t agree with.
In your scenario, the 10% who are running forked software risk losing all their deposit by double-signing blocks on the same network and chain ID as the majority 90%. In practice, if 10% wanted to split off from the majority and run incompatible clients, they would be forced to use a different network or chain id, which means they are running a different blockchain.
In my scenario the it is the 90% that is double signing, and they are risking nothing because it is the same 90% that gets to punish them.
If the 10% wants to fork off and do a completely different blockchain, what happens to the folks who aren’t colluding either way? I mean, while we’re down to just throw away people’s stakes, why not do so for everyone who isn’t explicitly on our side?
The scenario sounds extremely implausible; a chain with 90% colluding actors would be worthless, and the remaining 10% of honest users would likely exit to another chain that is not majority run by malicious nodes.
For example: migrating to a new chain ID and restarting with a validator set limited only to the public keys of the 10% who are acting honestly, and loosening that restriction slowly over time.
The attack would end up being extremely costly: not only because it makes the original chain’s token price worthless (who wants to be on a malicious chain?), but because the attacker may also have their deposit slashed in the new chain by the now-majority of honest users defending it.
The 90% is an arbitrary and unnecessary figure. Note it is not 90% of actors either. It is the bag holders of the bulk of the wealth. Far easier to imagine. And if you try to fork off into a world where the most important financial players have nothing, you will not be taken seriously. The money is more important than the crypto.
That is true. However, to the point made above, proof of work is actually using a scarce resource. If you fork a proof of work chain, the amount of mining power remains the same. You can’t mine both chains with the same resources. If you fork a proof of stake chain… everything just copies over. And then maybe if people place nicely in the name of the being good crypto citizens they agree to only focus on one chain.
My (maybe naive) understanding is that proof of stake is actually better here, no? Stakers would need to commit to one particular fork and accept that their stake (in ETH) would be lost/slashed in all other forks.
In contrast, in PoW, there's nothing stopping miners from creating a hostile fork that is economically advantageous to them (despite maybe being "worse" overall) and then flipping back to the original chain if their fork doesn't work out. Their hash power can't be slashed in the same way stakers ETH can be in PoS.
Doesn't a fork in both cases continue with the existing chain? In PoW that means that mining power has to be allocated between the two chains, thus constituting a vote for legitimacy. In PoS each party keeps their stake in both new chains and can vote in both of them. There is no need to pick a lane.
The validators choose which to support. If you think one will fail, you will be selling off the forked eth, bridging it over, and buying more eth on the chain you want to support
> In a proof-of-stake world, each fork can have a valid voting majority of stakers. There's no actually-scarce resource to split, so no external mechanism to decide which fork is the "real" one.
So what really happened when a PoS chain forked? Justin Sun learned the hard way.
With Bitcoin and Bitcoin Cash (and Ethereum and Ethereum Classic), it's no different from a demerger from the perspective of a company shareholder. You own a greater number of shares because the company has split in two, but they are not the same shares. They are shares in different companies that have the same origin but will go in different directions. Same with those currencies. The current version of Ethereum works a bit differently, as explained elsewhere in this comment section.
The complication is a huge red flag for me. Enormous. Red. Flag. What are we missing in all that complexity? What perverse incentives and unintended consequences are hiding in all that?
Also, you can't even unstake your eth. The developers promise it's coming soon, but right now, you can't.
IMO complication is due to lack of good explanations and lack of understanding of the subject. Bitcoin’s PoW is complicated, the idea is simple but in practice you run into many insecurities (forks, confirmation time, lack of verifiable light client, rule of more work vs longest chain, 51% attacks and how to bootstrap a new chain, centralization of miners, etc.)
On the other hand the hotstuff protocol is much more easy to grasp IMO (check my explanation in the book Real-World Cryptography)
PS: oh and also Bitcoin proof of security seems like a nightmare. It’s nice to create protocols that look simple but if you can’t prove their security it’s a bit dumb :) on the other hand the safety proof of hotstuff is quite comprehensive : https://www.davidwong.fr/lbft_safety/
Bitcoin's proof of work is not that complicated, even though you threw out some words that are peripherally related to it. Nice try though.
I had to look up hotstuff proof of stake. As far as I can tell that's not what Ethereum (the coin we are discussing here) uses? Not sure where you are going with this.
this line of thinking is quite difficult to get by in the modern world, same applies to vaccines, or to your car, or to the food you eat the browser you use, etc, in fact if you randomly look in your room right now it is very likely that you will be shocked (e.g. the complexity of the HDMI cable)
My HDMI cable is not asking me to trust it with my hard earned money ;-)
Vaccines and cars and everything else you hint at have been around a long time and the trade-offs are pretty well understood. Proof of stake (and it's various implementations) have a long way to go before they reach that status
Compared to the likes of Ethereum, Bitcoin is super simple.
Compared to others, it's still somewhat complicated.
While the use of PoW for consensus is super simple (most cumulative difficulty wins), Bitcoin script is a huge source of complexity in itself, with tons of warts. As it turns out, you don't need script to do payments, multi-signatures, atomic swaps, discreet log contracts, bidirectional payment channels etc., i.e. nearly all of the functionality that script is used for.
All those can be done with so-called script-less scripts [1], which is mostly creative use of Schnorr signatures.
Bitcoin's emission is not that simple either with the reward halvings every 4 years. A fixed block subsidy (i.e. pure linear emission) is not only simpler, but arguably fairer too, avoiding a concentration of wealth on early miners/adopters, and leaving later generations more than mere crumbs.
> Bitcoin's emission is not that simple either with the reward halvings every 4 years. A fixed block subsidy (i.e. pure linear emission) is not only simpler, but arguably fairer too, avoiding a concentration of wealth on early miners/adopters, and leaving later generations more than mere crumbs.
The halving is probably the reason for the high tides of Bitcoin prices and the inflow of capital to all of cryptocurrency.
Agree, PoW + halving was good for the bootstrapping phase. Now it's a ticking time bomb with no obvious way to change course. Best solution of course is for bitcoin to adjust the schedule and do one final cycle to distribute the remaining coins, and then transition into being an Eth rollup, but good luck with that argument.
> A fixed block subsidy (i.e. pure linear emission) is not only simpler, but arguably fairer too, avoiding a concentration of wealth on early miners/adopters, and leaving later generations more than mere crumbs
Yet Ethereum had a premine of around 60M, roughly half of all existing coins today. Later emission seems negligible regarding fairness.
If your goal is to passively hold coins without losing share, Ethereum is the best option I know of.
With both PoS and PoW, a holder loses share when the total coin supply increases. On Ethereum at least, this is less of a problem with staking than mining, because staking is less costly so there's a tenth as much issuance.
However, with sufficient usage, the ETH supply actually shrinks, because a portion of fee revenue is burned. This means non-staking holders actually increase their share.
You are not supposed to buy ETH as a way to speculate on its price.
ETH is a resource used to represent processing and storage power. You can think of it as "AWS credits" that you can buy and use to run programs.
The absolute price of ETH is of no interest. The only meaningful number that you should care about is "what is the gas price compared to the ETH price", as in, "how expensive is it to access decentralized computing".
Speculating on ETH value is an investment strategy that is completely separate for ETH utility. People interested in the latter shouldn't care about the former. Just as people using AWS shouldn't really care about AWS stock price.
If I'm using AWS I definitely care about the stock price since if it goes to zero I'm gonna have to find a new cloud. Also I have to buy shares to run my program, apparently.
DAO hack? Ah, the incident where someone read the contract carefully and got completely screwed.
It's bizarre to me that people wrote a contract that says one can take the money in certain circumstances, but then completely refused to abide by that.
I really feel bad for the person who figured out how to get the money but then was denied by insecure bullies. What an absolute joke.
The primary one is that in the presence of byzantine faults it goes for consistency over availability, however the Avalanche ecosystem generally prefers that choice.
This seems like it would be extremely simple for tech folks to understand.
Strikes me as strongly analogous as to why each of us doesn't run our own email server? Which is, when email was first invented, may have not seemed like a bad idea, but in terms of scale something like federation works better?
Bitcoin is a money, Ethereum is becoming a Rube Goldberg machine to obfuscate the fact that it was issued as a security - where the issuers were paid WITH MONEY.
Yup. I've always said that Bitcoin is the grey brick cellphone or the Model T; the famous proof-of-concept that nonetheless ends up getting overtaken by better tech.
In the case of Bitcoin simple actually doesn’t mean more secure (since bitcoin forks constantly).
Simple protocols take time to land, and are often digestions of much more complicated protocols. We’ve seen that with TLS being simplified into Noise, or the sponge function for hash functions. If you look at the history of consensus protocols they are getting simpler and simpler as well, arguably hotstuff and streamlet and all the hotstuff variants are simpler and simpler to understand.
How difficult would it be to stake Ethereum, supposing you could afford a multiple of 32 eth?
I know you can join cooperatives for this purpose, but then it’s not your crypto anymore and this space is filled with thieves and con artists.
It’s something I’ve been kicking around as an idea for a while as part of a diversified portfolio, if eth drops to a point where I could afford 32.
I’m extremely skeptical of cryptocurrencies, but eth is the best of them and the network transaction volume is supposedly in the neighborhood with Visa ( something I find hard to believe.)
If you are interested in running what is referred to as a 'solo' validator, it isn't that difficult if you already have some linux sysadmin experience. There are several good guides around setting up the physical hardware, the node software, generating the validator key(s), making the staking deposit and then running the validator.[1][2][3]
Then there is a very helpful community called EthStaker - they have a subreddit at r/ethstaker and a discord (invite should be available in the subreddit).
If you want something a little more automated, Dappnode is a well regarded web based front-end and the Rocketpool node stack makes things very easy to be an operator for their pool using a TUI.
There are a lot of options, with a wide range of requirement and capabilities.
> the network transaction volume is supposedly in the neighborhood with Visa ( something I find hard to believe.)
I think the PR line is that PoS ETH can “scale to 100,000 TPS”, but it’s currently pushing 15-30 [1]. Visa does much more, though various figures are reported from 1,750 to 24,000. So, grains of salt and all that.
Correct, the plan is to scale to that level but currently is not doing that. The current L1 (Ethereum Mainnet) + L2 combined TPS can be seen here https://ethtps.info/
Important to note that Ethereum embraces the idea that L2's will provide a lot of the scale and L1 will remain the base, main layer of security. So the goal isn't for L1 to scale massively, but to be able to support a healthy ecosystem of secure L2's which scale in different ways!
For one, Visa just does funds transfers. If Ethereum just transferred ETH, it could do 700 tx/sec, based on the gas limit per block divided by the 20K gas for a simple ETH transfer. A lot of Ethereum transactions are more complex and use more gas.
Second, second-layer "rollups" already support transaction rates up to a couple thousand per second, without losing base-layer security guarantees. Essentially they compress the transactions on chain. (Actual traffic is much lower than that, so far.)
The longer-term plan is to move to rollups in a big way, and add a form of data sharding to multiply the on-chain data storage. That's where the 100K/sec comes from.
> If Ethereum just transferred ETH, it could do 700 tx/sec
So... Still an order of magnitude less than Visa.
> A lot of Ethereum transactions are more complex and use more gas.
How complex are they, are they a significant number, and dies this explain the abysmal transaction rates?
Visa aside, on Singles Day AliPay does 1 to 1.5 billion transactions in one day.
Okay. AliPay is an outlier. Klarna does about 2 million transactions per day, an average of 23 per second (it's significantly higher during peak hours, and lower during off-peak hours. Source: worked at Klarna). The transaction includes: client lookup (a complicated affair that differs from country to country and session to session), credit score calculation, order set up, payment (out of a several dozen different options) set up... all while conforming to banking and local regulations across 45 countries. Anything in eth anywhere close to that complexity-wise?
> Second, second-layer "rollups" already support transaction rates up to a couple thousand per second
So layer 2 batches transaction into a batch that then gets batched on layer 1 into a bugger batch that is then written in one go to the blockchain.
Ethereum runs the EVM, which is a Turing complete execution environment. It can run things of arbitrary complexity.
> Congrats, you've reinvented batch processing.
This is an extreme over-simplification of zero knowledge proofs. You would do well in digging deeper what is being achieved instead of dismissing it without any understanding.
Most of the cost comes from the need to maintain consistency in state. This means that even simple database updates require a lot of work updating hash trees and verifying that other nodes reach the same results. The design of these hash trees isn’t terribly efficient, and indeed was in some ways designed to be deliberately inefficient in order to ensure that nodes didn’t fragment into running specific contracts.
The good news is that there’s a lot of room for improvement in the design. The bad news is twofold: (1) efficiency improvements will eventually cause transaction processing to be data-bound rather than compute-bound, and (2) these improvements to improve compute may be incompatible with existing Ethereum nodes. ZK and optimistic rollups potentially offer a way out of this update mess that don’t require dramatic changes to the underlying consensus system. However they will also inherit some of the limitations above, including tradeoffs between availability and processing speed.
This is probably the first reply I've seen that doesn't shy away from saying "yes, we're inefficient", and looking at the solutions with a critical eye.
Over Ethereum there are completely automated exchanges (think Nasdaq), lending, escrow, stablecoins, zero-knowledge proof verifiers, games, payments...
Blockchains are designed to meet the most extreme requirements of availability, censorship-resistance and cost of attack. They achieve them by exploring the extremes of replication of the solution space of distributed systems. For example, Ethereum runs on a Raspberry Pi, and every node runs the exact same things. Therefore how fast it goes is limited to the slowest node you want to make able to run the blockchain.
But, what you are dismissing as simple batch processing are the application of very novel techniques (novel as in math was invented in the last 5 years to make them possible) that allow to externalize most of the heavy computation outside the blockchain and delegate to the blockchain the verification of a proof. Therefore allowing to inherit the security properties of the blockchain but achieving much higher scalability.
Ethereum settles nowadays 200 bitcoin equivalent transactions per second. And is targeting to scale to 1-10M transactions per second by 2030.
> Over Ethereum there are completely automated exchanges (think Nasdaq), lending, escrow, stablecoins, zero-knowledge proof verifiers, games, payments...
All of those "oh my god complex things" on Ethereum are a variation of "look up a single number in one account, look up a second number in the other account, add or subtract two numbers".
Even doing a KYC + proper credit check on a client will cripple Ethereum.
> that allow to externalize most of the heavy computation outside the blockchain and delegate to the blockchain the verification of a proof.
So, batching. But with an extremely complex processing that you trust devs implemented correctly.
> Ethereum settles nowadays 200 bitcoin equivalent transactions per second.
No one cares about "equivalent transactions" to be honest. People care about actual things being handled by actual transactions they engage in.
> So what exactly is so complex that Ethereum runs that it processes stuff so slowly?
Nothing against the talented devs working at Klarna, but if they have trouble handling the load, they can always add a couple TB of memory or a couple hundred CPU cores.
Ethereum needs to solve 100k tps while continuing to run on a Raspberry Pie on a home internet connection.
> Nothing against the talented devs working at Klarna, but if they have trouble handling the load, they can always add a couple TB of memory or a couple hundred CPU cores.
Ouch. Burn :)
A lot of fat has been trimmed from Kred and it's now rammed into an AWS instance, but the pain is real :)
> Ethereum needs to solve 100k tps while continuing to run on a Raspberry Pie on a home internet connection.
To run a node you need a 2TB disc, at least 16 GB of RAM and a quad-core CPU. So, not on Raspberry Pi yet (and probably not ever).
And then you actually go into the docs.... And: oh, 8 GB RAM should work, but let's have a 32 GB swap. The CPU should be fine, but let's overclock it. Oh, you shouldn't use Geth to ensure ecosystem health, but all clients except Geth require at least 16 GB of RAM. And geth will eat all of your disk spce if you're not careful.
So, for a single combination (Geth + Nimbus) it may just be possible to run this tower of babel on a Raspberry Pi. And.... The only thing it will be doing is... nothing, really.
You are not making an effort to appreciate the opposite point if view. An order of magnitude for a young, decentralized, trustless and permissionless network is quite an engineering feat.
How complex? -> Turing complete.
Also there is more to L2s than batching. Their aim is to maintain the security guarantees of the L1 without sacrificing availability. Plus, Zk proofs and merkle trees allow for great data compression in the rollup.
Turing completeness is actually amazing in its simplicity.
You take a push down automata (finite state automata plus a stack) and then add the ability to read and write anywhere in the stack.
The essence of Turing completeness is the ability to take any intermediate result as an input to the computation of the next result.
This is why the halting problem is even a problem, because you need all of the intermediate results to know the end result.
Ok now back to the topic at hand. Turing completeness on the L1 layer isn't very impressive because every node is supposed execute the code to validate it. The problem with L2 then is the fact that you must somehow avoid that, i.e. the L2 layer executes the smart contract and determines a result and these results are batched on the L1 where the point is that you're not supposed to execute the contract as otherwise there is no speedup to be gained. It is sort of a paradox.
The end result has to be verified on chain. The most promising strategy so far is build a zkEVM which produces a zero knowledge proof that can be verified on L1 via a smart contract.
I still don't understand how this convinces people to buy Ethereum.
Money is supposed to be a medium of exchange because barter is expensive and time consuming. Instead of trading anything for anything we trade anything for money and money for anything. Competition is good but is Ethereum even competing?
How exactly do random wealth transfers to early adopters serve any purpose that money is supposed to be used for according to classical text books?
The real problem right now is you can't unstake any eth you have staked. The developers promise it's coming soon, but personally I wouldn't stake any until then.
Given that they successfully transitioned an entire consensus change and things didn't implode (yet), I'm feeling a bit more optimistic that they can do withdrawals.
In practice: pretty simple. You can do it at home if you have decently reliable internet and power.
You don't need five nines of uptime, you need like, two.
You don't get subject to slashing for your node going offline, you only get slashed if your node is doing shit out of consensus like actively cooperating in double spends.
Remember that Visa transactions are not equal to Bitcoin/Ethereum transactions. A visa transaction is just a promise of payment at some future date, probably. That's why they can have such a high rate. Bitcoin and Ethereum transactions are settled cash in your wallet. Apples and oranges.
Bitcoin has the lightning network based on Bitcoin smart contracts that can do Visa-like rates of Visa-like transactions. I don't know if Ethereum has anything like that.
I suggest checking the /r/ethstaker/ (https://www.reddit.com/r/ethstaker/) community if you are interested in staking. I've been staking from genesis block and has required very little upkeep. Dive in!
Its about as difficult as setting up an Ubuntu desktop PC. Can get a NUC + 16gb ram + 2TB SSD and that will be more than enough.
For software Rocketpool has a really nice guide + configuration GUI, and you only need 16eth for it and you get more rewards than from a normal staking node. It's still fully self custodial.
Over many years, the 32 ETH limit really screws everyone in the world who can’t afford to stake $40k USD.
Choices are: use custodial staking (share your keys with custodian - risky), use non-custodial staking (keeps your keys private but has costs e.g. Lido charges 10% of your staking rewards), use an L2 coin (risks), use a financial proxy for Etherium (ugggh).
I guess running your own node means you can’t use a cold wallet, so security costs/risks are high?
> Choices are: use custodial staking (share your keys with custodian - risky), use non-custodial staking (keeps your keys private but has costs e.g. Lido charges 10% of your staking rewards), use an L2 coin (risks), use a financial proxy for Etherium (ugggh).
Rocketpool is non-custodial, allows you to run your own node with about 17.6 eth (16 eth + 1.6 eth worth of their token), and then earn a commission from the folks contributing the other 16 eth and not running a node. There is a decent amount of smart contract risk and risk around the value of the token, but it is a generally working protocol.
> I guess running your own node means you can’t use a cold wallet, so security costs/risks are high?
To answer the security concern - The staking keys can only be used for validation activities, and can't be used to spend the funds. When depositing the stake, you can specify a normal ethereum address where withdrawn funds will go to, and that address can be controlled with a hardware or cold paper wallet/signer. The worst an attacker who compromised your node and took your staking keys could do is get you slashed (a little more then a 1 eth penalty in normal circumstances), which would be of no benefit to them.
Apart from the solid advice below, I would probably suggest practicing cor a while on a testnet to see can you meet the required availability requirements.
It doesn't seem to be that hard, but keep in mind that staking requires you to be actively validating. There are major penalties for screwing up (attacking the network), and minor penalties even for going offline. You still need hardware, network, and electricity to run the validator.
Why do the first two images after the LMD-Ghost section [1] look like they were made on an iPad? All the other images are made using proper tools. I didn't realize that the letter in the first image was a V because it looked like a N. Feels slightly inconsistent.
Does Ethereum have some sort of system built-in to be able to internally and correct as the community learns about new issues? AFAIK everything that's written is written in stone, no? (Barring a majority decision agree to a new ledger entirely like they did that one time)
That would just be the normal upgrade process. You'd submit an EIP, it would undergo review, a spec would be developed, and it'll be worked into the client development and release schedule.
Yes: much like other standardized software. Many people coordinate and agree on patches and new specs, and then developers work toward implementing and testing it across clients. This is how all forks have happened so far, including “patches” like EIP-1559, and how it will continue.
Yes, Vitalik asks everyone to download a new version with the protocol patched. Previously it was "pretty please do this", now it is "do this, or you lose all your staked ETH".
how do you get started with "smart contracts"? all the "tutorials" always end creating your own crypto and that's it....
i need something basic, like alice and bob contract to sell 100 watermelons for 1 BTC and sarah is the arbitrator in case they have a problem... something like this.
or a smart contract to validate a sale of a house for 2 BTC.
or a partnership deed for a business between alice and bob with 3 clauses
For Solidity-based tokens, learn Solidity to be able to know the syntax for creating your contract.
After developing the contract, use something like Truffle Suite to validate that the contract is good, and add a testing suite around it.[1]
Find a test net for the coin that you're developing for and create an account. Generally testnets will allow you to have "play money" to work with. This will allow you to learn how to deploy your contract to the testnet (which is functionally identical to mainnet)
Deploy it there, test it further. Write apps around it with tools like web3.js or eth.js as appropriate.
Buy some currency for the applicable mainnet and deploy your contract to mainnet just as you did with testnet, only this time it'll cost actual currency to deploy -- this will vary wildly by network and token and such.
Different tokens have different protocols and such. The above works for Eth and Eth-based tokens. Cardano is Haskell-based, and refers to smart contracts as programs, and the process is wildly different. Some other tokens use Rust, or other languages, but the BASIC outline I've laid out is basically the same no matter which (except for Cardano, which may be the same, I have no idea.)
Anything that connects to the physical world makes little sense at the moment as it defeats the purpose of such a smart contract.
What you can do is anything that is related to moving ETH or ERC tokens/NFTs between addresses.
So an example that you see often is a Kickstarter type contract. This contract collects ETH from many sources over a period of time but will only pay out to the payout address if the minimum is reached in that time period. Otherwise all the funds are returned. This contract is fully autonomous and can be validated to do what it is supposed to do. You don't have to trust a single company like Kickstarter to follow the rules or not cancled your compain. The project being a scam or not compleeting is another story.
So in other words what you can do in a smart contract are financial constructs that are zero trust.
The reason many scams happen is also in part that people are not checking that the contracts are solid and prevent rug pulls etc.
I don’t understand the benefit of that… in the end, you have to trust the person you are sending the coins to to do what they say the will. This is true regardless of the smart contract. The only thing the smart contract does is guarantee that at least other people are also getting scammed.
Come to think of it, though, it doesn’t even guarantee that. The person who created the contract and will get the funds if the minimum is reached could always just send ETH from one of their other own accounts to trigger the threshold.
It makes sense for things that the contract can control.
If the contact enforces that when $tokenAmount is sent to $address, $asset is sent to $depositor.
If and when more things exist on the blockchain, and/or more physical institutions sign on to it, and/or more and more digital goods are worth transacting in such a fashion, then smart contracts will make more sense.
If neither of those materialize more tangibly than they do, it'll be hard to manufacture use cases for it, I think (though I am hardly an expert).
But considering the types of things that are already mostly digital, it seems like we have the _potential_ to lean into the latter case. Domain names, accounts, Github subscriptions, e-books, music, rights to watch movies / television shows, etc., those things could all be integrated into the blockchain and enforced via smart contracts easily.
Probably the best use case I've seen is stadium / conference tickets, but if we ever get to a phase where companies significantly adopt, we can do some interesting things, like communal ownership of assets. Ownership stake can be variable, depending on who is doing the most work. Profits could then conceivably be distributed among those who have earned it the most. "What to do next" could be a decision that is decided upon by a council of token-holders, for better or worse, and truly non-managerial workers could meaningfully participate in a company's decision-making, profit-sharing, etc.
Ok, let's take your example; concert tickets. You will still need to trust a central authority (the concert venue) to honor your ticket. Why not just let the concert venue own the whole thing?
tbf, it's not "my" idea, there are just a couple of NFT-based ticket sales startups that exist and I am aware of them.
The main benefit I would see from the venue's perspective is in both scalping prevention and achieving price equilibrium with less effort, because smart contracts can allow a rake to be collected on each resale of a ticket. Beyond that, while this use case doesn't appeal to me, I know of people who've collected scrapbooks of concert tickets, but the NFTs of the tickets are a collectible item (to whatever extent someone deems a digital asset "collectible") and can be potential collected in a digital scrapbook as either social proof or memoria.
That said, there's nothing in my view that mandates that the central authority doesn't own the whole thing. You can own the whole thing, either on your own token, or as a non-blockchain product altogether -- or not at all, but there are existing tools and technologies that allow for easier on-ramps than building it yourself and I think most venues don't particularly care what the technology is or that it's NFTs or that it's blockchain, so I don't know of any reason that a blockchain based offering couldn't find itself competitive in the marketplace unless their sales pitch is exclusively that.
> I don't know of any reason that a blockchain based offering couldn't find itself competitive in the marketplace
The main reason is that you have shown exactly zero reasons why anyone shold adopt it in a space that's already mostly solved the issue of selling tickets to people. You are teling people to create insane complexity just to solve the single case of selling a single ticket to a single person and pretend that's all there is. And telling people "but it's blockchain so it's good actually". That's not how this works, that's not how any of this works.
> And telling people "but it's blockchain so it's good actually"
I did literally the opposite of that when I said "I don't know of any reason that a blockchain based offering couldn't find itself competitive in the marketplace unless their sales pitch is exclusively that."
Restated, I am saying that "but it's blockchain so it's good actually" is not a viable sales pitch. All the rest of my comment are reasons that I think are pitchable features.
You seem to have imagined me saying something I didn't and are arguing against what you've imagined I said.
> I don't know of any reason that a blockchain based offering couldn't find itself competitive in the marketplace
So what are the reasons that a a blockchain based offering could be copetitive in the marketplace? And what would bockchain have to do with it?
Remember ,we're talking about tickets: a problem largely solved. Where a central authority you trust releases a ticket, and where the central authority you trust verifies the ticket at the venue.
So, what is the sales pitch for tickets for a blockchain-based ticketing startup? Other than, you know, "but it's blockchain!" (as all these startups do)
I listed the benefits in my previous message that you have apparently not read now.
From another comment you've made "I stopped making an effort [appreciating a pro-blockchain point of view] five-seven years ago for many obvious reasons," I won't bother to re-list them. If you aren't going to engage in good faith because you've imagined me to be a crypto-proponent, I'd appreciate it if you'd at least read what you're trying to argue with.
> I listed the benefits in my previous message that you have apparently not read now.
Oh, I have. None of those are tangibl benefits to either the venues or to the consumers. Or are not issues to begin with. All you propose is to build a tower of babel to kinda maybe solve minor issues.
I especially like this: " smart contracts can allow a rake to be collected on each resale of a ticket." Ah yeah, let's milk money for ever, and ever, and ever.
As to collectibel items and NFTs, you don't need NFTs to make collectible items. Especially considering how actual data for this bullshit is always invariably stored on a centralised server somewhere.
But sure. "Benefits".
That's one of the many reason why I stopped making an effort [appreciating a pro-blockchain point of view] five-seven years ago. Because all the bullshit that crypto absolutists come up with is so far removed from reality. And that's even for the simplest use cases like selling one ticket ot a single person for a single concert.
You have mistaken me for a crypto-absolutist, as well as your dismissals as real.
Resales already happen now, so your "money forever and ever" counter-argument isn't particularly persuasive, and if there are going to be resales, _of course_ the venue would prefer to get a commission. That is a real market problem now, and there exists a real solution for it.
"Tickets are a solved problem" rings as intuitively spoken as "nobody will ever need more than 640K"
Despite your imagining otherwise, there are undoubtedly non-blockchain solutions that can be built here to solve those real problems, but there are real solutions to them now that for whatever reason you refuse to entertain because the answer contains the words block and chain contiguously.
> if there are going to be resales, _of course_ the venue would prefer to get a commission. That is a real market problem now
There are so many things wrong with this.
1. You assume that as matter of indisputable fact that venues are absolutely entitled to a cut on any ticket resales, in perpetuity.
2. You assume that people reselling tickets (and venues not getting a cut) is a problem. It isn't, really. This is somewhat true for a very tiny number of very popular events, and even there there are ways to mitigate it. The hundreds of thousands of events that happen around the world that require the ticket don't have this "problem".
3. It's telling that you assume that it's the venues that have to get in on the cut. Not the concert organisers. Not the actual people in the event (artists, sports teams, presenters etc.)
4. Of course, as with all "solutions" involving blockchains it doesn't solve anything. You transfer a ticket to another person for free, and get the money for it in a different transaction. You transfer credentials for the wallet which bought the ticket to a person, you get money in a different transaction. Etc.
5. Of course, as with all "solutions" involving blockchains, this one exclusively focuses on a single issue (which is largely inexistent in the grand scheme of things) to cater to the simplest of all the cases (selling a single ticket to a single person). And all this "solution" does is: make it extremely complicated and complex, not really solving anything, and making other legitimate use cases even more extremely complex or impossible (because ticketing is much more than just selling a single ticket to a single person, even if it's the biggest use-case).
> "Tickets are a solved problem" rings as intuitively spoken as "nobody will ever need more than 640K"
This is observable reality. There are hundreds of thousands of events that require tickets around the world (probably even on any given day). You buy a ticket, you go in, done.
It is a solved problem.
> solve those real problems
You have to show that it's both a) a real problem, and that b) what you propose is an actual solution, not a "well, if you squint hard enough and ignore reality, it barely works for the simplest of cases, if at all"
> or whatever reason you refuse to entertain because the answer contains the words block and chain contiguously.
The only reason I refuse to entertain them is because you keep failing to show how it is a solution to anything. Given the list of issues I listed above that are immediately obvious to anyone with half a brain and a grasp on reality.
And yes, that is an issue with almost literally anything that has "block and chain contiguously".
> venues are absolutely entitled to a cut on any ticket resales
No I don't. Moreover, "in perpetuity" is a red herring.
> you assume people reselling tickets is a problem
No I don't. I perceive it as a problem venues are willing to pay to solve.
> It's telling that you assume that it's the venues that have to get in on the cut
Again, no I don't. Anyone on the supply side of this can negotiate this in. The tickets can originate from the artists, and then the organizers, and then the venues. Artists and venues can openly negotiate on this.
I've said before that you're imagining things I'm not, and halfway through your response, that's all you've done. I'm not going to bother to read or reply to the rest.
You can have hybrid smart contracts, that rely on oracles inserting real world data on chain (see Chainlink for example).
You could for instance have 5 independent oracles responsible for validating whether the concert happened or not. The "ticket" smart contract would release the money only if the 5 oracles agree it happened, or refund the buyers otherwise.
Chainlink is much more sophisticated than that and handle oracle reputation, cross chain oracle proof, conflict mitigation, etc.
> You can have hybrid smart contracts, that rely on oracles
So, trusting centralised data providers.
> You could for instance have 5 independent oracles responsible for validating whether the concert happened or not.
Ah yes. Because the ticket is validated after the concert has happened, and not, you know, at the entrance to the venue.
And also so many "coulda/woulda"s in your description of something that has already been solved and doesn't require mountains of compleiy on top of it. I mean, you can't reliably show how having a single ticket to a single concert would work better than the existing system. And that's the simplest thing that can happen to a ticket.
Seriously this blind anti-blockchain trend on HN makes any kind of rational discussion impossible.
Can we just stop this and act like engineers and actually _try_ to understand each other?
> So, trusting centralised data providers
Where did you understood that? Did you even read the comment you're replying to?
Chainlink (being just one example of an oracle protocol to illustrate the discussion), allows you to choose how many oracles you want, with whatever reputation constraint you want, strictly named or open ended, with or without whistleblowing/conflict mitigation algorithm, etc.
How does that deserves a snarky "So, trusting centralised data providers"?!
> Ah yes. Because the ticket is validated after the concert has happened, and not, you know, at the entrance to the venue.
There are multiple ways to handle this, a lot of future crypto contract implement something very similar to:
- The venue issues tickets that can be purchased through posting money to a smart contract.
- The smart contract locks in the money until, say, 5 oracles validate that the concert did happen.
- The venue can prove the locked in ticket sale amount as collateral to borrow money in preparation of the concert.
- The oracles validate that the concert happened, unlocking the sale money to the venue.
or
- The concert was a scam, oracles do not validate that it happened, thus ticket sales are refunded.
> something that has already been solved and doesn't require mountains of compleiy
My comment is not about the rationale or utility of the concert ticket example. It's about how that could be implemented with a smart contract.
> And also so many "coulda/woulda"s in your description
Chainlink is already used since multiple years to secure billions of dollars of pegged tokens, sport bet results, election results, insurance, etc.
> Can we just stop this and act like engineers and actually _try_ to understand each other?
This would be a great thing for blockchain proponents to start doing, yes. HN is littered with threads where people have spent hundreds of comments trying to get someone to explain how a blockchain is better than the status quo, and it always devolves to “I need to sell my random hashes”, usually with a side of “I have done no research into the domain I’m trying to sell into”.
Concert tickets are a great example. There are no widespread problems with tickets being sold for concerts which don’t happen and refunds being denied in violation of the terms of sale. Similarly, people don’t have any trouble paying for tickets since the existing options are cheap and safe. Those problems certainly aren’t large enough to warrant the additional cost and risk of using a blockchain.
The actual problem with concert tickets in the U.S. is that one company has exclusive contracts with most of the venues, their agents handle bookings for most popular bands, and they have a comfortable relationship with the company which controls radio play in much of the country. If you want to do anything in this space you need to understand that it’s not a technical problem, and explain what you’re doing differently which will succeed unlike the various failed attempts since the beginning of the web.
> Can we just stop this and act like engineers and actually _try_ to understand each other?
Let's do that. I only wish these blind crypto absolutists would actually look at real world from time to time.
> Where did you understood that?
From your statement: "You can have hybrid smart contracts, that rely on oracles inserting real world data on chain"
Oracles are always cenralised data providers that you trust. And for may, many, many applications there will be only a handful of them.
> There are multiple ways to handle this, a lot of future crypto contract implement something very similar to:
Again. None of these are much of an issue for existing systems. Have you been to a real concert in the real world lately? You buy a ticket, you go to a concert, done.
No need for "five oracles to validate that a concert happened". There are hundreds of thousands of concerts happening all around the world without this inanity. What exactly does blockchain bring into this equation? Or "smart" "contracts" (which are neither smart nor contracts)?
> It's about how that could be implemented with a smart contract.
Indeed. That's what I was addressing. You wanted to talk like real engineers trying to understand each other? So try to understand this: you are proposing a mountain of complexity to solve what is largely a non-issue.
Your entire description on how ticket sales happen have literally no basis in the real world. And that's on top of the fact that you completely ignore what the original comment (and then I) said: your ticket is issued by a trusted central authority, and then is validated at the entrance by a central trusted authority. What does blockchain bring into this euation except lots of "coulda shoulda oracles"?
Edit:
Even in the cryptoutopia world the "contract" for the ticket will of course be released by the central authority running the concerts, and you'll have to trust that they didn't screw up the programming. And no, "you can always check the contract" doesn't work since there are now multiple cases of these "smart" "contracts" passing multiple security audits and still having glaring holes in them. A human-readable cotract you have with the concert organizer can actually be audited by regular people, and is enforceable.
> Chainlink is already used since multiple years to secure billions of dollars of pegged tokens, sport bet results, election results, insurance, etc.
> that people are not checking that the contracts are solid
Ah yes. It's the people's fault that they don't check code in esoteric programming languages running on esoteric VMs using made up words for everything.
Yeah remember, you're supposed to upload your mind into the computer if you want to live in that kind of world. What will happen to you in the case of a fork? There will be two of you.
This is not true. Let me quote the UK's Head of Civil Justice:
6. The theory is to dispel the myth that blockchain is a fringe technology used only by those wanting to risk their livelihoods or possibly make their fortunes on volatile cryptoassets like Bitcoin.
7. The blockchain is now at a stage in its development equivalent to where the internet was in or around 1995. The internet was unstoppable in 1995 and blockchain technology is unstoppable now. It will become ubiquitous in all major industrial and financial sectors, simply because it allows for the immutable recording of data, thereby reducing friction in commercial and consumer transactions and obliterating the scope for dispute as to what has occurred.
8. As the Master of the Rolls and Head of Civil Justice in England and Wales, I hold an office that pre-dates modern trade in derivatives and reinsurance, even steam engines, powered flight, and certainly the internet. I am particularly and obviously concerned about the reputation and development of English law and the jurisdiction of England and Wales.
9. Many people do not realise that English law governs trading in €600 trillion of OTC derivatives annually, in €11.6 trillion in metals trading, in £250 billion in M&A deals, and in £80 billion in insurance contracts every year – just to take a few examples. My hope is that English law will prove to be the law of choice for borderless blockchain technology as its take up grows exponentially in the months and years to come.
This seems like a non-sequitor. It is not clear what you are disagreeing with or what point you are trying to make with that quote, besides that a top UK lawyer is pro-crypto.
I was responding to "Anything that connects to the physical world makes little sense at the moment as it defeats the purpose of such a smart contract."
That's why the judge's quote is relevant. They don't see a distinction between regular contracts and smart contracts. It's all just contracts.
I'm simplifying slightly (see Ricardian Contracts if you want the detail).
> They don't see a distinction between regular contracts and smart contracts. It's all just contracts.
That is not some that any of those quotes states. The thrust of those quotes is focused on the value of the blockchain as an immutable ledger, and doesn't mention "smart contracts" once.
The statement you are trying to dispute seems to be pretty widely accepted. Once you need to refer to physical world events, you need yo trust some entity to report those events accurately, removing the trustless aspect of "smart contracts" that is their primary selling point.
The most you can read into the quotes that you posted is that the judge sees a strong future for the UK judiciary in resolving disputes about trust when "smart contracts" have to interact with the offline world.
I would also point out that "smart contracts" are not literally contracts, but pieces of trustless software. Conflating those concepts does nothing to help the uphill reputational battle that faces the cryptocurrency ecosystem given all of it's shenanigans.
I don’t think this makes the case that you are claiming. Smart contracts are not the equivalent legal contracts, it’s a very good word. As for #6, I think people are more interested in more complicated rug-pulls involving NFTs then just trading BTC.
>alice and bob contract to sell 100 watermelons for 1 BTC and sarah is the arbitrator in case they have a problem... something like this
You create an owner variable that is used to show who can withdraw from the smart contract and is set to 0 at the start. You add 2 methods. The first is a method that is only usable by Sarah that lets her change the owner variable. The second is a withdraw function that is only usable by the owner. You can even enforce that the owner can only be set to Alice or Bob if you want.
Bob deposits 1 wrapped BTC. If Alice gives him the watermolens Sarah sets Alice as the owner. If Alice doesn't Sarah sets Bob as the owner.
>a smart contract to validate a sale of a house for 2 BTC.
You don't need a smart contract for that. Every transaction already gets validated by the network.
>a partnership deed for a business between alice and bob with 3 clauses
This depends on the clauses but you would put all the company assets into the smart contract and then write methods that let you spend those assets while not violating those clauses.
I only have a surface-level understanding of smart contracts, but you'd need an oracle for the off-chain validation part of the three situations you mentioned, and https://ethereum.org/en/developers/docs/oracles/ seems to have some contract examples.
What's the hangup with normal tutorials? There's a plethora of tutorials online.
People recommend ethernauts[1] and cryptozombies[2], but I found those quite slow when I was learning. Most useful for me was reading existing implementations of smart contracts, and learning from there.
hm creating your own crypto token is a smart contract, its just a standardized set of classes, modify the classes and see what happens
anyway try scaffoldeth.io
you compile the tutorial website first and then build a bunch of common smart contract scaffolding
note this is the EVM ecosystem so it would be impossible to conflate example in pure BTC, smart contracts are playing catchup in BTC ecosystem. There are a couple competing attempts there, very little scaffolding. There are many orders of magnitude more activity in the EVM ecosystem than there are in bitcoin ecosystem/UXTO model smart contracts.
> and not what the unoriginally critical HN crowd would like you to believe.
Of course. Just don't listen to the extreme ones, who continue to screech and parrot the same old absolutist takes over and over again to the media for engagement farming.
The truth is crypto is here to stay, but not all of them are going to survive. Only a few projects and cryptocurrencies will still be around longer than others and both crypto maximalists and anti-crypto absolutists are going to end up compromising in the end.
ETH is a captured system and is not censorship resistant like Bitcoin. Since its switch to PoS, entities that verify blocks must be OFAC compliant. https://www.mevwatch.info/
Here is a good visualization of this problem: [1]. You can see that 99% of restricted blocks will be included within 5 mins, given the current level of OFAC compliance. Even if 99% of nodes are OFAC compliant, it would only take 5 hrs for your Tornado Cash transaction to have a 99% likelihood of being accepted.
All of this will be moot with enshrined PBS in the protocol but that may not come for some time.
A Bitcoin block is produced every 10 minutes. An Ethereum block every 12 seconds. It would take 98% of validators censoring transactions on Ethereum for a normal transaction to be included faster on Bitcoin than a censored transaction is included in Ethereum. In practice, there are miners censoring transactions on Bitcoin too, so the number is higher even.
This only shows that this is baseless FUD. Most importantly, Proposer-builder separation will take care of this problem completely on Ethereum.
One thought it does raise in my mind, though - this is complicated.
Bitcoin is simple. The rules are simple. Simple is really good when it comes to securing a currency.
This, in comparison... I mean, oof. I get the high-level "proof of stake" idea, which (in my mind) has a similar mental complexity to Bitcoin's. But all the algorithms that need to work to support it... it introduces the idea in my mind that somewhere in one of those algorithms is a small oversight. Even if that's not the case, the thought is there.
My opinions on proof-of-stake hasn't changed (seems much better than PoW in real-world use for so many reasons) but it does seem to erode the beautiful simplicity of proof-of-work.