Blockchain krempelt das Records Management um

26.05.2017

Bisher dachte man beim Begriff Blockchain immer an digitale Währungen, neue Geschäftsmodelle für Banken und Versicherungen. Aber Blockchain verändert auch andere traditionelle Anwendungsfelder - so zum Beispiel das Records Management.

Die "Blockkette" ist ein Verfahren, in dem kontinuierlich gemachte Einträge durch kryptografische Enkodierung der verketteter Einträge die Verfälschbarkeit ausschließen. In der Regel benutzt man eine Datenbank, deren Sicherung gegen Manipulation (Integrität, Authentizität) durch Speicherung des Hashwertes des vorangehenden Datensatzes im jeweils nachfolgenden durch kryptographische Verkettung gesichert ist. Ähnliche Prinzipien kennen wir bereits aus kaufmännischen Systemen, wo eine Buchung nicht einfach gelöscht werden kann. Hier muss im Journal ein neuer Eintrag gemacht, der alte als ungültig gekennzeichnet und vom neuen Datensatz referenziert werden.

Daher ist der Schritt in die gleichermaßen abzusichernde revisionssichere Archivierung naheliegend. Records Management und revisionssichere Archivierung betreffen auch vorrangig kaufmännische, handels- und steuerrechtliche Vorgaben, wo es um Verfälschungssicherheit und Nachweisfähigkeit geht.

Was man jedoch bedenken muss ist, es geht hier um eine spezielle Lösung für die Datenbank, also bei einer traditionellen Referenz-Datenbank-Architektur eines revisionssicheren Archives um die Metadaten und Verwaltungsdaten. Die Objekte (Belege, Dokumente etc.) werden ja in einem separaten Speicher referenziert. Dieser ist aber nicht durch Blockchain abgesichert. Lediglich wenn man die Dokumente auch direkt als BLObs Binary Large Objects in der Datenbank mitspeichern würde, ergäbe sich das gleiche Schutzprinzip. Das würde aber die Nutzung durch die großen Datenmengen entscheidend verlangsamen. Allerdings ist für die revisionssichere Archivierung dieser Schritt eigentlich nicht notwendig, weil die Informationsobjekte im WORM-Verfahren unveränderbar gespeichert werden und zu dem die Daten der Informationsobjekte wie Hash, Größe, Datum, Titel etc. ebenfalls in Eingangs-Protokollen verzeichnet wird, die ihrerseits auch revisionssicher archiviert werden. natürlich kann man aber auch bei den Audit-Trails das Blockchain-Prinzip zur Absicherung einsetzen. Der Einsatz von Blockchain wäre aber genaugenommen nur auf die Index- und Verwaltungsdatenbank zu beschränken und macht dort auch Sinn. Über die Indexdatenbank wird das Wiederfinden und der Zugriff auf die sicher archivierten Objekte umgesetzt. Veränderungen hier würden zwar nicht zu Veränderungen bei den revisionssicher archivierten Objekten führen, aber man würde durch Manipulation gegebenenfalls andere oder keine Dokumente finden. Durch Blockchain lässt sich also die Verwaltung der archivierten Objekte zusätzlich absichern. Aber man muss auch noch andere Records-Management-Prinzipien in Betracht ziehen - das Löschen von Informationen. Hier wird bisher unterschieden zwischen "logischem Löschen" des Eintrags, der auf das separat gespeicherte Dokument verweist, und das "physische Löschen", bei dem sowohl der Eintrag in der Indexdatenbank als auch das gespeicherte Objekt gelöscht werden. Dies funktioniert so mit Blockchain nicht.

Der Ansatz Blockchain für Records Management zu nutzen und generell Records Management zu automatisieren kommt wie vieles aus den USA. Dort geht es im Records Management vorrangig um die Verwaltung von Daten mit Datenbanken. Der zu nutzende Speicher, also z.B. ein sicheres WORM-Verfahren, ist eine nachgeordnete "Baustelle". Bei reinen Records-Management-Anwendungen wird sich ebenso wie bei Fibu-, ERP-, Bank- und anderen Anwendungen der Blockchain-Ansatz sinnvoll einsetzen lassen. Für Konzepte wie die revisionssichere Archivierung wird aber eine generelle Frage zu lösen sein: welche Zukunft hat die Referenz-Datenbank-Architektur? Werden hier BLOb-Datenbanken, Hadoop-Speicher, Cloud-Architekturen und andere Entwicklungen das traditionelle, liebgewonnene Konzept grundsätzlich in Frage stellen? Immerhin beschäftigen sich auch professionelle Archivdienstleistungsanbieter wie Iron Mountain damit und nicht nur Berater und Analysten wie Alan Pelz-Sharpe (Deep Analysis) und Steve Weissman (Holly Group). In den USA ist das Thema brandheiß.

Ach ja, ähnliche Ideen für einen anderen Anwendungszweck hatten wir in Deutschland schon mit den Verfahren zum Nachsignieren der Zertifikate von elektronischen Signaturen mittels Hash-Bäumen. Und das könnte auch jemanden auf die Idee bringen, man lässt das Ganze mit Signaturen und Nachsignieren und macht hier einfach auch auf Blockchain.

Ulrich Kampffmeyer

Kommentare

Gespeichert von Gregor Joeris (nicht überprüft) am/um 1. Juni 2017 - 18:35 Permanenter Link

Die Blockchain soll ja nun mal wieder alles revloutionieren, auch "Information Governance" oder "Records Management".
Als ITler denke ich da eher an "The Hype is a Cycle" [http://geek-and-poke.com/geekandpoke/2016/12/12/hype-cycle]
ich kann diese Euphorie inhaltlich leider nicht nachvollziehen, ganz im Gegenteil.

Im Ernst: Wenn man die Grundlagen der Blockchain-Technologie betrachtet, wie sie aus der Originalquelle [https://bitcoin.org/bitcoin.pdf] hervorgehen (deren Lektüre bei diesem Thema zu empfehlen ist), dann kann ich nur sehr wenig Potenzial für diese Technologie rund um "Information Governance" oder "Records Management" erkennen.

Das revolutionäre an Blockchain ist zunächst die Vermeidung einer zentralen Instanz. Bei der wichtigsten Anwendung von Blockchain – Bitcoin – werden Finanztransaktionen ohne eine zentrale Bank abgewickelt. Die Blockchain ist ein "Distributed Ledger", der zudem noch vollständig öffentlich ist. Dies ist die zweite wichtige Eigenschaft. Da dies natürlich ein Problem ist, sind sie z.B. bei Bitcoin komplett anonym (die Blockchain verwendet Signaturen; die verwendeten Zertifikate sind dann wieder anonymisiert, eigentlich ein schlechter Scherz).

Um ohne zentrale Instanz Transaktionen sicher abzuwickeln, bedarf ist zudem einer Lösung des Double-Spending Problems. Die Validierung der Transaktion erfolgt durch ein sog. "Proof-Of-Work". Die Beteiligten Knoten des Blockchain-Netzes "kämpfen" darum, als erste einen Block zu validieren (wodurch im Übrigen die neuen Bitcoins geschürft werden). Da dies sehr aufwendig ist, werden immer viele Transaktionen in einem Block zusammengefasst. Schließlich ist die Chain eine Chain, eine sequentielle Kette. Skalierung erreicht man damit nicht. Die Validierung einer Transaktion ist also langsam und die Technologie by-design nicht skalierungsfähig. Und etwas aus der Kette löschen bricht die Kette auch, wie im Artikel schon erwähnt wurde.

Zusammengefasst: Wir haben es also mit einer nicht-skalierbaren, langsamen, oft Einzelobjektebene nicht-transaktionalen Technologie zu tun deren Daten entweder komplett öffentlich sind (Datenschutz? Unternehmensgeheimnisse?) oder daher ggf. noch komplett anonym sind. Und damit möchte man nun "Information Governance" oder "Records Management" abbilden?

Wie geht Nachvollziehbarkeit bei Anonymität?
Wie geht Datenschutz bei öffentlichen Daten? Und ohne Löschmöglichkeit?
Wann bekommt man die Bestätigung, dass ein Dokument erfolgreich archiviert wurde?

Und vor allem: wo ist hier überhaupt der UseCase, auf eine zentrale Instanz verzichten zu müssen? Es ist ja nicht so, dass man seine aufbewahrungspflichtigen Dokumente heutzutage zu einem zentralen ArchivCenter bringen muss. Vielmehr steht doch jedes Unternehmen für sich in der Pflicht, die Dokumente selbst aufzubewahren. Es gibt hier weder den Bedarf, eine zentrale Instanz aus der Transaktionskette zu entfernen noch den Bedarf, ein "Distributed Ledger " nutzen zu wollen (abgesehen davon, dass man es in diesem Kontext wohl auch nicht so einfach darf). Der Austausch aufbewahrungspflichtiger Dokumente läuft heute und seit je her immer schon zwischen zwei Parteien und jeder bewahrt seine Dokumente auf. Die Echtheit kann man mit digitalen Signaturen schon ewig absichern, wenn denn überhaupt gewünscht.

Stopp, halt. Eine zentrale Instanz gibt es noch. Den Staat. U.a. als zentrale Stelle von Geburts- und Heiratsurkunden usw. Super, diese zentrale Instanz könnten wir natürlich ausbooten. Heiraten ohne Staat, das wird ein Erfolgsmodell…

Lassen wir das brandheiße Thema mal in Ruhe abkühlen.

Entspannte Grüße,
Gregor Joeris

Nur ein paar klärende Argumente zur Erläuterung meines Ursprungsbeitrages und um Gregor Joeris' Kritik aufzugreifen:

Die Grundkonzepte der Blockchain funktionieren nicht für Records Management:

  • verteilt und öffentlich
    passen nicht in eher zentrale Inhouse-IT-Konzepte
  • sequentielle Absicherung
    wird bei größeren Datenmengen ineffektiv und langsam
  • Anonymität der Einträge
    widerspricht Verantwortlichkeit, Nachvollziehbarkeit und Prüfbarkeit
  • keine Möglichkeit zum Löschen
    widerspricht dem Grundprinzip des Records Management in Bezug auf die Entsorgung veralteter, ungültiger und falscher Information

Besonders das Thema Datenschutz, DSGVo, wird noch einige Hürden für die Blockchain aufbauen. Und von der Stromrechnung einmal ganz zu schweigen ... 

Zwei Trends verändern aktuell das Records Management: Blockchain und Automatisierung.

Während Unternehmen wie Deep Analysis (Alan Pelze-Sharp), Holly Group (Steve Weissman), Inacta (Jens Beba), Iron Mountain und zahlreiche andere den Einsatz von Blockchain beim Records Management promoten, sieht SER Solutions (Gregor Joeris) dies in seinem Beitrag in unserem Blog kritisch. Auch wir bei PROJECT CONSULT reagieren eher zurückhaltend auf dieses Einsatzfeld von Blockchain. 

Den Trend der Automatisierung im Records Management beflügelt Künstliche Intelligenz (KI). Bereits im Sommer 2014 hatten wir Anwendungsfelder der Automatisierung im Records Management beschrieben (Records Management und Automation) und das Thema in einem virtuellen Roundtable der Competence-Site zur Diskussion gestellt (Automatisierung als Zukunft des Records Management?). In unserem Artikel findet sich bereits damals eine lange Liste von Funktionen, die automatisiert werden.

Records Management & Automatisierung (2014): Anwendungsbereiche

Durch die rasch voranschreitenden Entwicklungen bei Bigdata Analytics und Artificial Intelligence (AI) hat sich der Trend nun beschleunigt. Gerade beim Aufbau von Ordnungssystematiken, bei der Erfassung von neuen Records (Records Declaration), bei intelligenter Vererbung von Ordnungskritierien und anderen Metadaten. und beim Erschließen der Inhalte sind Fortschritte zu verzeichnen. Besonders der aufwändige und fehlerträchtige Flaschenhals der manuellen Erfassung von Records und ihrer Metadaten kann überwunden werden. In verschiedenen Vorträgen, zuletzt im Juni 2017, und Artikeln sind wir auf die möglichen Einsatzfelder von KI Künstlicher Intelligenz im Information Management eingegangen.

Folie 89 - Keynote "ECM - und was kommt danach?" Lobonet http://bit.ly/lobonet_DrUKff    

Die Automatisierung im Records Management schreitet schneller voran und ist wichtiger als der rein technologische Ansatz von Blockchain. Künstliche Intelligenz, Analyse-Verfahren und Automatisierung entlasten direkt den Endanwender. Sie unterstützen nicht nur herkömmliche Verfahren und Ansätze des Records Management sondern bringen neue Funktionalität und Nutzungsmodelle in die angestaubte Branche, die sich auf die Verwaltung von klassischen Dokumenten mittels ihrer Metadaten konzentrierte. Voluminöse Konzepte der Vergangenheit, die besonders das Records Management in der öffentlichen Verwaltung und regulierten Branchen betreffen, werden obsolet. Bereiten wir uns auf eine Revolution der Schriftgutverwaltung vor! Auch die systematische Behinderung von effizienten Methoden zur Verwaltung, Erschließung und Nutzung elektronischer Records im Public Sector wird zu einem Ende kommen.

So wie man Blockchain im ECM Umfeld kritisch betrachten sollte, sehe ich das auch bezüglich KI.
KI-Funktionalität wird noch stärker als heute im Dokumenteingang und Klassifizierung die Aufgabe der Massenbelegverarbeitung übernehmen und mit zunehmender Leistungsfähigkeit in weitere und komplexere Szenarien vordringen, z. B. Vertragsmanagement u. ä und in den heute noch manuellen Aufgaben mindestens qualifizierte Vorarbeit leisten.
Wenn man die Arbeitskräfte-Entwicklung sich anschaut ein nahezu notwendiger Schritt.
Ich denke KI wird ähnlich ECM in früheren Jahren überschätzt und z. T. überzeichnet - schließlich kann man an einem Hype gut verdienen und die Karten der Anbieter können ggf. neu gemischt werden.

Deswegen Augen auf wenn jemand vorschwärmt - er könnte dafür entsprechendes Eigeninteresse haben, ebenso wie derjenige der neue Themen in Bausch und Bogen ablehnt.

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Während bei uns im Blog Joeris von SER wie auch wir (siehe oben) den Einsatz von Blockchain-Technologien für Records Management eher "zurückhaltend" sehen, ist Beba von inacta durchweg positiv eingestimmt, was den Einsatz von Blockchain im Informationmanagement angeht. In unserem Jubiläums-Newsletter-Kompendium (http://bit.ly/PCJub25NL) hat er den Beitrag "Anwendungsmöglichkeiten von Blockchain-Technologie im Information Management" veröffentlicht: http://bit.ly/PCjub25Beba . Die kritischen Stimmen weisen auf Anforderungen der GDPR/DS-GVO und Architektur-Probleme hin, die den Einsatz für klassisches Records Management stark einschränken.

in unserem August-Newsletter (der quasi Band 2 unseres Jubiläum-Newsletters vom Juni ist) hat Sanooj Kutty (Mannai Trading Co., Qatar) ein aktuelles Beispiel für den Einsatz von Blockchain beim Records Management geliefert "Know your Expat - A case for Blockchain based Records Keeping in Qatar" (Seite 32ff, http://bit.ly/PCNLAug2017, PROJECT CONSULT Newsletter 04/2017, August 2017). In dem Workflow geht es um Beantragung und Genehmigung von Aufenthaltsgenehmigungen für Qatar.

 

Inzwischen gibt es auch in Deutschland die ersten Projekte, bei denen Blockchain-Techniken für die elektronische Archivierung eingesetzt werden. Bei der Metro geht es hier um Massendaten aus Kassen, die dem KassenG unterliegen: http://bit.ly/MetroBlockchain. Naturgemäß geht es eigentlich nicht um "Archivierung" sondern um "Aufbewahrung" entsprechend den Vorschriften von HGB, AO und GoBD. Im Anwendungsfall geht es nicht um dokumentorientierte Speicherung sondern um strukturierte Datensätze.

Bei Massendaten aus Tausenden von Kassen greifen bisherige Archivierungskonzepte nicht. Diese basieren auf einer Indexdatenbank, die auf einzelne Objekte in einem separaten Speicher verweist. Perfomance- wie auch Mengengründe stellen dieses Konzept aber bei Massendaten in Frage. Jeder einzelne Index in der Datenbank hätte z.B. die gleiche Größe wie der aufzubewahrende Datensatz des Kassenbons. Das Eintragen und Prüfen der Indexinformation und das Wegschreiben der Archivobjekte ist bei großen strukturierten Datenmengen nicht performant genug. Die Nutzung von WORM-Verfahren im Speicher führt zu zusätzlichen Größen- und Performance-Problemen. Die vorgesehene Lösung erlaubt darüber hinaus die Auswertbarkeit der Daten mit Analytics-Werkzeugen.

Es handelt sich bei der geplanten Lösung aber nicht um eine "klassische" Blockchain, wie sie z.B. bei virtuellen Währungen zum Einsatz kommt. In den öffentlichen, verteilten Systemen mit Mining-Funktionalität kommen viel aufwändigere Verfahren als in einer Inhouse-Lösung, wo Datensätze, mit Prüfsummen versehen, verknüpft werden und in sequentieller Abfolge gegengesichert werden. Natürlich müssen in dieser auf Open-Source- und Bigdata-Werkzeugen basierenden individuellen Lösung eine Reihe von Problemen berücksichtigt werden. Hierzu gehört z.B. die Bildung von Zeitscheiben, um Informationen nach den Aufbewahrungsfristen löschen zu können, Verknüpfungen zu Laufzeitsystemen z.B. mit den zugehörigen Daten aus Materialwirtschafts- und Logistik-Programmen sowie die Behandlung personenbezogener Daten nach DSGVo in den Kassenbelegen. 

Ob durch solche Lösungen die bisherigen Konzepte der revisionssicheren Archivierung mit Referenzdatenbank und separatem Repository in Frage gestellt werden, ist wenig wahrscheinlich. Wie auch das Records Management benötigt die effiziente Verwaltung und Erschließung von Information mehr als nur Analytics und verfälschungssichere Speicherung. Anders als eine Blockchain ermöglicht Records Management und revisionssichere Archivierung auch das gezielte, nachvollziehbare und dokumentierte Löschen - etwas, was es in einer verketteten Blockchain per Definitionem nicht geben kann.

Die Lösung von Deepshore und Metro soll zukünftig der Open-Source-Community zur Verfügung gestellt werden.

Es gibt nicht die EINE Art der Blockchain sondern verschiedene. Die meisten Menschen gehen immer von der Distributed Ledger Blockchain mit verteiltem Proof-of-Work aus, wie z.B. virtuellen "Währungen" (BITCOIN und Co.) zu Grunde liegt. Dabei bedeutet Blockchain in erster Linie eine besondere Art der Verkettung. Wikipedia sagt zu Blockchain:

"Eine Blockchain (auch Block Chain, englisch für Blockkette) ist eine kontinuierlich erweiterbare Liste von Datensätzen, genannt „Blöcke“, welche mittels kryptografischer Verfahren miteinander verkettet sind. Jeder Block enthält dabei typischerweise einen kryptografisch sicheren Hash (Streuwert) des vorhergehenden Blocks, einen Zeritstempel und Transaktionsdaten".

Es geht hier eher um das Modell "Auditing", Wikipedia schreibt hierzu (Ergänzungen im Beitrag im September 2018): 

"Beim Auditing in der Informationstechnik geht es darum, sicherheitskritische Operationen von Softwareprozessen aufzuzeichnen. Dies betrifft insbesondere den Zugriff auf und die Veränderung von vertraulichen oder kritischen Informationen. Das Auditing eignet sich hierbei deshalb für eine Blockchain, weil es relativ geringe Datenmengen produziert und gleichzeitig hohe Sicherheitsanforderungen aufweist. Eine Blockchain kann hierbei das Audit-Log (auch als Audit-Trail bezeichnet) vor Veränderung schützen. Zudem sollten die einzelnen Einträge mit einer digitalen Signatur versehen werden, um die Echtheit zu gewährleisten. Ein dezentraler Konsensmechanismus, wie bei Bitcoin, wird nicht zwingend benötigt."

Gehen wir einen Schritt weiter: Verkettung plus Audit-Trail zur zusätzlichen Absicherung. Für Records-Management- und Archivsysteme, die Inhouse oder in einer eigenen private Cloud laufen, lassen sich so andere Blockchain-Architekturen aufbauen, die nicht wie die Internet-Währungen funktionieren. Sie sichern sich durch die Verkettung sowie zusätzlich durch einen Audit-Trail, der ebenfalls als Blockchain aufgebaut ist. So etwas kann man dann als "Block Chain mit Blockchain" nennen. Zur einfacheren Unterscheidung benutzen wir für die nur verketteten Blöcke den Begriff Block Chain in zwei Worten. 

Die Bildung von Prüfsummen mit Hash und deren Anhängen an Informationsobjekte gibt es schon sehr lange in der elektronischen Archivierung (z.B. im SIZ-Konzept für die Archivierung in der Sparkassen-Finanzgruppe). Hieraus lässt sich einfach der nächste schritt der Verkettung generieren. Dies alles wird in einem Audit-Trail protokolliert, in dem die Operationen mit den Transaktionsdaten, dem Zeitstempel und anderen Attributen kontinuierlich aufgezeichnet werden. Die Informationsobjekte (oder Dokumente) liegen vereinzelt vor und sind nicht Bestandteil des Audit-Trails selbst.  Wie das Eintragen eines neuen Blocks kann nun auch das Austragen eines Blockes geschehen. Hierfür müssen aber zusätzlich noch ID, Hashwert und Transaktionsdaten des dem zu löschenden Block vorausgehenden und folgenden eingetragen werden. Erfolgt das Lesen der Retrieval-Information vom Jüngsten zum Ältesten wird zunächst die "Block-Löschungs-Information" gefunden. Die Audit-Trail-Daten inkl. den dort mitgespeicherten Metadaten stehen aber weiterhin zur Verfügung und sorgen für Nachvollziehbarkeit. Das Thema der Absicherung über Zeitstempel lässt sich entsprechend eIDAS auch mit zertifizierten Zeitstempeln als Fernsignaturen erreichen, die als qualifizierte Signaturen einen noch höheren Nachweiswert haben. Alternativ kann auch in verteilten Organisationen oder Verbünden über Master-Nodes nachgedacht werden.

Blockchain-Lösungen à la Bitcoin sind weiterhin für Archivierung und Records Management nicht geeignet.

Das Verfahren der Verknüpfung von Blöcken nebst Audit-Trail haben wir schon in mehreren Beiträgen angesprochen und auch in der Abschluss-keynote auf der EUROFACTURA-Tagung in Bielefeld am 10.10.2018 dargestellt - http://bit.ly/EuroFactura18-Keynote - dort Folie 68 bis 82.  Mehr dazu gibt es auf unserem Update Information Management 2019: http://bit.ly/updateIM19news

 

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Almost all of the current archiving and RM systems are based on databases. To change the architecture to Blockchain is a very major change. Most suppliers will be reluctant to go that way.

Of course, aspects of Blockchain are useful for archiving. Of course, auditing and auditing are important, and if that's inherent in architecture, that's very good.

But the distributed characteristics of Blockchain are mostly not needed. And is RM really transaction-oriented? My clients are also having this discussion: How do we use Blockchain if we do not want to use everything from Blockchain? Is Blockchain worth it? Difficult question. I have not found an answer yet.

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Lieber Herr Schwalm,

auf Twitter (http://bit.ly/SchwalmDSGVO) haben Sie geschrieben "Solange Blockchain die Compliance zur DSGVO nicht ermöglicht ist Beweiswerterhaltung ein Thema von vielen" und dies als Antwort auf unseren Beitrag http://bit.ly/PC-Blockchain gepostet. In der folgenden Diskussion haben Sie eine Reihe von Fragen und Entgegnungen zu unseren Kommentaren gepostet, die nur schwer auf Twitter zu beantworten sind. Zu einigen grundsätzlichen Aspekten Ihrer Einwürfe rund um DSGVO und Blockchain möchte ich daher hier bei uns im Blog Stellung nehmen.

Wir sind uns, glaube ich, einig, dass es nicht die EINE Blockchain-Technologie gibt. Wir sprechen hier nicht über die public Blockchain, wie sie bei "Währungs"-Anwendungen wie Bitcoin zum Einsatz kommt. Dass das öffentliche Verfahren für Records Management und Archivierung - ebenso wie für die Erfüllung der Anforderungen der GDPR nicht geeignet ist, habe ich eingangs zu diesem Blog geschrieben. Wir sprechen über interne "private" Anwendungen für Unternehmen und Unternehmensverbünde. Hierbei kommen einfachere Verfahren zum Einsatz, die keinen externen "Proof-of-Work" oder die aufwändige Generierung von "Coins" benötigen. Hier sind aktuell zwei Typen zu sehen: der Audit-Trail als Blockchain und die Speicherung von Massen-Transaktionen als Blockchain. Beim erwähnten Anwendungsfall von Deepshore bei der Metro handelt es sich um den letzteren. 

In unseren Ausführungen geht um die Kombination zweier Ansätze: eine eher klassische Blockchain für den Audit-Trail als Nachweis der Transaktionen, Unverändertheit usw. sowie die Nutzung von verketten Blöcken, sprich Informationsobjekten (oder Dokumenten). Klassische Blockchain-Anwendungen bevorzugen strukturierte, möglichst gleichförmige Daten oder gleich aufgebaute Datensätze. Dokumente, unterschiedlich in Art, Größe und Format, sind dafür eher ungeeignet. Zumindest werden Informationsobjekte benötigt. Ein solches Informationsobjekt setzt sich aus Header, dem eigentlichen Inhalt (Content) und einem Trailer zusammen. Im Header hat man einen Unique Identifier mit Zeitstempel, der jedes Objekt identifiziert sowie weitere Metadaten, im Trailer zum Beispiel eine Prüfsumme mit Hash-Wert über das Informationsobjekt. Solche Objekte wurden z.B. bereits Anfang der 90er Jahre in Standards wie ISO 10166 und z.B. im "SIZ-Grundindex" für die Archivierung in der Sparkassen-Finanzgruppe oder im "CCSDS OAIS" der Weltraumbehörden umgesetzt. Natürlich gab es damals noch nicht den Begriff der Blockchain. Eine Verknüpfung von Referenzobjekten wie z.B. das Schreiben des Unique Identifiers zusammen mit der Prüfsumme in den Header des Folgeobjektes, den Audititrail oder eines Referenzobjektes, war möglich. Warum wurde aber dieses relativ aufwändige Softwareverfahren, dass auch kontrolliertes Ändern, Löschen und Referenzieren von Versionen und Renditionen erlaubt, bei der elektronischen Archivierung nicht implementiert? Ganz einfach - man vertraute damals Anfang der 90er Jahre mehr den verfälschungssicheren digitalen optischen Speichern wie optischen Platten und optischen Bändern. Dies machte damals einen zusätzlichen Schutz durch Verkettung unnötig, da dieser auf nur einmal beschreibbaren WORM-Medien Schwierigkeiten nach sich zieht. Die aktuelle Diskussion um Blockchain bei Records Management und elektronischer Archivierung greift so Verfahren und Funktionen auf, die es längst gibt.

In unserem Vorschlag der Kombination von Block Chain - verketteten Informationsobjekten - mit der Blockchain - als zusätzlich kontinuierlich durch Hashwert-Bildung abgesichertem Protokoll (Audittrail) - wird es möglich, Informationsobjekte konsistent sowohl logisch als auch physisch aus der Block Chain zu entfernen. Das Entfernen entspricht dem Ersetzen oder Ändern unrichtiger Information ebenso wie dem Löschen nicht mehr benötigter oder unzulässiger Information. Im unveränderbaren, kontinuierlich weiter geschriebenen Audittrail werden zusätzlich zu eigentlichen Transaktion der Typ der Transaktion, die notwendigen Daten des Vorgängers in der Kette und des Nachfolgers in der Kette mit gespeichert, so dass die Lücke über das Protokoll nachvollziehbar geschlossen wird. Das Protokoll gibt außerdem den Nachweis, welches Objekt mit welchem Inhalt entfernt wurde. Dies entspricht auch den Prinzipien des Records Management, dass nicht geändert oder gelöscht wird ohne einen Nachweis. Um Fehler und Inkonsistenzen bereits programmtechnisch schneller als das Durchsuchen der Audittrail-Blockchain zu ermöglichen, empfiehlt sich ein gesichertes Extra-Protokoll oder eine Tabelle mit den Änderungen und Löschungen zu führen. Ein solches Änderungs- und Löschprotokoll gehörte bereits zu den Prinzipien der revisionssicheren Archivierung Mitte der 90er Jahre. Stößt man beim Arbeiten mit Dokumenten (Informationsobjekten) auf ein entferntes Objekt, so wird dieser Fehler zunächst performant gegen das Löschprotokoll/Löschtabelle (und andere Fehler-Tabellen) geprüft und eine entsprechende Information ausgegeben. Ob Informationsobjekte nun logisch oder physisch gelöscht werden (müssen) obliegt dem Inhalt und dem Anwendungsfall. Ältere Archivsysteme haben nur Dokumente direkt gespeichert und sind daher - leider - nicht in der Lage den Informationsobjekt-basierten Ansatz der Kombination von Blockchain mit Block Chain umzusetzen. Hier sind die Anbieter zu kurz gesprungen. 

Sie werfen die Frage der Metadaten in Bezug auf die personenbezogenen Daten auf: Welche Daten sind wo? Wir haben hier drei relevante Komponenten: den Content des Informationsobjektes selbst, die Metadaten im Header und Metadaten im Audit-Trail (und natürlich bei herkömmlichen Systemen in der Index-Datenbank). Der Inhalt eines Informationsobjektes beinhaltet natürlich alle personenbezogenen Daten, in die ursprünglichen Datei - sei es Scan, ein PDF, eine Liste, eine E-Mail - ursprünglich enthalten waren und die natürlich unverändert nachvollziehbar gespeichert werden. Die Metadaten im Header sind grundlegende Informationen, die zu Identifizierung, Verwaltung und Schutz benötigt werden. Hier kann kontrolliert werden, dass keine Daten, die unter die DSGVO fallen, enthalten sind. Im Audit-Trail sind dann auch nur solche Daten enthalten, die die Identifikation und Nachvollziehbarkeit sowie die Unverändertheit durch Hashwerte der Objekte und Hashwerte der Transaktionen, auch bei Bedarf mit qualifiziertem Zeitstempel nach eIDAS, enthalten. Ihre eine Frage bezieht sich auf die möglicherweise in der unveränderbaren Blockchain enthaltenen personenbezogenen Daten. Auch hier gibt es bereits seit den Frühzeiten der revisionssicheren Archivierung aus den 90er Jahren entsprechende Konzepte. Bekannt und weitverbreitet ist das Prinzip der Dokumentenklasse, bei der Attributwerte auf das zugeordnete Objekt vererbt werden in dem die ID der Dokumentenklasse als Metadatum mitgespeichert wird (aber nicht die Attribute und ihre Inhalte; die liegen in der Verwaltung des Records-Management- oder Archivsystems). Das gleiche Prinzip gibt es auch für "neutrale Benutzerklassen". Diese entsprechen Rollen, die langfristig stabil sind und auch nach Jahrzehnten noch den Zugriff auf gespeicherte Informationen erlauben. Im Konzept der 90er Jahre stand bereits im Vordergrund, dass keine personenbezogenen Daten ausgewertet werden können. So das BDSG schon damals. Daher wurde in den Metadaten nur eine ID für den Benutzer und seine Benutzerklasse (inkl. Ort und Zugriffsweg für die Daten in einem externen Verzeichnis) für die Berechtigung mitgespeichert. Dies geschah in der Indexdatenbank, in objektorientierten Systemen auch in den Metadaten des Informationsobjektes. Wenn man nun einen Anwender, der ein Objekt generiert und zur Speicherung übergeben hat, ermitteln wollte, musste man mit dem Datum des Objektes, der ID und der Benutzerklasse in ein separates Berechtigungssystem wechseln, um ermitteln zu können, welcher Benutzer zu welcher ID zu diesem Zeitpunkt gehörte. Die personenbezogenen Daten der eigenen Anwender waren so im Archivsystem selbst nicht direkt erschließbar (es sei denn, man benutzte das Berechtigungssystem des Archivsystems extensiv und hatte keine Integration mit einem separaten Directory Service). So wurden zumindest personenbezogene Daten in Metadaten, Protokollen und Indexdatenbank der eigenen User vermieden. Die User waren nur außerhalb des Archivsystems ermittelbar und so hat man das Problem der personenbezogenen User in langzeitig ausgelegten Archivsystemen umgangen. Ähnlich kann man dies nur auch mit Namen, Adressen usw. von Kunden, Interessenten, Partner etc. machen.direkt personenbezogen sind und sich nicht durch die Geschäftsbeziehung mit Funktionsträgern in Firmen ergeben. Hier werden auch nur die IDs der Personen aus dem Ursprungssystem zusammen mit den Informationen, wie man im Ursprungssystem an die jeweilige Person herankommt, gespeichert. So ist auch hier die personenbezogene Information aus dem Speicherbereich des langzeitig ausgelegten Archivsystems entfernt. Zugriffe und Nachvollziehen der Benutzung personenbezogener Daten liegt so in den Anwendungen, in denen sie entstanden und empfangen wurden. Dies erleichtert auch den Nachweis einer Anfrage, wo welche Informationen zu einer Person gespeichert ist. Im Idealfall eines gut organisierten Archiv- oder Records-Management-System sind die Daten sauber getrennt sowie in den Metadaten beim Informationsobjekt und im Audittrail sind keine personenbezogene Daten enthalten, die direkt auswertbar oder innerhalb des Systems direkt auffindbar sind. DI referenzierten Systeme (oder Tabellen) mit den personenbezogenen Daten benötigen natürlich auch eine Historisierungsfunktion um die Identifizierbarkeit und Nachvollziehbarkeit über längere Zeiträume sicherzustellen. Aber solche Anforderungen und Lösungen gab es schon bei der revisionssicheren Archivierung in den 90er Jahren - ganz ohne Blockchain und auch ohne Block Chain.

Wie eingangs der Diskussion schon einmal erwähnt - es ist immer eine Frage, wie professionell die Verwaltung von Information organisiert ist. Es ist schon gut, wenn man überhaupt weiß, welche Information man wo hat. Dass die Systeme selbst Informationslandkarten und Verfahrensdokumentationen erstellen ist einer meiner langgehegten Wunschträume. Und nun kommt da die DSGVO/GDPR mit all ihren Anpassungsgesetzen und Schlenkern. Ehrlich gesagt, personenbezogene Daten sind nahezu in jedem Schriftstück, in jeder E-Mail, in jedem Datensatz - halt überall. Die DSGVO ist daher beim besten Willen überhaupt nicht vollständig zu erfüllen. Hier muss man auch Risiko-Bewertung betreiben, was man in welchem Umfang nun umsetzt. Daten und Dokumente in einer Blockchain + Block Chain, die entsprechend Geschäftszweck, den Vorgaben von HGB, AO, GoBD, Zoll usw. aufbewahrt werden müssen, stellen da in Bezug auf die personenbezogenen Daten nach DSGVO das geringste Problem dar.

Mit den besten Grüßen,

Dr. Ulrich Kampffmeyer

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Eine Blockchain im engeren begrifflichen Sinne einfach als hash-verkettete Liste aufzufassen, ist mir persönlich zu trivial, auch wenn dies die offizielle Wikipedia-Definition ist. Die eigentliche Blockchain-Innovation ist die verteilte Konsensfindung per "proof-of-work". Ich halte es für wesentlich sinnvoller, Krypto-Logfiles und "echte" Blockchain klar zu trennen, siehe z.B. auch den Vortrag von Felix von Leitner (FeFe) zu Hype-Themen für Banker: https://ptrace.fefe.de/hype/#0 (Blättern im Vortrag mit Pfeiltasten).

Tatsächlich sichern wir in Doxis4 unsere Audittrail-Einträge seit dem damailigen Launch der neuen Produktgeneration in 2008 mit einer Hash-Verkettung. Da stehen auch die Löscheinträge eines Informationsobjekts mit drin. Die Chain kann man zudem nicht nur linear lesen, sondern sich auch z.B. direkt alle Einträge eines Informationsobjekts abrufen, um alle Einträge zu diesem zu haben (nur die Verifikation, ob die Hashwerte noch stimmen, muss über die Chain laufen; das muss man nur bei Bedarf tun und diesen gibt es normalerweise ja gar nicht).
Damals wurde noch nicht über Blockchain geredet und trotzdem war das schon im Produkt. Das war so trivial, dass man das gleich mit gemacht hat, wenn man ein System schon neu entwirft. Wir werden uns damit aber auch weiterhin nicht im Lichte der Blockchain sonnen, dafür ist es zumindest mir wirklich zu einfach. Ein valides Verfahren zur Sicherung eines Audittrails ist es aber natürlich.

Vielleicht sollte man den Decision Tree von https://spectrum.ieee.org/computing/networks/do-you-need-a-blockchain , der beschreibt, wann man eine (echte) Blockchain braucht, noch um einen Punkt erweitern: "wenn eine hash-verkettete Liste reicht, machen sie es einfach und planen 1 PT dafür ein".

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Lieber Kollege Joeris,

schön, dass Sie bereits 2008 Block Chain in SER Produkten einsetzten (bei einzelnen unserer Kunden bereits 1995). Dass das Verknüpfen von einzelnen "Blöcken" relativ einfach ist, ist unbestritten. Wenn es dann aber um den Ansatz "Löschen" geht, schon schwieriger. 

Gegenstand meines Beitrages oben (http://bit.ly/Block__Chain) war jedoch weitergehend: die Kombination verknüpfter Blöcke (Block Chain) mit einer "echten" Blockchain, wobei aber bei Inhouse-Lösungen nicht das verteilte Prinzip mit zahllosen Beteiligten gegeben ist, sondern eher an eine Lösung mit einem Master-Node, der selbst oder per Fernsignatur mit einem qualifizierten Zeitstempel sowohl die Verknüpfung der einzelnen Blöcke wie auch die Verifkation und Absicherung der Transaktionen in der echten "Audit-Trail-Blockchain" ermöglicht. 

Erfahrungsgemäß ist eine solches sichereres Konzept, dass auch den Anforderungen des Einsatzes der qualifizierten Signatur in Deutschland gerecht wird, nicht mit einem Personentag zu erledigen. :)

Mit den besten Grüßen,
Dr. Ulrich Kampffmeyer

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Insgesamt eine sehr spannende Diskussion hier, auf die mich mein Kollege Falk Borgmann (der hier ebenfalls bereits kommentiert hat) aufmerksam gemacht hat. Ich möchte gerne nochmal Bezug auf die hier gegebene Einschätzungen nehmen, was eine Blockchain ist, und wo man den (durch Hypes tatsächlich sehr strapazierten) Begriff "Blockchain" richtig verwendet. Im Prinzip ist es natürlich richtig, dass die kryptografische Verkettung der Datensätze ein elementarer Bestandteil von Blockchain-Artigen Technologien ist. Es ist aber auch richtig, dass diese Art der Verkettung auch bereits in der Pre-Blockchain Phase existierte und ggf. sinnvoll eingesetzt werden konnte (wie die Verwendung von SER ja auch zeigt). Jedoch sonnt man sich damit aus meiner Sicht zu Recht nicht im "Lichte der Blockchain", da hier ein elementarer Punkt, nämlich der Aspekt des verteilten Systems, keine Berücksichtigung findet. Und genau dieser ermöglicht eben, dass etablierte Verfahren technisch anders umgesetzt werden können.
Ich selber arbeite seit über 15 Jahren im Bereich der DMS/ECM/EIM/CS Systeme (oder was auch immer gerade die aktuelle Definition gerade ist) und es galt technisch im Bereich der Beweiswerterhaltung und Löschbarkeit häufig das Prinzip: Es ist sicher, weil es in einem abgeschotteten, monolithischen System liegt, welches eben genau nicht offen und transparent ist, sondern den Zugriff auf die Daten (insebsondere das Löschen und Verändern) mittels singulärer Autorität unterbindet. Mit diesem Prinzip der abgeschotteten Appliance verdienen insbesondere auch Storage Anbieter mittels magnetic WORM signifikant Geld - durchaus zurecht, denn Sie lösen damit ein Problem hinsichtlich der Vertrauenswürdigkeit. Daten können selbst durch den obersten Admin im Unternehmen nicht mehr unbemerkt gelöscht oder verändert werden, da der "Schlüssel" dafür nur dem Hersteller bekannt ist. Ein durchaus praktikabler Ansatz, bei dem man sich aber eben komplett vom Hersteller und dessen Mechanismen (und dies kann auch eine Hashkette als ergänzendes Feature sein) abhängig macht.
Und genau hier schaffen die Mechanismen aus der Blockchain-Technologie eine Alternative, wo der monolithische "Single Point of Truth" gegen ein mehrheitliches Konsensverfahren getauscht wird. Genau das ist der Kern der Technologie, der es ermöglicht Vertrauen zu generieren, sofern eine gewisse Heterogenität und "Seperation of Power" gegeben ist. Und für die Konsensverfahren existieren eben nicht nur der durch Bitcoin bekannte "Proof of Work", sondern noch etliche weitere, die insbesondere in konsortialen oder private permissioned Blockchains hervorragend geeignet sind mittels byzantinischer Fehlertoleranz ein 4-Augen Prinzip zu unterstützen und abzusichern (Für einen Vergleich der Konsensverfahren siehe z.B. https://hackernoon.com/consensuspedia-an-encyclopedia-of-29-consensus-a…, für eine Erklärung der BFT z.B. https://deepshore.de/de/beitraege/item/26-der-byzantinische-fehler-abwe…). Und dies ist auch technisch mehr, als hashverkettete Datensätze in eine zentrale Datenbank zu schreiben.
Die technische Implementierung ist hier dennoch nicht besonders aufwändig (dies könnte man, entsprechende Infrastruktur vorausgesetzt, auch mit 1 PT realisieren). Der sehr viel aufwändigere Teil ist, wie immer, der gesamte Prozess und das Verfahren drum herum. Denn die Technologie selbst, löst kein einziges regulatorisches Problem "einfach so". Im besten Fall kann es einen entsprechenden Prozess unterstützen und in geeigneten Umgebungen dafür sorgen, dass Vertrauen auch technisch erhalten bleibt. Es befreit einen aber, wie in der Vergangenheit auch, nicht davon, den fachlichen Gesamtprozess zu planen, zu implementieren und zu dokumentieren. Ein Vorteil für die Kunden ergibt sich dann eher im laufenden Betrieb und der TCO, da sie eben nicht mehr von einer proprietären Technologie oder einem dedizierten CloudService abhängig sind, sondern Infrastrukturagnostisch agieren können.

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Hallo Herr Bruenker,

Sie sprechen das Thema "Vertrauen" an und stellen dar, dass es in einer verteilten Umgebung das Konsensverfahren Vorteile gegenüber den bisherigen monolithischen, sich direkt im Unternehmen abgeschottet befindlichen Archiv- und Records-Management-Verfahren habe.

Dagegen spricht der Charakter der Informationen in Archiv- und Records-Management-Systemen, die im Regelfall vertraulich sind, z.B. kaufmännische Daten. Auch im Sinne des aktuellen Gesetzes zum Schutz von Betriebsgeheimnissen besteht die Anforderung, die Information sicher und vertraulich zu bewahren. Eine (öffentliche) verteile Blockchain öffnet aber die Information allen Beteiligten. Daher sehe ich für herkömmliche Records-Management- und Archivierungsanwendungen eher den von mir beschriebenen internen Ansatz aus Block Chain und einer Audit-Trail-Blockchain (in der die Inhalte selbst nicht enthalten sind). Die Audit-Trail-Blockchain kann man dann durchaus dezentral und verteilt aufbauen, wenn denn keine kritischen Unternehmensdaten darin enthalten sind. 
Anders mag dies in verteilten Organisationen, Supply-Chain-Verbünden oder Filialunternehmen für bestimmte Geschäftsprozesse aussehen. Hier kann man dezentrale Lösungen a la Blockchain nutzen, jedoch ist auch hier die Lösung auf eine definierte, eingeschränkte, begrenzte und bekannte Nutzergemeinschaft beschränkt. 

Letztlich entscheidet, welche Daten für welchen Zweck wie geschützt werden sollen. Für interne Archiv- und Records-Management-Anwendungen stellt ein Ansatz mit verketten Blöcken und einer Audit-Trail-Blockchain, die durch externe Signaturen (Fernsignatur) als vertrauenswürdigem Drittem (Vertrauensdiensteanbieter nach eIDAS) eine Alternative für herkömmliche Referenzdatzenbank-Architekturen mit Index-Datenbank und separat gehaltenen Objekten dar.

Übrigens - in China werden Blockchain Records schon als Legal Evidence, also als Beweis, gesetzlich anerkannt.

Mit den besten Grüßen und Wünschen für die Festtage,
Dr. Ulrich Kampffmeyer
 

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Dem geneigten Leser sei auch dieser Artikel hier ans Herz gelegt:
https://www.cryptoglobe.com/latest/2018/12/research-study-no-evidence-o…
Ein Forscherteam hat versucht, erfolgreiche Blockchain Projekte zu eruieren. Turns out: es gibt keine. Das Ding ist wohl im "Through of Disillusionment" angekommen.

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Lieber Kollege Hartbauer,

wie ich bereits erwähnte, gibt es nicht die "eine", allein-seligmachende Blockchain. Unterschiedliche Architekturansätze, von der verketteten öffentlichen Blockchain á la Bitcoin über zentral gesteuerte Blockchains mit Master-Node bis hin zu Inhouse-Lösungen mit verketten Blöcken und/oder abgesicherten verketteten Audittrails.

Im Bereich von Archivierung und Records Management machen nur die letzteren, die Kombination von Block-Chain mit "echter" Blockchain einschließlich der Möglichkeit kontrolliert zu ändern, löschen und zu ergänzen, Sinn. Solche Lösungen kann man sogar mit einer traditionellen Index-Datenbank für die Metadaten des Records Management sinnvoll kombinieren. Die Prinzipien von Ordnung und Ordnungsmäßigkeit können so zusätzlich zur Konsistenz, Nachvollziehbarkeit und Unveränderbarkeit gewahrt werden. Diese Lösungen sind noch nicht weit verbreitet und andererseits auch wenig bekannt, da es sich um Inhouse-Lösungen eines Unternehmens oder eines Verbundes von Unternehmen oder Filialen handelt. Es kommt also auch darauf an, wonach man sucht, wenn man eine solche Bewertung wie "Keine erfolgreichen Projekte" abgibt. Selbst Anbieter aus Deutschland wie Nextevolution/Deepshore sehen das vielleicht anders.

Wir stehen bei der Entwicklung der unterschiedlichen Ansätze erst am Anfang (zusammenfassende akademische Literatur gibt es ja auch erst seit 2008 mit dem Aufkommen von Bitcoin). Blockchain wird sich weiterentwickeln. Und Block()Chain ist eine Alternative zu bisherigen Konzepten der revisionssicheren Archivierung.

Mit den besten Grüßen,
Dr. Ulrich Kampffmeyer

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Sehr geehrter Hr. Hartbauer,
über die o.g. genannte Studie sind wir auch schon gestolpert. In Teilen kann man einige Aspekte auch nachvollziehen, jedoch teilen wir als Deepshore nicht die Conclusio.
Nachvollziehen können wir den beschriebenen Eindruck, dass hinter sehr vielen "Blockchain-Basierten" Lösungen tatsächlich kein tragfähiges technisches Fundament steht. Wir haben als Deepshore dieses Jahr an sehr vielen Konferenzen und Veranstaltungen im Bereich "Distrubuted Ledger" teilgenommen und es ist wahrlich erschreckend, mit wie wenig konkret umgesetzten Use-Cases einige große, wie auch kleine Firmen sehr marktschreierisch behaupten, sie hätten ein erfolgreiches Blockchain-Projekt umgesetzt. Allzu häufig findet man hier wirklich bestenfalls Prototypen hinter den vollmundigen Versprechungen - häufig nicht mal das (Einige Unternehmen verkaufen grobe Ideen in Form eines "Whitepapers" als Produkt - Hauptsache man sagt "Blockchain"). An dieser Stelle können wir die Ergebnisse der Studie durchaus nachvollziehen. Dennoch finde ich die Aussage "0 Succesfull Blockchain Projects" mehr als nur gewagt. Wir wurden zum Beispiel nicht angefragt und hätten nur zu gerne unseren Stack und den Mehrwert von Blockchain-Technologie zur Beweiswerterhaltung von digitalen Informationen dargestellt. Hierbei ist Blockchain tatsächlich nur ein Teil der Lösung, aber er trägt eben auch einen relevanten (und monetär bewertbaren) Teil zur Lösung bei. Die METRO verarbeitet mittlerweile mit unserem Blockchain-Stack tatsächlich produktive Daten.
Die Deepshore arbeitet aber nicht am einzigen Use-Case, der bereits produktiv Nutzen generiert. Wir kennen einige andere Startups die Blockchain-Basierte Systeme praxisrelevant erfolgreich einsetzen.
Trotzdem, der Hype um Blockchain hat die Erwartungen sehr hoch geschraubt, und viele Projekte die mit dem Versprechen "Disruptive Use-Cases" zu formen an den Start gegangen sind, haben einfach ihre Versprechen nicht gehalten. Es gibt dennoch auch erfolgreiche und sinnvolle Implementierungen, die einen echten Mehrwert generieren.

MfG
Falk Borgmann

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Nun erklärt auch McKinsey, dass die Blockchain nicht so toll sei wie ursprünglich gedacht: "Blockchain’s Occam problem" (https://mck.co/2SWcFEs). Matt Higginson, Marie-Claude Nadeau und Kausik Rajgopal schreiben darin "Blockchain has yet to become the game-changer some expected. A key to finding the value is to apply the technology only when it is the simplest solution available.". McKinsey bezieht sich aber in ihrer Studie auf die Finanzwirtschaft, und nicht auf das von PROJECT CONSULT hier beschriebene Anwendungsgebiet von "Audit-Trail-Blockchain" und "Block Chain + Blockchain". Vom Niedergang diverser Crypto-Währungen und mangelnden Anwendungen für die "public-distributed-ledger-proof-of-work-blockchain" sind der Nutzen von verketteten Objekten (selbstbeschreibende Informationsobjekte, sprich Dokumente mit XML-Header und XML-Trailer) mit Blockchain-Audit-Trail-Protokollen wenig bestritten. Übrigens war McKinsey eines derjenigen Analysten-Häuser, die die Blockchain als den "Game Changer" im Finanzdienstleistungsmarkt hochgejubelt haben,

dsgvo_einverstaendnis_comment
Einverständniserklärung nach DSGVO

Neuen Kommentar schreiben

Ich stimme zu, dass die von mir eingegebenen Daten einschließlich der personenbezogenen Daten an PROJECT CONSULT übermittelt und dort zur Prüfung der Freischaltung meines Kommentars verwendet werden. Bei Veröffentlichung meines Kommentars wird mein Name, jedoch nicht meine E-Mail und meine Webseite, angezeigt. Die Anzeige des Namens ist notwendig, um eine individuelle persönliche Kommunikation zu meinem Beitrag zu ermöglichen. Anonyme oder mit falschen Angaben eingereichte Kommentare werden nicht veröffentlicht. Zu Nutzung, Speicherung und Löschung meiner Daten habe die Datenschutzerklärung zur Kenntnis genommen.

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.