Der 10. Juni war der dritte Tag unserer Akklimatisation in Hongkong. Und die letzten 26 Stunden haben wir fast ohne Schlaf verbracht und in der ersten Phase des EOS Global Hackathons ein Prototypprojekt unter dem Arbeitsnamen SensorPay mit einem Gesamtpreispool von eineinhalb Millionen Dollar entwickelt. Der Moment der Demonstration des Projekts vor den Richtern rückte näher.

Wenn Sie wissen möchten, wie diese Geschichte endete, schauen Sie sich gleich den letzten Teil an. In der Zwischenzeit werden wir systematisch über EOS-Technologien sprechen und wie wir auf die Idee gekommen sind, Zahlungen für IoT mit EOS zu verknüpfen. Gleich danach wird es eine detaillierte Beschreibung der technischen Füllung des Projekts geben.

0. Hintergrund

EOS ist eine Blockchain der neuen Generation, manche halten sie sogar für einen Ethereum-Killer. Wenn Sie plötzlich nicht mehr wissen, was eine Blockchain oder ein Ethereum ist, hilft Google. Und wir haben vor ungefähr einem Jahr angefangen, EOS auszugraben, unter anderem indem wir die früheren Produkte der Autoren BitShares und Steem studiert haben.

Die Vorteile von EOS gegenüber Ethereum: Der Transaktionsdurchsatz ist um drei Größenordnungen höher. entwickeltes Genehmigungssystem für intelligente Verträge; die Fähigkeit, verlorenen Zugriff wiederherzustellen und Fehler in der Blockchain zu beheben; Onchain-Netzwerkverwaltung. Schwächen: Bedenken hinsichtlich der Zentralisierung, potenziell anfälligerer DPoS-Konsens, Rohcode und eine steilere Lernkurve für Entwickler.

Da wir diese Technologie schon lange lieben und für vielversprechend halten, konnten wir die Reihe von Hackathons, die von den Autoren von EOS unterstützt wird, nicht außer Acht lassen. Wir wollten einfach nur da sein, unsere Ideen in diesem inspirierenden Umfeld verwirklichen und sie einem breiten Publikum zugänglich machen. Natürlich wurde die Möglichkeit, gutes Geld zu gewinnen, auch zu einem zusätzlichen angenehmen Motivator.

Daher ist EOS die einzige funktionierende Lösung für die öffentliche Blockchain, von der wir wissen, wo Sie VIELE Transaktionen ausführen können. Wo ist es erforderlich? Natürlich im IoT! In der Tat, wenn jeder Toaster zu Mikrozahlungen wird, zahlt er für jedes Stück Brot an den Kühlschrank (und dies ist, wie Sie verstehen, standardmäßig cool), wird es viele Transaktionen geben. Ganz zu schweigen von allen möglichen anderen Anwendungen in Medizin, Industrie und Alltag.

Einige Wochen vor dem Hackathon tauchten regelmäßig alternative Ideen auf und es fanden kleine Brainstorms statt. Wir haben Ideen anhand bekannter Schiedsrichterkriterien verglichen: Nutzung von EOS-Funktionen, Kreativität, öffentliche Wirkung und Skalierbarkeit. Aus diesem Grund haben wir uns für IoT + EOS entschieden - eine Lösung, die Daten von Sensoren übernimmt und viele Zahlungsvorgänge an EOS sendet.

Übrigens wollten wir hier auch erzählen, wie wir unseren Block Producer für EOS erzogen haben; wie sie vorhatten, den Konstrukteur von ERC721-ähnlichen Token und die Unterstützung für konstante Funktionen für ihn zu spülen; Wie haben sie das Merkle Root ACL-Protokoll eingereicht? All dies passt jedoch nicht in den Artikel, sodass wir zu unserem Hauptprojekt zurückkehren werden.

1. Vorbereitung

1.1. IoT

Um den IoT-Teil des Projekts vorzubereiten, muss die richtige Hardware ausgewählt werden. In der Rolle des RFID-Lesegeräts wurde der RC522 ausgewählt, der auf dem SPI-Bus arbeitet: Er ist beliebt und einfach zu bedienen.

Bei der Suche nach einem Zähler haben wir uns auf das Vorhandensein eines Impulsausgangs konzentriert, da Sie damit Daten sehr einfach lesen können: Ein Impuls ist X kW⋅h (wobei X vom Modell abhängt). Daher haben wir am Mercury 201.5-Zähler angehalten.

Am schwierigsten war es, sich für den Controller zu entscheiden, der Daten von den Sensoren sammelt, eine Transaktion bildet, sie mit Ihrem privaten Schlüssel signiert und an das Netzwerk sendet. Dementsprechend benötigten wir ein Gerät mit einem Netzwerkmodul, das eine Transaktion mit ECDSA signieren konnte (in diesem Fall auf der elliptischen Kurve secp256k1, da es in EOS zum Signieren verwendet wird).

Die Wahl fiel zunächst auf den Mikrocontroller ESP8266, der über ein Wi-Fi-Modul und alle erforderlichen Schnittstellen zum Anschluss unserer Sensoren verfügt. Gleichzeitig ist es sehr kompakt. Aber keine der Firmware hat eine native Implementierung von elliptischen Grundelementen. Es ist möglich, eine eigene Implementierung zu schreiben, dies ist jedoch keine Aufgabe für den Hackathon. Als Ergebnis wurde Raspberry Pi 3 B für den Prototyp ausgewählt und die eosjs-Bibliothek wurde zum Generieren und Signieren von Transaktionen verwendet.

1.2. Die Infrastruktur

Einige Tage vor dem Hackathon haben wir vor Ort und auf dem Server eos-hackathon.smartz.io eine EOS-Assembly ( Quelle ) vorbereitet. Die Installation, Montage und Tests von Abhängigkeiten verliefen für ein so junges Projekt überraschend reibungslos (mithilfe der Dokumentation ). Es gab nicht genug Zeit für die Vorbereitung anderer Infrastrukturen, und ich musste mich bereits während des Hackathons damit befassen.

1.3. Architektur

Am Vorabend des Hackathons diskutierten wir die Architektur und klärten die Produktdetails. Wir wollten die folgenden Hauptfälle implementieren: Zahlungen für Strom und Zahlungen für Einkäufe, die mit RFID-Tags gekennzeichnet sind. Sie planten auch, das Produkt leicht erweiterbar zu machen und es in anderen Bereichen zu verwenden.

Die Idee der Architektur ist, dass der Dienstleister (Produzent) einen Vertrag erstellt - den zentralen Punkt der Interaktion zwischen Lieferant und Verbraucher. Jeder Verbraucher hat sein eigenes Guthaben, das aufgefüllt werden kann. Die Gelder werden auf der Grundlage von Sensorsignalen abgebucht. Alle Daten - Benutzer, Sensoren, Statistiken - werden im Lieferantenvertrag gespeichert.

Benutzereinstellungen sind dem Verbraucher oder Flags (z. B. einer bevorzugten Benutzerkategorie) zugeordnet - user_meta . Mit dem Verbraucher können mehrere Sensoren verbunden werden, für die jeweils ein Vertrag und Abrechnungseinstellungen ( billing_meta ) angezeigt werden. So können Sie einen unveränderlichen staatenlosen Abrechnungsvertrag abschließen, der für eine große Anzahl von Verbrauchern verwendet wird. Die erforderlichen Daten werden während des bill(payload, user_meta, billing_meta) der bill(payload, user_meta, billing_meta) . Es wird auch die Möglichkeit einer unterschiedlichen Abrechnungslogik, d. H. Unterschiedlicher Verträge, festgelegt: Zum Beispiel betrachtet einer Strom, der andere Waren. Jeder Sensor hat einen „Zeiger“ auf seinen Abrechnungsvertrag.

Es wird davon ausgegangen, dass der Verbraucher dem Sensorhersteller vertraut, dem Dienstleister jedoch nicht unbedingt. Die Schnittstelle zur Interaktion mit dem Sensor ist äußerst einfach: Es handelt sich um einen Aufruf der Lieferantenvertragsmethode mit einem numerischen Parameter, der in die Abrechnung übertragen wird. Der Dienstleister startet Verbraucher, Sensoren, Abrechnungsverträge und deren Beziehungen in seinem Vertrag mithilfe von Kontrolltransaktionen - primitiven Setzern. Wenn eine Transaktion vom Sensor empfangen wird, werden Daten überprüft, Daten für die Abrechnung generiert, die Abrechnung aufgerufen, die Zahlung aufgezeichnet und Statistiken aufgezeichnet.

Vielleicht haben wir vor allem die folgenden Punkte besprochen, die für die Anwendbarkeit des Produkts in der realen Welt wichtig sind:

Anzahlungen oder Nachzahlung? Füllen Sie Ihr Konto auf und verwenden Sie es (wie eine Mobilfunkverbindung) - oder verwenden Sie es und zahlen Sie es dann aus (wie AWS)? Hier gibt es keine richtige oder falsche Antwort: Unterschiedliche Unternehmen bevorzugen unterschiedliche Modelle. Der Einfachheit halber haben wir uns für Vorauszahlungen entschieden.
Sollte der Benutzer für jeden Lieferanten ein separates Konto führen oder stammen alle Gebühren von einem Konto? Wieder - es gibt keine richtige und falsche Entscheidung; Darüber hinaus hängt die Antwort eng mit der Antwort auf die vorherige Frage zusammen. Vorauszahlungen sind gute Freunde mit individuellen Verbraucherkonten - sie wurden genommen.
Eine Gebühr in EOS, einem Token eines Dienstleisters oder einer stabilen Münze (gebunden an die Fiat-Währung) erheben? Andere Optionen als stabile Münzen sind für den Verbraucher natürlich aufgrund der Volatilität unpraktisch, und stabile Münzen im Rahmen von EOS gibt es noch nicht. Zu diesem Zeitpunkt war noch nicht einmal das Haupt-EOS-Netzwerk vorhanden! Der Einfachheit halber nahmen sie ein bedingtes Zeichen.

2. Codierung

Zunächst haben wir die API und den Rahmen des Lieferantenvertrags festgelegt, um gleichzeitig mit der Entwicklung des Frontends, des Gerätecodes, der Abrechnung und des Hauptvertrags ( Quelle ) zu beginnen.

2.1. IoT

Der erste, der einen Code zum Lesen von Impulsen von einem Zähler implementiert. Für die Arbeit mit GPIO (Allzweck-Pins) wurde die Onoff-JS-Bibliothek verwendet. Später wurden der Schaltung aus Gründen der Übersichtlichkeit zwei LEDs hinzugefügt: Die erste blinkte, wenn ein Signal vom Zähler empfangen wurde, und die zweite, wenn eine Antwort auf eine erfolgreiche Transaktion vom EOS-Knoten kam. In ähnlicher Weise haben wir ein Schema und einen Code zum Lesen von RFID-Tags entwickelt, mit dem einzigen Unterschied: Das Lesen erfolgte auf dem SPI-Bus unter Verwendung der MFRC522-Python-Bibliothek. Wie sich herausstellte, unterscheidet sich die SPI-Einstellung für den Raspberry Pi 3 von der Einstellung in früheren Board-Modellen. Diese Anweisung half uns zu verstehen.

Die Geräte wurden von der Power Bank gespeist, die allen Hackathon-Teilnehmern erfolgreich präsentiert wurde, und sie mussten das Internet selbst mit dem iPhone 5 teilen, da das WLAN des Hackathons ausschließlich mit 5 GHz funktionierte, funktionierte dies beim Raspberry Pi nicht.

2.2. Infrastruktur und Dienstprogramme

Die Organisatoren rieten, das Docker-Bild von eos-dev aufzunehmen , aber wir waren verwirrt über die fehlende Beschreibung und Dokumentation des Bildes. Auf dem Server arbeiteten sie weiterhin mit der vorbereiteten Assembly und verwendeten lokal eos-dev, um eine systematische Installation von EOS zu vermeiden.

Sofort dringend benötigt die Fähigkeit, schnell zu bauen und zu testen. Ideal: Erstellen und Ausführen einer lokal ausführbaren Datei. Es war jedoch nicht zu übersehen, dass für die Ausgabe nach der Assembly WebAssembly und in der EOS-Umgebung mit dem entsprechenden Boost Bibliotheken und Systemverträge erforderlich waren. Die notwendigen Kompilierungsoptionen könnten in eosiocpp.in ausspioniert werden. Wir haben uns jedoch entschieden, dieses Spiel nicht zu spielen. Das vorhergesagte Ergebnis ist zwar etwas langsamer, aber wichtiger als eine schnelle Lösung mit einem potenziellen Rechen. Daher haben wir für die Montage eoscpp genommen, das sich im eos-dev-Container befindet.

Es stellte sich heraus, dass es mit dem Start schwieriger wurde, ich musste die lokale EOS-Blockchain erhöhen, und wieder gab es keine vorgefertigte Lösung. Nur Software. So erschien die erste Version der Startinfrastruktur. Die Idee ist, die Nuancen der Montage und Konfiguration zu verbergen und einen selbstkonsistenten Satz von vier bis fünf "Tasten" für typische Aktionen zu erhalten. Weniger Kontrolle, aber weniger Fehlerwahrscheinlichkeit und Zeitersparnis.

Zu den Hauptkomponenten von EOS gehören die Nodeos, Keosd Daemons, das Cleos Console-Dienstprogramm und der Eoscpp-Compiler:

nodeos - EOS node, Daemon - Netzwerkteilnehmer, bietet Zugriff auf die Blockchain und erzeugt optional neue Blöcke;
keosd - ein Daemon zum Verwalten lokaler Brieftaschen, in denen Schlüsselpaare gespeichert sind;
cleos bietet Befehle vom Abrufen von Informationen über Transaktionen bis zum Arbeiten mit Schlüsseln. Es wird basierend auf Aufrufen in nodeos und keosd über die HTTP-API implementiert.
eoscpp kompiliert Verträge in WebAssembly und ermöglicht es Ihnen, die binäre Anwendungsschnittstelle basierend auf dem Quellcode abzurufen.

Es wurde sofort klar, dass Cleos-Befehle im Zusammenhang mit Keosd-Aufrufen nicht funktionierten. Da ein Fehler ausgegeben wurde, der auf die Unzugänglichkeit des Keosd-Netzwerks hinweist, haben wir Zeit damit verbracht, Netzwerkprobleme im Docker-Netzwerk zu diagnostizieren. Strace zeigte jedoch, dass es sich nicht um das Netzwerk handelte: Cleos hat immer auf localhost auf die falsche Adresse zugegriffen (und im Fall unserer Infrastruktur haben verschiedene Daemons unterschiedliche Netzwerkadressen in einem separaten Docker-Netzwerk). In cleos wurde ein Fehler diagnostiziert: Bei der Überprüfung der Verfügbarkeit von Keosd, die vor einem Befehl für Brieftaschen ausgeführt wird, wird der in den Argumenten übergebene Port berücksichtigt, die Adresse jedoch nicht. Im Rahmen des Hackathons haben wir als Workaround auf das Host-Netzwerk in Docker umgestellt .

Der nächste Schritt war das Dienstprogramm zur Vertragskompilierung mit dem Compiler im Container ( Commit ). Eingabe- und Ausgabeverzeichnisse wurden bereitgestellt. Und schließlich die Möglichkeit, einen Vertrag in die Blockchain hochzuladen und Transaktionen zu senden ( Commit ). Wieder - Dienstprogramme in einem einheitlichen Stil, einfache "Schaltflächen". Damit war die Basisinfrastruktur beendet, aber die Überraschungen gingen weiter: Wir stießen auf das Problem der C-Funktionen für die Arbeit mit dem Speicher (ausführlicher unten).

Abschließend haben sie begonnen, Konten in einer Datei einzurichten (jeder Vertrag und jeder Teilnehmer benötigt separate Konten), zusammen mit Schlüsselpaaren, die beim Start der Blockchain automatisch erstellt werden, damit ein Team die Testumgebung erhöhen kann. Eine Kopie dieser Umgebung wurde auf eos-hackathon.smartz.io bereitgestellt.

2.3. Intelligente Verträge

2.3.1. Lieferantenvertrag und Stromabrechnung

Nach dem Start des Hackathons haben wir begonnen, die Vertragsstruktur gemäß dem obigen Schema festzulegen. Das System bestand aus folgenden Verträgen:

supplier - supplier ;
billing_electricity - ein Vertrag zur Berechnung der billing_electricity für jeden Tick des billing_electricity .

Im supplier wird der größte Teil der Arbeit von normalen CRUD-Vorgängen ausgeführt: Hinzufügen von Benutzern, Tarifen, Zählern, Erhöhen oder Verringern des Benutzersaldos. Komplexere Methoden waren dafür verantwortlich, Daten vom Zähler zu empfangen, einen Vertrag zur Berechnung einer Zahlung (Abrechnung) aufzurufen und das persönliche Konto eines Benutzers nach einem Rückruf von einem Abrechnungsvertrag zu belasten. Der erforderliche Abrechnungsvertrag wurde anhand des Tarifs des Benutzers festgelegt.

Nach dem Aufruf im Abrechnungsvertrag wurde die Zahlung berechnet und die Methode zum Abbuchen der Zahlung vom persönlichen Konto des Benutzers aufgerufen. Nachdem wir die Hauptlogik geworfen hatten, dachten wir sogar, wir würden zu einfache Verträge abschließen. Wenig später, nach der Bereitstellung der Verträge im Knoten und deren Tests, wurde klar, dass die Verträge zwar einfach sind, aber es gibt Nuancen. :) :)

Nach der Bereitstellung stellte sich heraus, dass die erwarteten Vertragsaufrufe voneinander nicht funktionierten. Nicht genug Rechte. Im Gegensatz zu intelligenten Verträgen in Ethereum, bei denen ein Vertrag aus einem Vertrag im Namen des aufrufenden Vertrags abgerufen wird, beginnt in EOS die gesamte Kette mit dem Initiator der Transaktion. Wenn ein Vertrag aus einem Vertrag aufgerufen wird, wird geprüft, ob der Initiator dem Vertrag dies erlaubt hat.

Mentoren schlugen sofort vor, wie man in einem einfachen Fall handeln sollte. Rechte werden wie folgt hinzugefügt (über den Smart Contract von eosio system):

 ./cleos push action eosio updateauth '{"account":"electricity","permission":"active","parent":"owner","auth":{"keys":[{"key":"EOS7oPdzdvbHcJ4k9iZaDuG4Foh9YsjQffTGniLP28FC8fbpCDgr5","weight":1}],"threshold":1,"accounts":[{"permission":{"actor":"supplier","permission":"eosio.code"},"weight":1}],"waits":[]}}' -p electricity

In diesem Fall ermöglicht das electricity dem supplier , andere Verträge in seinem Namen zu kündigen. Weitere Informationen zu Rechten finden Sie in Technical WP EOS . In unserem Land verursachte der supplier den billing , der wiederum erneut als supplier . Das analoge Hinzufügen von Rechten in dieser Form hat nicht funktioniert:

 ./cleos push action eosio updateauth '{"account":"electricity","permission":"active","parent":"owner","auth":{"keys":[{"key":"EOS7oPdzdvbHcJ4k9iZaDuG4Foh9YsjQffTGniLP28FC8fbpCDgr5","weight":1}],"threshold":1,"accounts":[{"permission":{"actor":"supplier","permission":"eosio.code"},"weight":1},{"permission":{"actor":"billelectro","permission":"eosio.code"},"weight":1}],"waits":[]}}' -p electricity

Es wurde ein Fehler ausgegeben: Ungültige Berechtigung. Hier konnten uns die Mentoren nicht mehr helfen: Sie sagten, dass sie dies selbst nicht getan hätten. Und wer hat das getan? Vielleicht nur Dan Larimer. Wir konnten die Fehlerursache im EOS-Code nicht schnell finden und haben bereits begonnen, alternative Optionen ohne eine Kette von Aufrufen in Betracht zu ziehen. Es hat wunderbar verhindert, dass sich der Mechanismus zum Aufrufen anderer Verträge in EOS auch vom Äther unterscheidet. Wenn ein anderer Vertrag angerufen wird, wird dieser Anruf in die Warteschlange gestellt und erst abgeschlossen, nachdem der aktuelle Anruf abgeschlossen wurde. Es funktioniert nicht, den Vertrag anzurufen und nach dem Anruf die von diesem Vertrag aufgezeichneten Daten zu lesen.

Schließlich fanden sie später im EOS-Code den Grund für den Fehler beim Festlegen der Rechte für zwei Verträge. Es stellt sich heraus, dass die Konten in der Liste der Rechte nach Konto sortiert werden sollten: Stellt sicher, dass alle Schlüssel eindeutig und sortiert sind und alle Kontoberechtigungen eindeutig und sortiert sind ( Authority.hpp ). Nachdem die Reihenfolge der Konten geändert wurde, funktionierte die Aktualisierung der Rechte - und unser Vertragssystem begann zu funktionieren.

2.3.2. Das Problem der C-Funktionen mit dem Speicher

Es ist lächerlich zu sagen, aber am Ende konnten wir die vorgefertigten Funktionen nicht zum Parsen von Zahlen (!) Verwenden, um die Abrechnungskonfiguration zu lesen. Nach std::istringstream Funktion std::istringstream , was ziemlich seltsam ist. Und bei der Verwendung von atof und dergleichen sowie sscanf - env.realloc verschärft. Aus irgendeinem Grund wurden die genannten Funktionen zum Arbeiten mit dem Speicher der Standard-C-Bibliothek beim Laden des Codes in Nodeos nicht gefunden. Die C ++ - Funktionen, die mit dem Speicher arbeiten, funktionierten.

Bei der Ausführung des WebAssembly-Vertrags wird natürlich kein Standardspeicherzuweiser verwendet, sondern eine eigene Sandbox, die unter bestimmten Bedingungen für jede Transaktion bereitgestellt wird. Auch die Unterstützung für C-Funktionen beim Arbeiten mit Speicher über dieser Sandbox ist seit langem implementiert. Ihre Implementierung erfolgt in Standard-EOS-Verträgen . Wahrscheinlich ist in der Verbindungsphase etwas schief gelaufen.

Nachdem wir ungefähr eine Stunde lang nach einem Ausweg gesucht hatten, auch mit Hilfe eines der Mentoren, beschlossen wir, nicht fortzufahren und eine Problemumgehung vorzunehmen: Schreiben Sie unseren eigenen Code, der das Problem des Parsens von Zahlen löst. Der Datenstrom-EOS-Mechanismus passte nicht zu uns: Er erforderte die Fähigkeit, Datenpakete verschiedener Strukturen in einem Feld zu speichern und von Hand zu bilden (genau die Abrechnungskonfigurationen).

2.3.3. Einkaufsabrechnung

Im zweiten Wind, der entweder von den Energieingenieuren oder vom frühen Frühstück geöffnet wurde, schrieben sie die Abrechnung für den Einkauf im Laden. Das allgemeine Arbeitsschema lautet wie folgt:

Der Lieferant erstellt einen Abrechnungsvertrag und schreibt ihn in seinem Generalvertrag vor.
Am Outlet des Geschäfts richtet der Lieferant Frameworks ein, die RFID lesen, mit EOS interagieren und ihre eigenen Konten im Abrechnungsvertrag vorschreiben können.
Jedes Produkt im Geschäft ist mit einem RFID-Tag ausgestattet, alle Tags sind im Abrechnungsvertrag eingetragen.
Der Käufer bezahlt die Ware durch Scannen seiner RFID und die Ware wird aus dem Abrechnungsvertrag entfernt.
Beim Verlassen des Geschäfts lesen die Rahmen zusätzlich RFID-Einkäufe. Wenn sich die Waren noch im Geschäft befinden, wird die Transaktion nicht bestanden und der Rahmen sollte den Alarm auslösen (ja, Sie können die Transaktion nicht einmal senden, sondern nur die Tabelle lesen).

Es macht keinen Sinn, sich mit dem Vertragscode selbst zu befassen: Dies ist Standard C ++ 14 mit einigen EOS-spezifischen Konstrukten und Bibliotheken. Besser gesagt im EOSIO Wiki und im EOSIO Developer Portal .

2.3.4. Frontend

Der Frontend-Teil des Projekts wurde mit React implementiert. Anstelle der üblichen vielen entschieden sich Redux für MobX, was die Entwicklung erheblich beschleunigt und es Ihnen ermöglicht, den globalen Status ohne Kopfschmerzen zu verwalten.

Die Integrationsphase der Front-Blockchain verlief nicht so reibungslos wie erwartet. Das eosjs- Paket wird sehr aktiv finalisiert, gefolgt von der EOS-Brieftasche für den Scatter- Browser. In diesem Haufen verursacht dies oft Probleme. Und nicht die Tatsache, dass der Code, der gestern funktioniert hat, heute gut funktioniert. Wir sind auf diesen Rechen getreten (und nicht das erste Mal). Eine Stunde Versuch und Debugging in einem schläfrigen Zustand - das Problem ist gelöst.

Betrachten Sie ein vereinfachtes Diagramm der Interaktion der Client-Seite der Anwendung mit eos. Dazu benötigen Sie die eosjs-Bibliothek und die Scatter-Browser-Erweiterung.

Wir erinnern Sie daran! Scatter wird nach eosjs aktiv aktualisiert. Vergessen Sie nicht, die Bibliothek zu aktualisieren.

Als nächstes ein kurzer Blick auf Lesen und Schreiben. Es gibt zwei Möglichkeiten, mit intelligenten Verträgen in EOS zu kommunizieren: Senden von Transaktionen (dadurch wird die Blockchain geändert, ohne dass Rückgabewerte angegeben werden) und Lesen von Tabellen (schreibgeschützte Aktion).

Betrachten Sie den Transaktionssendecode:

  sendTransaction(funcName, data) { return this.scatter .suggestNetwork(this.network) .then(() => this.scatter.getIdentity({ accounts: [this.network] })) .then((identity) => { let accountName = this.getAccountName(identity); // wrap eos instance const eos = this.scatter.eos(this.network, Eos, this.configEosInstance); return eos.transaction(accountName, (contract) => { contract[funcName](data, { authorization: accountName }); }); }); }

Eingabeargumente: Funktionsname und Objekt, seine Werte sind Argumente dieser Funktion. Dritte Zeile: Wir bestätigen das Netzwerk, über das wir mit EOS interagieren. Vierte Zeile: Wir erhalten identity , der Parameter ist ein Objekt mit dem accounts (für dieses Netzwerk). Die Funktion getAccountName gibt das erste Konto aus der empfangenen getAccountName (im identity ) zurück.

In diesem Beispiel wird Scatter zum Signieren einer Transaktion verwendet. Scatter ist ein Wrapper über eine Instanz der Eos Klasse. In Zeile 9 rufen wir die eos Methode mit ihren Parametern auf:

this.network - ein Objekt mit Netzwerkparametern.
Eos ist eine Instanz von eosjs.
this.configEosInstance - Ein Objekt mit Parametern für eine Eos-Instanz (siehe Dock-EOSJS).

Die letzte transaction akzeptiert accountName und callback als Eingabe. Das callback ist ein Vertrag, der sich im accountName . In callback 'e rufen wir die Methode des empfangenen Vertrags mit dem Objekt auf, seine Schlüssel sind die Argumente der aufgerufenen Methode.

Betrachten Sie die Methode zum Lesen von Tabellen:

  readTable(data) { this.eos = this.scatter.eos(this.network, Eos, this.configEosInstance); return this.eos.getTableRows({ json: true, limit: 1, ...data, }); }

Hier brauchen wir zum Lesen nur eine eos Instanz.

Um die Benutzeroberfläche zu entwerfen, haben wir Materialise, Semantic und Ant entfernt und selbst Stile entwickelt. In den letzten Stunden des Hackathons schien eine Idee die Benutzeroberfläche wiederzubeleben und eine Visualisierung des Prozesses hinzuzufügen. Markierte die neuen Zeilen der Tabelle für zwei Sekunden in Grün und erhielt einen coolen Effekt a la Stock Quotes. Die Verbesserung erhöhte die Attraktivität des Projekts erheblich und wurde zur letzten Phase des Aufbaus der Benutzeroberfläche.

3. Montage

Drei Stunden vor Ablauf der Zeit hatten wir einen Raspberry Pi mit dem Mercury-Stromzähler und einem daran angeschlossenen RFID-Lesegerät sowie eine Lichtanzeige. Der gesamte Tischstrom ging durch den Merkur. Für jede ausgegebenen 0,3125 Wh / h sowie für jeden „Kauf“ schickte Raspberry Pi Transaktionen an unsere Blockchain, und der Dienstanbieter konnte Benutzer, Sensoren, Abrechnungen verwalten und Verbrauchsstatistiken anzeigen.

Für eine weitere Stunde beschäftigten wir uns ruhig mit Kontrollen und fügten den letzten Schliff hinzu. Zwei Stunden vor Ablauf der Zeit haben wir ein vollständiges Produkt mit zwei implementierten Fällen erhalten, das das Konzept vollständig veranschaulicht und in den letzten Minuten sogar keine Commits enthält!

4. Demonstration

Demonstrationen von Projekten (auch bekannt als Stellplätze) bestanden aus zwei Phasen. In der ersten Phase wurden 69 teilnehmende Teams in vier Gruppen eingeteilt, von denen jede vor zwei Richtern und ohne Zuschauer getrennt gefüttert wurde. Die Richter gaben Noten (vier Kriterien mit jeweils 5 Punkten) und basierend auf diesen Noten wurden die Top 10 Teams für die zweite Stufe ausgewählt. Diese Teams hatten die Möglichkeit, ein Projekt auf einer großen Bühne vor dem Publikum und allen acht Richtern zu inszenieren.

Wir sind in der ersten Gruppe gelandet. Unsere Richter waren der CEO und Präsident (ich frage mich, wie sich diese Positionen unterscheiden) von Everipedia. Für die Aufführung wurden drei Minuten eingeplant, die vom Timer streng überwacht wurden. Wir beendeten unsere Inkonsistenz, forderten jedoch auf, die Rede 30 Sekunden vor dem Zeitplan zu beeindrucken. Die Richter fragten oberflächlich und ziemlich kurz etwas, und die Demonstration war beendet.

Wir, naive, waren überrascht, dass wir nicht auf die tatsächliche Arbeitsfähigkeit des Produkts und noch mehr auf den Kodex des Richters geachtet haben. Technische Umsetzungsprobleme interessierten sie nicht im geringsten. Wir könnten genauso gut die blinkenden Raspberry Pi-Lampen und das Bild auf der Vorderseite zeigen.

Wir hatten das Gefühl, dass wir bei der Präsentation des Projekts gescheitert sind, weil wir erwartet hatten, mit einer tatsächlichen Lösung, einem Prototyp und nicht nur einer farbenfrohen Beschreibung eines sozial bedeutenden und ehrgeizigen Projekts zu beeindrucken. Alles wurde wie durch Notizen gespielt: Wir haben das Problem, den Schmerz und unsere Lösung beschrieben, gezeigt, wie es funktioniert, und die Entwicklungspläne des Projekts beschrieben. Wenn wir im Voraus über die Bewertungsmethoden Bescheid gewusst hätten, hätten wir viel anders gemacht.

Die Richter aus den vier Streams der ersten Runde reduzierten ihre Punktzahlen und tauschten 15 Minuten nach Ende der Spielfelder ihre Ansichten aus. Nach der Bekanntgabe der Gewinner begann. In der Halle herrschte eine nervöse Atmosphäre: Nach dem 26-Stunden-Marathon müde, wollten die Leute gewinnen, es gab viele starke Teams und sie wussten, dass sie den Sieg erringen konnten. Und das wussten wir - und warteten auf die Ergebnisse.

Um zu verhindern, dass sich die Zuschauer entspannen, wurden die Ergebnisse in drei Teilen bekannt gegeben. Die ersten vier Finalisten, dann noch drei, dann noch drei. Zwischen Ankündigungen und am Ende - Aufführungen. Wir sind nicht in die Top 10 gekommen und hatten keine Gelegenheit, die große Bühne zu betreten. Zwei russischsprachige Teams schafften es in die Top Ten, von denen eines schließlich das dritte wurde. Herzlichen Glückwunsch an die Gewinner, sie haben ihre Preise verdient.

5. Schlussfolgerung und Pläne

AngelHack . , . — , , . , , , — .

26 IoT- EOS. , .

— UI ( — -- Smartz ), . - , blockchain-ready , , — . :) :)

, , «», «» . . 5 . , 100 , . SensorPay !

Yuvasee (entrepreneur)
algs (hardware & backend developer)
therealal (architect, backend developer, devops)
bolbu (frontend developer)
quantum (blockchain & backend developer)

Wie wir IoT-Zahlungen bei einem Hackathon in Hongkong gesehen haben