5 ms·
The point of Ethereum is not really to be a distributed computer. It also seems misleading to describe it that way, as it doesn't distribute computations. Every
by pgsimp 6y ago
The point of Ethereum is not really to be a distributed computer. It also seems misleading to describe it that way, as it doesn't distribute computations. Every node computes the same thing.
- viraptor 6y agoIt also barely computes anything. It's closer to distributed consensus. (Distributed tricky consensus? - I acknowledge there's a tiny bit of logic)
- derefr 6y agoYes, Ethereum Mainnet isn’t much of a distributed computer in the Mosix sense (it’s more of a decentralized computer); but a private/protected PoA EVM blockchain very much would work to truly distribute computation. Or, to put that another way: as long as all nodes can trust each-other (and so run entirely in fast sync, with no redundant verificational executions of the same blocks), then Ethereum does in fact allow N computers to work on pieces of N subproblems in parallel and use the state trie as a blackboard for syncing/linearization between those subproblems. (The actual heavy computation would have to occur outside the chain, in oracle sibling processes, but they could at least load their binaries from the state trie. Think of it like AI bot-clients cooperatively playing a MOO where users can define object code.) Essentially, Ethereum is a distributed database with Turing-complete CRDTs. Mind you, nobody’s using Ethereum that way, but that doesn’t mean the underlying tech isn’t natively capable of being used that way. (Just like, say, oldschool fixed-function-pipeline GPUs could be used as GPGPUs, if you could translate your linear-algebra problem into an equivalent scene-geometry rendering problem.)
- TechBro8615 6y agoI’ve never understood Oracles as a concept. They seem fundamentally untrustworthy. ETH seemed to have a higher tolerance for introducing the trade offs of Oracles than Bitcoin. But without Oracles, the overlay networks you speak of couldn’t compute any meaningful logic without requiring an absurd amount of resources from the main net. If you’re making a distributed computer, it’s like you’re scaling silicon circuits up to the network level. So any operation using those circuits will of course be more expensive. That means that many computations on the main net are cost prohibitive. I would like to learn more about the trade-offs and risks of a blockchain relying on Oracles as a source of truth.
- chrisco255 6y agoOracles are always going to be less decentralized than a distributed blockchain VM. Chainlink's (oracle platform) approach to this is to have oracle nodes post a bond that can get slashed if the computation is deemed invalid. But most Chainlink oracles have 21 or fewer nodes. This is fine for supplemental data but would be vulnerable to all the same attacks that DPOS chains have suffered if used as base layer consensus.
- derefr 6y agoLike I said, Ethereum can be used as a distributed computer presuming an complete web of 100% trust between nodes. E.g. when the nodes are all run by a single corporation, with the node operators being different employees in different locations. In that case, the oracles (= native processes interacting with the blockchain nodes) would be presumed-trustworthy just as much as the nodes themselves are. The only question would be whether the out-of-chain computations of the oracles are able to move the state forward in a deterministic, linearizable manner as if they were on-chain computations — which is totally possible if you make your blockchain into a collection of arbitrary-CRDT smart-contracts and only interact with shared data through them. But to directly address your statement, in general, oracles as a concept are “trustworthy” iff 1. they rely solely on public information as input; or 2. are run by a centralized entity, which is the same entity that has sole ownership of the resource being modified by the oracle; or 3. the system is built such that any oracles can submit a cryptographic proof of X, and as soon as any oracle does so, the condition is triggered. Re: case 1, just as you can re-compute the transactions of a blockchain to arrive at the same consensus state, you should be able to grab a copy of the oracle’s code yourself and run it in a proper “context”, whereupon it will re-assert all the same transactions it ever originally asserted to the chain. This requires that all APIs the oracle deduces its assertions from have historical-data variants. Re: case 2, the oracle is basically just standing in for a human. If you trust a human to do X, then you trust an oracle to do X. Re: case 3, this is what on-chain prediction markets do. Rather than the win-condition for a prediction being something a human watches for and then enters, many private individuals (bettors) are incentivized to each have their own oracle running that watches for the win-condition however they like, and then — as soon as that condition attains — proves to the smart contract that the condition attains. The smart contract doesn’t have to care which oracle submitted the proof, only that there is now such a proof.