Coder Legion - Recent posts tagged evm

Building a Real MetaMask + Ethereum Sepolia Payment Flow for MyZubster

Fri, 25 Sep 2026 05:53:49 +0000

Building a Real MetaMask + Ethereum Sepolia Payment Flow for MyZubster

I’ve been working on the next stage of the MyZubster Marketplace: connecting authenticated users, MetaMask wallets, signed marketplace requests, and real blockchain payment verification.

The target flow is:

MyZubster account
→ verified MetaMask wallet
→ signed marketplace request
→ seller acceptance
→ Ethereum Sepolia payment
→ server-side verification
→ PAID
→ COMPLETED

This week we reached an important milestone: real wallet ownership verification is working end-to-end.

What is working now

We created a completely isolated E2E environment on the VPS instead of experimenting directly in production.

The test stack currently runs as:

React frontend
127.0.0.1:3010

    ↓ proxy

MyZubster backend
127.0.0.1:5010

↓

MongoDB + Ethereum Sepolia RPC

The environment stays private. Instead of exposing the development ports publicly, I access the React frontend from my local machine using an SSH tunnel.

That also means I can use the real MetaMask browser extension against the remote test backend.

Real MetaMask verification

The first working flow is:

Authenticated MyZubster user

↓

Connect MetaMask

↓

Backend generates challenge

↓

MetaMask personal_sign

↓

Backend verifies signature

↓

Wallet becomes VERIFIED

And this is now working with a real wallet.

The UI successfully reached:

Verified · 0xBBBc51B471…03f514bCBb

with confirmation that the wallet was linked to the MyZubster account.

The important detail is that this is not a payment.

personal_sign is only being used to prove wallet ownership.

No ETH is transferred and no gas is consumed.

Authentication and wallet ownership are separate

One thing I wanted to preserve in the architecture is a strict distinction between platform identity and blockchain identity.

A user first authenticates with MyZubster, currently through mechanisms such as Google or GitHub OAuth.

MetaMask then proves control of an EVM address.

So:

AUTHENTICATED ≠ WALLET VERIFIED

And later:

WALLET VERIFIED
≠ REQUEST SIGNED
≠ TX SUBMITTED
≠ PAID
≠ COMPLETED

Those states should never collapse into a single “connected” status.

An interesting network detail

The wallet verification test happened while MetaMask was on:

chainId 84532

which is Base Sepolia.

The Marketplace payment system itself targets:

Ethereum Sepolia
chainId 11155111
0xaa36a7

That is intentional.

Wallet ownership verification proves control of an EVM address.

The actual payment step independently checks the required network and can request MetaMask to switch to Ethereum Sepolia before sending anything.

Signed Marketplace requests

The next layer is already implemented.

When a Buyer requests a real Marketplace listing, MyZubster can generate an order-specific challenge.

The Buyer signs it with MetaMask:

Marketplace listing

↓

Order challenge

↓

personal_sign

↓

Signature verification

↓

Signed request

Again, this does not move funds.

It creates cryptographic evidence that the verified Buyer wallet approved that specific request.

The Seller can then see wallet evidence before deciding whether to accept the order.

The payment architecture

After Seller acceptance, the server creates an ETH payment intent.

That intent defines the expected:

sender
recipient
amount
chain

The frontend then verifies that the currently selected MetaMask account matches the Buyer wallet.

It also verifies Ethereum Sepolia.

Only then can it call:

ethereum.request({
method: "eth_sendTransaction",
...
})

MetaMask still requires explicit approval from the user.

MyZubster never receives the private key.

A transaction hash is not proof of payment

This is probably the part of the architecture I care most about.

The browser submitting a transaction hash does not automatically change the order to PAID.

The backend independently checks the blockchain through the Sepolia RPC.

It verifies things such as:

correct sender
correct recipient
correct network
correct amount
successful transaction
minimum confirmations

The lifecycle can therefore look like:

TX_SUBMITTED

↓

CONFIRMING

↓

3 confirmations

↓

PAID

If something does not match, the verifier can reject the transaction instead.

What has actually been tested

So far the real environment has validated the isolated VPS deployment, frontend/backend proxy, Ethereum Sepolia RPC access, SSH browser access, OAuth-authenticated MyZubster session, MetaMask detection, wallet connection, real personal_sign, server-side signature verification, and successful wallet linking.

The blockchain payment code exists, but I am deliberately not calling the whole Marketplace payment flow complete yet.

What remains

The next E2E test needs two actors:

Seller account + Seller MetaMask wallet

Buyer account + Buyer MetaMask wallet

The Seller will create an ETH listing.

The Buyer will sign a request.

The Seller will inspect and accept it.

The Buyer will then submit a real Ethereum Sepolia transaction using test ETH.

Finally, the backend should independently detect and verify the transaction before changing the order to:

PAID

and eventually:

COMPLETED

After the happy path works, we still need negative tests for wrong wallets, wrong networks, wrong recipients, incorrect amounts, failed transactions, insufficient confirmations, and reused transaction hashes.

Why I’m building it this way

I don’t want “Connect Wallet” to become a magic button that implicitly means identity, authorization, payment, and settlement.

Each operation should have its own proof.

OAuth
→ proves the MyZubster account

Wallet signature
→ proves control of the address

Order signature
→ proves approval of the request

Blockchain transaction
→ proves value movement

Server verifier
→ proves that the transaction matches the order

That makes the system more complex than a simple wallet-connect demo, but it also makes the trust model much clearer.

The first major milestone is now working:

a real authenticated MyZubster user can connect MetaMask, sign an off-chain challenge, and have their EVM wallet independently verified and linked by the backend.

Next stop: the first complete Buyer → Seller transaction on Ethereum Sepolia.

Enterprise Vulnerability Management: A Comprehensive Guide

Thu, 23 Apr 2026 22:56:14 +0000

Understanding Enterprise Vulnerability Management (EVM)

Okay, let's dive into Enterprise Vulnerability Management (evm). You ever stop to think how many doors and windows you have in your house? Now, imagine that for your entire company. Scary, right?

EVM is basically a super organized system for finding, fixing, and keeping an eye on weaknesses in your company's tech stuff. (EVM for the rest of us - PMI) Think of it as a continuous cycle of security check-ups, but on a grand scale.

Definition: It's the process of finding, checking, fixing, and reporting flaws in your it setup. (What is Debugging? - Debugging Explained - Amazon AWS) SentinelOne says it's all about closing those exploit paths before the bad guys get a chance. That sounds pretty good, right?
Scope: It covers everything, from your office computers, cloud servers, phones, and even those weird iot devices, according to sentinelone. (What is Endpoint Protection? A Comprehensive Guide 101)
Why it Matters: Honestly, there's a ton of reasons to care. It protects from cyber attacks, helps you follow rules (compliance!), keeps things running smoothly, handles remote workers, and helps your security team handle all of it.

Okay, so maybe you're not a techie. But, trust me, this stuff matters to everyone—especially the people holding the purse strings.

Quantifying the Risk: It's about figuring out how much you could lose if something goes wrong. Think about it: a data breach can cost millions and ruin your reputation. For example, a retail company might calculate that a breach of their customer database could lead to millions in fines, lost sales due to reputational damage, and the cost of credit monitoring for affected customers.
ROI (Return on Investment): Showing that spending money on evm actually saves you money in the long run. It's like saying, "Hey, spending a little now means we won't get hit with a huge bill later." For instance, an organization might track the reduction in security incidents and the associated costs (like incident response and downtime) after implementing an EVM program, demonstrating a clear financial benefit.
Aligning With Business Goals: evm needs to fit in with what your company actually cares about. Are you okay with some risk, or do you want to be super careful?

Here's a peek at how EVM might look in action:

Imagine a hospital. They've got tons of devices: computers, medical equipment, you name it. An evm program would constantly scan all those devices for weaknesses before some hacker does.

Diagram 1 illustrates the cyclical nature of Enterprise Vulnerability Management, showing the key phases from identification to remediation and continuous monitoring.

Alright, that's the basic idea behind Enterprise Vulnerability Management. Now that you have a general understanding, up next, we'll dive deeper into the business case for evm.

Key Components of an Effective EVM Program

Okay, so you're trying to build an Enterprise Vulnerability Management (evm) program. Where do you even start? It's like trying to organize your junk drawer – overwhelming, but totally doable if you break it down.

An effective evm program isn't just about buying a fancy scanner; it's about building a solid, repeatable process. Think of these components as the pillars holding up the whole operation.

First things first, you gotta know what you have. It's kinda like figuring out what ingredients are in your fridge before you try to cook dinner.

Automated asset discovery: Use tools that automatically find everything connected to your network. This includes servers, workstations, cloud instances, and even those weird iot devices no one remembers setting up.
Accurate asset inventory: Keep a detailed, up-to-date list of all assets. I mean, really detailed – operating systems, software versions, network addresses, who owns it, etc.
Asset classification: Categorize assets based on how important they are to the business. A database with customer data is way more critical than, say, the breakroom tv. This way, you know what to focus on first.

Think about a retail chain; they've got point-of-sale systems, inventory servers, customer databases, and a whole lotta other stuff. If they don't know everything that's connected to their network, they're basically leaving doors unlocked for hackers.

Alright, now that you know what you have, you need to find out what's broken. This is where the scanning comes in.

Right vulnerability scanners: Pick the right tools for the job. What I mean is, you need scanners that can handle your specific environment – operating systems, applications, network devices, the whole shebang.
Optimal scan configuration: Configure those scanners correctly. Don't just run them out of the box; tweak the settings to get the best coverage and accuracy.
Vulnerability scoring: Understand vulnerability scoring systems. The Common Vulnerability Scoring System (cvss) gives each vulnerability a severity score.
Authenticated vs. unauthenticated: Know the difference here. Authenticated scans log into systems to get a much deeper look. Unauthenticated scans are like knocking on the door – they only see what's visible from the outside.

According to Tenable, vulnerability management solutions help organizations accurately identify, investigate and prioritize vulnerabilities across their attack surface.

Found the problems? Great! Now, let's fix 'em.

Risk-based remediation: Fix the most dangerous stuff first. Don't waste time patching low-risk vulnerabilities when critical systems are exposed.
Automated patch deployment: Automate as much of the patch deployment process as possible. This saves tons of time and reduces the chance of human error.
Exception management: Sometimes, you can't patch something right away. Maybe it'll break a critical application, or there's no patch available yet. That's were compensating controls come in.

Compensating Controls: These are security measures put in place to reduce the risk of a vulnerability when the primary control (like patching) isn't feasible or immediately possible. For example, if a critical server can't be patched due to compatibility issues, a compensating control might be to isolate that server on a separate network segment (network segmentation) or to implement stricter access controls and monitoring for it. In essence, they're alternative security safeguards to mitigate risk.

Oh, and don't forget about sso and user management. You can implement this for enterprise client with SSOJet's api-first platform.

Okay, so you've scanned, assessed, and patched. Are you done? Nope!

Key Performance Indicators (kpis): Set up kpis to track the effectiveness of your evm program. Things like: How many vulnerabilities are found per month? How long does it take to patch them?
Dashboards and reports: Create dashboards and reports to visualize your progress and identify trends. SentinelOne says that auditors expect to see logs of weaknesses identified, patching deadlines, and confirmation of patch implementations.
Stakeholder communication: Keep everyone in the loop. Let management know what you're doing, what progress you're making, and what risks you're facing.

Diagram 2 outlines the core components of an effective EVM program, from asset management and scanning to remediation and reporting.

These key components are essential for building a solid Enterprise Vulnerability Management program. Next up, we'll dive into some of the tools and technologies that can help you automate and streamline the whole process.

The EVM Process: A Step-by-Step Guide

Okay, so you're thinking about vulnerability management? It's more than just running a scan and hoping for the best, you know? It's a process, a cycle, a whole thing. Think of it like this: you wouldn't build a house without a plan, right? Same goes for keeping your systems safe.

First up, you gotta figure out what you're actually trying to protect. It's not just about slapping a firewall on everything and calling it a day.

Defining the scope of the evm program is essential. What's in bounds? What's out? Are we talking everything, or just the stuff that makes us money? You need to decide what is important. Consider factors like business criticality (e.g., systems directly supporting revenue generation), regulatory requirements (e.g., HIPAA for healthcare data), and the overall attack surface.
Identifying key stakeholders and their responsibilities is crucial. Who is in charge of what? Is it the it team? The security team? Some random guy named bob in accounting? Someone needs to own this, or it'll fall apart fast.
Establishing policies and procedures is surprisingly important. What happens when a vulnerability is found? Who gets notified? What's the timeline for fixing it? write it down, or you'll be making it up as you go.

Next, you need to go hunting for problems.

Conducting asset discovery and vulnerability scanning is the main event. You need to find everything connected to your network, and then scan it for weaknesses. Think of it like walking around your house and jiggling all the doorknobs.
Analyzing scan results and identifying vulnerabilities is where it gets tricky. You'll probably get a ton of results and decide what's important.
Validating vulnerabilities and eliminating false positives is essential, because scanners aren't perfect. You don't want to waste time chasing ghosts, you know?

Now you know what's broken; let's fix it.

Prioritizing vulnerabilities based on risk is key. Not all vulnerabilities are created equal. Some are minor annoyances, others are gaping holes that could sink the ship.
Developing remediation plans and assigning owners is important. How are you going to fix each vulnerability? Who's going to do it? What is the timeline?
Implementing remediation actions (patching, configuration changes, etc.) is the actual work. This is where you roll up your sleeves and start patching systems, changing configurations, and generally making things more secure.

You fixed the problems, but this is not over. You need to make sure they stay fixed.

Verifying the effectiveness of remediation actions is essential. Did the patch actually work? Are you sure? Don't just assume it's fixed; double-check.
Monitoring systems for new vulnerabilities is a never-ending process. New vulnerabilities are discovered all the time, so you need to keep scanning and assessing.
Generating reports and tracking progress is how you know if you're actually getting better. Are you finding fewer vulnerabilities over time? Are you patching them faster?

As Escape.tech notes, it's about evolving beyond mere compliance and building a "thriving organism capable of adapting to and repelling sophisticated cyber attacks". That puts it nicely, right?

So, that's the Enterprise Vulnerability Management process in a nutshell. Next up, we'll dive into the tools and technologies that can help you automate and streamline the whole thing.

Challenges in Enterprise Vulnerability Management

Okay, so you're trying to wrangle all the moving parts in Enterprise Vulnerability Management (evm)? It's like herding cats, isn't it? So many things can go wrong, so many things to keep track of.

One of the biggest headaches is just the sheer volume of vulnerabilities you're dealing with. I mean, hundreds, sometimes thousands, popping up every month. It's a constant barrage.

Sorting Through the Noise: You're not just seeing a list; you're trying to figure out what actually matters. Is this a minor glitch, or is it the kind of thing that'll let hackers waltz right in? It's a constant gamble.
Prioritization Headaches: Deciding what to fix first? That's the real trick. You can't patch everything at once, so you're constantly weighing risks, potential impacts, and the resources ya got. Kinda like playing whack-a-mole, but with really nasty consequences if you miss one.
Automation to the Rescue: Thankfully, there are tools out there that can help you sort and prioritize. These tools help you to automate vulnerability and threat management, which is essential in large organizations.

And then there's the whole legacy system problem. Old systems that can't be easily patched, or might break if you do try to patch them.

The Unpatchable: You've got these ancient systems humming along, keeping the lights on, but they're basically sitting ducks. No new patches, no support, just a big ol' vulnerability waiting to be exploited.
Compensating Controls: If you can't patch, you gotta get creative, right? Things like network segmentation, intrusion detection, all that jazz. It's like putting up extra walls and security cameras around a rickety old building.
Upgrade or Die Trying: Eventually, you gotta bite the bullet and upgrade or replace these dinosaurs. But that's a project in itself, right? Planning, budgeting, migrating data – it's a whole thing.

Don't even get me started on the distributed workforce. Remote workers, home networks, personal devices – it's a whole new can of worms.

The Wild West: Remote devices are outside your nice, controlled network. You don't know what kinda security they got, what kinda networks they're connecting to. It's like sending your data out into the wild west.
Home Network Nightmares: Home networks are notoriously insecure. Weak passwords, outdated routers, you name it. It's a hacker's playground.
Policy Enforcement: Getting remote workers to follow security rules? Good luck with that. You need strong policies, clear communication, and maybe a lil' bit of nagging.

And then there’s the whole DevSecOps thing. Getting security baked into the development process from the start.

Shifting Left (and Hoping for the Best): The idea is to catch vulnerabilities early, before they make it into production. Sounds great in theory, but it requires a major culture shift. Integrating security into the development pipeline means developers need to be security-aware, and security teams need to collaborate closely with development. This can involve training, providing secure coding guidelines, and embedding security testing tools directly into the CI/CD pipeline.
Automated Scans in the Pipeline: You can automate vulnerability scans in the ci/cd pipeline, which is great. But you gotta make sure the scans are accurate, fast, and don't slow down development too much. This helps catch common coding errors and dependency vulnerabilities early, reducing the burden on later stages of the EVM process.
Security and Devs – Friends, Not Foes: Getting security and development teams to actually work together? That's the real challenge. Breaking down silos, fostering collaboration, it's a long process. When security is seen as a blocker, it's ignored. When it's integrated as a shared responsibility, it becomes a force multiplier for EVM.

So, yeah, Enterprise Vulnerability Management? It's not for the faint of heart. But, knowing these challenges is half the battle. Next up, we'll dive into some of the tools and technologies that can help you automate and streamline the whole process.

Best Practices for a Robust EVM Program

Alright, so you're trying to keep your Enterprise Vulnerability Management (evm) program from going off the rails? It's like trying to juggle chainsaws while riding a unicycle, right? Let's talk best practices...

Establish Clear Policies and Procedures:<

Part-1: Intro to MEV(Maximal Extractable value) Attack

Thu, 07 Aug 2025 17:24:51 +0000

MEV attacks happen when someone (usually a miner, validator, or bot) manipulates the order of pending transactions in Ethereum (EVM chains) to make extra money
This attaclk is done by front-running, back-running, sandwich or liquidation attacks
mempool -> this is a public memory pool, where all TNX are visible
bots and attackers scans mempool for higher and profitable trades

Note: This is just an intro for MEV attack with minimal code example. Part-2 will contain the code example for each attack type in MEV

How this attacks work?

valid user submits TNX for some operation -> attacker/bots scan the mempool for profitable opportunities or for high trades
before user submit and completes TNX -> attacker/bots manipulates the block/price/protocol to earn more profit

Core concepts of MEV

it is easier to take advantage of MEV opportunities on ethereum than bitcoin
Due to Ethereum account model as compared to Bitcoin UTXO model
arbitrage trading
liquidation
sandwiching

Types of MEV Attacks

Front-running attack:

An attacker/bot scans mempool for higher trading price and sees user TNX waiting to be processed and quickly submits their own -> just ahead of yours

// protocol will submit TNX to select a winner ->  attacker/bot sees TNX in mempool -> realizes they are not winner
// before protocol completes TNX and select a winner  ->   attacker refunds all token from protocol
// winner ends up getting lower winning price  -> attacker/bot gets their token
function selectWinner() external;
function refund(uint256 amount) external;

user submit TNX -> attacker/bot scans TNX in mempool -> attacker submit their own TNX before user can submit their TNX

Sandwich attack:

An attacker places one transaction just before user and another just after user -> sandwiching your trade.

// attacker/bot TNX  ->>>  user TNX  ->>>   attacker/bot TNX
// user takes flashloan to buy token  ->  attacker/bot buys token before user  ->  increases the token price
// user buys token at higher price ->  after users TNX  ->  attacker/bot sells token at higher price
function flashloan(to, token, amount) external;
function Tswap(token, amount) external;

Attacker buys before you and sells after you ->>> earning profit and users ends up paying higher price

Arbitrage MEV Attack:

An attacker exploits price differences for a token across different DEX's at the same time

// tokenA costs -> 100 USDC on uniswap
// tokenA costs -> 150 USDC on sushi at same time
// attacker/bots continuously scans mempool for higher trades and price changes
function tokenA_pool_uni(amount) external;
function tokenA_pool_sushi(amount) external;

attacker/bot always looks for higher and profitable trades in mempool to gain profit

Liquidation MEV Attack:

On DeFi lending protocols, if someone’s loan goes under-collateralize (not enough assets to back the loan, e.g., in a price drop), anyone can repay their debt and claim their collateral—with a profit bonus.
MEV bots race to be first and claim the extra bonus

// A loan on Aave or Compound is about to be liquidated. 
// Bots spot the chance, quickly repay the debt, seize the collateral (often at a discount), 
// and resell it for a reward

JIT (Just-In-Time) MEV Attack:

Simple contract example for MEV Attack

the contract is vulnerable to MEV attack
attacker/bot can scan mempool for TNX and password ->>> withdraws funds before user could
To run the code on remix checkout the below link(Thanks to CyfrinUpdraft):
Run code on remix

contract FrontRan {
    error BadWithdraw();

    bytes32 public s_secretHash;

    event success();
    event fail();

    constructor(bytes32 secretHash) payable {
        s_secretHash = secretHash;
    }

    // userA -> call withdraw() with valid password to withdraw 100ETH
    // userB -> user MEV Bot frontrun the TNX, uses the valid password from userA's TNX and calls the withdraw()
    // userB -> withdraws 100ETH before userA withdraws funds
    function withdraw(string memory password) external payable {
        if (keccak256(abi.encodePacked(password)) == s_secretHash) {
            (bool sent,) = msg.sender.call{value: address(this).balance}("");
            if (!sent) {
                revert BadWithdraw();
            }
            emit success();
        } else {
            emit fail();
        }
    }
    function balance() external view returns (uint256) {
        return address(this).balance;
    }
}

Mitigation

Proper slippage protection
use of private RPC url and Private transactions (Flashbots, MEV-resistant chains).
And, base on protocol implement the protection

Resources

Private variables are not really private on EVM

Tue, 08 Jul 2025 20:22:09 +0000

Private variables on EVM blockchains are not really private and hidden

Do you think storing important keys and data in private key's are safer on EVM chains. Definition say's all, EVM is an transparent chain
Attackers will always looks for deployed contract addresses of contracts that are vulnerable and contains funds
marking a variable as private only prevents other contracts from accessing it.
State variables marked as private and local variables are still publicly accessible

Simple contract scenario

The given contract stores password on-chain and it is marked as private variable

contract Vault {
        bool public locked;
@>  bytes32 private password;

    constructor(bytes32 _password) {
        locked = true;
        password = _password;
    }
    function unlock(bytes32 _password) public {
        if (password == _password) {
            locked = false;
        }
    } 
}

Above Contract stored password inside an private variable, thinking that it's safer and no one can access it!!!

Simple way to access private and public data of deployed contracts

With the help of contract addess and storage layout, attackers can easily read the data from private and public data stored on-chain

1. Through cast commands:

Dev's using foundry can use cast commands to access storage layout of any contract using below commands.

cast storage --rpc-url $SEPOLIA_RPC_URL --etherscan-api-key $ETHERSCAN_API_KEY CONTRACT_ADDRESS SLOT_NUMBER

This command can be used to easily read private variables stored on-chain

2. Through Etherscan:

Go to Etherscan and search for contract address
Copy and explore the TNX hash from internal transactions

Go for state and look for all storage value present!!!

Try this CTF to gain more understanding

https://ethernaut.openzeppelin.com/level/8

Real time case studies you want to look

https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell

So be aware of what you are storing on-chain and how you are enabling attackers to explore your contract and drains out all funds

Advance EVM - Opcodes, low-level calls and instructions

Thu, 03 Jul 2025 14:13:21 +0000

EVM compatible, opcodes and calling

The EVM basically represents all the instructions a computer needs to be able to read.
Any language that can compile down to bytecode with these opcodes is considered EVM compatible'

Data in Transactions:
- When we send a transaction, it is compiled down to bytecode
- The EVM processes this data to determine which function to call and what inputs to provide.

Bytecode:
- When a contract is deployed, it is compiled into bytecode understood by the EVM.
- This bytecode represents exactly the low level instructions to make our contract happen.
- This bytecode consist of opcodes

Opcodes:
- Each opcode is a 2-character hexadecimal, represents some special instruction
- This opcode reader is sometimes abstractly called the EVM

Encoding Data:
- Now, ABI encoding will convert data into bytes
- Ex: abi.encodePacked() || abi.encode()

Decoding data:
- Decoding is the process of taking the raw bytes and reconstructing the original data
- Ex: abi.decode()

call

 - How we call functions to change the state variable of the blockchain
 ```js
 function stateChange(address _address) public {
     s_state[_address] = 12;
 }
 ```

staticcall

- This is how (at a low level) we do our "view" or "pure" function calls  
 ```js
 function getState() public view returns(uint256){
     return s_state;
 }
 ```

Send TNX that call functions with just data field populated (EVM Signature Selector)

In order to call a function using only the data field of call, we need to encode:
1. function name
2. parameters we want to add

Now each contract assigns each function a function ID/Method ID:
1. Function selector is the first 4 bytes of the function signature
2. Function signature a string that defines the function name &
```
parameters
**Ex :  transfer(address,uint256)**
```

Lets assume, we need to call transfer(address,uint256) function but by filling the data field!!!

getFunctionSelector:

- By this method we will get function selector of the calling function.

function getSelector() public pure returns (bytes4 selector) {
    selector = bytes4(keccak256(bytes("transfer(address,uint256)")));
}

call Transfer Function with selector:

Will use abi.encodeWithSelector(bytes4 selector, args1, args2)

// Here, using EVM cheatcodes we can directly call the transfer() function using data-field

function callTransferData(address _address, uint256 _amount) public returns (bytes4 ,bool) {
    (bool success, bytes memory data) = address(this).call(
        abi.encodeWithSelector(getSelector(), _address,_amount)
    );
    return (bytes4(data), success);
}

call Transfer Function with signature:

Will use abi.encodeWithSignature(string functSignature, args1, args2)

// Here, we will not use function selector. Rather, we will use function signature to call our transfer() function by populating data field.

function callTransferDataSig(address _address, uint256 _amount) public returns (bytes4 ,bool) {
    (bool success, bytes memory data) = address(this).call(
        abi.encodeWithSignature("transfer(address,uint256)", _address,_amount)
    );
    return (bytes4(data), success);
}

Note: If there is anything wrong or if you want to share more concepts or if have any doubts. Pls comment below!!!

What is StarkNet and How Does It Differ from zkSync?

Wed, 26 Feb 2025 09:36:42 +0000

StarkNet Vs. zkSync

As Ethereum continues to grapple with scalability challenges, Layer 2 solutions have emerged as a critical innovation to enhance the network’s performance. Among these solutions, StarkNet and zkSync are two of the most prominent projects leveraging zero-knowledge rollups (zk-rollups) to scale Ethereum. While both aim to solve similar problems; high gas fees, slow transaction speeds, and limited throughput—they differ significantly in their architecture, features, and use cases. In this article, we’ll explore what StarkNet is, how it works, and how it compares to zkSync.

What is StarkNet?

StarkNet is a decentralized, permissionless Layer 2 scaling solution built on Ethereum that uses STARK proofs (a type of zero-knowledge proof) to enable scalable and secure smart contract execution. Developed by StarkWare, StarkNet allows developers to deploy complex dApps while maintaining Ethereum-level security.

Key features of StarkNet include:

Scalability: StarkNet can process thousands of transactions per second, far exceeding Ethereum’s current capacity.
Security: By anchoring its data back to Ethereum, StarkNet inherits the robust security guarantees of the Ethereum mainnet.
Flexibility: StarkNet supports general-purpose smart contracts, making it suitable for a wide range of applications, from DeFi to gaming.
Privacy: STARK proofs inherently protect user privacy by not revealing transaction details on-chain.

StarkNet is designed to be a general-purpose zk-rollup, meaning it can handle arbitrary computations and smart contracts, much like Ethereum itself.

What is zkSync?

zkSync is another Layer 2 scaling solution built on Ethereum that uses SNARK proofs (a different type of zero-knowledge proof) to achieve scalability. Developed by Matter Labs, zkSync focuses on providing fast, low-cost transactions while maintaining Ethereum’s security.

Key features of zkSync include:

User-Friendly: zkSync is designed to be intuitive for users and developers, with support for EVM compatibility (via zkEVM).
Low Fees: Transactions on zkSync are significantly cheaper than on Ethereum mainnet.
Instant Finality: Like other zk-rollups, zkSync provides near-instant transaction finality.
Focus on Payments: Early versions of zkSync were optimized for payments and token transfers, though newer iterations (e.g., zkSync Era) now support smart contracts.

zkSync aims to provide a seamless experience for Ethereum users, enabling them to enjoy faster and cheaper transactions without sacrificing security.

Key Differences Between StarkNet and zkSync

While both StarkNet and zkSync are zk-rollup solutions, they differ in several important ways:

Proof Technology
- StarkNet: Uses STARK proofs (Scalable Transparent ARguments of Knowledge). STARKs are considered more scalable and quantum-resistant but require more computational resources to generate.
- zkSync: Uses SNARK proofs (Succinct Non-Interactive ARguments of Knowledge). SNARKs are smaller and faster to verify but rely on trusted setups, which some consider a potential vulnerability.
Smart Contract Support
- StarkNet: Designed as a general-purpose zk-rollup, StarkNet supports complex smart contracts and arbitrary computations. However, writing smart contracts on StarkNet requires learning Cairo, a specialized programming language.
- zkSync: With the release of zkSync Era, zkSync now supports EVM-compatible smart contracts, allowing developers to deploy existing Ethereum dApps with minimal changes.
Developer Experience
- StarkNet: Developers need to learn Cairo, which has a steeper learning curve compared to Solidity (the language used on Ethereum). This can be a barrier for adoption, especially for developers unfamiliar with StarkNet’s ecosystem.
- zkSync: zkSync’s EVM compatibility makes it easier for developers to migrate their projects from Ethereum. This lowers the barrier to entry and accelerates adoption.
Transaction Costs
- StarkNet: Transaction costs on StarkNet are generally lower due to the efficiency of STARK proofs. However, the cost can vary depending on the complexity of the computation.
- zkSync: zkSync also offers low transaction costs, particularly for simple payments and token transfers. Smart contract interactions may incur slightly higher fees.
Use Cases
- StarkNet: Ideal for applications requiring high scalability and flexibility, such as gaming, NFTs, and complex DeFi protocols.
- zkSync: Suited for both payments and smart contract-based applications, with a focus on user-friendly experiences.
Ecosystem Maturity
- StarkNet: Still in its early stages of adoption, StarkNet’s ecosystem is growing but remains smaller compared to zkSync’s.
- zkSync: zkSync has gained significant traction, with many projects already deploying on its platform. Its EVM compatibility has accelerated adoption among Ethereum developers.

Real-World Use Cases

Both StarkNet and zkSync are being used in real-world applications, though their focus areas differ slightly:

StarkNet Use Cases

Immutable X: A Layer 2 solution for NFTs that leverages StarkNet’s scalability to enable gas-free minting and trading.
dYdX: A decentralized exchange that uses StarkNet’s technology for margin trading and derivatives.
Gaming: StarkNet’s high throughput makes it ideal for blockchain games requiring frequent, low-cost transactions.

zkSync Use Cases

Argent: A popular crypto wallet that uses zkSync for low-cost transactions.
Loopring: A decentralized exchange and payment protocol built on zkSync.
DeFi Protocols: Projects like ZigZag Exchange and Mute.io leverage zkSync for scalable DeFi applications.

The Future of StarkNet and zkSync

Both StarkNet and zkSync are poised to play a pivotal role in Ethereum’s scalability roadmap. Here’s what the future might hold for each:

StarkNet

Continued development of Cairo and developer tools to make it easier for developers to build on StarkNet.
Expansion into new use cases, particularly in gaming and NFTs.
Integration with Ethereum 2.0 and sharding to further enhance scalability.

zkSync

Wider adoption of zkSync Era, particularly among Ethereum developers looking for EVM-compatible scaling solutions.
Partnerships with major projects and ecosystems to drive liquidity and usage.
Potential integration with other blockchains beyond Ethereum.

StarkNet and zkSync are two of the most innovative Layer 2 solutions addressing Ethereum’s scalability challenges. While both rely on zk-rollups to achieve their goals, they cater to slightly different audiences and use cases:

StarkNet excels in scalability and flexibility, making it ideal for complex applications like gaming and NFTs.
zkSync prioritizes user-friendliness and EVM compatibility, appealing to developers looking for a seamless transition from Ethereum.

Ultimately, the choice between StarkNet and zkSync depends on your specific needs. If you’re building a highly scalable, custom application, StarkNet might be the better fit. If you’re looking for an easy-to-use, EVM-compatible solution, zkSync could be the way to go.

Ready to Explore StarkNet and zkSync?
Here are some resources to help you get started:

Whether you choose StarkNet or zkSync, both platforms represent the cutting edge of blockchain scalability and are paving the way for a more efficient and accessible web3 future.