Web3 technisch verstehen: Von Proof-of-Work zu Smart Contracts – unser Recap zu „web3, why you should care“ mit Daniel Kreiseder (hilarion 5)

Warum dieses Talk-Thema Engineers betrifft

Daniel Kreiseder stellte in „web3, why you should care“ klar, warum Web3 für Entwicklerinnen und Entwickler nicht mehr bloß ein Buzzword ist. Sein persönlicher Einstieg: anfängliche Skepsis („Interessiert mich das überhaupt?“), ein Jahr Praxis – und heute klare, technisch begründete Einsichten. Der Talk führt entlang der Entwicklung von Web 1.0 über Web 2.0 hin zu Web3 und präzisiert die Kernidee: lesen, schreiben – und besitzen. Nicht mehr nur Content erstellen, sondern Eigentum und Identität selbst kontrollieren – verteilt statt zentralisiert.

Wir bei DevJobs.at haben die Session mit dem Blick fürs Praktische verfolgt: Welche Architekturbausteine stehen im Zentrum? Wie funktionieren Konsensmechanismen? Was bedeutet das für Energieverbrauch, Sicherheit und Kosten? Wo sind die Tooling-Punkte für Engineers (Wallet, DApps, Smart Contracts, Solidity, EVM)? Und welche Anwendungsfälle sind bereits sichtbar – jenseits des Hypes?

Von Web 1.0 und Web 2.0 zu Web3: das Problemfeld

Web 1.0 – Vergangenheit

Statisch, verteilt, klassische Websites. Relevanz für heute: gering. Wichtig ist die Ausgangslage – das Internet als Content-Verteilnetz.

Web 2.0 – Plattformdominanz und Single Point of Trust

Web 2.0 brachte User-Generated Content in großem Stil. Der Haken: Inhalte entstehen zwar durch Nutzer, liegen aber auf zentralen Plattformen. Wer nicht zahlt, wird potentiell zum Produkt. Dazu kommt die Rolle zentraler Institutionen wie Banken als „Single Point of Trust“ – und damit auch als „Single Point of Failure“. Skandale in zentralen Systemen zeigen die Verwundbarkeit; Vertrauen bündelt sich an einer Stelle.

Web3 – Bewegung und Technologie

Web3 ist im Talk bewusst sowohl als bereits existierende Technik als auch als Bewegung beschrieben: Dezentralisierung, Besitz von Content und Identität, Kontrolle liegt bei den Nutzern. Ob man es Web 3.0 oder Web3 nennt, ist zweitrangig. Wichtig ist das Paradigma: „I read, I write – and I own.“

Kerntechnik Web3: Was eine Blockchain wirklich ist

Eine Blockchain ist eine Kombination aus:

• dezentralen Nodes (verteilte Computer),
• einer geteilten, unveränderbaren Kette von Datenblöcken,
• Mechanismen für Konsens (wer darf den nächsten Block schreiben?) und Integrität (ist der neue Block gültig und überall gleich?).

Fällt eine Node aus, bleibt das System verfügbar. Die härteste Herausforderung liegt im verteilten Konsens: Das Netzwerk muss korrekt und effizient entscheiden, welcher Block der nächste ist, und die Integrität über alle Kopien sichern.

Konsensmechanismen im Fokus

Proof-of-Work (PoW): Kryptografische Rätsel und hoher Energieverbrauch

Beim Proof-of-Work lösen Miner kryptografische Rätsel. Wer zuerst eine gültige Lösung liefert, schreibt den nächsten Block; die anderen verifizieren. Das Rätsel ist schwer zu lösen, aber leicht zu überprüfen. Weil viele Miner parallel rechnen und nur der Schnellste gewinnt, gehen enorme Rechenressourcen (und somit Energie) verloren. Grafikkarten übernehmen die Arbeit – skalierend mit der Schwierigkeit.

Daniel nannte als Referenz den Cambridge Bitcoin Electricity Consumption Index. Beispielwerte und Vergleiche aus dem Talk:

• Bitcoin: rund 118 TWh/Jahr (Bezugspunkt 2021) – mehr als die Niederlande, weniger als Argentinien.
• Österreich: etwa 70 TWh/Jahr (Gesamtenergieverbrauch),
• Deutschland: etwa 500 TWh/Jahr (Gesamtenergieverbrauch).

Der Hinweis „Äpfel-vs.-Birnen-Vergleich“ ist wichtig: Systemweite Energievergleiche sind nie perfekt. Dennoch wird die Größenordnung greifbar. Bei Ethereum zeigte Daniel eine ähnliche Kurve: Jahre mit wenig Aktivität (2018–2020), zuletzt deutlich steigend. Er bettet das in den Kontext ein: Setzt man den Energiebedarf traditioneller Branchen wie Banking oder Goldindustrie daneben, verschiebt sich die Perspektive – bleibt aber methodisch ein schwieriger Vergleich.

Proof-of-Stake (PoS): Validieren statt Minen

Proof-of-Stake ersetzt Rätsel durch Einsatz (Stake) und Validierung:

• Teilnehmer legen einen Einsatz („Stake“) in der jeweiligen Kryptowährung, werden zu Validatoren.
• Die Wahrscheinlichkeit, den nächsten Block zu schreiben, steigt mit der Höhe des Stakes (proportionale Auswahl).
• Der gewählte Validator schreibt den Block; alle anderen validieren.
• Wer betrügt oder falsch agiert, riskiert den Verlust des Einsatzes (ökonomischer Anreiz zur Ehrlichkeit).

Wesentlich: Der rechenintensive Wettbewerb entfällt, wodurch der Energieverbrauch drastisch sinkt. Daniel veranschaulicht die Effizienzgewinne mit zwei Punkten:

• Umstellung von Ethereum auf Proof-of-Stake („The Merge“) verspricht etwa 99,95 % weniger Energieverbrauch im Vergleich zu PoW (Richtwert aus dem Talk).
• Anschauliches Bild pro Transaktion: Wäre Bitcoin (PoW) so hoch wie der Burj Khalifa, entspräche Ethereum (PoW) dem Schiefen Turm von Pisa – und Ethereum (PoS) einem „kleinen Schrauben“.

Marktlage: PoW dominiert (noch), PoS wächst

Links die Schwergewichte (Bitcoin, Ethereum – PoW), rechts bereits mehrere PoS-Blockchains (im Talk nicht im Detail vertieft). Entscheidender Punkt: Ethereum arbeitet an der PoS-Umstellung („The Merge“). Der Termin war wiederholt verschoben; zuletzt angekündigt für später im Jahr (Q3/Q4) – „kommt bald“, aber ohne Garantien. Für Engineers bedeutet das: Die Roadmap ist relevant, insbesondere für Energie- und Kostenprofile von DApps.

Warum Ethereum? Smart Contracts sind der Gamechanger

Bitcoin kann Smart Contracts nur stark eingeschränkt. Ethereum wurde explizit entworfen, um Programme auf der Blockchain auszuführen – sogenannte Smart Contracts.

Smart Contracts in einem Satz

Ein Smart Contract ist Programmcode, der auf der Blockchain läuft und dort deterministisch ausgeführt wird. Beispiel aus dem Talk: Crowdfunding.

• In Web 2.0 braucht Crowdfunding einen Mittelsmann (Plattform), die einsammelt, verwaltet und verteilt.
• In Web3 übernimmt das der Smart Contract: Regeln und Auszahlungen sind im Code verankert, verteilt, transparent und automatisch.

Solidity, EVM und Tooling

• Programmiert werden (die meisten) Smart Contracts in Solidity – einer Sprache speziell für Ethereum.
• Ausgeführt werden sie in der Ethereum Virtual Machine (EVM).
• Andere Blockchains können die EVM unterstützen oder eigene Ansätze fahren; im Talk liegt der Schwerpunkt auf Ethereum.

Solidity und EVM sind für Engineers die Kerndomäne, wenn es um anwendungsnahe Web3-Programmierung geht. Die Besonderheiten: Zustandsautomat, On-Chain-Speicher, Gas-Kostenmodell, deterministischer Ablauf, keine klassische Username/Password-Auth.

DApps: Architektur aus Frontend, Wallet und Contract

Distributed Applications (DApps) kombinieren „traditionelles“ Web-Frontend mit On-Chain-Logik im Contract.

• Frontend: gewohnte Webtechnologien (z. B. Browser, Frameworks), häufig mit Wallet-Integration per Browser-Extension.
• Authentifizierung: statt Username/Passwort wird ein Wallet verbunden – im Talk prominent MetaMask.
• Backend-Logik: Smart Contracts (z. B. in Solidity) bilden Geschäftslogik, Zustände und Regeln ab.

MetaMask ist im Alltag die Brücke zwischen User, DApp und Blockchain. Im Talk tauchen auch weitere Bausteine auf: Brave Browser, OpenSea (NFT-Marktplatz), IPFS (verteiltes Dateisystem) – typische „Touchpoints“ beim Einstieg.

Gas Fees: Warum Transaktionen nicht gratis sind

Transaktionen in Ethereum kosten Gebühren („Gas“), bemessen in Gwei (Gigawei, 10^-9 ETH). Der Gaspreis schwankt; man kann zwischen Prioritäten wählen (High/Average/Low). Daniel zeigt einen Snapshot hoher Preise (67 Gwei) und ein konkretes Gefühl für teuer vs. günstig:

• Beispiel im Talk: Ein OpenSea-Verkauf kann rund 20 US-Dollar kosten.

Der Punkt dahinter: „Gratis wie Freibier“ ist Web3 nicht. Das ist gut und schlecht zugleich. Schlecht, weil Kosten entstehen; gut, weil Nutzer nicht nur das Produkt sind. Für Engineers ist das Kostenmodell zentral: Jede On-Chain-Operation muss in der Logik gerechtfertigt sein, und Gas-Optimierung ist Teil des Designs.

Token-Typen und der NFT-Schub

Daniel ordnet Tokens grob in drei Kategorien ein – jeweils mit klarer technischer Rolle (rechtliche Fragen bleiben bewusst außen vor):

• Payment Token: die „Coins“ (z. B. Bitcoin, Ether) zur Wertübertragung.
• Security Token: digitale Abbildung von Geschäftsanteilen (Wertsteigerungspotential am Gesamtsystem).
• Utility Token: Gutschein/Schlüssel/Zugang, ohne inhärente Wertsteigerungslogik.

NFTs (Non-Fungible Tokens) markiert er gesondert: digitale Assets mit eindeutiger Identität, Sammlerwert oder Nutzungsrecht – und zunehmend reale Utility.

Beispiele und Marktphänomene

• CryptoPunks: generative Bildserien als frühe, prominente NFTs.
• Bored Apes: Club-Mitgliedschaft durch NFT („Bored Ape Yacht Club“), teils sechsstellige Preise.
• Rekordverkauf: ein NFT für 69,3 Millionen US-Dollar (im Talk als Summe genannt; nicht der Name, sondern die Größenordnung ist hier das Signal).
• „Goldgräberstimmung“: hoher Takt, viele Opportunitäten, aber auch Spekulation. Europäische Projekte fühlen Zeitdruck wegen US-Marktdynamik (Zeitzonen-Effekt).

Phishing und Sicherheitsvorfälle: Web 2.0-Angriffsfläche, Web3-Konsequenzen

• Beispiel: Instagram-Hack beim Bored Ape Yacht Club. Über kompromittierte Logins wurden Phishing-Links gestreut; Nutzer verbanden Wallets – und verloren wertvolle NFTs.
• Ähnlich: Ein Discord-Server-Hack, wieder mit Phishing-Masche.

Wichtig: Das sind keine grundlegenden Blockchain-Schwächen, sondern klassische Web 2.0-Angriffswege (Social Engineering, kompromittierte Accounts) mit hohen On-Chain-Folgen. Für Engineers bedeutet das: UX, Sicherheitsaufklärung und Signatur-Transparenz sind Teil des Systemdesigns.

Jenseits der Spekulation: Marken und Projekte mit Realbezug

• Marken: Nike, Adidas, Louis Vuitton experimentieren aktiv mit NFTs. Beispiel: NFT-Begleitung zum physischen Produkt (Schuhe) und Nutzung im Metaverse.
• Projekte: „Crypto-Barristers“ finanzieren via NFTs eine Kaffeerösterei; „WomenRise“ koppelt Kollektionen an Gleichberechtigungsinitiativen.
• Supply Chain: „Piraperoni“ nutzt QR-Codes und Blockchain, um Bestandteile und Herkunft pro Flasche transparent zu machen.
• Energiegemeinschaften: In Medien (z. B. ORF-Beitrag) werden Modelle vorgestellt, in denen sich mehrere Akteure zusammenschließen – konzeptionell nahe an Crowdfunding, mit Blockchain als Abwicklungs- und Transparenzschicht.

Was Engineers aus dem Architekturteil mitnehmen sollten

1) Konsensmechanismus bestimmt Energie- und Kostenprofil

• PoW ist robust, aber energieaufwendig.
• PoS ist effizienter und verändert ökonomische Anreize (Stake, Slashing, Validatoren).
• Die Roadmap von Ethereum („The Merge“) ist ein Schlüsselfaktor für DApp-Kosten, Nachhaltigkeitsprofile und Akzeptanz.

2) Smart Contracts sind präzise, aber teuer im Fehlerfall

• Smart Contracts laufen verteilt, deterministisch und transparent.
• Gas-Kosten machen jede Operation teuer – Optimierung ist ein Designziel.
• Fehler sind kostspielig; Deployments sind quasi „immutable“. Exaktes Modellieren der Geschäftslogik ist Pflicht.

3) DApp-UX dreht sich um Wallets

• MetaMask und Co. ersetzen klassische Logins.
• „Verbinde dein Wallet“ ist die zentrale Interaktion – damit rücken Signaturfluss, Berechtigungen und Schlüsselmanagement ins Zentrum.
• Phishing-Abwehr beginnt im UX: klare, überprüfbare Schritte, wenig Angriffsfläche, umfangreiche Aufklärung.

4) Datenhaltung: On-Chain vs. Off-Chain

• Große Assets (z. B. Bilder) liegen typischerweise nicht vollständig On-Chain.
• IPFS ist ein verbreitetes, verteiltes Dateisystem für Off-Chain-Assets mit On-Chain-Referenzen.

5) Token-Design ist Technik plus Governance

• Utility vs. Security ist oft juristisch – technisch zählt: Welche Rechte, Aktionen und Zustände verknüpft der Contract?
• NFTs können Sammlerobjekt, Zugangsticket oder Besitznachweis sein – die Logik definiert den Mehrwert.

Sicherheitsimplikationen: alte Muster, neue Auswirkungen

Phishing ist alt – die Konsequenzen in Web3 sind neu. Ein kompromittierter Social-Account reicht, um Nutzer in betrügerische Signaturen zu locken. Für technische Teams heißt das:

• Minimiert Off-Chain-Angriffsflächen (Admin-Accounts, Social Media, Discord/Telegram).
• Macht Signaturanfragen transparent (was wird wofür signiert?).
• Trennt Berechtigungen (z. B. Approval-Scopes) und führt nur das Nötige aus.

Community und Kultur: Zusammenarbeit statt Konkurrenz

Daniel beschreibt die Web3-Community als offen, freundlich, kooperativ. Konkurrenzdenken tritt zurück; das Miteinander dominiert – bei hoher Geschwindigkeit und großem Wissensdurst. Für Engineers kann diese Kultur ein Katalysator sein: schneller Austausch, geteilte Learnings, gemeinsames Bauen.

Fünf Fragen, die offen bleiben – als Denkrahmen für Engineering-Entscheidungen

Daniel endet bewusst mit fünf unbeantworteten Fragen, die die Ambivalenzen auf den Punkt bringen:

1. Ist Blockchain ein Umweltsünder – oder eine Technologie, mit der sich die Wirtschaft nachhaltiger gestalten lässt?
2. Ist Web3 ein Weg, zentrale Monopole abzubauen – oder Freiheit für wenige und Abhängigkeit für viele?
3. Bietet die Transparenz der Blockchain mehr Manipulationssicherheit – oder kollidiert sie fundamental mit dem „Recht auf Vergessenwerden“?
4. Schützt Web3 besser vor Cyberangriffen – oder erhöht es die Angriffsfläche durch neue Praktiken und hohe On-Chain-Werte?
5. Entwickelt sich Web3 zu einer demokratischen Internetgemeinschaft – oder zu einem „Wilden Westen“ mit entsprechendem Risiko?

Diese Fragen sind kein Showstopper, sondern Leitplanken für Architektur- und Produktentscheidungen. Sie helfen, Anforderungen, Risiken und Trade-offs bewusst zu designen.

Konkrete Takeaways für Engineers

• Modelliert eure Geschäftslogik so, dass On-Chain nur das Nötige landet. Jede Operation kostet Gas; alles andere gehört Off-Chain (z. B. IPFS) mit sauberer Referenzierung.
• Plant für Wallet-first-UX. „Verbinde Wallet“ ersetzt „Erstelle Account“. Erklärt jede Signatur und verlangt so wenig Persistenzrechte wie möglich.
• Rechnet in Gwei. Kostensensitivität ist Feature, nicht Bug. Prüft Gas-Preise (z. B. über Gas-Tracker) und bietet Prioritäten an.
• Bedenkt die Netz-Roadmap. Die PoS-Umstellung von Ethereum verändert Energie- und Kostenprofile fundamental – das beeinflusst eure Betriebskosten und eure Sustainability-Story.
• Absichert Off-Chain-Kanäle. Social Hacks (Instagram, Discord) ziehen On-Chain-Schäden nach sich. Security-Playbooks gehören ins Produkt.
• Nutzt die Community. Offene Ressourcen und Diskursgeschwindigkeit sind hoch – Austausch spart Zeit und verhindert Fehlkonzepte.

Fazit: „web3, why you should care“ – ein Jahr Erfahrung, klare technische Signale

Unser Eindruck aus dem Talk von Daniel Kreiseder (hilarion 5): Web3 ist gleichzeitig da und im Werden. Die Architekturprinzipien sind greifbar – Blockchain, Konsens, Smart Contracts, DApps, Wallets, Gas. Die Trade-offs sind ehrlich benannt – Energie vs. Konsens, Transparenz vs. Privatsphäre, Dezentralisierung vs. UX-Reibung, Sicherheit vs. Phishing-Risiken. Und die Anwendungsfälle reichen inzwischen von NFTs als Club-Schlüssel bis zu Supply-Chain- und Energiegemeinschaftsmodellen.

Für Engineers heißt das: Jetzt ist der Zeitpunkt, die Bausteine zu verstehen, mit kleinen Projekten Erfahrung zu sammeln und das Designhandwerk (Kosten, Sicherheit, Datenmodell) auf die Besonderheiten von Web3 zu kalibrieren. Wie Daniel es formuliert: Es ist spannend, real und bereits in Projekten – und es lohnt sich, hinzuschauen.

• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen

• 

  

  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.

  Jetzt ansehen

• 

  

  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.

  Jetzt ansehen