Arbitrum Stylus with Rust: Are we EVM yet?

Transcript

Hey. Hey. Uh so like uh today I'll be talking about stylus and uh stylus evm. So like and uh smart contract. So uh I think I'll touch in brief uh what stylus is. So like it's the way to run uh smart contracts that uh have a target for web assembly. So on any web assembly compatible language uh you can write smart contract that will be able to call uh any solidity contract. So it has full interperability. Um and uh let's let's start with major changes that happened in the ecosystem for the whole year of development.

So uh I'll touch here uh differences of stylus and uh solidity. So uh as you see uh the major difference is constructors. So it's very different to construct uh contract on stylus uh inheritance is different uh your so like because the main language for uh stylus AVM is rust because it has uh uh it it actually works quite uh well with uh web assembly. And uh the other things that uh are quite different but not much are context functions. So like if you wanted to make external calls, it's also uh kind of similar but different. And I also touched some interesting quirks. So

uh yeah, let's get started. Um so it actually how it was before if you wanted to instantiate your contract uh you had a few ways. So like first parameterize your uh contract with generics. So it's common approach in rust but it actually uh the argument will be determined in compile time. So and sometimes you want to do some logic when you instantiate your contract. So and the other solution was to use functions initializers uh as it was before. So it wasn't any constructor special function and uh we open zolin created a solution that was called uh coba where you it was possible to write uh constructors on solidity. So

it actually was pure disaster because uh code base of solidity and rust being coexisting. So and it kind of ruins whole point uh of using rust for smart contract. So like uh if you uh remember the first question of the presentation is uh are we on EVM? So it kind of really know with that kind of approach and I happy that we deprecated it. So uh and these changes uh happened quite recently. So that is how constructors works at the moment. So uh you just need to decorate constructor with constructor macro and it actually not a major difference from solidity. So uh this change was introduced uh by of chain lab

so quite recently and that is how it works. So yeah and here you can write like any kind of logic. So it's example of C71 token uh with consecutive extension. So let's go forward. So inheritance in Rust there is no inheritance. So uh it's mostly term from object-oriented uh programming languages but Rust it's not like that. So it's like all uh inheritance is decomposed in Rust. So uh there are generics there are traits uh but yet there is no virtual functions you cannot override functions.

So and uh at stylus uh to address this issue ex they added uh inherit uh keyword. So you just write inherit and all functions from inheriting uh contract are reexported and uh the problem was that it wasn't working on level of three. So uh it was quite useless. This is example and it's shown like where it uh compiler won't let it uh to be compiled. So uh of course uh trying to solve this solution developers could uh start uh creating some uh different approaches and here it's where it will be totally wrong. This example will be compiled but as you see the

third level contract is duplicated. So it's like just think that you have like two tokens uh inside one contract and you change balance in one and in the other you just read and it update wasn't perceived. So uh that was totally wrong approach and that is how it was before uh and the only solution was just uh use inherit keyword on client side. So only uh developers will use it. So it will be it was useless on uh library side because level of three was not supported. Um and how it is implemented now. So they added implement keyword. So and actually uh there is no like inheritance uh concept at all. Uh you

just implement some trait uh and you should link it to your contract. So and you can add some functions like constructor like uh function for minting uh in case of NFT token. So uh but yeah consumer is responsible uh for publishing API and uh that is what they should do. So just uh decorate with public and implement all those trades for RC71 or if they want to add some extension uh implement it for burnable. So uh this is more verbose uh but actually uh more clear for developers.

So with errors kind of no major changes uh you can use uh just set of bytes as a errors or vector of bytes or you can create typed errors that is more preferable. But if you just want to set up your uh contract quickly so just use the first option. Yeah. uh context function like for this year changed but not much. Uh stylus SDK team added VM uh VM API and where you can conveniently uh choose what function you need like uh you want to read contract address or uh message value that was sent with transaction. So uh it got more convenient but uh the previous API still available but will be dep uh is will be

deprecated soon. uh external call also has no major changes. So that is how it looks. Uh you can use also VM API for it. But yeah uh by the end you should just in uh write some solidity uh contract and then that macros uh generate uh the function and you just call it uh and then we come to the interesting quirk that wasn't addressed at all. So it's actually uh the difference of rust and solidity that in solidity function name uh so like it can exist two functions with the same name but different set of arguments in rust it's impossible and uh since we are building uh compatible contracts

compatible with solidity so uh we should assume that we could have like uh some functions with the same name and the that is the only solution and the bad thing that uh now nowadays this user who publishing the interface should also remember that uh that name uh should be different so like uh write it each time. So I I think that problem will be fixed in future and I hope so. Um yeah here I'll touch few topics about uh library development. So actually like it was before it's preferable uh to design your uh error types for your uh contract and uh yeah and have like like uh they rely

more on type system that trust you provide you. So um for inheritance so for inheritance uh trade based approach is preferable. So library should have uh some set of traits that uh it's it's expected from user that they uh export it and also some lo core logic implementation. So just for example 20 trait and uh burnable extension. So that is what we expect from user to publish and what user should do just uh implement them and uh forward to uh exact type uh from library

and the last thing that actually necessary for library is just to validate that uh code works correctly. So it's uh end to end testing uh and testing overall. So no major changes here. you can use like whether a RS or alloy provider and write your uh test cases. That is example how it can look like uh in our library. And of course there are some drawbacks for end to end testing. So uh for example they cannot pass fast. So, and of course like unit tests are much more preferable. And if you want to run the same test case multiple times with uh randomly generated arguments to like

hoping to find some uh mistake like uh prop testing or fuzzing also is not possible and uh for end to end test you have infrastructural dependencies. So you should first deploy nitro test node and uh wait for it. So uh but yeah uh the downside of unit testing that it's not compatible uh with solidity. So uh it you only can check interperability in end to end testing. So but yeah here is the example of uh how slow can be end to end test. So like we have 300 test cases or I think a bit more and it already takes uh 21 minute to pass. So uh maybe if we'll catch cargo styles it will be like 3 minutes

faster but anyway it's like it's scaling dis in disastrous way. So uh yeah and the thing that appeared so uh of chain labs developer of stylus SDK they also create a test framework so they call it stylus test uh it's more imperative so you should write uh what should you mock uh so uh which function should you mock so uh of course it can run in parallel uh in yeah it's just recent solution that recently appeared so but at least one test framework exist and the other is developed by open zeppel in mozzu. So uh also my colleague Net published a article recently. So uh like cool guide

about Mozu. So uh yeah it also runs in parallel but compared to stylus test uh you can write test cases in more declarative way. For example uh let's keep it. So here is example of positive and negative test case. So uh and yeah it looks quite simple. So uh it quite understandable what you're doing. So like who is the sender and uh you don't need to hardcode any addresses because addresses are derived from uh names of arguments. So for example uh Alice address derived from Alice string and for both it's same. Uh also you can check for events you can check for

errors. So for example if this contract return to error uh it actually storage will be reverted. So it's like kind of like a micro EVM implementation beneath but yeah it's actually works. Uh also in case of testing two contracts so you don't need to mock you can just create another contract like there is C71 and uh C71 has receiver extension and you you can uh just create receiver contract and when you send NFT to receiver uh it will uh that API will be triggered. So and you can check that it worked. So actually you can use like as many contracts as you need. So it works quite similar uh to what exist

on real onchain environment. So and uh the last point like last advantage of stylus uh why stylus uh actually was created is that it can show some uh benefits in terms of uh performance. So like actually uh it was advertised that it can be cheap. So and here are example of benchmarks. So we actually run benchmarks after each uh pull request get merged. So uh it actually very simple to understand like uh what happened wrong or like which changes introduced increased gas cost.

So uh you see that uh there is a column to uh that cached contract. So it's possible on stylus to cache contract and uh call will be a bit cheaper because uh you don't need to load web assembly so like and spend gas on it. So and also you can uh play with uh web assembly uh with external tools so and optimize it and make it better and uh the worst thing about it that it's actually worse than solidity. So uh all of those results it's not uh 21,000 uh gas fee is not considered here. So you should uh append it if you want to like note the uh price of the coal in total. So yeah it's all of it is a bit worse than

solidity that that's a bad thing and the same thing for airc 7 to1. So mostly it a bit wor sometimes it's same sometimes it works so in the most optimized way and that is the thing about styus that for uh simple scenarios for simple tokens it is not that optimal to use but of course if you don't have a target optimize tokens you can use it for the other applications for example we built uh Poseidon hash that is uh currently a bit solidity uh quite well so and that is the area where style shines. So like when you uh build some uh computationally intensive smart

contracts when you want to pull something like some game on chain like I also heard like some something been trying to pull AI model or yeah like just write some crypto primitives and uh the result can be uh result will can surprise you. And the best thing that in this article I also described uh not just the result or numbers because better not to trust numbers for example it's after recent updates it got a bit worse and yeah like we want go like to change title of article so like from like 18 times more to like 17.5 uh yeah and uh but the good thing is that uh the idea the optimization steps how you can uh

improve your performance of your smart contract are actually quite similar to what you're doing to optimize like your uh software on your like normal computers. So uh loop and rules uh inlining function. So like all of that can bring you results and it's similar to modern CPUs uh division operation is more expensive than multiplication. So uh in solidity uh those up codes uh charges same. So yeah uh that is actually uh the thing where uh it makes sense to use stylus. So u thank you.

All right. Uh we're going to open it up for questions here. We have about 10 minutes uh for questions. So if you just have a question just raise your hand. Uh you mentioned that u styos uh shines uh for use cases that are not the common the common ones and you mentioned the Poseidon harsh implementation. What other uh primitives cryptographic or not uh are in the pipeline? Uh so that can be uh applied to other use cases. Uh it's actually hard to tell. Yeah. like

we are uh thinking about our road map uh but but yeah there are like different projects like renegade labs they're building MPC on chain so uh so like superposition so uh it actually yeah yeah yeah the most obvious yeah it's some uh you know like cryptography like zk friendly hash like Poseidon or Person hash so uh the other things yeah like I don't know like you want to play some like onchain game that also didn't work. So, um but yeah, we haven't tried and it's actually hard to build road map over it especially knowing that we should build some library that people would use like oh people would use like

some game like I I don't know like uh but but yeah tokens are not the best part of styos. All right. Thank you so much. If there's no more questions, I appreciate it. [Applause]