Forem: Decipher with Zaryab

EVM Part1: The ABCs of Ethereum Virtual Machine

Decipher with Zaryab — Fri, 03 Mar 2023 04:40:18 +0000

Note:
This is going to be a Multi-Part Series with all extensive and imperative details about the Ethereum Virtual Machine, Opocdes, Bytecodes etc.

The next parts of this series shall only be published on the official website of Decipher with Zaryab.

Subscribe for Free now.
JOIN zaryabs.com

EVM in 100 words

The Ethereum Virtual Machine can simply be understood as an isolated environment specifically designed to process smart contract transactions as well as, most importantly, determine the overall state of the Ethereum blockchain with every new block that gets mined.

Imagine EVM as a computer that specializes in handling smart contract transactions as well as defining the rules for state changes from block to block in the Ethereum blockchain.

However, unlike physical computers, EVM is a virtual machine that is not bound to a single operating system or location, thus allowing global accessibility for anyone willing to run an Ethereum node.

Alright, there you go. EVM is now explained in precisely 100 words. Go ahead, count it 😃

Let's start Deciphering EVM

Now it's time to dive in just a bit deeper into EVMs.

If you have ever tried to understand and read about EVM before, you might have come across different ways in which EVM is defined. For instance:

EVM is a Virtual Machine ...
EVM is a State Machine ...
EVM is a Quasi-Turing complete machine...

I believe the best way to understand EVM effectively is to decipher each of these statements about EVM.

So, let's get started

EVM as a Virtual Machine...

To begin with, let's start with the VM(virtual machine) part of the EVM.

Let's roll back and forget about Ethereum and even virtual machines.

Let's talk about Physical machines.

Physical machines can simply be understood as the hardware that runs on your computer like the x86, ARM, or, perhaps your favorite, the new Apple M1. It's important to note that the lowest level of instruction, for a physical machine, is Binary. Basically just Zeros and Ones.

The physical machines perform actions based on their interpretation of these binary opcode instructions themselves.

Now, Virtual machines are very similar to physical machines as they too have opcodes to perform specific tasks. Some virtual machines you might know are JVM, LLVM, etc.

However, a crucial difference is a fact that these virtual machines, although they are quite similar to physical machines, aren't tied to any physical hardware.

This means that virtual machines provide a runtime environment but are completely platform agnostic. It allows compatibility across a wide variety of systems, irrespective of the underlying hardware.

Alright, now that we understand VMs, it won't be hard to grasp the Ethereum virtual machine.

EVM is a virtual machine which means it can run on multiple hardware irrespective of the underlying platform/OS. This is quite crucial as it plays a major role in enabling decentralization since we can run EVM on as many platforms as we want.

In fact, the EVM is what makes Ethereum so interesting and sort of revolutionary because we now have the power to execute any arbitrary code on a blockchain.

In the pre-EVM era, this would have been a nightmare as a new blockchain with custom logic had to be created every time a new app with specific use case was to be built.

Thus, EVM is a virtual machine that provides us with a completely virtual runtime execution environment for processing smart contract transactions and has global accessibility where anyone with any hardware can easily run this virtual machine.

EVM as a State Machine...

As previously discussed, in the 100-word EVM intro, one of the essential goals of EVM is to determine the state of the Ethereum blockchain, hence the state machine.

But what exactly are State machines?

State machine, in very simpler terms, is a device that specializes in storing state as well as defining the rules of state changes of a particular system.

It can change(transition) its state from one to another depending on the inputs provided to it. See

Now, considering the world of Ethereum, the state refers to an extensive data structure that keeps all the accounts, i.e., Externally-owned accounts (EOAs) or Contract Accounts(more on this later), linked together by hashes.

In other words, every detail on the Ethereum blockchain, i.e., the amount of ERC20 tokens you hold, governance proposals and their vote counts, NFT ownership, etc, are technically different states on the network. These states are reducible to a single root hash or, as we call it, the World State.

This world state of Ethereum basically represents the current state of the entire blockchain which comprises all the historical states that together form this current state hash.

Now it's important to note that even the slightest change in any of the accounts (EOA or Contract Accounts), leads to a change/transition in the world state. This means with every single transaction that is mined, be it your NFT ownership change or a governance proposal being executed, *leads to a change in the overall state of the chain. *Read more about Ethereum's world state in this article.

In a nutshell, every successfully executed transaction, irrespective of how big or small, leads to a change in the Ethereum state.

Fig.1a-Source: ethereum.org

And this is all possible because EVM acts as a state machine.

Well, why is this important?

EVM being a state machine plays a significant role in making the Ethereum blockchain so effective.

If we take a quick look at the Bitcoin blockchain, we will find that it's a distributed ledger that is quite strict in its state transitions. Transactions on the bitcoin blockchain lead to global state transitions that mainly track or record the ownership of the native currency(BTC).

While on the other hand, Ethereum being a distributed state machine provides much more than that.

Instead of simply recording the currency ownership states, it has the power to transition to a new state in response to an arbitrary smart contract input data as well.

This is incredibly significant because such flexibility in the state transitions is what allows us to create custom currencies(ERC-20 tokens), NFTs, complicated Defi protocols, or even a complete DAO using smart contracts.

EVM as a Quasi-Turing Complete Machine...

Alright, so per our usual approach, let's forget about Ethereum or EVM and only focus on the Quasi-Turing Complete part.

Actually, just focus on the Turing Complete part.

Turing Complete refers to the kind of machine that enables running a program that can answer/solve any computational problem, irrespective of the time or memory it takes to do so.

In other words 👇

Yes, that's Alan Turing who coined the idea of "Turing Completeness" 😃

For instance, languages like C, C++, or Java are turing complete systems.

Well, now comes the obvious question --- Can the Ethereum blockchain be considered a Turing Complete system?

Well, yeah sure. (But read the whole thing, there's a catch)

It's turing complete as it can execute any program similar to a turing machine and can read as well as write data to memory. In fact, turning complete plays a significant role in allowing Ethereum to run arbitrary logic via smart contracts, which other blockchains are incapable of.

However, there lies a caveat with the turning-completeness of Ethereum that cannot be overlooked. Here comes the catch.

If you recall the nature of Turing machine systems, they can basically run forever and* use infinite memory.*

In the world of Ethereum, though, we cannot really have programs that run forever or uses infinite memory.

While regular computers can simply halt such infinitely running programs, we cannot do the same with Ethereum as it's a global computer(and a distributed ledger) that must be accessible/online at all times.

Now, in order to avoid the halting issue in Ethereum, it includes a specific type of limitation in the computational steps for any smart contract execution. It imposes this limitation using the concept of Gas. Check out this article by Consensys to learn more about the fundamentals of Gas in Ethereum.

This means the EVM keeps track of every instruction that is to be executed and charges a particular amount of Gas fees (in ETH) for every computation or storage being used in the transaction. In other words, if you run out of gas (basically money) you can no more execute the transaction, thus resolving the issue of transactions/computations that run infinitely.

In simpler terms, Ethereum is indeed a Turing complete system. However, it does impose limitations using gas which doesn't really allow this system to include forever running computations or those that use infinite storage.

Therefore, while EVM doesn't belong completely in the category of a Turing-Complete system, we call it a Quasi-Turing Complete System.

Understanding the crucial components of EVM & Ethereum

EVM can be considered a machine with a simple stack-based architecture.

In order to effectively understand the working mechanism of EVM, we must understand some of its most crucial components and their responsibilities.

However, before diving into EVM components, I feel it's important to touch base on some fundamental concepts of the Ethereum blockchain.

Note: These fundamental concepts will help us understand EVM components better. However, feel free to skip them if you are already aware of them.

Quick Review of the basics

1. Accounts in Ethereum

An account in Ethereum blockchain can simply be defined as a component that represents either an individual user or smart contracts on the blockchain and allows them to initiate transactions.

Ethereum includes 2 different types of accounts:

Externally Owned Accounts --- also called EOA
Contract Accounts

Let's quickly understand each of them:

a. Externally Owned Accounts are controlled by their private key. In simpler terms, a specific EOA is controlled by a user who owns the private key of that account.

These accounts are capable of initiating transactions in the blockchain. However, transactions between two EOAs can only be limited to ether or token transfers.
Since these accounts are owned by private keys, the owner of the key must sign the transaction to initiate any activity in their account.
For instance, this is an Externally Owned Account --- HERE

b. Contract Accounts, on the other hand, are not controlled by a private key but by their own smart contract code logic.

Have you ever deployed on any EVM chain? The address you get after contract deployment is basically a contract account.
These are the accounts that do not just hold your ether or token balance but are also capable of storing smart contract codes within themselves.
While contract accounts are also capable of sending transactions, they do so only in response to receiving a particular transaction. In other words, they won't send a transaction unless their logic allows them to.
It must also be noted, that, unlike externally owned accounts, creating a contract has a cost attached to it since we are deploying data on the chain.
This, for instance, is a Contract Account

2. The Concept of GAS

Remember when we discussed EVM being a quasi-turing complete system? Well, the concept of Gas plays a significant role in making it one.

Gas, in laymen's terms, can be understood as a unit that describes the amount of computation power required to execute specific transactions on the blockchain.

For a transaction to be executed and affect the world state of the Ethereum chain, one must pay a certain amount of gas. Additionally, this amount of gas relies on how heavy a transaction is. The heavier the transaction, the more gas one must pay to execute it.

For instance, transferring 1 ETH to your friend can cost lesser gas than executing a Swap function on Uniswap smart contracts.

3. Transactions in Ethereum

Alright, we discussed briefly how EOAs are capable of initiating and sending a transaction, but.... What exactly are transactions in the context of EVM?

A one-liner answer would be:

A transaction in the Ethereum chain is basically an action that can be triggered by any externally owned account to perform a state-changing interaction on the blockchain.

It means, whether you use your ethereum account to transfer an NFT to your friend or you interact with the PushCore smart contract to create a channel on the Push Protocol or you deploy a new smart contract, everything is a transaction on the blockchain that contains cryptographically signed data messages defining the task to perform.

Transactions in the Ethereum blockchain can broadly be categorized into 2 specific types:

a. Message Call transactions:

Message calls refer to the transactions that are triggered by an EOA in order to interact with a contract account or yet another EOA.
You sending USDT to my address or interacting with Uniswap are all examples of message call transactions

b. Contract Creation transactions:

As the name suggests, these are transactions that aim to create a new contract account on the chain.
For instance, deploying a new smart contract for your next web3 project is a type of contract creation transaction.

The Architecture of a transaction in Ethereum

Let's quickly understand some of the crucial fields that an ethereum transaction holds:

nonce: A counter that keeps increasing every time you initiate a transaction from a particular EOA.
recipient or to: the address of the recipient of this transaction. (it can be an EOA or a Contract Account).
value: the amount of ether to be transferred from the sender to the recipient address. It can be left zero if no eth transfer is supposed to happen in your transaction.
data: an optional field to include any arbitrary data. This field can contain code in a specific transaction for a Contract account
gaslimit: which refers to the amount of gas that can use in a particular transaction.
maxPriorityFeePerGas as well as maxFeePerGas
and, signature

Alright, now that we understand the fundamental topics of the Ethereum blockchain, we are all set to dive in deep to get the gist of some crucial EVM components.

EVM Architecture and its Components

Fig.1b-takenobu-hs github

Storage

To begin with, Storage can be seen as the Hard drive of the computer that stores data permanently.

Storage can simply be understood as the permanent storage of the EVM. Any value that is written to the storage is retained even after the execution is completed.

In simpler terms, Storage is basically a key-value storage system that maps 32 bytes slots to 32-byte values.

It's imperative to note that since storage holds data permanently, it consumes more gas and is therefore costlier to use in your smart contracts.

💡 Considering the fact that storage operations are costs more gas, (= more money), it's always recommended to optimize your contracts to only use storage operations where necessary and remove wipe out the rest.

Memory

While EVM storage resembles a Hard drive, Memory is more of a RAM in the computer, a temporary data holder.

EVM memory is not really persistent and is wiped out as soon as the function execution is completed.

Unlike storage, memory usage in smart contracts is comparatively a cheap operation that costs less gas. However, it must be kept in mind that the cost of using memory can increase as memory usage increases in a function.

Calldata:

Calldata is an interesting section of the EVM and equally imperative.

It is a quite special data location of the EVM that refers to the location that stores the input parameters or arguments of the function that is supposed to be called.

Quite similar to memory, calldata is also a non-persistent data holder that is cleared after the execution of the transaction.

Calldata is quite cheaper and costs very less gas.

It should also be noted that it can never be written as it's read-only.

Stack

The stack is the most important component of the EVM.

EVM is technically a stack machine as it plays a significant role in every computation or operation performed in the EVM. With a maximum size of a total of 1024 values, the EVM stack can contain words of 256 bits.

It is mainly used to store smart contract instruction inputs as well as outputs.

Program Counter

The Program counter in an EVM indicates the specific instruction from the code, that should be read and executed next by the EVM.

This counter basically allows the EVM to step through the entire contract code and interpret as well as execute the specific instructions to reach the desired outcome/state.

At the very beginning of any transaction execution, the Program counter is set to ZERO.

How does EVM work?

Alright, now that we grasped the very core fundamentals of the Ethereum Virtual Machine as well as its components, it's time to combine all of it together and get the gist of how an EVM works.

Note: This is an eagle-eye perspective of how EVM works. We will dive into a lot of technical, in-depth and fun details about EVM in next articles of this series.

Before diving into EVM's working mechanism...

If you remember the very first line of the EVM in 100 words section of the article, it said --- Ethereum virtual machine is specifically designed to process smart contract transactions.

While it's true, it should also be kept in mind that the EVM cannot really execute solidity smart contracts directly. This is because the EVM doesn't really understand a high-level language like Solidity and therefore cannot interpret or execute it directly.

Every Solidity smart contract is compiled down to low-level machine instructions called Opcodes, which are understandable by the EVM.

In order to execute any tasks, storing data in state variables or executing a swap of tokens, the EVM uses these opcodes.

There are around 140 total unique opcodes at the moment and each one of them has a specific functionality attached to it. We shall read about opcodes extensively in the next article of this series.

EVM working mechanism

To begin with, it all starts with a transaction.

Here is what a dummy Ethereum transaction might look like. 👇

{\
from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",\
to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",\
gasLimit: "21000",\
maxFeePerGas: "300",\
maxPriorityFeePerGas: "10",\
nonce: "0",\
value: "10000000000",\
data: "0xabcd",\
}

Let's consider this transaction as the one that the EVM is now about to execute.

EVM Instantiation

Whenever a transaction triggers the execution of smart contract code, an Ethereum Virtual Machine (EVM) is instantiated with all the necessary information. These details are related to the current block being created.

The address in the 'to' *field is the address of the contract that is being targeted. Additionally, the transaction includes all other crucial details like *gas limit, ether value, *as well as the *data that is to be executed on the target contract.

As soon as an EVM is instantiated, it basically prepares itself to start the processing of a new smart contract transaction.

This preparation, for instance, involves:

the program counter of the EVM being set to zero,
Storage being loaded from the contract account,
Environment variables being set as well as memory initialized to zero, etc.

The EVM then pulls up the contract and its code associated with the given address in the transaction.\
This is where the significant role of the Program Counter starts. The program counter now helps the machine to step through the entire code which allows the EVM to interpret and execute the given instructions one-by-one.

Once all such preparations are done, the EVM technically is then ready to start executing the instructions (opcodes) and resulting in the intended state changes of the contract.

2. Gas Supply & Adjustments

Although the EVM is now all set to start processing these opcodes, we cannot keep the concept of *Gas *out of this equation.

As previously discussed in the *EVM as a quasi-turing complete machine *section, for every smart contract operation to be executed, a transaction fee must be paid in the form of gas.

When initiating a smart contract transaction, the sender of the transaction must provide a certain value of gas fees(in the form of ether) that he is willing to pay for this transaction to be executed.

Interestingly, as the smart contract operations are executed, the gas supply provided with the transaction reduces.

In other words, if the sender didn't provide an adequate gas supply required for the transaction to be completed, the supply eventually gets to zero and the EVM throws an Out of Gas exception error. This immediately stops further execution of the transaction.

If such an event happens, the entire transaction is rolled back and no changes are included in Ethereum's state.

The sender's ether balance, however, does decrease since he/she had to pay for the gas that was consumed so far by the transaction.

Gas can also be Refunded

Some transactions can also include a higher gas limit, i.e., the amount of gas that the sender is allowing to be consumed in his/her transaction.

However, if the provided gas limit is way higher than the required gas in the transaction, EVM simply refunds the unused gas back to the sender.

Fig.1c-Source: Ethereum.org

3. Processing transactions and Changing World State

Alright, let's consider that the above-mentioned transaction neither throws any *Out of gas *error nor has any logic error that might lead to its rejection.

This technically means this transaction can be successfully processed by the EVM, consume the required amount of gas, and lead to the expected changes in not just the target contract's state but also the entire world state of the chain.

Contracts calling Contracts

An interesting point to keep in mind is smart contracts can initiate transactions or calls to other smart contracts well.

A transaction initiated by an EOA to some Contract X *can also lead to a new transaction initiated by the targeted *Contract X *to some other *Contract Y if need be.

Every new call to a new contract creates a similar cycle of EVM instantiation and transaction execution which ultimately leads to desired state changes.

It should, however, be noted that every new smart contract transaction within the original transaction requires gas to adequately execute the transaction.

Therefore, a new EVM instantiation highly relies on the amount of gas remaining for the execution of the new transaction. In case the gas passed along with the transaction, isn't sufficient enough to make new calls to new contracts, the transaction shall completely revert.

The diagram below represents such transactions quite clearly.

Fig.1d-Source: ResearchGate

Wrapping it up

That brings us to the end of the very first part of the EVM series.

Remember, the core objective of this part was to set a strong foundation of the basics and important details about the Ethereum virtual machines. Thus, preparing ourselves to dive much deeper into its technicalities in the next series.

We now have a very clear idea of:

Basics of EVM.
Why is EVM a state machine and what exactly are virtual machines?
Why is EVM called a Quasi-Turing complete instead of a Turing complete machine?
Core components of EVM
An eagle-eye perspective of EVM's working mechanism.

In the next part, we shall start exploring the entire journey of smart contracts --- from development to its on-chain execution. Stay tuned.

Subscribe to Decipher with Zaryab 👇

https://www.zaryabs.com/

𝐃𝐞𝐜𝐢𝐩𝐡𝐞𝐫 𝐰𝐢𝐭𝐡 𝐙𝐚𝐫𝐲𝐚𝐛 𝐧𝐨𝐰 𝐡𝐚𝐬 𝐢𝐭𝐬 𝐨𝐰𝐧 𝐇𝐎𝐌𝐄. 🏡

Decipher with Zaryab — Mon, 20 Feb 2023 06:30:26 +0000

Attention Developers, Smart Contract Ninjas, and Web3 Enthusiasts.

Excited to share with you all about the launch of my independent publication, Decipher with Zaryab.
Started on 20th June 2022, with a family of 2000+ subscribers on LinkedIn, Decipher with Zaryab has now found its own home at 𝘇𝗮𝗿𝘆𝗮𝗯𝘀.𝗰𝗼𝗺

Decipher with Zaryab is aimed at helping Web3 builders become better Smart Contract Developers with strong mental models around Web3 & Smart Contract Security.
The publication provides simplified and curated technical (and sometimes not-so-technical) content for some of the most complicated but interesting topics in Web3.
Additionally, this publication is designed to help Web3 enthusiasts become valuable Web3 contributors.

The Bigger Picture

With its curated and simplified technical (and sometimes non-technical) content, this publication aims to:

Help software developers easily start out with smart contract development.
Provide simplified content for some of the most complicated technical or non-technical topics in Web3.
Emphasize the significance and need for Smart Contract Security while developing smart contracts
Share well-evaluated mental models for writing better, optimized, and secure smart contracts.
Guide Web3 enthusiasts to become valuable Web3 contributors

If you are someone who:

Strives to be a better smart contract developer
Become a valuable contributor to the Web3 space
Understand the significance of having mental models for being productive as a Developer
Loves simplified, curated, and well-researched content that gives you the 'AHA' moments

𝐓𝐡𝐢𝐬 𝐩𝐮𝐛𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐢𝐬 𝐟𝐨𝐫 𝐘𝐎𝐔.

𝗔𝗹𝗽𝗵𝗮: 𝙰 𝚗𝚎𝚠 𝚊𝚛𝚝𝚒𝚌𝚕𝚎 𝚜𝚎𝚛𝚒𝚎𝚜 𝚒𝚜 𝚝𝚘 𝚋𝚎 𝚕𝚊𝚞𝚗𝚌𝚑𝚎𝚍 𝚝𝚘𝚖𝚘𝚛𝚛𝚘𝚠. 𝚂𝚝𝚊𝚢 𝚃𝚞𝚗𝚎𝚍 👀
𝐒𝐮𝐛𝐬𝐜𝐫𝐢𝐛𝐞 𝐓𝐨𝐝𝐚𝐲 to get access to the full archive of everything that's been published before and everything that's still to come. Your very own private library is at https://www.zaryabs.com/.

Yet another Re-entrancy attack - What's keeping us from being a better Smart Contract Developer?

Decipher with Zaryab — Mon, 10 Oct 2022 05:34:17 +0000

It's been 6 years, 3months, and 25 days since the infamous DAO hack that shook the entire web3 world.

The one where we witnessed more than 3.5 million Ether being stolen away due to a bug in the smart contract.

This hack introduced us to one of the most dangerous attacks, The Re-Entrancy attack, possible in a smart contract.

Since then there have been enormous improvements and attempts to mitigate the risk of introducing such attack vectors in smart contracts.

Automated testing tools started including warnings about re-entrancy bugs, smart contract auditors became particularly cautious with codes dealing with external calls, and loads of blogs as well as video content were created (and are still being made) explaining the re-entrancy attack.

However, if you have observed the exploits in the past few years, along with all other new attack vectors, re-entrancy exploits are still a major concern and can be seen as a considerable bug behind many smart contract exploits.

In fact, the latest re-entrancy exploit that I read about was just a few weeks ago when Stader’s NearX smart contract was exploited with the exact same very well-known re-entrancy bug & $830,000 were lost.

Well, this isn’t just about re-entrancy bugs in smart contracts and neither is the blog going to explain re-entrancy bugs ( not again ).

Re-entrancy attacks are just one of the many well-known attacks that the smart contract dev community is well aware of but we find traces of such bugs in smart contracts even today, which leads to incredibly massive exploits.

Now the question is — WHY?

==============================

Despite having enormous tools, libraries, and educational content around such common bugs and attack vectors in solidity, why do we still witness such well-known attacks time and again?

This is undoubtedly one of those broad or open-ended questions that might have multiple narratives or answers.

However, after being involved in multiple smart contract security audits now, interacting with quite a few smart contract devs, and being part of some really active smart contract developer communities, I came across 2 extremely simple but imperative reasons behind this.

Most importantly, these reasons revolve around the very basics of how we approach Smart Contract development and learn Solidity, especially in the initial stages.

**1. The “Security-is-NOT-my-job”** mindset

==============================================

It can unquestionably be stated that the majority of the developers in the web3 space believe contract development and smart contract security to be two different things, which is true, to some extent.

However, completely denying any correlation between these two things is probably a mistake.

The rationale behind this is the fact that, at the very heart of it, the process of smart contract development broadly includes 3 most significant steps:

Design & Development
Optimizations
Security Validations of the Contract

While we are quite well aware of the first two steps, we most often forget, or even worse, do not consider Security Validations to be part of the contract development procedure at all.

It’s concerning because even if we consider a basic fact about smart contracts, i.e., their immutable nature after on-chain deployment, we can quite clearly see the significance of adding security checks and validations as a mandatory step in the smart contract development process.

The fact that you cannot change a line of code in your contract even if you found a major bug just seconds after deployment, is daunting in itself.

Well, just in case you think you can always upgrade your smart contracts or upgradeable contracts are extremely secure, let me stop you right there. 🛑

Read about the Wormhole Proxy Bug and think again.

Upgradeable contracts can have bugs too. 🪲

What should you do?

In very simpler terms, consider security checks & validations as an imperative part of any smart contract you develop, and learn at least the basics of smart contract security if you haven’t already.

Once you consider this, you can no more rely on just writing test cases for your smart contracts.

Test scripts are undoubtedly helpful, however, they are more inclined towards ensuring the contract functions execute as intended while the security of a contract is much more than that.

Even as a smart contract developer, you should definitely be good with at least one of the following (actually more than just 1) security tools to validate the security of your contract:

Static analysis tools like Slither, Mythril, Mythx. These tools effectively help you identify any well-known smart contract bugs that you might have in your contract.
Fuzz Testing tools like Echidna or Harvey help identify potential exploit scenarios or contract execution failures by throwing random & unexpected data into your contract.
Scribble, which is an amazing runtime verification tool by ConsenSys that allows you to annotate a solidity smart contract with crucial properties.
While auditing complex & bulky smart contracts, the one thing you need the most is a visualization tool, and that’s exactly where Surya comes in. It provides an incredibly simplified version of all crucial details about a contract’s structure including call graphs, inheritance graphs, etc.
VS Code visual auditor extension is an extremely helpful tool that provides security-oriented syntax as well as semantic highlighting and quite a few other tools that make the secure development of contracts easier.

My favorites → Slither, Surya, VS Code visual auditor, and Echindna. 😎

**Why should you do it (If you can get contracts Audited)?**

Well, to begin with, no one will ever care about the security of your smart contracts more than you (and your team). The very first person responsible for the security of your code should be YOU.

Secondly, the smart contract audit industry has been (and still is) in a “ High Demand & Low Supply of good security auditors “ phase*.*

This basically means there are just a handful of extremely experienced auditors and relying on just a few of them won’t really be scalable enough for the web3 world to expand its boundaries exponentially.

Additionally, there is a huge line of projects waiting for their contracts to get audited, which is why, when it's your turn you need to be ready with the right set of contracts, adequate test cases, coverage reports, and most importantly, the crucial discussion points you might want to have with your security auditor.

However, you won’t really be capable of having any effectual discussion with smart contract security experts if you yourself don’t understand, at least, the basics of smart contract security.

The inclusion of the security validations step in your smart contract development journey allows you to filter out all the well-known bugs beforehand with the help of static analysis tools.

This allows security auditors to specifically concentrate on the more important potential threats of the contracts instead of identifying and reporting the ones that could be easily found with the tools mentioned above.

Therefore, performing your own security checks before an audit doesn’t just shorten the lengthy audit durations, it helps achieve an adequate & better result out of the whole procedure.

This is a concept that the Secureum community brilliantly defines as CARE (Comprehensive Audit Readiness Evaluation) which intends to prepare your contracts before an audit to ensure that the outcome from the security audit is comparatively better and effective.

It’s important to note that i*ncluding security as a part of your smart contract development process isn’t a substitution for an audit of your contract, but a preparation for an adequate security audit.*

2. Avoiding Mistakes & Experimentations with Solidity (and the lessons that come from them)

==============================================================================================

Alright, while the first point was for developers already familiar with solidity(and basics of smart contract security), this part is more inclined towards those starting out with learning solidity or the ones in the very early phases of smart contract development.

Here is a quick tip for you:

Along with learning and developing simple solidity smart contracts, don’t be scared of experimenting and making mistakes while learning solidity.

Since its inception Solidity or smart contract development, in general, has been incredibly interesting but daunting as well as difficult for many developers at the early stage because of some very obvious reasons:

The immutable nature of Smart Contracts and the idea of getting almost everything right in one single shot before on-chain deployment.
The open-source nature of smart contracts and the fact that every single line of code is accessible/readable by anyone.
The whole concept of programming and storing money within Smart Contracts and the security risks that come with it.
Solidity still being at a very nascent stage and the difficulties in keeping up with the rapidly changing/evolving language.

Now, the concerns and risks associated with making mistakes while developing a smart contract can’t be overlooked. However, these have an adverse effect on the journey toward learning smart contracts effectively.

With so much at stake, it becomes harder for developers to experiment with Solidity or make mistakes on their own.

The popular idea of “Not reinventing the wheel or trying something new, to avoid introducing new bugs in the contract” stops developers from exploring different concepts of solidity and thus limits their potential with smart contract development, as a whole.

In fact, it is now considered a lot safer to simply fork an already existing audited contract instead of writing one from scratch. While this definitely does minimize the risk of contracts having bugs in production, it does stop developers from dealing with all the complications one might(and should) go through while developing the same. And, therefore, keeps us from deep-diving into solidity concepts more often than not.

While simply following a blockchain development course or consuming online content on smart contracts might help you get started with any specific topic, it won’t let you dive in deep and learn the fundamentals. Not unless you get your hands dirty with the same.

Most importantly, not experimenting with Solidity smart contracts also keeps us from learning about the various kinds of security vulnerabilities a contract might have and the plethora of ways a contract can be broken.

For instance, going back to the re-entrancy example:

Every smart contract developer might have heard, read, or discussed the reentrancy attack vector, but how many of us actually went ahead and tried to experiment with the same on some dummy contract, just to understand what happens behind the scenes?

This is precisely where smart contract security-based war games or CTFs like Ethernaut or Damn Vulnerable Defi also play such a significant role in learning smart contract development and security. They allow you to directly interact with a contract directly, make mistakes and eventually figure out the vulnerabilities.

Now, there are definitely some smart contract developers who experiment with Solidity and smart contracts a lot and therefore are becoming the best in the industry (check the Underhand Solidity Contest winners or their Challange Submissions, for instance).

However, as I previously mentioned, for the web3 world to expand its boundaries and scale with utmost security measures, we cannot simply rely on a handful of experts in the space.

Instead, every smart contract developer should aspire to learn more and dive in deep by not simply learning the basics but experimenting, making mistakes, learning from them, and then sharing them with the community.

Because, quite similar to life in general, the best learnings in software development also comes from mistakes.

Mistakes or Learning Experiences every smart contract dev should have at least once:

If you are just starting out with Solidity, there are a bunch of mistakes/experiments you can (and should) do while learning.

Dropping off some of them from the top of my head.

Solidity 101 mistakes/learnings:

Using memory keyword instead of storage and then realizing you never really stored the crucial contract states permanently on the contract.
Relying on blog time stamps for random calculation and realizing how they can be manipulated by the miners is therefore a bad practice. More details are here.
Storing secret information on smart contract state variables with a private visibility modifier only to find out that nothing is private on a smart contract. Every state variable value can be seen by anyone. Read more about this in SWC-136
You will always believe that a contract with no payable function (or payable fallback function) will never receive any ether unless you learn how selfdestruct can forcefully fund such a contract with ETH.
Failing to provide required input validation in functions & realizing how this can lead to unwanted scenarios any invalid arguments can be passed without proper validation. ( SWC-123 )

Gas Optimization & Security mistakes/learnings :

5. Writing expensive for loops only to find out how this could lead to a block gas limit issue and fail the complete transaction

6. Violating check effects interaction patterns and realizing how this could lead to the classic Rentrancy attack.

7. Using delegate calls between two contracts with different storage layouts and realizing why storage layouts must be exactly similar for delegate calls to work.

It's extremely important to ensure storage layout between two contracts involved in a delegatecall() is exactly the same. Otherwise, this leads to storage collisions. Read more about storage collisions here.

8. Including inadequate access controls for imperative functions of the contract and realizing how this could lead to any bad actor executing transactions without approval. SWC-105 covers this topic quite adequately.

9. Trying to send ether from one contract to another using the transfer function only to find out that it always sends a hard-coded 2100 gas only. This will help you realize the significance of the .call.value(…)(“ ”) function which allows adjusting the gas to be sent with a transaction. Read more about why .call() might be better than transfer().

10. Realising how tricky it is to delete mappings values in struct or in general and learning the right way to do it.

11. Trying to swap Token A with Token B using Uniswap and being vulnerable to sandwich attacks. This might help you realize the dark side of transaction order dependencies and MEVs and the DARK Forest of Ethereum .

Mr. Walter White experimenting with Solidity

While these are just some examples, there are way more interesting topics in smart contract development, from basic solidity to advanced deep dives in EVM Opcodes, that one can learn and experiment with.

Wrapping it UP 😊

=================

Web3 has come a long way in a very short span of time, however, the security of smart contracts is still a major concern.

The two ideas discussed above aren’t gonna make it all sunshine and rainbows at one go. There is undoubtedly a lot more we need to do to make Web3 a safer place.

However, imagine a whole generation of developers that includes the two ideas mentioned above while learning or developing smart contracts, prioritizes learning the basics of security, experiments with Solidity, learn from their mistakes, and then shares those learnings with the community.

That will, slowly but surely, lead us to a much safer and more secure web3 world than what we have now.

All it takes is some commitment be to consistent, the will to learn more from mistakes and experiments, and the aspiration to be the better version of the smart contract developer that you already are.

About myself

============

Who am I? 🙋🏻‍♂️

𝙃𝙞, 𝙄 𝙖𝙢 𝙕𝙖𝙧𝙮𝙖𝙗 👋🏻

A Smart Contract Engineer and Dev Team Lead at Push Protocol.
I work on smart contracts development as well as security audits of smart contracts.

Drop a ‘HI’ and Get in Touch 🤝

My Socials |Follow my Weekly Newsletter |My Web3 Speech & Presentations

Does adding a PAYABLE keyword in Solidity actually save GAS?

Decipher with Zaryab — Mon, 20 Jun 2022 06:49:48 +0000

If you have been developing smart contracts using Solidity lately, chances are you might have come across the payable keyword.

This blog is specifically about the same where we decipher all its interesting and weird secrets. 😃

Quick Intro: Basics of the Payable Keyword

Out of all the wonderful things that a smart contract can do, storing your money(ETH) is one of them. Now in order to take receive ETH in a smart contract, Solidity language has got a specific keyword called payable.

A payable keyword, in very simpler terms, is a modifier in the solidity language that can be attached to any function. Once attached, this keyword allows the function to receive ether. In other words, while triggering a function with a payable keyword, you can send ether (msg.value) along with that transaction.

While this is all good, I came across an interesting caveat around the payable keyword while scrolling through Twitter a couple of months ago. It grabbed all my attention and I figured that an interesting (but really wired) scenario takes place whenever a payable modifier is attached to any function 👀.

Let’s take a quick look at this interestingly wired scenario:

In the image attached above, we have a very simple setter function that sets the uint256 variable state to 100. If you trigger this function, you will find that the transaction gas cost is somewhere around 43300.

Alright, now let’s look at a 2nd condition.

In the 2nd case, we have the exact same function that executes an exactly similar transaction of setting a state variable. However, the only difference here is an additional payable modifier attached to the function.

Quite interestingly if you look at the transaction gas cost for calling this function, it's around 43276 which is lower than the function with no payable keyword mentioned above.

Yes, you got that right.

Adding a simple payable keyword just reduced the amount of gas consumption in the function. 😃

The AHA Moment 💡💡

Alright, now it's time to understand — Why exactly does the payable modifier lower the Gas consumption?

A very simple answer to that question is:

Adding a payable keyword lowers the number of opcodes being executed, thus lowering the amount of gas consumption.

That’s weird, isn’t it? How does adding an extra modifier to a function lower down the number of opcodes instead of increasing it???

Well here’s some technical (and logical) explanation for it. 😃

As we already know, for a function to be capable of receiving ether, a payable modifier must be attached to it. While a function without any payable modifier shall never be able to receive any ether.
It must be noted that this is a strict rule in Solidity and therefore if you try to pass Ether while calling a non-payable function, it will simply revert.
Therefore in the case of Non-Payable functions, there are additional opcodes that are executed while calling a non-payable function which ensures that the function shall only be executed if the ether (msg.value) is sent along with the transaction is exactly equal to ZERO.
However, the same is not true for Payable function. Payable functions allow users to pass in both non-zero or zero ether values while calling the function.
This basically means that even if zero ether (msg.value == 0) is sent while calling a payable function, the transaction is not reverted. Hence, there is no need to explicitly check the msg.value in the case of Payable functions.

In a Nutshell 🥜

In case of Non-Payable Functions:

a. Additional checks are included to ensure that no ether value is passed while calling the function.

b. These checks increase the number of opcodes being executed.

c. The increased number of opcodes ultimately results in higher gas usage.

In the case of Payable functions:

a. No additional checks are required since the function can accept both zero or non-zero values of ether.

b. No additional checks means no additional opcodes being executed.

c. Lower opcodes in execution means lower consumption of gas.

My TWO CENTS 🪙🪙
Does all of the above-mentioned details, mean we should use PAYABLE Functions to save gas?

Well, that could be a discussion.

Gas optimization is undoubtedly something that every smart contract wizard dreams of in their contracts.

However, an imperative question is:

While saving gas is important, it’s not really a good idea to compromise on the intended behavior of the function, minimizing the use of necessary state changes, or using inadequate tactics just to save a few extra amounts of gas. In other words, if a function has nothing to do with receiving ether, then it should not really have any payable keyword attached to it, even if that saves you some gas.

Therefore, I firmly believe that adding an unnecessary payable keyword in a function just to save gas is probably a bad decision. The above-mentioned scenario of reduction in gas while adding the payable keyword is just a wired solidity language design that is not at all effective.

About myself

Who am I? 🙋🏻‍♂️
𝙃𝙞, 𝙄 𝙖𝙢 𝙕𝙖𝙧𝙮𝙖𝙗 👋🏻
I am a proficient Blockchain and Smart Contract Engineer with a vision of Decentralizing and Securing the traditional Web with Web3. Mostly work on Smart Contracts with significant experience in both Development and Smart Contract Security.

What I Do 🧑🏼‍💻
I write secure and optimized Smart Contracts
I perform security audits on smart contracts and enhance the overall security of smart contracts on EVM chains
I write and speak about Web3 and Smart Contracts & contribute my part towards expanding the boundaries for Web3.

Drop a ‘HI’ and Get in Touch 🤝
Linkedin. | Twitter. | Github | Subscribe to My Weekly Newsletter | Invite me for Web3 Events

Solidity Guide: Behind the Scenes of PUBLIC and EXTERNAL Visibility of Solidity

Decipher with Zaryab — Tue, 27 Jul 2021 14:42:56 +0000

✩ 🎀 ---𝑨𝒏 𝑰𝒏𝒕𝒆𝒓𝒆𝒔𝒕𝒊𝒏𝒈 𝑭𝑨𝑪𝑻 𝒆𝒗𝒆𝒓𝒚 𝑺𝒎𝒂𝒓𝒕 𝑪𝒐𝒏𝒕𝒓𝒂𝒄𝒕 𝑫𝒆𝒗𝒆𝒍𝒐𝒑𝒆𝒓 𝑴𝑼𝑺𝑻 𝑲𝑵𝑶𝑾--- 🎀 ✩

When it comes to 𝐏𝐮𝐛𝐥𝐢𝐜 & 𝐄𝐱𝐭𝐞𝐫𝐧𝐚𝐥 visibility keywords,

𝘏𝘦𝘳𝘦 𝘪𝘴 𝘸𝘩𝘢𝘵 M𝘰𝘴𝘵 𝘰𝘧 𝘶𝘴 A𝘭𝘳𝘦𝘢𝘥𝘺 K𝘯𝘰𝘸:
𝐏𝐮𝐛𝐥𝐢𝐜 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧: Can be called from everywhere, internally as well as from outside the Contract

𝐄𝐱𝐭𝐞𝐫𝐧𝐚𝐥 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧: Can only be called from outside the contract and not accessible from within the contract.

𝘏𝘦𝘳𝘦 𝘪𝘴 𝘸𝘩𝘢𝘵 S𝘰𝘮𝘦 𝘰𝘧 𝘶𝘴 M𝘪𝘨𝘩𝘵 K𝘯𝘰𝘸:

𝐏𝐮𝐛𝐥𝐢𝐜 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧: Leads to Higher GAS COSTS

𝐄𝐱𝐭𝐞𝐫𝐧𝐚𝐥 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧: Costs Comparatively Lower GAS

𝑵𝒐𝒘, 𝑯𝒆𝒓𝒆 𝒊𝒔 𝒘𝒉𝒂𝒕 𝑴𝒐𝒔𝒕 𝒐𝒇 𝒖𝒔 𝑴𝒊𝒈𝒉𝒕 𝑵𝑶𝑻 𝑲𝑵𝑶𝑾:

𝐖𝐡𝐲 𝐄𝐱𝐚𝐜𝐭𝐥𝐲 𝐝𝐨𝐞𝐬 𝐏𝐔𝐁𝐋𝐈𝐂 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐬 𝐂𝐎𝐒𝐓𝐒 𝐦𝐨𝐫𝐞 𝐆𝐚𝐬 𝐭𝐡𝐚𝐧 𝐄𝐗𝐓𝐄𝐑𝐍𝐀𝐋 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐬?
In the case of PUBLIC Functions, arguments of the Functions are copied to 𝐌𝐄𝐌𝐎𝐑𝐘.
While on the other hand, Functions with External visibility can directly read arguments from 𝐂𝐀𝐋𝐋𝐃𝐀𝐓𝐀.

𝙎𝙞𝙣𝙘𝙚 𝘾𝘼𝙇𝙇𝘿𝘼𝙏𝘼 𝙞𝙨 𝘾𝙃𝙀𝘼𝙋𝙀𝙍 𝙩𝙝𝙖𝙣 𝙈𝙀𝙈𝙊𝙍𝙔, 𝙀𝙭𝙩𝙚𝙧𝙣𝙖𝙡 𝙁𝙪𝙣𝙘𝙩𝙞𝙤𝙣𝙨 𝙧𝙚𝙨𝙪𝙡𝙩 𝙞𝙣 𝙖 𝙡𝙤𝙬𝙚𝙧 𝙀𝙭𝙚𝙘𝙪𝙩𝙞𝙤𝙣 𝘾𝙤𝙨𝙩(𝙂𝙖𝙨) 𝙩𝙝𝙖𝙣 𝙋𝙐𝘽𝙇𝙄𝘾 𝙁𝙪𝙣𝙘𝙩𝙞𝙤𝙣𝙨.

𝘈𝘳𝘦 𝘺𝘰𝘶 𝘤𝘶𝘳𝘪𝘰𝘶𝘴 𝘢𝘣𝘰𝘶𝘵 𝘸𝘩𝘺 𝘗𝘜𝘉𝘓𝘐𝘊 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯𝘴 𝘤𝘰𝘱𝘺 𝘢𝘳𝘨𝘶𝘮𝘦𝘯𝘵𝘴 𝘵𝘰 𝘔𝘌𝘔𝘖𝘙𝘠 𝘸𝘩𝘪𝘭𝘦 𝘌𝘹𝘵𝘦𝘳𝘯𝘢𝘭 𝘍𝘶𝘯𝘤𝘵𝘪𝘰𝘯𝘴 𝘥𝘰𝘯'𝘵?

PUBLIC Functions can be called from outside as well as within the contract(Internal Calls). And internal calls are executed via code JUMP as array arguments are passed internally by Pointers to Memory.
Hence, when the compiler generates OPCODES for an internal function, the function expects its arguments to be located in Memory itself.

However, this is not at all the case in EXTERNAL functions. They don't care about Internal Calls at all and thus end up saving some gas.
Don't forget to COMMENT and Share your IDEAS. 𝗟𝗲𝘁'𝘀 𝗟𝗲𝗮𝗿𝗻 𝗮𝗻𝗱 𝗚𝗿𝗼𝘄 𝗧𝗼𝗴𝗲𝘁𝗵𝗲𝗿.

Solidity Security: The Significance of CHECK-EFFECTS-INTERACTION Pattern in Smart Contracts

Decipher with Zaryab — Tue, 27 Jul 2021 14:30:05 +0000

𝘛𝘰 𝘢𝘭𝘭 𝘵𝘩𝘦 𝘚𝘔𝘈𝘙𝘛 𝘊𝘰𝘯𝘵𝘳𝘢𝘤𝘵 𝘋𝘦𝘷𝘴 𝘰𝘶𝘵 𝘵𝘩𝘦𝘳𝘦, 📢
⚠️ 𝙉𝙀𝙑𝙀𝙍 𝙑𝙄𝙊𝙇𝘼𝙏𝙀 𝙏𝙃𝙀 𝘾𝙃𝙀𝘾𝙆-𝙀𝙁𝙁𝙀𝘾𝙏𝙎-𝙄𝙉𝙏𝙀𝙍𝘼𝘾𝙏𝙄𝙊𝙉 𝙋𝘼𝙏𝙏𝙀𝙍𝙉 ⚠️

Building a secure smart contract does require adhering to the Best Practices.
And one of the most crucial practices to keep in mind is the 𝐂𝐇𝐄𝐂𝐊 𝐄𝐅𝐅𝐄𝐂𝐓𝐒 𝐈𝐍𝐓𝐄𝐑𝐀𝐂𝐓𝐈𝐎𝐍 𝐏𝐚𝐭𝐭𝐞𝐫𝐧 while making External Calls.

𝐖𝐇𝐀𝐓 𝐞𝐱𝐚𝐜𝐭𝐥𝐲 𝐝𝐨𝐞𝐬 𝐢𝐭 𝐦𝐞𝐚𝐧?
In simple terms, it means that while designing a function in solidity, any state modification in the function must happen before an external call is made.

𝐖𝐇𝐘 𝐔𝐬𝐞 𝐭𝐡𝐢𝐬 𝐏𝐚𝐭𝐭𝐞𝐫𝐧?
Remember the DAO Hack of 2016 where the attacker drained 3.6 million ETH?
Well, one of the Imperative reasons behind that hack was the Violation of Check-Effects-Interaction patterns in function code.

𝙒𝙝𝙮 𝙗𝙚 𝙘𝙖𝙧𝙚𝙛𝙪𝙡 𝙬𝙝𝙚𝙣 𝙀𝙭𝙚𝙘𝙪𝙩𝙞𝙣𝙜 𝙀𝙭𝙩𝙚𝙧𝙣𝙖𝙡 𝘾𝙖𝙡𝙡𝙨?
An external call technically shifts the control over execution to another contract or a Third Party. This allows the Third-party contract to leverage from the fact that the Contract State didn't change before the external call.

It leads to an extremely undesirable scenario where a malicious actor can re-enter the contract and disturb the expected flow. Thus, leading to a potential Re-entrancy Scenario.

𝐇𝐎𝐖 𝐝𝐨𝐞𝐬 𝐭𝐡𝐢𝐬 𝐏𝐚𝐭𝐭𝐞𝐫𝐧 𝐒𝐞𝐜𝐮𝐫𝐞 𝐂𝐨𝐧𝐭𝐫𝐚𝐜𝐭𝐬?
Let's understand this by breaking down the 3 imperative steps in this pattern. (𝘔𝘰𝘴𝘵 𝘪𝘮𝘱𝘰𝘳𝘵𝘢𝘯𝘵𝘭𝘺, 𝘐𝘯 𝘵𝘩𝘦 𝘦𝘹𝘢𝘤𝘵 𝘰𝘳𝘥𝘦𝘳)

𝗖𝗛𝗘𝗖𝗞
The first part is to implement a 𝘾𝙃𝙀𝘾𝙆 or input validations(𝘸𝘪𝘵𝘩 𝘳𝘦𝘲𝘶𝘪𝘳𝘦 𝘰𝘳 𝘢𝘴𝘴𝘦𝘳𝘵 𝘴𝘵𝘢𝘵𝘦𝘮𝘦𝘯𝘵𝘴) to ensure that arguments passed are valid and the function is ready to be executed.
𝗘𝗙𝗙𝗘𝗖𝗧𝗦
Resolve all the 𝙀𝙁𝙁𝙀𝘾𝙏𝙎 to the State of the Contract. This part involves optimistically modifying the State Variables to a valid state in the protocol.
𝗜𝗡𝗧𝗘𝗥𝗔𝗖𝗧𝗜𝗢𝗡
The final step should include any 𝙄𝙉𝙏𝙀𝙍𝘼𝘾𝙏𝙄𝙊𝙉 with other external contracts. This is the step that should include any external call that is being made from the function, at the very end of the function.

✧ 🎀 𝗜𝗻 𝗮 𝗡𝗨𝗧𝗦𝗛𝗘𝗟𝗟 🎀 ✧
External calls must be the very last thing that you should do in a function. 𝘼𝙣𝙮 𝙨𝙩𝙖𝙩𝙚 𝙫𝙖𝙧𝙞𝙖𝙗𝙡𝙚 𝙢𝙤𝙙𝙞𝙛𝙞𝙘𝙖𝙩𝙞𝙤𝙣 𝙢𝙪𝙨𝙩 𝙝𝙖𝙥𝙥𝙚𝙣 𝙗𝙚𝙛𝙤𝙧𝙚 𝙖𝙣 𝙚𝙭𝙩𝙚𝙧𝙣𝙖𝙡 𝙘𝙖𝙡𝙡 𝙞𝙨 𝙚𝙭𝙚𝙘𝙪𝙩𝙚𝙙 𝙞𝙣 𝙤𝙧𝙙𝙚𝙧 𝙩𝙤 𝙖𝙫𝙤𝙞𝙙 𝙖 𝙧𝙚-𝙚𝙣𝙩𝙧𝙖𝙣𝙘𝙮 𝙨𝙘𝙚𝙣𝙖𝙧𝙞𝙤.

Moreover, even if attackers try to re-enter a function that follows the CHECK-EFFECTS-INTERACTION pattern, they cannot really abuse the State of the contract as it has been already modified before the external call is made.

Forem: Decipher with Zaryab

EVM Part1: The ABCs of Ethereum Virtual Machine

EVM in 100 words

Let's start Deciphering EVM

EVM as a Virtual Machine...

EVM as a State Machine...

Well, why is this important?

EVM as a Quasi-Turing Complete Machine...

Understanding the crucial components of EVM & Ethereum

Quick Review of the basics

1. Accounts in Ethereum

2. The Concept of GAS

3. Transactions in Ethereum

EVM Architecture and its Components

Storage

Memory

Calldata:

Stack

Program Counter

How does EVM work?

EVM working mechanism

Wrapping it up

Further Reading

Subscribe to Decipher with Zaryab 👇

𝐃𝐞𝐜𝐢𝐩𝐡𝐞𝐫 𝐰𝐢𝐭𝐡 𝐙𝐚𝐫𝐲𝐚𝐛 𝐧𝐨𝐰 𝐡𝐚𝐬 𝐢𝐭𝐬 𝐨𝐰𝐧 𝐇𝐎𝐌𝐄. 🏡

The Bigger Picture

Yet another Re-entrancy attack - What's keeping us from being a better Smart Contract Developer?

Now the question is — WHY?

1. The “Security-is-NOT-my-job” mindset

What should you do?

Why should you do it (If you can get contracts Audited)?

2. Avoiding Mistakes & Experimentations with Solidity (and the lessons that come from them)

Mistakes or Learning Experiences every smart contract dev should have at least once:

Wrapping it UP 😊

About myself

Who am I? 🙋🏻‍♂️

Drop a ‘HI’ and Get in Touch 🤝

Does adding a PAYABLE keyword in Solidity actually save GAS?

Quick Intro: Basics of the Payable Keyword

The AHA Moment 💡💡

In a Nutshell 🥜

About myself

Solidity Guide: Behind the Scenes of PUBLIC and EXTERNAL Visibility of Solidity

Solidity Security: The Significance of CHECK-EFFECTS-INTERACTION Pattern in Smart Contracts

**1. The “Security-is-NOT-my-job”** mindset

**Why should you do it (If you can get contracts Audited)?**