Conversation
|
|
||
| public TriggerType Trigger { get; } | ||
| public IVerifiable ScriptContainer { get; } | ||
| public IExecutionControl Control { get; } |
There was a problem hiding this comment.
This could be in neo-vm by default
Codecov Report
@@ Coverage Diff @@
## master #790 +/- ##
==========================================
+ Coverage 37.74% 37.74% +<.01%
==========================================
Files 176 178 +2
Lines 12442 12465 +23
==========================================
+ Hits 4696 4705 +9
- Misses 7746 7760 +14
Continue to review full report at Codecov.
|
|
What problem does this refactoring solve? |
|
We are able to ban opcodes in verification, and max amount of instructions to execute neo/neo/SmartContract/VerificationControl.cs Lines 6 to 23 in ca8de05 https://github.com/neo-project/neo/pull/790/files#diff-2753610b8764e06ef8ead3333db9b7aaR270 |
|
I think limit the max steps is useless. Limiting the max gas is enough. |
|
And the opcodes, like syscalls? |
|
Without SYSCALL, the verification script can't verify the signatures. There is no reason to limit it. |
| { | ||
| public class VerificationControl : GasControl | ||
| { | ||
| private readonly static List<OpCode> _bannedOpcodes = new List<OpCode>(new OpCode[] { /*OpCode.NOP*/ }); |
There was a problem hiding this comment.
Its in a good direction shargon, however needs a little more complication here. To ban backwards jumps we need to analyse the code and its first parameter... so, a callback returning true/false is better than a static list.
I've been thinking and another option would be to have different JMPF (jump forward) that can only jump forward. If we do this, its easier to ban. And create 3 more: JMPF, JMPFIF and JMPFIFNOT . A callback can avoid this and give more control on used opcodes.
There was a problem hiding this comment.
This gonna be an interesting thing!
There was a problem hiding this comment.
Do you want to handle these bannedOpcodes in this PR or split in two?
|
I really do not have the perfect understanding that you @igormcoelho, @lightszero, @erikzhang and @shargon have been sharing over these topics. However, biased or not, I am in favor of things that my brother @igormcoelho proposes, related to not being turing complete and remove the jumps in some special cases. After that, we should also please come back to that discussion about |
|
|
||
| public long GasConsumed { get; private set; } = 0; | ||
|
|
||
| public GasControl(long gas = 0, bool testMode = false) |
There was a problem hiding this comment.
Perfect, perfect, @shargon.
The refactor is precise!
It is much more readable.
I agree with it.
The other discussions out of the refactor and the class could be moved to other PR.
Maybe we can rename GasControl -> GasManager or GasTuringCompleteManager or GasTuringIncompleteManager...aehuaheuaheua
Turing is just for fun. Maybe GasManager or GasLimitsManager
|
Can we move with this PR? It has a nice refactor, maybe split this or leave this template and later adjust. |
|
ping @shargon...ahueahuea |
|
If all are agree i can fix the conflicts otherwise i will close it. Now i think that is not needed because we only check gas |
|
I think it's not needed anymore. |
* release-2.10.0 * Update v2.10.0.md (neo-project#785) * Update v2.10.0.md * Update v2.10.0.md * Update and rename v2.10.0.md to v2.10.0 * Update v2.10.0 * update exchange * Introduction for gas related rpc (neo-project#788) Introduction for gas related rpc * add plugin * Update v2.10.0.md * update English files
Close #789