How do layer 2s differ from execution sharding?
vitalik.eth.limo
vitalik.eth.limo
That said there is a lot of complexity around bridging which leads to high transaction fees, long waiting times (e.g. some projects have a 7+ days waiting time for bridging tokens back from L2 to Ethereum mainnet).
Another downside to Ethereum is that it forces all this legacy on everyone... As many L2s and other ERC20 tokens will be abandoned in 20+ years, much of their data will still be stored on Ethereum mainnet blockchain. Smart contacts are more like accounts, they aren't like old transactions, you can't just prune them after some time without major ramifications.
With old transactions in single-token blockchains, you can potentially prune old transactions while keeping account data and balances the same. The trust and centralization implications of doing this are minimal and constrained to that single blockchain only. With Ethereum, Ethereum community can't just decide to prune old unused smart contracts from the mainchain since it would affect the integrity of L2s and it's noth Ethereum's place to decide whether or not they can delete tokens that belong to other communities.
Overall, Ethereum ecosystem has a legacy problem due to the fact that they are multi-token. L2s accumulate unnecessary legacy from Ethereum and also from other L2s.
IMO, the benefits of decoupling tokens from Blockchain infrastructure aren't worth it as the value of a token is ultimately derived entirely from its infrastructure/integrations.
If it increases faster than blockchain size, then we're OK.
Hope is not a strategy, and things should actually be the other way round: to avoid centralization, blockchain projects should be designed to scale at the same rate available compute power does externally: b/w, storage, etc.
Everything around you banks on an ever expanding economy and continuing inflation. Housing, pensions, etc.
Saying that this is not a strategy is just plain wrong.
A surprising number of things are "OK" if we ignore externalities.
You fo realize ethereum isn't bitcoin, yes?
Regardless, it sounds as if you're against more efficient, power saving computing?
(Hands down, compute power is incredibly power efficient, compared to 20 years ago. This trend does, and will continue.)
If you have issues with ethereum, which is one of the most friendly power consumption cryptos which exists, don't blame people citing techical facts.
Optimistic rollups have to have such a waiting period by design. If you want to avoid it, use ZK rollup L2s.
End users will rarely use this process, instead they're directed to swap pools which essentially do an atomic swap of the same asset on both sides of the pool. The counterparty can observe the batches submitted by the sequencer are legitimate and can act on their side of the swap and collect a fee for providing liquidity.
Taking it a step further, in the future I imagine we will see wallets that abstract the concept of chains away, and automatically move the asset to the chain with the platform you are trying to interact with as part of the interaction transaction.
I started to write an article [1] a while ago about how wallets ought to go about this but it seems the ecosystem insists on doubling down on developer tooling that really bakes in the concept of "which chain the user is on" into how all the libraries are used. It doesn't have to be this way but it'd require a bit of work to really get to the world where chains are very abstracted, and I'd like to see someone work towards it.
[1] https://tr3y.io/articles/crypto/towards-better-wallets.html
I'm sure that market makers and exchanges in traditional finance have a lot of complexity behind them.
That's where zero knowledge proofs come in. If you know the root hash at state a, and the new root hash at state b is given along with a zk proof, that proof data can quickly prove that the state change from a to b was arrived at correctly. In this case, the benefit of doing this on ethereum (or other evm l1 blockchain) is that those proofs can be validated on chain.
Layer 2s if they’re needed are as easily added on top as it is for Ethereum. But Solana is so fast and cheap already right now that it hasn’t been necessary.
I’m of the philosophy that since you only get to build one base layer, you should really spend the time to do it well and have it designed to be as efficient and performant as possible.
This wasn’t easily achieved by the way. It’s a heroic feat of engineering that shouldn’t be discounted.
Solana recommends 10Gbit/s network speed for running a node.
Ethereum nodes can easily run on almost any home connection.
Any more details about this would be interesting for me.
I’ve written off Solana after looking at it seriously several times now, yet it continues to have the appearance of thriving. Fwiw my biggest issues in the past has been a combination of large data and resource requirement and vulnerability of archive/full history nodes to Google services shutoff and centralization with censorship possibilities.
also two thirds of transactions are validators voting for blocks.
also afaik solana finalization time is not sub second, but 10 seconds. intrestingly why misleading info about sub second still persist...
also solana cannot really execute as part of single transaction all needed. so from 1/3 of useful transactions, half is just account lookup table creation.
so it feels somebody tries hard to tell the story about high throughput and low latency, while both are not there.
one cannot bridge or act in reality for 32 * 400 ms
https://solana.stackexchange.com/questions/7945/single-slot-...
To date no transaction has been rolled back on Solana once two thirds of the validator set have voted on it.
tl;dr Users often submit transactions that attempt to arbitrage price discrepancies on-chain. But someone else fills the arb before them and so their transaction while successfully received will result in nothing happening. The transaction didn't fail though. Solana, your "decentralized server", successfully received the request.
The result is that everyone relies on the Solana Foundation to store the full archive, and pretty soon even non-expired history will only be possible for large companies to store.
for validators it may be last 300 blocks. for bridges 30k blocks. for rollups 300k.
assuming it is possible to start validator from any block(trusting random subset of validators to bootstrap) and account state is way smaller its ok.
also, as i see 100tb costs 3k usd. so some archieval nodes can be just payed some to handle that.
And that number is going to grow exponentially, to the point where the network is destined to have a centralized, and thus fragile, structure.
I agree that most nodes do not need the full history, but even everyday operational costs are enormous: dozens of gigabytes a day just to keep up?
so economics of storage i do not know, but that leads back to artificially cheap transactions. as soon as tx will be real price, they will pay storage.
But if I was managing big money, I wouldn’t want it on Solana. Ethereum is far more decentralized and secure.
I can see a near future where Bitcoin is “digital gold”, Ethereum is the settlement layer for institutions, and Solana is the blockchain for retail users.
I don’t understand why people view Ethereum as more secure than Solana. They’re exactly the same in terms of security. And Solana is actually more decentralized than Ethereum is!