Seemly like a wonderful idea,
but, what is a nxt scripts？
I'm not familiar with it. Can U provide some essaies for it?
Topic: Nxt :: Automated Transactions (AT) - progress and discussion - page 10. (Read 17307 times)
Hi, CIYAM.
Seemly like a wonderful idea,
but, what is a nxt scripts？
I'm not familiar with it. Can U provide some essaies for it?
Seemly like a wonderful idea,
but, what is a nxt scripts？
I'm not familiar with it. Can U provide some essaies for it?
Here is a test:
- Write a script that can forge blocks.
Will anyone challenge this task?
- Write a script that can forge blocks.
Will anyone challenge this task?
Maybe. What are the ground rules? Does it need to execute as a script on the blockchain? Or, can it operate on my node outside of the NRS Java process?
Only inside the sandbox with access only to blockchain data.
I think so, but not quite sure what you mean by BIOS? I think a main goal should be to limit access to local system as much as possible for security reasons.
I think he means that if our language is like Assembler then function calls - getLastBlock(), for example - are BIOS calls invoked via interruptions.
Here is a test:
- Write a script that can forge blocks.
Will anyone challenge this task?
- Write a script that can forge blocks.
Will anyone challenge this task?
As for me, I'm going to research the Lua VM.
Have heard some good things about it - the main question is can we have effectively API (or BIOS if you like) type functions with it?
Good luck for the project everyone. This will definitely kill most of competitors.
My thinking was that you might be able to get away with a SUBSET of the command set... but then you may lose Turing-completeness..?
Actually you'd be surprised - there is a "Turing complete" language that has only 1 op code (but I am not interested in trying to be "that minimal").
I think basing it on a well-known system like x86/x64 assembly would be terrific. Coders know it and it's well-documented!
The main problem with x86/x64 is the number of op-codes - to keep things simple if we are going to consider an existing "machine code" language then it should probably be more minimal than those.
My thinking was that you might be able to get away with a SUBSET of the command set... but then you may lose Turing-completeness..?
I think the RISC approach is interesting, too!
Thanks - yes - a RISC style approach is what I am thinking of also.
I think basing it on a well-known system like x86/x64 assembly would be terrific. Coders know it and it's well-documented!
The main problem with x86/x64 is the number of op-codes - to keep things simple if we are going to consider an existing "machine code" language then it should probably be more minimal than those.
I think basing it on a well-known system like x86/x64 assembly would be terrific. Coders know it and it's well-documented!
Okay - let's get "stuck into it" (warning - this topic is going to include a lot of "technical" discussion).
So first and foremost we have the problem of "what kind of scripting language should we use"?
In considering this we have to understand that we don't wont Nxt nodes wasting large amounts of CPU cycles on scripts when there most important function is of course to process Nxt transactions.
For this reason a "high level" language does not seem suitable (too hard to control) and instead a "low level" language (like "assembly code") seems more appropriate (we can control each "execution step" with a "low-level language" and not get tricked into accidentally executing long loops).
Also we need this "low level language" to be able to directly (and safely) communicate with the NRS otherwise it would be pretty useless (take the initial "use case" of sending dividends to shareholders - you need to know a few things like the "balance" and the "list of shareholders" to do this).
So - is there an existing "low-level" language (close to if not assembly) that is suitable or do we need to "roll our own"?
I am not sure of the answer to this question and look forward to your input.
So first and foremost we have the problem of "what kind of scripting language should we use"?
In considering this we have to understand that we don't wont Nxt nodes wasting large amounts of CPU cycles on scripts when there most important function is of course to process Nxt transactions.
For this reason a "high level" language does not seem suitable (too hard to control) and instead a "low level" language (like "assembly code") seems more appropriate (we can control each "execution step" with a "low-level language" and not get tricked into accidentally executing long loops).
Also we need this "low level language" to be able to directly (and safely) communicate with the NRS otherwise it would be pretty useless (take the initial "use case" of sending dividends to shareholders - you need to know a few things like the "balance" and the "list of shareholders" to do this).
So - is there an existing "low-level" language (close to if not assembly) that is suitable or do we need to "roll our own"?
I am not sure of the answer to this question and look forward to your input.
GREAT!
+100
Good luck and all the best to the everyone involved in this project!
+1
Thanks to @klee we have begun a project to enable "scripts" for Nxt which will provide a "Turing complete" method of executing code to do useful things such as "pay dividends to shareholders" of a Nxt Asset.
At this stage we are still "brainstorming" mostly and the code itself won't be publicly released until it is completed (we are aiming for the start of April to coincide with other important feature releases).
CfB and myself will be sharing technical lead on this project and will be working with a small focused team in order to get this done "right" and as "quickly as possible".
At this stage we are still "brainstorming" mostly and the code itself won't be publicly released until it is completed (we are aiming for the start of April to coincide with other important feature releases).
CfB and myself will be sharing technical lead on this project and will be working with a small focused team in order to get this done "right" and as "quickly as possible".
Jump to: