search

ethereumproject / ECIPs

The Ethereum Classic Improvement Proposal
55 stars 47 forks source link

ECIP-1038: Jets in Ethereum Virtual Machine #82

Closed sorpaas closed 6 years ago

sorpaas commented 6 years ago

(Rendered)

Abstract

Jets are optimization marks. Using jets, users can place optmization marks in an EVM program. An EVM interpreter will then verify the optimization mark claim, and if the verification passes, execute a native code version of the program that is equivalent to the original program.

splix commented 6 years ago

I have a question: if VM already has a db of native code and can verify against it, why a developer need to add a special mark to force it? can't it be done automatically w/o external request?

sorpaas commented 6 years ago

If what you are talking about is account code_hash to native code mapping, then yes. That's the extended version of precompiled contracts, and SputnikVM already supports it. (To add this to Parity or Geth is also not a hard thing.)

However, many contract only differs for a subset of its code, and to optimize them, we want to replace a subset (and commonly occurring) code to native one. This cannot be done without marking, because otherwise the complexity would be O(nm), meaning that you need to match each line (n) repeatedly with each item (m) in the existing database.

splix commented 6 years ago

I don't like idea of having a hack to let VM know more that it can learn from bytecode itself. It's compiler job to optimize for evm, and put everything in order that can be executed in optimal way by VM (i.e. it should able to find a pattern automatically). I'm in favor what JVM JIT does, starting from basic https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/underst_jit.html and there're tons of researches that we can apply to out VM

RorschachRev commented 6 years ago

The problem I see with this is that it breaks all compatibility. If this ECIP is adopted, it should be bundled with additional opcodes or other EVM breaking functionality. The obvious advantage here is that everyone who adopts Jets can process code chunks faster. If we can make Jets an "optional" instruction that is skipped by non-compliant clients, that is great. We would offer performance gain with no downside.

I'd like to know more about verification, and where the Jet execution code would be located. Are we going to lower gas costs on Jet code, or go with the "native EVM cost" and only use Jets to speed execution?

I think Jets sidestep the issue of "needing 30 new OPCodes" very cleanly, and some code that currently takes 3 million gas could be done with execution costs approaching 6k gas. Are we measuring execution time of a Jet for accurate gas accounting in the future?

This is a huge topic, and warrants more thought.

sorpaas commented 6 years ago

@RorschachRev No, jets doesn't do what you said. I think there's some misunderstanding.

Jet marks are normal opcodes in the current consensus rule. So it does not break compatibility. Existing EVM runs jet marks just fine, just being slower without the native code. Jets requires that the native code that it replaces cost the same gas, and have the same side effect. So there's no "native EVM cost" or anything like that. The cost is the same.

I think what you are talking about is more like pre-compiled contracts. That's a separate topic and there's indeed something to be reviewed as well: https://that.world/~essay/pdf/non-hard-fork-precompiled.pdf

RorschachRev commented 6 years ago

splix documented something like Pysco for speeding up python programs at run or compile time. That work was one of the early attempts at supercompilers, and it worked well for non-optimized code. Adding this functionality inside solc and other compilers makes sense, I don't see any reason why this should be in the EVM.

@sorpaas I thought Jets were like the paper you linked, but sidestepping the EVM into C/OpenCL. Either branch would be valid, but the cost of doing the same operations in EVM would be 3 mil gas and doing the operations in C/OpenCL would be 10k gas. Doing it with a contract in your paper still requires a hard fork to create a separate contract block and a new network message right? After that infrastructure is in place, you have a block of contracts that are similar to Oracles in that they compute based on input, and then generate an in blockchain answer that the nodes can process. Why not skip the whole hard fork, skip the dedicated block and the new message architecture and just create a series of "compute Oracles"? If the market adopts 5 of those computations, we could put the popular opcodes in the EVM, with a fallback to use the compute oracle. That way no hard fork is required, and the work could be done by oracle or by miner. Paying the Oracle(s) (I like 3 oracles) would be done "per problem" x "number of users" which allows smooth migration away from the oracle. Actually allocating the ETC vs Gas is something I'd have to think on more, but you may have a better solution.

I don't think the EVM should be extended with Jets, I think it should be done by compilers.

sorpaas commented 6 years ago

(@RorschachRev I still think we're talking about different things. This ECIP was about an EVM implementation-specific details and has nothing related to hard forks, but let's continue the discussion later.)

I have a feeling that we tries to mix two different types of specifications here and thus make several stuff hard to move forward:

So, as an experiment, announce ethoxy/specs, a specification repository that only accepts non-consensus-layer specifications. The repo has maturity level in replace of ECIP's status. And instead of "reaching consensus", it is defined in terms of whether an implementation has come in place. This would make implementor's life a lot easier.

In the beginning, I'm going to move this, together with the RLP media type ECIP to that repo and see how it goes...