Montag, August 19, 2019

Kurz und Knapp – Was ist EOS?

 

EOS (Enterprise Operating System) ist eine Software, auf deren Basis eine neue Art von Blockchain aufgebaut werden soll, mit einem neuen Konsensus-Mechanismus. EOS will als eine Art Operating-System funktionieren, mit dem es wesentlich einfacher sein soll, dezentrale Apps zu entwicklen, als beispielsweise auf Basis der Ethereum-Blockchain.

 

Die EOS-Software kommt mit einigen vorgefertigten Tools daher, die das Entwicklen von Dapps wesentlich einfacher machen soll. Zusätzlich dazu unterstützt EOS gängige Programmiersprachen, wie zum Beispiel Javascript oder C++. Ethereum zum Beispiel benutzt eine eigene Programmiersprache, Solidity, was eine wesentlich größere Hürde darstellt, Applikationen auf Blockchain-Basis aufzubauen.

 

Derzeit wird das Projekt noch über ein einjähriges ICO finanziert und die EOS-Token, die man erwerben kann, sind ERC20-Token auf der Ethereum-Blockchain. Nach Beendigung des ICOs soll eine eigene Blockchain entstehen und die Besitzer der ERC20-Tokens können diese gegen die Varianten auf der neuen Blockchain eintauschen.

 

Kopf hinter dem EOS-Projekt ist Dan Larimer, der bereits die beiden Blockchain-Projekte Steemit (dezentrale Social Media Plattform) und Bitshares (dezentrale Exchange) auf den Weg gebracht hat.

 

Anmerkung: weiter unten findet ihr eine deutsche Übersetzung des White Papers von EOS von mir.

 

Zahlen und Fakten zu EOS

 

Sitz: Cayman Islands

 

Validierung: Delegated Proof of Stake

 

Token: EOS

 

Token-Fähigkeit: Der Token stellt seinem Besitzer eine gewisse Menge der Rechen-, Speicher- und Bandbreitenkapazität der Blockchain bereit. Desweiteren können Token-Besitzer ihre Stimme darüber abgeben, welche Parteien zu den 21 Master-Nodes gehören sollen, die den Konsenus der Blockchain herstellen und Blöcke erzeugen sollen.

 

Maximale Anzahl: Im ICO ist das Cap bei einer Milliarde angesetzt. Im laufenden Blockchain-Betrieb soll es eine maximale Inflationsrate von 5% geben.

 

Verteilung: Die genaue Verteilung ist mir nicht bekannt, das ICO läuft seit Juni 2017 und jeden Tag werden 2 Millionen Tokens ausgeschüttet, die prozentual unter den eingegangenen Funds aufgeteilt werden.

 

Gelistet: Der ERC20-Token von EOS ist auf den Börsen sehr verbreitet, wird nach Beendigung des ICOs aber eingefroren und muss gegen die neue Variante des Tokens eingetauscht werden.

EOS im Detail

 

EOS ist ein Operating System für Dapp-Entwickler und kümmert sich um die gesamte kryptographische Funktionsweise, die Autorisierungen von Transaktionen und generell den Fortlauf der Blockchain. Entwickler können sich auf den Aufbau, die Instandhaltung und die Weiterentwicklung ihrer Produkte kümmern, ohne sich auf kryptographischer Ebene mit dem System auseinandersetzen zu müssen.

 

EOS bietet für die Entwicklung der Dapps einige vorgefertigte Tools an und ein System von Accounts mit verschiedenen Autorisierungsleveln, die eigenständig eingestellt und modifiziert werden können. Jeder Account erhält eine eigene private Datenbank. Zudem können gängige Programmiersprachen eingesetzt werden, um Dapps zu entwickeln, was einen enormen Vorteil gegenüber bisherigen Blockchains darstellt, die auf Smart Contracts basieren.

 

Auf der EOS Blockchain soll es keine Transaktionsgebühren geben und durch die Benutzung von mehreren „threads“ soll es möglich sein, gewisse Anwendungen parallel ausführen zu können. Das heißt, dass eine wesentlich höhere Anzahl an stattfindenen Transaktionen erreicht werden kann. Im White Paper wird angegeben, dass so mehrere Millionen Transaktionen pro Sekunde möglich sein sollen.

 

EOS Token

 

Der EOS-Token ist eine Art Programm-Token, der seinem Besitzer Bandbreite, Speicher und Rechenleistung zur Verfügung stellt, proportional zur Gesamtanzahl der existierenden Token. Zur Veranschaulichung: wenn jemand 1% der EOS-Token besitzt, dann kann er auch 1% der Performance der Blockchain benutzen. Laut White Paper soll es möglich sein, nicht genutzte Performance weiterzuleiten, bzw. zu „vermieten“.

 

Konsensus-Methode

 

EOS benutzt den sogenannten „Delegated Proof of stake“ Algorithmus. 21 Master-Notes werden für die Block-Erzeugung und Konsenus-Kreierung zuständig sein. Diese 21 Notes werden durch alle Token-Besitzer gewählt und bei einem Missbrauch können sie wieder abgewählt werden. Der Zustand der Berechtigung zur Blockerzeugung (also wer die 21 Mining-Plätze belegt) wird laut White Paper immer wieder durch Votings aktualisiert.

 

Ein Blockerzeugungs-Zyklus wird nur 0.5 Sekunden dauern und läuft parallel ab – jeweils 6 Blöcke von 21 Minern. Wenn einer der Miner es versäumt einen Block zu erzeugen und er nicht innerhalb der folgenden 24 Stunden einen Block mined, dann wird er automatisch aus der Riege der Block-erzeugenden Master-Notes entfernt. So wird gewährleistet, dass immer nur Master-Notes eingesetzt werden, die die nötige Infrastruktur und Miningpower aufbringen können. Der Anreiz der Master-Notes zum Minen besteht aus einer Token-Ausschüttung bei jedem neuen Block. Der Token hat eine Inflationsrate von maximal 5%, die zum Teil an die Miner ausgeschüttet wird, zum Teil aber auch in „Funds“ eingezahlt, die innerhalb der Community aufgestellt, bzw. zur Wahl angeboten werden können. diese Funds sollen dann für vorgeschlagene Verbesserungen an der EOS Software und der Blockchain an sich verwendet werden.

 

Was bietet EOS für Möglichkeiten?

 

EOS könnte eine neue Spielwiese zur Entwicklung für Dapps aller Art werden. Das Fundament ist wesentlich zugänglicher und bietet effizientere Werkzeuge für die Konzipierung und Entwicklung von Dapps.

 

Verglichen mit Ethereum, dass mit seiner eigenen Programmiersprache „Solidity“ nicht besonders zugänglich für Entwickler ist und dessen Netzwerk Gebühren für Transaktionen erfordert, bietet EOS durch die Kompabilität mit den gängigen Programmiersprachen einen viel einfacheren Einstieg für Firmen.

 

Was sind die Risiken?

 

Der gewählte Konsensus-Mechanismus mag sich auf der technischen Ebene durchaus sinnvoll anhören, auf der wirtschaftlichen, bzw. „regierenden“ Ebene ist ein „Delegated Proof of Stake“ für die Endverbraucher allerdings nicht so vorteilhaft, da die Macht der Konsensus-Kreierung bei 21 großen Parteien liegt. Selbst die gegebene Möglichkeit einer demokratischen Wahl durch alle Token-Besitzer und auch die Möglichkeit des Absetzens der gewählten Master-Notes bietet keine 100 Prozentige Sicherheit. Wenn eine große Mining-Partei einmal etabliert ist, wird sie wohl Mittel und Wege finden, sich im System zu halten und es wird nicht einfach sein, sie aus dem Mining-Prozess herauszuholen. Dieses Konstrukt geht leider weg vom Ansatz der Dezentralität, auf die die Blockchain-Technologie ja eigentlich ausgelegt ist. Es gibt Berichte, dass sich der Bitcoin Mining Pool Antpool, bzw. Bitmain als einer der 21 Block Producer beworben haben soll.

 

Mit diesem Aspekt im Blickpunkt empfehle ich das Video von Dr. Julian Hosp zu EOS, der genau dieses potentielle Problem, das bei EOS entstehen könnte, gut erklärt. Außerdem zeigt er die Unterschiede zwischen Ethereum und EOS meiner Meinung nach gut auf.

Ein weiteres Risiko ist das ICO, bzw. generell der jetzige Stand des Projektes. Das ICO läuft über ein ganzes Jahr, mit einer Ausschüttung von 2 Millionen Tokens pro Tag und insgesamt einer Milliarde Tokens. Wie viele Token man letztenendes bei der täglichen Ausschüttung bekommt, in die man eingezahlt hat, weiß man im Vorfeld nicht. Durch die gewählte ICO-Strategie wird block.one, die Firma, die hinter EOS steht, desweiteren sehr viel Geld in Form von Ethereum eingenommen haben. Es wurden bereits erste Stimmen laut, die befürchten, dass mit dieser großen Menge der Preis von Ethereum beeinflusst werden könnte. Da Ethereum als direkter Konkurrent zu EOS bezeichnet werden kann, ist dies kein unerheblicher Faktor. Ich weiß allerdings nicht, ob man selbst mit einer eingenommenen Milliarden-Summe den Preis von ETH wirklich nachhaltig beeinflussen kann, da das tägliche Handelsvolumen und die Marktkapitalisierung von ETH doch sehr hoch sind.

 

Es gibt auch einige Gerüchte, dass EOS die eingenommenen Ether dazu genutzt haben soll, die eigenen Token zu pumpen, indem das Ether erneut in das ICO gesteckt wurde.

 

Ein weiterer Punkt ist, dass die ausgegebenen Token nicht Teil der geplanten EOS-Blockchain sind, sondern bloße ERC20-Token, die auf der Ethereum-Blockchain laufen. Es gibt lediglich das Versprechen, oder eher die Aussage, dass man diese Token nach dem Ende des ICOs gegen die „richtigen“ Varianten des Tokens eintauschen kann. In der AGB des Projektes stehen weiterhin viele Formulierungen, die bei einigen Sorge hervorgerufen haben: EOS Tokens Haben keine Rechte, Verwendungen oder Attribute, kein Kauf von EOS Plattform Tokens, der Kauf von EOS ist nicht erstattungsfähig und Käufe können nicht abgesagt werden, der EOS Token kann keinen Wert haben.

 

Das wird wohl eher unter „regulatorische Absicherung“, als unter schwarz auf weiß angekündigten Betrug zu verbuchen sein, dennoch zeigt es deutlich, dass das Projekt bisher noch ohne wirkliches Produkt dasteht.

 

Ein amüsanter Random Fact: Im Bitcoin-Forum wurde EOS mit „Extrem Offensichtlicher Scam“ bezeichnet 😀

 

Meine Meinung

 

Ich persönlich finde es sehr schwer dieses Projekt zu beurteilen. Zum einen hat Dan Larimer, der Kopf hinter dem Ganzen, mit Bitshares und Steemit zwei bereits funktionierende Produkte mit sehr vielen Nutzern vorzuweisen, die in der Praxis funktionieren. Das spricht für das Projekt. Die technische Beschreibung der EOS Software klingt generell sehr innovativ und zeigt einige gute Lösungen für die gängigen Probleme in Bezug auf die Skalierung einer Blockchain und weiteren Dingen auf. Im Großen und Ganzen hört sich EOS wie eine gut weitergedachte Neuentwicklung der Ethereum Virtual Machine an, mit sinnvollen Verbesserungen und Problemlösungen.

 

Negativ finde ich den gewählten Konsensus-Algorithmus und die damit einhergehende Abkehr von Dezentralität. Die weitere Entwicklung von EOS und Ethereum, bzw. was von beiden mehr Erfolg hat, wird wohl eine Antwort auf die Frage bringen, ob es sinnvoller ist, Skalierungslösungen direkt im Fundament der Blockchain zu suchen, wie es bei EOS der Fall ist, oder diese Probleme mittels Second Layer Technologien zu lösen, wie es bei Ethereum oder auch bei Bitcoin versucht wird. Second Layer Technologien sind auf jeden Fall der Dezentralität zuträglicher als die von EOS gewählte Variante.

 

Auch die enorme Menge an eingesammeltem Kapital finde ich nicht nur positiv. Einerseits ist es gut, wenn ein Projekt genug Mittel hat, um eine große Vision umzusetzen, andererseits weiß ich nicht, ob eine Milliardensumme wirklich für die Umsetzung notwendig ist und ob das nicht irgendwelche negativen Aspekte mit sich bringt.

 

Die Aussage, dass EOS der Ethereum-Killer werden wird, würde ich nicht unterschreiben. EOS ist bisher nur eine Idee, zwar mit viel eingesammeltem Kapital, aber ohne irgendwelche praktischen Anwendeungen und mit vielen offenen Fragen, während Ethereum absolut etabliert ist, viele praktische Anwendungen hat und im Grunde bereits das Blockchain-Fundament einer laufenden Industrie darstellt.

 

Ich halte eine Co-Existenz beider Projekte für möglich, sehe aber nicht, dass EOS Ethereum in nächster Zeit verdrängen wird und sehe Ethereum langfristig auf jeden Fall in Sachen Branchen-Dominanz weiter vorne.

 

Ich habe mir einen einzelnen EOS-Token gekauft, um zu sehen, wo die Reise hinführt und werde das Projekt auf jeden Fall weierhin genau beobachten.

 

Alle Infos zum Projektund zum ICO findet ihr auf der Website: eos.io und im White Paper.

 

Anmerkung:

 

Diese Informationen, die in diesem Beitrag stehen, sind anhand meiner Recherche und meines Verständnisses der Firmenidee entstanden. Ich kann nicht hundertprozentig versichern, dass ich das Firmenkonzept im kleinsten Detail verstanden habe und kann daher auch nicht versichern, dass die von mir gemachten Erklärungen komplett richtig sind. Ich kann jedoch versichern, dass ich meine Recherche nach bestem Wissen und Gewissen betrieben habe und mir sehr viele verschiedene, auch möglichst negative, Meinungen zu diesem Projekt angesehen habe, um eine differenzierte Meinung über das Projekt zu erhalten. Ich gebe generell keine Investmentempfehlung. Solltet ihr in Erwägung ziehen, in dieses Projekt zu investieren, nehmt diesen Artikel gerne als Anhaltspunkt, um euch eine Meinung zu bilden, schaut euch jedoch auch genau die Firma an, lest das Whitepaper und holt euch so viele verschiedene Meinungen wie möglich ein, auch bei anderen.lest euch gerne auch noch einmal meine generellen Investment-Regeln durch.

Deutsche Übersetzung des White Papers

 

Ich habe mich durch das White Paper gequält und versucht, es so gut wie möglich ins Deutsche zu übersetzen, da ich das Projekt und die technischen Details so gut wie möglich verstehen wollte. Diese Übersezung ist eher grob gehalten und erhebt keinerlei Ansprüche präzise oder inhaltlich zu 100% korrekt zu sein, das bitte ich beim lesen zu berücksichtigen.

 

 

EOS-White-Paper:

Die EOS.IO Software führt eine neue Blockchain-Architektur ein, die desigend ist, ein horizontales und vertikales Skalieren von dezentralisierten Applikationen zu ermöglichen. Das wird erreicht, indem man ein Konstrukt erstellt, ähnlich einem Operating-System, auf dem Applikationen erstellt werden können. Die Software bietet an: Accounts, Authentifizierung, Datenbanken, a-synchrone Kommunikation, und das Abstimmen von Applikationen über viele CPU Kerne oder Cluster. Die daraus resultierende Technologie ist eine blockchain-Architektur, die schlussendlich zu millionen von Transaktionen pro Sekunde führen kann und Nutzergebühren eliminieren kann. Desweiteren erlaubt sie ein einfaches und schnelles Entwickeln und Instandhalten von Dezentralen Applikationen, im Kontext einer gesteuerten/betreuten Blockchain.

Hintergrund:

Die Blockchain-Technologie wurde im Jahr 2008 mit dem Start von Bitcoin vorgestellt. Seitdem haben Entwickler und Gründer versucht die Technologie zu verallgemeinern, um eine höhere Bandbreite von Applikationen auf einer einzelnen Blockchain zu unterstützen.

Während eine Reihe von Blockchain Plattformen Schwierigkeiten hatten, funktionierende dezentrale Applikationen zu unterstützen, sind Applikationsspezifische-Blockchains wie die dezentralisierte Bitshare Exchange oder das Steem Social Network zu stark genutzten Blockchains mit tausenden Nutzern pro Tag geworden. Sie haben das durch eine erhöhte Performance erreicht bis hin zu tausenden Transaktionen pro Sekunde, mit reduzierter Latenz zu 1,5 Sekunden, indem Transaktions-Gebürhen eliminiert wurden, und eine Nutzerfreundlichkeit umgesetzt wurde, wie sie von existierenden zentralen Services angeboten werden (bsp: Facebook, Zentrale Exchanges)

Existierende Blockchain Plattformen haben Probleme mit hohen Gebühren und limitierter Rechenpower Kapazität. Das verhindert eine Verbreitung der Blockchain-Anwendung

Anforderungen für Blockchain-Applikationen

Mit dem Ziel eine verbreitete Anwendung zu erreichen, benötigen Applikationen eine Blockchain, die flexibel genug ist, die folgenden Anforderungen potentiell erfüllen zu können:

Millionen von Nutzern untersützen

Wenn man mit Firmen wie eBay, Uber, AirBnB und Facebook konkurrieren will, braucht man eine Blockchain Technologie, die in der Lage ist, Millionen von aktiven Nutzern pro Tag managen zu können. In bestimmten Fällen könnte eine Applikation nicht funktionieren/ Sinn machen, bis eine bestimmte anzahl an Nutzern erreicht ist und daher ist eine Plattform, die sehr viele Nutzer einfach handlen kann absolut vorrangig.

Kostenlose Nutzung

App-Entwickler benötigen die Flexibilität, den Nutzern kostenlose Services anbieten zu können. Nutzer sollten nicht für die Nutzung der Plattform bezahlen müssen, um die Vorteile ihrer Service nutzen zu können. Eine Blockchain Plattform, die ohne Gebühren für die Nutzer auskommt, hat höhere Chancen, sich zu verbreiten. Entwickler und Firmen können so auch effektive Vermarktungs- und Verbreitungstrategien entwicklen

Einfache Upgrade-Möglichkeit und Bug-Entfernung / Wiederherstellung

Firmen-aufbauende Blockchain-basierte Apps brauchen die Flexibilität, ihre Apps mit neuen Features zu verbessern. Die Plattform muss software- und smart contract upgrades unterstützen/bereitstellen.

Jede nicht-triviale Software ist potentiell anfällig für Bugs, selbst mit der rigorosesten Verifizierung. Die Plattform muss robust genug sein, diese eventuell auftretenden Bugs zu fixen.

Geringe Latenz

Eine gute Nutzererfahrung benötigt zuverlässiges Feedback mit einer Verzögerung von maximal ein paar sekunden. Längere verzögerungen rufen Frust bei den Nutzern hervor und lassen Blockchain-basierte Apps weniger Konkurrenzfähig werden im Vergleich zu traditionellen Alternativen. Die Plattform sollte daher für eine geringe Latenz bei Transaktionen sorgen können.

Sequenzielle Performance

Es gibt einige Apps, die nicht mit parallel laufenden Algorithmen implementiert werden können, sondern auf sequenziell ablaufenden Schritten aufgebaut sind. Applikationen wie zum Beispiel Exchanges brauchen genug sequenzielle Performance um große Volumen zu handlen. Deswegen sollte die Plattform schnelle sequnezielle Performance unterstützen.

Parallele Performance

Groß angelegte Applikationen benötign eine Aufteilung der Arbeitsleistung verteilt über viele CPUs und Computer.

Consensus Algorithmus (BFT-DPOS)

EOS.IO nutzt den einzigen bekannten dezentralisierten Konsenus Algorithmus, der bewiesen dazu in der Lage ist, die benötigten Performance Anforderungen für Applikationen auf einer Blockchain bereitzustellen, den „Delegated Proof of Stake“.

Unter diesem Alogrithmus werden diejenigen, die Tokens der Blockchain besitzen, die die EOS.IO Software übernommen hat, die Block Erzeuger mittels eines kontinuierlichen Anerkennungs-Voting systems wählen. Jeder kann an der Block Produktion teilnehmen und wird die Möglichkeit erhalten, Blöcke zu produzieren, wenn gegeben ist, das sie die Tokenhalter davon überzeugen können, für sie zu stimmen.

Die EOS.IO Software ermöglicht eine Erzeugung von Blöcken exakt alle 0.5 sekunden und exakt ein Erzeuger ist autorisiert einen Block zu jedem gegebenen Zeitpunkt innerhalb der gegebenen Zeit zu erzeugen. Wenn der Block nicht innerhalb der gegebenen Zeit erzeugt wurde, dann wird der Block in diesem Zeitfenster übersprungen. Wenn einer oder mehrere Blöcke übersprungen werden, dann exisitert eine 0.5 oder mehr Sekundenlange Lücke in der Blockchain.

Bei Anwendung der EOS.IO Software werden Blöcke in Runden von 126 produziert – Jeweils 6 Blöcke von 21 Erzeugern. Zu Beginn jeder Runde werden 21 einzigartige Block Erzeuger ausgewählt aus der aus dem Wahlergebnis der Token-Halter hervorgenagenen Zustimmung für die jeweiligen Block-Erzeuger. Die ausgewählten Block-Erzeuger werden ausgewählt in einer Auswahl zugestimmt von 15 oder mehr Block-Erzeugern

Wenn ein Block-Erzeuger einen Block verpasst und und innerhalb der nächsten 24 Stunden keinen weiteren Block erzeugt, dann wird fürs erste keine Rücksicht mehr auf ihn genommen und er wird aus den Block-Erzeugungs-Runden herausgenommen, bis er dem Blockchain-System erneut das Signal meldet, an der Block-Erzeugungs-Runde teilnehmen zu wollen. Diese Vorgehensweise soll sicherstellen, dass das Netzwerk immer flüssig läuft und die Nummer von verpassten und nicht geminten Blöcken minimiert wird, in dem Block-Erzeuger, die anscheinend nicht geeignet sind, aussortiert werden.

Unter normalen Umständen erlebt eine Delegated Proof of Stake Blockchain keine Forks, weil die Block-Erzeuger nicht gegeneinander konkurrieren, sondern zusammenarbeiten. Wenn es zu der Situation einer Fork kommt, wird der Konsenus automatisch zu der längsten Kette wechseln. Diese Methode funktioniert, weil die Rate der hinzugefügten Blöcke korreliert direkt zu dem Prozentsatz an Block-Erzeugern, die den selben Konsneus teilen. In anderen Worten: Eine Blockchain-Fork mit mehr Block-Erzeugern wird schneller wachsen, als eine mit weniger Erzeugern, weil die Fork mit mehr Erzeugern weniger verpasste und ausgelassene Blöcke ereben wird.

Desweiteren wird kein Block-Erzeuger Blöcke gleichzeitig auf zwei Forks erzeugen. Ein Block-Erzeuger der dabei erwischt wird, wird sehr wahrscheinlich aus dem Erzeugungs-Prozess herausgevoted werden. Es soll zudem einen Kryptografischen Nachweis für solche Vorfälle benutzt werden, der einen automatischen Ausschluss zur Folge hat.

Byzantinische Fehler-Toleranz ist zu traditionellen Delegated Proof of Stake Methoden hinzugefügt, indem allen Block-Erzeugern erlaubt wird, alle Blöcke zu signen, solange sie nicht den selben Zeitstempel oder die selbe Blockgröße für mehr als einen Block verwenden. Sobald 15 Erzeuger einen Block gesigned haben, ist der Block unveränderlich anerkannt. Jeglicher Byzantinischer Blockerzeuger müsste einen kryptografischen Nachweis seines Verats generieren, indem er zwei Blöcke mit dem selben Zeitstmepel oder der selben Blockgrößer signed.

Mit diesem Modell sollte ein unveränderbarer Konsensus in etwa einer Sekunde erreichbar sein.

Transaktionsbestätigung

Typische Delegated Proof of stake Blockchains haben eine 100% Block-Erzeuger Beteiligung. Eine Transaktion kann als bestätigt angesehen werden nach einer durchschnittlichen Zeit von 0.25 Sekunden nach dem Zeitpunkt der Meldung.

Zusätzlich zu DPOS fügt die EOS.IO Software eine a-synchrone Byzantinische Fehler Toleranz (aBFT) hinzu, für ein schnelleres Erreichen eines unveränderlichen Konsenus. Der a-BFT Algorithmus stellt eine 100% Bestätigung der Unveränderbarkeit einer Transaktion nach etwa einer Sekunde sicher.

Transaktion als Proof of Stake

Die EOS.IO Software setzt voraus, dass jede Transaktion einen Teil des Hashs eines vorherigen Block-Headers enthält. Dieser Hash dient zwei Funktionen:

  1. Es verhindert eine Kopie einer transaktion auf Forks, die den referenzierten Block nicht enthalten
  2. es signalisiert dem Netzwerk, dass ein bestimmter Nutzer und sein Stake (Anteil) auf einer spezifischen Fork sind

Über die Zeit werden alle Nutzer auf der Blockchain bestätigt, was es sehr schwer macht, nachahmende Blockcketten zu forcieren, da die Nachahmung nicht in der Lage sein würde, die Transaktionen von der legitimen Blockkette zu migieren.

Accounts

Die EOS.IO Software genehmigt allen Accounts, von einem einzigartigen menschlich lesbaren Namen aus bis zu 12 Buchstaben referenziert zu werden. Der Name wird vom Erzeuger des Accounts ausgewählt. Der Account-Ersteller muss genug RAM besitzen, um den Account zu speichern, bis der Account Tokens staked um seine eigenen RAM zu reservieren.

In einem dezentralisierten Kontext werden App Entwickler die nominalen Kosten für die Accounterstellung bezahlen, um einen neuen Nutzer anzumelden. Traditionelle Unternehmen geben bereits signifikante Summen pro Kunden aus in Form von Werbung, kostenlosen Services und so weiter. Die Kosten, einen neuen Blockchain Account zu erstellen, sollten im Vergleich nicht nennenswert sein. Glücklicherweise ist es nicht nötig Accounts zu erstellen für Nutzer, die bereits bei einer anderen Applikation angemeldet sind.

Actions & Handlers (Aktionen und Anwendungen)

Jeder Account kann strukturierte Aktionen an andere Accounts schicken und kann Skripte definieren um Aktionen anzuwenden, wenn sie erhalten wurden. Die EOS.IO Software gibt jedem Account eine eigene private Datenbank, die nur von ihren eigenen Anwendern benutzt werden kann. Handlungsdefinierende Skripte können Aktionen zu anderen Accounts schicken. Die Kombination von Aktionen und automatisierten Anwendungsdefinitionen ist, wie EOS.IO smart Contracts definiert.

Um eine parallele Ausführung zu unterstützen, kann jeder Account eine Reihe von Bereichen in seiner Datenbank definieren. Die Block Erzeuger werden Transaktionen zeitlich so ausführen, dass kein Konflikt mit dem Speicherzugang zu diesen Bereichen entsteht und so können sie parallel ausgeführt werden.

Rollenbasiertes Zugangsmanagement

Zugangs- oder Genhemigungsmanagement beinhaltet, zu bestimmen, ob eine Applikation richtig autorisiert ist oder nicht. Die einfachste Form von Zugangsmanagement ist es, zu überprüfen, ob eine Transaktion die benötigten Signaturen hat, aber das setzt voraus, dass die benötigten Siganturen bereits bekannt sind. Im Allgemeinen ist Autorität an Individuen gebunden, oder Gruppen von Individuen und ist oft aufgeteilt. Die EOS.IO Software bietet ein festgelegtes Zugangsmanagement-System, das Accounts detaillierte Kontrolle auf hohem Level gibt, darüber wer was wann tun kann.

Es ist extrem wichtig, dass Authentigizierung und Zugangsmanagement standartisiert wird und separiert von der Geschäftslogik der Applikationen. Das ermöglicht Tools, die entwicklet werden können, um Zugänge auf einer universellen Ebene zu managen und gleichzeitig wird die Möglichkeit der Performance-Optimierung bereitgestellt.

Jeder Account kann kontrolliert werden durch jede gewichtige Kombination aus anderen Accounts und Private Keys. Das erzeugt eine hierarchiche Autoritäts-Struktur, die wiederspiegelt, wie Zugänge in der Realität organisiert sind und macht Multi-Nutzer Kontrolle über accounts einfacher den je. Multi-Nutzer Kontrolle ist der größte Beitrag zur Sicherheit, und wenn es richtig genutzt wird, kann es das Risiko des Diebstahls durch Hackings stark senken.

Die EOS.IO Software erlaubt es Accounts zu definieren, welche Kombination aus Keys und oder Accounts bestimmte Aktions-Typen zu anderen Accounts senden können. Zum Beispiel: Es ist möglich einen Key für den Social Media Account eines Nutzers zu haben und einen anderen für den Zugang zu einer Exchange. Es ist desweiteren möglich, anderen Accounts die Berechtigung zu geben zum handeln mit einem Nutzeraccount und all seinen Vorteilen zu geben, ohne den Key heruaszugeben.

Namentliche Berechtigungs-Levels

Durch die Nutzung der EOS.IO Software können Accounts namentliche Berechtigungs-Levels definieren, die jeweils abgeleitet werden von höheren Levels an namentlichen Berechtigungen. Jedes namentliche Berechtigungs Level definiert eine Autorität. Eine Autorität ist ein dreifacher multi-signatur Check bestehend aus Keys und/oder namentlichen Berechtigungs Leveln anderer Accounts. Ein Beispiel: Ein „Freund“ eines Accounts kann ein Berechtigungslevel für eine Aktion gesetzt bekommen, gleichberechtigt kontrolliert durch jeden der „Freunde“ des Accounts.

Ein weiteres Beispiel: Die Steem-Blockchain, die drei hard-coded namentliche Berechtigungslevels hat: 1. Owner 2. Active 3. Posting – also Besitzer, Aktiver User oder Kommentierer/Kommentar. Die „Posting“ Berechtigung kann nur soziale Aktionen ausführen wie zum Beispiel Votings oder Posten, während die „Active“ Berechtigung alles machen kann, außer den Besitzer des Accounts aktiv zu wechseln. Die „Owner“ Berechtigung ist gedacht für „cold storage“ und ist in der Lage alles zu tun. Die EOS.IO Software generalisiert dieses Konzept indem es jedem Account-Halter erlaubt ist, die eigene Hierarchie zu definieren, genau wie das gruppieren von Aktionen.

Berechtigungs-Abbildung

Die EOS.IO Software erlaubt jedem Account eine Abbildung zu definieren, zwischen einem Contract/Aktion oder einem Contract eines anderen Accounts und dem eigenen namentlichen Berechtigungslevel. Zum Beispiel: Ein Account-Halter könnte die Media Applikation des Account-Halters abbilden in dem Berechtigungsbereich eines „Freundes“ des Account-Halters. Mit diesem Abbilden könnte jeder Freund des Accounts posten als der Account Halter auf dem Social Media Kanal des Account-Halters. Selbst wenn sie als der Account-Halter posten würden, würden sie immer noch ihre eigenen Keys verwenden, um die Aktion zu verifizieren. Das bedeutet, dass es immer möglich ist, zu identifizieren, welche Freunde wann und in welcher Form den Account benutzt haben.

Berechtigungen evaluieren

Wenn eine Aktion vom Typ „Action“ gesendet wird, von „Alice“ zu „Bob“, dann wird die EOS.IO Software als erstes überprüfen, ob „Alice“ eine Berechtigungs-Abbildung für „Bob“s Unter-Bereiche, auf der die Aktion stattfinden soll, definiert hat. Wenn bei der Überprüfung nichts gefunden wird, werden schrittweise die Überverzeichnisse überprüft. Wenn keine Übereinstimmung gefunden wird, dann wird die angenommene Abbildung vorgenommen im „Active“ Bereich von „Alice“

Wenn die Abbildung einmal identifiziert ist, wird die Überprüfungs-Autorität validiert, indem der dreifache multi-signatur Prozess und die Autorität, die mit der namentlichen Berechtigung assoziiert ist, benutzt. Wenn das fehlschlägt, dann wird es verlegt in die Stamm-Berechtigung und abschließend in die Besitzer-Berechtigung „Alice Owner“

EOS Techniqual White Paper Github

EOS Techniqual White Paper Github

Standard Berechtigungsgruppen

Die EOS.IO Technologie erlaubt desweiteren, dass alle Accounts einen „Besitzer“ haben, der alles tun kann und eine „Active“ Gruppe/Bereich, die alles tun kann, außer die Beistzer-Gruppe/Bereich zu ändern. Alle anderen Berechtigungsgruppen sind hergeleitet aus dem „Active“ Bereich.

Parallele Evaluation von Berechtigungen

Der Prozess der Berechtigungs-Evaluation ist „read-only“ und Änderungen an Bererchtigungen durch Transaktionen nehmen keinen Effekt, bis zum Ende eines Blocks. Das heißt, dass alle Keys und Berechtigungs-Evaluationen für alle Transaktionen parallel ausgeführt werden können. Weiterhin bedeutet dies, dass eine schnelle Validierung einer Berechtigung möglich ist ohne eine rechenintensive Applikation zu starten, die wiederholt werden müsste. Abschließend heißt das, dass Transaktionsberechtigungen evaluiert werden können, während ausstehnde Berechtigungen ankommen und es ist nicht notwendig sie zu wiederholen wenn sie einmal angenommen wurden.

All diese Dinge berücksichtigt, eine Berechtigungsverifizierung repräsentiert einen signifikanten Prozentsatz der benötigten Rechenleistung die für die Validierung von transaktionen nötig ist. Der Fakt, dass eine Transaktion in einen bekannten, verifizierten Block integriert ist, genügt, um diesen Schritt zu übersrpingen. Das reduziert die Rechenleistung, bezogen auf eine weiterführende, immer größer werdende Blockchain signifikant.

Aktionen mit erzwungener/geplanter Verzögerung

Zeit ist ein essenzieller Bestandteil der Sicherheit. In den meisten Fällen ist es nicht möglich zu wissen, ob ein private key gestohlen wurde, bis er benutzt wurde. Zeitbasierte Sicherheit ist umso wichtiger, wenn Leute Applikationen nutzen wollen, die es notwendig machen, dass die keys sich auf Computern befinden, die mit dem Internet verbunden sind, wegen des täglichen Gebrauchs. Die EOS.IO Software ermöglicht es App Entwicklern zu kennzeichnen, das bestimmte Aktionen eine minimale Zeitperiode warten müssen, nachdem sie in einen Block integriert wurden, bevor sie akzeptiert/verifiziert werden können. Während dieser Zeitperiode können sie abgebrochen werden.

Nutzer können Informationen dazu per Mail oder SMS erhalten, wenn die Ausführung einer dieser Aktionen transferiert wird. Wenn sie sie nicht ausgeführt/ in Auftrag gegeben haben, dann können sie den Account-Wiederherstellungs-Prozess verwenden, um ihren Account wiederherzustellen und die Aktion rückgängig zu machen.

Die benötigte Verzögerung hängt davon ab, wie gehaltvoll die jeweilige Ausführung ist. Einen Kaffee zu bezahlen wird eher keine Verzögerung haben und in wenigen Sekunden unveränderlich sein, während der Kauf eines Hauses evtl. Eine 72 stündige Klärungs-Zeitperiode haben wird. Der Transfer eines ganzen Accounts in die Kontrolle eines neuen Besitzers könnte bis zu 30 Tage betragen. Die exakten Verzögerungen werden von den App-Entwicklern und den App-Nutzern bestimmt.

Wiederholen gestohlener Keys

Die EOS.IO Software bietet Nutzern die Möglichkeit an, die Kontrolle über ihren Account wiederherzustellen, wenn ihr Key gestohlen wird. Ein Account-Besitzer kann den „Besitzer-Key“ benutzen, der in den letzten 30 Tagen aktiv war zusammen mit der Bestätigung eines ausgewählten Account-Wiederherstellungs-Partners, um den Besitzer-Key auf den alten Account zurückzustellen. Der Account-Wiederherstellungspartner kann die Kontrolle ohne die Hilfe des Besitzers nicht wiederherstellen.

Es gibt für den Hacker nichts zu holen, indem versucht wird, durch den Wiederherstellungsprozess zu gehen, weil sie den Account bereits „kontrollieren“. Weiterhin, wenn sie nicht durch den Prozess gehen, würde der Wiederherstellungspartner eine Identifikation verlangen und eine Multi-Factor Autentifizierung (Handy oder e-mail). Das würde dazu führen, dass der Hacker am Ende so oder so nichts in Händen hält.

Dieser Prozess ist sehr unterschiedlich im Vergelich zu einem simplen multi-signature Arangement. [Für mich unverständlicher Satz:] With a multi-signature transaction, another entity is made a party to every transaction that is executed. Im Gegenzug ist der Wiederherstellungspartner nur ein Verbündeter im Bezug auf den Wiederherstellungsprozess und hat keine Kontrolle über die täglichen Transaktionen. Das reduziert die Kosten und rechtlichen Verbindlichkeiten aller Involvierten Parteien signifikant.

Deterministische parallele Ausführung von Applikationen

Ein Blockchain-Konsenus hängt von deterministischen (reproduzierbaren) Verhalten ab. Das heißt, dass alle parallelen Ausführungen frei sein müssen von der Nutzung von Mutexes (Verhindert gleichzeitige Ausführungvon Prozessen, die gemeinsam gentutzte Datenstrukturen verändern) oder anderen Verhinderungs-/Blockierungs-Mechanismen. Ohne diese Blockierungen muss es trotzdem möglich sein, zu garantieren, dass parallel ausgeführte Transaktionen keine nicht-deterministischen bzw. nicht reproduzierbaren Reslutate hervorbringen.

Die Veröffentlichung im Juni 2018 von EOS.IO Software wird eingleisig funktionieren, die Software enthält aber die Datenstrukturen, die nötig sind, um zukünftig „multithreated“, parallele Ausführungen durchzuführen.

Innerhalb einer EOS.IO software-basierten Blockchain, wird es, sobald parallele Ausführungen ermöglicht sind, die Aufgabe der Block-Erzeuger sein, Die Aktions-Vermittlung innerhalb unabhängiger Teilbereiche zu organisieren, sodass sie parallel evaluiert werden können. Die Ausführung ist der output eines Block-Erzeugers und wird deterministisch ausgeführt werden, aber der Prozess des Generierens eines Ausführungs-Zeitplans muss deterministisch sein. Das heißt, dass Block-Erzeuger parallele Algorithmen nutzen können, um Transaktionen zu planen.

Teil der parallelen Ausführung heißt, dass wenn ein Skript eine neue Aktion generiert, wird es nicht sofort transferiert, sondern wird geplant innerhalb des nächsten Zirkels übermittelt zu werden. Der Grund dass es nicht sofort übermittelt werden kann, ist, dass es sein könnte, dass der Empfänger gerade seinen eigenen Status in einem anderen Teilbereich aktiv modifiziert.

Minimierung der Kommunikations-Verzögerung

Verzögerung/Latenz ist die Zeit die es braucht, eine Aktion von einem Account zu einem anderen zu senden und dann die Antwort zu erhalten. Das Ziel ist es zu ermöglichen, dass zwei Accounts Aktionen hin und zurück austauschen können innerhalb eines einzigen Blocks ohne die 0.5 Sekunden warten zu müssen zwischen jeder Aktion. Um das zu ermöglichen, teilt die EOS.IO Software jeden Block in Zirkel. Jeder Zirkel ist in Teilbereiche unterteilt und jeder Teilbereich enthält eine Liste an Transaktionen. Jede Transaktion enthält ein Set an Aktionen die übermittelt werden sollen. Diese Struktur kann visualisiert werden als ein Baum an dem alternative Abzweigungen sequenziell und parallel produziert werden.

EOS Techniqual White Paper Github

EOS Techniqual White Paper Github

Transaktionen, die innerhalb eines Zirkels generiert werden, können in jedem folgenden Zirkel oder Block übermittelt werden. Block-Erzeuger werden immer mehr Zirkel hinzufügen bis das maximale Zeitfenster für einen Block erreicht ist oder keine neuen generierten Transaktionen mehr übermittlet werden müssen.

Es ist möglich eine statische analyse eines Blocks zu nutzen, um zu verifizieren, dass in einem Zirkel keine zwei Teilbereiche sind, die versuchen den selben Account zu modifizieren. Solange gewährleistet ist, dass es keine Zeitverzögerung gibt, kann ein Block erzeugt werden, indem alle Teilbereiche parallel bearbeitet werden können.

„Read-only“ Aktions-Anwendungen

Manche Accounts können in der Lage sein eine Aktion auf einer Bestanden/Nicht-Bestanden Basis auszuführen ohne ihren internen Zustand zu modifizieren. Wenn das der Fall ist, dann können diese Anwendungen parallel ausgeführt werden, solange nur „only-read“ Aktions-Anwendungen für einen bestimmten Account involviert sind in einem oder mehreren Teilbereichen innerhalb eines bestimmten Zirkels.

Atomic Transaction mit mehreren Accounts

Manchmal ist es erstrebenswert zu gewährleisten, dass Aktionen übermittelt und akzeptiert werden von mehreren Accounts auf atomarer Ebene. In diesem Fall sind beide Aktionen platziert in einer Transaktion und beide Accounts werden den selben Teilbereich benutzen und die Aktionen sequenziell bestätigen.

Partielle Evaluation des Blockchainstatus

Eine skallierte Blockchain Technologie erfordert es, dass gewisse Komponenten mdoular sind. Nicht jeder muss alle Daten bearbeiten/speichern, vor allem wenn sie nur einen kleinen Tiel der Applikationen benutzen wollen.

Ein Exchange-App-Entwickler lässt Full-Notes arbeiten, zu dem Zweck den Status der Exchange den Nutzern anzuzeigen. Diese Exchange-Applikation hat keinen Bedarf an dem Status der im Bezug zu Social Media Applikationen steht. EOS.IO Software erlaubt jedem Full-Note eine Unterauswahl an Applikationen auszuwählen und zu verwalten. Aktionen, die zu anderen Applikationen übermittelt werden, werden sicher ignoriert, wenn die Applikation niemals von dem Status eines anderen Contracts abhängt.

Subjektives „Best Effort“ Ausführen/Planen

Die EOS.IO Software kann die Block-Erzeuger nicht zwingen, jede Aktion an jeden anderen Account zu übermitteln. Jeder Block-Erzeuger macht seine eigene subjektive Einschätzung/Messung der rechen/arbeitsleistungs bezogenen Komplexität und der benötigten Zeit zur Ausführung einer Transaktion. Das kommt darauf an, ob eine Transaktion durch einen Nutzer erzeugt wird, oder autmomatisch durch einen smart contract.

Auf einer gestarteten Blockchain, die die EOS.IO Software benutzt, sind, auf einem Netzwerk-Level, alle Transaktionen berechnet auf einer rechenleistungs-bandweiten-Berechnung, die basiert ist auf der Anzahl von WASM Instruktionen, die ausgeführt werden. Jeder individuelle Block-Erzeuger, der die Software nutzt, sollte das Nutzen von Ressourcen selbst kalkulieren mit eigenen Algorithmen und Messmethoden. Wenn ein Block-Erzeuger zu dem Schluss kommt, dass eine Transaktion oder ein Account einen unverhältnismäßigen Betrag an Rechenleistungskapazität benutzt hat, dann kann die Transaktion einfach abgelehnt werden, wenn der eigene Block erzeugt wird. Wenn andere Block-Erzeuger die Transaktion jedoch als gültig erachten, wird sie trotzdem durchgehen.

Generell, solange mindestens 1 Block-Erzeuger eine Transaktion auch im Hinblick unter den Ressourcen-Nutzungs-Limitierungen als gültig erachtet, dann werden alle anderen Block-Erzeuger die Transaktion auch als gültig erachten, aber es könnte bis zu einer Minute dauern, bis die Transaktion einen Produzenten/erzeuger findet.

In manchen Fällen könnte ein Block-Erzeuger einen Block erzeugen, der Transaktionen beinhaltet, die eine Ausführung in einer Größenordnung darstellen, die außerhalb der akzeptierbaren Verhältnisse sind. In diesem Fall wird sich der nächste Block-Erzeuger evtl.dafür entscheiden, den Block abzulehnen und das Unentschieden wird mit dem dritten Block-Erzeuger entschieden. Das ist nicht unterschiedlich zu dem was passieren würde, wenn ein großer Block zu Netzwerk-Übertragungs-Verzögerungen führen würde. Die Community würde den Versuch der Ausnutzung bemerken und ihre Stimmen vom Block-Erzeuger abziehen.

Diese subjektive Evaluation von rechenleistungs-Kalkulaitionen berfreit die Blockchain von einer notwendigen peräzisen und deterministischen Messung, wie lange etwas dauern soll. Mit diesem Design besteht keine Notwendigkeit die Instruktionen präzise zu zählen. Das erhöht die Möglichkeiten für Optimierungen dramatisch, ohne mit dem Konsensus zu brechen.

Aufgeschobene Transaktionen

Die EOS.IO Software unterstützt aufgeschobene Transaktionen, die ausgewählt wurden, in der Zukunft ausgeführt zu werden. Das ermöglicht rechenleistung zu verschiedenen Teilbereichen zu verlagern und/oder die Erzeugung von längerfristigen Prozessen, die kontinuierlich fortlaufende Transaktionen aufgeben.

Aktionen ohne Kontext

Eine Aktion ohne Kontext involviert rechenleistungen die nur eine Transaktionsdatei erfordern, aber nicht bezogen auf den Blockchain-Status. Signatur-Verifizierung, zum Beispiel, ist eine Rechenleistung, die nur die Transaktionsdatei und eine Signatur erfordert, um den public Key festzulegen, der die Transaktion gesigned hat. Das ist eine der aufwendigsten individuellen Rechenleistungen, die eine Blockchain ausführen muss, aber weil die Rechenleistung ohne Kontext ist, kann sie parallel ausgeführt werden.

Aktionen ohne Kontext sind wie andere Nutzer-Transaktionen, außer sie benötigen Zugang zum Blockchain-Status um die Validierung durchführen zu können. Die EOS.IO Software ermöglicht das nicht nur, um alle Aktionen ohne Kontext, wie zB Signatur-Verifizierung parallel auszuführen, sondern viel wichtiger noch, es ermöglicht generalisierte Signatur-Verifizierungen.

Mit der Unterstützung von Aktionen ohne Kontext, werden Skalierungstechniken wie zB Sharding, Raiden, Plasma, State Channels und andere parallel schaltbarer und praktischer. Diese Entwicklung ermöglicht inter-blockchain Kommunikation und potentiell unlimitierte Skalierung.

Token-Modell und Ressourcen-Nutzung

Alle Blockchains sind Ressourcen-abhängig und benötigen ein System um Missbrauch zu verhindern. Mit einer Blockchain die EOS.IO Software benutzt, gibt es drei umfassende Aspekte, die von Applikationen genutzt werden.

  1. Bandbreite und Protokollverwahrung
  2. Rechenleistung und Sicherheitskopien von Berechnungen
  3. Status Sicherheitsverwahrung

Bandbreite und Rechenleistung haben zwei Komponenten, sofortige Nutzung und langezeit-Nutzung. Eine Blockchain unterstützt ein Protokoll aller aktionen und dieses Protokoll ist abschließend geseichert und aufbewahrt von allen Full-Notes. Mit dem Protokoll aller Aktionen ist es möglich den Status aller Applikationen wiederherzustellen.

Die Rechenleistungs-Aufgabe sind Kalkulaitonen die ausgeführt werden müssen um den Status vom Aktions-Protokoll zu regenerieren. Wenn die Rechenleistungs-Aufgabe zu groß wird, wird es notwendig Snapshots vom Status der Blockchain zum machen und die Transaktionsgeschichte der Blockchain abgetrennt zu verwahren. Wenn die Rechenleistungs-Aufgabe zu schnell zu groß wird, dann würde es evtl. 6 Monate dauern um ein Jahr an Transaktionen abzuwickeln. Es ist daher unabdingbar, dass die Rechenleistungs-Aufgabe sorgfältig überwacht wird.

Die Blockchain-Status-Verwahrung ist eine Information, die von der Applikations-Logik zugänglich ist. Sie enthält Informationen wie zum Beispiel Transaktions-Aufzeichnungen oder Account-Balances. Wenn der status nie von der Applikation gelesen wird, dann wird er auch nicht gespeichert. Zum Beispiel: Blog-Post-Content und Kommentare werden nicht von der Applikations-Logik gelesen, also werden sie auch nicht im Blockchain-Status gespeichert. Währendessen werden aber die Existenz eines Posts oder Kommentars, die Anzahl an Votes und andere Werte im Blockchain-Status gespeichert.

Block-Erzeuger veröffentlichen ihre verfügbare Kapazität an Bandbreite, Rechenleistung und Status. Die EOS.IO Software erlaubt jedem Account, einen Prozentsatz der verfügbaren Kapazität zu benutzen, proportional zu der anzahl an Tokens, die sie in einem drei-tages-staking-contract halten. Zum Beispiel: Wenn eine auf der EOS.IO Software basierende Blockchain gestartet wird und wenn ein Account 1% der maximalen Tokenanzahl besitzt, dann hat dieser Account das Potential 1% der Status Aufbewahrungs Kapazität zu nutzen.

Angewendet auf die EOS.IO Software auf einer gestartetebn Blockchain bedeutet das Bandbreite und Rechenleistungs-Kapazität auf einer partiellen Reserve-Basis gelagert sind, da sie vergänglich sind. Ungenutzte Kapazität kann nicht für zukünftige Nutzung gesichert werden). Der benutzte Algorithmus ist ähnlich wie der Algorithmus, der von Steem benutzt wird um Bandbreiten-Nutzung zu limitieren.

Objektive und Subjektive Bemessung

Wie vorher bereits diskutiert, hat benutzte Rechenleistungs-Nutzung signifikante Auswirkungen auf Performance und Optimierung. Deswegen sind jegliche Ressourcen-Nutzungs-Einschränkungen subjektiv und eine Verbesserung wird durch die Block-Erzeuger erzielt, in Abhängigkeit zu ihren genutzten Algorithmen und Kalkulationen. Das würde typischerweise durch einen Block-Erzeuger implementiert, über das Schreiben eines Individuellen Plugins.

Es gibt bestimmte Dinge, die belanglos sind im Bezug auf Messungs-Objektivität. Die Anzahl der übermittelten Aktionen, und die Größe der gespeicherten Daten in der internen Datenbank sind einfach objektiv zu messen.

Adressaten-Zahlungen

Traditionell bezahlen Firmen die Rechnungen für Büroräume, Hardware und andere Dinge, die man für ein Unternehmen benötigt. Der Kunde kauft spezifische Produkte der Firma und der Gewinn dieser Produkt-Verkäufe wird benutzt um die laufenden Kosten zu decken. Ganz ähnlich ist es bei Websites, die ihren Besuchern keine Mikrotransaktionen abverlangen, wenn sie die Website besuchen wollen, um Serverkosten abzudecken. Deswegen sollten Dapps auch nicht von ihren Nutzern verlangen, die Blockchain direkt für ihren Nutzen zu bezahlen.

Eine gestartete Blockchain, die die EOS.IO Software benutzt, braucht ihre Nutzer nicht direkt für die Nutzung der Blockchain bezahlen zu lassen und zwingt somit auf ihr laufende Geschäftsmodelle nicht dazu, ihre Strategien darauf abzustimmen.

Während es möglich ist, dass der empfänger zahlen kann, ermöglicht EOS.IO dem Sender für Bandbreite, Rechenleistung und Speicher zu bezahlen. Das bemächtigt App-Entwickler dazu, sich eine bevorzugte Methode auszusuchen. In vielen Fällen verringern Sender-Zahlungen die Komplexität für Entwickler signifikant, die kein eigenes Zahlungsfluss-System integrieren wollen. App-Entwickler können Bandbreite und Rechenleistung an ihre Nutzer delegieren und das „Sender-bezahlt“ Modell aufstellen. Aus der Perspektive der Endnutzer ist die Nutzung kostenlos, aber aus der Perspektive der Blockchain finden dann trotzdem Sender-Zahlungen statt.

Delegierte Kapazität

Ein Token-Halter auf einer Blockchain, die EOS.IO benutzt, der keinen direkten Bedarf daran hat, seine ganze verfügbare Bandbreite zu nutzen, kann diese an andere Nutzer weiterleiten oder vermieten. Die Block-Erzeuger zeichnen diese Weitergabe von Kapazität auf und leiten sie dementsprechend weiter.

Transaktionskosten abgetrennt vom Token-Preis

Einer der größten Vorteile der EOS.IO Software ist, dass der Spielraum an Bandbreite, der für eine Applikation zur Verfügung steht, vollkommen unabhängig vom Token-Preis ist. Wenn ein App-Besitzer eine relevante Menge an Tokens auf einer Blockchain mit EOS.IO hält, dann kann die Applikation unbegrenzt mit einem fixen Stadium an Bandbreite genutzt werden. In so einem Fall sind Entwickler und Nutzer nicht betroffen von irgendwelchen Preisschwankungen des Token-Marktes und somit auch nicht abhängig von Preis-Entwicklungen. In anderen Worten: Eine Blockchain, die EOS.IO Software anwendet, ermöglicht es den Block-Erzeugern auf natürliche Weise die Bandbreite, Rechenleistung und Speicher pro Token zu erhöhen, unabhängig von seinem Wert.

Eine Blockchain, die die EOS.IO software benutzt, belohnt Block-Erzeuger jedes Mal wenn sie einen neuen Block erzeugen. Der Wert des Tokens wird die Höhe der Bandbreite, des Speichers und der Rechenleistung beeinflussen, in dem Sinne wie viel davon sich ein Produzent leisten kann. Dieses Modell unterstützt auf natürliche Weise, dass ein steigender Token-Wert die Netzwerk-Performance verbessert/erhöht.

Status Speicher Kosten

Während Bandbreite und Rechenleistung zugewiesen/geleitet werden können, benötigt der Speicher von App-Statusen einen App-Entwickler der Token besitzt bis der jeweilige Status entfernt wird. Wenn der status niemals entfernt/gelöscht wird, dann sind die Tokens effektiv aus der allgemeinen Netzwerk-Zirkulation herausgenommen.

Block Belohnungen

Eine Blockchain, die EOS.IO Software benutzt, wird Block-Erzeuger für jeden neuen Block mit neuen Tokens belohnen. Unter diesen Umständen, ist die Anzahl an Tokens die generiert wird, abhängig von der angestrebten Bezahlung, die von allen Block-Erzeugern veröffentlicht wird. Die EOS.IO Software kann so konfiguriert werden, dass eine Obergrenze an Belohnungen für Block-Erzeuger entsteht, sodass die Inflation des Token-Supply niemals 5% übersteigt.

Arbeitsvorschlag /Projektvorschlag System

Zusätzlich zur Wahl der Block-Erzeuger, gemäß einer Blockchain, die auf EOS.IO basiert, wird es möglich sein, dass Token-Besitzer eine Reihe von „Worker Proposals“ / Arbeitsvorschlägen wählen können, die Verbesserungen für die Community bringen sollen. Die Vorschläge, die gewinnen, erhalten einen gewissen Anteil von Tokens aus der Token-Inflation abzüglich der Tokens, die den Block-Erzeugern gewährt werden. Diese Vorschläge werden Token erhalten, proportional zu den Votes, die jede Applikation von den Token-Besitzern erhalten hat, bishin zu einer Anzahl, die sie angefragt haben und die sie brauchen, um umgesetzt werden zu können. Die gewählten Arbeitsvorschläge/Verbesserungen können durch neu gwählte Vorschläge seitens der Token-Besitzer ersetzt werden.

Das System bestimmt, dass beim ersten Launch von EOS keine „Worker Proposals“ implementiert werden, aber der Funding-Mechanismus wird direkt eingeführt. Der Funding-Mechanismus wird damit anfangen Funds zu sammeln zur selben Zeit wie die Belohnung der Block-Erzeuger startet. Sobald das Worker Proposal System implementiert wird, kann es ohne Fork in die Blockchain eingefügt werden.

Sicherheit / Steuerung / Governance

Sicherheit ist der Prozess, bei dem Leute innerhalb der Community:

  1. einen gemeinsamen Konsenus finden zu subjektiven Entscheidungsfragen von kollektiver Bedeutung, die nicht komplett von Software-Algorithmen erfasst und verarbeitet werden können.
  2. Die Entscheidungen, die sie getroffen haben, übertragen
  3. die Sicherheits/Steuerungsregeln ändern, durch konstituuionelle Verbesserungen

Eine auf EOS.IO basierende Blockchain implementiert einen Sicherheits-Prozess, der den exisitierenden Einfluss der Block-Erzeuger leitet. Ohne einen definierten Sicherheits-Prozess waren frühere Blockchains angewiesen auf informelle, oft kontroverse und „ad hoc“ Sicherheits-Prozesse, die oft zu unerwarteten Ergebnissen geführt haben.

Eine EOS basierte Blockchain versteht, dass Macht daraus entsteht, dass Token-Besitzer diese Macht auf die Block-Erzeuger delegieren. Den Block-Erzeugern wird limitierte und kontrollierte autorität gegeben, Accounts einzufrieren, fehlerhafte Apps zu updaten und Hard-Fork-Änderungen unter Berücksichtigung des zugrundeliegenden Protokolls vorzuschlagen.

In die EOS.IO Software ist die Wahl der Block-Erzeuger integriert. Bevor irgendeine Änderung an der Blockchain gemacht werden kann, müssen die Blockerzeuger dem erst zustimmen. Wenn die Blockerzeuger sich weigern, von den Token-Besitzern gewünschte Änderungen vorzunehmen, können sie abgewählt werden. Wenn die Block-Erzeuger Änderungen ohne die Erlaubnis der Token-Besitzer durchführen, dann werden alle anderen, nicht produzierenden Full-Note Validierungs-Parteien die Änderung ablehnen.

Accounts einfrieren

Manchmal verhält sich ein Smart Contract in unerwarteter oder den Regeln abweichender Weise und versagt dabei, seine gegebene Aufgabe zu erfüllen. Oder es kommt vor, dass eine App oder ein Account einen Fehler entdecken, der es ihnen erlaubt, eine inakzeptable Menge an Ressourcen zu nutzen. Wenn solche Fälle zwangsläufig vorkommen, haben die Block-Erzeuger die Macht, solche Vorkommnisse zu beheben.

Die Blockerzeuger auf allen Blockchains haben die Macht, zu entscheiden, welche Transaktionen in die erzeugten Blöcke integriert werden. Das gibt ihnen die Möglichkeit, Accounts einzufrieren. Eine Blockchain, die EOS.IO anwendet, formuliert diese Autorität, indem sie den Vorgang des Einfrierens als 15/21 Abstimmung unter den aktiven Block-Erzeugern formuliert. Falls die Block-Erzeuger dies ausnutzen sollten, können sie abgewählt werden und der betroffene Account ist nicht mehr eingefroren.

Account-Code ändern

Wenn alles andere fehlschlägt und eine „unaufhaltbare App“ in einer unberechenbaren Art und Weise agiert, erlaubt eine Blockchain auf EOS basis den Block-Erzeugern den Code des betroffenen Accounts zu ersetzen ohne eine Hard-Fork einsetzen zu müssen. Ähnlich wie das Einfrieren eines Accounts wird dies über eine 15/21 Abstimmung entschieden.

Basis-Regeln / Constitution

Die EOS.IO Software ermöglicht es einer Blockchain ein peer-to-peer Nutzungsbedingungen-Agreement zu etablieren, oder einen bindenden Vertrag zwischen den unterzeichnenden Parteien, gemäß einem „Grundgesetz/Basis-Regelwerk“. Der Inhalt dieser Constitution definiert Verpflichtungen zwischen den Nutzern, die nicht komplett durch einen Code forciert werden können und erleichtert Problem/Streitlösungen durch die Etablierung einer Jurisdiktion und Gesetzeswahl zusammen mit anderen gegenseitig akzeptierten Regeln. Jede Transaktionsmitteilung innerhalb des Netzwerks muss den Hash des Regelwerks beinhalten als Teil der Signatur und den Unterzeichner des Vertrages binden.

Das Regelwerk definiert weiterhin die menschlich-lesbare absicht/Sinn hinter dem Quellcode-Protokoll. Diese Absicht/Sinn wird benutzt, um den Unterschied zu identifizieren zwischen einem Bug und einem Feature, wenn Fehler auftreten und leitet die Community an welche Fixes in Ordnung sind und welche nicht.

Das Protokoll und das Regelwerk upgraden

Der folgende durch EOS.IO definierte Prozess bschreibt, wie das Protokoll, definiert durch den vorschritsmäßigen Code und das Basisregelwerk, geupgraded werden kann.

  1. Die Block-Erzeuger schlagen eine Änderung des Regelwerks vor und benötigen eine 15/21 Mehrheit
  2. Die Block-Erzeuger behalten eine 15/21 Mehrheit für das veränderte Regelwerk für die nächsten 30 Tage
  3. Alle Nutzer werden benötigt, um die Zustimmung des neuen Regelwerkes einzuleiten, als neues Regelwerk für zukünftige Transaktionen
  4. Die Block-Erzeuger nehmen die Änderungen am Quellcode vor und veröffentlichen es im neuen Regelwerk und schlagen es dann der Blockchain vor, indem sie den Hash des neuen Regelwerkes benutzen
  5. Die Blockerzeuger brauchen eine 15/21 Zustimmung des neuen Codes für die nächsten 30 Tage
  6. Die Änderungen treten 7 Tage später in Kraft, so wird allen nicht produzierenden Full Notes die Zeit gegeben auf den neuen Quellcode zu upgraden
  7. Alle Nodes, die den neuen Quellcode nicht annehmen werden automatisch heruntergefahren

Standardmäßig dauert das Updaten der Blockchain und das Hinzufügen neuer Features 2 bis 3 Monate, während Updates zum reparieren nicht-essenzieller Fehler, die keine Änderung am Basis-Regelwerk benötigen, 1 bis 2 Monate dauern.

Notfall-Änderungen

Die Blockerzeuger können den Vorgang beschleunigen, wenn eine Softwareänderung notwendig ist, um einen gefährlichen Fehler oder Sicherheits-Lücke zu beheben, die aktiv Nutzer schädigt. Generell gesagt könnte es gegen die Basisregeln sein, neue Features oder Behebungen von harmlosen Fehlern mit einem beschleunigten Update umzusetzen.

Skripte und virtuelle Maschinen

Die EOS.IO Software wird zuallererst eine Plattform sein, die für das koordinierte Vermittlen von autorisierten Nachrichten (called Actions/Aktionen) an andere Accounts zuständig ist. Die Details der Programmiersprache und virtuellen Maschinen sind implementierungsspezifische details die größtenteils unabhängig sind vom Aufbau der EOS Technologie. Jede Sprache oder virtuelle Maschine, die deterministisch und vernünftig gesandboxed ist und ausreichend Performance hat, kann in die EOS.IO Software API eingebettet werden.

Schema-definierte Aktionen

Alle Aktionen, die zwischen Accounts hin und her gesendet werden, sind definiert durch ein Schema, welches Teil des Blockchain-Konsensus-Status ist. Dieses Schema erlaubt eine nahtlose Übertragung zwischen binären und JSON repräsentationen der Aktionen.

Schema-definierte Datenbanken

Der Datenbanken-Status ist ebenfalls nach einem ähnlichen Schema definiert. Das sichert, dass alle Daten aller Applikationen in einem Format gespeichert sind, das als menschlich-lesbares JSON angelegt ist, aber gespeichert und verändert mit der Effizienz von Binärcode.

Generische Multi-Index-Datenbanken-API

Um Smart Contracts zu entwickeln, benötigt es ein definiertes Datenbank Schema, um die Daten zu finden, zu speichern und zu tracken. Entwickler brauchen normalerweise die selben Daten, sortiert oder indexiert durch mehrere Felder und um Konsistenz zwischen den Indexen zu bewahren.

Authentifizierung von Applikation separieren

Um parallele Möglichkeiten zu maximieren und um Rechenleistungsanforderungen im Bezug auf regenerierenden App-status durch das Transaktions-Log zu minimieren teilt die EOS Software die Validierungs-Logik in drei Sektionen auf:

  1. Validieren, das eine Aktion intern konsistent ist.
  2. Validieren, dass alle Voraussetzungen gültig sind
  3. Modifizieren des Applikations-Status

Die Gültigkeit der internen Konsitenz einer Aktion zu überprüfen ist ein „read-only“ Vorgang und benötigt keinen Zugang zum Blockchain-Status. Das heißt, dass es komplett parallel ausgeführt werden kann. Voraussetzungen überprüfen, wie zum beispiel die benötigte Balance, ist auch ein „read-only“ Vorgang und kann daher ebenfalls von einer Parallelschaltung profitieren. Nur Modifizierungen von App-Status benötigt Schreibrechte und muss sequenziell für jede applikation von statten gehen.

Authentifizierung ist ein „read-only“ Prozess zur Verifizierung, dass eine Aktion ausgeführt werden kann. Die Applikation macht die eigentliche Arbeit. Es ist notwendig, das beide berechnungen in Echtzeit getätigt werden, wobei der Authentifizierungsprozess nicht mehr notwendig ist, wenn die Transaktion einmal in der Blockhcain gespeichert ist.

Inter-Blockchain-Kommunikation

Diesen Abschnitt habe ich leider nicht verstanden und konnte ihn auch nicht übersetzen.

Fazit

Die EOS.IO Software ist durch Erfahrung mit bereits erfolgreichen Konzepten und besten Praktiken designed worden und repräsentiert fundamentale Verbesserungen/ Errungenschaften innerhalb der Blockchain-Technologie. Die Software ist Teil einer ganzheitlichen Blaupause für eine global skalierbare Blockchain-Gemeinschaft, in der dezentralisierte Applikationen einfach entwickelt und geleitet werden können.

Tags: , , , , , , , , , ,
Der Autor dieses Blogs.

0 Comments

Leave a Comment

%d Bloggern gefällt das: