 Semantics-based compilation is the process of taking a programming language semantics and generating a compiler from it. What does that mean? So you take the semantics and a program in that language for it to have the semantics. And now the tool, the SBC tool, generates a new semantics which is a synthesis of the original semantics for the particular program. It's like instantiating the semantics of the, let's say, Psi, take the C language, right? You have a Psi program, a C semantics, and a C program, and now you generate another semantics which is very specialized for that particular program. It summarizes the semantics of blocks, let's say, in the C program, or the semantics of while loops, conditional statements, into new constructs with new semantics. And you'll have a semantics which is much simpler and therefore much faster to execute and to reason about. But the drawback of this is that it is specialized for your program. It doesn't work with any other program except with your program. This is a mini-sense to what people in the functional program community call partial evaluation. When you take a function, it has several arguments, and some of the arguments are known, then you can partially evaluate the function to inline the effects of those arguments that are known. Something similar, but one level higher. You do it with formal semantics of languages. So you have the semantics, and now the input is the program, and you now specialize the semantics for that particular program, and you get another semantics. And now you have another semantics in K, and you can use your backends, in particular, your yele back end, and this way you get a yele binary for a particular program generated completely automatically based on the semantics of the programming language that you want to compile to yele. For example, if your program is in Solidity, what we do, we take the Solidity semantics, we plug it into the SBC tool, and now we take a Solidity program, and what you get out of the SBC tool is, first, another case semantics, if you care about that, and you do care about that for other purposes, like verification, and then from that you get a yele binary that you can execute on various clients, in particular, on the client that is completely generated automatically from the yele semantics. So that's what SBC is, in short, it's a tool that takes one of the tools in the K suite that takes semantics, and the program generates another semantics, which then generates a binary in yele based on the yele back end of K. And that works for any language now for which you have a formal semantics. So that's the idea of SBC, to be able to write smart contracts in any programming language for which you have a formal semantics. The vision here is that you can put a programming language semantics on the blockchain, and then you can write programs in that programming language by simply referring to that language, and SBC will grab the language from the account, and it will generate then the binary, the yele binary, which is then put into the smart contract that now you want to execute. So the alternative to SBC would be to write the compilers by hand for your language. And we know that, we know how to do that, that's what the programming language community has been doing for many, many generations. The problem with that is, as we know, the compilers have bugs, and these bugs in compilers are very, very problematic, because you, as a developer, write a program and you think the program does something, and then you compile it, you get the binary, and that binary does something else. For example, you may reorder the operations in your program. You may have A minus C plus B, and you think that you wrote it in that smart way to avoid an overflow, and then the compiler may reverse, you may reorder the instructions to A plus B minus C, and you have an overflow on A plus B, and your program is suddenly wrong, but if you look at the original program, the original program was just fine in your mind as a programmer, but the compiler introduced the error. So that's one thing. Then also languages, we tend to think that Java is a programming language, and that's it, but actually there are lots of Java programming languages. There is Java 1.4, Java 5, 6, 7, 9, and so on, and Solidity actually changes every week, almost. So who keeps updating all this, and who makes sure that there are no errors generated? So the advantage of the SBC approach is that you have a formal semantics of your language or version of your language, and then you get a correct by construction compiler for your language at the push of a button. So that saves all the hard work needed to implement compilers, and this is a major step ahead. SBC gives us the peace of mind that programs are compiled correctly. Also it gives us the possibility to experiment with language design. As we know in the blockchain space, there are lots of different approaches, lots of different languages, based on different approaches to implement smart contracts, each of them thinking that it is safer, more secure, and so on than others. So what SBC does for you here, it saves you from implementing compilers and thus introducing bugs in compilers for all these languages. It could be that actually the blockchain space sees proliferation of languages at a much higher speed than any other field before. So that makes SBC even more important in this space, exactly for this reason. Implementing a correct compiler is not an easy job. Implementing any compiler actually is not an easy job. Very, very few are trained or can implement correct compilers. Generating them automatically from formal specifications will at least speed up the design and hopefully will help us design better languages faster than in the past. So I think the blockchain space in particular is quite suitable as an application of SBC, which is why we wanted to develop SBC for this space. So SBC as a principle, as an approach, has nothing to do with Yale in particular. SBC is very general. It takes a language semantics in K, it's all about K actually. It takes a language semantics in K, it takes a programming K, and it gives you another language semantics in K. Which means that you can now generate interpreters for the language, for which you have a semantics in K, in any language for which you have a back-end to K. In particular, we have a back-end, a Yale back-end for K, which means that we can do SBC for Yale. And since we also generated the entire Yale virtual machine from the formal specification of Yale using the LLVM back-end of K, now we can take the SBC generated Yale programs and run them on the automatically generated Yale virtual machine. So you have Yale at two different levels here, both of them related. And through this connection, we can now write smart contracts in any programming language and have a correct by construction compiler to Yale. That is the connection. There is no difference really for developers. For developers, SBC will be like any other compiler. They will just have their programming in Solidity or Plutus, and then they will compile. They will call the compile command, like I sold C, for example, for Solidity, and compile to Yale. Everything happens under the hood. Right, so a few months back, we only had SBC working for some toy languages. And the reason was because we didn't have the actual semantics of languages like Solidity and Plutus, we were working on the semantics of these languages. Now we have the semantics of these languages, both Plutus and Solidity. And the SBC framework itself has been significantly improved, and now we can literally have SBC for Solidity and Plutus. I believe that SBC can completely change the way we implement programming languages, overall, not only on the blockchain, because it eliminates the need to implement ad hoc compilers and optimizations in compilers. All this can be done generically in a framework and then reused across all the different languages and then people, everything will be open source and in the public domain. And enthusiasts can contribute to SBC, can contribute to optimizations with ideas. And this way, the SBC tool will become more and more powerful to generate more and more optimal code, and that will benefit all programming languages at the same time. What happens now is that people implement ad hoc compilers for each programming language and they redo the same work over and over again in different settings, which in my view is at best uneconomical and a waste of talent. I believe that we should implement all these optimizations into one place, into an SBC-like tool, and then apply it across all the languages. Just take the languages you put, plug and play your language and get the best compiler for your language, which is also correct by construction. So regarding the future of SBC, to be very successful, we have to overcome two major problems. One is performance. The current performance is acceptable, but in order to compete with handcrafted compilers, we have to improve the performance more. And another area of work needed is automation. We still have to annotate the semantics of various places, telling it where SBC should do its magic. All those places can be in principle detected automatically in the specification, but right now we have to annotate by hand. So it's not as easy as just taking a specification and plugging it into the SBC and you get a compiler. You still have to do a bit of work. You have to spend like a morning or so for a language, trying to adjust the semantics to work with the SBC. So I hope that soon, a matter of months, we'll get to a point where we can literally take a semantics and automatically generate the SBC from it. And when that happens, I think SBC will have a great future because it can literally mean that compilers, as we know them today, are not needed anymore. Could be the beginning of the end of compilers, as we know them.