3 ms·

No one’s overlooking ethereum, it’s just not that useful to use the worlds slowest, most expensive computer when there is literally any other option for most ca

No one’s overlooking ethereum, it’s just not that useful to use the worlds slowest, most expensive computer when there is literally any other option for most cases.

hanniabu 4y ago
If you're willing to throw out security and use one of the many EVM clones, then you're just better off using a database. You're giving away the main value add and are just left with inefficiencies.
- KMag 4y ago
  > If you're willing to throw out security and use one of the many EVM clones... The devil is in the implementation details, but if we're talking about eBPF vs. EVM... one of them was designed for deadlock-free execution of untrusted code in-kernel, and the other is EVM. Though, for smart contracts, I think we're best off with a graph reduction execution model, where the contract is presented its initial state and an array of the output contract states, and the contract graph evaluates to True i.f.f. the outputs are an acceptable end-state given the initial state. The client code would propose the new state, along with a compact representation of the path taken through the graph. (The path represented as the index of each branch taken at every OR node in a pre-order traversal of the graph.) The client-side execution to find a True path through the graph might not be efficient, but the on-graph verification is fast, and the format lends itself to a declarative contract description.
  - cfcosta 4y ago
    Isn't this a modified version of eUTXO [1]? Known initial state/datum, transactions can be simulated/commited without needing global input like the account model needs. The tradeoff is, of course, that scripts become much harder to implement, as you can't depend on global state. [1]: https://iohk.io/en/research/library/papers/the-extended-utxo-model/ https://iohk.io/en/research/library/papers/the-extended-utxo...
- yieldcrv 4y ago
  If only I could use a database where all my users pay for all traffic to it

No one’s overlooking ethereum, it’s just not that useful to use the worlds slowest, most expensive computer when there is literally any other option for most cases.

hanniabu 4y ago

If you're willing to throw out security and use one of the many EVM clones, then you're just better off using a database. You're giving away the main value add and are just left with inefficiencies.

KMag 4y ago
> If you're willing to throw out security and use one of the many EVM clones... The devil is in the implementation details, but if we're talking about eBPF vs. EVM... one of them was designed for deadlock-free execution of untrusted code in-kernel, and the other is EVM. Though, for smart contracts, I think we're best off with a graph reduction execution model, where the contract is presented its initial state and an array of the output contract states, and the contract graph evaluates to True i.f.f. the outputs are an acceptable end-state given the initial state. The client code would propose the new state, along with a compact representation of the path taken through the graph. (The path represented as the index of each branch taken at every OR node in a pre-order traversal of the graph.) The client-side execution to find a True path through the graph might not be efficient, but the on-graph verification is fast, and the format lends itself to a declarative contract description.
- cfcosta 4y ago
  Isn't this a modified version of eUTXO [1]? Known initial state/datum, transactions can be simulated/commited without needing global input like the account model needs. The tradeoff is, of course, that scripts become much harder to implement, as you can't depend on global state. [1]: https://iohk.io/en/research/library/papers/the-extended-utxo-model/ https://iohk.io/en/research/library/papers/the-extended-utxo...
yieldcrv 4y ago
If only I could use a database where all my users pay for all traffic to it