Hacker News new | ask | show | jobs
by rvz 1667 days ago
That is completely true. Rust is where it is going for cryptocurrencies that need to have very secure smart-contracts and scale up to millions of users with tens of thousands of transactions per second.

Even if it is completely unrelated, it is 'at least' production ready and will be used more than these projects would ever be used in terms of Rust projects.

2 comments

Rust in Cryptocurrency is mostly a marketing play (and I say this as someone who does a lot of Rust).

Are there even any cryptocurrencies that allowed less-safe languages like C in the first place?

In my opinion (as a Rust dev), Rust is weirdly over complicated for what they’re trying to do. Common types scripting languages are basically more than sufficient (and safe)for these applications.

It’s only a matter of time before a crypto project overplays the safety of Rust and them has a huge heist due to a logic bug, which will further contribute to jokes about Rust programmers. Most of the Rust devs I know are wary of Rust crypto projects.

We need to distinguish nodes written in Rust vs smart contracts.

Given the context assuming smart contracts you may have a point. Often consensus will be much slower and a limiting factor in execution. Solana may be a bit different here in their efforts to parallelise independent transactions.

High level provable languages always seemed like a good idea to me for smart contracts. As you say Rust doesn't necessarily seem like the sweetspot for this.

The Ethereum EVM assmebly is wildly unsafe but regularly used for the sake of gas and other things that would be impossible (most hilariously string manipulation). Solidity is unsafe with respect to things like overflow. It doesn't have memory unsafety in the traditional sense. Partly because it is allocate only and you don't have to deal with bounds checking yourself.

If that includes C++ then basically every cryptocurrency that’s not written in Rust (Bitcoin, Ethereum, Monero…)
Rust won't protect smart contracts from logic bugs.
It depends on how much logic and/or arithmetic you can get away with encoding into the type system. We abuse the heck out of it to restrict things like register & field access, state-machine transitions, and also track resource allocation/consumption. That said, it's incredibly painful to develop anything that way, and it also doesn't ultimately prevent a different problem of the "model" you've written down in the types being wrong. So, it's not a panacea, and it's incredibly difficult, but it can winnow down the surface area of potential problems and bugs... or at least move them to compile-time.
I don’t think anyone said it would.
> Rust is where it is going for cryptocurrencies that need to have very secure smart-contracts

There is an implication here that Rust will help make smart contracts "secure", but AFAIK the vulnerabilities in smart contracts have been in their logic, not in their memory/type safety or whathaveyou.