We don't need as less instructions as possible. We need a usable language.
Indeed I had thought that was what you *meant* (rather than what you actually said).  Do you agree that it should have op codes for things like SHA256 and what about the whole problem of the impact of running said scripts on the TPS rate? In any case, since 1000TPS is bandwidth limited, we dont really have any CPU bottleneck issues, unless you actually want to calculate crypto functions in the script instead of pushing it down with the script embedded in the AM |
|
|
|
We don't need as less instructions as possible. We need a usable language.
Indeed I had thought that was what you *meant* (rather than what you actually said). Do you agree that it should have op codes for things like SHA256 and what about the whole problem of the impact of running said scripts on the TPS rate? I have suggested that scripts be able to access a subset of NXT core, that would include Curve25... and SHA256 can be easily added if it is not there already |
|
|
|
CfB, what is your opinion of subleq? It seems we just need to implement one opcode.
There already exists Higher_subleq (assembly language) and C compiler, so that sure sounds like the quickest path. The CPU model they use doesn't seem too crazy.
James
We don't need as less instructions as possible. We need a usable language. OK, then one of the 28 to 32 instruction ones Edit: does this mean you don't consider C a usable language? |
|
|
|
If the network didnt check the forgers work than forgers could just publish false answers every time and claim the transaction fees anway. meaning they would have no incentive to actually execute the code.
The whole idea has security implications that we haven't even considered yet. This will turn out to be real bad for Nxt if malicious nodes are able to steal money. There are many other things in the pipeline: - Distributed Storage - In progress - Multi-signatures - In progress - Blockchain Shrinking - In progress - Two-phase Payments - In progress Software supported escrow transactions - Voting System - In progress - Reputation System - Will be implemented after Voting System Account trust rating system. Check if sellers on the distributed exchange have a good history, if stock issuers pay dividends and if gateways honor their asset redemptions. - Decentralized Mixing Service - Concept not ready - Cryptographers please contact core dev team members - Distributed Computing - Concept not ready - Smart Contracts - Concept not ready Why not work on these? It appears cfb has very short attention spam. Last week it was zerocoin, and now it's built in VM. I hope he doesn't follow through this and focuses on finishing things already listed. Maybe more trusted developers should be added to the team. Looking at his posting history, I will vote for "CIYAM Open". Etherium Edit: I think it would be really cool to do to Etherium what XCP did to mastercoin Edit2: Plus I think CfB was getting bored doing easy stuff, this is not so easy |
|
|
|
So the script will be able to access any AM in the blockchain. The app needs to seed the script with the required block#, etc.
Will the scripts have an easy way to access alias data also? If so, that could be another way to pass data to the script
Scripts will have easy way to access any data on the blockchain. Good morning Belarus!!! |
|
|
|
If it is about bandwidth why was everyone so worked up about inefficiencies of subleq?
So interpreted subleq VM is not a CPU bottleneck?
You are worried about bandwidth and amount of AM?
I do think that "subleq" would end up becoming a CPU bottleneck but I am now going on the assumption we have an *efficient* instruction set (so am now ignoring the CPU issue) but I think that even assuming no CPU issue the bandwidth problem will be an even bigger problem. I agree bandwidth is a big problem, but 1Mbps is supposed to available everywhere and much much more in Belarus I am worried about beefy hub servers. We need lots of them to support 1000TPS and if we are going to have all those servers anyway, might as well use the CPU power. I have a feeling without running Turing scripts they will get bored at 1% load factor |
|
|
|
Why would 1 millisecond execution time impact 1000 TPS transaction times?
Maybe reduce it to half millisecond time budget to give some room
Don't think in terms of real time. The VM is virtual. So is the time. Yes, but it is running on similar class servers, so we can estimate time to correspond to number of opcodes interpreted. Wont be exact, but as long as we charge by opcodes executed, all the scripts will behave in expected manner |
|
|
|
If all the nodes have to compute it, then all the nodes have to compute it.
So once again - do you want 1000+ TPS or do you want these "arbitrary script" type txs (as I don't believe that you are going to be able to have both)? you have convinced me for one CIYAM. another blockchain another day. i definitely think that nxt's proof of stake lays a foundation for a much better DAC than pow. someone should definitely develop a turing complete nxt, just not on this chain. What if we limited it to 100 Turing scripts per block? |
|
|
|
If all the nodes have to compute it, then all the nodes have to compute it.
So once again - do you want 1000+ TPS or do you want these "arbitrary script" type txs (as I don't believe that you are going to be able to have both)? you have convinced me for one CIYAM. another blockchain another day. i definitely think that nxt's proof of stake lays a foundation for a much better DAC than pow. someone should definitely develop a turing complete nxt, just not on this chain. Thought experiment time. Let's say each node gets to run an arbitrary program in a VM, but only 1 instruction per block. Will that impact 1000 TPS transaction times? How about 2 instructions per block? I think you see where this is going. N instructions per block (where N is variable based on the speed of the underlying hardware)? Will that impact 1000 TPS transaction times? Why would 1 millisecond execution time impact 1000 TPS transaction times? Maybe reduce it to half millisecond time budget to give some room |
|
|
|
1000 * 1 millisecond = 1 second
Call a 1 millisecond script a transaction and it is part of the 1000 TPS
generates the same fee so what does it matter the type it is?
Although the actual amount of CPU pain might not be overwhelming the problem is going to be the "size" of the tx. The whole 1000+ TPS is about "size" (and "bandwidth") more than it is about actual CPU time. If it is about bandwidth why was everyone so worked up about inefficiencies of subleq? So interpreted subleq VM is not a CPU bottleneck? You are worried about bandwidth and amount of AM? James |
|
|
|
If all the nodes have to compute it, then all the nodes have to compute it.
So once again - do you want 1000+ TPS or do you want these "arbitrary script" type txs (as I don't believe that you are going to be able to have both)? 1000 * 1 millisecond = 1 second Call a 1 millisecond script a transaction and it is part of the 1000 TPS generates the same fee so what does it matter the type it is? |
|
|
|
Why would all the nodes care if the email was sent out as per the Turing saved AM instructed?
You'd want multiple nodes to run it in order to check each other's work so it can be trustless. Otherwise, I could just write a malicious node to take your money and lie about the results. *Exactly* (had already made that point but I think it was missed). Guilty as charged. So most (all) of the network needs to run all the Turing scripts. We need beefy hub servers, if we have 1000 Turing scripts running per second, that would mean NXT is worth a LOT more! That is a lot of transaction fees. Which means there wont be that many scripts running all the time. I dont think runtime is as big of an issue as people are worried about. Interpreted VM can go pretty fast and I dont see the Turing scripts being thousands of lines of C code. The example code on etherium site was less than 20 lines of code. Even interpreted, very fast to run. James |
|
|
|
Why would all the nodes care if the email was sent out as per the Turing saved AM instructed?
You'd want multiple nodes to run it in order to check each other's work so it can be trustless. Otherwise, I could just write a malicious node to take your money and lie about the results. Is your name Bob?  |
|
|
|
Not necessarily. Just don't expect the result to be available by the next block.
CfB *himself* said 1000+ TPS would only be *possible* if protocol was changed to binary and kept "dead simple". So - how is it now suddenly become *possible* to also execute (even just a few) instructions of VM "per transaction" (as you can't assume they won't *all* want to do that) and still have 1000+ TPS? Does anyone else see the problem here? Don't tie them together. The VM runs in a separate thread from the Nxt protocol. Use the referenced transaction option of the Nxt protocol to link the result to whatever you want to do with it. It doesn't matter if the result comes in the next block, or 100 blocks later. I assumed the Turing complete stuff is application specific and does not need to be done by all the nodes. Why would all the nodes care if the email was sent out as per the Turing saved AM instructed? I think only the forging node has to run the Turing scripts. Turing scripts are not part of the NXT blockchain, they just utilize AM and alias to function. The key is to be able to reliably run an "algorithm", but more usually business process, like deposit/withdrawal. No heavy lifting as far as computation goes. James If the network didnt check the forgers work than forgers could just publish false answers every time and claim the transaction fees anway. meaning they would have no incentive to actually execute the code. Ah, Evil Bob! My brain hurts when I think about all the Evil Bob scenarios, so I leave that to you If all the nodes have to compute it, then all the nodes have to compute it. |
|
|
|
Not necessarily. Just don't expect the result to be available by the next block.
CfB *himself* said 1000+ TPS would only be *possible* if protocol was changed to binary and kept "dead simple". So - how is it now suddenly become *possible* to also execute (even just a few) instructions of VM "per transaction" (as you can't assume they won't *all* want to do that) and still have 1000+ TPS? Does anyone else see the problem here? Don't tie them together. The VM runs in a separate thread from the Nxt protocol. Use the referenced transaction option of the Nxt protocol to link the result to whatever you want to do with it. It doesn't matter if the result comes in the next block, or 100 blocks later. I assumed the Turing complete stuff is application specific and does not need to be done by all the nodes. Why would all the nodes care if the email was sent out as per the Turing saved AM instructed? I think only the forging node has to run the Turing scripts. Turing scripts are not part of the NXT blockchain, they just utilize AM and alias to function. The key is to be able to reliably run an "algorithm", but more usually business process, like deposit/withdrawal. No heavy lifting as far as computation goes. James |
|
|
|
We need some kind of a competition. The goal is to find a language with min number of opcodes.
OH NO! NOT BRAINFUCK !!!!!!!!!!!!!!!!! Apparently we managed to get even worse than that - I think maybe CfB might have changed his mind about this now. well this sort of thing would be a long way off anyways even if we did do it. the more i think about it the more i think about how important specialization is. these sorts of blockchains should probably best be built on a per application basis. one unique blockchain per dac. part of the beauty of nxt forging is that multiple blockchains can coexist with out competing for security resources. (atleast not in the way of a POW coin) Yes! I knew big brained guys will figure out the parts I cant. I just see the high level picture, need help with the details James |
|
|
|
Not necessarily. Just don't expect the result to be available by the next block.
CfB *himself* said 1000+ TPS would only be *possible* if protocol was changed to binary and kept "dead simple". So - how is it now suddenly become *possible* to also execute (even just a few) instructions of VM "per transaction" (as you can't assume they won't *all* want to do that) and still have 1000+ TPS? Does anyone else see the problem here? see above |
|
|
|
kill -9 after time limit is up. time limit = # NXT paid * milliseconds
The time it would take to run a program would depend on the underlying computer. This may lead to a given program with the same input succeeding when run on a fast/powerful computer, but not succeeding when run on a less fast/powerful computer. And it would mean the idea of "forging" on cell phones would be dead, aside from giving up fast transactions, 1000 tps, as some have been claiming. Services provided by "Service Providers" on beefy servers cell phones are expected to go to slim clients, forging via Account Control and pooled forging |
|
|
|
kill -9 after time limit is up. time limit = # NXT paid * milliseconds
You couldn't use "milliseconds" as the instructions would be processed at different times on different hardware. Understand that you'd ideally want *every node* to be able to verify *every transaction* which is going to have to include any VM script operations performed (otherwise how could you ever trust the "state" of the specific instance?). I guess "light nodes" could skip that work but that would lesson the security of the blockchain (if we are assuming that say only Hallmarked nodes are going to check the code has been executed correctly). I cant see how we avoid relying on hub (hallmarked?) servers. For advanced services we need beefy servers. I think CfB's plan was to simply count the number of instructions and then abort the interpreter session. If your loop exceeds the instruction limit, then it stops after 10000 opcodes are executed. Something like that. Time would vary based on server spec, but not too dramatically. I guess it wont be exact cost per millisecond, but approximate cost per millisecond of execution time James |
|
|
|
if on the other hand we tried to centrally plan this and dictate what sorts of code are acceptable and what sorts arnt, than who know what sort of innovation we may be stifling for lack of creativity and foresight on our part.
Good grief - suggesting ideas for a "useful instruction set" is now called "central planning"? So - let's say we go with the idea of the 1 instruction low-level language and we charge say 1 NXT per 100 "operations". Then a simple SHA256 operation will likely cost you 100's of NXT - so we have now a completely useless VM for doing SHA256 (but at least it wasn't "centrally planned" I guess). No one has answered what it will do 1000 tps claims?
Indeed - the reason why I was suggesting we would need a "practical" instruction set if we are going to bother with this at all. I would imagine much cheaper to pay 1 NXT for client generate AM that does any complex calcs. The scripts can access AM data, so the idea is for the higherlevel code to push down expensive to calculate data into AM How would it impact the decentralized exchanges without any third part gateways when even simple SHA 256 operations would be that costly? I think this will have serious security implications (and flaws). I doubt it work at all. CPU intensive calculations will be done in the client (or service module on hub) and pushed down to the Script via AM data The problem is not calculation time, as with proper allocation of work to the appropriate layer you have access to the local CPU, the hub server CPU before it goes into the molasses slow VM. The key to designing practical system is to minimize the work that the Turing script needs to do. Its goal is to generate AM data that is then processed by hub server modules and/or client My thinking on automating gateways already has several solutions using multisig approaches, I have posted before. However, I think there could well be a way to implement a method similar to XCP's escrow process followed by BTCpay. Just need to add LTCpay, DOGEpay, etc. There will certainly be bugs at first, but a gateway does not do any really complicated tasks. Deposit and withdraw. Not sure why you are so skeptical that it wouldn't work. I dont understand the multisig methods with timeouts in the articles, but I am sure someone else will. I also think someone else will be able to figure out an analogue for XCP escrow process. When someone says something is impossible, it only means that it is impossible for them to do it. I just keep asking until I find someone that says it is really difficult! James |
|
|
|
|
Show Posts
