Quote from: CIYAM Open on February 08, 2014, 10:41:46 AM

Quote from: jl777 on February 08, 2014, 10:33:16 AM

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

Now we are perhaps getting to the core problem - basically you need to have operations that don't have harmful side effects (so sending emails or the like is a very bad idea).

So consider "sending a BTC transaction" (not that this is perhaps the best idea) - one can send it without harm even if it has already been sent (in fact if you were using bitcoind then your own instance wouldn't even try sending it again if it has already seen it). These are really the only kind of operations you want to be performing.

Yes, I do not imagine we want to allow plugins to be able to do everything. We need to have constraints on what the plugins are allowed to do and source review will need to be the basis for trusting that the constraints are followed.

maybe just stipulating that the plugin works on a best efforts basis and there always needs to be an independent method for verification (presumably with automated retry and other error handling)

If we constrain the set of actions to an allowable set of things to do, that eliminates a large set of issues

for instance, we can have a plugin that queries a website and puts the JSON data into an AM, maybe it gets good data, maybe server error, but if we can be assured that it actually made the query then we can trust the data in the AM.

It seems we again come to needed zeroknowledge proof that code was executed. All of the cool features seem to revolve around this same zeroknowlege proofs.