4 ms·
Before starting work on Ethereum, Vitalik worked on "colored coins", i.e. tokens on Bitcoin. The 2013 Ethereum whitepaper[1] talks about the various limitations
by wcoenen 6y ago
Before starting work on Ethereum, Vitalik worked on "colored coins", i.e. tokens on Bitcoin. The 2013 Ethereum whitepaper[1] talks about the various limitations in Bitcoin that motivated the creation of Ethereum. One of them was that tokens on bitcoin do not work well for light clients.
[1] https://ethereum.org/en/whitepaper/ https://ethereum.org/en/whitepaper/
- SnowProblem 6y agoI disagree with Vitalik and don't think these ideas were explored far enough. You can do proof-of-work on L2 state just like L1 which would enable light clients. The benefits of the colored coin approach is that the base consensus layer stays simple, like Internet packets, and more complex logic can be pushed out to apps or second-layer nodes that specialize.
- wcoenen 6y ago> You can do proof-of-work on L2 state just like L1 which would enable light clients. The more I think about this, the less sense it makes to me. Do you have a reference that explains how this would work? It sounds like you're talking about building a blockchain on top of a blockchain, which doesn't seem practical. Surely it would be better to handle decentralized consensus once in the base layer, so that the layer on top can focus on other things? Think IP vs TCP: TCP doesn't come with its own solution for relaying packets across network boundaries. It relies on IP for that, and instead it focuses on providing reliable streams.
- SnowProblem 6y agoYes, something like that. Users could pay extra fees for their transactions to be part of L2 consensus and to be loadable by light clients. If they don't pay, the event is still recorded on-chain, so apps and services they trust can still load their and others' tokens if its in their interest. Apps shoudn't have a problem keeping up, if they want to, so long as L2 state is localized (ie. colored utxos, not metacoins/accounts). They might even share relevant L2 transactions with other services that are also indexing that protocol in a sub-network. These are just some of the ideas I am exploring.