New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Why smart contracts speak Rust? - Rastko Misulic | Ceres Blockchain Solutions

ETH Belgrade CommunityTue, Oct 7, 2025, 12:00 AM

Why smart contracts speak Rust? - Rastko Misulic | Ceres Blockchain Solutions

Transcript

First of all, let's introduce Rust. Rust has system level control and high level uh abstraction and many blockchains already uh many blockchain Yeah. Is it better? Great. Uh many blockchains already adopt Rust.

For example, Solana, Polka Dot, and near because of its performance and safety. Rust has compile time guarantees to reduce runtime bugs which is critical for the smart contracts. Rust has ownership model which means that every value has only single owner and ownership could be transferred but all owner is prevented from the usage because absence of the garbage collector memory is freed deterministically when order goes out of scope. This is an example. We have a value x with a string hello.

We transfer ownership to y. We could uh print Y but X is no longer uh owner of the string hello. Rust also has borrowing and references. Borrowing could be done in two ways. Immutable and mutable borrowing.

Compiler uh enforces no dangling references and compile time checks ensures that references don't talk to the live data uh itself. in smart contracts. This prevents re-entry by controlling the access to the mut mutable state. Lifetimes in Rust annotates how long references are valid avoiding dangling references in this example from the function longest. We can see lifetime of a for every input and return value and we could be sure that reference of the return value uh can be uh greater than input lifetimes in contracts.

This ensures that state reference remain vi during execution. Sorry at the compile time. We also have overflow and underflow checks. Uh Rust defaults to checked arithmetics. Integer overflow underflow panics at compile time in contracts.

This check uh these checks prevents malicious large inputs uh to corrupt smart contract data. Memory safety in Rust is really important. Rust enforces no null pointers or taggling pointers. ownership and borrowing mechanisms ensure safe memory access without runtime overhead. We also have type option that replaces now pointers which help which can help avoid vulnerabilities to the me exploits.

Rust is used for the smart contracts of Solana. They are called programs and they are written in Rust. Ankor is a rust framework for developing Solana programs. Uh it's a practically set of macros to reduce boilerplate. Anchor also also uses Rust type system to define a construct.

This is the example of one Salana program written in Rust name is hello. We have one function to init and we have accounts uh for the context for the init function. We can see that we have lifetimes mutual mutable borrowing result as a return type and for example no se semicolumn at for the return value substrate in and ink at on polka dot uh parach chains are uh made with pallets pallets are written in substrate and ink is rust based DSL to be executed on polka dots. It uses rust macros to reduce boiler plate macros like ink message for for functions in storage for storage of course. Uh it it also uh inherits ownership borrowing and memory safety.

Ink contracts are compiled to web assembly and can be executed on par chains that implements contract pallet. This is example of the simple flipper contract uh written in ink. We have macros for ink contract constructor message. We also have mutual borrowing for the flip and regular mutual borrowing for the get. Next is noir.

Noar is rust's inspired DSL for for writing circuits in zero knowledge proofs is developed by AIC. It uses compile times check to enforce circuit constraints. We have simplified borrow uh borrowing model references exist but lifetimes are static so there is no bar borrow checker. This is example of the one uh function and implementation for the uh noir contract. We have assert, we have uh mutual reference uh mutable references, generics etc.

Next is move. Move is smart contract uh language designed for the many blockchains but currently is adopted by sui and optus. move is resource oriented language and it's designed to ensure that assets cannot be destroyed or copied sorry it uses generics in models and function one model is practically one smart contract for for uh network compile time safety is guaranteed because verifier enforces no double spending type safety and memory safety. This is the example of the counter contract written in move. We have object counter with a key ID owner value.

We could create increment set value. We can see that uh syntax really resembles Rust. We have mutual b mutable borrowing assert macro for for checks lifetimes in smart contract development in rust based smart contract development are really important because that uh they ensure reference don't outlive the data and there is no dangling pointers in ink and anchor uh lifetimes annotate only context data to ensure safe borrowing. Noir does not have lifetimes as we mentioned because every value is copied and all the references are static. Move handles lifetime implicitly because every object is is live uh until we destroy it or move it.

Next are compile time checks. In smart contract we uh RAS provides uh overflow and underflow checks to prevent integer wraparound exploits. We also have ownership and borrowing as mentioned because we don't want to have nulls or dagling pointers. Type safety is really important because we can uh write functions that are compatible with any type. We don't have garbage collector but we have deterministic execution which is essential for the blockchain.

How to handle errors in rasbed smart contracts. We have a type result that is used for error propagation. We have error of type typ and uh result of type. Ink and anchor uses similar result type uh and ink and anchor contracts are reverting on result error. Noar uses assert uh to enforce proof conditions and move uses assert macro to abort transaction on failures.

How to prevent re-entrance via barbing? Re-entry is a famous attack vector in smart contracts. Uh it arises when contract makes external calls which then call back the contract and try to mutate the state unexpectedly. Rust have mut mutable borrow which is enforced to be only one mutual mutable borrow references at a time which prevents re-enter state mutation. Generics in smart contracts.

Ink supports generics for storage. Move us generics like in this example for the ID function which demonstrates uh polymorphism allowing function to operate with any type. For example, we could send uh uint or string to this function and it will always return the same type as we send it. Anchor uses generics for CPI accounts and contexts and generic codes compiles down to the without uh runtime costs because we have for example this function ID in uh after compilation uh compiler would enforce one version for example of function ID with u int one version of ID with string and paste it with with no runtime costs. Last but not least, what are the best practices for the Rasbased smart contract?

We should always prefer immutable immutability if it's possible. It's better to use let than let mute. If we don't want to mutate state uh right uh be uh be aware that we don't need uh we need to uh be careful when are writing uh unsafe code. We need to uh be good in testing and try to minimize vulnerabilities and we always you we need to always use unchecked arithmetics to avoid overflows and underflows. We could use track check etc.

That's it. Thank you.

Automatic transcript — names and jargon may be misspelled.