A .NET Dinosaur in Web3. Day 15 - DAO Voting

🗳️ Challenge Day 3 of 7: Arrays, Mappings, and the Gas Limit Trap

Day 3 was about storage design — when every action with data has a real cost.

I think what helped me here is that I have some background from high school in low-level programming. A long time ago I learned how to write code for microcontrollers — my first programming language was Assembly, then BASCOM, C, and C++.

Life Without LINQ: The Cost of Loops in Solidity

In the .NET world we have many options for managing collections. In Solidity we have just a couple of mechanisms to work with them, and all of them must be implemented very carefully.

In Solidity we have mapping — looks similar to Dictionary<K,V> — but behaves completely differently.

A Solidity mapping has no .Count. No .Keys. No .Values. You cannot iterate it with foreach. It's a virtual hash table where every possible key in the universe pre-exists and defaults to zero. The EVM computes keccak256(key) and points directly to a 32-byte storage slot. That's it.

There is no collection. There is no enumeration. There is just a key and a slot.

Is Solidity More Limited Than C++?

Yes.

Coming from C/C++, you had vectors, lists, maps, full iterator support, exceptions with catch hierarchies, floating point, recursion, full pointer control. Solidity has none of that — because of the execution model:

C++ / C#  →  CPU + RAM + OS  →  resources are cheap
Solidity   →  EVM  →  every operation = real money

When SLOAD (reading from storage) costs ~2,100 gas, the language can't afford conveniences that hide cost. Syntactic sugar that obscures what's expensive is dangerous.

⚠️ The most striking example: no floating point. All financial logic uses integers:

// "1.5 tokens" = 1_500_000_000_000_000_000
uint256 price = 1.5 ether; // compiler expands to 10^18

The reason is determinism. Every node in the network must produce byte-for-byte identical results. IEEE 754 floating point gives platform-dependent rounding — unacceptable for a consensus system.

Feature	C++ / C#	Solidity
Collection iteration	foreach, iterators	for by index only, if you track length yourself
Dynamic structures	vector, list, map	mapping (not iterable), array (dangerous in loops)
Exceptions	full try/catch hierarchy	revert / require — no hierarchy
Floating point	float, double	absent entirely
Recursion	free	stack depth limit = 1024, gas explodes
String type	full object	primitive — no `.length`, no `==` comparison

I also looked into Rust and what we have in the Solana network — and my next priority will be a deeper investigation of Solana.

These limitations are specific to the EVM. Rust is used for smart contracts on Solana and NEAR — and there the story is different. Those chains compile to WebAssembly (WASM), where Rust's zero-cost abstractions, ownership model, and low-level memory control are a natural fit. Writing a Solana program in Rust looks like systems programming — you work with raw account bytes directly. The expressive power is much greater, but the entry bar is significantly higher.

Solidity is a language designed for mathematically auditable contracts where:

convenience is sacrificed for predictability
syntactic sugar is sacrificed for cost transparency
flexibility is sacrificed for auditability

The Architectural Crime: Dynamic Arrays in Loops

Because mappings can't be iterated, junior developers often reach for dynamic arrays to track participants, then loop through them to compute results — and commit a crime:

// ❌ GAS LIMIT DoS VULNERABILITY
function countVotes(uint256 proposalId) external {
    for (uint256 i = 0; i < voters[proposalId].length; i++) {
        // some counting logic...
    }
}

In .NET, iterating 10,000 items is microseconds of CPU time. In the EVM, every iteration reads from storage — that's an SLOAD opcode, and it costs real gas. Write operations inside a loop are worse — SSTORE can cost 5,000 to 20,000+ gas per slot.

With 2,000 voters, calling countVotes() would exceed Ethereum's Block Gas Limit. The transaction becomes physically impossible to mine. The contract freezes permanently. Votes are locked forever. This is a Gas Limit DoS Attack — written into the contract at design time, not introduced later by an attacker.

Worth noting: the vulnerability doesn't require hitting the gas limit today. An unbounded loop that's safe with 100 voters becomes dangerous with 10,000. The state grows; the gas cost grows with it.

The Solution: O(1) Everything

The fix is architectural: track state at the moment it changes, not after the fact.

Instead of storing voters and counting later, increment counters at vote time. One voter votes → one counter increments. Loops — NEVER ❌

What Actually Clicked

storage vs memory — the correct mental model.

Proposal storage proposal = proposals[_proposalId] creates a reference to the actual storage slot. It doesn't copy the struct into transient memory — it points directly to where the data lives on-chain. When you write proposal.votesFor += 1, that change persists.

Proposal memory proposal = proposals[_proposalId] creates a copy. Changes to that copy disappear when the function returns. Nothing is written to the blockchain. The data is silently discarded.

The performance note is more subtle than "storage saves gas on writes." storage pointers are useful when you need to access the same slot multiple times in one function — they avoid redundant lookups. But writes to storage (SSTORE) are among the most expensive operations in the EVM. The storage keyword doesn't make writes cheaper; it makes them possible and avoids unnecessary copies when reading.

CEI applies here too.

The order inside vote() matters:

if (hasVoted[_proposalId][msg.sender]) revert AlreadyVoted(); // Check
hasVoted[_proposalId][msg.sender] = true;                      // Effect
proposal.votesFor += 1;                                        // Effect

State is updated before any counters change. Checks-Effects-Interactions, same principle as Day 2's withdraw().

Nested mappings for O(1) duplicate detection.

mapping(uint256 => mapping(address => bool)) public hasVoted — proposalId maps to a voter address maps to a boolean. Any double-vote check is a single storage lookup, regardless of how many proposals or voters exist.

The Sybil Attack Problem

One voter, one vote sounds fair. In practice, it's fragile.

An attacker generates 1,000 wallets, funds each with a tiny amount for gas, and votes 1,000 times. The contract can't distinguish them from 1,000 real participants.

This is the Sybil Attack — the same identity problem that came up earlier in this series when building the voting contract from scratch. I covered it in detail in Day 3 of the original series. The problem is unsolved at the protocol level. Most production solutions still route back to Web2 identity providers.

The architectural response in real DAOs is token-weighted voting: instead of votesFor += 1, use votesFor += tokenContract.balanceOf(msg.sender). Controlling 1,000 empty wallets doesn't help if voting power requires holding tokens.

block.timestamp — The Honest Picture

The contract uses block.timestamp to enforce voting deadlines. The honest picture after PoS is more nuanced than the usual "validators can manipulate timestamps" warning.

After The Merge, Ethereum time is divided into strict 12-second slots. Each validator is assigned a slot and is expected to produce a block at that slot's designated time. They cannot arbitrarily drift the timestamp by seconds — the timestamp must be greater than the parent block's timestamp and consistent with the slot timing. The "15-second manipulation window" that existed under Proof-of-Work no longer applies.

The realistic manipulation vector in PoS is a validator skipping a slot — which shifts the timestamp by 12 seconds. For DAO voting periods that run for days or weeks, this is completely irrelevant. A 12-second drift doesn't change the outcome of a vote that closes in 7 days.

Timestamp manipulation becomes a real concern only for hyper-sensitive financial logic — MEV opportunities, flash loans, contracts where a single block matters. For governance and voting, block.timestamp is the correct and standard approach.

The advice to use block.number instead is outdated. In PoS, skipped slots mean block numbers don't map reliably to real-world time — gaps accumulate over long periods. block.timestamp is more accurate.

Testing The Contract

After a clean deploy, the full happy path in the console:

npx hardhat console --network localhost

const { viem } = await network.create();
const [deployer, voter1, voter2] = await viem.getWalletClients();

// Connect to the contract
const daoAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";
const dao = await viem.getContractAt("SimpleVotingDAO", daoAddress);

// 1. Create a proposal - duration: 24 hours 86400 sec
await dao.write.createProposal(["Should we officially declare 2026 the year of Hardhat 3?", 86400n]);

// 2. switch the account and vote
const daoAsVoter1 = await viem.getContractAt("SimpleVotingDAO", daoAddress, { client: { wallet: voter1 } });
await daoAsVoter1.write.vote([0n, true]);

// 3. checking the poposal state of index 0
await dao.read.proposals([0n]);

Testing Time-Dependent Logic

Testing deadline enforcement requires moving the blockchain clock forward. Hardhat's local network supports this:

// In Hardhat 3, networkHelpers.time.increase() shifts the local chain forward
await context.networkHelpers.time.increase(65); // advance 65 seconds

This is the blockchain equivalent of mocking DateTime.UtcNow via ITimeProvider in .NET — same problem, different mechanism. The underlying local node (npx hardhat node) exposes evm_increaseTime and evm_mine RPC commands. Hardhat wraps them in a clean API.