DEV Community: Okoli Evans

AVNU Paymaster & Gas Sponsorship on Starknet

Okoli Evans — Sun, 22 Mar 2026 23:24:52 +0000

A Practical Guide for Building Gasless dApps

PART ONE

Understanding AVNU Paymaster

Imagine this:

You're a normal Web2 user.

You've been hearing about Web3 for a while, and you finally decide to try it out.

You find a cool game.

The UI looks clean. It feels legit for a gamer.

So you go through the process:

You install MetaMask.
You follow a YouTube tutorial.
You create your wallet.

You come back, connect your wallet, and click the main button:

"Start"

And then you see this:

"Insufficient ETH for gas fees."

You pause.

What is gas?
Why do I need ETH?
I just want to start my game…

At this point, most users don't go buy ETH.

They leave.

This is the gas fee problem — and it quietly kills Web3 adoption.

No matter how good your product is, requiring users to hold a native token before doing anything is friction most won't tolerate, especially new web3 users.

On Starknet, AVNU Paymaster has successfully fixed this problem.

Built on Starknet's account abstraction model, it allows:

Your dApp to sponsor gas fees entirely for users
Or users to pay fees in supported tokens (like USDC, USDT)

No STRK required for normal transactions.
No onboarding friction.

What Is a Paymaster?

A Paymaster is a smart contract that handles transaction fees on behalf of a user. Users do not pay gas fees — the fees are paid by a sponsor on behalf of the user.

This unlocks a UX potential for dApps running on Starknet. Coupled with native account abstraction on Starknet, builders can now achieve web2 level of UX in their applications.

PART TWO

Paymaster Setup

Setup paymaster account and create API key on AVNU portal.

Go to https://portal.avnu.fi/
Click on connect wallet and sign in
Create your account

The next page will require you to enter your name and your contact details, fill in the required details accordingly. Once you are done, click on create account and it takes you straight to your dashboard:

Click on Create Your First Key to create your API key. Enter your project name (can be anything) and click on create key.

If you got everything right, you'll see this page:

Click on add credits to fund your paymaster account. The credit is what is actually used to make payments on behalf of your users.
Monitor your dashboard

Once live, you can track everything from the dashboard — gas sponsored, success rate, number of unique accounts sponsored, burn rate, etc.

Now that we have completed the paymaster setup, next is to show how you can integrate it in your dApp.

PART THREE

Integration Guide

Prerequisites

Node.js (v18+)
JavaScript / TypeScript project

Step 1 — Install Dependencies

The PaymasterRpc class is imported directly from the starknet package. If you don't have it installed yet, add it to your project:

npm install starknet

Step 2 — Initialise the Paymaster

The PaymasterRpc class is your connection to the AVNU Paymaster service. Initialise it with your chosen network endpoint and API key:

import { PaymasterRpc } from 'starknet';

const paymaster = new PaymasterRpc({
  nodeUrl: 'https://starknet.paymaster.avnu.fi', // mainnet
  // nodeUrl: 'https://sepolia.paymaster.avnu.fi', // testnet (free)
  headers: {
    'x-paymaster-api-key': process.env.AVNU_API_KEY,
  },
});

Step 3 — Execute a Sponsored Transaction

Pass the paymaster into the Account constructor, then call executePaymasterTransaction():

import { Account, RpcProvider, PaymasterRpc } from 'starknet';

const account = new Account({
  provider,
  address: process.env.ACCOUNT_ADDRESS,
  signer: process.env.PRIVATE_KEY,
  paymaster,
});

const result = await account.executePaymasterTransaction(calls, {
  feeMode: { mode: 'sponsored' }, // You sponsor, user pays nothing
});

✅ No gas required from the user
✅ Paid from your AVNU credits

Step 4 — Secure Your API Key (Server Proxy)

Never expose your API key in frontend code.

Create a server-side proxy that forwards requests to AVNU with your key attached. Here's a Next.js example:

// app/api/paymaster/route.ts
export async function POST(request: Request) {
  const body = await request.json();

  const response = await fetch('https://starknet.paymaster.avnu.fi', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-paymaster-api-key': process.env.AVNU_API_KEY!,
    },
    body: JSON.stringify(body),
  });

  return Response.json(await response.json());
}

Here's the same pattern in an Express backend — this is taken directly from Zapcode's production wallet.js:

router.post('/paymaster', async (req, res) => {
  try {
    const response = await fetch(AVNU_PAYMASTER_URL, {
      method: 'POST',
      headers: avnuHeaders, // includes x-paymaster-api-key, stored server-side
      body: JSON.stringify(req.body),
    });
    const data = await response.json();
    res.status(response.status).json(data);
  } catch (err) {
    console.error('[paymaster]', err.message);
    res.status(500).json({ error: err.message });
  }
});

Step 5 — Use the Proxy on the Client

Point your PaymasterRpc to your own proxy route instead of directly to AVNU — your API key never touches the browser:

const paymaster = new PaymasterRpc({
  nodeUrl: '/api/paymaster', // your proxy route
});

Full Working Code Example

Here's a complete, annotated JavaScript file combining all the steps above. Replace the placeholder values with your own before running.

// avnu-paymaster-example.js
import { Account, RpcProvider, PaymasterRpc } from "starknet";
import * as dotenv from "dotenv";
dotenv.config();

async function main() {
  // 1. Set up the Starknet RPC provider
  const provider = new RpcProvider({
    // For Sepolia testnet: "https://starknet-sepolia.g.alchemy.com/starknet/version/rpc/v0_10/YOUR_ALCHEMY_KEY"
    nodeUrl: "https://starknet-mainnet.g.alchemy.com/starknet/version/rpc/v0_10/YOUR_ALCHEMY_KEY",
  });

  // 2. Initialise the AVNU Paymaster
  const paymaster = new PaymasterRpc({
    // For Sepolia testnet: "https://sepolia.paymaster.avnu.fi"
    nodeUrl: "https://starknet.paymaster.avnu.fi",
    headers: {
      "x-paymaster-api-key": process.env.AVNU_API_KEY,
    },
  });

  // 3. Set up account — paymaster is passed in the constructor
  const account = new Account({
    provider,
    address: process.env.ACCOUNT_ADDRESS,
    signer: process.env.PRIVATE_KEY,
    paymaster,
  });

  // 4. Define the contract calls to execute (we use STRK for demo)
  const STRK_ADDRESS = "0x04718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d";

  const calls = [
    {
      contractAddress: STRK_ADDRESS,
      entrypoint: "transfer",
      calldata: [
        "0xRECIPIENT_ADDRESS",  // recipient wallet address
        "1000000",               // amount (STRK has 18 decimals — adjust accordingly)
        "0",
      ],
    },
  ];

  // 5. Execute — user pays nothing, your AVNU credits cover the gas
  console.log("Submitting sponsored transaction...");
  const result = await account.executePaymasterTransaction(calls, {
    feeMode: { mode: "sponsored" },
  });

  console.log("Transaction hash:", result.transaction_hash);

  // 6. Wait for on-chain confirmation
  await provider.waitForTransaction(result.transaction_hash, {
    retryInterval: 2000,
  });

  console.log("Confirmed!");
}

main().catch(console.error);

Create a .env file in your project root:

AVNU_API_KEY=your_api_key_from_portal
ACCOUNT_ADDRESS=0xYOUR_STARKNET_ACCOUNT_ADDRESS
PRIVATE_KEY=0xYOUR_PRIVATE_KEY

Run it:

node avnu-paymaster-example.js

Testing & Verifying Your Integration

Test on Sepolia first — switch your PaymasterRpc nodeUrl to sepolia.paymaster.avnu.fi. Credits are unlimited and free.

Check your dashboard — after running a transaction, go to your AVNU Portal explorer on your dashboard. You should see:

The transaction hash appear in your logs
The gas cost deducted (on Sepolia this is simulated — no real cost)
Transaction status: confirmed or failed

Common errors:

Error	Fix
401 Unauthorised	API key is missing or incorrect — check your `.env` file
Account not compatible	Your wallet must be Ready (ArgentX) or Braavos and deployed on-chain
Insufficient credits	Top up your credit balance in the AVNU Portal (mainnet only)
Transaction rejected	Check your calldata and contract address are correct

Conclusion & Next Steps

You now have everything you need to integrate AVNU Paymaster into your Starknet dApp. To recap what you've built:

Set up your account and API key in the AVNU Portal
Initialised the PaymasterRpc provider with starknet.js
Executed a fully sponsored transaction — gas paid by your dApp
Set up a secure server-side proxy to protect your API key

Gas sponsorship is one part of the AVNU paymaster guide. In the next guide, we'll cover the second mode — letting users pay gas in any token (USDC, USDT, LORDS, wstETH, and more) — which opens up entirely new possibilities for builders on Starknet.

Useful Links

AVNU Portal — portal.avnu.fi
AVNU Paymaster Docs — docs.avnu.fi/docs/paymaster
starknet.js — starknetjs.com
GitHub — github.com/avnu-labs/paymaster

For questions or feedback, kindly leave a comment or send a message at https://x.com/okolievans

From Web2 to Web3: A Practical Guide to Building a Gasless Crypto Payment Flow (With Starknet & StarkZap)

Okoli Evans — Thu, 19 Mar 2026 10:58:54 +0000

A hands-on guide for React/Node developers to integrate wallets, social login, and USDC payments — without learning blockchain from scratch or writing many lines of code.

Why Most Web2 Developers Get Stuck trying to build on Web3

Most Web2 developers coming into Web3 hit the same wall — and usually with very little guidance.

You start with the docs, and immediately run into a wall of jargon: nonces, calldata, account abstraction, gas estimation. Before long, you’re three hours deep in a Stack Overflow rabbit hole wondering why you didn’t just use Stripe.

This guide is for developers who already know React, Node.js, or any backend stack — but haven’t really touched Web3 beyond reading about it or seeing monkey pictures on X.

By the end of this article, you’ll have built a complete Web3 payment flow:

Social login (email / Google)
Embedded wallets (no seed phrases)
Gasless transactions
On-chain USDC payments

And you’ll do it without needing to understand zero-knowledge proofs or low-level blockchain concepts.

Everything here comes from building Zapcode — a real QR-based USDC payment system on Starknet. These are production patterns, not toy examples.

What Is Starknet (And Why It Matters)

Starknet is a Layer 2 scaling network on Ethereum.

Here’s what matters in practice:

Transactions are fast
Fees are extremely low (fractions of a cent)
Security is still backed by Ethereum

Under the hood, Starknet batches transactions and proves them on Ethereum using zero-knowledge proofs. But you don’t need to think about that.

As a developer, you can treat it like:

“Ethereum — but more advanced and more scalable.”

What Is StarkZap?

StarkZap is an SDK that sits on top of Starknet and abstracts the hardest parts of Web3 development. One command to rule them all: npm install starkzap, to install Starkzap package.

Instead of dealing with:

Raw calldata
Account deployment
Signing flows
Gas mechanics

You get simple APIs.

What StarkZap Gives You

Wallet creation — no seed phrases required
Account deployment — handled automatically
ERC20 transfers — send USDC with a clean API
Fee sponsorship — users pay zero gas via AVNU
Social login — email / Google login via Privy
Bitcoin support — via Starknet cross-chain infrastructure
Staking module — for DeFi-style apps

That last one — social login — is what changes everything.

Making Crypto Feel Like Web2: Social Login

The biggest UX problem in Web3 is wallet setup.

“Install MetaMask. Save these 12 words. Don’t lose them.”

Most users drop off right there.

Privy fixes this.

Users log in with email or Google, and a wallet is created for them behind the scenes. From their perspective, it feels like any normal app.

Here’s how we set it up:

Install privy: npm install @privy-io/react-auth

then:

// apps/frontend/src/main.tsx
import { PrivyProvider } from '@privy-io/react-auth'

<PrivyProvider
  appId={import.meta.env.VITE_PRIVY_APP_ID}
  config={{
    loginMethods: ['email', 'google'],
    appearance: { theme: 'dark' },
  }}
>
  <App />
</PrivyProvider>

That’s it.

Backend Setup (Important Gotcha)

You need two Privy clients:

Installation command: npm install @privy-io/server-auth @privy-io/node

// apps/backend/src/lib/privy.js
import { PrivyClient } from '@privy-io/server-auth'
import PrivyNode from '@privy-io/node'

export const privy = new PrivyClient(
  process.env.PRIVY_APP_ID,
  process.env.PRIVY_APP_SECRET,
)

export const privyNode = new PrivyNode({
  appId:            process.env.PRIVY_APP_ID,
  appSecret:        process.env.PRIVY_APP_SECRET,
  authorizationKey: process.env.PRIVY_AUTHORIZATION_KEY,
})

This distinction matters more than it looks:

server-auth → authentication
node → wallet operations & signing

If you mix them, things break in non-obvious ways.

Onboarding a User Wallet

When a user scans a QR code in Zapcode, we need to:

Create a wallet
Fund it (for deployment)
Deploy it on-chain
Make it usable

StarkZap handles most of this:

// apps/frontend/src/pages/PayPage.tsx
const sdk = new StarkZap({
  network: 'mainnet',
  paymaster: { nodeUrl: `${API_URL}/api/wallet/paymaster` },
})

const onboard = await sdk.onboard({
  strategy:      OnboardStrategy.Privy,
  accountPreset: accountPresets.argentXV050,
  deploy:        'if_needed',
  feeMode:       'user_pays',
  privy: {
    resolve: async () => {
      const token = await getAccessToken()
      const res   = await fetch(`${API_URL}/api/wallet/starknet`, {
        method:  'POST',
        headers: { Authorization: `Bearer ${token}` },
      })
      const { wallet: w } = await res.json()
      return {
        walletId:  w.id,
        publicKey: w.publicKey,
        serverUrl: `${API_URL}/api/wallet/sign`,
      }
    },
  },
})

The key part:

deploy: 'if_needed'

First-time users get deployed. After that, it’s invisible.

The One Catch: Account Deployment Costs

AVNU sponsors transactions — but not account deployment.

New wallets must pay a small STRK fee.

How We Solved It

We use a treasury wallet:

const BUYER_PREFUND = BigInt('300000000000000000') // 0.3 STRK

await sendStrk(wallet.address, BUYER_PREFUND, 'buyer')

This is a one-time cost per user.

After that → everything is gasless.

Sending a USDC Payment

Here’s the actual payment logic:

const tx = await walletRef.current.execute(
  [{
    contractAddress: USDC_MAINNET,
    entrypoint:      'transfer',
    calldata:        [
      merchant.walletAddress,
      String(Math.round(parsed * 1_000_000)),
      '0',
    ],
  }],
  { feeMode: 'sponsored' },
)

From the user’s perspective:

Click → Pay → Done

No gas. No wallets. No confusion.

Gasless Transactions (How It Works)

AVNU’s paymaster covers gas fees:

router.post('/paymaster', async (req, res) => {
  const response = await fetch('https://starknet.paymaster.avnu.fi', {
    method:  'POST',
    headers: {
      'Content-Type':        'application/json',
      'x-paymaster-api-key': process.env.AVNU_API_KEY,
    },
    body: JSON.stringify(req.body),
  })
  const data = await response.json()
  res.status(response.status).json(data)
})

Why This Matters

Users don’t need:

ETH
STRK
Any understanding of gas

This removes one of the biggest barriers in Web3 UX.

Server-Side Signing

router.post('/sign', async (req, res) => {
  const { walletId, hash } = req.body

  const result = await privyNode
    .wallets()
    .rawSign(walletId, { params: { hash } })

  res.json({ signature: result.signature })
})

StarkZap handles calling this automatically.

Real-World Flow (Zapcode)

Here’s what the full system looks like:

Merchant signs up → gets wallet + QR code
Buyer scans → logs in with email
Wallet created + deployed automatically
Buyer enters amount → clicks Pay
USDC transfers instantly (gasless)

All without users knowing anything about crypto.

Common Pitfalls (Learned the Hard Way)

Starknet.js v9 changed Account constructor
You must use two Privy clients
Wallet ownership depends on your authorization key One way to avoid silent errors is to use the latest versions of the packages.

Final Thoughts: Web3 Is Finally Usable

You don’t need to understand zero-knowledge proofs to build on Starknet.

You don’t need to know what account abstraction means to ship a real product.

StarkZap handles the complexity — you focus on the experience.

If you’re a Web2 developer who’s been curious about Web3 but kept bouncing off the complexity wall:

This is your way in.

The tooling is ready.

The UX is finally good enough and getting better.

You can ship real applications now in just a few lines of code. Use Starkzap.

Resources

Zapcode Live: https://zapcodex.netlify.app/
Zapcode Github: https://github.com/OkoliEvans/zapcode

StarkZap: https://github.com/keep-starknet-strange/starkzap
StarkZap sample codebases and projects: https://github.com/keep-starknet-strange/awesome-starkzap

AVNU: https://portal.avnu.fi

Privy: https://privy.io

If you build something with StarkZap, drop it below.

I’d genuinely love to see what you ship.

Understanding Digital Signatures: The Role of v, r, s in Cryptographic Security and Signature Verification.

Okoli Evans — Sun, 11 Jun 2023 20:27:41 +0000

Pre-script: This article is not intended for newbies, knowledge of Ethereum and/or solidity is presumed.

Transactions on Ethereum are signed messages originating from Externally Owned Accounts (EOAs). There are more to this simple description though, as not all of such messages are valid transactions. Valid transactions must contain these required parameters: Nonce, Recipient, Value, Data, Gas price, Gas limit, Chain Id and v, r, s, and the transaction must be signed using the EOA’s private key (and we’ll see why shortly).

Understanding the concept of digital signatures without prior understanding of the components of that signature may be a bit much for some people, so we’ll first try to explain some of these concepts (of course these concepts are well detailed in the Ethereum book).

Nonce is an acronym for Number used ONCE. It’s an integer that keeps track of the number of messages signed and transmitted from an account. It increments per transaction, and a nonce cannot be used more than once. Any transaction signed with an already used nonce is rejected by the network.

Value is the amount of ether or token forwarded with the message. Transactions containing only values are known as ‘payments’.

Data is the payload forwarded with the transaction. These are mostly function calls (payload containing function selector) directed to contract accounts, as most EOAs do not contain bytecodes and hence cannot handle such calls. Transactions containing only data are known as ‘invocations’. Aside from these, transactions can also contain both data and value, or nothing at all.

Chain ID represents the blockchain network to which the transaction is to be sent. The use of chain id means that transactions created for one blockchain cannot be valid on another blockchain. This protects transactions from replay attacks, as transactions become invalid if sent to another network. (see EIP-155 for more on this).

v, r, s are signature variables generated from EOA’s private keys and used for digital signatures creation and verification. (More on this shortly).

The Idea of Private keys and Public keys
Private keys are a secret set of randomly generated integers used in cryptography for creating public keys and signing transactions. These keys are neither required nor transmitted on Ethereum network, they are sole properties and responsibilities of EOAs, and anyone with access to them has access to all the accounts generated from that private key.

Now, how do we generate public keys from private keys? Magic.

Ethereum makes use of public key cryptography, also known as asymmetric cryptography, to create public-private key pairs. Elliptic curve cryptography (which is a form of asymmetric cryptography) is used to calculate the public key from the private key in an irreversible equation using the elliptic curve algorithm secp256k1.

Two things to bear in mind:
i) ‘A public key is a point on the elliptic curve, meaning it is a set of x and y coordinates that satisfy the elliptic curve equation’. Hence public keys are two numbers joined together, each number representing a point on the elliptic curve.

ii) The elliptic curve algorithm used to calculate these points is a one way function. In practice it is very easy to calculate the public key from a private key, but impossible to reverse the process and recover the private key that generated that public key. This means that the algorithm cannot be reversed to get a private key that generated a public key. Not even quantum computers have been able to achieve this.

Transaction serialization

Now that we understand the concept of public and private keys and how they are generated, let us go a step further to explain how transactions are serialized before they are broadcasted to the network.

Serialization is the concept of preparing signed messages for broadcast to the Ethereum network by using a particular function (algorithm) to create a particular sequence of bytes. The function used for formatting the transaction is a generally accepted standard on the network, such that transactions formatted with this standard are accepted on the blockchain irrespective of the library, language or application used by any particular node. On the Ethereum network the standard used for this purpose is the RLP encoding algorithm (the Recursive-length prefix algorithm).

Concept of Digital Signatures

Digital signatures are synonymous with traditional official signatures. It’s simply a way to authorize a transaction or message on the internet. Any signed transaction contains a digital signature, and the signature is a proof of validity of such message.

Digital signatures are very important because they provide a proof of the account where a transaction originates from (tx.origin in Solidity), and the signer of such a transaction cannot deny that the signature originated from his account. Digital signatures also provide proof that the content of a message or transaction is not tampered with, because any change in the content of the message will produce a signature entirely different from the original one.

How Digital Signatures are Created

On the lower level, digital signatures are generated from Elliptic Curve Digital Signature Algorithm ( ECDSA ), and this algorithm consists of two parts. The first part is the signature creating algorithm, while the second part is the signature verifying algorithm.

Digital signatures are created when a private key signs an already serialized transaction. Actually the serialized transaction here is the Keccak256 hash of the RLP-encoded message. The mathematical function for signing transaction is:

S i g = Fsig(Fkeccak256(m), k)
where: k = the signing private key
           m= the RLP encoded message
           Fkeccak256 = Keccak256 hash function
           Fsig = the signing algorithm
           Sig = the resulting signature

The function Fsig produces a signature (S i g) that generates the two values r and s, which are instrumental in signature verification. S i g = r, s
(more on this in the Ethereum book referenced below).

I found this explanation by Svetlin Nakov, (PhD) to be very detailed and thus helpful:

“The ECDSA signing algorithm (RFC 6979) takes as input a message msg *+ a private key privKey *and produces as output a signature, which consists of a pair of integers {r, s}.

…The calculated signature {r, s} is a pair of integers, each in the range [1...n-1]. It encodes the random point R = k * G, along with a proof s, confirming that the signer knows the message h and the private key privKey. The proof s is by idea verifiable using the corresponding pubKey.”
(See reference for more info or links ).

Signature Verification
This is handled by the second part of the ECDSA algorithm. To verify a transaction one must have the signature ( r and s ), the serialized transaction and the public key. This public key must correspond to the private key used in signing the transaction initially. The signature verification algorithm takes these listed components and returns a boolean value depending on if the signature is valid or not; true for valid signature, false for invalid. The mathematical computations and the processes involved are complex and cannot be covered in this article, but below is the summary of the verification process (again, as explained in Svetlin Nakov’s book):

i. Calculate the message hash, with the same cryptographic hash function used during the signing.

ii. Calculate the modular inverse of the signature proof, that is the inverse of signature generation function (see function above).

iii. Recover the random point, r, generated during the signing from the x-coordinate.

iv. Generate from R' its x-coordinate: r' = R'.x

v. Calculate the signature validation result by comparing whether r' == r

“The general idea of the signature verification is to recover the point R' using the public key and check whether it is the same point R, generated randomly during the signing process.”

Again, this is a simple summary of the entire concept of signature generation and verification, by Sveltin Nakov:

“The signing signing encodes a random point R (represented by its x-coordinate only) through elliptic-curve transformations using the private key privKey and the message hash h into a number s, which is the proof that the message signer knows the private key privKey. The signature {r, s} cannot reveal the private key due to the difficulty of the ECDLP problem.

The signature verification decodes the proof number s from the signature back to its original point R, using the public key pubKey and the message hash h and compares the x-coordinate of the recovered R with the r value from the signature.”

The signature is valid if the x-coordinate recovered, r’, is the same as the one randomly generated during the signing, r.

What about v?
As already explained, in public key generation using elliptic curve cryptography, two possible public keys are generated at every instance. This is because the elliptic curve algorithm is symmetry across the x-axis, so for any value of x that is generated, there are two possible values that fit the curve; one on each side of the x-axis.
Question now is, how does this algorithm pick the correct value of x to concatenate with the y value? This is where v comes in.

According to the Ethereum Yellow paper, “ v is a 1 byte value specifying the parity and finiteness of the coordinates of the curve point for which r is the x-value.”

To make it simpler, v is added to the signature verification function to help detect the correct value of r between the two possible generated values R and R’. If v is even, the R is the correct value, if v is odd, then R’.

For more clarification, this is a snippet from the Ethereum book:
“At block #2,675,000 Ethereum implemented the "Spurious Dragon" hard fork, which, among other changes, introduced a new signing scheme that includes transaction replay protection (preventing transactions meant for one network being replayed on others). This new signing scheme is specified in EIP-155. This change affects the form of the transaction and its signature, so attention must be paid to the first of the three signature variables (i.e., v), which takes one of two forms and indicates the data fields included in the transaction message being hashed.

…The special signature variable v indicates two things: the chain ID and the recovery identifier to help the ECDSArecover function check the signature. It is calculated as either one of 27 or 28, or as the chain ID doubled plus 35 or 36.

…The recovery identifier (27 or 28 in the "old-style" signatures, or 35 or 36 in the full Spurious Dragon–style transactions) is used to indicate the parity of the y component of the public key.”

The whole idea of Spurious Dragon upgrade was to mitigate the security challenges of replay attacks and signature malleability, and this was achieved by the introduction of chain ID and recovery identifier into the variable v.

ECRECOVER

ecrecover is a global function in solidity used for signature verification. It takes the massage hash and the signature verification variables v, r, s, and returns an address. The returned address can then be compared against other addresses to find a match.

address signer = ecrecover(msgHash, v, r, s);

SECURITY ALERT: The ecrecover function above is vulnerable to signature replay attack because of the reasons already explained above, so do well to avoid using it in your contracts. Openzeppelin’s ECDSA library is secure and tested for this purpose.

Conclusion

Cryptography is the backbone of blockchain technology. And a public system for value exchange and transactions such as the blockchain should be 100% secure, and should also ensure data integrity, authenticity and confidentiality.

Digital signature is an efficient way to not only keep track of transaction origins, but also to ascertain that transactions are not compromised after they are signed and transmitted. The creation and verification of digital signatures are made possible by the variables v, r, s.

If you find this article interesting, or perhaps cryptography, these resources are available for you.

Resources:
https://ethereum.stackexchange.com/questions/45461/verify-ecdsa-signature-in-solidity -> ECDSA and signature verification implementations

https://ethereum.stackexchange.com/questions/79302/why-do-we-use-serialize-function-of-ethereumjs-tx-package-before-broadcastin -> RLP encoding and tx serialization

https://ethereum.github.io/yellowpaper/paper.pdf -> Ethereum Yellow Paper

https://github.com/ethereumbook/ethereumbook/blob/develop/06transactions.asciidoc#digital-signatures -> Ethereum book: Digital Signatures

https://cryptobook.nakov.com/digital-signatures/ecdsa-sign-verify-messages -> Sveltin Nakov: Digital signatures

https://medium.com/cryptronics/signature-replay-vulnerabilities-in-smart-contracts-3b6f7596df57 -> Signature Vulnerabilities

Ethereum as a Global State Machine.

Okoli Evans — Sat, 28 Jan 2023 18:01:05 +0000

Right from inception, the Ethereum project was clearly spelled out in a well prepared document called Ethereum whitepaper. Ethereum has always been developed, tweaked and updated to meet the goal that is the Ethereum project.

What is the Ethereum project? A short summary to this question is that Ethereum was born to be a global state machine that is truly decentralized.

The word global here is pretty self-explanatory... leaving us with state machine.

A global state machine is a globally distributed system that achieves and maintains one outcome or result simultaneously across its entire network. State here refers to the current result at that instant. On a state machine, the outcome is always the same across the entire system or networks, or in the case of Ethereum, nodes.

Now, maintaining a state on a distributed network implies that there is a mechanism to track the change in state in real time across the entire network; this also implies that the entire distributed networks when given a set of code must arrive at the same result after executing the program.

So how do we track state transitions across a global network of computers? It gets tricky... to ensure that Ethereum network is deterministic, all the nodes(computers) across the world that powers the Ethereum blockchain must run an Ethereum compliant program called client.

An Ethereum client must not necessary be written in a particular programming language, but it must be written according to the specifications provided in the Ethereum yellow paper (different from Ethereum white paper).
Those programs written according to the Ethereum specifications are called Ethereum clients.

Ethereum clients, when installed and ran on a computer connects that computer to the Ethereum blockchain network.
Anybody can download any of these clients and install on their system and become an Ethereum node.

Once such system successfully connects to the Ethereum blockchain network, it will download past records of the transactions recorded on the network... afterwards it will become a fullnode; and a validator if the owner meets the preset requirements.

Ethereum is not just distributed, it is also decentralized. That is why it depends on independent computers across the world to run the network. No single computer has a control over what happens on the network, decisions are collectively made by the majority of all the computers on the network. The process by which this democracy is achieved on the network is overseen by an algorithm known as 'consensus mechanism'.

PS: This is still pretty high level; no very technical stuff yet. Anyone can easily understand even without any prior knowledge of blockchain network. If you are intrigued by what you read, feel free to dive down the rabbit hole; simply type in 'what is blockchain technology' on Google and take it on from there. Cheerio.

programming #blockchain #Ethereum #ethereumblockchain

Err: fetching data via API works on localhost but doesn't work on live server

Okoli Evans — Wed, 07 Sep 2022 05:34:55 +0000

As a young developer, there are some minor bugs you might encounter that will be pretty confusing. Every new developer, and even experienced devs encounter this every now and then. The thing about software development is that a single comma, semicolon or colon in a wrong place will likely make your code not compile, or render an element or function undefined.

When I started out newly, I once spent two days searching for a bug, only to find out that the issue was just a '}' in a wrong place... bugs are completely normal.

So I was working on a demo movie app some time ago, it happened that the API fetch and every components worked perfectly on localhost, but wasn't fetching when deployed on live server. It was really confusing for me then that I had to abandon the project altogether. Recently I was going through my repositories and found the abandoned project, so I decided to try and fix it.

Issue:

const handleSubmit = async () => { setLoading(true); const response = await fetch( `http://www.omdbapi.com/?s=${searchParam}&apikey=70c11897` ); const data = await response.json(); console.log(data); if (data) { setMovieList(data.Search); localStorage.setItem("movieList", JSON.stringify(data.Search)); setLoading(false); setSearchParam(""); } };

It turned out that the problem was a very simple one. The API URL I was using was 'http://apiurl.com/key'. Now the problem is most web engines don't render insecure links, so my API URL was blocked from fetching data on live server. The simplest solution right? All I needed to do was add 's' to the 'http' like so 'https://apiurl.com/key'.

Fixed:

const handleSubmit = async () => { setLoading(true); const response = await fetch( `https://www.omdbapi.com/?s=${searchParam}&apikey=70c11897` ); //notice the 's' now added to 'http' const data = await response.json(); console.log(data); if (data) { setMovieList(data.Search); localStorage.setItem("movieList", JSON.stringify(data.Search)); setLoading(false); setSearchParam(""); } };

Like I said, some bugs can be pretty confusing for beginners, but hey, even the best developers were once beginners and coding is one skill that requires tenacity, determination and resourcefulness. So when you encounter a bug, seek for solution on open source websites or ask experienced devs for help. I hope this helps someone. ☺