Cryptofin as a strong foothold for Rust

Edit: Moved the discussion to users forum. Please continue there.

cryptofin is a term I use for Crypto-Finance - a growing industry using software and cryptography to build systems transferring value. It notably includes, but is not limited to: Bitcoin, other crypto-currencies, blockchains etc.

Before we begin: Please let's keep our personal opinions about Crypto Finance, Bitcoin and alikes to minimum.

I'd like to start with observation that programming languages greatly benefit from establishing themselves in certain niches. It ensures traction, real life usage, corporate support, mind share etc.

Notable example: Kotlin's popularity exploded after it became official language of Android. Similarly other recent yet successful languages established themselves like this: Swift has iOS, Go - distributed systems, Kotlin - Android.

Rust is very versatile and is specifically trying to establish itself in webassembly, embedded and core systems programming. While obviously worthwhile and with some success, embedded and general system programming are a more difficult areas, because they already do have estabilished dominant programming languages.

Fintech seem so interesting is that it is a fairly new niche, without a strong, long estabilished or otherwise dominant PL. Additionally Rust is really a perfect fit for cryptofin, which has unique and demanding set of requirements:

  • security, safety and reliability - as cryptfin operates on valuable digital assets in adversary environments, there is no room for mistakes;
  • performance - as performance characteristics are critically important for economic and functionality of the system;

The fit is good, that without much attention Rust has already become de facto language of choice for cryptofin. A lot of popular cryptocurrencies and cryptofin systems is using and is fond of Rust, despite Rust community never explicitly trying to address that niche. Even Bitcoin, which was initially implemented in 2009 in C++, has a growing community of Rust developers.

While cryptofin is not yet a huge industry, it is really quite well funded, and as a principle - is typically based on Open Source: any cryptofin Rust project tends to provide Rust community with a lot of Open Source work.

Cryptofin is also on the cutting edge of many efforts: security, trust minimization, cryptography, etc. Dominating cryptofin means getting a mindshare in many areas important to high-caliber, mission-critical system software.

I think it's worthwhile to raise the awareness of this quiet success, and possible future benefits . While at it, I'd like to list from the top of my head problems with Rust for cryptofin (and specifically rust-bitcoin, which I'm somewhat participating in). Addressing or helping address these, could lead to even stronger dominance of Rust in this area.

Trust (bootstrapping). Cryptocurrencies are a lucrative target for cyber-crime, malicious software etc. Because of this cryptofin developers are very distrustful, and are trying to eliminate any technical risks. Specifically, right now most Rust users are trusting rust compiler binaries, compiled and distributed by Rust team. That is putting a lot of trust in Rust team - their infrastructure, employees etc., especially in the light of possible state-level actors trying to subvert or shut-down such systems. One could just compile the compiler itself... but you can only do that with a Rust compiler, again ... provided by Rust Team. It's a circular dependency, and unlike languages like C/C++ Rust has only one feature-complete implementation ATM. The problem was somewhat solved by independent bootstrapping using mrust, but it is still a a pain point. I don't know how much can be done about it - maybe Rust developers would be OK with making sure newer versions of the compiler, compile with somewhat older versions, to ease the pain of independently bootstrapping the compiler, or mrust could get more help to keep up with the evolving language.

Language and ecosystem stability guarantees. Partially because of the bootstrapping problem, and partially because of general conservative approach, lack of any LTS releases, backporting fixes, minimum required rust compiler version management, etc. is a problem. Cryptofin developers can not and do not really want to roll with the "just use the latest stable version" mantra. I observe that this creates a lot of tensions (example). One one hand I understand that language and ecosystem are very alive and quickly evolving, on the other hand I understand that people working on rust-bitcoin are used to their code compiling with no problems on 10-year old c compilers. Rust is simply not yet there (not even 10 year old in the first place), but it seems to me that it would be really beneficial for perception of Rust's stability and maturity to start rolling out some stability guarantee: eg. starting with 6-month-long LTS cycles, that could get extended with time, as the language stabilizes, and encouraging some backward-compatibility minimums in the ecosystem.

1 Like

This would be better discussed on https://users.rust-lang.org/ . (If you find a specific area that you'd like to enhance in Rust, you could take that specific area/feature back here for discussion.)

2 Likes

This. As time passes, I find the 6-week release cycles increasingly harmful. Rust is at version 1.37 currently. What is this rush warranted by? I don't want to reiterate points that I had already made in the past about continuously pushing changes (and in particular, additive new features) into the language, but it seems to me that — based on some other voices I've heard — wanting more conservative governance is not at all limited to cryptocurrency folks.

The other two big systems programming languages — C and C++ — do perfectly fine with only one release in several years. And I do think that's a great thing. Settling down and letting users get used to new features and idioms takes time (a lot of time). I can barely keep up with them even by regularly following IRLO, URLO, and the rust-lang/rfcs repo. I think that is a serious problem unto itself, but it is exacerbated when trust and security are at stake.

To me, this problem appears similar to the concerns raised about transitive dependencies with unsafe code, and the inability for a single developer or smaller team to completely audit every such dependency. At least with the core language, the problem size "only" grows linearly with every new version/every added feature or change, but even so, as I just mentioned, it's not really tractable in practice.

(Disclaimer: I'm not a cryptocurrency person, I'm not here to shill for any such system, and I'm a firm believer that "crypto" means "cryptography". :stuck_out_tongue:)

First: 6-week release cycles and rate of change don't have anything to do with each other, apart from the 6-week release cycle making Rust more maintainable and stable. If we had a 12-week release cycle, we'd have twice as many changes in each release. But in addition, having a regular release cycle makes people less likely to try to push their feature in before it's ready, because they can always "catch the next train"; on balance, I'd suggest that that improves baseline quality.

Second: Rust changes because people have needs that it doesn't fully meet yet. Folks are working to make it better for many additional use cases.

All that said, you might look at the Sealed Rust project.

11 Likes

My bad. I'll repost it and link here.

Please don't post any more, and feel free to lock this thread or something.

Edit: Moved the discussion to users forum

1 Like

I forgot to mention that I've heard this argument before, and I don't think it works in practice. People are still pushing features, and there have been at least two occasions where such a feature has been stabilized at a stage that is considered to be premature by many (namely, default binding modes and postfix await).

I'd argue that "await". Is an example of this working well. it took ages to get "await" into stable. {I'm not sure it is yet. Haven't checked receltly, though I use it in nightly) but the decisions have taken time, and it's been worth the wait.

There's no break in backwards compatibility anyway, so you if it's stability you want, only use stable features.

At. Some point a decision does have to be made. Personally, I think postfix await is fantastic though I disagreed until I used it. And the fact they took so long to pull this together, and didn't rush is testament to the strenght of the 6 week cycle.

1 Like

[thread continued on users forum]