Sparkster has finally opened its code repositories to the public, and as
the project has been somewhat in the centre of discussion in the crypto
community, as well as marketed by one of the high profile crypto influencers,
we have been quite curious to see the result of their efforts.
The fundamental idea of the project is to provide a high-throughput
decentralized cloud computing platform, with software developer kit (SDK) on
top with no requirement for programming expertise (coding is supposed to be
done in plain English). The idea of plain English coding is far from new and
has been emerging more than a few times over the years, but never gotten any
widespread traction. The reason in our opinion is that professional developers
are not drawn to simplified drag & drop plain language programming
interfaces, and non-developers (which is one of the potential target groups for
Sparkster) are, well, most probably just not interested in software development
However the focus of this article is not to scrutinize the use case
scenarios suggested by Sparkster (which do raise some question marks) but
rather to take a deep look into the code they have produced. With a team
counting 14 software developers and quite a bit of runway passed since their
ICO in July 2018, our expectations are high.
Non-technical readers are advised to skip to
the end for conclusions.
Source code review
Sparkster initially published four public repositories
in their github (of which one (Sparkster) was empty). We noticed a lack of
commit history which we assume is due to a transfer of the repos from a private
development environment into github. Three of the above repositories were later
combined into a single one containing subfolders for each system element.
The first impression from browsing the repositories is
decent after recent cleanups by the team. Readme has been added to the main
repository with information on the system itself and installation instructions
(Windows x64 only, no Linux build is available yet)
However, we see no copyright notes anywhere in the
code developed by Sparkster, which is quite unusual for an open source project
released to the public.
Below is a walk-thru of the three relevant folders
containing main system components under the Decentralized-Cloud repository and
a summary of our impression.
The source code is written in C++. Everything we see
is very basic. In total there are is not a lot of unique code (we expected much
more given the development time spent) and a lot of the recently added code is
GNU/forks from other projects (all according to the copyright notes for these
An interesting part is, that if this master node
spawned the compute node for this transaction, the master node will request the
compute node to commit the transaction. The master nodes takes the control over
more or less all communication to stakeholders such as clients. The master node will send a transaction to 20
other master nodes.
The lock mechanism during voting is standard: nodes booting
in the middle of voting are locked and cannot participate to avoid incorrect
We cannot see anything in the code that differentiates
the node and makes it special in any way, i.e. this is blockchain 101.
All source files sum up to a very limited amount of
code. As the master node takes over a lot of control, the compute node focuses
on the real work. A minimalistic code is generally recommended in a concept
like this, but this is far less than expected.
We found the “gossip” to 21 master nodes before the
memory gets erased and the compute node falls back to listen mode.
The concept of 21 master nodes is defined in the block
producer. Every hour a new set of 21 master nodes become the master node m21.
“At any given point in time, 21 Master
Nodes will exist that facilitate consensus on transactions and blocks; we will
call these master nodes m21. The nodes in m21 are selected every hour through
an automated voting process”
The compute node is somewhat the heart of the project
but is yet again standard without any features giving it high performance
The source code is again very basic. Apart from this,
the code is still at an experimental stage with e.g. buffer overflow disabling
being utilized, something that should not be present at this stage of
Overall the storage uses json requests and supports/uses
the IPFS (InterPlanetary File System). IPFS is an open source project and used
for storing and sharing hypermedia in a distributed file system. The storage node
not only handles the storage of data, it also responds to some client filter
In total Sparkster has produced a limited amount of
very basic code, with a team of 14 developers at their disposal. As their announcement
suggests that this is the complete code for their cloud platform mainnet,
we must assume that the productivity of the team has been quite low over the
months since funds were raised, since none of the envisioned features for high
performance are yet implemented.
The current repository is not on par with standards for
a mainnet release and raises some serious question marks about the intention of
the project altogether. The impression is that the team has taken a very basic
approach and attempted to use short cuts in order to keep their timelines
towards the community, rather than develop something that is actually unique
and useful. This is further emphasized by the fact that the Sparkster website
and blockchain explorer is built on stock templates. We don’t see any sign of
advanced development capability this far.
Based on what we see in this release Sparkster is
currently not a platform for ”full scale support to build AI powered apps” as
their roadmap suggest and we are puzzled by the progress and lack of provisioning
of any type of SDK plugin. The Sparkster team has a lot to work on to even be
close to their claims and outlined roadmap.
Note: we have been in contact with the
Sparkster team prior to publishing this review, in order to provide opportunity
for them to comment on our observations. Their answers are listed below but doesn’t change our overall conclusions of
the current state of Sparkster development.
“We use several open source libraries in
our projects. These include OpenDHT, WebSocket++, Boost, and Ed25519. In other
places, we’ve clearly listed where code is adapted from in the cases where
we’ve borrowed code from other sources. We’ve used borrowed code for things
like getting the time from a time server: a procedure that is well documented
and for which many working code examples already exist, so it is not necessary
for us to reinvent the wheel. However, these cases cover a small portion of our
overall code base.
Our alpha net supports one cell, and our
public claims are that one cell can support 1,000 TPS. These are claims that we
have tested and validated, so the mainnet is in spec. You will see that multi
cell support is coming in our next release, as mentioned in our readme. Our
method of achieving multi cell support is with a well understood and documented
methodology, specifically consistent hashing. However, an optimization
opportunity, we’re investiging LSH over CS. This is an optimization that was
recommended by a member of our Tech Advisory Board, who is a PHD in Computer
Science at the University of Cambridge.
Our code was made straightforward on
purpose. Most of its simplicity comes from its modular design: we use a common
static library in which we’ve put common functionality, and this library is
rightfully called BlockChainCommon.lib. This allows us to abstract away from
the individual nodes the inner workings of the core components of our block
chain, hence keeping the code in the individual nodes small. This allows for a
high level of code reusability. In fact, in some cases this modular design has
reduced a node to a main function with a series of data handlers, and that’s
all there is to it. It allows us to design a common behavior pattern among nodes:
start up OpenDHT, register data handlers using a mapping between the ComandType
command and the provided lambda function, call the COMM_PROTOCOL_INIT macro,
enter the node’s forever loop. This way, all incoming data packets and command
processors are handled by BlockChainCommon, and all nodes behave similarly:
wait for a command, act on the command. So while this design gives the
impression of basic code, we prefer simplicity over complexity because it
allows us to maintain the code and even switch out entire communications
protocols within a matter of days should we choose to do so. As far as the
proven track record of being secure, fast and efficient.
We’ve specifically disabled warning 4996
because we are checking for buffer overflows ourselves, and unless we’re in
debug mode, we don’t need the compiler to warn about these issues. This also
allows our code to be portable, since taking care of a lot of these warnings
the way the VCC compiler wants us to will mean using Microsoft-specific
functions are portable (other platforms don’t provide safe alternatives with
the _s suffix, and even Microsoft warns about this fact here:
To quote: “However, the updated names are Microsoft-specific. If you need
to use the existing function names for portability reasons, you can turn these
AI development is for the platform, not
the block chain”