3 ms·
> 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.
by 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 agoIsn'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...