Web3 for engineers: consensus, contracts, and costs – our in-depth recap of “web3, why you should care” by Daniel Kreiseder (hilarion 5)

Why this session matters to a technical audience

In “web3, why you should care,” Daniel Kreiseder walks through a year of hands-on exposure to Web3: from initial doubt to practical insights. The core transition he frames is simple but profound: the web has evolved from read (Web 1.0) to read/write (Web 2.0), and now to read/write/own (Web3). Ownership and control move from centralized platforms back to users, supported by decentralized architecture.

We at DevJobs.at followed the talk with a builder’s mindset: Where are the technical edges? How do consensus mechanisms work in practice? What are the implications for energy, security, and costs? Which tools actually show up when you build (MetaMask, Solidity, EVM, IPFS, OpenSea, Brave)? And which use cases are already real, despite the hype?

From Web 1.0 and Web 2.0 to Web3: framing the problem

Web 1.0 – the static past

Mostly about distributing content through websites. It set the stage, but it’s not where today’s challenges sit.

Web 2.0 – platforms and the single point of trust

User-generated content exploded, yet lived on centralized platforms. If you’re not paying, you might be the product. On the financial side, banks act as a centralized “single point of trust”—which also becomes a “single point of failure.” Scandals in centralized systems illustrate the risk concentration.

Web3 – both movement and technology

Naming aside (Web 3.0 vs. Web3), Daniel describes it as a living movement: decentralized ownership of content and identity, user control, and distributed infrastructure. The guiding idea: I read, I write—and I own.

The Web3 core: what a blockchain is

A blockchain combines:

• decentralized nodes (distributed computers),
• a shared, immutable chain of data blocks,
• mechanisms for consensus (who writes the next block?) and integrity (is it valid and consistent across all replicas?).

Nodes can fail without taking down the network. The hard problem is distributed consensus: agreeing on the next block and keeping state consistent and tamper-resistant.

Consensus in practice

Proof-of-Work (PoW): cryptographic puzzles, massive energy

Miners solve cryptographic puzzles; the first valid solution gets to author the next block, everyone else verifies. The puzzle is hard to solve and easy to check. Because many miners compute in parallel and only one wins, enormous compute (and thus energy) is wasted. GPUs dominate the workload.

Daniel references the Cambridge Bitcoin Electricity Consumption Index to ground the energy discussion. Indicative comparisons from the talk:

• Bitcoin: roughly 118 TWh/year (2021 reference) — more than the Netherlands, less than Argentina.
• Austria: ~70 TWh/year (total energy consumption),
• Germany: ~500 TWh/year (total energy consumption).

As Daniel notes, these are apples-to-oranges comparisons, yet they anchor the scale. Ethereum showed a similar curve: relatively quiet in 2018–2020, then accelerating. Context matters: compared to traditional sectors like banking or gold, the narrative shifts—but the methodology remains tricky.

Proof-of-Stake (PoS): validators, probability, and slashing

PoS replaces puzzles with economic stake and validation:

• Participants stake the native token to become validators.
• Probability to propose the next block is proportional to one’s stake.
• The selected validator proposes; others validate.
• Misbehavior risks losing the stake (economic incentive to play by the rules).

This cuts out the brute-force competition and reduces energy drastically. Two anchors Daniel used:

• Ethereum’s transition to PoS (“The Merge”) targets about 99.95% lower energy use versus PoW.
• Per-transaction analogy: if Bitcoin’s energy were the height of the Burj Khalifa, Ethereum (PoW) would be the Leaning Tower of Pisa—and Ethereum (PoS) a small screw.

Market snapshot: PoW incumbents, PoS momentum

On the PoW side sit the heavyweights (Bitcoin, Ethereum). Multiple PoS chains exist, though the talk doesn’t enumerate them. The critical shift is Ethereum’s move to PoS via “The Merge.” Schedules have slipped; at the time of the talk, the target was later in the year (Q3/Q4) — “coming soon,” without hard guarantees. For builders, this roadmap directly impacts DApp cost and sustainability profiles.

Why Ethereum? Smart contracts are the lever

Bitcoin supports smart contracts only in a limited way. Ethereum was designed so programs can run on-chain as first-class citizens: smart contracts.

Smart contracts in one line

A smart contract is program code executed on the blockchain, deterministically and transparently. Daniel’s go-to example: crowdfunding.

• Web 2.0 requires a middleman platform to aggregate funds, enforce rules, and distribute proceeds.
• Web3 codifies this in the smart contract: contributions, thresholds, and payouts are rules on-chain—no intermediary required.

Solidity, EVM, and the tooling surface

• Most contracts are written in Solidity, a language purpose-built for Ethereum.
• Code runs on the Ethereum Virtual Machine (EVM).
• Other chains may support the EVM (or differ), but the talk centers on Ethereum.

For engineers, Solidity and the EVM are the practical core: state machines, on-chain storage, deterministic execution, and a gas cost model that influences every line of logic.

DApps: where web and chain meet

Distributed applications combine a conventional web frontend with on-chain logic.

• Frontend: standard web tech, often the browser with a wallet extension.
• Authentication: instead of username/password, the user connects a wallet—MetaMask featured prominently in the talk.
• Backend logic: the smart contract encapsulates business rules, transitions, and permissions.

Alongside MetaMask, Daniel name-checks Brave (browser), OpenSea (NFT marketplace), and IPFS (distributed file system) as common touchpoints in a Web3 stack.

Gas fees: why transactions have a price tag

Operations on Ethereum cost gas, denominated in Gwei (Gigawei, 10^-9 ETH). Network conditions impact price; users choose priority (High/Average/Low). Daniel shows a snapshot with elevated prices (67 Gwei) and a tangible example:

• An OpenSea sale can cost about 20 USD in fees.

The moral: Web3 isn’t “free as in free beer.” That’s a feature, not just a bug—users aren’t only the product. For engineers, gas is a design driver: each on-chain action must be justified and optimized.

Token taxonomy and the NFT surge

Daniel outlines three token types at a high level (legal nuance intentionally out of scope):

• Payment tokens: coins like Bitcoin and Ether for value transfer.
• Security tokens: akin to equity slices—exposed to value appreciation of the underlying venture.
• Utility tokens: vouchers/keys/access without embedded value appreciation.

He treats NFTs separately: non-fungible tokens as unique digital assets, from collectibles to access keys and proof of ownership.

Examples and market dynamics

• CryptoPunks: early, prominent generative image NFTs.
• Bored Apes: membership keyed by NFT (“Bored Ape Yacht Club”), with high price tags.
• Record sale: a single NFT sold for 69.3 million USD (the talk focuses on the magnitude, not the name).
• “Gold rush” mood: frenetic pace, a lot of speculation—and a lot of capital. A European time-zone handicap adds FOMO for some builders.

Phishing and security incidents: Web 2.0 vectors, Web3 fallout

• Instagram hack involving the Bored Ape Yacht Club: compromised login, phishing links, users connected wallets, NFTs stolen.
• Discord server hack with a similar social-engineering pattern.

These are not fundamental blockchain flaws; they’re traditional Web 2.0 attack vectors with high on-chain consequences. For engineering teams, this shifts the emphasis to signature clarity, minimum approvals, and hardening off-chain channels.

Beyond speculation: brands and grounded projects

• Brands: Nike, Adidas, and Louis Vuitton experiment with NFTs. Examples include pairing physical goods (shoes) with NFTs and using them in the metaverse.
• Projects: “Crypto-Barristers” funding a coffee roastery through NFTs; “WomenRise” aligning collections with equality initiatives.
• Supply chain transparency: “Piraperoni” uses QR codes and blockchain to record origin and ingredients per bottle.
• Energy communities: as covered in the media (e.g., an ORF feature), groups organize around shared, sustainable energy models—conceptually akin to crowdfunding with blockchain as rails.

Engineering takeaways from the architecture discussion

1) Consensus determines energy and cost envelopes

• PoW is robust but energy-intensive.
• PoS is dramatically more efficient, with economic incentives (stake, slashing) replacing brute force.
• Ethereum’s PoS transition (“The Merge”) will reshape cost, sustainability narratives, and likely UX trade-offs.

2) Smart contracts are precise—and unforgiving

• On-chain code runs deterministically and publicly.
• Gas is the budget you design against; micro-optimizations matter.
• Upgrades and mistakes are expensive; model business logic carefully before deployment.

3) Wallet-first UX flips authentication

• “Connect wallet” replaces “create account.”
• Users sign intents; transparency in what is being signed is part of security.
• Minimize approval scopes and long-lived permissions.

4) On-chain vs. off-chain data hygiene

• Large assets rarely live fully on-chain.
• IPFS is a common choice for off-chain storage with on-chain references.

5) Token logic is technical design plus governance

• Utility vs. security classification is often legal, but the contract defines rights, actions, and state transitions.
• NFTs can be collectibles, access tokens, or ownership attestations—your logic determines utility.

Security implications: old tricks, new stakes

Phishing isn’t new. The difference now is that a single misguided signature can transfer high-value assets instantly and irreversibly. Technical teams should:

• Harden off-chain channels (admin accounts, social media, Discord/Telegram ops).
• Make signature prompts explicit about what they do.
• Reduce approval scopes; prefer least privilege by default.

Community and culture: collaboration over rivalry

Daniel highlights a positive, cooperative Web3 culture. Knowledge is shared, momentum is high, and a lot gets built quickly. For engineers, that’s a real advantage: faster learning cycles and common patterns you can adopt and adapt.

Five unresolved questions to guide engineering choices

Daniel closes with five deliberately open questions that capture the tensions in Web3:

1. Is blockchain an environmental offender—or a lever to make the economy more sustainable?
2. Does Web3 reduce platform monopolies—or create freedom for a few and dependency for many?
3. Does blockchain transparency increase manipulation resistance—or collide with the “right to be forgotten”?
4. Does Web3 improve protection against cyberattacks—or raise risk with new practices and high-value on-chain assets?
5. Is Web3 a highly democratic internet community—or a new “Wild West”?

These are not blockers; they’re guardrails for architecture and product strategy. They help teams design consciously around trade-offs.

Practical next steps for engineers

• Put only what must be immutable on-chain. Everything else—references, media—belongs off-chain (e.g., IPFS) with clear linkage.
• Treat wallet UX as core product. Explain signatures, avoid blanket approvals, and make permission revocation obvious.
• Think in Gwei. Gas costs shape product economics; expose priority choices and time-sensitive operations.
• Track the network roadmap. Ethereum’s PoS shift changes the energy and cost baseline—plan for it.
• Secure your off-chain footprint. Social-account compromises (Instagram, Discord) can cascade into on-chain losses.
• Learn from the community. Patterns, pitfalls, and optimizations are being shared in real time.

Conclusion: “web3, why you should care” – real, in motion, and worth your attention

Our read of Daniel Kreiseder’s talk (hilarion 5): Web3 is both present and evolving. Architectural primitives are clear—blockchains, consensus, smart contracts, DApps, wallets, gas. The trade-offs are explicit—energy vs. consensus, transparency vs. privacy, decentralization vs. UX friction, security vs. phishing exposure. And the use cases stretch from NFT-based clubs to supply-chain and energy-community pilots.

For engineers, now is the time to understand the primitives, build small, and tune your design craft (cost, security, data) to Web3’s specifics. As Daniel put it through his one-year lens: it’s exciting, real, and already powering first (and second, and third) projects—well worth a closer look.

• 

  

  NFTs are dead. Long live NFTs!

  Daniel Kreiseder von hilarion 5 gibt in seinem devjobs.at TechTalk Einblicke in die Welt der NFTs und zeigt warum vielleicht mehr dahintersteckt als Hype.

  Watch now
• 

  

  Wird KI meinen Job ersetzen?

  Daniel Kreiseder von hilarion 5 nimmt in seinem devjobs.at TechTalk das aktuelle Thema von künstlicher Intelligenz aus Sicht der Software Entwicklung unter die Lupe.

  Watch now

• 

  

  Alexander Peinsipp, CEO & Senior Solution Architect bei hilarion 5

  CEO & Senior Solution Architect von hilarion 5 Alexander Peinsipp spricht in seinem Interview über die Besonderheit der Team Organisation, auf was beim Recruiting geachtet wird und mit welchen Technologien gearbeitet wird.

  Watch now

• 

  

  Andreas Rainer, Full Stack Developer bei hilarion 5

  Andreas Rainer von hilarion 5 erzählt im Interview über seine ersten Schritte mit dem Programmieren, was er in seiner Rolle als Full Stack Developer macht und gibt Tipps für Neueinsteiger.

  Watch now