Topics

Scorex 1.2.2 and roadmap for April

Alexander Chepurnoy
 

Dear Scorex maillist subscribers,

In the first place I am happy to announce new Scorex release 1.2.2 published on GitHub and Sonatype on last Sunday. Release notes could be found in [1].  the most significant modification is the exclusion of a runnable application. So from now Scorex is modular framework for developers only, and to launch application connecting to our first public testnet called Lagonaki, there is another repository for that [2]. Note that Permacoin implementation is externalized into another repository as well [3]. 

On Monday a new paper of mine has been published on Arxiv [4]. Basically it is about a new Proof-of-Work scheme reminds Permacoin but using state snapshots in the past instead of static dataset. Thus we can get some interesting bonuses, e.g. fast trustless bootstrapping and safe blockchain pruning(with purging old full blocks).

For Permacoin implementation we have developed static Merkle trees with on-disk persistence(as Permacoin is about huge trees). Later a Merkle tree functionality was extracted into Scrypto framework [5]. Now I'm working on versioned updateable Merkle trees within Scrypto.

Why authenticated data structures(and Merkle trees specifically) are important in a blockchain development? There are so many applications of them actually:

1. Light clients could get transactions and state elements along with proofs(see Buterin's "Merkling in Ethereum" [6]
). In Proof-of-Stake cryptocurrencies light clients could exist only if a state being Merklized(see White's paper[7]).

2. With Merklized state even fullnodes can store only a part of state(White's paper, again [7]). As a drawback that means increased transaction size and heavy transaction validation(due to Merkle proof check), the latter could be solved with SNARKs though.

3. They are needed in some consensus protocols, namely Permacoin and the new scheme of mine [4].

So I'm working on reworking Merkle trees implementation and will finish that work with benchmarking(e.g. 40M elements with few K updates, somewhat like block processing with current Bitcoin state).

After that I'll start to work on Ergaki specification. Ergaki is the next public testnet to be launched somewhen in the summertime. Unlike Lagonaki, it will be innovative in every aspect and based on work done in IOHK Research:

1. New proof-of-work scheme from [4], or, more likely, Bitcoin-NG - like scheme with proof-of-stake or some BFT algo for microblocks. Maybe Interactive Proof-of-Stake, also from me [8]. Rational behaviour by default, i.e. a node deletes blocks not needed for mining.

2. New transactional module. It will be about boxes [9], but not UTXOs from Bitcoin. Concrete proposal is to be decided yet.

3. New fees model. Basically, a fee will be not about transaction size, but state increasement size. So if a transaction is about state size lowering, it is about minimal or no fee at all. And storing boxes in a state will be charged not for size, but for life timespan also(with possible exception for a minimal template box). This way Ergaki would be intended to be not a digital gold but a public bulletin board for protocols mixed with an economy.

4. New difficulty adjustment algo. A paper on that is basically ready and will be released before summer.

As you can see, Ergaki could be called freaky in comparison with cryptocurrencies of today(especially because of the fees model I guess). But I believe that would be an interesting experiment. Also it would be a good test for Scorex flexibility.

Back to Scorex, we aim to have a minor release weekly. Next release will be about some bugfixing, and then we'll implement peers blacklisting(for now the network is vulnerable to rogue peers). For Lagonaki, we need to fix some issues with a Debian package and Docker image.


Summarizing, plans for April are to finish efficient updateable persistent Merkle trees, write down Ergaki specification, ensure Scorex is flexible enough for Ergaki implementation(and refactor if not), also bugfixing and network layer improvements in Scorex.



References:

Best regards, Alexander.