Quote from: Come-from-Beyond on February 07, 2014, 10:40:16 PM

Quote from: jl777 on February 07, 2014, 10:38:16 PM

If BCNext likes what you are doing, you will get added to NXT credits API!

BCNext likes every attempt to review his ideas.

I will present a proposal on NXT core change that will give NXT fundamentally more value and allow it to become platform for all types of new functionality. Like Internet protocol did.

First, I want to make sure I at least understand the current expected implementation of NXT VM (Turing scripts) as to what it is able to do. My understanding is that it will be able to access the "entire state of NXT blockchain", so aliases, AM, etc. anything that is in the blockchain, it can access. With the concept of externally pushing down into an AM any additional data needed, the input side for the NXT VM seems well covered.

It is the output side that I am concerned with. I believe as it stands now, it will be able to send NXT and save an AM. My proposal is based on this limitation. If this is all that NXT VM can do, it means that ANY OTHER side effect of NXT VM cannot be trustless nor decentralized.

For clarity, let's say "side effect" is to send and email. I choose this example as I assume it is possible to send an email using Java with little effort and jean-luc won't yell at me about making him do horrible things to the code. The NXT core email SMTP side effect, can generate a hash on the contents and recipient of the email and use that for TXID to be put into NXT email blockchain (or even main blockchain). The importance of something being in the blockchain is that it can be validated by all on the network. The importance of being implemented in the NXT core is that it is the only way for it to be able to be trusted.

So, using the above mechanism, any side effect that can be implemented into the NXT core can implement a decentralized and trustless solution that is controlled by the NXT VM script. However, one problem that I see is that there is no assurance that the NXT VM's output AM is going to be parsed properly and the NXT smtp invoked.

Without a way to assure a once and only once invocation of "side effect" that we can rely on being used, the power of NXT VM is limited to the self-enclosed NXT universe. On the other hand, if we can ensure that "side effects" that are supported by NXT core do in fact get executed, it opens up vast new possibilities. VAST!

I want to take it one step further by having a NXT-plugin architecture defined. There are just some things that even I wouldn't want shoved into the NXT core, let alone jean-luc! So, we need a way to ensure that such external plugins are executed once and only once (similar to double spend problem). I imagine that not all NXT nodes will have support for all external plugins, but as long as the NXT hubs (> 100 servers) can run these external plugins, then I believe it will work.

So, finally here is my attempt at utilizing TF for this as so far it has been pretty mechanical. Assuming that the vast majority of forging is done by NXT nodes with a full set of external plugins, then within a reasonable number of blocks, the plugin will get invoked. We can use TF to see how many blocks we need to wait for the first forged block that is on a node capable of executing the external plugin! This is SUPER useful, since otherwise we would need to try to invoke the plugin, wait for error and then retry. MUCH better if we minimized errors in the first place.

I hope this is close to what BCNext is looking for?

Generalizing, for any plugin functionality there needs to be a way to invoke it once and only once and a way to verify it on all other nodes. For hardcoded plugins, we avoid the whole verification process. If there is a way for the NXTcore to get a read only pointer to the memory space of the plugin code space, the NXT core can add a function to verify the hash of the code space to verify that it is still running an unmodified version since the published source code of that plugin. So, maybe we just need to memory map the plugin and find its code, hopefully not too hard to do. Verification that the plugin has not been modified goes a long way to preventing Evil Bob from changing the code that implements the plugin. If the plugin code cannot be changed and it is correlated to published source code, then maybe even skeptics can trust that the NXT plugins will always do what they are supposed to. [I avoid discussion of proper error handling within the plugin as that is specific to each plugin]

So, at the very least the hardcoded plugin will allow NXT VM to affect the world outside the NXT blockchain and this is the key to being able to implement DAC. If we can make NXT plugins secure and verifiable, then NXT will be the first platform that allows anybody to create new functionality that is decentralized and can operate without trust by simply defining a "side effect" and a way to verify the side effect was actually done. Combine this with Transparent Forging's ability to predict the future forging nodes, allows a subset of NXT infrastructure to perform the plugins work.

Needless to say, achieving the above will make NXT like the Internet was when the only thing you could do was email. Order of magnitude increase in the utility is probably a gross underestimate.

James