NFT⚡Brit Gaile 🏃

@mihaieremia @beniaminmincu x.com/SeverMM/status…

Let's talk about the #MultiversX smart contract Rust framework 🦀 and dispel some of the confusion surrounding it! There's been recently a lot of interest in the community about our tools, and even a poll to name some of them! This is great! 🔥 So let's use this occasion to provide a quick tour of the framework. First off, it's much more than a development framework. As you will see in this post, it provides support for building both on- and off-chain. The vision is to have smart contracts developed at a very high standard of quality, and then build dApps around them. Ideally, this framework should be everything you will ever need to develop on the #MultiversX blockchain, a swiss army knife for everything blockchain. I also want to point out, that while developed and optimized for #MultiversX, it is modular enough that it could in principle be used with other blockchains and systems. There is a large repo containing all the functionality and a lot of examples (mostly in the form of contracts), feel free to check it out: github.com/multiversx/mx-… There is also a lot more on how to build smart contracts here: docs.multiversx.com/developers/sma… 1. The data format (codec) I am not even going to start with the framework proper, since before that we need to talk about how data is encoded on the blockchain. We've built a very fast and compact codec, specifically for our blockchain needs. Most importantly, we wanted a format that: - can be read by humans with little effort, - is as compact as possible, and - can be encoded and decoded fast. You can read more about it here: docs.multiversx.com/developers/dat… 2. The smart contract base framework What might feel familiar for most people, we have a smart contract framework. It contains everything needed to write a smart contract in Rust. Very importantly, this base framework is not tied to any particular implementation. It is not really a WebAssemly framework, because it knows nothing about WebAssembly. Contract code can be built and run on any platform, and specifically, as you will see, we do not debug or test contracts via WebAssemly most of the time. This also means that smart contract code doesn't actually need to end up on the blockchain. We are working, for instance, on a solution to deploy smart contract code as a service that merely queries the blockchain, but runs off-chain. The base framework is very high-level. It gives you abstractions to easily express storage, I/O, events, and most especially transactions. We are in the final stages of creating a unified syntax for all transactions: those launched by users and smart contracts, simple transfers and contract calls, tests, queries, you name it. There will be more about this soon. It also provides a lot of types and optimized operations, which on our VM run extremely fast. We call them managed types, and they allow us to avoid performing allocation on the heap and dealing with memory in the precious smart contract computational space. 3. The wasm adapter Because the base framework doesn't know about WebAssembly, we need a separate adapter to aid in the build process. 4. The meta crate Building contracts is complicated, for reasons we have no control over. So we put a lot of effort in creating a tool that hides this complexity and makes day to day developer life easy. For a long time, mxpy was used for all contract maintenance, but we felt that a native Rust application is closer to the framework and more accessible from the Rust ecosystem. Meet multiversx-sc-meta, sc-meta in short. It does the following (in no particular order): - helps to build the ABI, - builds contracts to wasm (production/debug mode), - helps generate boilerplate for tests, - creates new projects from template, - upgrades contract projects to the latest version, - generates boilerplate for snippets, - makes it easier to run tests, - (coming soon) installs some required dependencies. By the way, the "meta" in the name comes from "meta-programming", since this is its main purpose: to be a (meta-)program that deals with other programs, i.e. the contracts. You can read more about it here: docs.multiversx.com/developers/met… 5. The testing framework In an ideal world, development is 10% of the effort, while the remaining 90% is reserved for testing. Smart contracts need to be exceptionally tested. There are several ways to test: - on a real blockchain (testnet/devnet/mainnet) - on the real Go VM, but with a mock blockchain, we have a Go tool for that - in pure Rust, on a simulated VM. Yes, we've built a full MultiversX VM in Rust (more about this later). This testing framework revolves mostly around the 3rd option, the Rust VM. It also allow for step-by-step debugging of contracts. It provides a rich syntax for setting up Rust tests, which come in 3 flavors: - unit tests, - white-box integration tests, - black-box integration tests, that imitate the blockchain. It also provides the support for running Mandos json scenarios. 6. The Rust VM Now that we've mentioned it, let's also say a few words about the Rust VM. It is a replica of most of the functionality on the main Go VM. It is currently only used for tests and debugging, but we are working on integrating Wasmer (our VM's engine) in it and slowly turn it to a fully functional alternative to the Go VM. If we are ever going to have multiple independent implementations of the MultiversX protocol it makes sense to start with the VM, isn't it? 7. The interactor framework Building and testing contracts is just the first step. They need to be deployed, then we need to sent interact with them. For a Rust developer it is painful to have to switch languages to do so, so we're offering the possibility to have small Rust programs that do just that. For now this is only for small interactions, but we are planning to do a full web service Rust framework. The syntax that we employ here is very similar to the one that we use in tests, and in contracts. After all, it's all just transactions everywhere. Since everything is Rust, it is quite straightforward to formulate these interactor transactions with the help of the very types and endpoints defined in the contracts themselves! There is no need to rewrite anything in another language, not even to bother with the ABI, contracts naturally provide all functionality for format calls to them. 8. More There are several more smaller tools, some libraries for dealing with tests, some experiments with UI, etc. For an overview, this is enough, we'll stop here. Final thoughts As you can see, there is a lot going on in here, and this is just scratching the surface. We've been working for years to provide this very rich and friendly developer experience. We are also very proactive about bugs and vulnerabilities, and are designing our frameworks to make most types of bugs impossible to write in the first place. I want to return to my main point: this is much more than just a smart contract development framework. We are creating a new way for developers to interact with the blockchain, all integrated, with powerful abstractions, and no effort spared to achieve bug-free code. So with that being said, It's time to build! 🛠️🔥🚀

♾ Onefinity Chain ♾ The next steps have been solidified, and the path to the future is now set. OneFinity Chain is poised to be the first EVM-compatible Sovereign Shard on @MultiversX, charting a clear path for the future. #MultiversX #EGLD

Enter the @Ta_da_io Gleam challenge and win your share of the $8,000 in $EGLD prize pool 🔥 Discover the platform enhancing cutting-edge AI models via #MultiversX microtransactions & participate in the growing AI data economy. Win up to $2,000! 🍀 gleam.io/JBZVo/tada