Hey! I'm David, the author of the Real-World Cryptography book. I was previously a crypto architect at O(1) Labs (working on the Mina cryptocurrency), before that I was the security lead for Diem (formerly Libra) at Novi (Facebook), and a security consultant for the Cryptography Services of NCC Group. This is my blog about cryptography and security and other related topics that I find interesting.
I've been writing (although mostly reading) OCaml on-and-off this last year. It's been quite a painful experience, even though I had some experience with functional languages already (erlang, which I really liked).
I find the language and the experience very close to C in many ways, while at the same time boasting a state of the art type system. It's weird. I think there's a real emphasis on the expressiveness, but little on the engineering. Perhaps this is due to the language not having enough traction in the industry.
So about this, I have two things I'd like to say. The first, is that if you're looking for a somewhat low-level (there's a garbage collector) language you can make a real dent in, OCaml might be the one. It's pretty bare bone, not that many libraries exist, and if they do they are barely usable due to a lack of documentation. My first contribution was a library to encode and decode hexadecimal strings, because I couldn't find one that I could use. That should tell you something.
My second contribution was a tool to build "by example" websites. I used it to make a website to learn OCaml by examples, and another one to learn Nix by example. How cool would it be if people started using it to build a number of "by examples" websites in the OCaml ecosystem :D?
Anyway, I digress, the second thing I wanted to say is: if you're working on OCaml (or want to contribute to a new language), here's my wishlist:
a tool like cargo to manage dependencies (& versions), start projects, run tests, etc. Two important things: it should use a real configuration language (e.g. toml, json, yml) and it should work in a convention over configuration model.
better integration with vscode. Every time I write or read OCaml I find myself missing rust-analyzer and its integration with vscode. I just want to be able to go to definitions, even in the presence of functors, and easily find the types of things (and see their implementations).
being able to run a single test. It is crazy to me that today, you still can't write an inline test and run it. It's the best way to debug or test something.
better compiler error messages. I think the lack of a tool like cargo, and this, are the biggest impediment to the language. See this issue for an example.
better default for ocamlformat. OCaml is hard to read, some of the reasons are hard to change, but the formatting can be fixed and it really needs some work.
a linter like clippy. It's 2022, every project should be able to run an OCaml linter in CI.
good documentation for stdlib and 3rd party libraries. Documentation is really subpar in OCaml.
a use keyword to import specific values in scope (as opposed to "opening" a whole module in scope)
PS: would someone actually be interested to work on any of these for a grant? There's a number of new-ish companies in the OCaml space that would probably pay for someone to solve these. I guess reach out to me on the contact page if you're interested.
I just implemented method calls in noname, and I made a video showcasing it and checking if the implementation is correct with some simple examples.
Don't forget, if you want to play with it check it out here: https://github.com/mimoo/noname and if you have any questions or are running into something weird please leave a comment on the Github repo!
I guess this is part 3. With part 1 introducing noname, a programming language inspired by rust that makes use zero-knowledge proofs to provide verifiable computation, part 2 going over a simple arithmetic example and part 3 going over custom types.
In this update, I showcase a new feature: functions, and go through the debug compilation of an example program to see if the implementation is sound (that it constrains what it is supposed to constrain). In this video I do something more: I optimize the implementation of assert_eq so that you can see a bit of the compiler internals. I also end the video abruptly, thinking I found a bug in the implementation. If you were an attentive student, you would have figured out that there was no bugs: doing things on constants does not create any gates.
noname is the DSL I'm working on to write rust-like programs and prove their executions using zero-knowledge proofs.
The previous post used noname as an education tool to explain how programs get compiled to gates and constraints.
In this post, I showcase a new feature: custom gates, and go through the debug compilation of an example program to see if the implementation is sound (that it constrains what it is supposed to constrain).
I've talked about noname previously, my toy side project to create a DSL to write zkapps on top of kimchi.
I've recorded a video that showcase it, and walks through the circuit output by compiling one of the example. It might not make too much sense if you don't know about kimchi or plonk. And so you might want to watch my series of videos on plonk beforehands.
I've been spending a few weekends working on a DSL for writing zero-knowledge programs. It's been a fun project that's taught me a LOT about programming languages and their designs. I've always thought that it'd be boring to write a programming language, but my years of frustrations with languages X and Y, and my love for features Z and T of L, have made me really appreciate tweaking my own little language to my preferences. I can do whatever I want!
It's called "noname" because I really didn't know what name to give it, and I still haven't found a good one. You can play with it here: https://github.com/mimoo/noname, it is still quite bare bone but I'm amazed at what it can already do :D
It is very close to Rust, with some ideas from Golang that I liked. For example, I do not implement too much inference because it decreases readability, I force the user to qualify each library calls, I forbid shadowing within a function, etc.
Programs look like this:
use std::crypto;
fn main(pub public_input: Field, private_input: [Field; 2]) {
let x = private_input[0] + private_input[1];
assert_eq(x, 2);
let digest = crypto::poseidon(private_input);
assert_eq(digest[0], public_input);
}
and you can use the CLI to write your own programs, and generate proofs (and verify them). Underneath the kimchi proof system is used.
But the really cool feature is how transparent it is for developers! If you run the following command with the --debug option for example:
It's been forever since I've been thinking of doing a podcast. Today I decided screw it, I'll do it live.
From the description:
This series focuses on teaching you about cryptocurrencies from the very start! We'll start with databases, banks, distributed systems, and we will then go further with Bitcoin, Ethereum, Mina, and other cryptocurrencies that are making the world advance today.
Cryptocurrencies from scratch: databases, the banking world, and distributed systems
This is the first episode of a series on cryptocurrencies. In this series I will tell you about cryptocurrencies from scratch. This first episode is quite non-technical and should be easy to understand for most folks. I will explain what databases are, how banks around the world move money around, and what cryptocurrencies fundamentally offer.
Bitcoin from scratch: The Bitcoin client, public keys and signatures, and the miners
In the previous episode we briefly talked about what cryptocurrencies fundamentally are, and what problems they attempt to solve. In this episode we'll dig int our very first cryptocurrency: Bitcoin. This will be a high-level overview that will cover what the software looks like, what cryptographic signatures are, and who are these miners who process transactions.
More on Bitcoin: How does mining work? What are hash functions? And what is Proof of Work?
In this third episode we'll dig more into the tech of Bitcoin. But for that, we'll need to talk briefly about cryptographic hash functions and how they work. Once done, we'll talk about mining, proof of work, chains of blocks, and mining pools!
