DEV Community: Yelyzaveta Dymchenko

How Not to Pull a "GitHub Engineer" With Your VS Code Extensions

Yelyzaveta Dymchenko — Fri, 22 May 2026 15:19:40 +0000

If a GitHub engineer — someone who works at the company that literally hosts the world's code — can get their computer hacked through a VS Code extension... you probably should read this.

Spoiler: staying safe is not hard. It's just a few small things most developers never bother doing because nothing bad has happened yet.

Let me save you the trouble of learning this the hard way.

What Happened (May 2026)

On May 19, 2026, GitHub told the world that hackers had broken into roughly 3,800 of its private repositories. The entry point was a VS Code extension called Nx Console — a popular tool used by millions of developers, with a verified badge from Microsoft.

But here's what makes this story interesting: it wasn't a simple "someone installed a bad extension" situation. It was a chain of events, each one making the next possible.

Here's how it actually went:

Attackers first broke into TanStack — a set of popular JavaScript packages used by many projects. They snuck a credential-stealing payload into those packages.
One of the developers who maintains Nx Console used TanStack in their own work. When the malicious TanStack package ran, it stole that developer's GitHub login credentials.
With those stolen credentials, the attackers published a malicious version of Nx Console to the VS Code Marketplace.
The malicious extension, once installed and running, quietly collected everything it could find on the machine: passwords, API keys, SSH keys, GitHub tokens, AWS and Google Cloud credentials, even contents of 1Password vaults.
It sent all of that out silently — using HTTPS, the GitHub API, and DNS, all of which look like completely normal traffic.
One of the people who had Nx Console installed and auto-updated happened to be a GitHub employee. Their stolen GitHub tokens gave the attackers access to 3,800 internal repositories.

This wasn't a dumb mistake by a careless person. It was a well-planned attack that moved through multiple trusted tools before anyone noticed.

Why VS Code Extensions Are Riskier Than You Think

When you install a VS Code extension, it gets full access to your computer. It can:

Read and write any file you can open
Send data over the internet to anywhere
Run programs in the background
Read your passwords, API keys, and .env files
Access your SSH keys and cloud account credentials

Most antivirus tools won't catch this. Extensions are written in JavaScript, not the kind of files security tools usually flag. The malicious Nx Console payload was a small piece of code hidden inside a larger file. It didn't look like malware because most of it was still the real, working extension.

Also worth knowing: the "Verified Publisher" badge means Microsoft confirmed the publisher is real, owns a domain, and has been on the Marketplace in good standing for at least six months. That's a useful signal — but it can't protect you if that publisher's account gets stolen. In the Nx Console case, it was the real, verified publisher. Just with stolen credentials.

How Attackers Do It (So You Can Spot It)

There are a few tricks they keep using:

Fake extensions with similar names — they publish something called prettierteam.prettier instead of the real esbenp.prettier-vscode. Same icon, same description, different publisher. Most people don't check.

Poisoned updates — they steal a real publisher's account credentials and push a bad update to an extension people already trust. Your computer auto-updates it. This is exactly what happened with Nx Console.

Sleeper extensions — they publish something harmless, wait for people to install it, then flip a switch in a later update. By then you trust it. Auto-update does the rest.

Extensions that actually work — some malicious extensions do exactly what they say they do. They're just also stealing your data at the same time. Much harder to notice.

What You Can Actually Do

1. Look at What You Have Installed

Run this in your terminal:

ls ~/.vscode/extensions/

Go through the list. If you don't recognize something, or haven't used it in months — delete it. Every extension you remove is one less way in.

For the ones you keep, take 30 seconds to check:

Does it have a real GitHub page with real activity?
Does the number of installs make sense for what it is?

A color theme with 9 installs and no GitHub link is worth being suspicious about.

2. Turn Off Automatic Updates

Go to Code → Settings → Settings then click the small JSON icon in the top right corner. Add these two lines:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}

Why do you need both?

extensions.autoUpdate — stops VS Code from downloading and installing updates on its own
extensions.autoCheckUpdates — stops VS Code from even checking for updates in the background

They're separate settings that work independently. If you only turn off one, VS Code can still do part of the process on its own. With both off, nothing changes on your computer unless you go and click update yourself.

This is the single most important thing on this list. The GitHub breach specifically happened because auto-update silently installed a bad version of a trusted extension. If that engineer had auto-update off, they would have updated Nx Console manually — and by the time they got around to it, the malicious version would already have been pulled.

3. Install a Network Monitor (macOS)

LuLu is a free app for Mac that tells you whenever any program on your computer tries to send data somewhere. Think of it like a doorbell for your internet traffic.

brew install --cask lulu

After you install it: go to System Settings → Privacy & Security → Allow LuLu, then restart your Mac.

A word of honesty here: LuLu would not have stopped the GitHub breach specifically. The malicious Nx Console sent stolen data out through GitHub's own API and normal HTTPS traffic — the same connections the real extension makes every day. A popup saying "Nx Console wants to connect to github.com" would look completely normal. LuLu is most useful when an unknown extension tries to connect to some random server you've never heard of. For attacks that use trusted services like GitHub or DNS as the exit route, it won't help much.

That said — LuLu is still worth having. Most malicious extensions do phone home to unfamiliar servers, and LuLu catches those.

4. Check Before You Install Anything New

Before installing any extension, take 30 seconds:

Verified checkmark on the publisher → good sign, but not a guarantee (the Nx Console publisher was verified — their account was just stolen)
Real GitHub repo with recent commits → good sign
High install count for a popular tool → good sign
Name that looks almost like a well-known extension → warning sign
Just published, no history → warning sign
A simple theme or formatter that wants to run scripts → big warning sign

A theme extension has no reason to run commands on your computer. If something simple wants unusual permissions, that's your answer.

The Honest Part

There is no list somewhere that will keep you safe. By the time a bad extension shows up in a security report, people have already been affected. And as the GitHub case shows, sometimes the attack goes through tools you genuinely trust and have used for years.

What actually helps is simpler:

Fewer extensions — you can't get hurt by something you didn't install
Manual updates — gives you a chance to check before anything changes on your machine
LuLu — catches extensions phoning home to unknown servers
Habit — check before you install, not after something goes wrong

The people doing this are patient and organized. The GitHub attack started with one compromised JavaScript package, moved through a developer's stolen credentials, through a trusted extension, and ended with 3,800 private repositories being stolen. Every step looked normal until it was too late.

The good news is that most developers aren't doing any of this yet. Doing even two or three of these things puts you in a much better position than most.

Everything you want to know about Ethereum Stateless

Yelyzaveta Dymchenko — Wed, 14 Jan 2026 20:57:25 +0000

The Ethereum State is becoming unmanageable.

To verify blocks today, running a node requires a 2TB+ NVMe SSD and significant bandwidth. This hardware barrier forces centralization, pushing users to rely on trusted third parties like Infura or Alchemy instead of verifying the chain themselves.

The solution is Stateless Consensus - a fundamental shift in how nodes communicate. This article explores the mechanics of Verkle Trees, the engineering constraints of the network, and why solving the "Concurrency Trap" is critical for Ethereum's roadmap.

The Constraints: Latency & Bandwidth

Why can't we just send the data needed to verify a block?

To verify a block statelessly, a node needs specific account values (balances, nonces, code) along with a cryptographic proof that these values are correct. This package is called The Witness.

The problem is network propagation. Blocks must propagate across the global P2P network in seconds. If we used today's math, the Witness would be 10-20 MB per block. At that size, propagation slows down, stale block rates increase, and only massive data centers can keep up.

To make statelessness viable, we need to shrink that proof from 20 MB to <100 KB.

The Architecture of Statelessness

Statelessness splits the network into two distinct classes of nodes:

Proposers (Heavy): These nodes store the full 2TB state. They build the blocks and generate the Witness.
Validators (Light): These nodes store nothing. They receive the (Block, Witness) tuple and verify it mathematically.

The Bottleneck: Merkle Patricia Tries

Ethereum currently uses Merkle Patricia Tries (Radix-16). In this structure, every node has 16 children. To prove that one specific child value exists, you must provide the hashes of all 15 siblings at every level of the tree's depth.

The Math:

Size ≈ 15 × Depth × 32 bytes

This scales linearly. As the state grows, the tree gets deeper, and the proof gets bigger. Currently, this results in roughly 3-4 KB per account. In a busy block consuming 30M gas, the total witness data exceeds the bandwidth budget of the P2P network.

The Fix: Verkle Trees & Vector Commitments

To solve this, Ethereum is moving to Verkle Trees.

In a Verkle Tree, we make the structure much wider. Each node has 256 children instead of 16. Normally, proving one child among 256 would require sending 255 sibling hashes—a massive amount of data.

The Solution: Polynomials

Instead of hashing the siblings, we treat the 256 children as coefficients (v) of a polynomial P(x). It looks like this:

P(x) = v₀ + v₁x + v₂x² + ... + v₂₅₅x²⁵⁵

We then "commit" to this entire polynomial using KZG Commitments.

The KZG Magic Formula 🔮

The commitment C is a single curve point, derived from a secret value s. It is calculated by multiplying the Generator point G by the polynomial's value at s:

C = G • P(s)

To prove a specific child value y at index z, the prover calculates a Quotient Polynomial Q(x):

Q(x) = (P(x) - y) / (x - z)

Why this formula works:
The logic relies on polynomial divisibility. If the value at index z is truly y, then subtracting y from the polynomial makes it perfectly divisible by (x - z). If the value were anything else, there would be a "remainder" left over, and Q(x) would not be a valid polynomial. By providing the commitment to Q(x), the prover demonstrates that the division was clean and the data is correct.

The "Proof" is simply the commitment to this quotient polynomial Q(x). This proof is a constant 48 bytes, regardless of whether the tree is wide or narrow.

The Impact: Bandwidth Saved

Merkle Proof: ~3,000 bytes per account (Linear complexity).
Verkle Proof: ~150 bytes per account (Constant complexity). This reduces the stateless block witness from 10 MB down to 200 KB.

The Engineering Challenges

1. The Trade-off: Trusted Setup

KZG Commitments require a "Structured Reference String" (SRS)—a set of parameters generated using a secret value $s$.

The Risk: If an attacker knows s, they can fake proofs P'(s) = P(s) and trick the network into accepting bad data.
The Defense: The "Powers of Tau" Ceremony. Over 140,000 participants contributed entropy to generate these parameters. As long as one single person in that chain deleted their "toxic waste" (secret randomness), the system is mathematically secure.

2. The Concurrency Trap (Race Condition)

Who should generate these proofs? There are two approaches:

Strong Statelessness: Users generate proofs for their own transactions.
Weak Statelessness: Block Builders generate proofs for everyone.

Ethereum has chosen Weak Statelessness because of a fundamental distributed systems problem: The Race Condition.

If users had to make these proofs themselves, their transactions would often fail when the network is busy. Therefore, the burden is placed on the Block Builders (Proposers), who have the server capacity to regenerate proofs instantly.

Future Proofing: State Expiry

Another piece of the puzzle is State Expiry (EIP-7736). Statelessness solves the verification problem, but the underlying database (stored by Proposers) still grows endlessly.

Mechanism: Epoch-based tree rotation.
Logic: If a "leaf" (account) is not accessed for ~1 year, it is dropped from the active tree.
Restoration: To use that account again, the user must provide a proof from the "Archive" to reactivate it.

Conclusion: The "Verge" Vision

All of this math serves one singular vision in Vitalik’s roadmap, known as "The Verge." The goal is to make the chain so lightweight that verifying Ethereum no longer requires trusting centralized providers like Alchemy or Infura.

Today: We trust.
Tomorrow: We verify.

Summary & Specs

Feature	Description
Tech	KZG Polynomials compress 256 siblings into 48 bytes.
Network	Reduces bandwidth overhead by ~99%.
UX	"Weak" statelessness prevents transaction failures.
Target	The "Hegota" Upgrade (H2 2026).

Related EIPs:

Top Resources

Vitalik Buterin: "Verkle Trees"
- Link
Dankrad Feist: "Verkle Trie for Eth1 State"
- Link

Polygon’s AggLayer Explained: Aggregating Liquidity Across Chains

Yelyzaveta Dymchenko — Tue, 16 Sep 2025 08:20:14 +0000

Introduction – Why Liquidity Matters

In crypto, liquidity means how easily you can buy, sell, or move assets without delays or high costs. In DeFi, liquidity is oxygen: without it, apps struggle, trades become expensive, and users leave.

But Ethereum’s rollups, while solving scalability, split liquidity into dozens of separate networks. Imagine every neighborhood in a city printing its own currency — trade inside each one works, but moving money across town is messy. Worse, bridges connecting those neighborhoods have been some of crypto’s weakest points. In 2025 alone, crypto theft has already topped $2.17B by mid-year, driven by the $1.5B Bybit incident, which was the largest single hack on record.

In my previous article on ZK Rollup Superchains, I wrote about the race to unify Ethereum’s fragmented rollups. Now let’s look at how Polygon is approaching this challenge with its new interoperability layer: AggLayer.

This is the problem AggLayer is trying to fix.

What is Polygon’s AggLayer?

AggLayer is Polygon’s interoperability and liquidity aggregation layer, part of the broader Polygon 2.0 roadmap. Instead of being just another rollup, it connects:

Polygon PoS
Polygon zkEVM
New chains launched with Polygon’s Chain Development Kit (CDK)
And potentially non-Polygon chains in the future

into one unified ecosystem.

Normally, every pair of chains needs its own custom bridge — a messy and risky approach. AggLayer replaces that with one shared highway - the Unified Bridge. Apps and users interact across chains without juggling multiple wrapped tokens or bridges.

👉 Think of it as many small ponds merging into one giant lake of liquidity.

Quick note on CDK*:* Polygon’s Chain Development Kit is an open-source toolkit to launch custom zk-powered chains. Developers can spin up new appchains with different configurations, and AggLayer ensures they’re automatically plugged into the shared liquidity pool.

Even more ambitious: AggLayer is not limited to Polygon chains. It’s designed to be chain-neutral, potentially aggregating liquidity across all of Web3, not just Ethereum rollups.

Liquidity-First Design

Most rollups focus first on performance (faster, cheaper transactions) and then patch liquidity with bridges. Polygon flipped the script with a liquidity-first design:

All tokens and assets across Polygon chains are treated as if they’re in one pool.
Instead of many small ponds, AggLayer gathers liquidity into one giant lake.
Traders, DeFi apps, and NFT marketplaces all benefit because assets flow freely.

👉 Analogy: Instead of needing different logins for every bank branch, AggLayer makes it feel like you’re banking from one app, with one balance, everywhere.

Under the Hood: How AggLayer Actually Works

AggLayer’s architecture relies on three core systems that keep cross-chain transactions secure, efficient, and trustworthy:

1. Unified Bridge – The Shared Highway

The Unified Bridge is the central mechanism that moves tokens and messages between chains.

No more wrapped tokens: AggLayer treats assets natively across chains. A token on one AggLayer chain is equivalent everywhere — liquidity isn’t fractured into multiple versions.
Message passing: Smart contracts across chains can talk to each other, enabling cross-chain dApps without custom bridges.
Ethereum settlement: Bridge smart contracts on Ethereum track deposits, exits, and global chain states, providing a secure anchor.

👉 Analogy: The Unified Bridge is like a highway system that connects multiple cities. Each city keeps local toll records, but there’s also a central authority verifying the entire network.

2. Pessimistic Proof – The Security Guard

The Pessimistic Proof acts as AggLayer’s safety net. Before any withdrawal is approved, it double-checks that the assets exist and haven’t been claimed already.

Deposits must match withdrawals. No one can claim more than they put in.
Three Merkle Trees per chain:
- Exit Tree – logs what each chain sends out
- Balance Tree – tracks token balances
- Nullifier Tree – prevents replay attacks
Prevents “double dipping.” Once a withdrawal is claimed, it’s nullified.

👉 Analogy: Think of it as a strict accountant cross-checking both the books of each chain and the global ledger. If the numbers don’t add up, no transaction goes through.

3. State Transition Proof – The Auditor

The State Transition Proof (often called the AggChain Proof) ensures every transaction and every cross-chain operation is valid.

Internal verification: Confirms transactions inside each chain are correct.
Cross-chain verification: Confirms that bridge operations (deposits, exits, balances) are consistent with the global record.
Flexible proofs: Some chains use full ZK proofs, others lighter proofs like sequencer signatures.

👉 Analogy: This is like a forensic auditor who not only checks each company’s (chain’s) books but also compares them against the master ledger (AggLayer).

Most importantly: AggLayer enables atomic cross-chain transactions. That means multi-chain actions either all succeed or all fail together — no more risk of getting debited on one chain and failing on another.

Simplified architecture: AggLayer nodes coordinate proofs, Ethereum provides settlement, and the Unified Bridge ties everything together.

Why This Matters for DeFi

By combining these systems, AggLayer delivers on its liquidity-first promise:

Unified Liquidity: One pool of assets across chains → deeper markets, less slippage.
Atomic Swaps: Cross-chain trades that settle instantly or not at all.
Better UX: Users don’t care what chain they’re on — apps just work.
Lower Risk: One robust Ethereum-secured bridge instead of dozens of risky ones.

👉 Example: A DEX on one chain can tap liquidity from another instantly. A lending protocol can pool collateral from all chains. An NFT marketplace can let buyers and sellers trade seamlessly across chains.

Challenges Ahead

AggLayer is ambitious, but questions remain:

Attracting non-Polygon chains: Will independent ecosystems trust a Polygon-led framework? Its neutrality could help, but adoption will take time.
Sequencer decentralization: Polygon plans to use POL staking to decentralize sequencers and provers, but it’s not fully live yet.
Ecosystem fragmentation: Optimism’s Superchain, zkSync’s Elastic Chain, and AggLayer may unify liquidity within their own networks — but will they interconnect, or remain competing “mega-lakes”?

Conclusion – One Big Lake Instead of Many Small Ponds

Polygon’s AggLayer is a bold attempt to solve Ethereum’s liquidity fragmentation. With a shared bridge, strict proofs, and a liquidity-first design, it makes Polygon chains feel like one seamless ecosystem.

Instead of dozens of small, disconnected ponds, AggLayer promises one vast, thriving lake of liquidity — the kind DeFi needs to grow.