 Hi, everyone. Thanks for your interest in my APS talk, despite the circumstances. Regardless, I'd like to thank the APS Quantum Division for inviting me. So I am Ted Yoder from IVM, and this is joint work with Rahul, who is a PhD student at Stanford and who is also our intern. So I think in the scientific program, this was called something like surface codes based on rotation systems acting on maron fermions. And that is like a technique that we use, but I wanted to give here a more general title. So a graph-based formalism for surface codes and twists, because our motivation is really just one of unifying a bunch of surface code models and then going beyond that with some more examples and new codes. Okay, so here we have a bunch of different surface code models that are in the literature. In the lower left, we have the Brabikotayov model, which is the first surface code on the plane, and then Bombin and Martin Delgado recognize that you could rotate this to reduce the number of physical qubits that you need. So you still get one logical qubit and a code with the same distance, but you've cut the number of physical qubits in half, roughly. And then Bombin sometime later noticed that you could encode logical information into what are called twist defects in this 2010 paper, icing anions with a twist. But then also in the literature are a bunch of different representations of twists. So in my work with Isaac Kim, we had this triangular surface code where we move one of these, like, Hector Bombin twists into the middle of the code and also get a savings in the number of qubits here, right, over the standard rotated surface code. And then Kusselring had all sort of generalized the triangle code even into some sort of stellated codes, which asymptotically, as you increase this symmetry, can use even fewer qubits per logical qubit. And then there are different varieties of twists, like Krishna and Pulon also have some sort of different construction of these defects. So what we're really asking here is, you know, what unifies these models? When we come up with a formalism where each of these are special cases and then once we have such a formalism, what new codes can we find out? Okay, so why do you want to unify these? Well, the first, the zeroth reason might just be sort of being intellectually satisfied, right, that you now understand the full scope of what's out there. But some more concrete reasons are like if I want to optimize the code parameters, N being the number of physical qubits, K being the number of logical qubits, and D being the code distance, it's nice to have a general framework to sort of search through. And so this found where N is at least Kd squared or some constant times Kd squared, that's the Bravipul and Turhull bound, we want to optimize the constant C or minimize it more specifically. The second reason might be that you want to, you know, figure out what properties are fundamental to the service code. Like, is it important that the X logical operator is running one way and the Z the other? Certainly the topology of the logical operators is important, the fact that these are string-like. So we'll see some of that in our more generalized model. And then third, you might want to relate different codes through some local Clifford transformations. So some sort of generalization of Pockner moves. So I have one slide on this as well. So we'll go through each of these most explicitly. Number one is what we'll care about. Okay, so here's something of an outline of our construction. So you start with an embedded graph in any two manifold. It can be orientable or not. And then you associate mayuranas to every half-edge and odd-degree vertex. We'll motivate why that's the case. And in doing so, you get a mayurana service code. And then from this mayurana service code, you can associate some qubits such that the Hilbert spaces are equivalently represented. And you associate these qubits the vertices of the graph. And now you end up with a qubit service code. So if you wanted to skip the mayurana part, we also have a way to do that if you define these what we call cyclically anti-commuting sets of policies. Okay, so that's the rough outline of the construction. And we'll go through in more detail, obviously. But then once you have the construction, you can prove things about what the code parameters are after you do this. So we have a formula for k. We have bounds on the code distance. And then we have examples of different kinds of surface codes and Pochner moves to move between different codes or move around some of the odd-degree vertices. Okay. So to begin, we have to describe what a graph embedding is. And there's a nice combinatorial description of a graph embedding from the math community, which is called a rotation system. So what a rotation system is, is a set. You start with a set of half edges and also two permutations of the set. So nu is just any old permutation. And epsilon is a permutation that has to square to identity and also has no fixed points. And so now the things we associate with graphs, the vertices, edges, and faces correspond to orbits of nu epsilon and nu composed with epsilon, respectively. So for instance, this is why epsilon needs to square to identity because epsilon maps you from one half edge to the other half edge that both combined make up one edge of your graph. So you can see on the right here some examples of how a face corresponds to an orbit of nu composed with epsilon, how a vertex corresponds to an orbit of nu, how an edge corresponds to an orbit of epsilon. And then you can just figure out the genus of this surface using Euler's formula and counting the number of orbits. So the first part of this slide is a brief outline of what Majorana's are and Majorana codes. Majorana operators are just like these mutually anti-commuting operators. We'll think of here. And then they define a Majorana group. And if I'm defining a Majorana stabilizer code, then we can just take some subgroup of that Majorana group to form our stabilizers. And it's important that, of course, minus i is not in the stabilizer. And also that every stabilizer has even weight. That's sort of a physical constraint that the stabilizers preserved for me on parity. Okay, and so starting from our graph embedding, our rotation system, we associate Majorana's to each half edge and also each odd-degree vertex. So this is kind of like what Braviadol do in this correcting coherent errors with service codes paper. But they just do it for the rotated service code. And this is the more general prescription. Now, I've just told you where to put the Majorana's, but you also have to define stabilizers for them. So the stabilizers are associated to each vertex and also each face. So this picture on the right is supposed to be representing that the vertex stabilizers are the products of all Majoranas on half edges around that vertex and also possibly a Majorana at that vertex if it's an odd-degree vertex. And a face stabilizer is the product of all Majoranas around that face on the half edges only. So it's outlined in gold on the right. And so what sort of struck me about this rotation system picture is that we have these sort of abstract half edge objects that we use to define the graph, but now we're instantiating them with something physical, these Majorana operators. Okay, so from the Majorana code, we now want to convert it to a qubit surface code. Okay, so what we need to recognize is that there's the simple Majorana code where you have Majoranas and the only stabilizer, or the only non-identity stabilizer, is just the product of all the Majoranas. And this happens to encode m-2 over two qubits. And a basis for the logical operator is just like any product of two Majoranas. But this simple service code we can recognize is located at any face, or at any vertex of our code construction. So if we just replace the code space of this simple vertex code with m-2 over two qubits, then we've represented the exact same Hilbert space. So we just want to place m-2 over two qubits at every vertex. So this corresponds to placing one qubit at degree three and four vertices, two qubits at degree five and six vertices, and et cetera, three qubits at seven and eight, et cetera. And now the only stabilizers we have are just associated to faces of the graph. The vertex stabilizers in the Majorana code are automatically taken care of. Okay, so to describe this somewhat more directly without referring to the Majoranas, we can define a cyclically anti-commuting list of Pauli's. And this is just some ordered list of Pauli's where neighbors in the list, and it's also cyclic, of course. The first element is a neighbor of the last element. Neighbors in the list anti-commute, and anything else commutes. Okay, so like simple examples of cyclically anti-commuting lists are just the list x, y, z, or the list x, z, x, z. Okay, so given your embedded graph, you write down a cyclically anti-commuting list of Pauli's around each vertex, and of course the length of that list will have to correspond to the degree of that vertex. And then the product of Pauli's within a face is what you want to define as your stabilizers. So you get one stabilizer for every face. And you can also compare this with what Jonas Anderson calls the label set in this paper, which is basically his version of cyclically anti-commuting lists for vertices that have one qubit at them, in our language as would be the degree in three and four vertices. Okay, so how do you construct cyclically anti-commuting lists? Well, as I said, it's obvious for degree three and four, or length three and four, where you just have x, y, z and x, z, x, z. But then actually for higher degrees or longer lists, you can just compose these degree three and four lists. So on the left here, we have a degree seven vertex, which means that we have to write seven Pauli's around it. But then if we decompose it into two degree four vertices and one degree three vertex, we can actually just read off the Pauli's that we should choose. So in this case, there are seven sectors in the right-hand drawing, and there are seven sectors on the left-hand drawing, and those just correspond to each other one-to-one. And likewise with a degree eight vertex. Now it's just a composition of three degree four vertices. And you can imagine doing this like if I have for even larger L, if I have L equals nine, then I would just tack on another degree three vertex. Okay, so I've told you how to build your surface codes using these cyclically anti-commuting lists and some embedded graph. And now the question is, what are the properties of those codes? How many qubits does it encode? What is the code distance? So we'll take care of the number of encoded qubits here. This theorem tells us K, tells us the number of encoded qubits based on properties of the surface, whether it's orientable or non-orientable. It's genus, the number of odd degree vertices in the graph, and whether or not the graph is what we call a checkerboardable or not. So we say a graph is checkerboardable. If its faces can be too colored. And of course adjacent faces, faces sharing an edge have to be colored differently. So just to give you a rough idea of how this proof goes, you just count the number of independent stabilizer generators. And then K is equal to N minus that number. So there's a stabilizer generator for every face. So of course we have at most that many independent generators. But those aren't all independent. So actually the product of all faces is always identity. And you can even use some properties of these cyclically anti-commuting lists to show that the product of everything in the list has to be identity. So if I take the product of all faces, I will get identity on the entire space. And then also if the graph happens to be checkerboardable, then the product of all of one color of the faces, let's say the product of all the white faces is also identity. So you get these two different dependencies. Okay, so this reduces the number of independent generators as I've written here. And this is basically how the proof goes. You have to apply Euler's formula and that's how you get the genus part. But I think you can get the idea. Okay, so let's see some examples of this formula in action. So on the left-hand side, this is the rotated surface code. And I would say this graph is not checkerboardable. And this is a bit of a surprise because look, I've drawn this and it looks like a checkerboard. But there's actually an outer face. This is a tiling of the sphere. There's an outer face around this graph. And the outer face borders both white faces and black faces. So it's impossible to color the outer face consistently. So in this sense, this graph is not checkerboardable. It also has four odd-degree vertices that you can count. Those are just the corners. They're degree three. Everything else is degree four. So if you plug this into the formula, it's a, you know, it's a genus zero surface. It has four odd-degree vertices. We get the total number of encoded qubits is one. Compare this to the right-hand side. This is a checkerboardable graph. It's on the torus. And so genus equals one. It's orientable. It's checkerboardable, which means we have two encoded qubits. Now you may notice that you may notice something a little bit funny here. So if I, this graph is only checkerboardable because I've chosen it to be like four by four. So there are four horizontal lines and there are four vertical lines. If instead I choose it to be three by three, then the graph is no longer checkerboardable. And so here's like an attempt to checkerboard it. So I've colored these two faces black and I've colored their neighbors white, but then I don't know what to do with the faces around the outside. So this ends up being not checkerboardable. And if you plug this into the formula, you see that the number of encoded qubits is now one. So we've actually lost an encoded qubit. It's a very similar graph. It just happened that when there's an odd dimension of your square lattice on the torus, then you lose one of the encoded qubits because it's no longer checkerboardable. Despite this, sometimes I will draw the graph and color it. Even though it's not checkerboardable, I will color it. There are faces, neighboring faces that are the same color. And in doing so, I will define these defect lines, which basically include the edges between faces of the same color. So if you remove these edges from the graph, then you would get a checkerboardable graph. That is how the defect line goes. This won't be a big deal in this talk. But I'm just saying that this is some way that you can define a generalized notion of checkerboardability that makes these defect lines between twists. It gives them a mathematical definition. Okay, so let's get into some examples. So the first example I want to go through are what we're calling cyclic torc codes. So the way to draw these is on the torus, you draw two lines, two perpendicular lines. Y equals BX over A and Y equals minus AX over B. And then, you know, this is how you draw the graph. And if we draw the cyclically anti-commuting list around every vertex, then you can see explicitly the stabilizers XZ, ZX. The famous five qubits code stabilizers and the code is cyclic. Because you can translate these square faces along the Y equals B over AX direction. More generally, you get codes with A squared plus B squared physical qubits. If N, the number of physical qubits is odd, then you have one encoded qubit and the distance is A plus B. If N is even, you get two physical qubits and the distance is the maximum of A and B. So actually, we achieve N equals KD squared over 2 in two different regimes. So when you choose A equals B minus 1, or when you choose A equals 1 and B to be odd. And this is interesting because, you know, the rotated surface code achieves N equals KD squared and here we've had that, right? So I should point out that the A equals B minus 1 codes appear in this paper by Kovalov, Dumar and Priyadko where they're described somewhat differently. Alright, so some of you might be wondering, you know, you've defined your surface code model. How does that relate to Kataev's surface code? So in Kataev's model, you start with an embedded graph just as we do, but you place qubits on the edges and you define X type and Z type stabilizers around vertices and faces, respectively. In our model, how we would describe this is we would say there's a surface code defined on the medial graph of the graph that you started with. So you start with some graph here and I'm showing this on the projected plane because, well, in the end we're going to end up with Schor's code. So we start with some graph, we associate qubits to the edges, and then in our model, how we would define the stabilizers, they have to be associated to faces. So we should make every vertex and every face in this graph into a face in this medial graph. And so something we should point out about the medial graph is that they are always checkerboardable and they are also always for regular. So if you have a Kataev's surface code, you always end up with in our model what we would call checkerboardable and for regular graphs. Now that means you also don't have any odd degree vertices, so m equals 0. So in our theorem for the number of encoded qubits, you would simply have 2 times g encoded qubits or g depending on whether the surface is orientable or not. And now similar observations about medial graphs were made in these two papers. Okay, but moving on with some more examples, we can take these stellated codes of which the triangle code is one example and place them on higher genus surfaces. So the key observation here is that if I take a square and associate its opposite sides, that represents a torus of course. But likewise, if you take a hexagon and associate the opposite sides, that also represents a torus. So if we look over on the right hand side at the triangular surface code and we now associate opposite edges, we imagine this triangular surface code as a hexagon and we associate opposite edges. Then we've embedded this onto a torus. And actually when you do this, you double the number of logical qubits and you slightly reduce the number of physical qubits as well because now some qubits that were on the edges of the original code are associated with the qubit on the opposite edge. So you subtract the number of physical qubits related to the perimeter of the code. And you can do this for these higher order stellated codes as well. Just in general, if you have an n-gon and you associate opposite sides, you represent a genus n over 4 surface. So here, for instance, is the stellated code with five-fold symmetry. It starts out as a 3225 code. But then you can, by embedding on the double torus, get a 2345 code. So in general, we're doubling the number of logical qubits. And so actually with higher symmetry and higher genus surfaces, you approach n equals one-quarter kd squared versus n equals one-half kd squared, which is the planar stellated codes in Kessler. But what if we don't want to go to higher genus surfaces and we also don't want to have this sort of hyperbolic geometry in the center where we have to pack a lot of qubits into a small area? Well, then we could look at just codes in the plane. So in this case, we think about this problem as a circle packing problem. We want to take these twist defects and pack them as closely as we can in the plane, but still allowing a distance d between them, where d is the code distance. So the triangle code, of course, drawn here, achieves three-quarters kd squared and will abstract away the lattice work. So the lattice work basically controls the distance. You can choose whatever distance you want by choosing a finer and finer lattice. But here's sort of the abstract triangle code. If we extend the patch a bit and add two more odd-degree vertices, represented by the stars, then we also add two more of these d over two by d over two square faces. But in total, we get a smaller constant. So we get n equals 5 eighths kd squared. And likewise, we can just keep extending this code patch and get closer and closer to one-half kd squared. And this one-half kd squared was also pointed out by Hayes-Things and Geller, and this is like a concrete patchwork implementation of that density. Okay, so the second to last thing that I want to talk about is how you come up with bounds on the code distance. So to do this, we define a decoding graph for our graph. And this associates a vertex to every face. And then edges correspond to vertices in the original graph. There's an edge between two faces. If there exists a poly at that vertex, that anti-commutes with exactly two faces. And there can be multiple edges per vertex. So for instance, around a degree three vertex, you have this three-click triangle. Around a degree four vertex, you just have this cross, an x. And around degree five, you have a five-click. Around degree six, you have two uncoupled three-clicks, et cetera. And so it also turns out that any poly on the qubits at that vertex can be represented by taking some subset of the edges and multiplying the polys that those edges represent together. Because of what we pointed out previously that you can sort of decompose higher degree vertices into degree three or four vertices using these cyclically anti-commuting list constructions, we'll only consider graphs with degree three or four for the following slide. So here's an example of the decoding graph. Here's some service code patch. I didn't draw the defect lines, but you can see it's not exactly checkerboardable. It's only checkerboardable with some defects, as mentioned earlier. There are four odd-degree vertices marked by the stars. So cycles in the decoding graph represent stabilizers and logical operators of the code. And these cycles are allowed to go through the outer face as well, whose vertex is not drawn. So stabilizers, for instance, are these A, B, and C, represent stabilizers. Cycles in the decoding graph that represent stabilizers. Logical X, I mean, we're arbitrarily calling it X, but logical X is represented by the cycles D and E in the decoding graph. And then logical Z is represented by cycle F in the decoding graph. Okay, so here's an efficient algorithm to get some bounds on the distance, or in some cases it actually gives you the exact distance. So given a graph G, create its decoding graph, and then find a minimum cycle basis of the decoding graph. A minimum cycle basis is, well, a set of cycles that forms a basis for the entire cycle space, such that the total length of the cycles is minimized. And this can be done with Horton's algorithm. He was the first to come up with an efficient polynomial time algorithm, but there are also more efficient alternatives out there. And then third, you convert each of these cycles that you found in the minimum cycle basis to a poly using the correspondence of decoding graph cycles to polys, or edges in the decoding graph to polys. And you can also figure out which of these cycles are non-trivial by seeing if the poly anti-commutes with some other poly from the cycle basis. And those are going to be your non-trivial logical operators. That is, those are not stabilizers. And let W be the length of the shortest non-trivial cycle or non-trivial logical operator. Then theorem says that if the graph is checkerboardable, the distance is exactly this length W. If the graph is not checkerboardable, then W over 2 is a lower bound on the distance and W is an upper bound. Finally, I want to point out that there's a generalized form of Pochner move. Again, we can just think about degree 3 and 4. And then what we really want to do is be able to move around the odd degree vertices, these degree 3 vertices. Because if we can move those around, then we could swap them. And this corresponds to swapping poly logical operators. That is, we've done a logical cliford. So if we can move these odd degree vertices around, then we can do some logical clifords. So here, for instance, we have a degree 4 and a degree 3 vertex. And if we want to swap those degrees, we can do a control z gate on the two qubits here. So the upshot is that a local transformation can take one code to another code that's only distinct locally. Right, so we've reached the end of the talk. So our paper will be out shortly within a few weeks, we hope. And that will have more information about what I talked about here. Yes, so thank you for listening to this talk. If you have any questions in the meantime or even after the paper comes out, you can feel free to reach me at this email address. Thank you.