Freitag, 16. November 2018

Blockchain

Unter dem Pseudonym Satoshi Nakamoto wurde 2008 ein Whitepaper zur Blockchain veröffentlicht. 2009 wurde der Code für Bitcoin veröffentlicht.
 
Grundlegende Idee ist die sichere Weitergabe von Werten (in Form von Informationen) in einem Umfeld ohne vertrauensstiftende Intermediäre. Dabei werden die einzelnen Transaktionen digital signiert und fälschungssicher zu aufeinander folgenden Blöcken gebündelt. Durch ein implizites Konsens-Verfahren wird jeder Block der Blockchain vom dezentralen Netzwerk bestätigt. Das Netzwerk besteht aus sogenannten full nodes und Minern, die üblicherweise auch full nodes sind. Jeder full node erstellt gemäß den vorgegebenen Regeln seine eigene Blockchain auf Basis der von den Minern erstellten Blöcke.
 
Ein kryptografischer Hash ist ein digitaler Fingerabdruck einer Information, der eindeutig, leicht zu berechnen, aber in sinnvoller Zeit nicht umkehrbar ist.
 
Jede Transaktion in Bitcoin enthält Metadaten, wie den Hash der Transaktion als Referenz und die mit dem public/private Key-Verfahren erstellte digitale Signatur, sowie ein Array aus Inputs und ein Array aus Outputs. Die Summe der Inputs muss kleiner oder gleich der Summe der Outputs sein. Differenzen gehen als Transaktionsgebühr an den Miner, der diese Transaktion in einem Block veröffentlicht. Der public key (bzw. sein Hash) ist gleichzeitig die Adresse des Teilnehmers.
 
In einem Block werden die Transaktionen in der Struktur eines Merkle-Baums abgelegt. Dabei sind die Transaktionen die Blätter des Baumes, die paarweise über Hashs soweit zusammengefasst werden, dass ein Hash die fälschungssichere Wurzel des Baumes bildet. Der Header eines Blockes enthält neben dieser Wurzel u.a. einen Hashzeiger zum Header des Vorgängerblocks, wodurch die Blockchain gebildet wird. Außerdem enthält er die Lösung „nonce“ des Mining-Puzzles.
Neue Blöcke werden von Minern gebildet, die damit die Buchhaltung der Blockchain vornehmen. Sie sichern mit ihrer Arbeit die fälschungssichere Verknüpfung der Blöcke in der Blockchain. Im Proof-of-work ist ein Mining Puzzle zu lösen, das vom Netzwerk leicht verifiziert werden kann, aber nur durch Ausprobieren zu lösen ist. Der Miner muss den Wert „nonce“ (von „number used once“) finden, der in Verbindung mit anderen spezifischen Daten des Blocks und dem Hash des Vorgängerblocks einen Hash kleiner einem gewissen Zielwert ergibt. Jede nachträgliche Veränderung innerhalb eines Blocks erfordert dadurch die Neukalkulation dieses Blocks und aller darauf folgenden Blöcke um wieder eine korrekte Blockchain zu erhalten.
 
Der Zielwert des Mining Puzzles wird in regelmäßigen Abständen (alle 2.016 Blöcke, ca. 2 Wochen) vom Gesamt-Netzwerk angepasst, um eine durchschnittliche Zeit von 10 Minuten für die Bildung eines neuen Blockes zu gewährleisten und auf Veränderungen im Netzwerk und Hardware-Entwicklungen reagieren zu können. Da das Mining-Puzzle nur durch Ausprobieren gelöst werden kann, ist die Wahrscheinlichkeit, einen neuen Block zu erstellen, abhängig vom Anteil an der Rechenkapazität des Netzwerks und eine beherrschende Stellung wird unverhältnismäßig teuer.
 
Damit Miner diesen Aufwand treiben, enthält jeder Block als erste Transaktion die coinbase-Transaktion, die dem Miner einen bestimmten Betrag an Bitcoin (zu Beginn 50 Bitcoin) überträgt. Der Betrag halbiert sich alle 210.000 Blöcke (ca. 4 Jahre), bis in 2140 die maximale Zahl von 21 Millionen Bitcoin erreicht ist.
 
Andere Kryptowährungen verwenden teilweise andere Mining Puzzles, wie proof-of-stake (Anteilsbezogen) oder proof-of-Authority (ausgewählte vertrauensvolle Knoten bilden den nächsten Block).
 
Die Korrektheit der Blockchain wird durch einen impliziten Konsens sichergestellt:
Jeder Knoten speichert alle Transaktionen und seine Sicht der Blockchain. Bei der Verteilung eines neuen Blockes wird geprüft, ob alle Transaktionen innerhalb des Blockes valide sind und das Mining-Puzzle korrekt gelöst ist. Valide Transaktionen und Blöcke werden im Netzwerk weiterverteilt und die Blöcke in die individuelle Blockchain übernommen. Gibt es zwei korrekte Blöcke, die auf demselben Ausgangsblock basieren, werden beide Blockketten behalten. Neue Blöcke werden von den Minern immer auf der längsten Kette gebildet, weil hierin die meiste Rechenarbeit steckt und damit die Mehrheit des Netzwerkes dainter steht. Nebenketten verwaisen so schnell wieder. Die Transaktionen dieser Nebenketten gelten in der Hauptkette als offen und werden normal integriert.
 
Durch dieses Verfahren müssten bei rückwirkenden Änderungen in der Blockchain alle Blöcke von dort aus neu berechnet werden und die aktuell längste Kette der Blockchain eingeholt werden. Je weiter die Transaktion zurückliegt, umso aufwändiger wäre dieser Prozess. Innerhalb der Bitcoin-Blockchain können Transaktionen nach sechs folgenden Blöcken als sicher durchgeführt gelten.
 
Änderungen des zugrundeliegenden Blockchain-Protokolls können zu Forks (Aufteilungen) führen, wenn nicht alle Knoten die neuen Regeln übernehmen. Bei einer Soft Fork werden die Regeln strenger gefasst, so dass es bei einer Kette der Blockchain bleibt. Bei einer Hard Fork werden die Regeln gelockert (beispielsweise die höhere Blocksize in Bitcoin Cash), so dass es zu einer dauerhaften Trennung der Blockchain in zwei Ketten kommt, da Knoten die das neue Protokoll nicht anwenden, die entsprechenden Blöcke nicht akzeptieren.
 
Ein großer Nachteil von Bitcoin ist die relaitv geringe Skalierbarkeit durch die durchschnittlichen Block-Erzeugungszeiten von 10 Minuten und den Aufand der Verteilung aller Informationen im gesamten Netzwerk. Mit dem Lightning Netzwerk soll hier eine schnellere Alternative angeboten werden: es handelt sich um ein auf der Bitcoin-Blockchain aufsetzendes Netzwerk von vorfinanzierten Bezahlkanälen. Einzelne Knoten verbuchen in der Bitcoin-Blockchain einen Betrag, den sie im Lightning-Netzwerk verfügbar haben wollen. Innerhalb des Lightning-Netzwerks werden Transaktionen dann nur zwischen zwei Knoten abgehandelt, ohne sie an das restliche Netzwerk weiterzugeben. Das sichert eine erheblich höhere Transaktionsgeschwindigkeit und geringere Transaktionsgebühren. Es handelt sich aber durchgängig um valide Bitcoin-Transaktionen, es ist kein Vertrauen in die Partner notwendig.
 

DevOps

DevOps, die Zusammenarbeit von (nicht nur) Entwicklern und Operations in gemischten Teams basiert auf zwei Aspekten: der Übertragung der Prinzipien der Lean Production auf die IT (Arbeitsorganisation) und der Überzeugung, dass in den komplexen IT-Systemen von heute Fehler unvermeidlich sind (Führung).
 
Die drei Pfeiler von DevOps sind:
  • Verbesserung des Workflows von Development über Operations bis zum Kunden
  • Kontinuierliches, zeitnahes Feedback um immer stabilere Arbeitsergebnisse zu liefern
  • Kontinuierliches Lernen und Experimentieren zur Einbindung eines dauerhaften Verbesserungsprozesses in die Arbeitsorganisation


Die Verbesserung des Workflows erfolgt in DevOps mittels


continuous integration continuous delivery continuous deployment.

Dabei bedeutet continuous integration, dass die Entwickler nur an kleinen Programmteilen arbeiten, die mindestens täglich in das Hauptprogramm integriert werden. Automatisierte Tests in produktionsähnlichen Umgebungen sorgen dabei dafür, dass immer fehlerfreier Code vorliegt.


Continuous delivery stellt sicher, dass jederzeit deploybarer Code erstellt wird und umfasst neben der continuous integration auch automatisierte Infrastruktur-Setups und die weitgehend automatisierten Tests und Paketierungen des gesamten Releasezyklus.


Der weitgehend automatisierte Prozess von Development bis zum deploybaren Code wird als Deployment Pipeline bezeichnet.


Als Continuous deployment bezeichnet man eine Erweiterung des continuous delivery, bei der grundsätzlich ein automatisiertes Deployment in Produktion erfolgt.


Kontinuierliches Feedback entsteht durch:
  • Beobachten der Applikation durch Metriken fachlicher und technischer Art
  • Verständnis des non-functional Bereich durch Mitarbeit der Entwickler in Ops
  • Peer Review des Programmcodes


Ziel ist, die Qualitätssicherung immer möglichst nah an der Quelle durchzuführen, so dass der Zusammenhang zwischen Ursache und Fehlereffekt klar ist und keine Folgefehler entstehen.
 
Die Führungsphilosophie muss sich zu der einer lernenden Organisation ändern. Fehler werden als eine Möglichkeit zum Lernen angesehen, nicht als etwas, was zu bestrafen ist.
  • Incidents werden nach Behebung ohne Schuldzuweisungen aus unterschiedlichen Perspektiven betrachtet und Gegenmaßnahmen eingeführt. Die Erkenntnisse werden in die gesamte Organisation gestreut.
  • Mindestens 20% der Entwicklungszyklen werden reserviert, um organisatorische Verbesserungen und Lernen zu ermöglichen
  • Standards und Prozesse werden in einem Shared Source Code dem gesamten Unternehmen zur Verfügung gestellt.
  • Bewusstes Provozieren von Fehlern, um die Widerstandsfähigkeit der Systeme zu verbessern


Nach einer im Auftrag von CA Technologies 2014 durchgeführten Umfrage verbessert die Einführung von DevOps Zeitaufwand für Fehlerbehebung und Maintenance von Anwendungen, Application Performance, Mitarbeiterproduktivität und Softwareakzeptanz bei End Usern und Kunden um jeweils ca. 20%.

PDF Download

API

Eine API, Application Programming Interface, ist eine maschinenlesbare Schnittstelle zu einer Software-Komponente, die unter Verwendung von Standard-Technologien über ein Netzwerk aufgerufen werden kann. Sie dient dem Austausch und der einfachen Weiterverarbeitung von Daten.
 
Bei einer API geht es weniger um die Einführung einer neuen Technologie, als um eine andere Art mit Schnittstellen umzugehen: die Bereitstellung von Self-Service, 1:n, wiederverwendbaren Schnittstellen. APIs sind aus Nutzersicht geschrieben. Der Anwender muss keine spezifische Software oder Wissen über interne Prozesse oder Systeme haben. Moderne APIs sind auf einfache Nutzung statt auf einfache Erstellung ausgerichtet.
Bei der Einführung einer API sind neben der reinen Entwicklung auch API Governance, Cyber Security, die Messung der API-Performance, die Betreuung der App-Entwickler und ggf. Bezahlmodelle zu berücksichtigen. 90% aller APIs sind intern genutzt. Meist werden so erst interne Daten strukturiert, dann anderen Geschäftsbereichen verfügbar gemacht und schließlich Kunden, Partnern, oder der Allgemeinheit.
Interne oder private API werden intern oder restriktiv mit ausgewählten Partnern oder Kunden genutzt. Externe oder public/open API sind allgemein verfügbar.
Man unterscheidet auch verwaltete API mit einer klaren Definition und Zielgruppe von nicht-verwalteten API mit definierter Schnittstelle aber ohne weiteres Monitoring. Letztere kommen z.B. bei Sensoren wie Fitbit zum Einsatz.
 
Zur Standardisierung der Struktur einer API werden Protokolle wie SOAP und REST verwendet.
SOAP (ursprünglich Simple Object Access Protocol, heute eingetragener Markenname in den USA) ist ein industrieller Standard des W3C und unterstützt somit auch alle andere W3C-Standards wie WS-Policy oder WS-Security. Bei SOAP handelt es sich um ein Netzwerkprotokoll, meist werden HTTP oder TCP verwendet, möglich sind auch SMTP oder JMS. Als Datenformat wird meist XML verwendet, es sind aber auch andere Formate möglich.
Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, welchem ein lokaler Name zugewiesen werden muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf http://www.w3.org/2003/05/soap-envelope. Kind dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem können Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zur Transaktionsidentifizierung, untergebracht werden. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Zur Semantik applikations-spezifischer Daten macht SOAP keinerlei Vorschriften, es stellt lediglich ein Framework zu deren Übertragung zur Verfügung.
REST steht für Representational State Transfer und ist der inzwischen deutlich häufiger verwendete Standard. REST ist ein Architekturstil, Kernidee ist das Konzept der Ressource. Ort und Name der Ressource werden in der URL abgebildet, z.B. http://example.com/orders. REST funktioniert unabhängig von jedweden Protokollen, üblicherweise wird aber HTTP verwendet. Bei REST wird stets über einen einheitlichen Satz von Standardmethoden auf eine Ressource zugegriffen, bei HTTP über die Methoden GET (lesen), POST (erstellen), PUT (ändern) und DELETE (löschen).
 
Als Datenformate bei APIs kommen meist JSON oder XML zum Einsatz.
JSON, JavaScript Object Notation, ist ein einfaches Format, in dem Objekte mit zwei Teilen beschrieben werden: keys und values. Keys sind Attribute eines Objektes, wie Bearbeitungsstatus oder Belag einer Pizza. Values sind die Ausprägungen dieser Attribute, also 'versandt' oder 'Pilze', 'Salami'. Dabei lässt sich auch ein Objekt als value einbetten.
XML, Extensible Markup Language, dient der Darstellung hierarchisch strukturierter Daten im Format einer Textdatei und ist plattform- und implementationsunabhängig. Hier ist jeweils ein Anfangs-Node erforderlich, der den key angibt, gefolgt von den values und abgeschlossen von einem End-Node.
 
Für die Autorisierung hat sich das Framework OAuth2 etabliert. Hier gibt es vier unterschiedliche Abläufe: die sicherste Methode ist der Authorization Code Grant. Wenn die Client-App keinen Server hat, gibt es die Abwandlung des Implicit Grant. Für die reine Server-to-Server-Kommunikation gibt es die Vorgehensweise des Client Credential und beim Password Grant oder Resource Owner Password gibt der User sein Password für den Server in der Client-App ein. Eine Vorgehensweise, die man normalerweise vermeiden möchte.
Für die Authentifizierung sind bekannte Standards FacebookConnect, Google FriendConnect oder der OpenId-Standard. Statt des Aufbaus eines eigenen Userpools erfolgt die Authentifizierung hier über sogenannte Identity Provider, genannt Single Sign-On. OpenId ist ein Standard, den unterschiedlichste Anbieter verwenden und der eine Spezialisierung innerhalb des OAuth2-Frameworks darstellt.
 
Eine Aktion des Servers, wen sich dort Daten ändern, ist in der Architektur von APIs schwierig. Es gibt die Möglichkeit des Polling, einer regelmäßigen Anfrage des Clients beim Server, des Long Polling, wenn der Server erst bei einer Änderung der Daten auf die Anfrage des Clients antwortet, oder des Webhooks. Hier wird der Client zum Server und kann somit Requests empfangen. Dafür stellt er dem Server eine callback URL zur Verfügung, an die der Server Updates sendet.

PDF Download