Move for Solildity Devs | Rahat Chowdhury - Movement Labs
Ethereum Denver·Thu, Oct 9, 2025, 12:00 AM
In this session, we'll introduce Solidity developers to the Move programming language and the Move Virtual Machine. We'll explore the benefits of building on Move, such as enhanced security features, resource-oriented programming, and formal verification. The talk will compare Move and Solidity, highlighting key advantages and differences. To make the concepts tangible, we'll convert a basic Solidity ERC20 token contract into a Move Module(contract) so developers get a sense for how things work on a practical level. 🚀 Get Ready for ETHDenver 2025! 🚀 We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2025—it’s going to be epic! 🌟
Transcript
[Music] G move y'all thank you for coming to my talk this is move for solidity devs uh my name is Rahat I'm going to be telling you a little bit about what we're doing at movement um how you can get started building uh on top of movement um and yeah let's get right into it um so I'm R hot senior deil engineer been deil in a few different places in the web through ecosystem for a while formerly hip-hop artist I don't do that anymore uh I no longer take uh requests for freestyles I kind of suck at it now so it's been a while uh since I've done that I've been a front and engineer freelance solity Dev um so I came into the move ecosystem from the VM side of things um so some of this is kind of going through a little bit of what I wish I kind of had when I was going into uh the movie ecosystem myself so quick agenda uh we'll do a quick history lesson uh on the Move um ecosystem in general little boring I'll try to keep it short um we'll talk a little bit very high level about the move virtual machine um we'll have an overview of movement how we're kind of like bringing this over to ethereum and then we'll look through a couple of code examples and Snippets um so you can kind of like solidify some of the concepts that we talked about cool so brief history of move where did it come from where did it start um few years ago Facebook was actually looking at building out a blockchain underneath um their social media platform um and that was uh two teams um or one team I suppose um DM and Liber teams who were coming in building out the move VM the move language um and initially this was supposed to be a chain that powered uh some of like uh Facebook's like payment uh type of systems that they wanted to go into unfortunately at the time the SEC decided no Facebook you cannot do this um and so uh the DM and lever teams kind of like branched out um some of them went on to become the Aptos um chain some of them went on to become the sui chain so right now the two most popular chains using the move language are Aptos and sui and um over us at movement and a few other chains are now also coming up with new move chains um and us especially we're building out something on top of ethereum so before we go into a little bit more on movement what exactly is the movm so again very high level um the movm is a runtime that ex executes move bik code this is similar to the evm executing ethereum bik code that's compiled from solidity and Viper but we're looking at using the move programming language instead um so the move programming language emphasizes safety flexibility and a resource Centric design and we're going to go into each of these when we go into the code examples um but essentially it gives you an environment that has has a lot of like VM level safety features and I'm not going to say it's safer or better than solidity um that is up to you to decide whether that is true or not um but it does give you an environment where it makes it a little bit easier to uh avoid some of the common kind of like pitfalls that you might see in solidity contracts so for an EV evm developer you can kind of think of the mve VM as a specialized environment in which every piece of data is treated much more rigidly um particularly anything declared as a resource and that's going to be the big thing that we focus on today and the language's design ensures that the assets behave the way that real world assets do um no implicit copy no accidental deposit things like that and we'll kind of like contextualize that in a bit so what's movement and what what do we have to do anything here so movement Network public uh main net soon TM um that's all been asked this week but um very very soon keep keep an eye out for announcements coming out there but what the movement Network um main net will be um it's going to be a proof of stake uh side chain on the ethereum um the movement network is the first move chain that is built using the move stack the move stack is going to be sort of like an SD and a set of Suite of tools that um other folks will be able to use in the future to build out their own move chains our goal really is to bring the move VM to ethereum and ultimately for me um the way that I've been approaching this at least on the devil side as I've been talking to devs I've been trying to onboard them to the move language is really just this question is like what if we could just provide devs with another environment with some of those safety level features um ingrained within the VM level so let's just jump jump into some code so on screen you'll see just like your basic solidity uh greeter contract um if you've uh onboarded and learned through hard hat you probably remember seeing this contract whenever you spun up a hard hat um back in the day um probably one of the first couple of contracts you've ever maybe looked at um as a solidity Dev so we're going to take a look at like how this converts over to move and um talk about some of those like Concepts um of safety as well this is what the contract looks like written in move um so slightly bigger we're going to be going through um some of these in a bit this does have a couple of additions a little bit of error handling um and a few other things in there that we'll be talking about in a second has a couple tests written out in there too so well how do smart contracts actually work right um so in the movm uh actually before before I continue there one thing to kind of note I mentioned before that the uh major players in the move ecosystem have been Aptos and SOI both of these companies have slightly different variations of move at Movement we use the apos Smo vs M so if you are coming from the apos ecosystem we're pretty much one to one um with their tooling so if you know aptop move you already know how to build on movement so modules and smart contracts um so modules are smart contracts a module is published at a specific address um so for example ZXI address will have a specific module it can have several modules in there it's kind of like one of the first things I had to kind of like conceptualize myself when you're you're looking at the evm solidity side when you deploy a contract each contract has its own address it's slightly different um on the Move side rather than each contract or module having their own address you're deploying specific modules to an address so you have your deployer address and you can um essentially deploy multiple modules to that address so users store what are called resources defined by that module into their own accounts and we take a look at that in the code in a sec and the way that you would interact uh with the contract is via entry functions so entry functions are just the functions that you would create scripts um to interact with from your front ends um from your scripts wherever and you have your view functions as well which do not um update any state and are just used for readon Access so this is the first part of that long um kind of uh module that I had uh written out before um this is kind of like how you define a smart contract um on the Move side you have your module you have what's called a named address in this case so the hello blockchain is actually corresponding to an address so that is going to be the address that I'm deploying to um I would set this in like my configuration of whatever address that should be and then message is the actual name of my module and you can see that a little bit in action with how I import um other libraries um throughout the rest of the contract so you'll see that that um the way that Imports kind of work is that you're using the Ed keyword and um you're importing from a specific address so the SD or standard library that is referring to the 0x1 address uh so at 0x1 we have several different modules that I can import one of those can be error signer string um in the case of string I'm going one uh level deeper into the module and importing the string type I can also import different functions for Strings from that as well um but essentially how you would import is you specify the address you specify the module and then you can go one level deeper specify any types or functions that you want to import as well apos framework is another address um that has several more um kind of like Library tools for you to use in this case there is uh we're going to be using an account um an event uh module that'll help us deal with our any accounts that we're using and emitting events so I've talked about resources a couple different times I've mentioned them uh so what exactly are they uh so move applies what's called resource oriented programming meaning assets which are resources are treated as first class citizens with very very strict rules and the goal here is to prevent things like duplication or destruction of onchain assets like tokens or nfts so um resources have different things called qualifiers um a couple of them are key store and drop U if it has a key um qualifier that means this resource uh can be published to an account Global Storage um has store it can be used in local variables variables or passed between functions that has dropped this allows resources to be explicitly dropped or destroyed without calling a custom function so if a resource lacks the the drop keyword the mve VM enforces that it can only be destroyed via a module that defines it EG like a burn function so this gives you like again the these different qualifiers will give you different protections on the VM level so adding a bit more onto the contract um now we have we're defining two resources uh resources are defined with structs my first struct is just this message holder resource uh I gave you that key uh qualifier so if you remember this allows the resource to be published in an account's global storage and we'll see how that kind of works out in a second um but the uh message holder struct has two things the message which is just a string and I'm using the string typing that I imported from the the standard string library and um a message onchain event that we're going to admit and that event is um then defined in the following struct below there so here now is kind of like the the first entry function for actually setting um your um your message right so if you recall back on the um solidity contract um you might do this in like your Constructor where when you deploy your smart contract you set your message uh in this case uh the way that this is done is we check to see if a resource in this case the message holder resource actually exists on the account that is interacting with um the uh contract at the time so in this case message holder this is the um actual resource that I defined does it actually exist on this account if it doesn't what we're going to do is take that resource and move it to the um account that is interacting with it a an account cannot have a resource until you've actually moved the account over to it hence the programming language move um so in this case we're moving um the message holder which will have the message and the event Associated to it and we'll we set that down here and emit the event up here as well so how resources are moved are moved in move um in that snippet we use the move to function and this places a new message holder resource into the caller's account if that resource doesn't exist we created it and this ensures that there's no accidental duplication only one message holder resource can exist per account unless the code explicitly allows more so if the message um holder already exists we fetch it using this Barrow Global mutation function um and this gives us just like a mutable reference so that we can update it um if need be later on and the move VM uh essentially enforces that no other references um can be made simultaneously which helps you with making sure there's no uh partial data updates um which can lead to things like organy so why this matters if you're building something a little bit more robust sty let's say you're doing some type of uh token contract nft type of contract you have much more safe minting and burning uh capabilities you can use the move to burn move um from these helpers with like moving resources in and out of accounts you have VM level safety like I was mentioning from double minting or inadvertently dropping these resources um there's much more clarity around the ownership and life cycle a user's balance or nft or message resource lives in their account so rather than let's say creating like a mapping between um the uh address to whatever their balance is and having to manage that yourself um because you're moving the resource to that account you can simply access the the um actual resource directly from the account itself so this resource based system kind of like naturally models um ownership and transfer logic of Assets in real life so continuing on with the um smart contract we have um just our basic view functions not too different I guess um from the city side of things you have a function uh to get the message um what this is going to do so like I mentioned resources have to be actually attached um to an account so the first thing this will do is just uh take a look whether this address has a message uh resource um so that's this assertion uh over here um we have just like this error message um defined up here we'll throw that error message if the message doesn't exist otherwise we'll borrow from the global state of that address and display whatever the message is testing is also um very nicely done uh within the VM um in solidity You' use let's say if you're using hard hat you'd probably do your testing via JavaScript um using Foundry you're able to um do your testing via solidity um on the movm um it comes like built-in uh testing Suites so you're able to Define your test right inside your module if you want to or create like a separate module for your test either way um you define tests using this hash test over here and you can Define accounts as well that will act as signers within those tests and run your tests this just a basic test looking at whether um this account is able to create a message here or not um so yeah like I was mentioning move includes built-in testing framework you can Define uh test entry functions inside the same module or a dedicated test module um the 0x1 like I mentioned spawns a test scenario with a signer at address 0x1 um that can be whatever you want it to be uh testing uh can create accounts and call your entry functions in a controlled environment so where do we go from here there's a couple different places um you can check out if uh you want to kind of like dive a little bit deeper uh start learning some more of the syntax if you're coming from solidity um move is a rust based language so if you've ever done rust before you might be a little bit more familiar with move syntax um with that said though we do have a bunch of resources for getting folks um uh up and ready these are our docs this is docs. movement network. XYZ um it goes over some of the code that I went over during this presentation um as well as interacting on chain uh different network RPC end points and all that um we also have our developer portal uh which can give you more in-depth guides into just learning move in general um if you want to just like uh re get like a deeper understanding of some of the concepts I went through we do have a couple of guides and tutorials here um this one I recommend uh my uh cooworker Cheyenne built like an onchain Twitter clone um and this goes into some of those like resources resource accounts and how uh some of those um movement of resources work in like another context here as well so with that said these are some of the resources that we're priding we're def um we're right now kind of like gearing up for our public mainnet release which will be pretty soon and um yeah excited to to be able to uh be here and give give you guys an INT introduction to this um happy to answer any questions later on I'll be around and yeah thank you for tuning into the talk
Automatic transcript — names and jargon may be misspelled.