Why is ethereum centralized?

If I'm following, ethereum is based on a single blockchain. It is counterintuitive to me, it seems the natural way to achieve the goals of such a project should involve a multitude of blockchains -- one per app essentially.

The disadvantages of centralization are many (so many that I leave them as an exercise to the reader) and the only positive feature of centralization I can think of is that it allows specifying cross-app contracts. But it shouldn't be beyond the wit of man to design a system that allows cross-blockchain contracts: for example, a peer to peer file storage services could be specified in the file storage blockchain with references to currency blockchains for payments. The user buying file storage would have a client talking to their service's blockchain and to the currency blockchain, without having to load/talk to the entire world of totally unrelated contracts.

That is, it seems to me that ethereum should be a toolset to create blockchains, not itself a blockchain sponsor trying to get all business conducted in one single place. What was the rationale for the decision to be centralised? I understand that being open source people will be able to start their own blockchains with ethereum code, still I'd like to understand what motivated this apparently baffling choice.

Comments

  • joeydeejoeydee Member Posts: 12 ✭✭
    robmyers said:

    ... applies all the network's processing power to maintaining the security of a single blockchain rather than fragmenting it altcoin-style...

    ^This

  • TechnologovTechnologov Member Posts: 102 ✭✭
    I think for data store (Dropbox-style), the main block-chain will be used for data-index only (pointers/links), and data itself will be in a separate data structure.
  • cigcig Member Posts: 7
    robmyers said:

    The blockchain is a distributed data structure, it's not centralized. There is no central authority or central authoritative copy of the blockchain.

    Yes the data is duplicated around, but still it's a single logical "database" entity, with the weaknesses following from trying to store the world in one database.

    For instance, a fork or a denial of service attack are (typically) "per blockchain" events. Political power (which the maths cannot remove as long as programs are run by people) also tends to concentrate around blockchains (the people with political clout in Bitcoin are not the same as the people with clout in Litecoin for instance).
    Ethereum having a single blockchain (rather than multiple blockchains) allows contracts to communicate with each other
    Yes, but as I said it's possible to design a facility that allows contracts over multiple blockchains -- possibly with some loss of flexibility, but I think that's a price worth paying for decentralisation; and it has software engineering advantages, as narrow interfaces are a disincentive against spaghetti designs ("dependency hell").

    If ethereum doesn't have that to me essential feature, someone else will probably implement it and win market share. Plenty of applications just stop being possible if you only allow "incestuous" contracts that can't refer to the world outside.

    It also makes bootstraping the universe (in the social sense, getting people to use the platform) many times harder. I came here because I have a couple of ideas that need such a toolset (I don't want to DIY the infrastructure), and they simply cannot be implemented if I cannot express contracts that refer to other blockchains in an open ended manner. Imagine a dating site where you can only date your relatives, do you think it will catch on?
    applies all the network's processing power to maintaining the security of a single blockchain
    But the raw processing power is not the problem, it's just a trick to constitute an assembly of people who form a consensus. You need an assembly of people who care, with sufficient diversity. This is best done on a per-app (or app class) level in my view: I don't care about what happens in online poker blockchains and they probably won't care about what happens in the things I'm interested in, so we'll both be weaker participants if the whole thing is concentrated in a giant cluster fcuk.

    Compare it with company size in a market economy: should all economic activity be conducted by one corporation (with subsidiaries), or by many independent corporations whose size is wherever the economies of scale sweet spot for their domain is? Of course there's a level that is too small, and some fragmentation will cost, but then single point of failure centralized models have a pretty bad track record, so a healthy level of diversity is both beneficial and necessary.
  • cigcig Member Posts: 7

    I think for data store (Dropbox-style), the main block-chain will be used for data-index only (pointers/links), and data itself will be in a separate data structure.

    Yes of course. Taking for granted that blockchains contain only app contract metadata, I still don't want all the world's metadata in one logical place.

  • robmyersrobmyers Member Posts: 65 ✭✭✭
    A multi-blockchain Ethereum is only as strong as its weakest link. If your blockchain doesn't trust my blockchain (with my two node server that I have hacked to inject arbitrary transactions), then a multi-blockchain system is still subject to politics and insecurity, more so than a single blockchain Ethereum.

    We cannot know ahead of time which contracts we will care about or which pools of computing power will succeed. Securing poker contracts alongside access control contracts and crypto-equity contracts in the same distributed database creates a broader community of mutual interest than exiling poker players to the PokerThereum blockchain.

    The reason Ethereum cannot refer to the outside world is that doing so creates problems for mining and for trust. If my miner and your miner access a third party the femtosecond before the value they provide changes and the femtosecond after, we have both incorporated the true state of the world into our blockchain but we will get different results. Likewise if the third party is malicious and is deliberately feeding different values to different miners. Security and logical consistency win out over convenience here.

    I do think there will be AltThereums, and some will be very popular. But relative to each other they will still be third parites subject to the problems I touch on here, and so an Ethereum Fediverse isn't a good idea for now.
  • cigcig Member Posts: 7
    robmyers said:

    A multi-blockchain Ethereum is only as strong as its weakest link.

    Yes and no.

    Yes, because inside a contract a broken component inside the transitive closure of blockchains the contract references will cause a problem. But also no, precisely because the transitive closure does not include most of the world.

    In the file storage app example, if either of the payment currency blockchain or the file metadata blockchain is broken, the contract is toast, but the contract is unaffected by problems on unrelated blockchains like the poker one(s). The bulk of the universe will be out of scope for most contracts.

    And even in the problematic case, the contract itself may be designed in a robust way, e.g. if the currency used in a contract collapses, you may have a procedure (e.g. consensus of contracting parties, or pre-agreed failover) to dynamically switch the contract to a new commonly agreed currency on another blockchain.
    then a multi-blockchain system is still subject to politics and insecurity, more so than a single blockchain Ethereum.
    Yes there are federation level politics, but I disagree they will be worse than the sum of disadvantages of the centralized solution. I can't provide a mathematical proof sadly :-).
    Securing poker contracts alongside access control contracts and crypto-equity contracts in the same distributed database creates a broader community of mutual interest than exiling poker players to the PokerThereum blockchain.
    Yes but at the same time providing a massive barrier to entry which prevents people from contracting on your platform in the first place. So you're likely to end up with a miniature network with a broad mix of 0.00001% of the world's blockchain contracts, and if I'm mistaken and you do succeed in getting a dominant market share for the one blockchain, you will inflict on the world all the risk of a bloated too-big-too-fail entity (reinventing Goldman Sachs, thanks...). Resilience to individual blockchain failure is a necessary feature of a robust world.
    The reason Ethereum cannot refer to the outside world is that doing so creates problems for mining and for trust. If my miner and your miner access a third party the femtosecond before the value they provide changes and the femtosecond after, we have both incorporated the true state of the world into our blockchain but we will get different results.
    That's a possibly valid objection for some things, but I think there are plenty of useful use cases that are not so sensitive, for a start anything that states irreversible actions have been taken, e.g. a BTC payment being made. You can verify that by observing the BTC blockchain and once the property becomes true it's going to stay that way and it can soundly trigger downstream conditions. Also while the femtosecond level is likely to be a hard or unsolvable problem, I suspect making contract conditions at the say day or month level (which is closer to the granularity of most real world stuff) should be pretty tractable (e.g. think of referencing BTC block numbers as your clock, with "confirmation" buffers to clear boundary effects).
    Security and logical consistency win out over convenience here.
    You can argue the same about dating only relatives... you can vet your cousins more easily than random strangers.

    Besides it's about removing choice. People who want to build single blockchain contracts can. The presence of a facility doesn't mean everyone has to use it, and people can keep making self-contained contracts that don't reference the outside world. It may be harder for them to find willing partners, compared to an idealised world where everybody makes only ethereum contracts on one chain, but that configuration is simply unlikely to happen.
    an Ethereum Fediverse
    Not sure what you mean here by Fediverse, but I don't mean only multiple ethereum blockchains talking to other instances of ethereum blockchains, but ethereum blockchain(s) contracts being able to reference non-ethereum blockchains, as well as sibling chains, either as per-protocol modules, some of whom should come in the standard distribution for popular blockchains like Bitcoin, or as a generic facility to build such easily.

    Yes it's more messy than a pure single-protocol world, but the world is messy, and a robust world, that copes with failure and death, requires diversity and mess. Besides, this is crucial for adoption, because, when people can incrementally adopt your system, you can stand on the shoulders of the current giants of the existing blockchains ecosystem.

    A good test app would be for example a peer to peer BTC/LTC exchange, that validates trades specified as ethereum contracts on the BTC and LTC blockchains.
  • robmyersrobmyers Member Posts: 65 ✭✭✭
    I don't have a mathematical proof either so I guess the best alternative is a friendly wager. :-)

    Regarding a multi-protocol, multi-blockchain world there have been discussions of how to refer to (e.g.) bitcoin transactions from within Ethereum as sidechains, so in that sense people are thinking about how to interface Ethereum with the outside world and how to decentralize it in the way you are talking about here.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Scalability is the most important of the hard problems. I think it is simply not at simple as you indicate. Although i do wonder how far you can take merged mining, and there are indeed mechanisms like coinswap, and even SPVs to connect two blockchains.

    Tooting my own horn, hanging blocks can make large bits of data with consensus and arbitrary programs on there.(though it would function a little differently than ethereum internally) Probably the first thing i will try make with that is a forum-like thing.(probably redditlike) Kindah demonstrate the large range, from contract-like stuff like ethereum, to.. forums.

    However it suffers quite badly on the data availability problem. This was an interesting writup by Peter Todd, boils it down to three things:
    1. Proof-of-publication
    2. Order consensus
    3. Validation
    And claims for many purposes the last one is not as important. Hanging blocks totally fails at the first one, but can use effective in Ethereum. At least it gives some hope that, even with ethereum entirely as now, just maybe there is a way to build something much more scalable ontop of it.

    Finally, you need a high level of certainty the the above are true..
  • jfwjfw Member Posts: 12
    Cig: IMHO you are right. Ethereum should maintain one "blockchain" per active agent. BTW: to me it's also strange that a contract is an agent. That's a bad application of language and I'm afraid no sane judge will accept it. Agents should enter into contracts!
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Color me not convinced.. Basically it does provide a toolset, you could use the source code to do merged mining with Ethereum, or maybe some other mechanism using a contract in Ethereum to have your own blocks.(like hanging)
    That's a bad application of language and I'm afraid no sane judge will accept it.
    Judges should be bound to accept matters of fact. But Ethereum contracts are sort-of agents -as-in it is treated like one by Ethereum, but it doesnt have actual agency -as-in it thinks for itself. The users behind pubkeys know what it will do, so those users are responsible.

    However responsibility might in some case become less clear because multiple users might interact with it. Also, the name contract isnt entirely apt.
Sign In or Register to comment.