Start now →

A .NET Dinosaur in Web3. Day 3: Voting, Sybil Attacks and Identity

By Alena .NET Dinosaur · Published April 29, 2026 · 4 min read · Source: Web3 Tag
Web3RegulationSecurityAI & CryptoMarket Analysis
A .NET Dinosaur in Web3. Day 3: Voting, Sybil Attacks and Identity

A .NET Dinosaur in Web3. Day 3: Voting, Sybil Attacks and Identity

Alena .NET DinosaurAlena .NET Dinosaur4 min read·Just now

--

Press enter or click to view image in full size
AI generated — .NET Dinosaur very confused =)

Day 3 was the first day that felt like actual software engineering rather than syntax tourism. The task: write a voting contract. Simple enough on the surface — until you start poking at the security model and realize the whole thing has serious gaps in its logic.

What looked like a toy example turned out to be a good proxy for real system design problems.

The Contract

Instead of dumping a wall of code here, I moved the full contract and instructions to GitHub. This post is about what actually matters — how it works.

GitHub: https://github.com/alena-dev-soft/solidity-learn/tree/main/contracts/03day

What Actually Clicked

structrecord in C# Not a class. No methods, no behavior — pure data container. Closer to record in C# than anything else.

mapping(address => bool)Dictionary<address, bool> Exact mental model. The key is a wallet address, the value is whether they've voted. Lookup is O(1), there's no iteration — same tradeoffs as Dictionary in .NET.

view modifier → read-only, free to call Methods marked view don't write to state, so they don't cost gas. The EVM equivalent of a GET endpoint versus a POST. This clicked immediately because the cost model maps directly to why you'd separate reads from writes in any system.

require() → guard clauses + exception in one require(condition, "message") is exactly if (!condition) throw new Exception("message") — except when it reverts, the transaction is reverted — no state is changed, but gas is still spent. Closer to a database transaction abort than a simple exception.

Key Insight

At some point I stopped and asked myself a simple question.

How does the contract know that “Alice” is actually Alice?

The answer was a little unsettling — because I’ve spent years designing systems where knowing who the user is was fundamental. Authentication, authorization, identity verification. That was always the baseline.

In Web3 there is no baseline like that.

The contract sees only an address. Just a string starting with 0x. No name, no history, no face. If the same person creates 10 wallets — congratulations, they now have 10 votes.

This is just how the system works…

And once that clicks, it quietly rewires how you think about everything else: access control, fairness, “one person = one vote.” All the assumptions we carry from Web2 — where identity is tied to accounts, emails, phone numbers — simply don’t apply here.

Ownership of a wallet is not identity. It’s just… ownership of a wallet.

The fix exists, of course. Several of them, actually.

Whitelist — the owner manually approves addresses. Simple, but it requires trusting whoever manages the list. And it scales terribly.

NFT / Token gating — only wallets holding a specific token can participate. Think of it as a membership card. Still doesn’t prove who the person is — just that they own the token.

Proof of Humanity — on-chain verification that a real human stands behind the address. Technically elegant. Still a largely unsolved problem at scale.

And then there’s the quiet irony: most production solutions still route back to Web2 identity providers — Google, Binance, Microsoft and others. Web3 solved decentralized execution beautifully — identity remains outsourced to the old world.

So no, dinosaurs aren’t extinct yet. Apparently we’re still needed. 🦕

Side Observations

Etherscan shows bytecode by default. The contract is there, but unreadable — same as looking at compiled IL instead of C# source. To expose the actual Solidity code, you need to verify the contract: upload the source, match the compiler version exactly. One wrong version number and it fails silently.

Remix doesn’t persist deployed contracts across page reloads. After a refresh, the contract still exists on-chain — but Remix has no memory of it. Recovery is straightforward: find the contract address on Etherscan, use “At Address” in Remix to reattach. Good to know before it happens in a less forgiving context.

Testing multi-wallet scenarios requires either Remix VM or separate wallets with testnet ETH. Browser Extension mode only sees what MetaMask sees. Not a problem — just a constraint to know upfront.

Conclusion

Day 3 changed something in how I think about system design in Web3.

In Web2, identity is assumed. You build on top of it. In Web3, identity is your problem to solve — and every solution is either a tradeoff or a dependency on something outside the chain.

The contract works. The logic is sound. The gaps are in the model, not the code.

Stage: Dinosaur 🦕 — mapping the terrain. Starting to see where the edges are.

Day 4 incoming.🚀

This article was originally published on Web3 Tag and is republished here under RSS syndication for informational purposes. All rights and intellectual property remain with the original author. If you are the author and wish to have this article removed, please contact us at [email protected].

NexaPay — Accept Card Payments, Receive Crypto

No KYC · Instant Settlement · Visa, Mastercard, Apple Pay, Google Pay

Get Started →