I always thought that tokenization is one of the most interesting concepts in blockchain. Basically, tokenizing means issuing a token that are linked to a real-world asset. The link can probably be implemented in multiple ways but if I understand the legal context properly, the primary way is a regulatory framework. I will definitely be doing more research into this, but first I wanted to create something of substance that I could use as a point of departure. I went with my first idea which is short-time rentals.

‍

I was trying to come up with an idea for a short program in Rust that would help me systematize some things that I've already learned and wouldn't be a basic primer. I've decided to refresh my memory on some Elliptic Curve routines, specifically, adding points on EC. This way I am able two kill two birds with one stone, if you excuse my double avicide.

‍

Recently I was experimenting with FuelVM - an optimistic rollup (in the default configuration, there are more options for setup - see below) working on top of Ethereum that provides Smart Contract functionality and is focused on delivering significantly higher transaction speeds and, as a side effect, lowering the transaction fees. You can learn more about the Fuel VM project on the Fuel Labs website.

The speed goals are delivered by a combination of techniques that FuelVM employs. First one being parallelization of the transaction execution thanks to the UTXO execution model. It allows leveraging OS multi-threading and CPU cores for parallel execution of transactions in a block which significantly reduces the execution time when compared to single-threaded execution.

Another aspect that speeds up the whole solution is the use of Rust language for implementing the node. Rust is a secure language in a sense that it prevents many types of weaknesses from being introduced into the program at the compilation time. Various strategies for memory management, variables lifetimes, concurrency etc.. are used to eliminate such weaknesses classes such as:

• race conditions
• double free
• Use-After-Free
• wild pointer dereference
• etc.

All of these weaknesses were often resulting in serious vulnerabilities identified in the final products that were written in C, C++, etc.