Ovidiu Damian - Infinite Languages, One Chain: Expanding Ethereum’s Developer Horizons

Okay. Okay. Now we are live. Come back soon here in the sunny days of Napoli. Here the second day of of our beautiful Napoli.

Uh so back in the days and be serious today guys. Uh today we have another speech super interesting with um a de a developer. We can say that. Okay. And uh you say that Ethereum doesn't need more solidity devs.

It needs all devs. That's right. So this is the these are the world of of video damian and uh come on the stage and talk about the P squ and why why why this quest why this uh question.

So

so as people will see during my presentation we started with

okay cool. So it's it's we we went with wanting to bring multiple programming languages on Ethereum specifically because there's actually if you look on the data there's so few solidity developers actually in the world. It's a programming language that is currently used solely for making EVM smart contracts. Basically, if you do not care about blockchain and at some point start caring about blockchain, it's simply something that will stop you from getting quicker into developing anything that's smart contracts just because the programming language is not used for anything else. And we thought that instead of having multiple users learn Solidity, we can do something using our expertise in order to enable developers that don't know and don't care about Solidity to develop on Ethereum and other EVM chains.

So let's get into it. So one of the main reasons for which we wanted for which we wanted to solve this is because this brings basically the fact that EVM is so centered around uh solidity is creating lots of fragmentation. This fragmentation can can be represented in many ways. First of all we have fragmentation of developers. As I've said before, there's many developers that don't know Solidity.

It's hard to learn it initially and they know other programming language and would rather just code in that programming language. And we all know that developers can be a little stubborn sometimes. So yeah, second of all, we have fragmentation between EVM and chains that are not EVM. For example, if I'm a good Solana developer, that doesn't make me a good DVM developer because it's a completely different paradigm. It's a completely different programming language.

Rust is very different from solidity and so on. Moreover, another another uh ecosystem that's very different. If I'm a good SUI developer, I have to learn move. I have to basically then if I want to get into Ethereum, I have to learn solidity and so on. It's basically so many hurdles if I want to just be a web free developer.

Not it shouldn't be so complicated to say. So moreover this having this type of fragmentation of builders and developers creates fragmentation of liquidity. People are developing on different ecosystems uh and it makes it hard to have all the crypto liquidity accessible for everybody which would be would would bring obvious great benefits. So our solution to web free fragmentation is verifiability. And what I mean by this, we as a company have lots of experts that are basically amazing when it comes to formal semantics.

Formal semantics is the science of creating creating programming languages and defining them in a mathematical way to say so. And because we are good and passionate with blockchains and formal semantics, we thought we we would make them kiss in the sense that we could bring formal semantics to blockchain and do something that do something with onchain formal semantics which is the way in which we are going to help with this because and here comes verifiability. If you if you are able to mathematically define a programming language, you are able to generate mathematical proofs that some code results in something specific which can also be done for onchain code. Now the solution we are proposing is first of all universal in terms of programming languages and program execution. Basically, whenever you start learning a blockchain, you wouldn't need to learn a specific programming language.

You could code on any chain using any programming language as long as it's adopting our tech in any way. Second of all, it's universal in proof mechanisms in the sense that we have tested whether our mathematical proofs generated whether our mathematical proofs that are generated uh with formal semantics are checkable easily with mainstream uh with mainstream ZK circuits and they are basically we've tested everything there is on the market and it's mainstream for ZK and it worked uh and It's universal in the sense of distributed consensus security guarantees or in not so complicated language it's very much compatible with blockchains in the sense that it's not hard to get to a validator consensus regard uh regarding the fact that it's secure. Now in order to do that we have three products to say so. First of all the verifiable language machine which allows which allows one to write smart contracts in any language. It even allows people to basically define new programming languages and use those.

Currently, we have a demo which I'll show at the end of my presentation which allows you to uh on the same blockchain. It allows you to write smart contracts in solidity, EVM, WASM and Rust. Why? Why did I put Solidity and EVM and WASM and Rust in different as different languages? because we support running solidity directly without compiling it to EVM and raster directly without compiling it to WASM just to show that it's possible to execute highlevel programming languages as well as low-level programming languages.

We have the verifiable settlement layer which allows you to generate proofs of execution and settle them on a common layer across ecosystems basically basically on our you could run your own programming language or smart contract in your own language on our VLM and then send proof of execution to Ethereum let's say or Solana or anything like that to have mathematical proof onchain that that code has been executed has resulted in something specific. For example, let's say I want to execute 2 plus 2 is four on in Python that's not possible in EVM, but it's possible on our VLM. You execute it and using VSSL you can check that that code has actually that 2 plus2 is actually for in Python and have that proof onchain on any on any uh on any uh blockchain and check it with any ZKVM using our VSSL and the verifiable consensus protocol is what keeps the the VLM and VSSL decentralized. We can't censor it. We can't uh we can make huge changes to it.

we can basically say no this is uh this is code that can't be executed anymore or anything like that because we have validators and the specific consensus protocol like other chains which keeps which basically keeps security in check. So for the VLM uh basically this would help bring in in an ideal world this would help bring 38 million developers to uh to the current web free ecosystem because people that know Python, TypeScript, Java or even that know how to write code by doing VIP coding via AI prompts can now basically come to web free. Um, the VSSL would basically help over 100K web free apps in uh that are in existence today to uh basically settle their own onchain claims quickly and securely and the the uh the VCP in this case would help process billions of transactions concurrently. Now let's let's explain a bit better what what's the market for us in the sense of in the sense of uh bringing more developers. So according so according to a study made in July 2024 by electric capital uh there's only 8.

8k active solidity developers in the world which is wild. That's wild. It's wild when you understand that it's so few of us. And let's if we go a bit further, we understand there's just 26k web 3 developers in the world that are active. Of course, if you have coded one smart contract in your whole life, that doesn't make you a full-fledged developer, but just 26k developers.

This is why maybe if you ever tried building your own project, you saw that uh developers are so expensive in web 3. So basically by using our tech you get access to 26 more million developers by just enabling C, Python and Rust. You get you can get access to even more web two developers by by basically supporting other mainstream programming languages like TypeScript, Java and so JavaScript uh and so on. And in 2030 when we will have prompt engineers as a as a more clear pathway for developing you will also be able to have access to even more developers by simply basically allowing prompt engineers to write and settle code on chain. Now to go for to go further on this instead people generally don't think about verifiability until it's too late.

Instead of asking okay why should my code be verifiable we want to change this paradigm into why not yet. So there are obvious reasons for which your code should be verifiable and that first one of the first reasons is to prove that the code executed is actually what people believe it is. So onchain it's relevant if I have gotten to my end result by executing 2 plus 2. Sure I got the result four but I can get to the result four by executing 3+ 1. If my code is ver verifiable and if execution in general gets verifiable, we can keep in check and we can check validators and compilers and so on and make sure that they function as needed.

Uh one cute story regarding this is uh the fact that someone from our company at some point using formal semantics helped audit the GCC compiler. Some of you some of you might know the GCC compiler. It's basically the most widely used C++ compiler and it's like huge in the sense that that compiler is basically how should I say it that compiler is one of the most well-maintained and complex open-source projects there is. And after they created the formal semantics of that in order to test the compiler, they have run all the tests to test that compiler. And using those formal semantic semantics, they have actually found some bugs in the compiler.

Obviously, in the meanwhile, they have also found some of their little mistakes. Okay, maybe the we didn't understand the C++ programming language as well as we thought and they found one of their own mistakes. But the point is just by defining C++ as a mathematical model and running the usual tests of a compiler against those tests you we were able to find bugs in one of the most wellrespected compilers on the planet. Now let's explain how exactly this helps not just developers themselves but also infrastructure providers. So whenever you want to add a language to your chain.

So let's say that tomorrow uh Vitalik decides okay from now on Ethereum uh will will try to support Rust as well besides solidity. They will have to have a code interpreter. They will have to create a co a compiler that compiles that to was some other or some other uh or even to EVM or anything like that. They will need a symbolic executor, a model checkle, a program verifier. That's huge work for everyone for anyone that wants to offer code execution in a secure way.

That's a lot of work and it has to be repeated from zero for each programming language. This is why most blockchains only support execution of only one programming language. And this is where we come in. Instead of having to build these tools for all of these languages, we use a a framework called K, which is a framework that was initially developed by our CEO while he was working at NASA, but in the meanwhile, he started his own company, which is Pi Squared. And this framework K basically is the framework that allows you to easily define your own programming languages in a mathematical way.

And based on that, so based on your definition, so you only write one mathematical definition and using that mathematical definition, you can then automatically generate an interpreter, a compiler, an executor, a checker, a verifier for that programming language. So you write one thing and then generate everything based on that. It's it's way more automatic. It's way more secure. It helps find bugs even in well-known open-source language projects and so on.

So let's see uh an example. This is how a simple programming language looks like when defined in the K framework. So if this looks complicated to you, I promise that it's not. And um you don't. So you have to somehow trust me.

But to explain this, uh just so you know, this is basically the first rule, the first lesson that uh students are are taught at at the university when learning K. basically where our CEO is a professor in uh in uh in uh Illinois Champagne nearby Chicago whenever he has the first lab with his students this is the first thing they learn so after two hours of learning K they can write this themselves understand it and run code themselves using a madeup programming language called simple sure you can't expect that language to after two hours of student work to have the same capabilities and speed of C++ or Rust But the point is they can create their own programming language they can add it on chain and once that is done after just one lab that can generate interpreters compilers and so on. Now how does this actually bring programming languages on Ethereum or on another chains? So in an ideal world we would sit Vitalik down or we would seek someone we would sit someone else from other chains down and say hey why don't you change all your validators so instead of executing code directly they use formal semantics to execute their code in that ideal world he would say yeah that sounds cool and do it but that's not realistic that won't realistically happen anytime soon because uh validators want to keep it safe and so on. So the more realistic way of doing it is by us having let's say our own chain think of it like a layer zero or a layer 2 or however you want to call it which does work based on formal semantics.

Whenever you want to run some Python code or some Rust code or anything as I said you want to write uh 2 plus 2 is four, you run it on our chain and after you run it on our chain, you also get a mathematical proof that that code has been executed and it has gotten to that result four. Now because uh mathematical proofs are generally huge are generally huge in terms of blockchain storage like uh a mathematical proof can occupy a few megabytes of data which is a lot for blockchain. What we do is we then take that mathematical proof and put it into a uh put it into a ZK proof so that you can easily store it on chain and then obviously with a data availability layer and with ZKVM check it quickly on other chains to make the result available. You basically can come on Ethereum ask hey I want to execute 2 plus 2 is four in Python. We listen to that.

We execute the code and you get the result back on Ethereum. Let's see how the workflow is exactly. So basically uh you define your own programming language. You define your own programming language. Then based on that you can generate an interpreter and that interpreter can run the program of of course it has an execution environment and runs the program has those hints uh those proof hints is able to generate the proof and based on the math proof it can then get to become a zk proof.

Now as let me check how much time do I have. Okay, I think we're good with time. So what I want to do now because uh what I want to do now because I've talked a lot theoretically I want to show you a quick video and I will explain while it's going with how that actually works and let's get to it. So basically we have the bring your own language demo which is a chain a chain which have modified to support multiple programming languages. It's an EVM compatible chain.

We have basically modified uh uh uh the we have modified the execution engine of uh ref rust ethereum and we have made it so you have a lang a language registry. Basically, this shows all the programming languages that are supported on our chain. Initially, because the chain was just spawned in the video, we only see EVM supported. Each chain has their own ID, pretty much like an address for smart contracts. And that ID is a unique identifier that is then used by nodes to identify those languages.

And obviously each language will have their own hash which which is basically something that can be used to check uh to check the to check that the code expected to be used is actually correct there. Now here I was showing basically the I was showing basically the hash and we can also check we can also check the contents of the contents of uh said code which I'm doing here. Basically this is a def a mathematical definition of Ethereum. It's very long. I'm not going I'm not going to go through all of it in the video.

But basically using this you can run Ethereum code which we actually do in the video and you'll see So as we get back here, we go to the next next uh tab and we try to add a new programming language. Okay. So I'm I'm choosing from my list of already made languages that I've prepared for the demo and I'm adding solidity directly. I can you can see the definition of the language I'm adding and you can see you can see I'm I'm signing a transaction and I'm simply adding the new language transaction completed successfully. There we go.

Now Solidity is also available onchain to run directly. So no compiling to EVM running Solidity directly. Now I take the I take the ID and put it there because I want to deploy a contract and I need to tell the node hey the contract I'm trying to deploy is in this programming language so that the node knows how to run that code and I'm adding the contract as you can see it's a typical USDC USDC contract in solidity typically RC20 you can see meta mask is even detected that this is a contract deployment and it's nothing special. Basically, it feels like classicalally VM. It's just that you can use lots of programming languages on it.

Okay, we have the address of the contract I deployed. I'm copying it and we can now go and interact with said contract. Okay, I'm I'm going to input the ABI offset contract to interact easily with of course. And there we go. I'll choose USDC.

And now I can load a contract. You can see name is detected, symbol is detected. I'm going to copy my address and check my balance. Obviously zero. The contract was just deployed.

So my balance is zero. I'll mint some tokens and a simple transaction request. Nothing too special and it it's okay for it to not feel special. Using multiple programming languages should give the same seamless experience as using general Ethereum. We have a transaction received as usual like in like in Ethereum and we have just executed code and I have minted tokens.

Now I can check my balance again. And there it is. I have my tokens. Now what we're going to do during the demo is also check this in explorer. You can see that our our uh fork of of the explorer also sees and understands that this code is written in solidity.

And basically basically you can see that I have some transactions uh that are in solidity. And this is where the magic comes in. The first few bytes that you see there are the only thing that's different from classical EVM because the first four bytes in in each contract is actually the language ID. So the validator basically looks at the first four by knows okay this is this programming language that I have to run let me run this code in a programming language of the ID you provided now I'm going to add a new language I'm going to add Rust we add it real Click and this transaction was completed. It's available on chain and I can deploy a contract in Rust of course.

You can see that's actual Rust code. And there we go. We have wrapped Bitcoin implemented in Rust and so on. It's basically kind of a ERC20 uh copy of a contract but written in Rust. I'm going to allow myself to spend my own tokens to basically show that just to show that it's working.

MetaMask even detect it as a spending cap request because it because me as a caller of a contract, I don't care in what language you've written your contract. As long as it returns what it should, that's all good. Got my got my token allowance. I can also show on chain that this is a Rust contract. It's viewable on chain.

It's working all good. I I can also see the first four buys for the Rust token ID for the Rust language ID. You can see 7275 7374 which is the ID of Rust. And before going further, I've I'm also deploying an EVM contract to show that classical EVM also works. We're on an EVM compatible chain that as you can see that's EVM byte code.

And there we go. Transaction will be completed soon. We copy my addresses. Uh again, I'm checking my balance again. All works well.

I'm going to deposit some Ethereum to get some to get back some wrapped Ethereum because that's the contract I've I've deployed. And as as you know, if you want wrapped Ethereum, you have to deposit Ethereum. All good. We have the transaction receipt. Everything works well.

Everything is nice. Okay. You can see the contract now has 0.1 Ethereum balance because I've sent it some. My balance has been depleted.

And you can also see it knows it's an EVM contract and it has a balance of 0.1 if because I've sent it some if. And you can see that basically is detected as a token transfer here. And now what I what we can also show is the fact that was can also be added on chain. Basically, you can execute Rust or WASOM directly, but we're going to go a bit faster through this to save time because it's similar to the other programming language.

So, we have WAM, we're deploying a Doge contract in WAM, which is again bite code. Okay, done. We interact with it real quick. again. Copying my address, checking my balance, minting some tokens.

And as this is done, I should be able to check my balance. Okay, done. Balance is there. All works well. No fuss.

You can see it's a wasome contract. is token name is detected as being dogecoin. All good. Okay. And the last language we're showing that we're supporting for the demo is the programming language called simple which you have seen before in the presentation.

It's that programming language that usually students are coding after one lab. That's to also show that you can invent your own programming language and come with them. It doesn't have to be something mainstream. It can be whatever you want. So we have the simple programming language.

That's literally the name. Okay. We have added it real quick. And we can again go through the same flow of deploying. And let's say we're deploying the pi squared token in simple contract is deployed is deployed real quick.

Once that's done, we're going to mean some balance and all will be well. There we go. Minting. Minting 9.886 886 tokens which is pi squar.

Okay, result is there. We have 9.86 pi square tokens and it's also detected as the programming language being simple. We also have the bites there. All's fine.

So this has been the bring your own language demo and before we end I've got one more short demo to show how everything works. So we have shown different programming languages working on the same chain. Now what I want to show is oh now what I want to show is multiple programming language interact languages interacting with each other like we can have a DEX in which one token is written in Rust and another in solidity and it will work seamlessly. The tokens themselves don't know they are written in different programming languages. They just are they can communicate seamlessly without any issue.

We have multiple tokens. We have a router contract which is written in EVM. We can see again the bytes. Then we have the pi square token written in simple. We have the rep Bitcoin in Rust.

We have a D token written in EVM USDC in Solidity and Dogecoin in WASAM. And if I try to do a swap, let's say I'm swapping 986 USDC into Doge. I'm doing a swap real quick. Of course, first they have to allow the spending of the tokens. As it gets confirmed, I will be able to actually do the swap.

We wait a bit for the transaction to go through. And now I also get a transaction request which I'm confirming. And the transaction was executed. You can see the balances have changed. And yeah, that's pretty much as simple as it gets.

You can simply have multiple you can simply have multiple programming languages interacting with each other. You can basically see I have interacted with an EVM contract which called a a solidity contract that interacted further and done a swap with a wasam contract. So yeah, that's basically as easy as it gets to have multiple programming languages working together on the same chain in a in a decentralized exchange in this example. So now as I've shown you all this and we're getting to the end, um feel free to follow us on X to stay up to date with everything we're developing. And you can also go to our developer portal to uh try out to try out what I've just shown you for yourselves.

We just had a we just had a month of DevNet that has ended recently in which we've collected feedback for our products from users and we'll closely get to a test net. Now before I end, do I also have time for Q&A? Yeah.

Yeah.

Well, well, no, it's it's a transaction on our DevNet. The prices are not necessarily real. It's it's basically we have just named the tokens to have relevant names but we didn't we didn't actually go on them and say okay let's track the real prices. The point was to show that multiple programming languages can work together but in real life if we launch it in this basically I think one hour later after we launch it we' probably have uh arbitrage boss that would keep our price like in reality. So

if that's all Thank you everybody. Thank you everyone.