Popular Post DevNullProd Posted August 27, 2018 Popular Post Share Posted August 27, 2018 Parts 1-8 of our rippled source audit is now online! http://wipple.devnull.network/research/rippled.html If you like this please consider following us on twitter and/or donating to the Wipple XRP Intelligence Project: https://twitter.com/DevNullProd http://wipple.devnull.network/donate.html tulo, ThomasTheTGV, Donkey and 8 others 5 6 Link to comment Share on other sites More sharing options...
Guest Posted August 27, 2018 Share Posted August 27, 2018 Interesting, any personal commentary on the code aside from the audit? Link to comment Share on other sites More sharing options...
DevNullProd Posted August 27, 2018 Author Share Posted August 27, 2018 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!) Donkey and RecentChange 2 Link to comment Share on other sites More sharing options...
DevNullProd Posted August 27, 2018 Author Share Posted August 27, 2018 As a note, please read the disclaimer in the report. Our analysis is nowhere near exhaustive and there is still alot left todo! Donkey 1 Link to comment Share on other sites More sharing options...
Guest Posted August 27, 2018 Share Posted August 27, 2018 You are awesome...... this is another fantastic thing that you have done. Mad respect and many thanks. Link to comment Share on other sites More sharing options...
Guest Posted August 27, 2018 Share Posted August 27, 2018 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? Link to comment Share on other sites More sharing options...
mDuo13 Posted August 27, 2018 Share Posted August 27, 2018 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. CarloRossi and DevNullProd 2 Link to comment Share on other sites More sharing options...
Guest Posted August 27, 2018 Share Posted August 27, 2018 (edited) Double post Edited August 27, 2018 by Guest Link to comment Share on other sites More sharing options...
mDuo13 Posted August 27, 2018 Share Posted August 27, 2018 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. Link to comment Share on other sites More sharing options...
DevNullProd Posted August 27, 2018 Author Share Posted August 27, 2018 (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 August 27, 2018 by riptidel CarloRossi 1 Link to comment Share on other sites More sharing options...
DevNullProd Posted August 27, 2018 Author Share Posted August 27, 2018 1 hour ago, Tinyaccount said: You are awesome...... this is another fantastic thing that you have done. Mad respect and many thanks. CarloRossi 1 Link to comment Share on other sites More sharing options...
DevNullProd Posted August 27, 2018 Author Share Posted August 27, 2018 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. Sukrim 1 Link to comment Share on other sites More sharing options...
Sukrim Posted August 27, 2018 Share Posted August 27, 2018 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. Link to comment Share on other sites More sharing options...
DevNullProd Posted August 28, 2018 Author Share Posted August 28, 2018 (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 August 28, 2018 by riptidel Link to comment Share on other sites More sharing options...
DevNullProd Posted September 12, 2018 Author Share Posted September 12, 2018 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! Donkey, Professor Hantzen, NightJanitor and 3 others 6 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now