constantine VS Vale

Percival cache attacks on Hyperthreading.

I go over some examples here: https://github.com/mratsim/constantine/issues/358#issuecomme...

`when myCondition():` instead of `if myCondition:` is done at compile-time.

Alternatively you can use a `static:` code block to force compile time evaluation. Or tag a function {.compileTime.} or tag function inputs with `static` modifier.

It is possible to create a compiler or an assembler running fully in Nim macros as well:

- https://github.com/mratsim/constantine/blob/master/constanti... (all that file runs at compile-time)

You can also implement Continuation-Passing-Style transformation at compile-time:

At a glance this sounds like a re-discovery of addition chains and using them to construct Pippenger algorithm. But applied to matrices instead of group elements.

See: https://github.com/mratsim/constantine/issues/37

I usually explain extension fields as similar to complex numbers with regards to reals.

I've collected a lot of extension fields references while working on my own implementation: https://github.com/mratsim/constantine/tree/master/constanti...

The best likely being

- Arithmetic of Finite Fields

Regarding your first question, you don't need to attack the hard-drive, for non constant-time crypto you can read power consumption or electromagnetic traces when the secret key is used to reconstruct it: - https://github.com/mratsim/constantine/wiki/Constant-time-arithmetics

Unfortunate name collision with my constant-time pairing-based cryptography library :/.

https://github.com/mratsim/constantine

KZG for sure yes, I actually already started implementing them: https://github.com/mratsim/constantine/tree/c2d716b/research/kzg_poly_commit

I have a small write-up on various details of elliptic curve crypto implementation here: https://github.com/mratsim/constantine/tree/master/constantine/elliptic

Not to be confused with Vale[0].

[0] https://vale.dev/

The article says they created a deterministic hypervisor that runs all pseudorandom behavior from a starting seed to enable perfect re-playability.

But that's all we know so far. I'm assuming there'll be some sort of fuzz testing, and static analysis or some defining actions that your software can perform.

Honestly it sounds a lot like it has a lot of crossover with what the Vale language is trying to solve: https://vale.dev/, but focused on trying to get existing software to that state instead of creating a new language to make new software already be at that state by default.

Why go through all the trouble when you can do this: https://www.hylo-lang.org/ and not spend a second thinking of lifetimes? No, copies will not be issued unless necessary.

Or why not keep exploring this idea as well? More research-oriented than the first one right now, though, so take it with a grain of salt: https://vale.dev/

Another relevant language might be Vale (https://vale.dev), which is aiming for "perfect replayability": https://verdagon.dev/blog/perfect-replayability-prototyped

Interesting. Very low level though and C(++) centric. She there any thoughts on combining the hardware and OS features with rust or https://vale.dev ?

Use a runtime memory management solution that's cheaper than garbage collection (see Vale)

This seems like a tool I'll be using, and this is an almost meaningless criticism, but why the name?

There's already the Vale programming language (https://vale.dev/), but moreover, I don't get the meaning of "vale". You could call it something like Englint which actually hints its purpose.