Porting the Solana eBPF JIT Compiler to ARM64

blog.trailofbits.com

44 points·ingve··7 comments

Solana really seems like the most interesting Layer-1 chain outside of Ethereum... lots of cool tech.

The real question is, why is anything written in Solana better off being run in a blockchain rather than a 'web2' client server architecture.

And so much overengineered.

Developing for Solana vs other EVM-based blockchains is enormously more expensive both in time and talent.

This is not "JiT" by any normal definition. I.e., the eBPF is translated to machine code at registration time, just once, and the resulting machine code executed unsupervised thereafter. There is no hint of runtime analysis of usage, or of progressive optimization. The only thing "in-time" about it is that translation from portable to native representation happens after the program starts up.

Isn't it the same for .NET, which is also commonly regarded as JIT compiler? My main criteria for JIT is that the machine code is not generated fully before the binary is started, but at startup time. Whether that's a one-time process (like what C# and eBPF does) or a continuous process (like Java and JS engines) seems to be another distinction.

It is true that it would be called AoT in the traditional sense.

However, our requirements are others: Instead of a few programs with many complex functions we have lots of programs with simple functions. Thus, we do the runtime analysis and compilation on a program level, not a function level.

Note I am not complaining about the tech, just terminology. Everything Trail of Bits does is exemplary.

Reply on news.ycombinator.com