This repository has been archived by the owner on Nov 22, 2023. It is now read-only.
Mode to disable backward jumps on NeoVM 3 #174
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #151
First of all, thanks for all the things you guys made me learn in the past months, it has been an amazing opportunity for me, to improve coding skills, testing skills, and learn more about cryptography and all kinds of stuff around a blockchain ecosystem like Neo.
After much thoughts, and many discussions with many different people, I think that we need an execution mode on NeoVM that would allow us to disable backward jumps. This disables loops on practice, although not generating problems to
if
s. This also disables recursive calls.Just a brief back in history, Bitcoin has become famous, and one of its explicit flags has been the capability of not having Turing-complete compution in its verification engine. It also doesn't have this sort of computation on Application Engine either (since it doesn't have one 😂), so I think Neo could benefit of also not having it on Verification trigger, while maintaining a full powerful Turing-complete application engine.
Verification and Application are very different things. Verification needs to be denied as quickly as possible, when necessary, without consuming too much resources from the network, while Application can be much more expensive, since it is paid in advance in Gas. If someone wants to have an infinite loop on Application, it doesn't matter, it will take time, and this time will be well paid on System Fees, no worry (and it will FAULT and be discarded in the future). But we cannot afford having this type of computation on the Verification engine, where nothing is actually paid (yet) to the network.
Disabling Turing-completeness can be done on several manners, one of each is simply removing backward loops, like done here. There even more severe strategies, like removing all sorts of computation from here (thus basically removing the Verification Trigger away). This is an attempt to keep the verification trigger, which is useful for several stuff, while keeping it well contained and fast to process.
Hope having a heated discussion here, but thanks in advance anyway ;)