Diese slides wurden auf dem Ethereum Central German MeetUp bei Etecture während der ://webweek rhein-main 2018 vorgestellt. Es geht um verschiedene Ansätze zur Entwicklung von Blockchain-Lösungen aus Beratersicht.
https://www.meetup.com/de-DE/Ethereum-MeetUp-Central-Germany/events/250409205/
2. 2
Agiles Service Design zur Abbildung von Logistikprozessen auf der Blockchain
Vorstellung Wer wird sind und was wir tun
Problemstellung/
Lösungsansatz
Was wir mit der Blockchain machen
Herausforderungen Was wir gern diskutieren würden
1
2
3
6. 6
Als führender Anbieter von Software für
die Automobillogistik machen wir bisherige
Papierprozesse zum digitalen Erlebnis!
2009
Gegründet
13
Mitarbeiter
3.2 Mio
Fahrzeugbewegungen
900
Lizenzierte Unternehmen
8.400
LKW
>10.000
Anwender
11. Zu betrachtender Prozess
• Ablauf
• Beladung
• Transport
• Entladung
• Dokumentation
• Frachtpapiere (eCMR)
• Zustand/Schäden
• Besitzübergang (Zeit, Ort)
• Infrastrukturen
• Dokumentenverwaltung
• Warenwirtschaftssysteme
11
Problemstellung
Fahrzeuge werden von A nach B gebracht.
Dabei sollen in Zukunft digitale Frachtpapiere zum
Einsatz kommen. Diese gilt es sicher abzulegen.
12. Angestrebter Prozess
12
Lösungsansatz
• Telematik System
• Frachtpapiere werden digital Erzeugt: Vom
Fahrer beim Aufladen, vorbereitet vom
Disponent.
• App sendet Daten an den zentralen
Datenspeicher-Server
• Server erstellt daraus das gewünschtes
Endformat: PDF, E-Mail etc.
13. • Alles bleibt wies ist!
(Freut sich jeder Admin)
• Bestehende API:
• Von den Dokumenten werden bereits
Prüfsummen erstellt.
• Neue API:
• Sendet NUR DEN FINGERPRINT des
Dokumentes an die Blockchain.
• Fingerprint wird mit einer VIN Verknüpft
• Prüfung der Blockchain:
• Ist das Dokument bereits vorhanden.
• Es darf zu keinen Zeitpunkt ein Hashwert
zweimal abgelegt werden
(Fehler/Kollisionsresistenz)
• Speicherung mehrerer Dokumente an
einer VIN
• Prüfung ob eine VIN am Dateninput
angehängt ist.
• Ausgeben der Hashwerte und der
Verknüpften VIN
• ÄNDERN/UPDATE soll nicht möglich sein.
Einmal drinne, immer drinne!
13
Erweiterter Prozess
Lösungsansatz
15. struct shippingDoc {
// hash of document
string docHash;
// timestamp storage (hashvalue)
uint dateOfStore;
// timestamp external creation
uint dateOfCreation;
}
struct VinDocument {
shippingDoc[] shippingDocs;
}
//vin => Documents[]
mapping (string => VinDocument) vins;
//hash => vin
mapping (string => string) checkHash;
• Oha: Warum denn den Hashvalue zweimal
speichern? (shippingDocs, map)
• Zu beginn:
teurer, da mehr Speicher benötigt wird.
• Praxistest:
ab ca. 20 Hashwerten/VIN ist billiger:
• Grund: Mit Maps können Prüfungen
effizient und schnell durchgeführt werden!
• Ohne doppelte Speicherung: Schleife
notwendig: Jede Speicherung wird teurer!
15
Smart Contract: Keep It Simple
Lösungsansatz
16. • Ethereum Basis:
• Smart Contract, ca. 150 Zeilen Code bisher
• 3 Parteien, ½ Dutzend Knoten
• ETECTURE, Mosolf, LAWA Solutions
• Private Blockchain
• PoA-Konsens
• 10 Sekunden Blockerstellung
• UI:
• API: Entgegennehmen von JSON Paketen
• Web-Frontend: Auslesen von Hashwerten,
Hochladen von Dokumenten, Prüfung ist das
da schon drinnen?
• Platform Thinking
• einfache Anbindung/Integration von
Partnern, Aufnahme neuer Knoten
• IoT Gedanke
• Transportfahrzeuge als Knoten?
• Digitale Transformation
• Paradigmenwechsel
• Distributed statt Zentral
16
Blockchain Specs
Lösungsansatz
17. Was hat man nun davon?
• Start Small
• Sichere Prüfungen, dass kein Frachtbrief doppelt vorhanden ist.
• Prüfung eines Dokumentes gegen die Blockchain: Wurde das Dokument nachträglich geändert?
• Scale Fast
• Dokumentation von Zustand, Schäden und Laufleistung eines Fahrzeuges
• Beleg und Beweisbarkeit für den Besitzübergang eines Fahrzeugs
• ThinkBig:
• Beweisumkehr: Mosolf muss nicht mehr nachweisen, dass ein Schaden bereits bestand
• Versicherung: Automatisierte Schadensmeldung und Schadensabwicklung
17
Lösungsansatz
19. • Iteratives vorgehen
• Doch besser Cadillac statt MVP?
• Value driven Development
• Who‘s value are we talking?
• Release early, release often?!
• Fail early, fail often, fail forward?
• Is failure no longer an option?
19
Agil trotz mit Blockchain?
Herausforderungen
BusinessValue
Budget
Agile is not SCRUM, agile is real teamwork
between customer & contractor; transparency
creates controllability, self-organized development
teams & short time to market
20. Architektur
• Tragfähige Datenstrukturen
• Was ist die richtige Strategie um Aufwand, Ausfallsicherheit und Geschwindigkeit mit einem Produkt wachsen zu
lassen?
• Anforderungen jetzt vs. Anforderungen später
• Komplexitätsabgrenzung: Was gehört in die Blockchain? SmartContracts vs. clientseitige Verarbeitung
• Thin-Clients?
• Welche Rolle können Thin-Clients und Dumb-Devices einnehmen?
• Müssen Thin-Clients die Blockchain mitschreiben?
• Automation
• Wie und wann können und sollten manuelle Prozesse zu SmartContracts werden?
• Distributed Travelling Ledger
• Mobile Synchronisation (Deutschland steht in Mobilfunk auf Platz 38 Weltweit)
• Nicht immer online?
• Offline-Funktionalitäten ausbauen?
20
Herausforderungen
21. Rechtlicher Rahmen
• VIN als personenbezogenes Datum?
• Dokumentation vs. Datenschutz
• Fingerprints als Weg zur EU-DSGVO Kompatibilität?
• Weltweiter Warenverkehr
• eCMR in Deutschland nur für innerdeutschen Transport zugelassen
• Formvorschriften
• Ist die BC eine qualifizierte digitale Signatur nach eIDAS-Verordnung
• Willenserklärung
• Ist eine Ausführung eines SmartContracts einer eindeutigen Willenserklärung gleichzusetzen
• Gestaltungsrechten bei Verträgen
• Keine Möglichkeit Anpassungen vorzunehmen, kein interpretationsspielraum
21
Herausforderungen
22. Vielen Dank für Ihre
Aufmerksamkeit_
Steve Stein
Informationsarchitekt
Steve.Stein@etecture.de
Telefon +49 721 570458-27
ETECTURE GmbH
Bachstraße 43
76185 Karlsruhe
http://www.etecture.de
Nils Bott
Software Developer
Nils.Bott@etecture.de
ETECTURE GmbH
Bachstraße 43
76185 Karlsruhe
http://www.etecture.de