DEV Community: Allan Githaiga

How I connected a React frontend to an ink! smart contract using Polkadot-API (PAPI)

Allan Githaiga — Sat, 27 Sep 2025 04:29:56 +0000

👋 Hey builders,
Have you ever tried connecting a frontend to a blockchain contract and felt like you were solving a Rubik’s cube in the dark? Yeah… me too. 😅

That’s why I wrote this guide, to walk you step-by-step through how I managed to connect a React + Vite frontend to an ink! smart contract using PAPI (Polkadot-API).
Spoiler alert: once I figured out the workflow, it felt less like rocket science and more like following a recipe. 🚀✨

Why this guide?

Instead of drowning in docs and scattered tutorials, I wanted a single walkthrough that shows:

How to build & deploy an ink! contract.
How to generate type-safe bindings with PAPI.
How to make a frontend talk to the contract through a wallet.

If you’ve been curious about ink! + PAPI but don’t know where to start, this article is for you. 🙌

Why PAPI?

Polkadot-API (PAPI) is the modern, modular JavaScript/TypeScript SDK for building dApps in the Polkadot ecosystem. It provides strong TypeScript support, a light-client-first approach, and SDKs (including an Ink! SDK) that generate typed bindings from contract metadata — making contract interactions safer and easier to write.

What I built

A small dApp that::

Connects to a browser wallet (Polkadot.js / Talisman).
Reads the current counter value (read-only query).
Increments or decrements the counter (signed transaction).

The contract metadata is included in the repo and PAPI generated TypeScript descriptors were used to produce strongly typed calls.

Steps I followed (practical)

1. Build the ink! contract
Install cargo-contract and build:

cargo install cargo-contract --force
cargo contract build --release

This produces the .contract artifact and metadata required by PAPI.

2. Generate PAPI descriptors from the .contract

I used the PAPI CLI to add my chain and the contract metadata:

pnpm papi ink add -k counter ./contracts/counter.contract
pnpm papi generate

This generates typed descriptors in frontend/.papi/ which are importable in the frontend.

3. Frontend: create client & Ink SDK

In src/papiClient.ts:

import { createClient } from "polkadot-api";
import { withPolkadotSdkCompat } from "polkadot-api/polkadot-sdk-compat";
import { getWsProvider } from "polkadot-api/ws-provider/web";
import { createInkSdk } from "@polkadot-api/sdk-ink";
import { contracts } from "@polkadot-api/descriptors";

const client = createClient(
  withPolkadotSdkCompat(getWsProvider("wss://westend-rpc.polkadot.io"))
);

const inkSdk = createInkSdk(client.getTypedApi("westend"), contracts.counter);

export { inkSdk };

This gives typed, chain-aware contract helpers.

4. Wallet connection & signer

I used PAPI’s pjs-signer helpers to connect the Polkadot.js/Talisman extension and obtain a polkadotSigner to sign transactions:

import { getInjectedExtensions, connectInjectedExtension } from "polkadot-api/pjs-signer";
const exts = getInjectedExtensions();
const selected = await connectInjectedExtension(exts[0]); // choose extension
const accounts = selected.getAccounts();
const signer = accounts[0].polkadotSigner;

The signer implements the PolkadotSigner interface that PAPI methods accept.

5. Query and send

Using the Ink SDK:

const instance = inkSdk.getContract(CONTRACT_ADDRESS);

// Query counter
const current = await instance.query("get", { origin: accounts[0].address });
console.log("Counter value:", current.output);

// Increment
await instance.send("increment", { origin: accounts[0].address })
  .signAndSubmit(signer);

// Decrement
await instance.send("decrement", { origin: accounts[0].address })
  .signAndSubmit(signer);

The SDK exposes .query(...) and .send(...).signAndSubmit(...), very helpful for dry-runs and signed transactions.

Final notes & tips

Use the generated descriptors, they save time and reduce errors.
papi.how
Always use dry-runs (.query() or .dryRun()) before sending signed txs to check gas/storage cost.
papi.how
Do not commit private keys to the repo; use browser wallets for signing.
papi.how

Links & resources

PAPI docs & guide (Polkadot Developer Docs).
docs.polkadot.com
PAPI ink! guide (codegen & usage).
papi.how
Ink! SDK docs (createInkSdk, getDeployer, getContract).
papi.how
Signers / pjs-signer usage.
papi.how
cargo contract build (ink! docs).
ink!
Vercel & Netlify deploy docs.
Vercel

🧠 Understanding Ethereum: EVM, Blocks, Gas, Accounts & Transactions Explained

Allan Githaiga — Thu, 17 Jul 2025 14:27:09 +0000

Ethereum is more than just transfers of ETH — it’s a decentralized global computer powered by nodes and fueled by gas. Let’s break down its core components to help you grasp why it works the way it does.

🔍 1. The Ethereum Virtual Machine (EVM)

What it is: The EVM is the runtime engine powering Ethereum, a virtual CPU that runs smart contracts and processes transactions.

Why it matters:

It ensures every node executes code deterministically, so all states stay in sync.
It supports a defined set of opcodes (like ADD, JUMP, SLOAD), with each costing gas based on the amount of computation required .

Analogy:
Think of Ethereum as a massive online code playground, and the EVM as the consistent engine that runs your code—even on someone else’s computer. Every time you press "execute," it runs exactly the same way.

⛓️ 2. Blocks: Ethereum’s Time Capsules

What it is: Ethereum groups transactions into blocks, each containing:

Block number, timestamp
Gas limit (cap for total gas used) & gas used

Transaction list, Merkle roots, parent hash, and proposer’s signature.
Why it matters:
Blocks batch transactions to maintain consensus across nodes.
Each block advances the state, forming a permanent ledger of changes.

Analogy:

Blocks are like train cars, each carrying multiple passenger transactions and connected to the previous one to form a train—a never-ending ride.

⛽ 3. Gas: Ethereum’s Fuel Meter

What it is: Gas measures how much computation you're using. Every EVM opcode requires a specific gas amount .
Why we pay gas:

It prevents spam and infinite loops.
It pays validators for computation.
It ensures execution stays deterministic and bounded.

Gas Units vs. Gwei:

Gas units = computational steps
Gwei = 10⁻⁹ ETH, used to price each gas unit.

🧠 Example with Analogy:
Imagine riding a motorbike:

Distance = gas units
Fuel price per km = base fee + priority tip
You load your bike with just enough fuel (gas limit) and tip for priority service (priority fee).

🧮 4. Accounts: EOAs vs. Contract Accounts

Ethereum has two account types

1. EOA (Externally Owned Account)

Controlled by a private key
Can initiate transactions
No code, just ETH balance

2. Contract Account

Live code at an address
Can store data, and run logic when triggered
Cannot initiate transactions—EOAs must call them

Analogy:
EOAs are like people with wallets, while contract accounts are like vending machines: they respond to your actions, they can hold funds, but they don’t make moves on their own.

🚀 5. Transactions: State-Changing Actions

What they are: The only way to change Ethereum’s state (send ETH, create contracts, interact with smart contracts).

Transaction content includes:

from, to, value, nonce
gasLimit, maxFeePerGas, maxPriorityFeePerGas
data (optional), signature components

Stages of a transaction:

Signed by your private key
Broadcast to mempool
Picked by a validator
Executed, state updated, included in a block
Block finalized—permanent record

Analogy:
Think of it like ordering at a busy coffee shop:

You put in your order (transaction)
It goes on the queue (mempool)
A barista (validator) makes it (executes)
You wait until they confirm your order is done (block inclusion)
You finally drink it when it’s served (finalization)

🔄 Recap Table

Component	What It Does	Why It Matters
EVM	Runs smart contract bytecode	Ensures consistent behavior across all nodes
Blocks	Batch transactions into permanent records	Maintain global state and ledger
Gas	Measures computation, controls use	Prevents abuse, rewards validators
EOA	User-controlled account with balance	Initiate transactions
Contract	Code and state living on-chain	Enables programmable logic
Transaction	Signed messages changing state	The only way to interact with Ethereum

🎯 Why This Matters

By understanding these pillars:

You’ll optimize gas usage
Avoid common errors like low gas limits
Build or interact with contracts more confidently
Understand transaction lifecycles and how fees work

What the Heck Are EIPs and ERCs? A Beginner’s Guide to 4 Ethereum Upgrades You’ve Never Heard Of

Allan Githaiga — Wed, 16 Jul 2025 13:05:40 +0000

They might not trend on Crypto Twitter—but without them, Ethereum wouldn't run this smooth. - Allan Robinson

🧭 What Are EIPs and ERCs?

EIPs (Ethereum Improvement Proposals) are Ethereum’s official feature requests or improvements, typically targeting protocol-level changes (e.g., transaction formats, gas fees).
ERCs (Ethereum Request for Comments) are a subset of EIPs focused on smart contract standards, used to ensure compatible interfaces across dApps.

They emerged as community-driven blueprints to evolve Ethereum in a consistent, transparent, and coordinate-driven way.

📜 History & Impact

The EIP process began with EIP-1 in 2015 to formalize how Ethereum should evolve.
Early successful proposals like EIP-20 (ERC-20) established core patterns for the ecosystem.
Over time, new needs arose: better transaction gas efficiency, clearer contract interoperability, and fairer developer incentives.
Thanks to EIPs and ERCs, Ethereum continues to grow backward-compatible while integrating new features without breaking older systems.

🛠️ Deep Dive into 4 Selected Standards

1. EIP‑2930: Access Lists (Core / Transaction Format)

🔍 Overview

Introduced in Berlin (2020) as part of a suite addressing storage cost spikes (alongside EIP-2929)
Lets you pre-declare which contract addresses/storage slots your tx will access.
Those slots are “pre-warmed” at lower cost, avoiding high “cold” access charges.

✅ Benefits

Saves ~200 gas per storage access
Reduces volatility and DoS attack risk from expensive cold storage.

❌ Drawbacks

Requires users/devs to predict exactly which slots will be used—mistakes can cost more gas than savings.
Adoption has been low: just ~1.5% of txs use it despite 42% potential benefit

⚙️ Analogy

Think of it like a grocery preorder: tell the store what you’ll need in advance and skip checkout lines—but if you order the wrong things, you wasted time and money.

2. EIP‑7547: Inclusion Lists (Core / Block Assembly)

🔍 Overview

A new proposal letting block proposers force inclusion of specific transactions in a block, reducing censorship
Especially useful for front-running, MEV-resistant applications.

✅ Benefits

Enhances fairness and censorship resistance in the mempool.
Empowers transaction originators to battle MEV-based exclusion.

⚠️ Considerations

Still under development.
Needs client & tooling support to become practical.

⚙️ Analogy

It’s like a VIP pass for users who want to ensure their ticket gets scanned even during rush hour.

3. ERC‑165: Interface Detection (Contract Interface Standard)

🔍 Overview

Standardizes how contracts announce which interfaces they implement—used widely since 2018
Contracts implement supportsInterface(bytes4 interfaceID) so others can detect capabilities.

✅ Benefits

Enables dynamic compatibility checks for wallets/dApps.
Avoids hard-coded assumptions, reducing risk of breakage.

❌ Drawbacks

Needs explicit implementation—some contracts skip it to save gas.
Only covers declared interfaces; doesn’t guarantee full compliance.

⚙️ Analogy

Like a software installer that checks if your system supports .NET 6 before installation—no surprises later.

4. EIP‑6969: Revenue-Sharing Contracts (ERC – Token & Wallet Standard)

🔍 Overview

A new proposal for sharing transaction fees (beyond ETH’s built-in burn/tip) with contract creators
- Users opt-in to send a developer fee to the dApp creator on each use.

✅ Benefits

Creates an incentive model for public dApps to be sustainable.
Offers an optional “tip” model for open-source contract authors.

⚠️ Controversies

May discourage usage if tips are high.
Needs to balance opt-in vs auto-fee structures.

⚙️ Analogy

Like paying 10% tip for offline delivery services you trust—optional but appreciated.

📊 Comparison Table

EIP/ERC	Category	Purpose	Adoption Status
EIP‑2930	Core / Tx	Improve gas for predefined access	Low adoption (~1.5%)
EIP‑7547	Core / Blocks	Censorship resistance via inclusion lists	Early draft
ERC‑165	Interface	Standard method to declare support	Widely adopted (NFTs, tokens)
EIP‑6969	ERC / Payments	Revenue-sharing tips to contract authors	Emerging interest

🔍 Final Takeaways

Access Lists (EIP‑2930) streamline gas costs—but you must think ahead.
Inclusion Lists (EIP‑7547) will help fairness in transaction ordering, ideal for censor-resistant apps.
ERC‑165 remains vital for automatic interface compatibility, powering wallet and dApp integrations.
Revenue-sharing (EIP‑6969) introduces an open tipping model, potentially sustaining free-to-use contracts.

🎯 Why These Matter for Beginners

Understanding why these standards were invented helps future developers reason about protocol design and usability, not just code.
- Seeing each EIP as a solution to a real problem—gas costs, censorship, interface detection, developer sustainability—makes you think like a protocol designer.
- Analogies keep concepts memorable and relatable.

Standards aren’t just code—they shape how Ethereum grows. - Allan Robinson

🚀 Unlocking Ethereum: From Magic Money to Math-Powered Machines

Allan Githaiga — Sat, 12 Jul 2025 18:46:39 +0000

"Not all computers live in your house. Some live everywhere." — Allan Robinson

🙋 Hey there, curious builder!

If you’ve been following along on this journey from Chapter 1 to Chapter 4 of the Ethereum Book, congratulations! You’ve taken your first real steps into understanding what makes Ethereum the beating heart of the Web3 revolution. But now, let’s tie it all together.

This article will serve as your grand recap. We’ll walk back through the major milestones you’ve hit — from installing MetaMask to unraveling the mathematical magic behind Ethereum addresses. But we’re going deeper this time, with clear explanations, descriptive breakdowns, and some jokes and analogies to make it fun.

🌍 Chapter 1: Ethereum — The Decentralized World Computer

Ethereum is not just a cryptocurrency.
It’s a decentralized world computer, where code is law and contracts live forever.

Imagine the internet, but with programmable money and no central administrator.
That’s Ethereum.

In this chapter, we:

Installed MetaMask, your Web3 portal.
Created a wallet (a safe for your digital coins).
Funded it using a testnet faucet.
Sent and received Ether — the fuel of Ethereum.

"Think of Ether as gas in a car. Ethereum is the engine. Smart contracts are the destination."

Ethereum allows anyone to deploy smart contracts — bits of code that live and operate independently on the blockchain. These contracts can't be tampered with once deployed. That’s a game-changer for trust, accountability, and decentralization.

💰 Chapter 2: Wallets, Contracts, and the Machine Brain

Once your MetaMask wallet was ready, you discovered two types of accounts:

🪖 Externally Owned Accounts (EOAs):

Controlled by private keys.
Can initiate transactions.
These are your regular wallet accounts.

🧰 Contract Accounts:

Controlled by code, not keys.
Can hold Ether and respond to transactions.
Cannot initiate transactions but can react to them.

We even wrote our first smart contract: Faucet.sol.

It allowed:

Users to withdraw up to 0.1 ETH.
Anyone to send ETH to it.

You deployed it on a testnet using Remix IDE.

This was your first encounter with the Ethereum Virtual Machine (EVM) — the brain that runs all smart contracts in the Ethereum world. Think of it as a global computer made up of thousands of nodes all syncing together.

🔐 Chapter 3 & 4: Cryptography — Ethereum’s Security Backbone

Ethereum is secure by math, not by secrecy.

This is where things got spicy.
We talked cryptography — the silent engine that makes Ethereum work.

Cryptography doesn’t hide data, it proves truths.

We explored:

Public key cryptography (asymmetric cryptography).
Digital signatures.
Trapdoor functions.
Elliptic curve cryptography.

🔑 Private Keys:

A private key is just a really big random number.
It gives you control over your Ethereum wallet.
It must NEVER be shared. Sharing your private key = giving away your money.

"Your private key is your soul. Lose it, and your crypto reincarnates into someone else's wallet."

👁‍🗨️ Public Keys:

Derived from the private key using elliptic curve multiplication.
Can be shared. They help the world recognize your account.
Used to verify digital signatures.

🔹 Ethereum Addresses:

Shortened versions of the public key (via hashing).
Every wallet has one (e.g., 0xabc123...).
Acts like a username for the blockchain.

Together, these elements enable secure, verifiable ownership of funds without any central authority.

🔹 The Discrete Logarithm Problem & Elliptic Curve Math

Ethereum uses a form of math called Elliptic Curve Cryptography (ECC) over a curve known as secp256k1.

Private Key k is a number.
Multiply it with a point G on the curve: k * G = K, the Public Key.
You can go from private to public, but NOT the reverse. Why?

Because that would involve solving the Discrete Logarithm Problem.

"It’s like trying to unblend a smoothie. Good luck getting that one blueberry back."

This one-way math gives us digital signatures and the ability to prove ownership without revealing secrets.

✨ The Magic of Digital Signatures

Every Ethereum transaction is a message signed with your private key.

The network can verify:
Who sent it (via public key).
That the message wasn’t altered (hash matching).

That it came from a valid source.

But it can do all this without knowing the private key itself. Pure cryptographic sorcery.

💜 Why This All Matters

This system allows:

Peer-to-peer payments.
Smart contract execution.
Fully decentralized apps (dApps).
A global trustless economy.

All without:

Banks.
Passwords.
Centralized control.

You now understand how your Ethereum wallet works, how transactions are signed, and why no one can just "guess" your key.

And that, my friend, is the magic behind the Ethereum World Computer.

🎉 What’s Next?

You’ve just finished the foundation:

Ethereum basics
Wallets and contracts
Cryptography, private keys, and addresses

Up next? We dive deeper:

Solidity smart contracts
Gas optimization
Attacks & defenses

The move to Proof of Stake

So stay curious. Keep coding. And never share your private key.

See you on-chain.

🔐 Cryptography in Ethereum

Allan Githaiga — Sat, 12 Jul 2025 16:12:36 +0000

Cryptography is one of the most important technologies behind Ethereum and other blockchains. Even though it sounds complicated, at its heart, it’s all about keeping things secure, proving ownership, and ensuring data can’t be faked or tampered with.

Let’s break down what cryptography means in the Ethereum world — in the simplest terms possible.

📘 What Is Cryptography?

Cryptography comes from a Greek word meaning “secret writing”. It’s the study of how to secure information using math. But it’s not just about hiding things — it also helps:

Prove something is true without showing it (like proving you know a password without telling it).
Prove data is authentic (like checking a digital fingerprint).

Ethereum does not use encryption to hide messages — everything is open and visible so the network can agree on the correct state. But it does use cryptography to verify and secure who owns what.

🔑 Keys and Addresses

🧍‍♂️ Accounts in Ethereum

There are two main types:

EOAs (Externally Owned Accounts) — controlled by private keys (what users use).
Smart Contracts — code-based accounts that live on Ethereum.

Every EOA has:

A private key — a secret number that proves control.
An Ethereum address — a public identity others can see.

Think of it like this:

Your address is your bank account number (public).
Your private key is your ATM PIN (secret).

You can’t get someone’s private key by looking at their address. But if you have the private key, you control the account and the funds in it.

🖋️ Digital Signatures: Proving Ownership

Every transaction on Ethereum must be signed using the private key. This creates a digital signature, which proves:

The transaction is authentic.
It could only have come from the person who owns the private key.

This signature is then verified by others using your public key (or Ethereum address). The private key is never shared — it stays hidden.
So, when you send ETH:

You sign the transaction with your private key.
The network checks the signature against your address.
If it matches — the transaction is valid!

🧠 How Do Private and Public Keys Work?

Ethereum uses a form of cryptography called Public Key Cryptography, also known as Asymmetric Cryptography.

This system uses two keys:

A private key (kept secret).
A public key (shared openly).

The cool part is:

You can generate the public key from the private key.
But you can’t go backwards — it’s mathematically impossible to figure out the private key from the public key.

This one-way math is what makes Ethereum secure.

🔢 What Is a Private Key?

A private key is just a very large random number — but a very important one!

Example:

f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315

It controls your funds. If someone else gets it, they can steal your ETH. If you lose it, your ETH is gone forever — no password resets in crypto!

That’s why wallet apps and hardware wallets help store and protect private keys safely.

🎲 How Are Private Keys Generated?

Generating a private key means picking a truly random number between 1 and a huge number called 2^256. That’s a number with 77 digits — more than the number of atoms in the universe!

Wallets usually use:

Your mouse movements, or
Your keystrokes, or
Other random inputs to generate a secure number.

It’s important that the random number is not predictable, or someone might guess it. Ethereum wallets use strong built-in random number generators to do this safely.

🧮 What Is a Public Key?

A public key is generated from the private key using elliptic curve multiplication. This is a kind of special math done on a curve called secp256k1.

Let’s simplify:

You start with your private key (a number).
You multiply it with a special constant point (called G).
The result is your public key — two coordinates (x, y) on a curve.

Here’s the math (don’t worry if it looks scary):

Public Key = Private Key × Generator Point (G)

This is a one-way function — easy to do, impossible to reverse.

📮 Ethereum Addresses

An Ethereum address is a shortened version of the public key. It's 40 characters long (20 bytes), usually written in hexadecimal.

Example:

0x742d35Cc6634C0532925a3b844Bc454e4438f44e

This is what you share to receive ETH or tokens. It’s like your bank account number, but public.

✍️ Digital Signatures in Detail

Let’s say Alice wants to send ETH:

She creates a transaction with details like amount, recipient, etc.
She uses her private key to sign the transaction.
The signature is sent with the transaction to the Ethereum network.
Anyone can verify the signature using Alice’s address.

This proves:

The transaction came from Alice.
The transaction wasn’t tampered with.
Alice authorized the action.

No passwords, no usernames, just math.

🔍 Is Ethereum Encrypted?

No. Ethereum is not encrypted. Everything — including:

Transactions,
Contract code,
Balances,
Messages,

...is visible to everyone. This is necessary for transparency and trust — it allows everyone to verify what’s happening.

In the future, Ethereum may use advanced cryptography like:

Zero-Knowledge Proofs – to prove something without showing it.
Homomorphic Encryption – to do computations on encrypted data.

But right now, Ethereum’s focus is on verification, not secrecy.

🚨 Keep Your Private Key Safe!

Never share it.
Never screenshot it.
Always back it up safely (use hardware wallets or seed phrases).
If you lose it, you lose access forever.

🧠 Final Thoughts

Cryptography might seem hard, but it powers everything in Ethereum — from accounts, to transactions, to smart contracts.

The most important things to remember:

Your private key = control over your ETH.
Your signature = proof that you own it.
Your address = your identity on Ethereum.

With public key cryptography and smart math, Ethereum allows you to be your own bank — secure, open, and unstoppable.

⚖️ Proof of Stake Explained: Ethereum’s Guardians of the Blockchain

Allan Githaiga — Thu, 10 Jul 2025 15:02:45 +0000

"With great power comes great responsibility... and staking penalties." – Uncle Eth (probably)

Welcome back Web3 explorers! Today, we dive into the magical realm of Proof of Stake (PoS) — the mechanism that keeps Ethereum running smoothly, securely, and sustainably.

Whether you're new to blockchain or just heard someone yell “slashing!” on crypto Twitter, this article breaks down the what, why, and whoopsies of PoS — Ethereum's heart after the Merge.

🤔 What Is Proof of Stake (PoS)?

Think of PoS like a blockchain boarding school — validators (Ethereum's new class prefects) are selected to propose blocks, check homework (aka validate blocks), and keep the system honest.

But unlike Proof of Work (PoW), where miners solve complex puzzles, PoS chooses validators based on how much ETH they lock (stake). The more you stake, the higher your chances of being chosen to propose or attest to the next block.

No pickaxes. Just ETH and good behavior.

🪙 Staking ETH: The Golden Entry Ticket

To become a validator, you stake 32 ETH.
Your ETH acts like a security deposit at an Airbnb — behave, and you’re good.
Mess around? You could lose part (or all 😱) of your stake.

🦊 Fun fact: You can use MetaMask + staking services to stake without running your own node!

🏆 Rewards: The Carrot on the Stick

Validators earn rewards by doing three things:

Proposing blocks – Like writing the first draft of history.
Attesting to blocks – Confirming someone else’s draft is good.
Sync committee participation – A random validator group that helps light clients stay in sync.

Good behavior = sweet, sweet ETH rewards.
Rewards depend on how active the network is and how many validators are online.

🚨 Penalties: When Validators Go Rogue

It’s not all sunshine and staking. There are penalties too!

😴 Inactivity Penalty

Validators who stay offline too long start losing ETH. This prevents the network from stalling due to absentee validators.

🔪 Slashing

The big no-no. If a validator tries to:

Propose two blocks at the same time (double proposing)
Vote for two conflicting blocks (double voting)
Surround votes maliciously

...they get slashed — a portion of their staked ETH is destroyed, and they’re kicked out of the validator set.

Slashing is like being expelled and fined at the same time.

Common Attacks by Validators (and How Ethereum Fights Back)

1. Long-Range Attacks

What it is: A validator tries to rewrite old blockchain history by proposing an alternative version of events from way back.

Ethereum’s defense:

Clients ignore chains that don’t include recent checkpoint finality.
Checkpoints are final every ~12 minutes (2 epochs).

🛡️ TL;DR: Once history is “finalized,” it’s set in stone.

2. Nothing-at-Stake Problem

What it is: In PoW, miners have to choose one chain because mining costs resources. In PoS, lazy validators could vote on all chains, trying to game rewards.

Ethereum’s defense:

Slashing validators for voting on multiple forks.
Attestations are tracked to punish “double dipping.”

3. Censorship (Proposer Censorship)

What it is: Validators might refuse to include certain transactions (e.g. from specific users or smart contracts).

Ethereum’s defense:

Proposer rotation – Validators are randomly chosen, so no one can control the chain forever.
MEV-Boost relays – Improve decentralization of block building.

4. Finality Delay Attacks

What it is: A group of validators tries to delay finalizing blocks by staying offline or acting slowly.

Ethereum’s defense:

Inactivity leaks gradually drain ETH from offline validators.
Eventually, the honest majority finalizes blocks.

👨‍🏫 What You Should Take Away

PoS is Ethereum's way of saying: "Behave and you’ll be rewarded. Cheat and you’ll be slashed."
Validators are ETH-holding users who run nodes and maintain the chain’s health.
Ethereum uses math, game theory, and crypto magic to reward good validators and punish bad ones.

The system is built to survive attackers, downtime, and even validators turning evil. (Sorry, Anakin.)

🧱 Bonus: Starting Your Validator Journey

Wanna be a validator? Here's a super simplified roadmap:

Stake 32 ETH.
Set up a validator client (like Lighthouse, Prysm, or Teku).
Connect it to your beacon node.
Start validating and watch your ETH grow! (Slowly... it’s not a get-rich-quick scheme.)

⚠️ Not ready for the full 32 ETH? Try staking pools like Lido, RocketPool, or Coinbase staking.

🧠 Final Thoughts

Proof of Stake is Ethereum’s superhero upgrade: greener, faster, and more secure. But with great power comes strict rules and harsh slashing.

Validators keep Ethereum running — as long as they don’t sleep on the job or try funny business.

So stake wisely, stay online, and remember: in Ethereum we trust, but verify.

🔥 Ethereum Basics: From Wallets to Smart Contracts

Allan Githaiga — Wed, 09 Jul 2025 13:29:17 +0000

🚪 Opening the Door: Wallets & Addresses

A wallet isn’t just where you “keep your crypto”—it’s your digital identity on Ethereum.

Public Address = like your email (where people send you ETH)
Private Key = your super-secret password to approve transactions

“With great private keys comes great responsibility.”

Keep your private key off screenshots, sticky notes, or the back of your hand. Seriously.

📨 Sending ETH: How Transactions Work

Think of a transaction like mailing a check:

You write the address + amount
You sign it with your private key
You pay a gas fee (like postage)
Ethereum confirms and records it forever

Once it's in, it’s in. Ethereum doesn’t do “undo.”

Diving Into Smart Contracts

A smart contract is like a vending machine that runs on code:

You send ETH → The machine checks the rules → It delivers the snack (or doesn’t)

These contracts automate everything from NFTs to DeFi lending to on-chain games—no humans in between.

⚙️ The Tools You Need

Your Ethereum toolbox 🧰:

MetaMask – Your wallet and dApp gateway
Remix IDE – Try writing your first contract in the browser
Truffle / Hardhat – Full toolkits for bigger dApps

These help you write, test, and deploy Solidity code like a pro.

🎉 So You Met a Fox… and Accidentally Discovered the World Computer

“At first, it looked like just another crypto wallet... until I realized I had downloaded a portal to a decentralized world computer.”

♦ Ethereum Is More Than a Coin — It’s a World Computer

Ethereum runs on something called the Ethereum Virtual Machine (EVM) — a fancy way of saying:

"Everyone runs the same code, and everyone agrees on the result."

Every Ethereum node is like a tiny brain in a big robot. Together, they make Ethereum a global, unstoppable, tamper-proof machine.

You’ve heard of the cloud? Ethereum is the thunderstorm. ⚡

🧠 EOAs vs. Contracts — Who Runs the Show?

You (and MetaMask) are using an Externally Owned Account (EOA):

Has a private key
Can send transactions
Can own and control smart contracts

But the smart contracts themselves? They’re contract accounts:

No private key
Can receive ETH
React only when triggered

You can think of EOAs as players and contracts as automated chessboards that move when touched.

💧 Your First Contract: The Testnet Faucet

Let’s make it rain (test ETH)!

Here’s a super simple (but very insecure) smart contract:

function withdraw(uint amount) public {
  require(amount <= 0.1 ether);
  msg.sender.transfer(amount);
}

This lets anyone request up to 0.1 ether. It’s like asking a magical bank to give you some coins—if the rules allow.

Step-by-step:

Paste this into Remix IDE
Compile it with the Solidity compiler
Deploy it with MetaMask on the Ropsten testnet
Send some ETH to the contract
Call withdraw(100000000000000000) and voilà! ETH sent!

Congratulations—you just made money move with code.

🧱 What You Really Did

Created a wallet
Funded it with test ETH
Wrote a contract
Deployed it on the testnet
Interacted with Ethereum like a dev

🚀 Final Thoughts

“You didn’t just install a wallet. You just shook hands with the future of the internet.”

Ethereum lets you go beyond holding coins—it lets you build logic, automation, and applications around value itself.

Welcome to Web3. This is just the beginning.

🧠 Ethereum : The Rise of the World Computer

Allan Githaiga — Tue, 08 Jul 2025 13:41:56 +0000

🌍 What Is Ethereum? A Glimpse Into the World Computer

Imagine a world computer that runs code exactly as programmed, without downtime, censorship, or third-party interference. That’s what Ethereum set out to be.

From a technical view, Ethereum is a big global machine made of many small computers (called nodes) all over the world. They all work together to store data, run programs (smart contracts), and agree on what is true.

But in simpler terms, Ethereum is like a shared computer that anyone can use to build apps that no single person controls.

💥 Where Bitcoin ₿ Stops, Ethereum Begins

Many people come across Ethereum after hearing about Bitcoin. While both use blockchain, Ethereum isn't just for sending digital money.

Ethereum lets developers build dApps (decentralized apps) that live on the blockchain. Want to build a voting system? A game? A crowdfunding tool? Ethereum gives you the canvas.

Where the Revolution Started

In 2013, a 19-year-old developer named Vitalik Buterin saw a gap in Bitcoin's design. He wanted a blockchain that could run any app, not just money transfers.

So he wrote a whitepaper that introduced Ethereum: a platform that could run any code (Turing complete). Gavin Wood joined shortly after and became co-founder, helping build the tech vision.

On July 30, 2015, Ethereum launched its first block. From that moment, the world computer was born.

🧩 What Makes Ethereum ♦ Work?

Ethereum is made of multiple layers:

Peer-to-Peer Network: Computers that talk to each other
Transactions: Messages that change the system
Consensus Rules: Everyone agrees on what’s valid

🛠️ Ethereum: The Developer's Playground

Ethereum is a developer-first platform. You can write smart contracts in languages like Solidity and deploy them for anyone to interact with. Think of these as tiny programs that handle logic and money safely.

What makes it special?

You don’t need a company to host your app
You don’t need permission to build

It’s secure and transparent

🚀 From Frontier to Serenity: The Journey So Far

Ethereum has evolved through several stages:

Frontier: The early test version
Homestead: The first stable release
Metropolis: More features and security
Serenity (Ethereum 2.0): Faster, cheaper, greener (moving to Proof of Stake)

Each stage brought new tech, bug fixes, and upgrades to make Ethereum better for everyone.

♦ Why Ethereum Matters

Ethereum opens the door to a new internet, often called Web3. Unlike today’s Web2 (Facebook, Google), Web3 apps don’t need central servers. They are unstoppable, transparent, and owned by users.

With Ethereum, you can build:

🗳️ Voting apps
🪙 Your own tokens
🧠 Prediction markets
🏦 Decentralized finance (DeFi)

🧑‍💻 Why You Should Learn Ethereum

Ethereum is the perfect blend of:

Programming
Cryptography
Economics
Distributed systems

Smart Contracts: Programs that run on-chain

Gas: The fuel that powers everything

Ethereum has its own currency called Ether (ETH). You pay "gas" with Ether to run code and use the network.

✨ Final Thoughts

Ethereum isn’t just about technology. It’s about giving people control back. Control over their apps, data, and even money. Chapter One of "Mastering Ethereum" sets the foundation, and as we go deeper, the vision becomes even more exciting.

Stay tuned for more breakdowns from the Ethereum book!

Getting Your Feet Rust-y: A Beginner’s Guide to Rust for Polkadot Devs”

Allan Githaiga — Mon, 16 Jun 2025 20:02:03 +0000

“Rust is the skill. Polkadot is the playground. And you? You’re the architect.”

🚀 From Curiosity to Code: Why Rust + Polkadot?

For the past few months, I’ve been heads-down writing about Go — breaking down structs, interfaces, and everything in between. It was the language that helped me fall in love with code and gave me a strong foundation in backend development.

But something kept calling me: blockchain.

As I explored the space, I didn’t want to just write smart contracts or build on top of existing blockchains. I wanted to understand the core — the real infrastructure that powers the decentralized world.

That’s when I stumbled into the Polkadot ecosystem — a vision of Web3 that goes beyond just blockchains. It’s about connecting them all, and empowering developers to build their own chains using powerful tools.

And guess what? The whole thing runs on Rust.

“Learning Rust isn’t just about syntax — it’s about unlocking the power to shape the Web3 future.”

So here I am, making the jump from Go to Rust — not because I dislike Go, but because Rust is where my blockchain journey gets real. It's the language that powers Substrate, Polkadot’s core framework. It’s how you build parachains, runtime logic, smart contracts with ink!, and even validator tooling.

“If Web3 is a city, Polkadot is the highway system… and Rust is the language engineers use to build it.”

🧰 Why Polkadot Chose Rust (And Why You Should Too)

Polkadot didn’t randomly pick Rust — it was an engineer’s choice.

Here’s what makes Rust a no-brainer for blockchain:

✅ Memory Safety without garbage collection

✅ Blazing Speed like C/C++, minus the footguns

✅ Pattern Matching & Strong Typing to catch logic errors before they cost millions

✅ Rich Tooling like cargo, clippy, rustfmt

✅ Top-tier Wasm support — essential for running blockchains inside Polkadot

In blockchain, bugs aren’t just bugs — they’re million-dollar mistakes. Rust helps catch them before they happen.”

🧪 How Rust Powers the Polkadot Ecosystem

1. 🏗 Substrate Framework

Polkadot is built on Substrate, a blockchain-building toolkit 100% powered by Rust. Substrate lets you:

Build custom blockchains from scratch
Plug in prebuilt runtime modules (called pallets)
Launch your own parachains in the Polkadot network

2. ⚙️ SCALE Codec

Rust handles SCALE (Simple Concatenated Aggregate Little-Endian) encoding, which compresses and serializes blockchain data efficiently.
In short: Rust makes your data fly over the wire faster and cheaper.

3. 🌐 WebAssembly (Wasm)

Polkadot compiles its runtime logic into WebAssembly, a portable low-level format. Rust is one of the best-supported languages for Wasm. That means your Rust code becomes:

Cross-platform
Ultra-performant
Deterministic (great for consensus)

👨‍💻 Rust + Polkadot Career Paths

You’re not just learning Rust — you’re opening doors to jobs and grants in one of the most developer-friendly ecosystems in Web3.

💼 In-demand Roles:

Runtime engineers (building pallets)
Smart contract developers (with ink!)
Substrate CLI & tooling developers
Auditors, validators, and indexer engineers

💰 Funded Opportunities:

Web3 Foundation Grants
Substrate Builders Program
Rust-based tooling is often directly funded by core teams and DAOs.

“In Web3, learning Rust isn’t just smart — it’s strategic.”

🧭 Your Learning Path: Rust → Polkadot Dev

Want to feel like a blockchain wizard? Understand lifetimes, and you’ll tame time itself. 🧙‍♂️

🔨 Practice Projects to Get Started

🐱 Substrate Kitties
Build an NFT marketplace (like CryptoKitties, but Rusty)
click here

2.🛠 Substrate Node Template
Launch your own chain in minutes

3.✍️ ink! Smart Contracts
Write contracts with familiar Rust syntax
click here

“The best way to learn Rust is to break stuff—safely. Substrate makes it fun.”

Rust is a Power Move

Rust isn’t trendy. It’s battle-tested. And in the Polkadot ecosystem, it’s the default. Learning Rust today is how you build scalable, secure, future-proof blockchain apps tomorrow.

So grab your terminal, fire up cargo new, and join a growing tribe of fearless Rustaceans and Polkadot pioneers.

“Rust is your skill. Polkadot is your playground. And you? You’re the architect of the next decentralized world.”

[Boost]

Allan Githaiga — Fri, 20 Dec 2024 17:23:37 +0000

Go Microservices: A Beginner's Dive Into Modern Architecture

Allan Githaiga — Fri, 20 Dec 2024 17:22:13 +0000

Introduction

When I first started my journey as a backend developer, I was overwhelmed by the complexity of designing systems that could handle growth and changing requirements. I still remember the night I stayed up debugging a monolithic application that crashed due to a minor change in one of its components. That experience taught me a valuable lesson about the importance of scalable and modular architecture.

Microservices became the beacon of hope, offering solutions to the limitations of monolithic systems. This article aims to share my journey and knowledge, helping backend developers like you gain a clear vision of how microservices can transform your projects. Together, we’ll explore the basics, understand the architecture, and implement a real-world example in Go.

What are Microservices?

Microservices is an architectural approach where a single application is divided into small, independent services. Each service focuses on a specific functionality, communicates with others through APIs, and can be developed, deployed, and scaled independently.

How Microservices Work

Microservices operate by splitting an application into distinct services, such as user authentication, payment processing, or order management. These services interact through:

API Communication: Services communicate using REST, gRPC, or message brokers like RabbitMQ or Kafka.
Decentralized Data: Each service often has its database, allowing autonomy and reducing bottlenecks.

Main Components of a Microservices Architecture

Main components of microservices architecture include:

Microservices: Small, loosely coupled services that handle specific business functions, each focusing on a distinct capability.
API Gateway: Acts as a central entry point for external clients also they manage requests, authentication and route the requests to the appropriate microservice.
Service Registry and Discovery: Keeps track of the locations and addresses of all microservices, enabling them to locate and communicate with each other dynamically.
Load Balancer: Distributes incoming traffic across multiple service instances and prevent any of the microservice from being overwhelmed.
Containerization: Docker encapsulate microservices and their dependencies and orchestration tools like Kubernetes manage their deployment and scaling. 6.** Event Bus/Message Broker:** Facilitates communication between microservices, allowing pub/sub asynchronous interaction of events between components/microservices.
Database per Microservice: Each microservice usually has its own database, promoting data autonomy and allowing for independent management and scaling.
Caching: Cache stores frequently accessed data close to the microservice which improved performance by reducing the repetitive queries.
Fault Tolerance and Resilience Components: Components like circuit breakers and retry mechanisms ensure that the system can handle failures gracefully, maintaining overall functionality.

Microservices vs Monolith

Benefits of Microservices

1.Scalability: Scale specific components as needed.

2.Flexibility: Use the right technology for each service.

3.Resilience: Failures in one service don’t impact others.

4.Rapid Development: Teams can work independently.

Challenges

1.Complexity: More components to manage.

2.Data Consistency: Requires additional mechanisms.

3.Latency: Inter-service communication can slow performance.

4.Testing: Requires integration testing.

Real-World Example: A Hotel Booking System

We’ll create a basic hotel booking system using Go, showcasing microservice architecture.

Project structure

hotel-booking/
├── main.go
├── services/
│   ├── booking/
│   │   ├── booking.go
│   │   ├── handler.go
│   │   └── routes.go
│   ├── customer/
│   │   ├── customer.go
│   │   ├── handler.go
│   │   └── routes.go
│   └── room/
│       ├── room.go
│       ├── handler.go
│       └── routes.go
├── api-gateway/
│   └── gateway.go
└── go.mod

Main Application

// main.go
package main

import (
    "log"
    "net/http"
    "micro/services/booking"
    "micro/services/customer"
    "micro/services/room"
)

func main() {
    // Initialize routes for each service
    booking.RegisterRoutes()
    customer.RegisterRoutes()  // Ensure this is implemented like booking
    room.RegisterRoutes()      // Ensure this is implemented like booking

    // Add a root handler for the base path
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Welcome to the Hotel Booking API"))
    })

    log.Println("Starting hotel booking microservices...")
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatalf("Failed to start server: %v", err)
    }
}

Booking Service

booking.go

// services/booking/booking.go
package booking

type Booking struct {
    ID       string
    CustomerID string
    RoomID    string
    CheckIn  string
    CheckOut string
}

handler.go

// services/booking/handler.go
package booking

import (
    "encoding/json"
    "net/http"
)

func HandleBooking(w http.ResponseWriter, r *http.Request) {
    booking := Booking{}
    if err := json.NewDecoder(r.Body).Decode(&booking); err != nil {
        http.Error(w, "Welcome Allan Robinson \n Book hotel services", http.StatusBadRequest)
        return
    }
    w.WriteHeader(http.StatusCreated)
    json.NewEncoder(w).Encode(booking)
}

routes.go

// services/booking/routes.go
package booking

import "net/http"

func RegisterRoutes() {
    http.HandleFunc("/booking", HandleBooking)
}

Customer service

customer.go

// services/customer/customer.go
package customer

type Customer struct {
    ID   string
    Name string
    Email string
}

handler.go

// services/customer/handler.go
package customer

import (
    "encoding/json"
    "net/http"
)

func HandleCustomer(w http.ResponseWriter, r *http.Request) {
    customer := Customer{}
    if err := json.NewDecoder(r.Body).Decode(&customer); err != nil {
        http.Error(w, "Welcome Allan Robinson to our hotel services", http.StatusBadRequest)
        return
    }
    w.WriteHeader(http.StatusCreated)
    json.NewEncoder(w).Encode(customer)
}

routes.go

// services/customer/routes.go
package customer

import "net/http"

func RegisterRoutes() {
    http.HandleFunc("/customer", HandleCustomer)
}

Room Service

room.go

// services/room/room.go
package room

type Room struct {
    ID     string
    Type   string
    Status string
}

handler.go

// services/room/handler.go
package room

import (
    "encoding/json"
    "net/http"
)

func HandleRoom(w http.ResponseWriter, r *http.Request) {
    room := Room{}
    if err := json.NewDecoder(r.Body).Decode(&room); err != nil {
        http.Error(w, "Welcome Allan Robinson \n Book a room", http.StatusBadRequest)
        return
    }
    w.WriteHeader(http.StatusCreated)
    json.NewEncoder(w).Encode(room)
}

routes.go

// services/room/routes.go
package room

import "net/http"

func RegisterRoutes() {
    http.HandleFunc("/room", HandleRoom)
}

API Gateway

gateway.go

// api-gateway/gateway.go
package main

import (
    "net/http"
)

func main() {
    // Proxy requests to specific services
    http.HandleFunc("/api/booking", func(w http.ResponseWriter, r *http.Request) {
        resp, _ := http.Get("http://localhost:8080/booking")
        w.WriteHeader(resp.StatusCode)
    })

    http.ListenAndServe(":9000", nil)
}

Github repo for this article

Go-Microservices

Mastering Algorithms with Go: A Beginner's Guide to Sorting Small Data Sets 🔥

Allan Githaiga — Thu, 12 Dec 2024 04:19:37 +0000

Algorithms are the backbone of problem-solving in programming. Whether you're organizing your tasks, finding the fastest route on a map, or simply sorting a list of names, algorithms come into play. In the world of software development, understanding algorithms is crucial for writing efficient, scalable, and maintainable code.

In this article, we'll focus on one of the most basic & fundamental algorithmic challenges—sorting small data sets. We'll explore how to implement sorting algorithms in Go and understand their relevance in real-life scenarios.

Why This Topic Matters

Sorting data is one of the most common tasks developers face. From ranking search results to organizing user data, efficient sorting can dramatically impact application performance. For beginners, learning sorting algorithms provides a strong foundation for understanding more complex algorithmic concepts.

But here's a twist: What if you’re faced with a situation where performance matters even for small data sets? Imagine you're developing a leaderboard for a local hackathon where rankings must update in real-time. You need a sorting solution that's both simple and efficient. That’s where this article comes in.

1. QuickSort Algorithm

The following code implements a dynamic leaderboard for a local hackathon. It uses efficient sorting and other utility functions to handle real-time updates.

// QuickSort sorts the participants slice in descending order of scores.
// It uses a divide-and-conquer approach for efficient sorting.
func QuickSort(participants []models.Participant, low, high int) {
    if low < high {
        // Find the pivot position
        p := partition(participants, low, high)
        // Recursively sort the left and right subarrays
        QuickSort(participants, low, p-1)
        QuickSort(participants, p+1, high)
    }
}

Input: The slice of participants, along with low and high indices for the current sorting range.
Output: The slice is sorted in descending order.
How it works:

Calls the partition function to position one element (pivot) in its correct sorted place.
Recursively sorts the two halves of the array around the pivot.

2. Partition Function

// partition rearranges the slice such that elements greater than or equal to the pivot
// appear before it, and elements less than the pivot come after it.
func partition(participants []models.Participant, low, high int) int {
    pivot := participants[high].Score // Select the pivot as the last element
    i := low - 1                      // Initialize pointer for greater elements

    for j := low; j < high; j++ {
        // If the current element's score is greater than or equal to the pivot
        if participants[j].Score >= pivot {
            i++ // Move the pointer
            // Swap the current element with the element at pointer i
            participants[i], participants[j] = participants[j], participants[i]
        }
    }

    // Finally, place the pivot in its correct position
    participants[i+1], participants[high] = participants[high], participants[i+1]
    return i + 1 // Return the index of the pivot
}

This function ensures elements are rearranged:

Larger scores are placed on the left of the pivot.
Smaller scores are placed on the right.

Returns the pivot index, which divides the array for further sorting.

3. Update Scores

// UpdateScore updates a participant's score based on their name.
// If the participant isn't found, it displays a message.
func UpdateScore(participants []models.Participant, name string, newScore int) {
    for i := range participants {
        // Find the participant by name
        if participants[i].Name == name {
            // Update their score
            participants[i].Score = newScore
            return
        }
    }
    fmt.Println("Participant not found!")
}

Purpose: Quickly updates a participant’s score.
Flow:

Loops through the participants slice. If a match is found (Name == name), updates their Score.
If no match is found, prints a helpful message.

4. Display the Leaderboard

// DisplayLeaderboard prints the participants in sorted order.
func DisplayLeaderboard(participants []models.Participant) {
    fmt.Println("\n--- Hackathon Leaderboard ---")
    for i, participant := range participants {
        // Print each participant's rank, name, and score
        fmt.Printf("%d. %s - %d\n", i+1, participant.Name, participant.Score)
    }
}

Purpose: Outputs the current state of the leaderboard.
How it works:

Iterates through the sorted slice.
Prints the rank, participant name, and score in a readable format.

5. Add a New Participant

// AddParticipant adds a new participant if their name isn't already present.
func AddParticipant(participants []models.Participant, name string, score int) ([]models.Participant, error) {
    // Check if the participant already exists
    if CheckIfParticipantExists(participants, name) {
        return participants, fmt.Errorf("participant with name %s already exists", name)
    }
    // Append the new participant
    participants = append(participants, models.Participant{Name: name, Score: score})
    return participants, nil
}

Ensures no duplicate names in the leaderboard.
If the participant doesn’t already exist, appends them to the slice and returns the updated slice.

6. Check if a Participant Exists

// CheckIfParticipantExists checks if a participant with a given name exists in the slice.
func CheckIfParticipantExists(participants []models.Participant, name string) bool {
    for _, p := range participants {
        if p.Name == name {
            return true
        }
    }
    return false
}

A helper function to verify if a participant’s name is already in the leaderboard.

7. sample workflow in Main

func main() {
    // Initialize participants
    participants := []models.Participant{
        {Name:"Alice",Score: 85},
        {Name:"Bob",Score: 70},
        {Name:"Charlie",Score: 90},
    }

    // Add a new participant
    participants, _ = AddParticipant(participants, "Diana", 75)

    // Update Bob's score
    UpdateScore(participants, "Bob", 95)

    // Sort the leaderboard
    QuickSort(participants, 0, len(participants)-1)

    // Display the leaderboard
    DisplayLeaderboard(participants)
}

If you'd like to explore the complete code implementation and try it out for yourself, you can find the project on my GitHub repository Dynamic-Leaderboard. Feel free to clone it and experiment with the algorithms!
Happy coding 🎉