Stellard compared to Rippled

So there’s a new fork in town going by the name of Stellar!

Jed McCaleb had an idea for a new cryptocurrency which did not depend on mining and hired a small team of developers (David Schwartz, Stefan Thomas and Arthur Britto). This idea grew into one which borrowed from Ryan Fugger‘s original concept of community credit and was designed to provide a scalable solution for global payments with liquidity provided by anyone who wanted to make an offer or supply credit to satisfy that payment. An elegant concept was the basis for the formation of OpenCoin, later to become Ripple Labs. Jed hired Chris Larsen, and a subsequent, well-documented fallout occurs over the allocation of 20% of the XRP to three individuals and the fair distribution of the remainder. Jed leaves Ripple Labs and announces a “Secret Bitcoin Project”, which it turns out is a fork of the rippled codebase with some minor modifications and a new user interface. The release is partnered with a clearly expressed set of rules governing the distribution of the XRP equivalent known as STR.

So what are these code modifications and do they make a big difference to how likely Stellar is to succeed? Let’s have a look at the significant commits which have occurred since the fork attempt began on April 24th 2014. We’ll disregard all of the obvious “rename ripple=>stellar” alterations. 

Account ids begin with a g is a fairly straightforward change to the base58 alphabet for encoding account ids and other Stellar types. The main result is that all account ids begin the letter “g”, rather than an “r”. Why “g”? Who knows. 

Add InflationDest field is perhaps the most revolutionary change. The idea is that each account gets to nominate another account which, each week, receives a share of 0.019% of all the STR in existence, perhaps as a result of continued good stewardship of the network and supporting codebase. The field is optional. The formula is here and then revised here and here and here. Two new fields FeePool and InflationSeq are added to the LedgerHeader. 

Accounts can be deleted means that a user can consolidate his/her STR back into a single account from multiple accounts. Trustlines must first be removed. 

Clean up old unimplemented data structures, such as Nickname and GeneratorMap. 

Bootstrapping from a centralised peer provider is removed. 

A switch to ed25519 from P256 for creating and verifying signatures is implemented. 

Expose wallet_public to anyone and rename to create_keys. This is a security risk as someone could fake a response on a server and be in possession of your secret. 

Rename some API calls and change the default min_ledger for some calls. 

Remove EmailHash, WalletLocator, WalletSize, MessageKey and Domain fields from AccountRoot serialization format and the flag PasswordSpent. 

A painful merge of the main rippled codebase. 

Some surprising lack of familiarity with a key data structure in the codebase. 

So, does the above represent any serious deviation or innovation on the rippled implementation? The inflation is an interesting idea, but it reminds me of the old bankers’ adage.

The switch to ed25519 may one day permit performance gains, but not before any nodestore speed issues have been solved. The ability to delete an Account is useful. Everything else is mostly cosmetic and housekeeping. 

What is obvious from the team of three developers working on the C++ codebase is that there is not a deep understanding of what is going on in the internals, at least not yet. There is no published roadmap of future changes. Worst of all is that recent security fixes on the main rippled codebase have not been integrated into the stellard codebase and a new security flaw has been wilfully introduced.

The switch to an open and thoroughly explained plan for STR distribution is a welcome one, but a web page with words on it is just that. Time will tell.