Block Collider - Blockchain Code Review And Audit

Share this article

URL Copied

Smart contracts can be initiated or executed by smart contracts on other blockchains. How? I start an ETH transfer to a NEO smart contract, how can that possible work without an ETH NEO bridge? Block Collider consuming the blocks doesn’t add this functionality, not unless they implement a bi-directional stream. Block Collider being aware of the state of other blockchains doesn’t actually accomplish anything.

That out of the way, we are here to review their code, no matter how little the concept makes sense to me on a technological level.

554 commits, 12 branches, 4 contributors. So Block Collider has the concept of a Rover, this is the consumer of blocks, I’m actually interested to see how this works, so let’s start with it.

To start out with, I’m happy to see const (object cannot be changed after initialization) declaration. I always hate to see var (can be changed) declarations when a const will work, so, good start.

This is the Waves rover (program to collect blocks from the Waves API), it uses the pre-built Waves API to collect a block, compares the block to the local cache, and then attempts to make a unified block (combining all current pending blocks). I don’t know what I was expecting, but I was expecting more: don’t get me wrong, there is nothing wrong with this implementation, but it relies on standard synchronous connectivity to get its results.

I would have preferred something more decentralized; now of course, it becomes ridiculous to think that each Block Collider node should also run a node (or at least light node) of each blockchain it consumes, but this solution is just very basic.

Same setup for NEO as Waves.

Same for Lisk, right now it just looks like copy-paste.

Not a fan of the error handling, but this is a PoC after all, so no reason to nitpick.

Quite a lot of substance to the Ethereum implementation, this is less of just scanning blocks and is an actual Ethereum interaction implementation. Not sure why the disparity, but I prefer this implementation over the previous three.

BTC implementation follows the same pattern.

Now we know how blocks are collected. Bit of a centralized manner, but we won’t hold that against them. So blocks are streamed (or fetched), I still don’t know why.

This is transaction.js, the hash is just a blake2bl of the input variables. I’m not seeing how the ‘from’ is signing this transaction, but perhaps that is from self.trust, so let’s get back to this later.

For the most part, it’s very rudimentary code. I’m not saying it’s bad, just very basic.

There just isn’t a lot going on.

Claim block implementation above: if the block hasn’t been mined, you create a new Coinbase transaction that awards you the MinerReward (no fees currently) and you sign the block. Straightforward implementation. I’m not seeing block validation though.

Standard Express server for HTTP interaction.

Lots of user-specific hardcoded values, these aren’t good practice, but they aren’t inherently bad in a proof of concept.

Again, nothing wrong here, just nothing interesting. Was expecting something more for consensus.

Most of the real substance iseems like a re-implementation from https://github.com/bcoin-org/bcoin

The good parts are mostly bcoin.

Block Collider Code Review – Verdict

The code is consuming blocks, it is creating new signed blocks from the consumed blocks. What purpose this has, I honestly don’t know. Why they are doing this? I honestly don’t know that either. The code itself is average.

I can see it appears incredibly rushed, the typing and indentation style is sloppy and the general codebase has a rushed feel to it (duplicated sections, whole files commented out, I suspect they had a deadline and they rushed to meet it).

It’s not red flag code, but it isn’t good code. I really don’t see what they are bringing to the game. They appear to have simply copied bcoin, and added some centralized block streaming, and this doesn’t really accomplish anything.

Disclaimer: Crypto Briefing code reviews are performed by auditing what is on display in the master branch of the repo’s made available. This review is not a comment on the overall project, scope, or success thereof. This was done as an educational review and any comments in the article are the opinion of the writer. It is normal for code to change rapidly, hence we timestamp our code reviews so that they present a snapshot at a moment in time. Information contained herein should not be used as any comment or advice on the project as a whole.

Timestamp: April 12th 2018, 3:53pm

Share this article

URL Copied