Hacker News new | ask | show | jobs
by pgt 3090 days ago
The RAIblocks whitepaper is worth reading just as a reference on how a technical paper should be written.

(Disclosure: I became interested in RAI on NYE and recently invested some money in it)

The RAI secret sauce is the "block lattice" design where each account is its own blockchain and you only need to care about the chains you want to do business with, unless you encounter conflicts. Conflicts are resolved by proof-of-stake voting. If you don't run a full node, you choose a representative to vote on your behalf.

Today I spent the afternoon playing around with a conceptual design in ClojureScript for a better desktop wallet: http://petrustheron.com/posts/xrb-wallet-concept/

From a contrarian investor point-of-view, RAIBlocks is interesting because it is at the juncture of a terrible wallet experience, a weird name, dubious exchanges (at least UI wise), an okay website - but an excellent whitepaper and a working protocol that's free to transact on.

If it scales, I predict it will do well. My biggest concern is C++ as an implementation language, compared to, say OCaml that is easier to verify. I also don't have a strong feel for the robustness of the conflict resolution mechanism. However, the author is proficient and the codebase is readable.

The closest DAG impl. AFAIC, is Hashgraph, based on supermajority consensus that counts transactions that were "strongly witnessed", but it is patented with no coin presently for sale.

1 comments

One thing that I don't get is what is the incentive to vote on tx?
As I see it, if you don't vote the wrong president might win. Dirty txes jeopardise the asset value and you could be left with a tyrant in your chain who has even more voting stake. It's self-regulating in that way. But there may be another consistency issue I'm not aware of.
So there is a conflicting tx, your software is going to vote on it automatically. How do you pick which tx is the 'clean' one and which one is the 'dirty' one?
When your node encounters a conflict (a fork), where two signed blocks have the same parent (double spend attempt), it creates a vote referencing the block and broadcasts it to the network.

The nodes vote and the weighted majority (>51%) is taken as the real fork. The weight of a node's vote is the sum of the balances all accounts that have named that node as its representative.

The key thing here is that when a fork or missing block occurs, only the accounts referenced in the transaction are affected. The rest of the network proceeds with processing transactions for other accounts.

The voting mechanism is to wait for 4 voting periods (1 minute total) and keep a cumulative tally of incoming votes from the other representatives. The most popular block wins majority and is kept. The other block is discarded.

Refer to page 4 (bottom right) of the whitepaper: https://raiblocks.net/media/RaiBlocks_Whitepaper__English.pd...

As far as I am concerned, this is a great design (if you buy into proof-of-stake, which I do).