Scorex 2.0 Pre-Announce
Dear maillist reader,
Last release 1.2.8 was on Jun, 9th. Does that mean development is not active at the moment? No! We are working hard towards a very major release 2.0.
Scorex 1.x was built with an idea expressed by L.M. Goodman. The idea is that a cryptocurrency design is about few protocols: network, consensus and transactional (my article on that: http://chepurnoy.org/blog/2015/08/a-cryptocurrency-architecture/ ). Implementation of the idea in Scorex is described in "On the Way to a Modular Cryptocurrency" blog series ( http://chepurnoy.org/blog/2015/10/on-the-way-to-a-modular-cryptocurrency-part-1-generic-block-structure/ ) and wiki.
There are still some problems about flexibility of design in Scorex 1.x
- Full block is signed with pre-defined signature scheme. In Bitcoin there is no signature for a block or a blockheader (in PoW that is an overkill). Full block/blockheader separation is impossible, as well as Bitcoin-NG microblocks etc.
- Signature scheme is hardcoded into transactions, only simple signing is possible(no Bitcoin-like scripts).
- Node state being updating via impure functions returning just Unit(so hiding all the effects). Even worse, updates are spread around the codebase.
What is coming:
- The most abstract authentication model possible, just (trait Proposition) and (trait Proof[P <: Proposition]) in the bottom.
- Abstract state elements, just (Box[P <: Proposition]) in the bottom(you can get Bitcoin-like output or Ethereum-like account from a Box)
- Very abstract transaction notion in the bottom as well
- Updates return new version of an entity.
- Centralized storage of a stable reference to a node state. Node state is a quadruple (State, History, MemoryPool, Wallet). On block processing, for example, all the components are to be updated. Update semantics is to be defined clearly. We can get laws checking easily for such approach. For example, with property testing we can check the law: "for any quadruple, if we apply N valid blocks and then go back for N version, the resulting quadruple will be the same as original one". Then a machine will generate thousands of test samples and check the law against them. Also, it would be much easier to find bugs of read-when-update kind (very painful to find usually).
- Flexible hierarchy of node state modifiers: transaction, full block, block header, state snapshot, key and micro blocks etc.
- All the modules are to be extracted. So Scorex core (with < 4K LoCs) will fit in the dedicated repository. Maybe some example micro-application will be provided (really micro, with in-memory storage etc).
- Wallet reworked
The list is not final. I still need to figure out some things before first milestone version.
Later we will need to improve network layer(peer discovery etc). That's planned for 2.1.
And we are preparing manual for Scorex 2.0 to describe a new design with finer granularity. A current draft is about 23 pages at the moment, final version will be about 30-40 pages. The manual will be released along with the code.
I would be happy to get our concepts and code reviewed. Let's discuss them over this maillist and chat ( https://gitter.im/input-output-hk/Scorex ).