© Excellent backgrounds/Shutterstock.com
Java Magazin
Teil 2: Smart Contracts und decentralized Applications mit Ethereum

Signed, sealed, delivered

Ethereum ist der zweite große Wurf in Sachen Blocktech (Blockchain-Technologie), Bitcoin war der erste. Digitale Währung und kryptografische Zahlungen trafen den Nerv der Zeit inmitten der tobenden Finanzkrise. Bei Bitcoin geht es eigentlich immer nur um Zahlungen in eine Richtung - was im Gegenzug geschieht, hängt irgendwie in der Luft. Genau da geht Ethereum mit programmierbaren Zug-um-Zug-Geschäften weiter und nennt die zur Ausführung kommenden Programme einfach Contracts.

Lothar Wieske


ArtikelserieTeil 1: Can’t touch this – Digital Currency Bitcoin und Digital Disruptor BlockchainTeil 2: Signed, sealed, delivered – Smart Contracts und decentralized Applications mit EthereumTeil 3: Hyper, Hyper, Hyperledger: Blocktech fürs Business

Blocktechies sprechen eine eigene Sprache. Es geht aber hauptsächlich um vier Achsen oder Attribute, die eigentlich ständig vorkommen und verwendet werden: distributed/localized, decentralized/centralized, permissionless/permissioned und tokenized/tokenless. Beginnen wir mit distributed/localized. Die meisten heute verwendeten Systeme zur Buchhaltung und für den Zahlungsverkehr werden in eigenen Serverräumen oder im eigenen Rechenzentrum mit relationalen Datenbanken implementiert. Entsprechend wird eine localized Blockchain auf einer überschaubaren Zahl von Infrastrukturen von einer überschaubaren Zahl von Organisationen betrieben. Im Gegensatz dazu läuft eine distributed Blockchain auf einer größeren Zahl von unabhängigen Infrastrukturen und wird von einer größeren Zahl von unabhängigen Organisationen betrieben. Diese Kon­stellation bedingt vollständige Replikate der Blockchain und, neben weiteren Techniken zur Absicherung, den Einsatz eines Konsensprotokolls, um deren Konsistenz sicherzustellen und beizubehalten. Distributed Blockchains widerstehen damit auch größeren Systemausfällen oder böswilligen Angriffen.

Decentralized Blockchains geben allen Teilnehmern a priori gleiche Privilegien. Das schließt nicht aus, dass die Teilnehmer später spezielle Rollen aushandeln. Aber es bedeutet, dass es keine vorher definierten Teilnehmer für solche speziellen Rollen gibt. Im Gegensatz dazu vergibt eine centralized Blockchain an ausgewählte Teilnehmer spezielle Rollen. Authentifizierung und Autorisierung liegen bei einer centralized Blockchain dicht beieinander. Bei einer decentralized Blockchain agieren die Teilnehmer aber typischerweise anonym oder pseudonym. Gerade diese fehlende Identifizierung birgt das Risiko byzantinischer Fehler. Der Nakamoto Consensus von Bitcoin liefert eine neue praktische Lösung für ein langjähriges Problem der Informatik: das Problem der byzantinischen Generäle. Wie kann Vertrauen ohne vertrauenswürdige Dritte sichergestellt werden? Seit einem wichtigen Unmöglichkeitsresultat „Impossibility of distributed consensus with one faulty process“ (Michael Fischer, Nancy Lynch, Michael Paterson) aus dem Jahr 1985 ist klar, dass es dafür keine allgemeine Lösung gibt. Unter einschränkenden Annahmen...

Java Magazin
Teil 2: Smart Contracts und decentralized Applications mit Ethereum

Signed, sealed, delivered

Ethereum ist der zweite große Wurf in Sachen Blocktech (Blockchain-Technologie), Bitcoin war der erste. Digitale Währung und kryptografische Zahlungen trafen den Nerv der Zeit inmitten der tobenden Finanzkrise. Bei Bitcoin geht es eigentlich immer nur um Zahlungen in eine Richtung - was im Gegenzug geschieht, hängt irgendwie in der Luft. Genau da geht Ethereum mit programmierbaren Zug-um-Zug-Geschäften weiter und nennt die zur Ausführung kommenden Programme einfach Contracts.

Lothar Wieske


ArtikelserieTeil 1: Can’t touch this – Digital Currency Bitcoin und Digital Disruptor BlockchainTeil 2: Signed, sealed, delivered – Smart Contracts und decentralized Applications mit EthereumTeil 3: Hyper, Hyper, Hyperledger: Blocktech fürs Business

Blocktechies sprechen eine eigene Sprache. Es geht aber hauptsächlich um vier Achsen oder Attribute, die eigentlich ständig vorkommen und verwendet werden: distributed/localized, decentralized/centralized, permissionless/permissioned und tokenized/tokenless. Beginnen wir mit distributed/localized. Die meisten heute verwendeten Systeme zur Buchhaltung und für den Zahlungsverkehr werden in eigenen Serverräumen oder im eigenen Rechenzentrum mit relationalen Datenbanken implementiert. Entsprechend wird eine localized Blockchain auf einer überschaubaren Zahl von Infrastrukturen von einer überschaubaren Zahl von Organisationen betrieben. Im Gegensatz dazu läuft eine distributed Blockchain auf einer größeren Zahl von unabhängigen Infrastrukturen und wird von einer größeren Zahl von unabhängigen Organisationen betrieben. Diese Kon­stellation bedingt vollständige Replikate der Blockchain und, neben weiteren Techniken zur Absicherung, den Einsatz eines Konsensprotokolls, um deren Konsistenz sicherzustellen und beizubehalten. Distributed Blockchains widerstehen damit auch größeren Systemausfällen oder böswilligen Angriffen.

Decentralized Blockchains geben allen Teilnehmern a priori gleiche Privilegien. Das schließt nicht aus, dass die Teilnehmer später spezielle Rollen aushandeln. Aber es bedeutet, dass es keine vorher definierten Teilnehmer für solche speziellen Rollen gibt. Im Gegensatz dazu vergibt eine centralized Blockchain an ausgewählte Teilnehmer spezielle Rollen. Authentifizierung und Autorisierung liegen bei einer centralized Blockchain dicht beieinander. Bei einer decentralized Blockchain agieren die Teilnehmer aber typischerweise anonym oder pseudonym. Gerade diese fehlende Identifizierung birgt das Risiko byzantinischer Fehler. Der Nakamoto Consensus von Bitcoin liefert eine neue praktische Lösung für ein langjähriges Problem der Informatik: das Problem der byzantinischen Generäle. Wie kann Vertrauen ohne vertrauenswürdige Dritte sichergestellt werden? Seit einem wichtigen Unmöglichkeitsresultat „Impossibility of distributed consensus with one faulty process“ (Michael Fischer, Nancy Lynch, Michael Paterson) aus dem Jahr 1985 ist klar, dass es dafür keine allgemeine Lösung gibt. Unter einschränkenden Annahmen...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang