Say, many CPU: many GPU, make powerful machine

davidpbrowndavidpbrown London, UKMember Posts: 15
There's an analogy that Ethereum is like a CPU, where BitShares DACs behave more like Application Specific ASICs. That prompts a question, why would you want a CPU to do what an application specific GPU can do better and with less overhead? I don't know, whether Ethereum ever might want to limit itself to what is not possible from Application Specific offerings rather than trying to reinvent them. For all the pretensions of doing Namecoin in 9 lines, for example, why would Ethereum want to do that? - There's no added value being on Ethereum, where there is however substantial added overhead.

In the case there are multiple chains: if you do set multiple 'CPU's running, then each Ethereum chain could be tasked with a unique complex problem; or set of problems relative to the size of storage and strain on any one chain. Other 'chains' could then be also BitShares or any other 'GPU'.

Comments

  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    edited March 2014
    Not sure if the title and analogies land well here :) I suppose you mean the overhead of running the interpreter, that has to keep track of the fees. Afaik that is the only real overhead.

    However, the size of a running full node is also increased because namecoin only has to deal with namecoin, whereas ethereum has to deal with any sort of contract out there. I wouldnt call it 'overhead', it is just 'load that it attracts'.

    Anyway some reasons: (approximately in decreasing importance)

    1. Contracts can talk to each other in trustless ways. Afaik we dont know how to do that across blockchains.
    2. AFAIK we dont know how to make coins equally valuable across blockchains. Or even how to send coin across without too much fuss.
    3. It can do many variations of ideas, and fairly quickly because of 1. Ethereum can do many variations of namecoin! Infact you could give the contract an ability to change the code with N out of M signatures if needed. Or you could say "Here is a new better namecoin contract, with copies the entries of the old one. Here is how to check.". People could check and switch.
    4. Developers of contracts dont have to worry about the blockchain software around it. Though you could have 'blockchain per script', or a 'blockchain maker helper' build onto a single network to solve this too.(this point would be nr 1 if this wasnt possible)
  • davidpbrowndavidpbrown London, UKMember Posts: 15
    I'm thinking more the overhead of everything in one blockchain rather than the interpreter, which I don't expect will be an issue, so long as the load is spread and the network overall is consistently fast and responsive to requests.
    So, I'm no expert on the complexity; I can only wonder about what is possible..

    1. DVC addresses map to BTC but I don't know whether there is a limit to doing that for many chains. Having the same addresses perhaps is a route to talking across chains.
    2. I don't see any need to have ETH-A identical value to ETH-B
    3. Yes, obviously Ethereum adds a great deal of flexibility but there is a point at which the balance may tip in the other direction and having another chain or solution like BitShares doing what they have already established, might be useful to draw on. Large part of whatever is done will be the market and the community and being able to take advantage or capitalise on top of other alternatives would be another strength. Limiting what you can do might be unecessary, if Ethereum can talk many languages/chains, it might be more useful.
    4. I guess I'm wondering the common question of how on earth will Ethereum be able to do everything on one chain.
Sign In or Register to comment.