Jump to content
Sign in to follow this  
devnullprod

rippled source code analysis and audit

Recommended Posts

We did post a few comments in reply to Nik here:

 

Overall we've found the code easy to understand and grok. Of course with any active project there are some artifacts and inconsistencies wrt style, organization, etc; but there are largely superficial, and from what we gathered so far things are well written. We aim to continue analysing the various components / subsystems that make up the codebase and updating the site w/ additional analysis so stay tuned! (will post additional updates both to our twitter and here so make sure to subscribe to one of the two or both!)

Share this post


Link to post
Share on other sites

Thanks for linking into the existing docs for a bunch of this stuff. By the way, if you want to know more about the sqlite vacuum stuff that's in int main(), there's a new doc (just waiting for the rippled 1.1.0 release) that explains what it's for and when to use it. Basically, if you have a full-history database that you started on an old version of rippled (<0.40), you can run out of space to store transactions due to limitations from the SQLite page size setting, so the VACUUM thing lets you migrate to a new SQLite database with larger capacity. New full-history rippled servers don't have this problem because they configure SQLite DB with the larger page size setting from the start.

Share this post


Link to post
Share on other sites
3 minutes ago, essexboyracer said:

Ah, I wondered why disk access speed was so important with rippled, it's because of the database (aren't there 2 DBoptions though when installing?)

rippled always uses an SQLite database to store some transaction history. Additionally, the core ledger store can use either RocksDB or NuDB (both are included in the rippled source code). RocksDB is better or about even for most use cases, but NuDB is better for storing lots of historical data on SSDs without using too much RAM.

Share this post


Link to post
Share on other sites
Posted (edited)
35 minutes ago, mDuo13 said:

Thanks for linking into the existing docs for a bunch of this stuff. By the way, if you want to know more about the sqlite vacuum stuff that's in int main(), there's a new doc (just waiting for the rippled 1.1.0 release) that explains what it's for and when to use it. Basically, if you have a full-history database that you started on an old version of rippled (<0.40), you can run out of space to store transactions due to limitations from the SQLite page size setting, so the VACUUM thing lets you migrate to a new SQLite database with larger capacity. New full-history rippled servers don't have this problem because they configure SQLite DB with the larger page size setting from the start.

Awesome, good to know. From personal experience we know regularly vacuuming a large db can greatly help with performance and storage size, so I'm sure this is going to help alot of people with limited resources. Awesome work!!!

Edited by riptidel

Share this post


Link to post
Share on other sites
1 hour ago, Tinyaccount said:

On another note....   a similar thing done on a wallet would add a great deal of value I believe...

 perhaps you may have inspired other devs to do that?

Agreed, unfortunately probably won't have time to do this ourselves in the near future, but if any community members wanted to do this, I'm sure it'd be greatly received!

As a related note, even though it's very simple, Wipple live supports integrated wallet functionality. You can navigate to the settings page and enter private keys. They are 100% stored client side (in your local browser's localstorage) and never transmitted anywhere. These can then be used to issue transactions. for example sending payments. For other transaction types click the '+' icon in the upper right hand corner of that page.

---

We added this as we needed an extremely simple way to issue test transactions to a XRP network (the rippled URI can be set via the settings page as well, by default its the mainnet but it can be set to the testnet or any other). It's very basic but has a few frills, such as auto-suggesting offer sequences, currencies, etc based on ledger objects associated with the account being used. It should be great for both development and production purposes so long as you don't mind a lack of eye candy (another item on the TODO list!)

Since it's important that everyone in crypto leans on the paranoid side when it comes to key management, you may want to checkout the source code backing the wallet mechanism.  

Share this post


Link to post
Share on other sites
Posted (edited)
14 hours ago, Sukrim said:

Sounds more like a description of the code in prose to me than what I understand as an "audit", but seems like a nice idea.

Well this is just the first stage... as mentioned in the report, we're starting from the top down.

Edited by riptidel

Share this post


Link to post
Share on other sites

What better day to release parts 9-12 of our rippled source code audit than on 9/12! Read about the overlay network, find out how the nodestore works, and explore the details of ledger & transaction management and the consensus process!!!

Follow us on twitter for more updates!

Share this post


Link to post
Share on other sites
Sign in to follow this  

×