Cursory RaiBlocks analysis | Whitepaper, Repo, Devs

I'm a software dev and like to do at least a minimal level of due diligence before investing into any coin or token. In particular I generally...

• Read the white paper
• Do some background checking on the devs
• Checkout the code repository activity

Here are my thoughts...

Highlights from the Whitepaper along with supporting anectdotes.

• RaiBlocks definition of Ledger stands out

The ledger is the global set of accounts where each account has its own transaction chain. This is a key design component that falls under the category of replacing a run-time agreement with a design-time agreement; everyone agrees via signature checking that only an account owner can modify their own chain. This converts a seemingly shared datastructure, a distributed ledger, in to a set of non-shared ones.

This is a fundamentally different way to apply blockchain, and applies a segregated, distributed data structure, as opposed to a globally shared data structure.

• Focus on minimal hardware reqs to run full nodes

Hardware requirements for nodes are also minimal, since nodes only have to record and rebroadcast blocks for most transactions.

This is one anecdote from the paper amongst others that demonstrate a design principle of keeping the overhead of running nodes to a minimum, which serves to maximize the number of nodes in the network.

• Optimizing transaction overhead

When a receiving account sequences input transfers, it keeps a running total of its account balance so that at any time it has the ability to transfer any amount with a fixed size transaction. This differs from the input/output transaction model used by Bitcoin and other cryptocurrencies.

• Simplified transaction model

Since agreements in RaiBlocks are reached quickly, on the order of milliseconds to seconds, we can present the user with two familiar categories of incoming transactions: settled and unsettled. Settled transactions are transactions where an account has generated receive blocks. Unsettled transactions have not yet been incorporated in to the receiver’s cumulative balance. This is a replacement for the more complex and unfamiliar confirmations metric in other cryptocurrencies.

• Some concerns regarding potential DDoS and flooding vulnerabilities

Pre computed proof of work attacks are mentioned as a vulnerability, with temporary network congestion as a result, and is currently a topic under review. To read up more on this check out section V.E of the paper.

A lot of these attacks are intended to be mitigated with the minimal PoW mechanic, however there are most likely shortfalls here, and another user on this sub has already pointed out the potential issues that could arise if ASICs were created to run the Blake2 hash.

In general I think these are solvable problems and hopefully the devs take a serious look at them.

Github repo

The good news is the repo is highly active, with 100+ commits over the last 4 months. The down side is that the vast majority of those commits are only from 2 devs - Colin LeMahieu (67 commits) and a user - SergiySW (43 commits). Hopefully more active quality contributors join this project over time.

Quick background on the lead dev

According to LinkekdIn, Colin LeMahieu has been a software developer at Dell, AMD, and Qualcomm. His work appears to include optimizations on compilers, linkers and assemblers, and general optimizations through concurrency and architectural refactoring.

At least based on this brief CV, he looks to be very legitimate systems engineer.

TLDR & Conclusion

Based on my expedited review I'm bullish on RaiBlocks and think it has some pretty groundbreaking principles. Most importantly I've gained confidence that this is a legitimate technology with original ideas on streamlining blockchain, with legitimate developers pushing it forward.

References

RaiBlocks Whitepaper

RaiBlocks repository