@Fabric Foundation Wenn Sie jemals einen Lagerroboter beobachtet haben, der spät in der Abendschicht arbeitet, fühlt es sich fast routinemäßig an. Die Maschine rollt einen Gang entlang, hebt einen Container, lässt ihn anderswo fallen, und das System notiert leise, dass die Arbeit beendet ist. Eine Zeile erscheint in einer Datenbank. Der Bestand wird angepasst. Niemand denkt viel darüber nach.
Innerhalb eines einzelnen Unternehmens ist dieser Datensatz normalerweise ausreichend.
Die gleiche Organisation besitzt den Roboter, die Software, die ihn steuert, und die Datenbank, die protokolliert, was passiert ist. Wenn später ein Fehler auftritt, greifen Ingenieure auf die Systemhistorie zu. Sie scrollen durch Zeitstempel, einfache Marker, die zeigen, wann jede Aktion stattfand, und versuchen, die Reihenfolge zu rekonstruieren. Die Annahme ist ziemlich einfach: der Datensatz ist vertrauenswürdig, weil das Unternehmen das System kontrolliert, das ihn erstellt hat.
Die Dinge beginnen ein wenig ins Wanken zu geraten, sobald Roboter diese geschlossenen Umgebungen verlassen.
Stellen Sie sich eine Liefermaschine vor, die eine Sendung in einem Lager abholt, sie in eine Logistikkette überträgt, die von einem anderen Unternehmen betrieben wird, und schließlich während der Route mit der kommunalen Infrastruktur interagiert. Der Roboter produziert die ganze Zeit Informationen. Standortverläufe. Aufgabenbestätigungen. Sensordaten, die Hindernisse oder Routenänderungen beschreiben.
Aber die meisten dieser Aufzeichnungen befinden sich in privaten Datenbanken, die demjenigen gehören, der die Maschine in diesem Moment betreibt. Jeder Teilnehmer behält seine eigene Version der Ereignisse.
Zunächst klingt das machbar. Unternehmen tauschen ständig Berichte aus. Doch die Reibung tritt auf, sobald die Verantwortung eine Grenze überschreitet. Ein System behauptet, der Roboter habe einen Schritt abgeschlossen. Ein anderes System ist auf diese Behauptung angewiesen, bevor es die Zahlung freigibt oder die nächste Aktion auslöst.
Plötzlich wird die Frage etwas unangenehm.
Wie kann jemand überprüfen, was die Maschine tatsächlich getan hat?
Hier tritt ungefähr das Denken hinter dem Fabric-Protokoll in das Gespräch ein. Nicht als Roboterbauer, sondern mehr als Infrastruktur um Roboter, sobald sie in gemeinsamen Umgebungen zu arbeiten beginnen.
Fabric schlägt vor, ein öffentliches Hauptbuch zu verwenden, um robotische Aktionen zu koordinieren. Ein Hauptbuch ist in einfachen Worten ein gemeinsames Protokoll von Ereignissen. In blockchainbasierten Systemen ist dieses Protokoll über viele Computer verteilt und durch Zeitstempel und kryptografische Beweise miteinander verknüpft, was es schwierig macht, vergangene Einträge zu ändern, ohne dass es alle bemerken.
Für die Robotik ist die Implikation ziemlich praktisch. Wenn eine Maschine eine Aufgabe abschließt, kann das Ereignis in einem Protokoll festgehalten werden, das mehrere Parteien einsehen können. Anstatt einer einzelnen Datenbank eines Betreibers zu vertrauen, können die Teilnehmer auf eine gemeinsame Geschichte dessen zurückgreifen, was passiert ist.
Fabric beschreibt dies oft durch die Idee des verifizierbaren Rechnens. Der Ausdruck klingt technisch, obwohl die Bedeutung ziemlich bodenständig ist. Er bezieht sich auf Systeme, die demonstrieren können, dass eine Berechnung oder Aktion tatsächlich stattgefunden hat - nicht nur berichten, dass sie es getan hat.
Das ist wichtig, wenn Maschinen mit Menschen oder Institutionen interagieren, die nicht über dieselben internen Systeme verfügen.
Der Umfang des Problems ist auch nicht mehr besonders klein. Der Internationale Verband der Robotik schätzt, dass weltweit etwa 3,9 Millionen Industrieroboter derzeit aktiv sind, hauptsächlich in der Fertigung, aber zunehmend auch in Logistik- und Dienstleistungsumgebungen. Wenn diese Maschinen beginnen, organisatorische Grenzen zu überschreiten, wird die Koordinierungsebene um sie herum schwerer zu ignorieren.
Die Architektur von Fabric versucht, sich direkt mit dieser Ebene auseinanderzusetzen. Daten von Maschinen gelangen in das Netzwerk. Berechnungen helfen zu validieren, was geschehen ist. Governance-Mechanismen ermöglichen es verschiedenen Interessengruppen - Entwicklern, Betreibern, manchmal Regulierungsbehörden - mit demselben Protokoll von Maschinenaktivitäten zu interagieren.
Das Hauptbuch beginnt in diesem Sinne, sich eher wie ein gemeinsamer Speicher als wie eine Finanzinfrastruktur zu verhalten.
Stellen Sie sich einen Inspektionsroboter vor, der Abschnitte der öffentlichen Infrastruktur scannt. Seine Berichte könnten Wartungspläne oder Sicherheitsentscheidungen beeinflussen. Wenn diese Berichte an verifizierbare Berechnungen gebunden sind, die in einem Hauptbuch aufgezeichnet sind, ändert sich das Gespräch leicht. Anstatt sich vollständig auf denjenigen zu verlassen, der den Roboter eingesetzt hat, können andere überprüfen, wie das Ergebnis erzeugt wurde und wann.
Nichts davon beseitigt die Komplexität. Verteilte Verifizierung verlangsamt die Dinge im Vergleich zu privaten Systemen. Die Koordination zwischen vielen Akteuren führt zu eigenen Fehlerquellen. Selbst Transparenz schafft Designspannungen darüber, welche Informationen sichtbar bleiben sollten und welche nicht.
Dennoch fühlt sich der zugrunde liegende Wandel spürbar an.
Roboter bewegen sich allmählich in Umgebungen, in denen viele Organisationen und viele Menschen von denselben Maschinen abhängen. Wenn das passiert, trägt Intelligenz allein nicht mehr die ganze Last. Die umgebende Infrastruktur zur Aufzeichnung, Überprüfung und zum Verständnis von Maschinenaktionen wird ebenso wichtig.
#ROBO $ROBO
