What a peer would do is have to run the script itself (get used to the fact that the script will need to run on *every* peer except perhaps for some lightweight ones) and compare it's result to that being suggested by another peer.
This is why the script's state must be "deterministic" if a peer tells you that the answer to running script A with state X results in state Y but you think it results in state Z then you ignore that block as being invalid and block the peer.
I am agreeing with you here. The script is run on all non lightweight peers, output AM needs to be deterministic and the same across the entire network. that is the assumption I am working with.
Encoded in the output AM is the trigger to call a specific plugin with specific data, identical for all nodes.
So far I think we are on same page. Where is the flaw in my logic? Do we need super fancy zeroknowledge stuff or even more complicated obsfucation algos to make sure that the NXT core validated the plugin before it was called?
I think that is the weakness you are pointing out. How to verify that plugin verification was run by forging node. I dont think all nodes need to be verified with proper plugin because only the forging node is responsible for "side effects" from NXT VM scripts. I am pretty sure we cant have more than one node doing side effects, especially if it involves transactions