Ferengi Rule of Acquisition #239: Never be afraid to mislabel a product.
Cryptography and cryptocurrency aren't the same, and I know of no other use for blockchain. Maybe they were hoping to win over non-believers by deceiving them about the content of the article.
let me guess, you don't actually write code. just talk down people who actually do
this is a crypto lib and the authors repo obv has a ton of hardwork
https://github.com/mratsim/constantine
At a glance it seems fair to say that this is both a cryptocurrency library and a cryptography library.
The only truly general purpose thing here is SHA256. Every protocol on its supported list starts with either "ethereum" or "evm", and to the best of my knowledge the other primitives have seen very little use besides cryptocurrency.
The Internet Engineering Task Force, which in particular standardizes TLS, has acknowledge my contributions for my contributions to the very generic and globally useful hashing-to-curve primitive: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-t...
BLS signatures are general purpose, the only Ethereum specific thing is choosing which elliptic curves are used for public keys and which for signatures as well as a prefix before hashing inputs.
Similarly KZG polynomial commitments are generic, the Ethereum specific thing is the trusted setup ceremony which needs to be specialized per protocol.
I think this is cool, but how sure are the authors that this is side-channel safe? There is a similar (modular, high performance, zero-dependency) library in Common Lisp but it can't give side-channel guarantees due to how some Common Lisp compilers implement integer and arithmetic functions
Then the library defines its own types SecretBool and SecretWord throughough library that cannot be mixed with regular Nim types and are based on uint32/uint64 so the compiler cannot assume 0/1 and do boolean logic.
Assembly is used to avoid compilers getting too smart and reintroducing branches but the no-assembly fallback should still compile without branches.
By convention, all variable-time cryptographic functions are suffixed _vartime.
> Releasing Constantine v0.1.0 - A modular cryptography stack for blockchain and proof systems
I guess OP had to “edit” the title for conciseness…
Cryptography and cryptocurrency aren't the same, and I know of no other use for blockchain. Maybe they were hoping to win over non-believers by deceiving them about the content of the article.
They aren't, but this is a cryptography library.
The only truly general purpose thing here is SHA256. Every protocol on its supported list starts with either "ethereum" or "evm", and to the best of my knowledge the other primitives have seen very little use besides cryptocurrency.
And BLS signatures are standards as well: https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signatur...
Similarly KZG polynomial commitments are generic, the Ethereum specific thing is the trusted setup ceremony which needs to be specialized per protocol.
The finite field backends and the elliptic curves supported are all generic as well: https://github.com/mratsim/constantine/blob/master/constanti...
https://github.com/sharplispers/ironclad
Then the library defines its own types SecretBool and SecretWord throughough library that cannot be mixed with regular Nim types and are based on uint32/uint64 so the compiler cannot assume 0/1 and do boolean logic.
Assembly is used to avoid compilers getting too smart and reintroducing branches but the no-assembly fallback should still compile without branches.
By convention, all variable-time cryptographic functions are suffixed _vartime.
There is a plan to add automated constant-time checks as well https://github.com/mratsim/constantine/issues/7.
More of this, please. I think this should be the norm.