The Bitcoin code base is more than 100 thousand lines of mostly C++ code, where NXT (the first working implementation of a proof-of-stake system) is more than 45 thousand lines of Java and all the parts/components that make up the system(s) are enmeshed together in a way making it difficult for researchers and developers to carry out reliable experiments on that basis (also sometimes referred to as Bitcoin's technical debt). So, Scorex comes in here as a modular blockchain development framework built and maintained by IOHK (the company developing Cardano and sometimes also working on Ethereum Classic too).

Scorex is in contrast less than 4 thousand lines of Scala (Scala itself a functional language geared towards mission critical systems and such) and modular in the sense of how it handles different parts of the system as loosely coupled components. This is a really cool and quite useful addition in IOHK's arsenal of research and development tools and also in line with their engineering philosophy and mission statements (of separating concerns in distinct layers and operational logic contained in inter-operable modules, etc. and, as a company, in building high quality tools and working prototypes for blockchains).

It comes with a simple transactional layer and two out-of-the-box consensus schemes (2 PoS, one NXT-like and one Qora-like and an additional PoW module) that are easily swapped in and out by just editing a line of code.It provides an asynchronous network layer on top of TCP, a JSON API (and a command-line client for it) and a set of cryptographic primitives available in a separate scrypto framework.

Scorex is so designed as to allow a broad range of systems and system configurations to be easily assembled and put together, choosing and combining consensus protocols with transaction/block/ledger types in a peer-to-peer networking infrastructure (which may even include multiple block types and/or non-linear histories). Scorex has a core and complementary modules, some of which are production ready while others experimental prototypes. As a foundation for building blockchain systems and cryptocurrencies, Scorex is designed to be modular, performant and secure (notably, Waves was built on top of the Scorex framework).

Basic Components

Every crypto-currency implementation has four basic components:

• Network Protocol: Peer-to-peer networks implemented with asynchronous message exchange, defined message types, gossip protocols, etc.
• Consensus Protocol: Consensus protocols decide on the right canonical chain according to a set of rules (e.g., every block must be valid, signed, reference the previous one, "longest chain rule" in Bitcoin, etc.)
• Transaction Protocol: Blocks contain transactions and transactions are global state modifiers. In the simplest case, modifying a balance sheet. Every node on the network must have the same current state as all other nodes for the same block height and each node executes all the transactions in incoming blocks, following the same validation rules as every other participating node in the network. Transactions can be implemented in various different ways depending on the purposes and goals (in Bitcoin they have multiple inputs and outputs with a script attached to every pin, while Ethereum has contract creation/instantiation type transactions and message call transactions that call functions in contract code).
• Internal State: The global/system state representation interface, in Bitcoin that's lists of UTXOs, in Ethereum it's the state hash stored into each block as per the standard state representation interface given in the Yellow Paper.

A generic block structure typically consists of: 

1. Pointer to the previous block before it, making a chained sequence.
2. Consensus-related data, e.g. nonce and difficulty target for Bitcoin or generation signature and base target for NXT.
3. The transactions, which may include other transactions or state-related data or meta-data, such as Merkle tree root hash for the transactions, etc.
4. Additional useful information: block structure version, timestamp, uncles, etc.
5. Signature(s) of who did what, who validated or mined this or that block, etc.

Creating a new blockchain-based crypto-currency typically means replacing (2) and/or (3) with something new. 

We'll get in more practical detail and code snippet examples later on, perhaps in a follow up post. For now we'll just give a general overview of the framework.

Scorex Features

Scorex requires Java 1.8 (must install the JDK from Oracle's site) and it consists of a number of JARs containing a number of features:

• scorex-basics: the framework's core.
• scorex-transaction: transactional layer implementation.
• scorex-consensus: NXT/Qora consensus implementations.
• scorex-perma: Permacoin consensus implementation.

Additional/Extra Modules and Experimental Prototypes: On-chain Treasury, Hybrid PoS/PoW Chain, Etc.

The PoW module is available separately and there's other concepts and experimental prototypes available and being built/developed (following the higher level specifications as per their respective papers), one particularly interesting one (for me anyway) being a proof of concept implementation of an on-chain treasury system based on the specs described in the paper "A Treasury System for Cryptocurrencies: Enabling Better Collaborative Intelligence". The treasury system introduces new transaction types and a separate treasury state, facilitating voting protocol and proposals funding of the ecosystem/chain.

A presentation of the on-chain treasury system for governing and managing the sustainable funding of a system/blockchain's long-term maintenance and development. 

The Scorex distribution also includes one working example of a blockchain system built on Scorex, TwinsCoin. Twinscoin is a hybrid PoW/PoS currency with complete correspondence between PoW and PoS blocks, the purpose/goal of which being protection of the hybrid chain against adversarial majority hashing power. The implementation uses its Twinscoin consensus protocol and a Bitcoin-like transaction model of multiple in- and outputs w/o the scripts.

Quick Commentary

The above might come quite handy and picking up Scala on the level of using Scorex doesn't seem like something too impenetrably obscure or low level machinic (obviously not as simple if one is to translate some specification into code, but for the purposes of just using what's already available and tweaking it and playing around with things, it's fairly straightforward and self-explanatory and also appears well documented too). That treasury prototype I find a really cool idea, I think it also implements liquid/delegative democracy regimes and zero-knowledge proofs and other such cool things like that. Think, for example, about the possibility of deploying some such governance system on your local or municipal levels, of district or community or whatever (just as an example).

Scala as such is also known to be highly reliable and, yes, as mentioned earlier, the Waves platform was built on Scorex. The guy who launched/built Waves had previously worked in developing NXT along with Sergei Ivancheglo, who is now known to have also been the creator of the IOTA token and one of the four founders of the IOTA project and foundation. I'll share some more how-to's and such to do with Scorex at some point soon if there's interest in it (or even if there isn't, as sometimes I almost as if post here to keep track/document some things that are one way or the other also important to myself).

Some Links and Resources

Scorex wiki and tutorial/documentation.