Another post from me, now on "production readiness".
It is hard to develop a database engine. Jan Kotek is a brilliant dev undoubtly but there's no stable MapDB release around after few years of active development,
Cryptography isn't just hard, its a mess. It is really hard to implement a primitive properly(!) (e.g. a signature scheme). And even a perfect implementation cant' save against improper usage or bad randomness. Things are much harder when we're talking about design and implementation of cryptographic protocols.
A cryptocurrency can dev go nuts. It is a crazy mix of many hard-to-develop things. And if millions of users put billions collectively at stake, software behind that must be polished like a diamond. Unfortunately, amongst thousands of coins(few IPOs to be declared daily on this forum) there are only 1.5 seriously validated systems(so Bitcoin, after few years of issues fixing, see
https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures, and partly Ethereum).
So Scorex was declared to be not ready for a production use. Since 1.1.0 modular design is there, so a consensus as well as transactional modules are to be injected into core. Since 1.2.0 only core is to be called Scorex, and our first testnet application running on Permacoin consensus protocol is being called Lagonaki.
Let's take a closer look on readiness of modules:
1. Core: no any protection against any DDoS atm. Peer blacklisting is just done(in 1.2.3). Networking layer is quite raw. Other things in the core are seem to be pretty OK.
2. Nxt-like consensus module: unlike Nxt, "effective balance" == balance and that is trivially insecure. There are many small tweaks in Nxt not copied into the module(I am pretty unsure all of them are adding up to the protocol security though).
3. Qora-like consensus module: again "effective balance" == balance. Aside of that, algo is copied pretty precisely.
4. Permacoin consensus module(
https://github.com/ScorexProject/Permacoin-consensus): there are some open question in the protocol design itself (see my paper
http://arxiv.org/abs/1603.07926 ). Our implementation isn't tested on really huge datasets.
5. Simplest transactional module. Simplest tokens transfers (like Nxt payments) and nothing more. Protection against double-inclusion is quite stupid(account nonces like in Ethereum are needed).
So yes, all the components must not be used as provided in a popular cryptocurrency. And I'll eventually fix only core issues. I'm going to implement next few modules(more innovative this time) and a new testnet application with working name Ergaki (
https://scorex-dev.groups.io/g/main/message/3?p=,,,20,0,0,0:Created,0,,20,1,0,1996315 ).
But Waves doesn't need anything except of core probably. They will build own transactional and consensus modules. Then it is Waves business to prove those modules are shine like a diamond.
P.S. On a team's photo, I was offline for those days, so do not really know what happened. I need to have another call with Sasha to clarify.
