Plank: The New Best Way to Develop Smart Contracts

Transcript

[music] >> Everyone, thank you for coming to my talk. Yeah, um as Karthik nicely introduced um I'll be talking about Plank, my new smart contract language that I've been working about for the past 8 9 months, the motivation, the design, uh and how I hope to make it uh the new best way to develop smart contracts. Um so, just a little bit of background and about me for context. So, I've been developing smart contracts with Solidity for over 5 years now and auditing on and off for about 4 years. And I've had over this time kind of a love-hate relationship with Solidity. I went from

the beginning when I was learning to first appreciating smart contracts, the power to program finance, the ability to to move around money with with code, um to building more advanced projects, working on protocols that have processed billions in volume and millions of TVL, uh and then all the way to wanting to build even bigger things or more advanced or wanting to push the boundaries of security and starting to feel held back by Solidity as a language when I was a developer. But, I also started to notice when I was auditing different protocols and auditing clients that a lot of the things that I first thought were just DevEx annoyances, things that were bothering me as a developer, also had direct or indirect consequences in the

security and quality of the codebases that I was auditing. I would notice clients were repeatedly doing the same foot guns, um they were repeatedly lacking tests or documentation, and overall it felt like this was uh indirect consequence uh of Solidity, and I realized that it DevEx is more than just uh builder annoyance. It propagates through the entire development life cycle, right? At the beginning, if you have poor DevEx, like maybe your features just take a bit longer, maybe you just have to skimp out on some tests, or maybe you have to scale back the ambition of your protocol's design or architecture.

But, the net result of that is that when you do your first audit, the auditor has to spend more time finding and clearing out the easy bugs. They have to spend time and tell you, "Oh, you missed this, you missed this. You should have written a unit test for this." And that means that either they're going to have to cover less ground or you're going to have to spend time on on more audits or spend more money. And the overall result is that what initially was just something that was bugging your smart contract dev, at the end ends up impacting your entire development life cycle and your entire product development.

So, the core reasons for that or what personally annoyed me as a developer is first and foremost is extensibility, right? As you want to do more and more advanced things with Solidity, such as testing with Foundry is very common now, or you just want to build more complex applications, you want to extend and tune the compiler and language to your needs. But, Solidity doesn't really offer you a lot of options to do that. There's There's no generics, there's no metaprogramming, there's not a lot of these advanced features that maybe you often don't think of, but they are what allow you to build nice libraries and to really scale the size and security of your project.

And that would be okay if at least the the defaults, the things you deal with day-to-day, are in in good shape. But, the reality is that they're not as good as I think they could be. There's security footguns all over in the basic building blocks you use. Um the things you use day-to-day are not very well optimized and leads a lot of developers um to want to push the boundaries and optimize their code, which leads them to reach for inline assembly and these low-level things that are much more error-prone, much less secure, um uh and lead to to real exploits. And then there's other things like error handling, like for example, try-catch uh doesn't actually catch all errors. Um And the last thing is like all of this

would be fine if at least, you know, Solidity was the new hot thing. It's moving quickly, it's fixing things. But the reality is that that doesn't seem to be happening either. The last major update of Solidity was 0.8.0 in December 2020. And I don't want to make it sound like nothing has happened since. They've made minor incremental updates and like in 2022, for example, they released like custom types and operator overloading. But a lot of the core problems we've been complaining about for years have not meaningfully changed. I guess 2026 and I can't get proper auto complete working in my editor for Solidity, right? So, I feel like something can be better. Um, and all of this I think this hack is a is a nice example because while it's small in the great scheme of

things, this is one where the link between Solidity's flaws and um, the real-life result is very direct. So, in this hack, what the developer did is because they wanted to optimize their smart contract instead of using the built-in Solidity decoder and encoder, they they tried to write their own within line assembly to try and squeeze out more gas to make uh, the fees lower for their users. And as a result, uh, that resulted in them making a mistake and having a vulnerability. So, but why is it really like this? I think um, I think it's not for lack of trying like the Solidity team has had a lot of resources and has done a lot in the past few years. But why has it still remained like this? And my thesis is is that

Solidity tries to do too much and ends up doing too little as a result or ends up making themselves the bottleneck. So, if you think about Solidity, like what is Solidity? What does the compiler do? What does the language do? It it comprises of a mix of basic general purpose programming things like uh, variables types loops functions and then like the smart contract like higher level things like dealing with storage, dealing with ABI encoding and decoding, events, inheritance, all of this lovely stuff that uh, developers like.

But the problem is that all of these things are implemented in the compiler and language itself. And if you look at how more modern languages like Rust or Zig or Python do a lot of these things, they're not baked into the fundamental language itself. You can the the core language, if you strip away all the like all the Solidity code in this example, all the Python or Rust code, is actually very a very small, a very simple language. For example, Rust at its core doesn't have hash maps, right? The hash maps are implemented using Rust code in the standard library. But in Solidity, all of these things are baked in. And that means that anytime you want to build tooling, uh anytime you want to build static analyzers, editor

integrations, all of that, you need to cover all of these edge cases, all of these fundamental built-ins. Um and that causes things to be quite quite slow. Or when you want to add a feature now, because the language doesn't have a lot of these extra things, you need to again add it as a core language thing. And this means that if we think about who can improve the ecosystem, who can contribute to the stack, we have a big part of the stack that is only accessible to 5% of or maybe that's even too large of a number, like 5% of ecosystem participants, the tooling devs, the compiler engineers, and then everything else, like the applications and third-party libraries, is not accessible to anybody who can write

Solidity essentially. So, from all of this, it's clear that if we want to do things better, we need to shrink the core. So, with Plank, we shrink the core and as a result, if we want to build tooling, static analysis, all of that, it's easier. But there's still the missing piece, right? All these features that I circled before, like all the ones in black, we still want them in our new language, right? So, if we make um the core language simpler, that's not free. So, the way we fill that gap is with a standard library. And And this is how every other language does it. So, it's not some some big revelation, but I think it's it's new in its application to smart contracts.

And the result of this is that now much more of the stack can effectively be contributed to um by your average smart contract dev. Like to extend and build on Plank, you don't need to be a compiler engineer. You just have to know Plank and you can work on the most fundamental primitive parts of the compiler uh or the language stack and uh extend it. So concretely this sounds all great, but concretely what have we done today? The Um so I have. So, as a result in the standard Wait, this is Okay. Yeah, so as a result, the standard library can have everything that um Solidity offers you, but a lot more. So, if any of you have

developed Solidity um or work with smart contracts in the front end, you might have heard of EIP-712. But it's basically how you sign your intents and how the encoding works. Well, the smart contract developer, every time they want to define a new order or message type for the standard, they have to completely rewrite it from scratch. There's no reusable built-in, and you can't easily add it to Solidity uh because the core features are just missing. While in Plank, because we are able to just in the standard library implement, for example, something like ABI encode, it also lets you um implement something like uh EIP-712.

So, the result is that um in the past 8 months, we have been able to build a working compiler that end-to-end takes in Plank, produces Real EVM bytecode that compiles more than 40 times faster than Solidity. And this is this is still a bit of a conservative number in the sense that um we're comparing like a somewhat optimizing Plank compilation to completely unoptimized uh debug Solidity compilation. So, this number is likely even higher. And then in terms of actual gas and automatic optimizations, uh, we're also making headway on that. So, we're not quite at par or below Solidity yet, uh, but very close. There's still a lot of low-hanging fruit and in a lot of the benchmarks we're

only at 1% overhead. And in the past 2-3 months alone, thanks to this accessibility, it's also starting to play out. We've had 11 independent contributors to a project that maybe a lot of you haven't heard yet. Um, and so I feel like our our thesis of making the core language, uh, extensible and accessible, uh, is starting to really pay off. Um, so yeah, uh, what's next? In the next few weeks we're going to release version 0.2, which is finally going to bring a lot of these things together and actually let you and your team use it.

Um, we're also working on a next-gen stack scheduler. So, concretely what this means is that the code generation of the compiler will get even better. Um, and you will have to optimize yourself and write low-level code less because the compiler will do more for you automatically, which means you can write more secure code, which means also your agents can write more readable code that's easier to review. Um, and then finally, we started working on and will continue working on fully formally verifying our compiler. So, the reason we can do this in the first place is one because our core language is smaller, but the reason also why I think this is so important is that it will let us really leverage, um, agents in the development of the compiler, but also

let you, uh, formally verify, um, your own contracts easily by building on top of the verified compiler, as well as letting us iterate on things like optimizations, um, uh, more quickly. Um, so yeah, that's it. Uh, thanks for coming. Uh, if you'd like to contact me directly, uh, there are my socials. And if you want to learn more about Plank, uh, how you can use it and, uh, stay up to date for the next uh release. Uh you can scan the QR code or go to our website. Thank you so much.