# Circom buses: a new journey

- Speakers: [Albert Rubio](https://streameth.org/speakers/albert-rubio)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-15
- Duration: 15:17
- Watch: https://streameth.org/watch/673706ab74749a4b8973680e

## Description

Circom is one of the most widely used languages in programmable cryptography. In this talk we present an amazing new circom feature, called buses. Like structs in other languages, programmers can define their own buses, as new types, in a general way to create structured collections of signals and freely use them in their code. Buses increase the readability, modularity and security of circuits. Illustrative examples as well as the renewed circomlib, using buses, are presented.

## About the speakers

### Albert Rubio

Over the last five years I have been leading the development of circom, one of the main DSLs for defining ZK protocols. I have also extensively worked on developing tools and techniques for the analysis of smart contracts and on the generation of optimized EVM code (as part of funded projects by the EF). I am also leading the ZK-ARCKIT project (funded by the EF) to provide tools to analyze, transform and optimize the polynomial constraint systems generated for building ZK proofs.


## Transcript

Hello, welcome everybody. I'm here to present a new great feature of CIRCM called buses. So just a little bit of context of what is CIR Circum, just in case you don't know. So Circum is a DSL where the programmer explicitly provides the constraints defining the circuit, and also provides an efficient way to compute the witness. In Circum, one of the nice features that we have a large library of circuits that programmers can reuse. And in fact, this is really encouraged because this is the best way to program easily good and safe new circuits. What the compiler does is from this program produces constraint system in R1 CS on one hand and on the other hand you get the code that allows you to execute the circuit and compute the witness. Probably one of the drawbacks of CIRCOM till today was the fact that CIRCOM has or had two simple type system. Okay let's see it in an example assume that we want just as a simple example we want to to build a circuit comparing dates and then what happened that when you want to do that with circum there was no way to express dates you just could include signals and then you need to express six signals for day month and year of edge of the inputs okay so then you have something like this which doesn't express any structure of the of the data as a date okay so imagine that then you think okay let's put it all together and then I use an array but that's maybe even worse somehow because you don't even have any clue about what's the year day what's the the month what's the year so what do we really need so what we need is doing it properly okay and this from now on can be done with buses so with a bus you can introduce this new type that says well this is a single structure that will have the day, the month and the year. And then from that point on you operate with this and then you can say well I have two inputs, data dates and then of course you can access these fields of the bus using the standard dot operation. So this looks much nicer. So the point is that buses are a collection of signals, like trucks in other languages. And of course we call them buses because we work with circuits. And then what's a collection of signals? A bus. So this is the reason for the name and not using struct like in other languages. A bus can be defined in a very general way without restrictions. So you can use signals, arrays and other buses. Altogether. There is no restriction except for recursive definitions, arrays, and other buses. Okay? All together. There is no restriction except for recursive definitions, but they will come soon. Okay? So then a bus defines a new type. And the point is that now using these types, the compiler can prevent from mixing data. And that's very important. Okay? So now we will be able to ensure type safety and so on and also this will help us to define the library of circuits in a circuit in a proper way using all these data and and make it this nicer so let's see a bit a bit of this orthogonality in the definition of the of the buses and then see here, I have this date, but then I can define a new bus that uses this bus inside an array. No restriction at all. So now we have a new bus definition, which is made of a signal and an array of dates. Look that also we can use parameterized buses as we can have parameterized templates in Zircom. And this is just to make things fit well because you see here I define a template with a parameter and this parameter is used when defining a bus. So then I have this N for the plate and this end is again used to define the the bus that I'm using as input and look then here I'm using an anonymous component another feature of of sitcom then and you see I'm just using as input the array of dates that I that was a field of this profile bus. So everything is done smoothly like in any other language. All of a sudden you can see this code and it is no longer considered low level. It was something that was always said about Zircon that it was low level. It's not low level anymore. So look at this code., doesn't look low level. So let's go a bit on what we are providing with this. Now we can combine buses with another feature, what was called tags. And the combination of both things that you get new types using buses and then you also have some notion of subtyping using the tags. So now we can mix both things, the buses and tags. And then the tags can occur inside and outside the bus. So if they are inside the bus they restrict any instance of this bus. So you attach this property to all instances of the bus. But if you use it outside, it's for the particular instance you're using. And adding tags is very important, because somehow they show particular properties on the types. Okay, so this is a very nice combination that makes a good, still not so complex, but a strong and useful type system. Okay, so all this will impact a lot in the circumlip. And let's see it through an example coming from the library, which is this circuit for the baby Jab-Jab elliptic curve. And then the point is that in the original JabJab elliptic curve. And then the point is that in the original form you have something like this. You see, you work with points, but what happens? Again, the points are not there. So you have here two signals, one for the X, one for the Y, and it's for the two points, so there is no structure here. And then you also have operations for the Montgomery points, so there is no structure here. And then you also have the operations for the Montgomery form, and then we are using an array of two signals instead of the two signals. And then you see there is kind of a mismatch, but well, who cares? And then you have also the conversors as circuits, and then you see here we are using the Edward forms here as two signals and in the other part as an array of two signals. So altogether, it's low readability and error prone. So what's different now? So look, I will just create a bus for Edwards Point, and then I have all this so nicely written. I get an Edwards Point, another point, and produce another point. So for Montgomery Point, same there. I do this there, and I get the same nice presentation. And then you see here, I have this two things. And now for the conversers, you see everything looks nice. Then we have readable code and type safe. Okay, so finally using buses, I can avoid using both types of points because in fact they are points, but the thing is that they are in one form or another. Then I use tags to distinguish them. You see here, I say, yeah, I have a point, but it's Edwards. And then in Montgomery, I say, I have a point, but it's Montgomery. And then with the conversion, it's clear that I go from a point in Edwards to a point in Montgomery. And then the type check will check everything. Okay? Good. in Montgomery. Okay, and then the type check will check everything. Okay, good. So we have revised the library, we have added buses, tags, make it compatible with different primes, and we don't need to audit again because we have formally verified that the constraints are the same. It's simply that they are nicely written. Okay? So conclusions, CIRCOM is great, but now it's even better. Okay, so now we have these buses to structure circuits, and we can ensure pipe safety, and increase reliability and security, and help audit all these ZK projects. And of course, we will have this new circum lip for the, for the, for the, for adapted to all this. And just this for coming soon, but well, it's just what is coming in the next few months that will be useful for all developers. Okay, thank you very much. Thank you very much, Albert, for your wonderful presentation. Now for my favorite section, we're going to go to the Q&A. We have the QR code on the right. Make sure to scan it, and we can start with the first question. I saw a few questions kind of like are similar, so some people may be a bit confused about why a bus is called a bus and why not struct or class. As I said because this is a circuit we are programming circuits and then buses is the word I would say it's not just there is I wouldn't say well you can call it a structure. Structures are in C-like languages, but then why not a map or a dictionary or so? So we decide, okay, we are doing circuits or bosses. Got it. Thank you. Now for the next question, are there any educational courses that can follow up to learn Circle programming language? There are many. There is a lot of courses and tutorials on the web for following and learning Circle. I think that if you just put tutorials on Circle, you will get many of them available. Gotcha. So put tutorials and you'll find a lot of resources and documentation on it. Yeah. Okay. Next question is, what are some applications you're most excited about that is possible with circum buses? I mean, with buses, the point is not that you will be able to design new circuits. The point is that they will be defined in a nicer way. And they will be readable is that they will be defined in a nicer way and they will be readable and it will be much more difficult to make mistakes because even the compiler will check that all types match and then you're not gonna mix things that are not meaning the same. I think that it's more about the security of the circuits and of the way you program than the fact that you can develop new things a new project that you could not do before it's just so it improves the security but also offers a better UX for the devs overall very nice will circum become close to a high-level language like Python? Well, in fact, as I said, I think that it already got with these new types and development. I think that this already can be considered a high-level language. Maybe we don't have some of the features, but it's also because they are not needed for our purpose, I would say. I think that providing a good type system was the missing step for getting a high-level language. All right. We have a few more other questions. So people are very curious about Circa and Buses. So maybe when is it available to use? It's already available. So the release was kind of a month ago and we have just released the SIRCOM 2.2.1 because we are fixing we are improving some parts but it's all available already and you can download it and use it in all your circuits from now on. And for the second lib, it will be released, the new version with the buses will be released in a few days. Fantastic. So you can already try it out. Make sure to check it out. Is it possible to add methods or associated function to a bus? Not this way, because this is not intended to be like this. I mean, we are not an object-generated language, and the same as we don't have inheritance, or we just have this notion of subtyping by means of tax, and we are not considering that you have method-associated templates. I mean, a template itself does, I mean, it's a sub-circuit, and it's not that, I think it's not that much sense to add methods to do things on top of it. I mean, it's, the circuit describes what is intended to do from the inputs to the outputs, but it makes not much sense to add new operations on top of it. Got it. And I think this will be the last question because we're running out of time. So tags don't have to be declared ahead of time. It seems like an easy way to make a typo. Well, there is. So for tags need to be declared ahead. So buses should be declared ahead before using them. But for tags, it's not like this. Well, maybe in the near future, maybe we will start at least to have the possibility to describe them and from the beginning, associate them to some buses in advance to avoid mixing things or just making something that is not easy to read because you combine tags on different things. Okay. Fantastic. Well, thank you for answering these questions. And thank you for the audience for the questions. Again, a big round of applause for Albert. And thank you very much.