Pyrofex

Mike Stay is applying category theory to computation at a new startup called Pyrofex. And this startup has now entered a deal with RChain.

But let me explain why I’m interested. I’m interested in applied category theory… but this is special.

Mike Stay came to work with me at U.C. Riverside after getting a master’s in computer science at the University of Auckland, where he worked with Cristian Calude on algorithmic randomness. For example:

• Cristian S. Calude and Michael A. Stay, From Heisenberg to Gödel via Chaitin, International Journal of Theoretical Physics 44 (2008), 1053–1065.

• Cristian S. Calude and Michael A. Stay, Most programs stop quickly or never halt, Advances in Applied Mathematics, 40 (2008), 295–308.

It seems like ages ago, but I dimly remember looking at his application, seeing the title of the first of these two papers, and thinking “he’s either a crackpot, or I’m gonna like him”.

You see, the lure of relating Gödel’s theorem to Heisenberg’s uncertainty principle is fatally attractive to many people who don’t really understand either. I looked at the paper, decided he wasn’t a crackpot… and yes, it turned out I liked him.

(A vaguely similar thing happened with my student Chris Rogers, who’d written some papers applying techniques from general relativity to the study of crystals. As soon as I assured myself this stuff was for real, I knew I’d like him!)

Since Mike knew a lot about computer science, his presence at U. C. Riverside emboldened me to give a seminar on classical versus quantum computation. I used this as an excuse to learn the old stuff about the lambda-calculus and cartesian closed categories. When I first started, I thought the basic story would be obvious: people must be making up categories where the morphisms describe processes of computation.

But I soon learned I was wrong: people were making up categories where objects were data types, but the morphisms were equivalence classes of things going between data types—and this equivalence relation completely washed out the difference, between, say, a program that actually computes 237 × 419 and a program that just prints out 99303, which happens to be the answer to that problem.

In other words, the actual process of computation was not visible in the category-theoretic framework. I decided that to make it visible, what we really need are 2-categories in which 2-morphisms are ‘processes of computation’. Or in the jargon: objects are types, morphisms are terms, and 2-morphisms are rewrites.

• Barnaby P. Hilken, Towards a proof theory of rewriting: the simply-typed 2λ-calculus, Theor. Comp. Sci. 170 (1996), 407–444.

• R. A. G. Seely, Weak adjointness in proof theory in Proc. Durham Conf. on Applications of Sheaves, Springer Lecture Notes in Mathematics 753, Springer, Berlin, 1979, pp. 697–701.

• R. A. G. Seely, Modeling computations: a 2-categorical framework, in Proc. Symposium on Logic in Computer Science 1987, Computer Society of the IEEE, pp. 65—71.

But I felt this viewpoint wasn’t nearly as popular as it should be. It should be very popular, at least among theoretical computer scientists, because it describes what’s actually going on in the lambda-calculus. If you read a big fat book on the lambda-calculus, like Barendregt’s The Lambda Calculus: Its Syntax and Semantics, you’ll see it spends a lot of time on reduction strategies: that is, ways of organizing the process of computation. All this is buried in the usual 1-categorical treatment. It’s living up at the 2-morphism level!

Mike basically agreed with me. We started by writing introduction to the usual 1-categorical stuff, and how it shows up in many different fields:

• John Baez and Michael Stay, Physics, topology, logic and computation: a Rosetta Stone, in New Structures for Physics, ed. Bob Coecke, Lecture Notes in Physics vol. 813, Springer, Berlin, 2011, pp. 95–172.

For financial reasons he had to leave U. C. Riverside and take a job at Google. But he finished his Ph.D. at the University of Auckland, with Cristian Calude and me as co-advisors. And large chunk of his thesis dealt with cartesian closed 2-categories and their generalizations suitable for quantum computation:

• Michael Stay, Compact closed bicategories, Theory and Applications of Categories 31 (2016), 755–798.

Great stuff! My students these days are building on this math and marching ahead.

I said Mike ‘basically’ agreed with me. He agreed that we need to go beyond the usual 1-categorical treatment to model the process of computation. But when it came to applying this idea to computer science, Mike wasn’t satisfied with thinking about the lambda-calculus. That’s an old model of computation: it’s okay for a single primitive computer, but not good for systems where different parts are sending messages to each other, like the internet, or even multiprocessing in a single computer. In other words, the lambda-calculus doesn’t really handle the pressing issues of concurrency and distributed computation.

So, Mike wanted to think about more modern formalisms for computation, like the pi-calculus, using 2-categories.

He left Google and wrote some papers with Greg Meredith on these ideas, for example:

• Michael Stay and Lucius Gregory Meredith, Higher category models of the pi-calculus.

• Michael Stay and Lucius Gregory Meredith, Representing operational semantics with enriched Lawvere theories.

The second one takes a key step: moving away from 2-categories to graph-enriched categories, which are simpler and perhaps better.

Then, after various twists and turns, he started a company called Pyrofex with Nash Foster. Or perhaps I should say Foster started a company with Mike, since Foster is the real bigshot of the two. Here’s what their webpage says:

Hello—

My name is Nash Foster, and together with my friend and colleague Mike Stay, I recently founded a company called Pyrofex. We founded our company for one simple reason: we love to build large-scale distributed systems that are always reliable and secure and we wanted to help users like yourself do it more easily.

When Mike and I founded the company, we felt strongly that several key advances in programming language theory would ease the development of every day large-scale systems. However, we were not sure exactly how to expose the APIs to users or how to build the tool-sets. Grand visions compete with practical necessity, so we spent months talking to users just like you to discover what kinds of things you were most interested in. We spent many hours at white-boards, checking our work against the best CS theory we know. And, of course, we have enjoyed many long days of hacking in the hopes that we can produce something new and useful, for you.

I think this is the most exciting time in history to be a programmer (and I wrote my first program in the early 1980’s). The technologies available today are varied and compelling and exciting. I hope that you’ll be as excited as I am about some of the ideas we discovered while building our software.

And on January 8th, 2018, their company entered into an arrangement with Greg Meredith’s company Rchain. Below I’ll quote part of an announcement. I don’t know much about this stuff—at least, not yet. But I’m happy to see some good ideas getting applied in the real world, and especially happy to see Mike doing it.

The RChain Cooperative & Pyrofex Corporation announce Strategic Partnership

The RChain Cooperative and Pyrofex Corporation today announced strategically important service contracts and an equity investment intended to deliver several mutually beneficial blockchain solutions. RChain will acquire 1.1 million shares of Pyrofex Common Stock as a strategic investment. The two companies will ink separate service contracts to reinforce their existing relationship and help to align their business interests.

Pyrofex will develop critical tools and platform components necessary for the long-term success of the RChain platform. These tools are designed to leverage RChain’s unique blockchain environment and make blockchain development simpler, faster, and more effective than ever before. Under these agreements, Pyrofex will develop the world’s first decentralized IDE for writing blockchain smart contracts on the RChain blockchain.

Pyrofex also commits to continuing the core development of RChain’s blockchain platform and to organizing RChain’s global developer events and conferences.

“We’re thrilled to have an opportunity to strengthen our relationship with the RChain Cooperative in 2018. Their commitment to open-source development mirrors our own corporate values. It’s a pleasure to have such a close relationship with a vibrant open-source community. I’ve rarely seen the kind of excitement the Coop’s members share and we look forward to delivering some great new technology this year.” — Nash E. Foster, Cofounder & CEO, Pyrofex Corp.

“Intuitive development tools are important for us and the blockchain ecosystem as a whole; we’re incredibly glad Pyrofex intends to launch their tools on RChain first. But, Ethereum has been a huge supporter of RChain and we’re pleased that Pyrofex intends to support Solidity developers as well. Having tools that will make it possible for developers to migrate smart contracts between blockchains is going to create tremendous possibilities.” — Lucius Greg Meredith, President, RChain Cooperative Background

Pyrofex is a software development company co-founded by Dr. Michael Stay, PhD and Nash Foster in 2016. Dr. Stay and Greg Meredith are long-time colleagues and collaborators whose mutual research efforts form the mathematical foundations of RChain’s technology. One example of the work that Greg and Mike have collaborated on is the work on the LADL (Logic as Distributed Law) algorithm. You can watch Dr. Stay present the latest research from the RChain Developers retreat.

Pyrofex and its development team should be familiar to those who follow the RChain Cooperative. They currently employ 14 full-time and several part-time developers dedicated to RChain platform development. Pyrofex CEO Nash Foster and Lead Project Manager Medha Parlikar have helped grow RChain’s development team to an impressive 20+ Core devs with plans on doubling by mid 2018. The team now includes multiple PhDs, ex-Googlers, and other word class talents.

Every Wednesday, you will find Medha on our debrief updating the community with the latest developments in RChain. Here she is announcing the recent node.hello release along with a demo from core developer Chris Kirkwood-Watts.

The working relationship between the RChain Cooperative and Pyrofex has gone so well that the Board of Directors and the community at large have supported Pyrofex’s proposal to develop Cryptofex, the much needed developer tool kit for the decentralized world.

The RChain Cooperative is ecstatic to further develop its relationship with the Pyrofex team.

“As we fly towards Mercury and beyond, we all could use better tools.”
— The RChain Co-op Team.

Listen to the announcement from Greg Meredith as well as a short Q&A with Pyrofex CEO Nash Foster, from a recent community debrief.

The following is an excerpt from the soon to be released Cryptofex Whitepaper.

The Problem: Writing Software is Hard, Compiling is Harder

In 1983, Bordland Software Corporation acquired a small compiler called Compas Pascal and released it in the United States as Turbo Pascal. It was the first product to integrate a compiler and the editor in which software was written and for nearly a decade Borland’s products defined the market for integrated development environments (IDEs).

The year after Borland released TurboPascal, Ken Thompson observed the distinct and unique dangers associated with compiler technologies. In his famous Turing Award acceptance speech, Thompson described a mechanism by which a virus can be injected into a compiler such that every binary compiled with that compiler will replicate the virus.

“In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.” — Ken Thompson

Unfortunately, many developers today remain stuck in a world constructed in the early 1980’s. IDEs remain essentially the same, able to solve only those problems that neatly fit onto their laptop’s single Intel CPU. But barely a month ago, on 22nd November 2017, the Intel Corporation released a critical firmware update to the Intel Management Engine and in the intervening weeks, the public at large has become aware of the “Meltdown” bug. The IME and other components are exactly the sort of low-level microcode applications that Thompson warned about. Intel has demonstrated perfectly that in the past 33 years, we have learned little and gone nowhere.

Ironically, we have had a partial solution to these problems for nearly a decade. In 2009, David A. Wheeler published his PhD dissertation, in which he proposed a mechanism by which multiple compilers can be used to verify the correctness of a compiler output. Such a mechanism turns out to be tailor-made for the decentralized blockchain environment. Combining Wheeler’s mechanism with a set of economic incentives for compile farms to submit correct outputs gives us a very real shot at correcting a problem that has plagued us for more than 30 years.

The Solution: A Distributed and Decentralized Toolchain

If we crack open the development environments at companies like Google and Amazon, many of us would be surprised to discover that very few programs are compiled on a single machine. Already, the most sophisticated organizations in the world have moved to a distributed development environment. This allows them to leverage the cloud, bringing high-performance distributed computing to bear on software development itself. At Google, many thousands of machines churn away compiling code, checking it for correctness, and storing objects to be re-used later. Through clever use of caching and “hermetic” builds, Google makes its builds faster and more computationally efficient than could possibly be done on individual developer workstations. Unfortunately, most of us cannot afford to dedicate thousands of machines to compilation.

The open-source community might be able to build large scale shared compilation environments on the Internet, but Ken Thompson explained to us why we could not trust a shared environment for these workloads. However, in the age of blockchain, it’s now possible to build development environments that harness the power of large-scale compute to compile and check programs against programmer intent. Secure, cheap, and fast — we can get all three.

CryptoFex is just such a Decentralized Integrated Development Environment (DIDE) allowing software engineers to author, test, compile, and statically check their code to ensure that it is secure, efficient, and scalable.

17 Responses to Pyrofex

1. Ilyas Khan says:

Hi John. Thank you for posting this interesting story. On a related note you might be interested in the collaboration between Cambridge Quantum Computing (where I work) and Bob Coecke’s group in Oxford which has the objective of exploring how to reduce the cost of implementing quantum software. There is some more detail and context in the link below and as a consequence of learning more about a very specific relationships between the entirely practical challenge of designing compilers for quantum processors and (in this case) ZX Calculus. I am very interested in Pyrofex. So thanks again for the blog post.

http://cambridgequantum.com/2017/10/20/collaboration-with-university-of-oxford-computer-science-department/

• John Baez says:

Thanks! And thanks for supporting the forthcoming journal Compositionality! I’ll be blogging about that here and elsewhere, once it takes off.

• I’m intrigued! Is there public info on this journal?

• John Baez says:

Whoops! No, not yet.

• OK :-) I’ll wait, and if it is a good one, as I suspect it is, I will publicise…

2. Bruce Bartlett says:

Congrats to Mike Stay. It is wonderful to see the success of a category-theoretic approach to computer science in this way.

• Mike Stay says:

Thanks! It’s not quite a success yet, but we’re working on it.

3. Bob Haugen says:

If I understand correctly, this blog has recently featured two different blockchainy projects from two different crews in the same posse roughly related by category theory:

• and Pyrofex and RChain.

Is that accurate enuf for blog discussion purposes?

If so, what’s the diff between them?

And will they be composable?

And is there a categorical expression to describe this development?

• John Baez says:

These are really interesting questions, but all I know is what I already wrote. Both projects are still under development, so I can’t just read a user’s manual for each system and compare them. But at present, they’re obviously different projects with different goals using different math—you can see that from my blog articles. As far as I can tell, Statebox aims to develop a “universal language for distributed systems”—a language with a strong visual aspect to it, using open Petri nets. Pyrofex is trying to develop “the world’s first decentralized integrated development environment for writing blockchain smart contracts on the RChain blockchain”.

• Bob Haugen says:

http://statebox.org/index.html says they got a blockchain, too…
and Pyrofex also has their own programming language (or at least version of Javascript), Pyr8.

So, in both cases: different blockchain + different programming language, but both inspired by category theory.

Anybody know what is different about their math?

• John Baez says:

Bob wrote:

Anybody know what is different about their math?

That was explained in the blog articles. It’s not a full explanation: for one thing, neither project is done yet. But if you read the articles you’ll see the math sounds pretty different except for the words ‘blockchain’ and ‘category’. For example Statebox seems to be using open Petri nets as part of a visual programming language for distributed systems, while Pyrofex appears to be using graph-enriched Lawvere theories to help set up a secure environment for software development.

• Mike Stay says:

From what I can tell, Statebox is using symmetric monoidal categories and other 1-categorical constructions. They seem to be interested in proving that they’re producing correct output, but not so much interested in the process of how they get there.

As John wrote above, I’ve been working on modeling operational semantics with higher categories like Gph-enriched Lawvere theories and working on incorporating the higher-dimensional stuff into the type system.

The Pyr8 software was a project we worked on for a year before pivoting to work on cryptocurrency. It was meant to run in datacenters, where the computers trust each other, as opposed to RChain, where everyone is mutually suspicious.

• Christian Williams says:

Yes, both are pioneering the exciting new field of categorical distributed computation, but at the moment they are not yet closely related. Which is good, because it means they have a lot to learn from each other!

Statebox is just beginning development, while Pyrofex is fairly new as well; we are of course very interested in exploring possible connections and collaborations, but this will take time. Thank you for mentioning this.

4. […] Pyrofex 4 by mathgenius | 1 comments on Hacker News. […]

6. John Baez says:

Over on Hacker News norswap wrote:

Why, why, why? What’s the point? Why do we want this?

The technology may be marvelous, if you don’t tell me why it’s useful, I won’t care one whit.

Mike Stay replied:

RChain is an Ethereum competitor. It aims to fix several problems with Ethereum.

First, it will scale better: Ethereum currently runs every contract on every computer running a node, and insists on a total order on all transactions. RChain will have a notion of a rooted directed acyclic graph of regions in which contracts will run, a much finer-grained notion of transaction, and will only insist on a partial order for transactions: when they do not conflict, they can be in any order.

Second, Ethereum has no type system. This has led to bugs in various contracts and wallets. In June 2016, a buggy contract led to the theft of \$50M in ETH from the DAO. The Ethereum community split into two parts: the first part insisted that “code is law” and that the hacker engaged in a series of perfectly valid transactions with the contract, so he was entitled to the ETH; the second part wanted human intervention to roll back a large transaction that was obviously a bug. They never reconciled, and “Ethereum Classic” forked off as a separate currency. Last year, someone exploited a bug in a Parity wallet and locked up \$380M. Contracts are expressions of programmer intent, but programmers are human and make mistakes. Type systems allow programmers to write a kind of “summary” of their intent as a type. The compiler compares the two expressions and fails if they are not consistent. Greg Meredith (President of RChain) showed that one could have defended against the theft using a spatial-behavioral type system:

Third, the Ethereum VM has suffered from various bugs (https://bounty.ethereum.org/) and relies on a find-and-patch system. RChain intends to formally verify as much of the platform as possible.

Last and probably least, Ethereum uses proof of work, which is basically proof of stake, but you’re staking GPUs and ongoing electricity costs. RChain will use Vlad Zamfir’s “correct by construction” proof of stake algorithm.

7. theshiz11 says:

This is all incredible stuff. Mike truly has great talent.

This site uses Akismet to reduce spam. Learn how your comment data is processed.