Just to give a small update on what we are currently working on:
The current approach has totally disconnected the verification of work from the remaining verification routines (which are required to verify the consensus critical PoS operations). The reason for this approach were on the one hand some concerns, that people were feeling unsafe to execute "untrusted" code. On the other hand, the verification on each node would limit the amount of time a work-task may run: imagine, that a pretty complex job is on the network which takes around 5 minutes to execute. If miners work 5 minutes on it, everything is just fine. But if every node needs 5 minutes to verify the solution, it wouldn't take long until the entire network stalls.
So the solution was to use "super nodes" which do this complex verification stuff. Super nodes were meant to be super-efficient very fast computers capable of doing many many verification if a very short time. However, and you all are right, this means centralization and "blind trust". But in fact, a decentralized system is what we want.
Supernodes were working fine (see PoC from a few months ago) and they were using the native xel_miner application (written in C) to do the verification. Xel_miner was not only encapsulating the entire mining logic but also provided an API for super nodes, which could enqueue the transactions seen on the XEL network and semlessly receive the verification result for further processing.
We worked out a different (asymetric) verification method. This clearly limits the use cases to some extent but on the other hand it vastly increases the integrity of the entire blockchain.
The asymetric verification will allow us to code arbitrarily complex ElasticPL programs (they may run for hours) and define separate, much less complex verification functions (which finish in a blick of an eye). Verifcation routines must be coded very carefully (to avoid unwanted "trapdoor" solutions which do not reflect what we actually want) but there will be a developers guide sooner or later.
Now, this scheme allows us to move the verification back into the java code base and again perform the verification on all nodes. (All is not strictly correct, as you will learn in the next point). This way, we drop any super nodes and guard nodes, and avoid any kind of centralization at all.
Work should not be consensus critical:
In an early version of Elastic (way before the super node proof-of-concept) work transactions were regular transactions and were consensus critical. Probably everyone of those who followed the progress remember the chain forks due to some unforseeable error (differencies in floating point operations on different platforms could lead to a hard fork ... yes).
We do not want this, so we:
1. Do not model the work communication as actual transactions but as binary messages transmitted over the Elastic messaging system.
2. Only do work processing when a "work=true" flag is set in the config. If you do not want to participate in any working activity, you can leave this feature off and you will not participate in any verification whatsoever (good for those who do not trust any code). But if you decide to turn it on later on, you can just catch up by synching all new "unparsed" messages of this kind. This is possible, because the "sort-of parallel chain encoded in those binary messages" and the actual blockchain do not need to be in sync at any point. Well, let's not become too technical here!
The cool thing is: If something goes wrong with one work package, other work packages and, even more important, the entire blockchain remains unaffected by it. How the work-payments will be modelled in this "unconventional approach" will be revealed at a later point in time
Now comes the actual task:
And now comes the task, which causes so much work at the moment and which eats up every free second that we have: We have to port the C ElasticPL to JAVA ElasticPL - in a way, that both work in the same way, in all cases on all platforms.
I am half way through (all of it was done in the last week alone - it's been "burnout-ish"):
What is there is the Tokenizing (splitting up code into tokens) and the construction of the Abstract Syntax Tree.
This was pretty hard - and this basically defines the entire ElasticPL language. What is still missing is the interpreter, and this is what I will be doing next.
If someone wants to play around, just open the project linked above in IntelliJ Idea and launch it. You will not see much, but those of you, who really want to dig into it, will quickly find out how to verify that the AST tree is actually built correctly. Also: feel free to report any bugs or any inconsistencies between the C and the Java version.
Disclosure: I currently do hold XEL coins.