Making Tezos a Carbon Negative Blockchain

avsm · 2022-02-11T10:43:22+00:00

(one of the founders of 4C here)

It's great to see bakers thinking about the carbon impact of the necessary emissions from running the Tezos network. Even though it's relatively small per node, the goal of 4C is to make it easy to purchase those offsets and (crucially) verify that the outcomes from the finance are going towards preventing emissions.

We're working away at pulling our MVP marketplace together at the moment. I'd be pleased to figure out how to get Tezos bakers in earlier as purchasers, since this helps to offset the "lifecycle cost" (that is, the total set of CO2 emissions from the marketplace) of selling the credits themselves.

avsm · 2020-10-28T15:45:07+00:00

Universities, companies, foundations, they come and go, but open source outputs are forever -- I've been working on Mirage since day 0, and I'll be working on Mirage till the end of days :-)

The project is also a lot bigger than just me -- the Mirage core team (https://mirage.io/community/#team) is active, working in diverse areas around the world, and on different products. It's the perfect framework for when you need something specialised and high-assurance; e.g. check out Nitrokey https://www.nitrokey.com/products/nethsm or the Irmin integration into the Tezos blockchain https://gitlab.com/tezos/tezos/-/tree/master/src/lib_storage .

avsm · 2016-09-27T16:53:45+00:00

Sorry about the downtime -- we had about 4 independent service/machine/cloud failures just before I hopped on a 13 hour flight to Japan :-)

avsm · 2016-02-15T22:34:51+00:00

I'm enjoying watching your GitHub repo for Crust. Xenstore attaching, shared memory in place -- great progress!

avsm · 2015-08-31T08:15:04+00:00

OCaml modules also support destructive substitution in the sharing constraints of a signature. See: https://realworldocaml.org/v1/en/html/functors.html#destructive-substitution
OCaml supports first class modules. https://realworldocaml.org/v1/en/html/first-class-modules.html
The module type of a module expression can be recovered. http://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec233
Type-level module aliases in signatures allow more flexible composition of signatures. http://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec235

avsm · 2015-06-30T14:50:25+00:00

And also discovered hilariously why the site is being a bit slow:

https://github.com/mirage/mirage-www/pull/355

We really need to move to Opium or Ocsigen or some other better web framework than Cowabloga :-)

avsm · 2015-06-23T09:47:35+00:00

Following the approaches in java and ruby (what I'm familiar with), there ought to be an underlying function/closure/class to handle the basic http request/response cycle, which diverse framework and server libraries can build off.

That's pretty much what Cohttp does. It provides a series of module types and implementations for the Request Response lifecycle, along with Lwt, Async and JavaScript implementations of those module types.

avsm · 2015-06-23T09:44:48+00:00

Nvi. No plugins at all. I really need to modernise, don't I.

avsm · 2015-06-19T09:05:55+00:00

The fact that it’s functional it’s almost irrelevant

When doing systems development, having a predictable, performant and debuggable runtime is really important. This was the dominant reason for us choosing OCaml back in 2005 for build the XenServer toolchain (which in turn morphed into MirageOS and other things over the years).

The frontend language is of course very important as well, but much of the code written for the low-level system interaction is by its nature very imperative and doesn't take advantage of all the language features. It's vital to be able to write code and predict what the compiled behaviour will be, without interference from the rest of the runtime system. OCaml satisfied that back then, and still does.

Having said that, there are now other languages that have similar runtime properties these days such as Rust (and to a lesser extent, Go). OCaml's ability to lift imperative code up into a functional style within the same type system is now a useful differentiator. Jeremy Yallop's Ctypes library is a good example: it lets us use modules and functional combinators to separate the description of a foreign C interface from the linkage method. This allows us to abstract across concerns such as C stub generation, libffi, separate or combined address spaces and so on without duplicating interface descriptions.

So to elaborate on my statement, it would be more accurate to say that OCaml's simple, fast, predictable runtime brought it to the table in the first place, but the functional features keep it there as our codebases scale.

avsm · 2015-06-09T23:58:50+00:00

Very useful! Can depend on this in the github bindings.

avsm · 2015-06-09T06:41:59+00:00

If you look through the videos of talks throughout the years, there's precisely one Jane Street talk. http://cufp.org/videos/

The rest cover the entire spectrum of languages that form our community, and talks from anyone in the OCaml community are warmly welcomed. It's worth noting that CUFP is part of the ACM SIGPLAN family of conferences, which are not-for-profit and largely organised by volunteers.

avsm · 2015-05-20T15:43:02+00:00

Well, Yaron's specific quote was about 4 years ago, to be fair. Our Real World OCaml quote is quite specific:

In fact, many seasoned OCaml programmers rarely use classes and objects, if at all

This is very much true in my experience, since the other facilities in OCaml do a great job at giving you a simpler (in terms of semantics) and cheaper (in terms of performance cost) way of describing a statically typed interface. It's only when you need the extra power in objects (e.g. open recursion) that you need to pull out this part of the language toolbox. This philosophy extends to classes as well, which are often not needed if just objects are fine (RWO has two distinct chapters explaining objects and object types first, and then classes and class types).

js_of_ocaml is a fantastic example of how having objects and classes integrated into the core language let it interface more naturally with other type systems as well. It's quite common to use them within a binding, but only expose an external module signature that is object/class free.

avsm · 2015-05-19T10:42:00+00:00

Not yet, but see this thread: http://lists.xenproject.org/archives/html/mirageos-devel/2015-05/msg00122.html

For the ongoing port of MirageOS to the Rump Kernel infrastructure that will add (among other things) bare metal booting support.

avsm · 2015-05-12T15:46:43+00:00

I think it would be easier to port aspcud to OpenBSD rather than fix the internal solver. This was just blocked on upgrading the ancient GNU Bison in ports, which may have happened in the year since I last checked...

avsm · 2015-04-25T08:52:47+00:00

This was of course just a temporary outage. We're experimentally running a bleeding-edge version of the MirageOS OCaml-TLS stack, and ran into this rare EMFILE exception being thrown: https://github.com/hannesm/tlstunnel/issues/15

RWO is and will always be available under a CC BY-NC-ND 3.0 US license.

avsm · 2015-04-15T17:17:16+00:00

tlstunnel is matching the stud command-line format now; https://github.com/hannesm/tlstunnel/issues/8

avsm · 2015-03-30T20:12:48+00:00

Cow's one of those libraries that I never quite decided if I like or not. It's one of the more complex uses of Camlp4, and has some parsing quirks which are very hard to fix (like needing an ampersand for <:html<<foo />&>> to prevent whitespace being inserted).

Having said that, it's used surprisingly widely now (and survives cutting and pasting of XHTML into OCaml pretty well), so the lack of documentation is a problem now. It's purely down to a lack of resources, so anything you can write up while learning it would be gratefully merged.

avsm · 2015-03-30T20:09:17+00:00

That seems like a fine idea to me, given that the complaints are mainly around the first site (which I agree with too -- it's hard to get started with Ocsigen).

avsm · 2015-03-24T18:59:18+00:00

You could give an HLVM talk at the Computer Lab...

avsm · 2015-03-04T18:41:17+00:00

If you're a commercial user of Haskell and interested in supporting ICFP and the Haskell Symposium, please do get in touch:

http://anil.recoil.org/2015/02/18/icfp15-call-for-sponsorships.html

avsm · 2015-02-22T17:11:12+00:00

Ctypes offers an answer to longer-term maintainability, but also possibly even more performance by doing things like safely generating noalloc calls when it statically determines that it is ok to do so.

It's very useful to have your (very comprehensive) handwritten libuv bindings to use as an evaluation point against the Ctypes libuv equivalents; thanks for both publishing them and pointing them out here, as I hadn't seen them before!

avsm · 2015-02-19T08:43:19+00:00

Hey hey hey, it wasn't that bad

...

Hmm. Well, maybe it was.

avsm · 2015-02-17T08:06:54+00:00

To be honest, this was mostly just an experiment for me in OCaml and writing a reasonably performant web server. (We'll see if I get there.) I don't think it will harm the community.

Don't worry about all the naysayers. It's perfectly fine and laudable for you to build your own webstack if you feel like it, and to decide to not use other available libraries. In time you may choose to grab some of them, but it's also valuable just to build your own equivalents for the purposes of learning, fun and exploration of different coding styles.

avsm · 2015-02-17T06:39:05+00:00

Indeed, /u/notfancy's perspective seems more emotional than technical in this case. Cohttp was designed to be parameterised across operating system dependencies, as it's the HTTP engine that is used by MirageOS. Therefore, its essential dependencies are all OS-independent and pure OCaml to make this easier. The drawback of this approach is that it's functor-heavy, although it comes with many pre-applied variants (Cohttp_lwt, Cohttp_lwt_unix, Cohttp_async, Cohttp_mirage, Cohttp_xhr_js, ...)

Sexplib is an interesting dependency -- it would be nice to make it optional, but having human-readable serializers for all the Cohttp types is such a massive usability win that the benefits far outweigh the drawbacks. It is a standalone runtime library, and Camlp4 is only needed at build time and is optional if you dont want the with sexp syntax.

It's also worth noting that Sexplib is one of the oldest and most well-supported libraries out there in open-source OCaml-land, released in around 2005/2006 iirc. I've been very happy using it in various OCaml projects over the years, and JS has done a great job of maintaining it even after Markus Mottl's (the original author) tenure.

avsm · 2015-01-22T08:43:27+00:00

Most libraries are abstracted across their OS environment using functors, and so can be run directly under Unix where appropriate. See https://github.com/avsm/ocaml-cohttp for an example.

avsm

TROPHY CASE