BitShares 2.0 is one of the most secure blockchain projects while Ripple is the least

in #blockchain3 years ago (edited)

Ripple is the most insecure choice for a blockchain developer. Use it at your own risk.

The latest report from China's CERT states that Ripple is the worst blockchain project. They checked for code quality, and for the obvious patterns like input validation which I've discussed previously, and the result is that Ripple is the most insecure. Not only is Ripple suspect due to centralization but now code quality is under question as well. Use at your own risk.

Graphene 2.0

Steem is based on the same codebase that Bitshares 2.0 is based on. Investors, developers, users, all can take note that Graphene 2.0 is high quality code and if we look at the trend the quality is improving with each iteration. In fact it is my opinion that Graphene 2.0 is more secure than Bitcoin at this time. CERT presents the statistics to prove it which can now be utilized as part of marketing for Steem and Bitshares as a very security platform and one of the most secure in the blockchain space.

Conclusion

Security can be improved further for Ethereum but it seems the developers are headed in the right direction. Ethereum based on CASPER will be interesting and possibly more secure than Ethereum is now. As I stated in my own post, the main issue is in smart contracts will be input validation and quality secure libraries. The Chinese CERT states the same thing and has graphs to back it up. It is for these reasons that I've always remained cautious of Ethereum because I understand the difficulty in building secure smart contracts. Graphene 2.0 and Steem can rely on a powerful API with secure libraries and a very limited high performance smart contract language. Developer Dan Larimer prefers Wren likely for performance reasons. If careful action is taken to make sure the average smart contract developer can write smart contracts without the obvious input validation and similar common errors then it might work but in my opinion will require curation.

The curated model would mean Steem or Bitshares should not accept any smart contract which hasn't gone through some sort of peer review process or which doesn't utilize known secure libraries. If a library is known to be secure and easy to use such as libSodium or Boost for example then on that basis we can say with reasonable confidence the program is secure because we know the foundation is secure. Unfortunately with Ethereum everything was very new and even the language Solidity was very new so there are no secure libraries. To put it in gamer terms Ethereum is not developer friendly while Bitshares and Steem have the opportunity to take the lead in that area.

References

  1. http://news.8btc.com/blockchain-software-security-report-by-china-cert-ripple-the-worst
  2. [FOR ANYONE WHO CAN READ IT] http://www.8btc.com/blockchain-software-bug-report
  3. https://steemit.com/tauchain/@dana-edwards/basic-model-theory-and-input-validation
Sort:  

Nik Bougalis (a member of Ripple's C++ team) posted a response to this a few days ago: https://www.xrpchat.com/topic/2674-fud-or-legit/#comment-24048

The short version is this: We run these same kinds of tests ourselves. Automated testing tools produce lots of false positives. Also, their reference to JNI (which has no applicability to rippled whatsoever) suggests they may have scanned repositories other than rippled that contain unsupported or experimental tools that don't have any security implications anyway.

Yep. The BitShares wallet has been the gold standard for sometime now afaiac.

Yet Ripple gets Bitstamp - https://steemit.com/crypto/@kingscrown/bitstamp-adding-xrp-ripple-for-trading

Sam as ETH is fully buggy but exchanges choose it over BTS - because they care of money not about the technology itself sadly

BTS is the smart kid sitting quietly in the corner of classroom hoping to get noticed. XRP, ETH etc. are the jocks that make a lot of noise and get attention. We all know what happens when highschool ends.

It seems buggy insecure blockchain platforms get a lot of funding. Why put funding into something which hackers can take control over? I understand with TheDAO because TheDAO was the first trial and first attempt at it but then you have something as old as Ripple? Ripple has no excuse because it's been around as long as Bitcoin if not longer yet isn't secure? It's never going to be secure if it's not secure by 2017.

ETH is just too new. It might someday become secure enough to do something with but it's a very new platform with an entirely new language and in the opinion of some security researchers has a reckless design.

It should come as no surprise to anyone here that Graphene is the best codebase capable of more than other cryptos. Bitshares is a great project and I look forward to it and Steem growing together. The Steem/Bitshares ecosystem will be fascinating to watch fluorish in the coming years.

With all honour to BitShares it has the biggest amount of medium level vulnerabilities. As far as I understand 8btc interpretation.

I concede this point but for what it is capable of doing it is on par with Bitcoin and more secure than Ethereum. The point is risk reduction and if medium level vulnerabilities don't seriously degrade the platform or cost any money to the users then it's not bad. Steem for instance is secure and even if somehow your account gets hacked there is a disaster recovery process built in.

This post has been ranked within the top 25 most undervalued posts in the second half of Jan 12. We estimate that this post is undervalued by $12.69 as compared to a scenario in which every voter had an equal say.

See the full rankings and details in The Daily Tribune: Jan 12 - Part II. You can also read about some of our methodology, data analysis and technical details in our initial post.

If you are the author and would prefer not to receive these comments, simply reply "Stop" to this comment.

I give you credit for responding and your point about false positives is valid. At the same time many people think the design of Ripple itself is flawed at a conceptual level, and think the XRP is too centralized.

While I do not know exactly what the Chinese CERT team used to determine their vulnerabilities I still report on it because whether they are practical or not it does indicate code quality. I would like to ask whether the Ripple development team relies on the practice of formal verification?

Formal verification could be very useful for critical components because then your engineers could offer a proof that the code cannot behave in certain ways. The main concern people have is that their money can somehow be lost or that there is some risk to their ability to transact. Formal verification might help resolve some of these worries even if it costs resources.

I agree with you that the Chinese CERT probably should have contacted Ripple privately or revealed more information. Politics may have been involved or maybe there was just not enough disclosure. I will say I'm not associated with their team and cannot read the language but I did look at the graph and stats. In your future responses please release the results of your audit which shows Ripple is secure so as to prevent this situation from happening again. If we can see Ripple is taking security seriously and trying to fix bugs it goes a long way.

It indicates code quality in some cases and not others. If used properly, yes, it can be used to measure code quality. But this report used it improperly in three major ways:

  1. They compared results numerically across different languages.
  2. They combined results in security critical code with results in non-critical code.
  3. They didn't survey a statistical sample of their results to determine how many of them reflected actual bugs.
    3 is the most important because if they had done this for Ripple, they would have discovered that all their results were false positives because Ripple uses this exact same technique to find actual issues.

Formal verification is not yet ready for real world use on systems as complex as the ones we're dealing with. We follow the research and there's certainly hope that it might be possible some day. We've particularly looked into formal verification of aspects of ILP's design (with some actual successes and some issues found that way) and with the mechanics of consensus and validation (with very limited success to date). Much more research is needed in this area before it will be practical on a larger scale.