The opcodes DUPFROMALTSTACK and DUP should return a clone instead of reference to stackitem about neo-vm

[anthdm]

@shargon The fix I had in mind will not break the chain in any case. It just needs some adjustments in the compilers. I totally understand that this will not be implemented before 3.0. I think in NEO 3.0 we will need to rethink the whole VM memory system. I feel like we are not utilizing all the stacks well enough.

[lightszero]

@lightszero do you think that we should implement this in neo3?
@shargon

I dont think so,i think a CLONE opcode is more better,just use CLONE when need.

[anthdm]

@igormcoelho DUPFROMALTSTACK will duplicate the array from the ALTSTACK on to the EVALUTATIONSTACK. After that, we SETITEM index 0 of the array on the EVALUATIONSTACK with SETITEM. SETITEM will pop the cloned array from the EVALUATIONSTACK and set the index 0 to 10. So we will overwrite the array on the alt ALTSTACK (shares the same pointer) with an operation that occurs on the EVALUATIONSTACK. SETITEM will not push something new on the stack. My issue is that operations on the ESTACK may not affect the ASTACK directly.

[anthdm]

To be more clear here: Stack machines never ever modify memory directly. The following should be some of a more correct implementation:

1. pop the item (array) from the ALTSTACK onto the ESTACK
2. modify the array (SETITEM) 
3. PUSH the modified array back on the ALTSTACK

[anthdm]

The contracts can still exist and operate with no issues. However, all the compilers need to be changed.

[igormcoelho]

I guess this breaks all contracts I've seen,because all of them update and pop parameters, what does not makes sense without collateral effect. I agree thats strange, but I dont see any way of attacking , specially if stack isolation effectively clones items to other stacks...perhaps its an enhancement for stack isolation itself.

[anthdm]

@igormcoelho Old contracts will not break if the VM changes the way it handles this. Just imagine there are as a couple of addresses in an array on the ALT stack. One could modify the pointer directly to change the address to any address he wants. However, I must agree that I do not see a simple and effective way to attack this. I would like to exclude any possible attack vectors possible and see this as a potential one.

[igormcoelho]

Perhaps I'm misunderstand something, but take a look at this simple code void main(int x) { x = 10; }, it usually generates the following operations:

5a PUSH10  # The number 10 is pushed onto the stack.
6a DUPFROMALTSTACK  # clone top element from altstack to mainstack
00 PUSH0  #An empty array of bytes is pushed onto the stack
52 PUSH2  # The number 2 is pushed onto the stack.
7a ROLL  # The item n back in the stack is moved to the top.
c4 SETITEM  # v[0]=10; sets element v[0] to top stack element 10, and DROP v

You can see that this sequence clones something from altstack to mainstack (in this case it's an array that stores all local variables), performs this 0, 2, roll, setitem, which basically takes the element before dupfromaltstack and puts on position 0 of the array taken from altstack. The thing I took some time to understand (and you can see in code below), is that after this operation, the array is virtually dropped from stack, because this sequence only performs pops and no push. So the effect of the attribution only happens in the original array at altstack because its "clone" is exactly the same array (as a collateral effect). PLEASE, correct me if I'm wrong, because I may be very wrong!! :)

https://github.com/neo-project/neo-vm/blob/master/src/neo-vm/ExecutionEngine.cs#L763-L791

[igormcoelho]

Ok, but we agree that this is the current behavior for all deployed contracts and verification accounts, right? If we change this right now, it's sure we will break everything, because we would need to know exactly how all contracts until now are using this shared pointer situation... it's like starting another neo-vm from scratch, in my opinion. Besides, we will also need to change all compilers. Perhaps a more feasible option would be to create new opcodes, that actually clone data instead of keeping references. Then, new codes/compilers would be aware of this safer behavior, and generate code accordingly.

[shargon]

If you change the logic of one OPCODE you break the chain, this could be something for NEO 3.0

[shargon]

@lightszero do you think that we should implement this in neo3?

[igormcoelho]

I wonder about this all the time, recently...
Global variables are already depending on this behavior, because they pop a copy of last value (static vars), and update this array consuming it. The side effect is an update of the other array, on the bottom of altstack.
It could indeed return a copy, and then push again to the bottom of altstack.

The problem is see is related to general attributions, x[4] = object, that MSIL treats as a reference type instead of a value type. But I think we could change that too, the moment is now.

@anthdm do you have a reference on this, I mean break stack isolation is against the model.., is it really worth the change?

[igormcoelho]

CLONE is a nice idea @lightszero , I fully agree.

@anthdm I think I understand your point that side-effects break the concept of pure stack-based computation. I also see this as a "impure" situation. However, I did some research on stack models, and since the 70's I couldn't find a single stack machine (Turing Complete) which is pure. All of them allow side-effects between stacks, or extra registers, or extra global variables, or extra linear memory... In all of these cases, it looks like these things were added to give more flexibility and improve performance. So, I think that CLONE is a nice idea, because it allows a compiler to be "pure" (and do not use side-effects), but it keeps the possibility of others doing that. I still think that compilers will end-up using side-effects to represent global and local variables concepts from higher-level languages, and it would be a big challenge not to do so. As long as stacks are isolated and protected, nothing bad can happen.

A good example is on this interactive tutorial: https://neoresearch.io/nvm-learn/#arrays