DEV Community: Akim B. (mousticke.eth)

Ethereum UX: Account Abstraction (AA)

Akim B. (mousticke.eth) — Wed, 07 Jan 2026 11:59:08 +0000

Introduction

If you have been in the Web3 community for a while, you might have heard about Account Abstraction, or if you are just a Web2 user, it might have been difficult to step into a blockchain transaction with Ethereum since there are some concepts like gas fees, stipends, signatures, and so on. For all of us, Ethereum has brought an amazing EIP (4773) which improves significantly the UX for interacting with the protocol.

Account abstraction makes Ethereum more user-friendly, secure, and ready for mass adoption by institutional and regular users. I have been playing around for a while, and I’d like to share with you what Account abstraction is, my insights, and what I’ve learned so far. Whether you're a developer, investor, or just crypto-curious, understanding AA could reshape how you think about wallets and transactions.

Let's start with the basics...

If you want to see a minimal implementation, please check a sample minimal account abstraction in my github repo: https://github.com/Mousticke/eth-erc4337-minimal-account-abstraction/blob/main/src/ethereum/MinimalAccount.sol

What is Account Abstraction?

In the Ethereum blockchain, there are two main types of accounts:

Externally Owned Accounts (EOAs): These are your standard wallets, controlled solely by a private key. They can't contain any EVM (Ethereum Virtual Machine) code. They're simple and straightforward.
Smart Contract Accounts: These hold executable code and are governed by that code's logic, not a single private key.

The problem with EOAs? They're a bit hard to hand on by the common user and risky:

Once you sign a transaction or lose your key, there's no recovery mechanism. One mistake, and your funds could be gone forever.
They rely on ECDSA signatures, which aren't quantum-resistant.
This setup isn't ideal for mainstream users who expect seamless, forgiving experiences like in Web2 apps without caring too much about signature, gas fee, secret keys. Plus, there is no sponsors to pay fees on our behalf.

So what is the alternative ? Here comes the Account Abstraction.

It blurs the lines between EOAs and contracts, turning every account into a programmable smart contract. You define custom logic, validation rules, and flows, making accounts smarter, safer, and more flexible.

Why Do We Need AA?

Blockchain's biggest barrier to adoption is poor UX. AA solves this by enabling:

Customizable security: Add multi-factor auth, social recovery, or spending limits without relying on a single key.
Quantum-proofing: Swap out ECDSA for more secure schemes.
Seamless integration: Make crypto feel like everyday apps, reducing friction for non-technical users.

In short, AA paves the way for billions of users by making blockchain as intuitive as logging into your bank account.

Key Components of AA (ERC-4337 Standard)

ERC-4337 enables account abstraction without requiring changes to Ethereum's consensus layer. It introduces a parallel system using an alternative mempool, allowing smart contract wallets (programmable accounts) to replace or augment traditional Externally Owned Accounts (EOAs).

Here's the core system

1. UserOperations (UserOps)

These are ABI-encoded structures that represent user intents (send ETH or swap tokens). It's not a real Ethereum transaction but a structured data packet sent to a dedicated mempool. Which means they can't access block-level info (like timestamps) to prevent manipulation, and they only interact with the sender's data. Ops flow through a decentralized peer-to-peer alt-mempool, avoiding centralized bottlenecks.

Main fields:

sender : The smart contract account address.
nonce : Prevents replays.
initCode : (Optional) Code to deploy the account if it doesn't exist (using a Factory).
callData : The action to execute (transfer tokens).
callGasLimit, verificationGasLimit, preVerificationGas : Gas estimates.
maxFeePerGas, maxPriorityFeePerGas : Like regular txs. Fees you put on MM for example.
paymasterAndData : (Optional) Paymaster info for sponsorship.
signature : Custom signature (validated by the account).

Users/wallets create and sign UserOps, then broadcast them to the alt-mempool.

2. Alt-mempool

A peer-to-peer network separate from the main Ethereum mempool. UserOps propagate here, keeping the system decentralized (no central relayer required).

3. Bundler

Think of this as a specialized node. It monitors the UserOp mempool (alt-mempool), bundles multiple ops together, simulates them to calculate gas fees, and submits them to the EntryPoint via handleOps(). Fees can be paid by the account itself or a Paymaster. Bundlers get reimbursed for gas (plus tips) from accounts or paymasters.

4. EntryPoint

A global smart contract deployed one per chain that handles everything. The entrypoint receives bundled UserOps from bundlers and runs in two phases:

Verification Phase : Checks signatures, nonces, and custom rules by calling account. validateUserOp() (and paymaster if used) to check signature, nonce, and rules.
Execution Phase: Actually performs the ops on-chain which can handles staking, deposits, withdraw, and post ops logic.

5. Smart Account (user’s wallet)

The user's programmable account. Must implement:

validateUserOp() : Custom logic (ECDSA, multisig, session keys).
execute() : Perform the action.

6. Paymaster

A contract that sponsors transactions. It can cover gas fees on behalf of users, enabling gasless experiences.

7. Aggregator

For efficiency, accounts can batch signatures using an aggregator, compressing multiple sigs into one to save on gas and data.

8. Factory

Deploys the account via CREATE2 if initCode is provided.

Transaction flow

User creates/signs a UserOp.
Broadcast to alt-mempool.
Bundler collects, simulates, bundles, and calls EntryPoint.handleOps(bundle) .
EntryPoint verifies ( account + paymaster ) → executes → refunds/reimburses.
On-chain as one tx from the bundler.

Real-World Use Cases

AA isn't theoretical. It's powering innovative apps today. Here are a couple of examples

Pay Gas Fees in Any ERC-20 Token

No more scrambling for ETH! Imagine a merchant checkout: A user places a $100 order in USDC. The Paymaster covers the gas fee (say, 1 USDC from the user), converts it to ETH, and pays the network. The merchant receives the full 100 USDC. This abstracts away crypto's "gas hassle," making it feel like a regular online purchase.

Connect your wallet using Google, Apple ID, or even biometrics. No seed phrases or manual gas settings required. For beginners, this eliminates the "What’s a private key?" confusion, turning crypto into a plug-and-play experience.

Signing with Google or Apple ID (Passkeys)

But I have mentioned earlier that you can even use your google account or apple id as a wallet by signing transaction directly by your fingerprint or face ID. That’s one of the most exciting feature turning a Web3 hassle into a Web2-like logins for blockchain wallets. You can now "connect" or sign transactions using your Google account, Apple ID, or device biometrics (Face ID/Touch ID). no seed phrases, no private keys to manage, and no confusing gas settings. This is powered by passkeys (based on the WebAuthn standard), turning your smart contract wallet into something that feels like logging into any modern app.

Instead of ECDSA signatures from a private key, the wallet can validate any signature scheme, including passkeys.

Passkeys are:

Cryptographic credentials created and stored securely on your device (in Apple's Secure Enclave or Google's Password Manager).
Unlocked via biometrics (Face ID, fingerprint) or PIN.
Synced securely across devices via iCloud or Google.
Phishing-resistant and passwordless.

When you sign in with Google or Apple ID

It's actually creating/registering a passkey tied to your account.
The private key never leaves your device. It's generated and stored in hardware-secured areas.
The public key is registered on-chain with your smart wallet.

Account abstraction flow with Apple ID / Google

In your DApp, choose to sign in with Google or Apple. Your device uses WebAuthn API to generate a passkey (private/public key pair). Then the smart contract account is deployed (via a Factory in ERC-4337). The public key is stored in the account as the owner.

Then it’s time to create a transaction. You may want to send tokens or swap on the DApp. The wallet creates a UserOperation (your intent). Instead of signing with a private key, it prompts your device by requiring your biometric ID. WebAuthn signs the UserOp hash using the passkey (on-device, secure). The signature (P256 curve) is sent with the UserOp to a Bundler. (There is an extra step because P256 is different from the secp256k1. We will talk later about it).

Ultimately, the EntryPoint contract calls your smart wallet's validateUserOp(), verifies the signature and process to the operations like we described above.

Hold on mate ! The private key from a Google or Apple passkey never leaves the device (it's stored in the secure enclave/hardware module and can't be exported). So, Solidity code on-chain can't access or use it directly to sign anything ? And my friend your right !

Instead, the device uses WebAuthn to sign the message/hash with the passkey private key on the client side (off-chain). Then, the smart contract wallet verifies the signature using the corresponding public key which is stored on-chain. This is possible because Account Abstraction (ERC-4337) allows custom signature validation in the validateUserOp function.

Passkeys use the secp256r1 elliptic curve (also called P-256), not Ethereum's native secp256k1. But Ethereum has a built-in precompile for secp256k1 (via ecrecover), but not for P-256. So the verification requires a custom Solidity code to implement P-256 signature checking. This is expensive in gas. Check this out here : https://github.com/daimo-eth/p256-verifier/blob/master/src/P256Verifier.sol

Benefits are huge

No Seed Phrases: Ever. Recovery via iCloud/Google sync.
Gasless and Seamless: Paymasters can sponsor fees. You pay in USDC or nothing at all.
Secure: Keys in hardware, biometrics required, phishing-resistant.
Cross-Device: Lose your phone? Recover via another device signed into the same Google/Apple account.
Mass Adoption Ready: Feels exactly like logging into Gmail

Final thought

AA is already live on networks like Ethereum (via ERC-4337) and is being adopted. It's a cornerstone for scaling Web3 to the masses.

Understand the ZK Rollups

Akim B. (mousticke.eth) — Sat, 28 Oct 2023 21:56:52 +0000

Abstract

Imagine you have a Christmas gift to send to your family for the next Christmas and you have 4 gifts to send. One option is to send 4 different parcels to your family location. But it will be expensive and/or maybe some delays between each parcels. What if you send all the gifts at once in a single parcel containing each parcel? It will be less expensive and you save time and effort.
If you understand this small abstract, you'll understand what ZK rollups are and how they scale Ethereum network. Let's dive into them.

What is a Rollup.

If you refer to the Ethereum website, the definition is a bit hard to understand. I'll try to make it easier for you to explain as I dedicate this article to everybody with or without deep knowledge about the blockchain.
On the Ethereum blockchain, there are two things that can be posted on the blockchain. Transactions or Data.
A transaction is just the action to send ETH between two addresses.
A data can be stored on the Ethereum blockchain which makes it different from Bitcoin. A data can be anything. A simple text or a compiled code which are smart-contracts.
A rollup is a solution that performs a bunch or a bundle of transactions execution outside the mainnet and post the final transactions data to the mainnet.

Blocks in Ethereum

But first, you need to know that the block size isn't dynamic and unlimited in space. A block has a target of 15 million gas but depending on the networks demand, the block can increase to 30 million of gas. The total amount of gas expended by all transactions in the block must be less than the block gas limit. This is important because it ensures that blocks can’t be arbitrarily large. If blocks could be arbitrarily large, then less performant full nodes would gradually stop being able to keep up with the network due to space and speed requirements. A block is proposed every 12 seconds.
Based on this statement, let's say that there are 100,000 transactions and every block can process 100 transactions. The priority of the validated blocks go for people who add a tip in the gas fee for the validator. Others transactions have to wait. Depending on the demand of the networks, a transaction can be delayed and slow. A fee can be more and more expensive so each transactions have to be more and more important to be included in priority.
As mentioned earlier, the Ethereum blockchain can handle data. We can perform some transactions in this data.
So what if one data can perform 10 transactions and we can process only 100 transactions or data in one block to the blockchain? We have scaled the Ethereum blockchain to 1000 transactions per block. This is what rollups are about.

A single transaction

A simple Ethereum transaction (to send ETH) takes around 110 bytes. An ETH transfer on a rollup, however, takes only 12 bytes

Parameter	Ethereum	Rollup
Nonce	3	0
Gasprice	8	0.5
Gas	3	0.5
To	21	4
Value	9	3
Signature	2 + 33 +33 (68)	0.5
From	0	4
Total	112	12

How does a rollup work?

There is a smart contract on-chain which maintains the Merkle root of the state of the rollup. Anyone can publish a batch of transactions in a highly compressed form together with the previous state root and the new state root. The contract checks that the previous state root in the batch matches its current state root. If it does, it switches the state root to the new state root.
How to do know that the post-state roots in the batches are correct? The answer to this question is the main key of the solution proposed by the two families of rollup.

ZKsnarks Rollup

If you break down the acronym Zero Knowledge Succinct Non-Interactive Argument of Knowledge you have:
Zero Knowledge: No need to see the transactions data
Succinct: Short
Non-Interactive: No need to deal with the people who verify the work
Argument of Knowledge: Proof they provided that these transactions are good.
ZKSnark or Zero Knowledge Succinct Non-Interactive Argument of Knowledge runs a computation off chain and submit a validity proof on chain.
A validity proof is the result of a computation and mathematically verified to be not fraudulent. So this rollup needs more computation and time to be submitted to the network. (If you want to know more about Zero Knowledge, you can find the paper on the internet. It a concept invented in 1985 by Silvio Micali).
Then, once this validity proof is created, it will be submitted to the blockchain and approved to the Layer 1. This computation off chain means that the Ethereum blockchain has offloaded some work to the ZKSnark checker which is what a Layer 2 solution does. Unlikely to the Optimistic rollup, once the validity proof is submitted, the funds are directly available to the user. However, it's more difficult to create an EVM compatible ZK rollup. You can check ZK-Sync for this part.

Optimistic Rollup

This rollup is used by Arbitrum and Optimism because it's easier to implement. These L2 use a single centralised node called a Sequencer that submits the transactions.
It assumes that the transactions are good and valid by default. Instead of submitting a validity proof, the optimistic rollups submit a fraud proof but only if the transactions are challenged by the networks.
So this rollup assumes that everybody tell the truth. They dont do some computation like ZKSnarks do. However, what they do post, is fact check-able by the network. Because transactions involves money, there will be always some people checking the transactions. So if the network attests that a transaction is fraudulent, the transaction is reverted and the block validator is slashed. That's why in Optimitic rollup, you have a challenge period where the nodes can use a verifier (contract) to check the transactions. The challenge period can last for one week and during this time, the user cannot withdraw the funds. The other drawback of this rollup is the sequencer. It's centralised and prone to censorship.

Recap

In short, here a table comparing the two solutions:

Rollup property/Rollup solution	Optimistic	ZK Rollup
Fixed gas cost per batch	40,000 (a lightweight transaction that mainly just changes the value of the state root)	~500,000 (verification of a ZK-SNARK is quite computationally intensive)
Withdrawal period	1 week (withdrawals need to be delayed to give time for someone to publish a fraud proof and cancel the withdrawal if it is fraudulent)	Very fast (just wait for the next batch)
Complexity of technology	Low	High (ZKSnarks are mathematically complex technology)

Setting up an Ethereum Node (Execution Client)

Akim B. (mousticke.eth) — Sat, 10 Sep 2022 17:55:33 +0000

Caveat

It's still possible to run the execution client (layer 1) alone but after the Merge in the upcoming days, we need to run the execution client and consensus client to be able to access to the Ethereum network. In this article, I will cover the execution layer only.
The execution client listens to new transactions and executes them in the EVM (state machine) and holds the database of Ethereum network.

See the overview of execution client in Etherenodes
See the execution layer specification in Ethereum Repo

This article covers the node running from the source code or from the package in Ubuntu.

Abstract
Prerequisites
Node Types
Why should I run a node
Installation
Create the chaindata folder
Run the node
Interacting with Geth
Run the node (dev mode / contributor)
Next Step
Conclusion

Abstract

Little abstract before jumping in our journey with the Ethereum node.
Ethereum is a distributed decentralised network of computers. Each computer in this network is running a software that contains the history of the blockchain, the ability to validate/mine blocks and transactions.
In order to be a node in the Ethereum network, a client needs to download this software that implements the specification of the yellow paper to be able to communicate within the network.
In this article, the client I'll be choosing is Geth. It's the most popular client and backed by the Ethereum Community.

Prerequisites

You can run a node on any computers but it's worth to consider running your Ethereum node in a dedicated hardware to minimise the performance issues.
Make sure to have a stable internet connection. Even though you can go offline, your node goes inactive until you come back and download the latest changes from other nodes automatically.
You can buy hardware from a vendor and have a plug and play node or you can build your own. The last option is cheaper and funnier.

Hardware

Minimum:

8GB RAM (16GB for a validator);

2TB SSD for write speeds (12TB for Archive node);

Recommended:

CPU with a benchmark score of 6667+

16GB RAM (32GB for a validator);

Unlimited High speed internet bandwidth;

Node types

In order to run your node, you need to be aware of the node types. Each node type consumes data differently. There are 3 node type:

Light Node
Full Node
Archive Node

Light Node

Instead of downloading the entire blockchain, you can download a shallow copy of the data containing only the block headers. A light node relies on a full node to get more data. A light node can also verify the data and participate to the network. The drawback is that you cannot participate in a consensus, you cannot be a miner nor a validator.

Full Node

The full node stores all block data not since the Genesis. This is periodically pruned and get only the most recent 128 blocks. A full node can:

Participate in a consensus;
Validate blocks;
Verify the states;
Serve the network and provide data on request;

The drawback is that you cannot query data at block #1,000,000 because you don't have the entire history. Only the 128 last blocks.

Archive Node

The archive node stores the historical states since the Genesis. Basically, if you want the query data since the first block, you can with the archive node.

Why should I run a node?

If you really believe in Ethereum, and decentralised crypto currency, you should consider running a node.

For me

You can use Ethereum privately and verify the data yourself. "Don't trust, verify" is a popular Blockchain mantra.

Don't rely on another node
Use an Ethereum wallet within the node and use DApps more securely and privately without leaking your address and balance to another node.
Build your custom RPC endpoint
Stake your ETH and earn rewards (be a validator with 32ETH)
Allow wallets provider like Metamask to use your node

For the Network

Enforce the consensus rules
Social recovery in case of massive attack
More diverse and robust network and provide a censorship-resistant ecosystem

Installation

Golang

In order to download the source code, you need to install git command.
geth is a software coded in golang. You need to install Go before.

If you are on Windows and have Chocolatey installed, you can run (Admin mode) these commands:



choco install git
choco install golang
choco install mingw

(If you run these commands, you'll need to close your terminal and open up a new one)

Then you can follow one of these steps in order to have Geth installed:

Download Source code (Windows) or
Download Source Code (Linux) or
Download the Package (Ubuntu)

Download Source code (Windows)

In order to download the source code, you can copy and paste these commands:



mkdir src\github.com\ethereum
git clone git@github.com:ethereum/go-ethereum.git src\github.com\ethereum\go-ethereum
mkdir src\github.com\ethereum\go-ethereum

You should have this output:

You can now build the project from the binaries



go get -u -v golang.org/x/net/context
go install -v ./cmd/...

Download Source Code (Linux)

If you have Linux (or MacOS), it's slightly different. You can just run this command:



go get -d github.com/ethereum/go-ethereum

If you have an existing Geth client, you can update with this command



go get -u github.com/ethereum/go-ethereum

Download the Package (Ubuntu)

You need to add the launchpad repository



sudo add-apt-repository -y ppa:ethereum/ethereum

Then you can download the stable version of go-ethereum



sudo apt-get update
sudo apt-get install ethereum

If you have an existing geth installation, you can get the latest version with the following commands:



sudo apt-get update
sudo apt-get install ethereum
sudo apt-get upgrade geth

Create the chaindata folder

In order to store the chain data, you need to create a folder somewhere in your system. I usually create the chain data at the same level of the binary (in my case)



mkdir -p ./chain/data

Run the node

Now you are ready for running the node.



geth console --syncmode full --networkid 1 --gcmode full --datadir ..\chain\data\

What I'm doing here:

geth: command line interface for the client
console: start geth environment
syncmode full: blockchain sync mode to full (default to snap)
networkid 1: run the mainnet (by default it runs the mainnet)
gcmode full: Garbage collection (full or archive)
datadir: chaindata folder path that I have created earlier on

You can run a testnet node if you want to. You need to remove --networkid 1 and replace by --ropsten or --goerli or kiln or sepolia or rinkeby.

Run geth --help to see the full list of commands

Once you have executed this command, you should have this output

You will see that it will be searching for peers and download the blockchain data since the genesis (7 years 2 month and 5 days in my case)

(It's running in foreground. As soon as you close the terminal or press Ctrl+C / Ctrl+D, it will shutdown the node). If you want to run a node in a foreground or using as a service in Ubuntu, there are a lot of documentation for you. This is not the purpose of this article.

Interacting with Geth

You can interact with your node by attaching it to the datadir



geth attach --datadir ..\chain\data\

You can see what is the current block being downloaded and the highest block by executing this command in the interactive console
eth.syncing

You can also execute Javascript code. In this example, I execute this snippet to know every 10 seconds the number of blocks per seconds being downloaded, the percentage of data downloaded and the remaining time



var lastPercentage = 0;
var lastBlocksToGo = 0;
var timeInterval = 10000;
setInterval(function(){
    var percentage = eth.syncing.currentBlock/eth.syncing.highestBlock*100;
     var percentagePerTime = percentage - lastPercentage;
     var blocksToGo = eth.syncing.highestBlock - eth.syncing.currentBlock;
     var bps = (lastBlocksToGo - blocksToGo) / (timeInterval / 1000)
     var etas = 100 / percentagePerTime * (timeInterval / 1000)

     var etaM = parseInt(etas/60,10);
     console.log(parseInt(percentage,10)+'% ETA: '+etaM+' minutes @ '+bps+'bps');

     lastPercentage = percentage;lastBlocksToGo = blocksToGo;
 },timeInterval);

The number of block will be decreasing because over the year, there are more and more transaction in a block and you will be downloading more data in a full node in the last 128 blocks.

Run the node (dev mode / contributor)

The purpose of this article is not to help you running in dev mode. So I won't detail too much.
If you want to contribute to the Ethereum client, you can run the command geth in dev mode without putting your assets at risk. There is a --dev flag that run geth in dev mode. In this way you have a node with:

Data directory with a testing genesis block
Max peers to 0. That means that Geth won't search for peers (default to 50)
The node won't be visible to other nodes
Gas price is set at 0 wei
PoA (Proof of Authority) in order to mine block on demand
Generate Block on demand.

For example, you can run this command:



geth --dev --http --http.api eth,web3,personal,net --http.corsdomain "http://remix.ethereum.org"

(See the full help from the command geth --help)

Next Steps

The next step is to run the consensus layer in order to be able to participate in the network after the merge.
After that, we will be covering the setup of a private node.

Conclusion

Here you have just an overview on how to setup an Ethereum node. There are more to cover like:

Using Clef as ab account management for Geth that allows to sign transaction
Create a specific user to setup the node and give privilege
Port forwarding for your node
Miner options from the command line (will be deprecated)
Auto start on boot in Linux And more.

Thank you for reading and have fun in the decentralised world :)

Solidity : Gas Optimisation

Akim B. (mousticke.eth) — Fri, 15 Jul 2022 18:09:46 +0000

Introduction
On Chain or Off Chain
Solidity Optimiser
EVM Slots
Loop through an array
Libraries
Events
Computed Values
Constants
Error handling

Introduction

When writing smart contract in Solidity, you may not be really concerned about the gas consumption in Remix environment or in a testnet. You only realise how much cost every OPCODES when you deploy in the mainnet on Ethereum (or in L2 but it's quite cheap).
Today, we will cover some optimisation we can do in Solidity. This list is not exhaustive and feel free to test every option you can.

The very first rule we keep in mind is : Every state variable we update cost you some fees. For more information, you can see the following documentation : Opcode. Many EIP try to optimise or adjust the gas cost of operations in the EVM. (EIP 2929, EIP 1559 for example)

On Chain or Off Chain Data

As mentioned above, writing state variable cost you some gas. That's why you should be aware that every user's call can cost a lot. You should be asking : "Do I really need to store this information on chain ?"
Every data related to the "ecosystem" or that doesn't need to be censored should be inside your smart contract. When it comes to metadata, files you can handle them off chain.

Solidity Optimiser

It's a mode that enable to produce a more efficient bytecode by reducing, the code size or the gas needed for the deployment. Keep in mind that the optimiser is not turned on by default because it takes more time to compile the actual solidity code which is not efficient in development mode. Turn on the optimiser when you want to deploy your smart contract

EVM Slots

You have probably seen or heard someone telling you to order your state variables by type ?
This is not without any reason. The EVM stores the data of a smart contract into a memory slots of 256 bits. A uint256 will fill one slot. But a uint128 will fill 128 bits over 256. if the next state variable is a uint256 then, the variable will be stored in the next slot. The EVM will perform a computation to force the previous slots to fit the remaining space.
Take this code :

uint128 variable_1
uint128 variable_2
uint256 variable_3

variable_1 will be stored in slot 0. Then variable_2 can fit inside the slot 0 because it has a remaining space of 128 bits.
After that, the variable_3 will be stored in slot 1.

In a not optimised version we can have this code

address address_1
uint128 variable_1
uint256 variable_2
address address_2
uint128 variable_3

address_1 is 160 bits long (address is a 20 bytes type). It will be stored in slot 0. variable_1 is 128 bits. But 128 + 160 = 288 bits. It can't fit in the 96 bits remaining space. (256-160). Then, variable_1 will be stored in slot 1. variable_2 is a 256 bits length. It will be stored in slot 2 because it can't fit in the slot 1 (128 bits remaining space). address_2 will be in slot 3 because the slot 2 is full. The variable_3 will be in slot 4 because the slot 3 has already 160 bits reserved (96 remaining).

To optimise this version, we can adjust the variable as follow :

uint128 variable_1
uint128 variable_3
uint256 variable_2
address address_1
address address_2

Here, there is 4 slots taken while the non-optimised version has 5 slots taken. We have saved 32 bytes and prevent unnecessary computation.

Loop through an array

Arrays are quite common nowadays and it's pretty straightforward to read values from them with a for-loop.
If you have guessed where I'm going by saying that, it means you read carefully the introduction.
If you read an array which is a state variable, looping inside the array without caching it into a memory variable cost you more gas.

In the following example, you can see that for a 9-length array, we spent 83037 gas in the un-optimised version and only 56475 in the most optimised

My advice: Avoid looping through an array that has a dynamic length. The gas consumption increases overtime and it will become a very expensive process.

(Try it on Remix)

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.7.0 <0.9.0;

contract GasTest {
    uint[] public arrayTest;
    uint public sumArray;

    constructor(){
        arrayTest = [1,2,3,4,5,6,7,8,9];
    }

    /**
    * Keep reading the value of the array from the state variable
    * Keep writing the result in the state variable sumArray
    * Bad idea
    * Gas cost = 83037 
    */
    function calculateSum() external {
        for(uint i = 0; i<arrayTest.length; i++){
            sumArray += arrayTest[i];
        }
    }

    /**
    * Keep reading the value of the array from the state variable
    * Caching the sum in the memory. Write only once in the state variable
    * Not an excellent idea
    * Gas cost = 58087 
    */
    function calculateSum2() external {
        uint _sumArray = 0;
        for(uint i = 0; i<arrayTest.length; i++){
            _sumArray += arrayTest[i];
        }
        sumArray = _sumArray;
    }

    /**
    * Caching the array in the memory
    * Caching the sum in the memory. Write only once in the state variable
    * Excellent idea
    * Gas cost = 56475 
    */
    function calculateSum3() external {
        uint _sumArray = 0;
        uint[] memory _arrayTest = arrayTest;
        for(uint i = 0; i<_arrayTest.length; i++){
            _sumArray += _arrayTest[i];
        }
        sumArray = _sumArray;
    }
}

Libraries

If you have many smart contracts using the same functionalities, you should extract all these functionalities to a library and deploy it.
Now, all the smart contracts can reference the deployed library instead of deploying the same code again and again and increase the bytecode length.
Because it's a deployed library, make sure that all your functions are external

Events

If you have data created on a smart contract but does not need to be read after by the smart contract, then events are a good candidate. Events consume less gas than a state variable.

Computed Values

Sometimes, you need to store values into the smart contract (hashes for example) and you need to compute this value. My advice is to compute this value off chain and instantiate your smart contract with the computed value. (Remember: The less OPCODE you have, the better optimisation you will get)

Constants

You can have some constant values in your state variables that won't change. Constant values can be useful for gas optimisation.

Here an example:

Read state variable with const: 21420 gas
Read state variable without const: 23541 gas

(Try it on Remix)

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.7.0 <0.9.0;

contract GasTestConst {
    //Gas cost : 21420 
    address public constant CONST_ADDR = 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4;
}

contract GasTestNoConst {
    //Gas Cost: 23541
    address public addr = 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4;
}

You can say that immutable works the same as const. The only difference between immutable and const is that you can initialise the value of the immutable variable into the constructor.

Error Handling

When you use require, you pass the error reason if the condition is not met. But very long string cost more gas.
Using a custom error cost less gas. For the example below, I put the same string.
Remember that with custom error, you should log the value.

The gas cost is just slightly different but after a while, it saves some money.

(Try it on Remix)

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.7.0 <0.9.0;

contract GasTestError {

    error CustomError(string message);

    //Gas cost: 21977 
    function testRequire(uint _val) public pure {
       require(_val <= 2, "Sorry but your value does not meet the requirement. Please select a value between 0 and 2. Otherwise... Good bye");
       //process
    }

    //Gas cost: 21955 
    function testError(uint _val) public pure {
       if(_val > 2){
           revert CustomError("Sorry but your value does not meet the requirement. Please select a value between 0 and 2. Otherwise... Good bye");
       }
       //process
   }
}

Conclusion

This list is not exhaustive. We could also add the EIP 1167 for the Proxy contract but I don't want to explain advanced technique. Try these 10 tips and play with your smart contract. The goal is to save some gas with basic optimisation for beginners.
If you have any question, please comment below ;)

Ethereum2.0 : Rebranding

Akim B. (mousticke.eth) — Wed, 26 Jan 2022 21:48:11 +0000

When Ethereum2.0 is coming? Now the sort answer is: Never
But hold on! Let's explain a bit.
Caveat: I won't detail too much about the upgrade of the second layer. There is a lot of articles explaining the general purpose of the Beacon Chain, The Merge and The Sharding. What I want you to be aware, is the naming convention used in the Ethereum Network. More specifically since January 24th 2022.

Because I mentioned the three milestones of Eth2.0, let me give you a short description for them.

Definitions

Beacon Chain

Introduce the proof of stake consensus for Ethereum network. It will be the backbone of the new network upgrade.

The Merge

Mark the end of the proof of work. Because the Beacon Chain is a separated network. But in the end, the Mainnet is going to be merged with the Beacon Chain.

Sharding

Act as a horizontal scaling of the Ethereum network. Each node will run a chunk of the entire blockchain. The big advantage stays in the hardware consumptions/requirements. This will improve the number of transactions.

Network upgrade

Since the end of 2020, we hear a lot of Ethereum 2.0. But the engineers of Ethereum don't use this term anymore and prefer to say, "Execution Layer" for Eth1 and "Consensus Layer" for Eth2.
The two layers is Ethereum

The roadmap of Ethereum consists in scaling the network and introduce the proof of stake consensus. This is the roadmap of Eth2.0. In order to be shipped, the release will take some time. There is, at this time, the beacon chain shipped. We are waiting for the merge in 2022 and the sharding in 2023.

Ok but at this point, why can't we say Ethereum 2.0?
1 - Prevent scam: Malicious actors will take advantage of the new name to create an ETH2 token and tell to the users to change between their current ETH to the "new" ETH because it will be deprecated.
2 - Staking: Staking in the Beacon chain is allowed with ETH and reward are given in ETH. There is no ETH2 rewards. This can create a confusion and we can join the first point of a potential scam.
3 - Models: Eth2 is not a new model. It's just an upgrade. But the overall architecture remains.

Conclusion

Keep in mind that the only network that exists is Ethereum. But the Ethereum network is a merge between the execution layer (Eth1) and the consensus layer (Eth2)

Vulnerability exploit : Access to the private state variable in a Smart Contract

Akim B. (mousticke.eth) — Thu, 30 Dec 2021 01:40:14 +0000

When we think about private data in general, we think that any program or software interacting with our smart-contract cannot access to this variable.
Usually, when we have a private variable in an OOP, we use a getter and a setter for manipulating or reading the data.
Sometimes, we can see that the private visibility is used to store some sensitive data and we don't want anyone to read that data.

Let's say in our smart contract, we define a private state variable to store a password, a secret key or whatever. So that nobody can read or modify the data.
But it doesn't mean that we can't access to this data.

A private state variable can be read

Let's jump into the code and some explanation
You can go to the github repo (Link below in the Conclusion) to get the source code or follow along with me.

Prerequisites

npm install -g truffle

Web3JS

npm install web3

Ganache

Instantiate Truffle project

First, create a truffle project within a directory with the following command :

truffle init

Then create a contract

truffle create contract TestPrivate

Code

Now we have a contract created, copy paste this code

// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;

contract TestPrivate {

  bool public slot_boolean = true;        // → slot 0 : 1 byte
  address public owner = msg.sender;                   // → slot 0 : 20 bytes
  uint256 public slot_uint256 = 1000;     // → slot 1 : 32 bytes
  uint[2] public data;                    // → slot 2 : 32 bytes and slot 3 : 32 bytes (one slot per element)
  bytes32 private secret_data;            // → slot 4 : 32 bytes

  struct User{
    uint id;
    uint8 role;
    address userAddress;
    bytes32 password;
  }

  User[] private users;                // → slot 5 starts at keccak(5) for first user
                                      // → second user at keccack(5) + (3 → slot used for the storing one struct of user)

  constructor(bytes32 _secret_data) {
    secret_data = _secret_data;
  }

  function enrollUser(uint8 _role, bytes32 _password) external {
    User memory user = User({
      id: users.length,
      role: _role,
      userAddress: msg.sender,
      password: _password
    });

    users.push(user);
  }
}

Now we have the code, let's see how the EVM stores the variables

Slots in the EVM

The EVM will store the state variables inside an array in a compact way. That means multiple values can use the same slot. A slot can store up to 32bytes.
So when a variable in the slot is lower than 32 bytes, if the next variable can fit in the remaining space, it will be stored in the same slot.
(It's better to use 32 bytes variables for gas usage but it's another subject).

Let's see in our code, how is it stored.
Our first variable is a boolean set to true. It will be stored in the slot 0 and takes 1 byte.

slot	type	32 bytes slot
0	bool	0x0000000000000000000000000000000000000000000000000000000000000001

Next, we have an address type which is 20 bytes size. But in the slot 0, we still have enough space to store 20 bytes.
So we compact two variables inside this slot

slot	type	32 bytes slot
0	address & bool	0x0000000000000000000000aC86db09Aa6756D9606d638bFb3a3A0f7669850401

So we now have 11 bytes remaining space. (20 + 1 = 21 bytes used)

After that, we have a uint256 with a value of 1000 (10). A uint256 is unsigned integer with a size of 256 bits (32 bytes). So the entire slot 1 will store this variable.
So the storage will be :

slot	type	32 bytes slot
0	address & bool	0x0000000000000000000000aC86db09Aa6756D9606d638bFb3a3A0f7669850401
1	uint256 (1000)	0x00000000000000000000000000000000000000000000000000000000000003e8

If this uint was a uint64, whe would store 8 bytes inside the slot 0 because we have enough space. But if the slot 0 was full, we would store the data inside the next slot with a remaining space of 24 bytes (32 bytes - 8 bytes). The EVM does some operation to convert a 2^(3+k) (where 0<k<3) bytes data to fit inside a 32 bytes slot by adding some 0 in front of the data.

Then we have an array of 2 elements of uint256. Each element is stored inside a slot. Because one element is a 32 bytes size, we use 2 slots for the entire array.

slot	type	32 bytes slot
0	address & bool	0x0000000000000000000000aC86db09Aa6756D9606d638bFb3a3A0f7669850401
1	uint256 (1000)	0x00000000000000000000000000000000000000000000000000000000000003e8
2	uint256(0)	0x0000000000000000000000000000000000000000000000000000000000000000
3	uint256(1)	0x0000000000000000000000000000000000000000000000000000000000000000

We store the private bytes32 inside the slot 4.

slot	type	32 bytes slot
0	address & bool	0x0000000000000000000000aC86db09Aa6756D9606d638bFb3a3A0f7669850401
1	uint256 (1000)	0x00000000000000000000000000000000000000000000000000000000000003e8
2	uint256(0)	0x0000000000000000000000000000000000000000000000000000000000000000
3	uint256(1)	0x0000000000000000000000000000000000000000000000000000000000000000
4	bytes32	0x0000000000000000000000000000000000000000000000000000000000000000

Next we have a struct of User. Inside that struct, we have :

id - uint (32 bytes)
role - uint8 (1 byte)
userAddress - address (20 bytes)
password - bytes32 (32 bytes)

So inside the array of User, we start to store at the slot 5. To know where to find the first user, we convert the number of the slot into a hash (keccak256). If we access to this slot, we have the id. Then if we increment the hash by one we access to the next slot which contains the role (1 byte) and the address (20 bytes).
If we increment the hash by 2, we access to the third slot, which contains the password.
If you want to access to the id of the second user, you increment the hash by 3 and so on...

Deploy the contract

Now let's deploy the contract.
We have a constructor that takes a parameter of a bytes32. Let's pass this argument 0x0000000000000000000000000000000000007365637265742069732068657265.
It's the string secret is here in hex representation.

To deploy the contract, we first need to create the migration file for truffle. For that, you need to compile the smart contract because we need to access to the artifact. Then create a file inside the migrations folder.

Run

  truffle compile

The output from the compile command should look like this :

$ truffle compile

Compiling your contracts...
===========================
> Compiling .\contracts\Migrations.sol
> Compiling .\contracts\TestPrivate.sol
> Artifacts written to D:\Documents\Development\Ether\security\solidity-private-data\build\contracts
> Compiled successfully using:
   - solc: 0.8.9+commit.e5eed63a.Emscripten.clang

Add 2_deploy_TestPrivate.js file inside the migrations directory

Then add this code inside the file 2_deploy_TestPrivate.js

const TestPrivate = artifacts.require("TestPrivate");

module.exports = function (deployer, network, accounts) {
  const secretUse =
    "0x0000000000000000000000000000000000007365637265742069732068657265"; //secret is here
  deployer.deploy(TestPrivate, secretUse);
};

After that you need to check if you have a network enabled inside your truffle config. (In my case, I will run a local network with ganache)
Your truffle config should look like this :

module.exports = {
  networks: {
    ganache: {
      host: "127.0.0.1", // Localhost (default: none)
      port: 7545, // Standard Ethereum port (default: none)
      network_id: "*", // Any network (default: none)
    },
  },

  // Set default mocha options here, use special reporters etc.
  mocha: {
    // timeout: 100000
  },

  // Configure your compilers
  compilers: {
    solc: {
      version: "0.8.9", // Fetch exact version from solc-bin (default: truffle's version)
      // docker: true,        // Use "0.5.1" you've installed locally with docker (default: false)
      // settings: {          // See the solidity docs for advice about optimization and evmVersion
      //  optimizer: {
      //    enabled: false,
      //    runs: 200
      //  },
      //  evmVersion: "byzantium"
      // }
    },
  },
};

Once you have all the setup done, after running the command truffle migrate --network ganache, you should see the following output

$ truffle migrate --network ganache

Compiling your contracts...
===========================
> Compiling .\contracts\Migrations.sol
> Compiling .\contracts\TestPrivate.sol
> Artifacts written to D:\Documents\Development\Ether\security\solidity-private-data\build\contracts
> Compiled successfully using:
   - solc: 0.8.9+commit.e5eed63a.Emscripten.clang



Starting migrations...
======================
> Network name:    'ganache'
> Network id:      5777
> Block gas limit: 6721975 (0x6691b7)


1_initial_migration.js
======================

   Deploying 'Migrations'
   ----------------------
   > transaction hash:    0xb6767a41e6067e2ec91eb8160df8a52064366aaa89768e7377dd6a5f9fc312ac
   > Blocks: 0            Seconds: 0
   > contract address:    0xA441f0E978c08E70c3249d97Dd542E7E37bEc06D
   > block number:        618
   > block timestamp:     1640659167
   > account:             0x009d6EF647f472b543A6057b443a72Dff6e61c7a
   > balance:             96.52405552
   > gas used:            248842 (0x3cc0a)
   > gas price:           20 gwei
   > value sent:          0 ETH
   > total cost:          0.00497684 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:          0.00497684 ETH


2_deploy_TestPrivate.js
=======================

   Deploying 'TestPrivate'
   -----------------------
   > transaction hash:    0x764f973c29ed5937b26728f80689387fcf99b38d96a635bcdf43edc17a331c1b
   > Blocks: 0            Seconds: 0
   > contract address:    0xd3a66714eB418B33f78c46FbC1B4996c6dE2F705
   > block number:        620
   > block timestamp:     1640659168
   > account:             0x009d6EF647f472b543A6057b443a72Dff6e61c7a
   > balance:             96.5160722
   > gas used:            356653 (0x5712d)
   > gas price:           20 gwei
   > value sent:          0 ETH
   > total cost:          0.00713306 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:          0.00713306 ETH


Summary
=======
> Total deployments:   2
> Final cost:          0.0121099 ETH

In ganache, we can see our contract deployed (You need to add the truffle config file)

Inside your json file of the previously compiled contract, you should see this object

"networks": {
    "5777": {
        "events": {},
        "links": {},
        "address": "0xd3a66714eB418B33f78c46FbC1B4996c6dE2F705",
        "transactionHash": "0x764f973c29ed5937b26728f80689387fcf99b38d96a635bcdf43edc17a331c1b"
    }
},

So now our contract is deployed and ready to use, we can add some data inside the users array.

Interact with the smart contract

Since we have a client (Ganache), we run the command truffle console
See if it works by returning the list of the accounts

truffle(ganache)> let accounts = await web3.eth.getAccounts()
undefined
truffle(ganache)> accounts
[
  '0x009d6EF647f472b543A6057b443a72Dff6e61c7a',
  '0x4EBE31e37c016253DE9B8994514Da6cBCB57f0a5',
  '0xC66A8fBAF9F95CCe86AefB8e713029E2aa9c7E8d',
  '0xF22f46120471166fb7029990D4eCBaCb63e575B4',
  '0x7B4794aD644543b80b71c1243185E37AEA50B403',
  '0xbe8eC832Ea864366F789AB1458358e4506228075',
  '0x108BdEa3473a7488377C9FbE5b12078bf311Ca16',
  '0xbdEe79e2C8CA3311B9C8531410f09567F22F4FEd',
  '0x579Ed8B42541E0877D9e2425D32a67127f22b0A3',
  '0xA3AD8DE6b1BDe5DacF715E4008866b3c12a5def0'
]
truffle(ganache)>

Now, let's create an instance of the smart contract

truffle(ganache)> let instance = await TestPrivate.deployed()
undefined
truffle(ganache)> instance
 ...
 contractName: 'TestPrivate',
      abi: [Array],
      metadata: ...
 ...

Access to the slot

Now we have our smart contract instance, let's see how we access to the slots.

First we need the address of the smart contract

truffle(ganache)> let address = await instance.address
undefined
truffle(ganache)> address
'0xd3a66714eB418B33f78c46FbC1B4996c6dE2F705'

We will use our address to get the data inside the storage with web3

Slot 0

For the slot 0, we have

truffle(ganache)> let instance = await TestPrivate.deployed()
undefined
truffle(ganache)> let address = await instance.address
undefined
truffle(ganache)> address
'0xB3884D48eA4f9CbC6bCE90E3D58d193C6c6d719C'
truffle(ganache)> let slot0 = await web3.eth.getStorageAt(address, 0, console.log)
null 0x9d6ef647f472b543a6057b443a72dff6e61c7a01
undefined
truffle(ganache)> slot0
'0x9d6ef647f472b543a6057b443a72dff6e61c7a01'

We can see our owner address 9d6ef647f472b543a6057b443a72dff6e61c7a and our boolean value 01
You can check the owner address

truffle(ganache)> await instance.owner()
'0x009d6EF647f472b543A6057b443a72Dff6e61c7a'

Slot 1

truffle(ganache)> let slot1 = await web3.eth.getStorageAt(address, 1, console.log)
null 0x03e8
undefined
truffle(ganache)> slot1
'0x03e8'
truffle(ganache)>

We can see the uint256 value 1000 in hex.

truffle(ganache)> parseInt(0x3e8, 10)
1000

Slot 2 and 3

As I said earlier, the slot 2 and 3 contains the value of the uint256 array. Each value are stored in one slot due to their size.

truffle(ganache)> let slot2 = await web3.eth.getStorageAt(address, 2, console.log)
null 0x0
undefined
truffle(ganache)> slot2
'0x0'
truffle(ganache)> let slot3 = await web3.eth.getStorageAt(address, 3, console.log)
null 0x0
undefined
truffle(ganache)> slot3
'0x0'

Slot 4

Here comes the funny part. We have a private state variable. Let's see what we have

truffle(ganache)> let slot4 = await web3.eth.getStorageAt(address, 4, console.log)
null 0x7365637265742069732068657265
undefined
truffle(ganache)> slot4
'0x7365637265742069732068657265'

We can see the hex value 0x7365637265742069732068657265. Since it is a bytes32 state variable, let's convert into an alphabet representation

truffle(ganache)> let asciiPrivateData = await web3.utils.toAscii('0x7365637265742069732068657265')
undefined
truffle(ganache)> asciiPrivateData
'secret is here'

We can see that we can clearly read the data.

Slot 5

In the user array, we first add 2 users.

truffle(ganache)> await instance.enrollUser(1, web3.utils.toHex("secret user1"))
{
  tx: '0xa9c1e069d453a41cce948f3c6779dc8d02a3ee2e50b3b4cba9866bc5f4c4aa4a',
  receipt: {
    transactionHash: '0xa9c1e069d453a41cce948f3c6779dc8d02a3ee2e50b3b4cba9866bc5f4c4aa4a',
    transactionIndex: 0,
    blockHash: '0x05ec32043c20202580f971711715d2c4c3483723703d3879b859080c92626ff0',
    blockNumber: 626,
    from: '0x009d6ef647f472b543a6057b443a72dff6e61c7a',
    to: '0xb3884d48ea4f9cbc6bce90e3d58d193c6c6d719c',
    gasUsed: 87357,
    cumulativeGasUsed: 87357,
    contractAddress: null,
    logs: [],
    status: true,
    logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
    rawLogs: []
  },
  logs: []
}
truffle(ganache)> await instance.enrollUser(2, web3.utils.toHex("secret user2"))
{
  tx: '0xedef6f68f3e742b6ec41e10e7256f1fceba84b247f2b1d83ec66b367f04511bb',
  receipt: {
    transactionHash: '0xedef6f68f3e742b6ec41e10e7256f1fceba84b247f2b1d83ec66b367f04511bb',
    transactionIndex: 0,
    blockHash: '0x4f6f86923646c4103d9b5eaf413f0ef2cebe175ea6b550fb971fd48a08ff52e6',
    blockNumber: 627,
    from: '0x009d6ef647f472b543a6057b443a72dff6e61c7a',
    to: '0xb3884d48ea4f9cbc6bce90e3d58d193c6c6d719c',
    gasUsed: 91557,
    cumulativeGasUsed: 91557,
    contractAddress: null,
    logs: [],
    status: true,
    logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
    rawLogs: []
  },
  logs: []
}

Now we have the 2 user, let's run our methods to get the storage at the slot 5

truffle(ganache)> let slot5 = await web3.eth.getStorageAt(address, 5, console.log)
null 0x02
undefined
truffle(ganache)> slot5
'0x02'

We can see that we have 2 User inside our array. The first user should be stored at the hash of the slot 5

truffle(ganache)> let hashFirstUser = await web3.utils.soliditySha3({type: "uint", value: 5})
undefined
truffle(ganache)> hashFirstUser
'0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db0'
truffle(ganache)>

Now, get the first user id

truffle(ganache)> let slot_user1_id = await web3.eth.getStorageAt(address, hashFirstUser, console.log)
null 0x0
undefined
truffle(ganache)> slot_user1_id
'0x0'
truffle(ganache)>

It should equal 0 because the id is the length of the array before we push the struct.

To get the user role and address, we need to read the next slot by incrementing the hash by one
0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db0 → 0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db1

truffle(ganache)> let slot_user1_roleAndAddress = await web3.eth.getStorageAt(address, '0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db1', console.log)
null 0x9d6ef647f472b543a6057b443a72dff6e61c7a01
undefined
truffle(ganache)> slot_user1_roleAndAddress
'0x9d6ef647f472b543a6057b443a72dff6e61c7a01'

We can see the role 01 and the msg.sender value. (Which is the same as the owner in this case) 0x9d6ef647f472b543a6057b443a72dff6e61c7a.

Then, we access to the password of the user by incrementing again the hash by 2
0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db0 → 0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db2

truffle(ganache)> let slot_user1_password = await web3.eth.getStorageAt(address, '0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db2', console.log)
null 0x7365637265742075736572310000000000000000000000000000000000000000
undefined
truffle(ganache)> slot_user1_password
'0x7365637265742075736572310000000000000000000000000000000000000000'
truffle(ganache)> await web3.utils.toAscii('0x7365637265742075736572310000000000000000000000000000000000000000')
'secret user1\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

We can clearly see the password of the user even though the state variable is private.

You can guess that if you want to see the data of the user 2, you need to increment the hash by 3 (3 slots for one user due to our structure)

truffle(ganache)> let slot_user2_id = await web3.eth.getStorageAt(address, '0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db3', console.log)
null 0x01
undefined
truffle(ganache)> slot_user2_id
'0x01'

We can access to the password of the second user by incrementing the hash by 5

truffle(ganache)> let slot_user2_password = await web3.eth.getStorageAt(address, '0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db5', console.log)
null 0x7365637265742075736572320000000000000000000000000000000000000000
undefined
truffle(ganache)> await web3.utils.toAscii('0x7365637265742075736572320000000000000000000000000000000000000000')
'secret user2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Conclusion

Do not assume that because you have a private state variable, we cannot access to the data. The recommendation is :
Do not store sensitive data on the blockchain.

You can get the code here : GitHub

DEV Community: Akim B. (mousticke.eth)

Ethereum UX: Account Abstraction (AA)

Introduction

What is Account Abstraction?

Why Do We Need AA?

Key Components of AA (ERC-4337 Standard)

1. UserOperations (UserOps)

2. Alt-mempool

3. Bundler

4. EntryPoint

5. Smart Account (user’s wallet)

6. Paymaster

7. Aggregator

8. Factory

Transaction flow

Real-World Use Cases

Pay Gas Fees in Any ERC-20 Token

Signing with Google or Apple ID (Passkeys)

Account abstraction flow with Apple ID / Google

Benefits are huge

Final thought

Understand the ZK Rollups

Abstract

What is a Rollup.

Blocks in Ethereum

A single transaction

How does a rollup work?

ZKsnarks Rollup

Optimistic Rollup

Recap

Setting up an Ethereum Node (Execution Client)

Caveat

Table Of Contents

Abstract

Prerequisites

Hardware

Node types

Light Node

Full Node

Archive Node

Why should I run a node?

For me

For the Network

Installation

Golang

Download Source code (Windows)

Download Source Code (Linux)

Download the Package (Ubuntu)

Create the chaindata folder

Run the node

Interacting with Geth

Run the node (dev mode / contributor)

Next Steps

Conclusion

Solidity : Gas Optimisation

Table Of Contents

Introduction

On Chain or Off Chain Data

Solidity Optimiser

EVM Slots

Loop through an array

Libraries

Events

Computed Values

Constants

Error Handling

Conclusion

Ethereum2.0 : Rebranding

Definitions

Beacon Chain

The Merge

Sharding

Network upgrade

Conclusion

Vulnerability exploit : Access to the private state variable in a Smart Contract

Prerequisites

Instantiate Truffle project

Code

Slots in the EVM

Deploy the contract