We would very much like to open source the steem monsters node software, and it will definitely happen at some point, but there are still some issues that we know of, and probably some more that we don't, that could cause multiple nodes to get out of sync / fork in certain situations.
We have limited resources and an unbelievably large list of changes and features, most of which are more important to keeping the business up and running than open sourcing the software, so we have to prioritize.
We are in the process of trying to raise funding now (something which is also quite time consuming) which should help us work on some of these items.
Also, please feel free to get in touch with me any time. I prefer Discord but anything works. I would also be interested in talking about your project and hearing your concerns with harpagon's project which we plan to use for some of our stuff.
Thanks for the info about SM open-source!
If I'm missing something, please tell me because I haven't done much research on the steemsmartcontracts project and might be missing something :shrug:.
My biggest concern with @harpagon's project is the lack of computational fees or computational limits per transaction. So someone could create a smart contract that on every transaction triggers a while(true) loop. Of course, there would likely be a limit put in place to stop that e.g. a timeout for 100 milliseconds for the transaction's computation, then all would be fine. But attacking this feature someone could create a more sinister contract, such as on a transaction something like this (obviously actually using the db api as in the code, this is just a proof of concept):
What this would do is break consensus among different nodes. Node A runs this for 100 milliseconds, at which point the loop had performed 10,000 iterations, leaving counter.storage at 10,000, while Node B, with a slower computer, only manages to reach 5,000 iterations, leaving its copy of counter.storage at 5,000. This would then break consensus between the nodes A and B. This wouldn't practically have any problems, because no smart contract wanting to be secure would use this, but it does mean that contracts have to be designed to maintain consensus.
Plus, with no computational fees, while(true) loop spamming would be easy because it would cost almost no RC, the transaction is nearly empty--which makes it theoretically less secure, but again, probably not practically. The only way to fix this problem would be to lower the threshold of compute time to something like 10 milliseconds so that the network could handle at maximum 30 transactions at maximum capacity per block, increasing the cost of attack. But low limits could introduce more problems.
What if there needs to be a 1,000 iteration loop in a smart contract? Node B is slower but Node A is faster, meaning that Node B halts transaction execution (it reaches the limit) and Node A completes the transaction because it has a faster computer, meaning that consensus is lost again, and this is probably the most practical and least theoretical flaw.
In all, I think steemsmartcontracts has a bit of theoretical flaws related to computation fees, but in general it's fine :).
thanks for your comments, these are indeed problems that we are aware of and that's why the mainnet will first not allow the deployment of smart contracts by the users (as the nodes are only protected against infinite loop for now), we will most likely open this feature once we are done testing the fees on the testnet.
For now, we are focusing on the contracts that will be shipped with the core code ;)
Hmm... any ideas on how fees could be done? Deterministic fees obviously couldn't work without a custom VM like the EVM, but maybe you could do some sort of compute time oracle?
Nice to see that that's something that you are aware of!
I read your most recent post, I'm interested in the proposals; I believe it's similar to how my project Engine will work.
But I'm wondering -- why the need to have seperate blocks and block producers, isn't that all handled by the Steem blockchain? e.g. couldn't you just stream transactions instead of having to seperate them into blocks?
I don't think that a fee on the computation time is necessary, at least if you have other forms of fees in place, the goal is to find a way to reach a consensus across the nodes and there are different ways to do that. (and that's why I built a blockchain/sidechain, these blocks will be used and verified by the block producers). I'm focusing on the core contracts now but once this is done, I'll go back to the fees/consensus implementation.
Regarding the proposal system, for now it's only accumulating tokens, I haven't yet decided on how they will be distributed but it will for sure use a stake based voting system.
I see with the fees and proposal system, but why do you need a way to reach consensus considering that Steem already does that for you? I’m just trying to understand — thank you for your time.
Basically, the Steem blockchain provides the consensus for the inputs but you need to have a way to reach a consensus on the outputs, If I take your example with the counters, if one node is somehow not able to reach 1000 loops, it will then provide invalid data, so you need to have a way to indicate that the transactions were (not) processed as they should have. Then you compare this output across the other nodes and try to reach a consensus. (but that's theory... for now I'm just thinking about a tool that will get the blocks from the nodes, compare them and expose the results of the comparison, that will easily show which nodes are not "doing their job" correctly so that you can vote them out if necessary. (as the nodes that are in the top 21 are getting tokens every time a block is produced)
Ok great; Stratos is doing a similar thing but I just don't call them 'blocks', I call them 'consensus checks'. Every 5 minutes or so every node (who opts in) posts a hash of their current state to the blockchain and compares that to everyone else's. So then you can audit whether the nodes are in consensus easily as well as tell if there is a problem with consensus while in testnet.
LOl did all of this become Steem-engine ? @shredz7 did ENGN become ENG ?
can you come talk to fyrtsikkena nd us on @steemspeak https://steemspeak.com about your non EOS STeemDAC ?