Turing-incomplete mode #1741
Turing-incomplete mode #1741
Conversation
Co-authored-by: Erik Zhang <erik@neo.org>
There was a problem hiding this comment.
Nice Erik,please wait for @igormcoelho and I to discuss.
neo-project/neo-vm#151 #837
|
Amazing step @erikzhang , certainly NEO gains a lot from this slight change. |
There was a problem hiding this comment.
In fact, I just noticed that this proposal will block if-then-else structure, wouldn't this be too limiting @erikzhang?
If only negative offsets on JMP are blocked (and all CALLs), we prevent all kinds of loops/recursions, without destroying the harmless ifs. If you worry about compilers, last time I checked the C# and Python were both generating loops in this format, which is the natural approach... anyway, if following this path, this should be made part of spec for compilers to fulfill.
Yes, it blocks if-then-else. But it will only be applied on the |
Ok, sorry for my misunderstanding. So I fully agree with you @erikzhang, InvocationScript should be highly limited. This is like previous approach of push-only, but written more concisely, I like it. So, regarding VerificationScript, any perspecting on also leaving it Turing-incomplete? I think it's important (but allowing ifs...). |
Are there any other potential applications? Turing-incompleteness seems to be useful conceptually, but at the same I'm not sure if we still have any problems for it to solve. There is a natural limitation to these scripts which is GAS available for them, do we really care about things they do with their GAS? Sure there is a question of unpaid failed verifications (like mentioned here: #837 (comment)), but limiting execution engine doesn't completely solve it either (as mentioned here: #789 (comment)), so maybe this question is more easily solved with (set by Policy contract) GAS limit (as was proposed here: #837 (comment)). It can also be enhanced with #1332 which just removes the VM out of the loop for most of transactions (so it can be economically motivated like using this verification type is cheaper than running a VM). So do we really need this? Are we really solving any problem we have that couldn't be solved in another (probably simpler) way? |
Yes, we need this, and this is the reason why Bitcoin doesn't have jumps and loops. Ethereum added GAS to resolve this, but they have explicit accounts, so it can be ensured that value will be paid in the end (with the exception of double spends and invalid address count nonces). Since NEO is even more flexible, I really don't see any other way around, because this computational effort hits directly the p2p nodes, which are not paid. The way it is now, there may be many dapplications that could heavily use Verification, but not in a long-term sustainable way. This proposed solution is quite simple (few lines only) and gives much more endurance to the project, while not cutting any feature. It's important to reduce InvocationScript, but I still hope to see some heavy limitations on Verification. |
|
I'm stupid, this doesn't solve the problem of |
|
Replaced by #1745 |
|
If you are stupid what are we? Ahahahah come on,Erik...ahahah |
Now I'm feeling highly depressed hahaha
It's not true @erikzhang, it partially solves the first part of an invocation... the next step is to limit verification backjumps. |
No description provided.