Welcome to Easter. [Music] Perfect. Please welcome our next speaker, Ben Greenberg, who's going to be talking about smart contracts without handcuffs. Thank you very much. Hey everyone, good afternoon.
Uh so what I want to talk to you about is really a dynamic that if you ever developed a smart contract in solidity, you may have experienced something along these lines. You're trying to write some simple function and yet you're stuck in a pattern of so much defensive programming. So many things we need to factor in, care about, be concerned about. Re-entrance is just one of them. But there's just so many issues when it comes to that.
So, what I really want us to spend the next few minutes on is Oh, this is helpful. Hey, I don't have to scream anymore. What I really want to spend the next few minutes on is talking about how to build smart contracts without the constraints that we're so used to allowing you to unlock the full potential in really a developer centered and excellent developer experience sort of way. Now, in 2023, there were somewhere around a 100 million developers that were pushing code out to GitHub. I think in the past couple years, that number has increased.
We're not less, but we're more. So, we're over a 100 million developers on GitHub pushing code of some sort. From simple hello worlds to really advanced stuff. How many of them do you think are working on blockchain applications? What What do you think?
1%. What would that number be? Give me a number. 30,000. That's any number high or lower?
Got a number? Oh, we're going to go with 30,000. You're really close. 24,000 according to the latest lecture capital report. Active web3 developers, meaning people who are regularly contributing code to projects in uh crypto.
So, 100 million developers, 24,000 active web 3 develers. Is that 1%? It's a little less, right? Okay. So, we're dealing in a world where developers, they just want to get stuff done.
They want to ship and be productive and see the results. They don't want to be stuck behind conventions and paradigms that are slowing them down. So, before we get further, my name is Ben and I work at Arbitum. I just started actually last week as a new devil engineer at Arbitum. So hey, this is my first talk as part of arbitrum and you can find me online everywhere at hummus on rails because I'm an old school Ruby on Rails developer from many years ago and that's my favorite food in the world.
So that's how you find me online and uh really excited to be here to talk to you about Wom. Who's heard of Web Assembly? One whoa this is a great audience. You're a web assembly audience. You've heard of Web Assembly.
So we're going to talk about Wom. For those of you who have not heard of Web Assembly, it's a fast and really portable runtime. It allows you to run code in many different languages at basically near native speed. It compile compiles to really small binaries and it can run basically everywhere. That's your two second on one foot introduction to web assembly.
But we're actually in this talk we're not really going to talk about web assembly. We're actually gonna talk about what I think is just a basic fundamental idea. We just want to create a context where builders can build, where they can get stuff done. And I think that means we need to reduce the things that get in the way like fragile tooling, forcing things over ways and forcing conventions over configurations and facing failure when things are not working or just tons of defensive programming patterns. so many issues.
So, we need to get those out of the way and allow developers to be productive. And I think this talk is about web assembly, but it's not about web assembly because what it really is about is how we can get to the place where builders can build using web assembly. And it makes web assembly is great for really two reasons. One is its language agnosticism and the other is its universal runtime. So, let's actually spend a couple minutes talking about both those areas.
When we say it's language agnostic, what we ultimately mean is a developer can pretty much bring their own language that they're used to, their stack they're used to. They can pick it from the vending machine and they can start developing in a blockchain context. That is hugely empowering. One cannot state enough how empowering and what a paradigm shift that ultimately is. You were talking about a context where there's tens and tens of millions of JavaScript and now TypeScript developers.
tens of millions of Python developers, millions and millions of Rust developers, C++ developers, from enterprise devs to startups to devs all over the world. And now they can actually unlock that productivity when they come into the smart contract space. Because ultimately, if you want to bring somebody into the space, if we even want 1% of the 100 million, we want 1% of the 100 million, it it's much more productive to meet that person where they are and teach them from where they are as opposed to trying to get them somewhere else. This is not a new idea. This is an idea that comes from hundreds of years of philosophy.
And we're not in a governance conversation. We're not going to talk about the Roman Empire now, but hundreds of years of philosophy and political science and everything else. Bring people to where bring yourself to where people are and you'll be a lot more productive in the developer context. Where are people? Well, they are in Python.
They are in Typescript. They are in C++. They are in C. They are in Java. Where are they not?
They are not in Solidity. I mean with we do love solidity but they're not in solidity. They are in C++, JavaScript, TypeScript, uh C etc. So this may sound a little provocative. I strongly believe the answer is not another DSL, not a no shame of any chain or project, but the answer is not launching another specific domain language that will solve all the problems.
We don't need another Rust lookalike because we have Rust. We don't need to create something else that is an abstraction but actually is a complexity. Is a simplification but actually is more overhead. We don't need those things. What we really need to do is escape from the trap of the DSL hell.
It really is a DSL hell. And the way that we can escape that is with runtimes that run on web assembly with WS and runtimes where you can bring your own language. Bring your own stack. You don't need to be stuck with learning the peculiarities and the unique quirks of this Rustbased DSL or this TypeScript DSL or or anything else. You can just use your own language, your own stack that you already know so well.
Now, this is my little bit of hitch. Stylus arbitrum stylus is one of those escape patches. It is built as a wasm runtime compatible with EVM and allows you exactly to do that to run smart contract code in the language that you know to write it and deploy it in the language that you know in the stack that you're comfortable with because you get the multivvm world EVM running alongside a WASM runtime. smart contracts write written in Rust, C, C++, compiled down to WASOM are deployed and get all the same benefits, get everything, all the same primitives and run exactly alongside the EVM, not competing with the EVM, but running alongside the EVM. Now, the second pitch of this is that it's not only language agnostic, it's also universal runtime.
This, my friends, I think is actually huge. What it means to be universal runtime is you get one runtime, one codebase for every device at every scale. And this is not just a blockchain thing. WASM nerds all over the world, this is what they're deeply excited about, right? Where did WASM begin?
What was the first use case for Wom? You look like you may know. No, you you look very interested though, so I'm happy to see that. But the first use case for WOM was in the browser, right? The first use case for Wom was in the browser.
the browser being the great equalizer of code. So with universal runtime, what it actually means is you can write one piece of code, compile it down, and you can run it on a mobile device, run it in the browser, run it as a smart contract on a smart contract VM, run it on a edge server, run it on like embedded devices, Raspberry Pies, run it on a backend, run it on AWS, I don't care. You can run it everywhere. the same piece of code same binary format can be running on a laptop on a mobile device on embedded devices. You don't need to recompile and it's automatically now this bit is frustrating for some developers.
It's actually fantastic for blockchain contexts. It is a sandbox bit of your code which what that means is it's built for a deterministic environment. Are blockchains deterministic or not deterministic? What do we prefer? Deterministic code.
We don't like things that we don't know the outputs. This is really frustrating for web two contexts because you lose some of the standard libraries, but we don't want those standard libraries anyways. We we make our cars a little more complicated. But that's the benefit. It's sandbox.
It's as if it was built for a blockchain. Pretty cool. So instead of having the VM lockin, you get the multivvm opportunities of what is ultimately what I'm calling the universal runtime. The runtime lets you run it essentially everywhere at every device, which by the way is also a great equalizer for decentralization. If I have to have a fancy hardware sub to run and be a blockchain node operator, I have to spend $10,000, $20,000, $30,000 to run a node.
Is that a decentralized blockchain? Probably not. If I can run your blockchain as a node operator on my phone, is that decentralized? Can that work around the world? Yes.
That's not the point of this conversation. But just keep in mind that this also is a democratizing factor for helping us achieve greater decentralization in our chains. So with the benefits you get things like using your own testing framework, local debugging, IDE support out of the box and you can compile with all the compilation tools you know. So in the Rust context like cargo build etc. You don't take the developer out of their context.
One of the worst things you can do who writes code here? Some people. Amazing. Okay, great. I also write once in a while.
One of the worst things that you can do is to take yourself out of that context. and put yourself in another context having to learn new mental models, new ways of doing things. It is super frustrating. If I can live inside my own mental model and my own context and my own tooling, I'm going to be 10x more productive than if I have to learn your thing just to get up and running. So, we want people to be able to build contracts.
This sounds kind of elemental, but it's actually not. We want people to be able to build contracts the way that you build software, the way that you write code. You know, in my years of doing Devril and blockchain, you know who are some of the most interested web 2 devs I've ever met in blockchain? Do you think it's JavaScript developers? No.
In my experience, this is anecdotal. Not blockchain develop, not JavaScript developers. You know, some of the most interested Web 2 devs I've met have been enterprise devs who spend most of their days working in like a Java context, a .NET context, and they come to this space because they're curious and looking for something different, something interesting, and they write code in strictly typed very uh similar environments to what a was runtime lets you have. So if we provide that context, we just open the door and make it just that much easier for people to actually walk through because when you're writing in Solidity, well, for somebody who's coming from something like uh C++ or something like uh C or coming from Java, you feel like you're kind of taking a step back in time, like you're going back to the JavaScript days where if you're writing in something like Rust or C++ for that matter, you get all all the benefits, all the utility that you're used to like very default handled automatically for example with strong typing and ownership through the strrus one map for all of user state.
You don't need to do manual checks for defaults which is really a common uh programming pattern in Solidity. You get rid of all of those things and you're just writing code the way you would write code in any other application environment. You don't need to kind of go back 15 years to JavaScript land and have to relearn how to do code in the way that you may have done it when you were in high school writing iframes on a website. So you get back to real software development environment. But I don't want you to take my word for me from from me.
Please do not take my word at it. I really beg you if there's one thing that comes in this context is we shouldn't believe what we say and hear, you should try it out yourself. So this QR code, it's not going to take you to some marketing copy. It's not taking you to anything that I'm tracking UTM links. It is taking you to a five minute quick start.
If you have five minutes today to sit on your laptop, five minutes, a coffee break, you can get and experience what it's like to write a smart contract the way that you may write software. So if you have five minutes, I really encourage you. I'm not tracking this. There's no marketing leads or KPIs from this. Just give yourself a chance to try it out.
write code the way you write software. Thanks guys very much. [Applause] Any questions? I stunned all of you so much. Trying to see if his hands are behind the lights.
Automatic transcript — names and jargon may be misspelled.