Earlier quoted context omitted.
Rust is the future of systems programming and will always be for the foreseeable future. The memory issue will mostly be addressed as needed, see from John Carmack yesterday[1], the C++ ecosystem advantage (a broad sense of how problems whether DS, Storage, OS, Networking, etc. have been solved) will be very hard to overcome for newer programming languages. I think it is ironic how modern C++ folks just keep chugging…
> The memory issue will mostly be addressed as needed I have no allegiance to either lang ecosystem, but I think it's an overly optimistic take to consider memory safety a solved problem from a tweet about fil-c, especially considering "the performance cost is not negligible" (about 2x according to a quick search?)
In-Memory C++ Leap in Blockchain Analysis
41–50 of 72 posts
Re: In-Memory C++ Leap in Blockchain Analysis
#42Thank you for the AMA. A few initial questions: - Would it be possible to open source your DB in the future? I think there are challenges in blockchain analysis (e.g. internal transactions) that goes beyond the specific DB. - Having used Chainalysis and others, your product seems superior based on your presentation. Which blockchains do you support? - Is there a "HN Code" to test Prism?
Re: In-Memory C++ Leap in Blockchain Analysis
#43Curious why you chose C++? Were there aspects of other languages/ecosystems like Rust that were lacking? Would choosing Rust be advantageous for blockchains that natively support it (like Solana)? To be clear: I don't mean to imply you should have done it any other way. I'm interested mainly in gaps in existing ecosystems and whether popular suggestions to "deprecate C++ for memory safe languages" (like one made by A…
Re: In-Memory C++ Leap in Blockchain Analysis
#44If the FBI tells you wallet A and wallet B belong to the same actor, how do you use that information, so that they can see it on their view, without leaking it to Europol?
FBI and Europol will work with the same forest (unless they are using on-premise setup), but with different "patches".
Re: In-Memory C++ Leap in Blockchain Analysis
#45Do you see crypto as anything more than scams/crime/speculation? Most people involved in crypto pretend it's the future and their business models depend on pumping up crypto. That might be the same for you all but I figure of anyone in the space, a group dedicated to tracking down where coins are moving for government agencies (I assume for scams/crime reasons) might not have the wool so pulled over their eyes.
First of all, at Caudena, we are not involved in crypto projects or investments ourselves. Our expertise lies in analyzing blockchains and providing deep technical insights into how various blockchains operate. We focus on tracking and understanding the flow of digital assets, often in support of government agencies investigating scams, fraud, and other illicit activities. That said, we absolutely believe that blockc…
Re: In-Memory C++ Leap in Blockchain Analysis
#46Earlier quoted context omitted.
> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations. (1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... (2) https://www.chromium.org/Home/chromium-security/memory-s…
Show me a memory issue that was caused by proper usage of POSIX concurrency primitives.
The great lesson in software security of the past few decades is that you can’t just document “proper usage,” declare all other usage to be the programmer’s fault, and achieve anything close to secure software. You must have systems that either disallow unsafe constructs (e.g. rust preventing references from escaping at compile time) or can handle “improper usage” without allowing it to become a security vulnerability (e.g. sandboxing).
Correctly use your concurrency primitives and you won’t have thread safety bugs, hooray! And when was the last time you found a bug in C-family code caused by someone who didn’t correctly use concurrency primitives because the programmer incorrectly believed that a certain piece of mutable data would only be accessed on a single thread? I’ll give you my answer: it was yesterday. Quite likely the only reason it’s not today is because I have the day off.
Re: In-Memory C++ Leap in Blockchain Analysis
#47Earlier quoted context omitted.
What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.
What a terrifying statement. Edit: to be less glib, this is like saying “our shred-o-matic is perfectly safe due to its robust and thoroughly tested off switch.” An off switch is essential but not nearly enough. It only provides acceptable safety if the operator is perfect, and people are not. You need guards and safety interlocks that ensure, for example, that the machine can’t be turned on while Bob is inside lubri…
Exactly. Here is a data point: https://spinroot.com/spin/Doc/rax.pdf
Tl;DR: This was software that ran on a spacecraft. Specifically designed to be safe, formally analyzed, and tested out the wazoo, but nonetheless failed in flight because someone did an end-run around the safe constructs to get something to work, which ended up producing a race condition.
Re: In-Memory C++ Leap in Blockchain Analysis
#48Earlier quoted context omitted.
There are like attempts at non scam projects, but none of them get any traction and usually end up closing. What, in your opinion, is a success story in this space?
Cadena post above yours mentioned quite a few use successful cases, all built on top of Ethereum or copy cats (Ethereum is by itself a successful use case) Without thinking too hard, Aave is shaping to be a giant by its own as lending protocol. Circle recently had a very successful IPO. Farcaster and Lens are attempting to compete as social network platforms (surprisingly they lack much of the toxicity that comes on…
Re: In-Memory C++ Leap in Blockchain Analysis
#49> "Built a custom in-memory columnar/graph database from scratch" This seems like an odd place to spend your resources. What do Prism's benchmarks look like vs Memgraph, KX kdb+, Apache Ignite, TigerGraph, etc.?