RandomJS

RandomJS copied to clipboard

Is this algorithm going to be implemented in any future forks?

@tevador , is there anything I can do to help get this implemented into wownero?

@VRRollerCoaster Yes, the original plan was to use it in wownero.

@Gingeropolous Currently the biggest issue is the EvalExpression (performance and compatiblity). The rest of the generator is ready to be reviewed.

I should have time to start working on RandomJS again around mid-September.

@tevador ,

I should have time to start working on RandomJS again around mid-September.

Great news!!!!!!!!! thanks!!!

Awesome!!!!!

Checking in on this. Is there anything I can do to help wownero integration?

@tevador , is there anything I can do to help with integration in wownero?

@Edgewalker9 @LordMajestros I'm still planning to do more modifications of the code generator to solve some potential issues. However, it might be possible to start integrating it now and only merge-in my changes later. Basically, this sample code needs to be integrated into wownero and deployed on testnet.

Currently, the development of RandomJS is stalled due to the following issues:

1. Poor performance of eval. I thought it was due to slow exception handling in XS, but it seems to be related to the performance of the parser and the fact that the argument of eval is re-parsed everytime it runs and not just the first time.
2. Resistance against "parser-skipping". Someone might implement a miner (in hardware or software), which skips javascript entirely and executes directly the expression tree generated by RandomJS. Some ideas how to prevent this are mentioned here: https://github.com/tevador/RandomJS/issues/10#issuecomment-429266593
3. Better formalization of the Javascript generator. IMO functions calls/recursion should be more emphasized as opposed to pure expression evaluation. Expression weights must be adjusted for optimal performance on CPUs. The generator is not production-ready at the moment as the weights and types of expressions were chosen almost arbitrarily.

All 3 major issues are related to the fact that we have to make sure there will be no unexpected optimizations.

eval performance may be greatly optimized by parser skipping and also execution skipping. Most of the time it suffices to simply know whether the expression is valid or whether it generates a syntax error. This simple optimization will short-circuit 95% of the cases without any evaluation whatsoever.

Unexpected optimizations are inevitable for any complex proof-of-work. For example, I think we can agree that random code generation, compilation, and execution is greatly more complicated than CryptoNight, yet the "simple" CryptoNight has been the subject of many optimizations over many years. Random code generation is hella complicated and IMO there's no way we're going to foresee all the optimizations.

Another issue is that due to its complexity, I'm not sure if RandomJS can ever pass the strict review needed for its adoption in Monero.

It would probably need expensive third-party audits like Bulletproofs. The audits would also have to include the entire Javascript engine to make sure there are no critical bugs.

Yes, the generator and the execution engine would both be subject to independent audit. This would be true regardless of whether we were using Javascript or RISC-V machine code or any other target. This has always been understood to be a requirement.