-
Notifications
You must be signed in to change notification settings - Fork 146
Mode to Disable Jumps and Turing-Completeness #151
Comments
Agree, brother, bye bye Turing. This is a good possibility for those that wants their smart contracts to run within this context. |
I can't see the benefits of this, you can avoid to use this opcodes |
It can be an option that also blocks jumps after dynamic invoke for exmaple. |
The point is: you could invoke a contract that has these opcodes in it, but your execution is guaranteed to not pass over them... the main idea is to disable loops in fact, but this should not affect If we have this mode enabled on vm, we could update compilers to use a flag --no-loops, in order to manually unroll loops for us (or using a decorator). Nearly all existing contracts would work better with a guaranteed maximum number of steps on loops, but if vm allows them, we can never be sure that code will finish in a given time. |
Guys, I think only Turing-incomplete opcodes should be used on a very fast verification:
|
@erikzhang @shargon @lightszero what about only allowing these opcodes during Neo 3.0 verification? |
Could you give me a practical example of why this is needed |
This allows us to calculate a tight upper bound of contract cost, regardless of its parameters. I give you the opcodes and I know the cost without executing them (reading storage, taking branches...). This is perfect for verification, and thats wht bitcoin still uses it. |
How to check signature without SYSCALL? |
SYSCALL will be controlled on Application layer Erik. |
Here's the proposed list of what should be allowed on verification Syscalls: https://github.com/neo-project/neo/blob/master/neo/SmartContract/InteropService.cs
https://github.com/neo-project/neo/blob/master/neo/SmartContract/InteropService.NEO.cs
|
Related to neo-project/neo#790 |
Just to clarify the proposed direction for Verification:
My questions here are:
|
But all is about gas, what do you think... the fee should be the verification and the execution fee? |
I think that, if we want to prevent consuming tx to enter mempool, this should be charged as network fee, instead of system fee. I mean, the Just to be precise here @shargon: |
If we follow this way, we don't need to limit the opcodes. Why limit it? |
The greatest advantage is to able to verify (Gas) Price is a way to prevent attacks to the network, correct? Bitcoin does not have gas, because it has (intentionally) a Turing-incomplete network. It's verification-based network, without storage, paying by tx size, so it's perfect for them. Since Neo and Ethereum have in common the fact to provide a Turing-complete network, and both require the concept of gas, to prevent things such as |
@shargon you asked for a practical example, this is one: Your node receives this script for Verification. How much does it cost? You don't know before executing it. You cannot provide an upper bound on the cost. Someone attached 1 GAS, is it enough? We never know. So you execute it, and only stops it if it runs out of gas (and that takes time). (if one jump costs 1 satoshi, you will spend 10^8 useless operations here, until you fail by gas, and don't win anything since it's on verification). Suppose the same thing on a Turing-incomplete network. How much will it cost?
I don't execute it, but maximum cost of this is 4 opcodes (1 satoshi each? so it's maximum 4 satoshi). How do I know it? Because it's impossible to have loops here. |
this example will be controlled by fee. You need to execute your verification for know the amount of required gas |
My proposal: Execute verification with the fee atached, the rest of the fee will be the fee for the invocation. if your verification cost 10Gas,and your invocation cost 1 of gas, you need to attach 11 of gas, or your TX will fault by gas |
This is what I'm trying to avoid..... to know the gas without executing anything. In order words, for a O(K) length script, validate network fee in O(K).
You mean, the unused part of the |
How do you calculate the count of opcodes? We can't get the count from script size. You'll have to do some static analysis. But I think most of the verification can be done in the time of static analysis. So this may be a bit more than a move. |
I agree with erik, parse and execution will spend more time than execution |
Parsing is linear on the tx size, meaning that it is ultra fast. No parsing is slower than a single ecc check, even for a thousand bytes. |
We should do it on ApplicationEngine. |
This issue needs to be transfered to neo-project/neo#837, right, @igormcoelho? |
Perhaps this is dealt on neo-project/neo#789, yes? |
At the end, it was needed :) |
Many applications (so many!) could benefit of a jump-free execution mode, where execution is bound to the number of opcodes, at most. Could we provide such a way now? It could be a flag passed to the execution engine, e.g. nojumps. This would also require disabling recursive calls and perhaps all calls.
The text was updated successfully, but these errors were encountered: