This entry is part of a series of blog entries in which I attempt to build a comprehensive threat model for the blockchain ecosystem. Check out the introductory entry.

When it comes to services on blockchain, we can view them similarly to regular services in terms of functions  and threats. Service providers, as in off-chain applications, are trying to make a coin by providing useful products and services to their users. So we're looking for example at:

- Fungible and non-fungible token contracts
- Token exchanges
- On-chain wallets
- Lending smart contracts
- DAOs
- many other types of service.

I will also refer to services as smart contracts.

In case of service developers, besides looking at the threats related to the service alone, it's also worthwhile to look at the development process (Software Development Life Cycle). I will do this in a separate blog entry because I think that due to numerous differences it makes sense to separate these two aspects.

Although risk analysis related to the exposure of assets that remain under control of service provider is a more general task than threat modelling, I feel that I should mention as a part of this entry's introduction that in case of on-chain applications risks can be considerably higher than in case of off-chain equivalents. The reasons for this include:
- sensitivity of assets under control
- volume of assets and transactions
- exposure in terms of code and data visibility
- unknowns that are related to the use of emerging technologies

For this reason I think that potential service providers should exhibit due diligence and due care for safeguarding assets under their control and understanding threat model of their perspective is a key aspect of this.

All right, let's explore the threats. As usual, I will rely on the STRIDE methodology.

‍

‍

‍

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.

Hello all! I am very happy to announce the long-awaited premiere of the AnxioCrew NFT collection,

the hottest NFT collection of 2023!

‍

Currently it's only on Avalanche because Ethereum is expensive :(

Only two amazing AnxioBuddy tokens minted for now! Enjoy!