Blockchain, Blockchain, Blockchain – Was taugt sie eigentlich bei der Digitalisierung des Steuerrechts?

Es scheint, als sei die Blockchain das neue goldene Kalb, das allerorten verehrt wird. Auch nur die Nennung des Hype-Begriffs zaubert ein Lächeln auf die Gesichter von Regierungen, Technikern, Juristen, Steuerberatern und – natürlich – Finanzverwaltung und Steuerpflichtigen. Nun gibt es die Idee der Blockchain bereits seit 2008 und seither immer wieder Erfolgsmeldungen über geplante und durchgeführte Pilotprojekte. Technisch sind Blockchains mittlerweile trivial; das Aufsetzen einer eigenen Blockchain (respektive Kryptowährung) kann jeder halbwegs begabte Programmierer in wenigen Stunden anhand von Open-Source-Frameworks bewerkstelligen. Sieht man aber von den „üblichen Verdächtigen“ im Bereich der Kryptowährungen ab, kommt aber der Zug irgendwie nicht über den Bahnhof hinaus. Woran liegt das?

Verteiltes Vertrauen

Um diese Frage beantworten zu können, muss man sich etwas mit den Voraussetzungen und Zwecken der Blockchain beschäftigen. Hier soll nicht das technische Konzept vorgestellt werden; die Kenntnis, wie eine Blockchain funktioniert, wird vielmehr vorausgesetzt.

Traditionell werden größere Datenmengen in einer Datenbank gespeichert. Es gibt verschiedene Datenbanktechniken, die sich im Laufe der Zeit entwickelt haben, und der Inhalt einer Datenbank kann so ziemlich alles sein, was es in Datenform gibt. Natürlich können Datenbanken auch (wachsende) Ketten von Ereignisdaten speichern, etwa von Transaktionen. Und selbstverständlich ist auch die Verknüpfung verschiedener Transaktionen oder Kontenblätter zu einem „Buch“ im Sinne der Buchhaltung („ledger“) in verschiedenen Datenbanktypen abbildbar (und wird auch seit langer Zeit in Datenbankform abgebildet, etwa in ERP-Systemen). Datenbanken können auf verschiedene Systeme verteilt und Veränderungen synchronisiert werden, sodass sämtliche Datenbanken inhaltlich identisch sind („Spiegelung“). Verteilte Datenbanken sind skalierbar, was ihre Leistungsfähigkeit (Reaktionszeit) und ihr Volumen angeht. Auch können inner- oder außerhalb der Datenbank Funktionen bzw. Ablauflogiken (Makros, Skripts, Programme) vorgehalten werden, die einmalig oder zyklisch ausgeführt werden und den Inhalt der Datenbank verändern.

Die Blockchain ist eine besondere Form der verteilten Datenbank. Ihre Idee basiert nicht darauf, dass andere verteilte Datenbanken ungeeignet wären, sich buchmäßig fortentwickelnde Sachverhalte zu speichern und zu organisieren oder „Smart Contracts“ auszuführen. Im Gegenteil: Die Performance von Blockchains im Verhältnis zu klassischen hoch performanten, verteilten Datenbanksystemen ist schlicht miserabel. Hintergrund der ursprünglichen Bitcoin-Blockchain, des „Urahnen“ der Blockchain, war vielmehr etwas ganz anderes, nämlich (im Rahmen der Suche nach einer Organisationsstruktur) die Prämisse, dass keinem Betreiber einer Datenbank getraut wird. Wer immer eine Datenbank verwaltet – ein Staat, eine Behörde, eine Bank, ein produzierendes oder Dienstleistungs-Unternehmen, eine Stiftung – kann Eigeninteressen haben und deshalb versucht sein, Inhalte zu „fälschen“, oder kann durch außenstehende Dritte „kompromittiert“ werden. Eine Kompromittierung liegt nach dieser Sichtweise auch dann vor, wenn durch Vorgaben des Gesetzgebers oder durch die Exekutive oder durch den Vollzug von Gerichtsentscheidungen ein Status der Datenbank erzwungen werden soll, der mit dem „frei gewählten“ Regelwerk nicht in Einklang steht. Die anarchistische Grundidee der Blockchain – vornehm gesprochen deren Unabhängigkeit von Gängelei und Einflussnahme – ist eine Form von Selbstjustiz in einem möglichst rechtsfreien Raum, der durch konsequente Globalisierung der Organisationsstruktur geschaffen wird, sodass insbesondere auch Eingriffe durch Träger staatlicher Gewalt vermieden werden. Die in diesem Bezugssystem erreichte „Fälschungssicherheit“ kennzeichnet damit in erster Linie die Abwehr äußerer Eingriffe in das frei postulierte Regelwerk der Blockchain selbst und dessen konsequente – von „Verfälschungen“ freie – Umsetzung.

Wenn der Inhaber von Wertgegenständen – Ausgangspunkt und Schwerpunkt der Diskussion ist ja das Thema Kryptowährungen – also keiner einzelnen Institution mehr vertrauen möchte, weil diese potenziell Eingriffen von außen sowie Interessenkollisionen ausgesetzt ist, wem kann man dann die Führung eines „Währungs- bzw. Münzenregisters“ anvertrauen? Die Antwort der Blockchain darauf lautete „distributed trust“, d. h. Vertrauen in eine Vielzahl (hoffentlich) unabhängig voneinander agierender Beteiligter in den verschiedensten Jurisdiktionen. Diese im Grundsatz gegenseitig anonymen Mitglieder eines „Vertrauensnetzwerks“ stellen Rechen- und Speicherkapazitäten bereit und betreiben so „Knoten“ einer besonderen Form einer verteilten Datenbank.

Die Blockchain-Datenbank mit stetig wachsenden Transaktions- bzw. „Buchdaten“ wird demnach idealerweise an eine – im Vergleich zu klassischen verteilten Datenbanksystemen – sehr große Anzahl von Knoten verteilt. Entscheidend ist, wer den nächsten Block verfassen, also die Datenbank „weiterschreiben“ darf und dafür eine Prämie erhält. Im „proof of work“-Fall kann die Wahrscheinlichkeit durch den Einsatz von mehr Rechenleistung erhöht werden („Mining“), im „proof of stake“-Fall kann die Wahrscheinlichkeit durch das Halten von mehr virtuellen Anteilen am Blockchain-Netzwerk erhöht werden. Der verfasste Block wird zwar von den anderen Knoten auf formale Übereinstimmung mit den festgelegten Regeln der jeweiligen Blockchain-Architektur geprüft, aber dennoch könnten (vorsätzlich oder als „Werkzeug“ eines Dritten) inhaltlich falsche Transaktionen (z. B. auf Basis entwendeter Schlüssel, mit denen Transaktionen durchgeführt werden) eingeschleust werden. Derartige Angriffsszenarien gibt es letztlich bei allen Blockchain-Formen; ihre Wahrscheinlichkeit sinkt durch die schiere Menge der teilnehmenden Knoten und der damit einhergehenden Reduzierung der Wahrscheinlichkeit (und damit der Motivation zur Kompromittierung), den nächsten Block beisteuern zu dürfen. In der Praxis liegt das Problem bei den Kryptowährungen daher auch nicht so sehr in der Kompromittierung der Blockchain an sich, sondern eher in spektakulären Fällen von Wallet-Einbrüchen und fehlerbehafteten Smart Contracts, die sich ungeplant um die von ihnen gehorteten Kryptowährungseinheiten bringen lassen.

Ist (nur) ein Teil des Netzwerks der Meinung, dass ein neuer Block der Blockchain nicht angehören sollte, weil er regelwidrig ist (auch Blockchain-Regelwerke sind mitunter auslegungsbedürftig) oder anderen Regelungen als bisher folgen sollte (d. h. streben „Initiatoren“ oder eine „Mehrheit“ eine Regeländerung an), besteht die Gefahr, dass die Blockchain sich parallel in verschiedene Richtungen weiterentwickelt („forks“). Das Problem der Verzweigung ist bislang auch in keiner „public“-Blockchain zufriedenstellend gelöst und dementsprechend sprießen nicht nur die Kryptowährungen, sondern auch deren „forks“ ständig neu aus dem (virtuellen) Boden. So mancher Initiator, der dachte, er habe die (politische bzw. Regel-) „Kontrolle“ über „seine“ („public“-) Blockchain, hat diese Kontrolle durch eine andersdenkende „Interessengruppe“ verloren und ist auf seiner Verzweigung sitzengeblieben.

Man kann an dieser Stelle tendenziös sagen, dass Blockchains in ihrer ursprünglichen Form, insbesondere Kryptowährungen, kleine oder große „Lotterien“ darstellen. Der Unterschied zum Glücksspiel liegt (lediglich) darin, dass hier beständig neues Geld (aus dem Nichts) geschaffen wird, d. h. die Gewinnprämie des Verfassers eines Blocks löst keinen spiegelbildlichen Verlust bei anderen Netzwerk-Teilnehmern aus (wenn man von einer reflexartigen geldmengenbedingten Wertminderung absieht, die in der Praxis nicht messbar ist). Ein „Entgelt“ für die Teilnahme (bzw. den Erwerb von „Losen“) muss ebenfalls, am deutlichsten beim „proof of stake“-Fall, aufgebracht werden. Die Motivation zur Teilnahme als aktives Mitglied zum Verfassen von Blöcken an einer Blockchain (also nicht nur als jemand, der „auf der Blockchain handelt“) ist somit die Aussicht auf einen Gewinn für den eigenen Einsatz von geldwerten Ressourcen. Das „verteilte Vertrauen“ ist lediglich der „Reflexnutzen“ dieses eigennützigen Verhaltens der Mitglieder. Man vertraut also als Nutzer der Blockchain letztlich nicht auf eine persönliche Integrität der Mitglieder in ihrer Gesamtheit, sondern darauf, dass die Aussicht auf einen Vorteil bzw. eine Belohnung dazu führt, dass die Spielregeln von allen eingehalten werden.

Private Blockchains

Die entscheidende Frage ist, was die Vorteile einer Blockchain sind, wenn man beim Design eines datenhaltenden Systems kein verteiltes Vertrauen benötigt oder dieses bewusst nicht in Anspruch nehmen will. Öffentlich-rechtliche Institutionen werden wahrscheinlich eine „public“-Blockchain nach dem vorbeschriebenen Muster, deren Regeln sie selbst letztlich nicht beeinflussen können, kaum für die Speicherung und Organisation „kritischer“ Daten verwenden. Man stelle sich vor, das deutsche Handelsregister würde mittels einer „public“ Blockchain mit internationalem Teilnehmerkreis bei möglichst großer Knoten-Anzahl betrieben. Die Mehrheit der Teilnehmer entwickelt nun – warum auch immer – die Vorstellung, eine einzutragende Verschmelzung zweier Gesellschaften sei nicht einzutragen, und es ergibt sich eine Verzweigung, in der diese Verschmelzung nie eingetragen wird. Oder die Zugangsdaten eines Teilnehmers werden entwendet und in dem Moment, in dem dieser den Zuschlag für den nächsten Block erhält, wird eine Verschmelzung eingetragen, die es gar nicht gab. Der Gesetzgeber könnte dieses „Monstrum“ nicht beherrschen, d. h. sicherstellen, dass es inhaltlich den Vorgaben deutscher Gesetze folgt, und auch die deutschen Gerichte und Exekutivbehörden wären machtlos. Wenn die Mehrheit der Teilnehmer, auf deren „Redlichkeit“ hier vertraut wird, „basisdemokratisch“ über die richtige Verzweigung entscheidet und die andere, die „gesetzmäßige“ Verzweigung links liegen gelassen wird, dann kann man von einer digitalen Revolution sprechen – aber nicht von einem verlässlichen Instrument der Verwaltung. Da müsste man den Teilnehmern schon den „richtigen“ Pfad gesetzlich mit Sanktionsandrohung vorschreiben, was das Prinzip der „public“-Blockchain in diesem Bereich ad absurdum führt.

Aus diesem Grund wird man in derartigen Konstellationen dazu neigen, vom Modell des verteilten Vertrauens abzurücken und das Vertrauen der Handelsregister-„Nutzer“ in den Staat als Betreiber des Handelsregisters in den Vordergrund stellen. Der Staat ist dann die (einzige) „trusted entity“ und gibt die Regeln der Blockchain verbindlich vor. Gegebenenfalls betreibt er auch den oder die einzigen Teilnehmerknoten, d. h. jeder neue Block wird von ihm selbst verfasst, zumindest aber geprüft. Damit sind Verzweigungen nicht mehr möglich und man muss auch nicht auf ausreichenden Eigennutz für irgendwelche anonymen Teilnehmer vertrauen.

Ist eine Partei aber vertrauenswürdig, dann kann sie für die von ihr gehaltenen und fortgeschriebenen Daten „bürgen“ (rechtlich: haften). Das ist letztlich auch der Grund, weshalb Dienste, die Datenspeicherung und Rechenkapazität im Netz anbieten (auch als Software as a Service), als (im Sinne der Datensicherheit und Manipulationsfreiheit) vertrauenswürdige Parteien angesehen werden. In diesem Bereichen – Microsoft Azure und Office 365, Amazon AWS, Google Web Services, SAP SaaS, Telekom Cloud, Archivsystemanbieter und viele mehr – werden die Daten der Benutzer (bzw. von deren Arbeitgebern), selbst wenn sie „massiv-parallel“ erfasst und verarbeitet werden, nicht in Form von Blockchains gespeichert. Wenn die Blockchain hier massive Vorteile bieten würde, müsste es längst ein „Blockchain-Outlook“, ein „Blockchain-basiertes ERP-System“ und eine „Blockchain-basierte Dropbox“ geben. Tatsächlich geht es aber immer dann, wenn eine Partei vertrauenswürdig ist, technisch also über eine entsprechend nachgewiesene IT-Sicherheit der angebotenen Dienste und der verarbeiteten Daten verfügt, nur noch um Performance und Ausfallsicherheit. Kein Betriebsprüfer wird bei in der Cloud gehaltenen Daten je auf die Idee gekommen sein, ein großer Anbieter relevanter ausgelagerter IT-Services habe steuerlich relevante Daten aus Eigennutz manipuliert, um dem Steuerpflichtigen – seinem Kunden – einen Vorteil zu verschaffen.

Damit wird deutlich: Um Datensätze in Datenbanken zu speichern, fortzuschreiben, inhaltlich zu verarbeiten – sowohl manuell als auch automatisch –, ist keine Blockchain notwendig. Die derzeit im Bereich des Steuerrechts oder der Rechnungsbearbeitung erwogenen Anwendungsfälle von Blockchains (und nicht nur diese) können bei Vorhandensein einer vertrauenswürdigen Partei problemlos mit klassischen IT-Technologien (und viel performanter) gelöst werden. Sämtliche Stellen, die steuerlich relevante Daten produzieren oder benötigen, wie Kreditinstitute, Steuerpflichtige, die Finanzverwaltung, Mittler etc. können genauso gut über eine von der Finanzverwaltung als „trusted party“ betriebene Plattform Daten zur Verfügung stellen, erhalten oder prüfen. Die Manipulationssicherheit wird durch den Plattformbetreiber sichergestellt, so wie die Manipulationssicherheit unseres Rechtssystems durch den Staat als dessen Betreiber sichergestellt wird.

Blockchain als Datenformat: Nutzen durch Verkettung?

Oft wird als zentraler Vorteil von Blockchains nicht die ursprüngliche Grundidee des verteilten Vertrauens angeführt, sondern die Authentizität, Rückverfolgbarkeit und Vollständigkeit der Block-Kette. Indem jeder Block einen Hash seines Vorgängerblocks beinhaltet, lässt sich relativ einfach „an der Kette entlang“ feststellen, ob die Blöcke lückenlos aufeinander aufbauen und ob frühere Blöcke verändert wurden (oder fehlen). Bei diesem Argument geht es also nicht mehr um die Organisationsform der globalen Verteilung von Vertrauen, sondern um das technische Datenformat, einen zusammenhängenden, wachsenden Datenbestand in Blöcke aufzuteilen, die jeweils mittels eines Hashs auf den Vorblock verweisen. Aus IT-Sicht ist dies nichts Spektakuläres: Dass Datenbanktabellen aufeinander (auch auf historische Vorversionen derselben Tabellen) verweisen, gibt es seit Beginn der Datenbanktechnologie.

Daraus folgt aber keine „Manipulationssicherheit“ per se. Natürlich kann eine solche Kette beliebig manipuliert werden, indem alte Blöcke verändert und die aufeinander aufbauenden Hashes „nachjustiert“ werden. Einfache Zeitstempel in den Blöcken könnten ebenso verändert werden. Entscheidend ist vielmehr, dass Manipulationen erkannt werden können. Dies wird tendenziell der Fall sein, wenn die Daten entweder an verschiedenen physischen Stellen als Kopien vorliegen, sodass die Veränderung eines Exemplars anhand der Nichtveränderung anderer Exemplare gezeigt werden kann, oder wenn die Daten von einer (externen) vertrauenswürdigen Stelle zu einem bestimmten Zeitpunkt signiert wurden oder wenn die Datenkette insgesamt von einer vertrauenswürdigen Stelle gehalten wird. Ein Beispiel für die letzte Variante: Natürlich kann der Staat das Handelsregister nachträglich „manipulieren“, aber erstens halten verschiedene Nutzer noch alte Handelsregisterauszüge in den Händen und zweitens würde man das einem Rechtsstaat nicht „zutrauen“ (zumal eine Veränderung für Amtsträger als besonders schwerer Fall der Urkundenfälschung strafbar ist).

Es ist an dieser Stelle zudem wichtig, bei Blockchains zwischen der Blockverkettung und der Verkettung der Nutzdaten zu unterscheiden. Bislang war Thema (nur) die Blockverkettung, d. h. die Aufnahme eines Hashes des Vorblocks (der wiederum den Hash des Vor-Vorgängers enthält) in den aktuellen Block. Diese Verkettungstechnik soll sicherstellen, dass die einzelnen Blöcke der Blockchain als solche „formal“ fortgeschrieben werden und Veränderungen in Vorgängerblöcken dazu führen, dass die Kette abbricht, sofern diese nicht in sämtlichen Nachfolgeblöcken nachvollzogen werden (was zu einer neuen Blockchain führt). In Abgrenzung dazu sind in der Regel auch die Nutzdaten als solche – unabhängig von der formalen Blockchain-Verkettung – verkettet. Stellen etwa die Nutzdaten Transaktionen zwischen Sendern und Empfängern dar, so wird dies technisch durch eine Signatur über die Vortransaktion (mit welcher der Sender das Transaktionsobjekt erhalten hat) und den öffentlichen Schlüssel des Transaktionsempfängers hinweg mit dem privaten Schlüssel des Transaktionssenders realisiert. Das Transaktionsobjekt ist also genaugenommen immer die Vortransaktion selbst bis hin zu einer „Wurzel“-Transaktion (die beim „Schürfen“ eines neuen Blocks anfällt und den „Gewinner“ begünstigt).

Man kann diese beiden Ebenen der formalen und inhaltlichen Verkettung durchaus voneinander trennen. Es bedürfte bei Kryptowährungen gar nicht der formalen Verknüpfung der Blöcke durch Hash-Werte, sondern man könnte den Weg einer jeden Krypto-Einheit durch einen „historisch gewachsenen“ Transaktionsdatenbestand zurückverfolgen, der nicht in „Blockform“ vorliegen muss. Die Authentizität einer späteren Transaktion ergibt sich dann anhand der signierten Verknüpfungen zu den Vortransaktionen. Sind diese Vortransaktionen nicht, unvollständig oder inhaltlich unrichtig im Transaktionsdatenbestand erhalten, kann die „Kette zur Münze“ nicht nachvollzogen werden. Ob bei dieser transaktionsbezogenen Authentizitätsprüfung zusätzlich Blöcke (mit Daten weiterer Transaktionen) formal richtig verkettet sind oder nicht, ist unerheblich. Die formale Verkettung der Blöcke diente ursprünglich (und im Bereich der „public“-Blockchain) lediglich der Erleichterung der Durchführung des „Gewinnspiels“ für neue Blöcke durch definierte Blockgrößen und durch definierte Blockinhalte (Hash des Vorblocks und „Nonce“-Wert) neben den eigentlichen Nutzdaten in Form von Transaktionen. Dabei war es natürlich notwendig, eine „Abfolge“ der Blöcke zu definieren: Das Spiel startet neu, wenn der vorherige Würfel gefallen ist, an den das neue Spiel dann anknüpft. Ohne definierte Würfel und Würfelgröße wäre dies kaum umsetzbar.

Das bedeutet im Ergebnis, dass – exemplarisch – eine „Kryptowährung“ nur auf der inhaltlichen Transaktionsverkettung basieren muss, nicht aber auf der Blockchain-Form. Insbesondere dann, wenn es eine vertrauenswürdige Partei für eine Kryptowährung gibt, was im Bereich der Blockchains durch eine „private“-Blockchain umgesetzt werden würde, ist die Verwendung der formalen Blockchain-Technik nicht notwendig. Es kann stattdessen auch ein einfaches, wachsendes Transaktionsregister verwendet werden. Ein Sender kann eine Vortransaktion sowie den öffentlichen Schlüssel des Empfängers signieren und zum Register einreichen, und jeder kann das Register (und damit die vollständige Transaktionskette jeder Krypto-Einheit) nachvollziehen.

Daneben ist die Bestrebung, eine Menge an (Transaktions-) Datensätzen unveränderbar zu machen, nicht immer sinnvoll. Schon aus steuerlicher Perspektive bedeutet die Vorgabe der Kenntlichmachung von Veränderungen (§ 146 Abs. 4 AO) nicht Unveränderlichkeit im technischen Sinne. Natürlich dürfen Veränderungen vorgenommen werden, auch nachträglich, aber sie müssen als solche protokolliert werden und der ursprüngliche Inhalt muss „feststellbar“ bleiben. Und generell kann es sein, dass die Rechtsordnung einen anderen Inhalt der Blockchain vorgibt als diese aufweist. Zumindest im Bereich der „private“-Blockchain kann das „Sein“ der Blockchain durchaus auch tatsächlich an das „Sollen“ der rechtlichen Vorgaben angepasst werden, etwa wenn sich Transaktionen als rechtlich unwirksam ergeben: Die Blockchain kann dann rückwirkend korrigiert werden. Hier versucht die Praxis, „Sollbruchstellen“ einzubauen, um schon die Notwendigkeit der Veränderung der Blockchain in derartigen Fällen zu verhindern. Dies kann am Beispiel der datenschutzrechtlichen Perspektive dargestellt werden: Personenbezogene Daten, die in bzw. auf einer Blockchain gespeichert werden, müssen löschbar sein (Löschgebot) bzw. dürfen unter bestimmten Umständen nur begrenzt einsehbar sein (Berechtigungskonzept). Um diese Ziele erreichen zu können, wurden verschiedene blockchainspezifische Pseudonymisierungstechniken erfunden, d. h. die eigentliche inhaltliche Information wurde von der Zuordnungsinformation, mit der die Information einer betroffenen Person zugeordnet werden kann, getrennt. So können die auf der Blockchain befindlichen Informationen „entschlackt“ werden und die Löschung der Zuordnungsinformation außerhalb der Blockchain kann zu einer Löschung der personenbezogenen Daten insgesamt führen. Überhaupt haben sich aus verschiedenen Gründen, auch dem Geheimnisschutz oder der Anonymität, Techniken der Informationstrennung entwickelt, was den Nachteil hat, dass dann die vollständige Information zum Teil in der Blockchain selbst, zum Teil außerhalb liegt. Die „Blockchain-Datei“ als solche enthält dann nicht alle maßgeblichen Informationen. Auch diese „Verkünstelungen“ stellen einen Nachteil im Verhältnis zu zentral bei einer vertrauenswürdigen Stelle betriebenen Datenbank dar.

Die Technik der Signatur als „Goldstandard“ der Authentifizierung

Deutschland hat als erster Staat 1997 ein Signaturgesetz erlassen. In der Praxis hat das 2016/2017 durch die eIDAS-Verordnung und das Vertrauensdienstegesetz abgelöste Signaturgesetz nicht die Durchschlagswirkung entfaltet, die man sich erhofft hatte. Dennoch hat sich die Technik der elektronischen Signatur (in Gestalt asymmetrischer kryptografischer Schlüsselpaare) und die zugrundeliegende Technik der Erzeugung digitaler „Fingerabdrücke“ von beliebigen Daten (Hash-Funktion) als sehr wirkmächtig erwiesen. Durch eine Signatur wird – so die juristische Wertung – zumindest widerleglich (d. h. bis zum Beweis des Gegenteils) vermutet, dass bestimmte Daten einer bestimmten Stelle zu einem bestimmten Zeitpunkt vorgelegen haben. Hierzu wird der Hash-Wert der Daten mit dem privaten Schlüssel des Signierenden verschlüsselt und die Richtigkeit der Signatur kann mit dem frei verfügbaren öffentlichen Schlüssel jederzeit und von jedem nachgeprüft werden. Das Vertrauensproblem wird im Bereich der Signatur seit jeher durch Public Key Infrastructures (PKIs) gelöst, die letztlich als Wurzel wieder auf den Staat verweisen (im Falle des Signaturgesetzes auf die Bundesnetzagentur). Der Nachweis bezieht sich zunächst nicht auf die inhaltliche Richtigkeit, sondern nur auf die Identität „irgendwelcher“ Daten; der Inhalt der signierten Daten wird aber dann Gegenstand der Signatur, wenn dabei (auch) eine Erklärung des Signierenden über den Inhalt getätigt und mit signiert wird.

Die „public“-Blockchain enthält in ihren gängigen Ausprägungen keine Signatur-Mechanismen hinsichtlich der Authentizität der Blockchain-Datei selbst (als Verknüpfung aus Einzelblöcken), sondern, wie oben dargestellt, lediglich hinsichtlich der in den Blöcken enthaltenen „Nutzdaten“ in Form von Einzeltransaktionen. Stattdessen gibt es einen impliziten „Signatur“-Mechanismus in dem Sinne, dass das Ergebnis der Blockbildung (und die daraus resultierende Prämie) von der Mehrheit der Teilnehmer durch schlichten Nachvollzug der Bildung des Blockes „akzeptiert“ werden muss, um den nächsten Block „erarbeiten zu können. Diese „faktische Authentifizierung“ durch die Mehrheit umfasst auch die richtige Verknüpfung zum Vorgängerblock. Das ist natürlich keine „Signatur der Blockchain“ durch eine vertrauenswürdige Stelle (bei verteiltem Vertrauen: durch sämtliche übrigen Teilnehmer) im technischen Sinne und bringt im Übrigen Probleme mit sich, wenn zwei Teilnehmer „quasi-gleichzeitig“ das Gewinnspiel für den nächsten Block – aber mit unterschiedlichen im Block enthaltenen Transaktionsdaten – gewinnen. Die Authentizität der „public“-Blockchain ergibt sich somit lediglich daraus, dass viele Kopien verfügbar sind, sodass ein einzelner Teilnehmer, der einen früheren Block manipuliert und daraus eine eigene Folge-Blockchain für sich fortschreibt, leicht aus der Mehrheitsperspektive als Manipulator erkannt werden kann (und aus Sicht der anderen Teilnehmer auch keine neuen Blöcke dieser verzweigten Blockchain mehr erzeugen darf).

Im Bereich der „private“-Blockchain fehlt ein derartiger Mechanismus der „Authentifizierung durch Masse“. Nur dann, wenn der Inhalt der „private“-Blockchain vollständig für deren Nutzer transparent ist (was nicht zwangsläufig der Fall ist), kann auch hier anhand der Massen von de facto anderslautenden Kopien bei den Nutzern – vorausgesetzt, diese haben die Blockchain-Datei ständig abgefragt und archiviert – eine Manipulation durch den Initiator und Betreiber der Blockchain aufgedeckt werden. Anstatt aber nun eine Blockchain alleine „für sich“ zu betreiben und damit (bzw. mit bei Dritten befindlichen Kopien) irgendwelche Nachweise über die Authentizität antreten zu wollen, ist es für diesen Nachweis geeigneter, die Datensätze durch eine vertrauenswürdige Stelle förmlich signieren zu lassen. Diese Stelle kann eine Institution wie die Finanzverwaltung oder eine Cloud-TSE sein oder eine gekapselte sichere Signaturerstellungseinheit in Hardware-Form, die über eine sichere Zeitquelle verfügt. Ob die einzelnen Datensätze dabei fortlaufende Nummern oder Referenzen auf Vorgängerblöcke enthalten, ist für die Authentizität des signierten Gesamt-Datensatzes (und der Zeit seiner Erstellung) unerheblich.

Man kann auf diese Weise einzelne Datensätze (in welchem Format auch immer), Datenbankteile oder sogar ganze Datenbank-Dateien (also Dateien, die eine vollständige Datenbank enthalten) signieren (lassen). Dabei muss nicht das eigentliche Dokument an den vertrauenswürdigen Dritten weitergereicht werden, sondern es genügt auch die Übermittlung und Signierung des Hash-Wertes. Bei der späteren Verifikation kann anhand der Originaldaten demonstriert werden, dass (nur) diese einen bestimmten Hash-Wert ergeben und dieser Hash-Wert mit dem öffentlichen Schlüssel des vertrauenswürdigen Dritten verprobt werden kann. Es liegt in der Natur der Hash-Funktion – und das rechtfertigt alleine ihre Funktion –, dass es mit vertretbarem Aufwand unmöglich ist, einen Datensatz zu finden, der vom Originaldatensatz abweicht, aber denselben Hash-Wert ergibt. Die Technik der elektronischen Signatur ist für die Absicherung der Authentizität von Daten wesentlich wertvoller und universeller als die Technik der Blockchain.

Tokens

Hinsichtlich Tokens wird häufig implizit unterstellt, dass diese exklusiv mit dem Thema Blockchain verknüpft sind. Im Grunde repräsentieren Tokens in ihrer eigenen „Bedeutungsumgebung“ virtuelle oder reale Gegenstände. Ähnlich wie im Wertpapierrecht ein Papier (als „Token“) eine Forderung verbriefen kann, kann ein digitaler Token im Sinne einer „Kennziffer“ einen virtuellen Sachverhalt repräsentieren oder auch einen realen oder rechtlichen Sachverhalt (Aktie) virtualisieren. Token sind als solche von der Blockchain oder anderen technischen Laufzeitumgebungen unabhängig. Sie können natürlich nur in einem bestimmten Blockchain-Umfeld generiert, verwaltet und nur dort werthaltig sein, aber sie können auch unabhängig davon vergeben werden und (z. B. als „Gutscheine“) einlösbar sein. Meist sind Tokens an zusätzliche Mechanismen der Identifizierung ihres Besitzers gekoppelt, denn ansonsten könnte nur mit einer Kopie des Tokens dessen wertmäßiger Inhalt „abgezogen“ werden (ähnlich einem Inhaberpapier, bei dem der physische Besitz die Legitimation vermittelt).

Aufgrund dieser zusätzlichen Anforderung an die Verknüpfung zwischen Besitzer und Vermögenswert ist ein Krypto-Vermögenswert häufig gar kein „Token“ im eigentlichen Sinne. In typischen Kryptowährungs-Blockchains bedarf die Übertragung von Währungseinheiten der Signierung einer – aus dem Hash der Vortransaktion und dem öffentlichen Schlüssel des Erwerbers bestehenden – Transaktion mit dem privaten Schlüssel des Inhabers der Währungseinheit. Einen „Token“, der als solcher übertragen würde, gibt es hier gerade nicht. Die Kryptowährungs-Einheiten, über die ein Besitzer verfügt, sind schlicht die Gesamtheit der von den Veräußerern signierten (und in die Blockchain aufgenommenen) Transaktions-Datensätze, in denen der Besitzer (vom Veräußerer) als Transaktionsziel (d. h. als Erwerber) benannt wurde.

Auch die Finanzverwaltung kann im Rahmen von Modellkonzepten „Tokens“ für beliebige fiskalische Zwecke ausgeben, ohne deswegen eine Blockchain betreiben zu müssen, solange sie als vertrauenswürdige Stelle für die Ausgabe (und ggf. Einlösung) dieser Tokens angesehen werden kann – was natürlich einer gesetzlichen Grundlage bedarf. Würde beispielsweise, das Modell der Fiskalisierung von Kassendaten in § 146a AO weiterführend, ein Rechnungsdatensatz (oder ein Hash eines solchen Datensatzes) an einen Dienst der Finanzverwaltung übertragen und die Finanzverwaltung liefert eine Signatur mit Zeitstempel zurück (Finanzverwaltung als „Cloud-TSE“), dann spielt es keine Rolle, ob die empfangenen Datensätze und die ausgelieferten Signaturen aufseiten der Finanzverwaltung in einer Blockchain gespeichert werden oder in einer „einfachen“ Datenbank. Auch die tatsächlichen Vorgaben der Fiskalisierung von Kassendaten in der Kassensicherungsverordnung sehen zwar eine Verkettung der Transaktionen über die von der zertifizierten technischen Sicherheitseinrichtung (TSE) vergebenen laufenden Transaktionsnummern vor, aber gerade nicht in „Blockchain-Form“. Das wäre zwar „hip“ gewesen, ist aber in der Sache unnötig.

Smart Contracts

Häufig werden Smart Contracts als untrennbar mit der Blockchain bezeichnet, ja sogar der Betrieb einer Blockchain nur wegen der Möglichkeit der Ausführung von Smart Contracts erwogen. Den Worten des „Erfinders“ des Begriffs, Nick Szabo, von 1997 kann entnommen werden, dass ein Smart Contract im Grundsatz ein Computerprogramm ist, das eigenständig Ereignisse verarbeitet und Aktionen ausführt, die man typischerweise der Ausführung von Geschäftsabläufen („business process“) bzw. Transaktions- oder Vertragsvereinbarungen zurechnen würde, sodass deren automatische Ausführung „smart“ („schlau“) ist. Damit stellen Smart Contracts begrifflich Computerprogramme mit einer bestimmten Zwecksetzung bzw. in einem bestimmten Einsatzkontext dar. Ein solches Computerprogramm (bzw. die Ausführung programmgesteuerter Anweisungen) kann seiner Natur nach ein Vertrag „sein“ bzw. einen solchen „repräsentieren“. Durch die Erweiterung herkömmlicher Computer-Schnittstellen und Schnittstellen-Protokolle, über die nur Datensätze („Formulare“) zwischen Systemen ausgetauscht werden, um Vertragsalgorithmen, die „selbstständig“ innerhalb ihrer Laufzeitumgebung „handeln“ können, sollen – so Nick Szabo 1997 – Geschäftsbeziehungen „smarter“ ablaufen. In einem Bericht des US-Senats 2018 heißt es: „While smart contracts might sound new, the concept is rooted in basic contract law. Usually, the judicial system adjudicates contractual disputes and enforces terms, but it is also common to have another arbitration method, especially for international transactions. With smart contracts, a program enforces the contract built into the code“. Das Schreiben und Verhandeln von Vertragstext wird so – in der Theorie – zum Schreiben und Verhandeln von Computerprogrammen verwendet, und anstatt vertragliche Ansprüche aufwendig in Gerichtsverfahren und ggf. mithilfe von Gerichtsvollziehern durchzusetzen, kann der Smart Contract die virtuelle Realität gleich so verändern, wie es seinem (bzw. dem vereinbarten) Code entspricht. Bildlich gesprochen muss man in der realen Welt einen Mieter aus einer Mietwohnung „herausklagen“, in der virtuellen Realität würde der Smart Contract den (virtuellen) Mieter automatisch „von der Plattform entfernen“. Was ähnlich spektakulär wie die Automatisierung im Industriezeitalter klingt, ist aber in der Praxis noch weit von breiter Anwendung entfernt. Dabei geht es natürlich nicht um den Einsatz von Computerprogrammen und automatisierten Prozessen, auch im Zusammenhang mit der Blockchain, sondern um „Bots“, die auf der Blockchain „leben“ und tatsächlich mit wirtschaftlichem Erfolg eingesetzt werden. Dass dies bislang nicht breitflächig eingesetzt wird – und eine Menge Arbeitskräfte obsolet macht –, dürfte zumindest zu einem guten Teil, wie so häufig in der IT-Welt mit ihren vielen Insellösungen, an fehlender Standardisierung und inkompatiblen Formaten / Laufzeitumgebungen liegen. Von wirklicher „Selbstständigkeit“ von „virtuellen Vertragsagenten“ ist also in der Praxis noch lange nicht die Rede; hier müsste insbesondere das Thema KI zunächst noch einen großen Schritt nach vorne machen.

Das Grundproblem, dass das „Rechtssystem“ hinsichtlich eines bestimmten Sachverhalts zu einem anderen Ergebnis kommen kann als der Smart Contract selbsttätig „vollzieht“, soll hier nicht weiter erörtert werden. Der oben skizzierte Smart Contract „Mietvertrag“ könnte eine Situation vorfinden, in der ein „analoges“ Räumungsurteil wegen sozialer Bedürftigkeit des Betroffenen derzeit nicht vollzogen werden; als Teil der Smart-Contract-Logik ist das wegen „unbestimmter Rechtsbegriffe“ und der Notwendigkeit des laufenden Zugriffs auf persönliche Einkommensverhältnisse in der Praxis nur schlecht implementierbar. Darüber hinaus wird aber erkennbar, dass Smart Contracts begrifflich zunächst nichts mit Blockchains zu tun haben. Der Grund, dass beide Themen miteinander verknüpft werden, liegt in der populären „public“-Blockchain Ethereum, in der zuerst im großen Stil die Möglichkeit geschaffen wurde, „auf der Blockchain“ (d. h. als deren Nutzdaten) nicht nur Transaktions-Datensätze, sondern auch ausführbaren Code mitsamt (statischem) Speicherplatz zu hinterlegen. Damit die Teilnehmer einen neuen Block generieren können – von denen dann ein zufällig ausgewählter „prämiert“ wird –, müssen die auf der Blockchain gespeicherten Smart Contracts, soweit sie in diesem Zyklus einer Ausführung bedürfen, „durchgerechnet“ bzw. „ausgeführt“ werden. Das Resultat, das insbesondere in geänderten (statischen) Daten oder in Transaktionsdatensätzen über Krypto-Währungseinheiten bestehen kann, wird dann Teil des neuen Blocks (und kann von den anderen Teilnehmer nachvollzogen und „akzeptiert“ werden). Hieraus wird deutlich: Die „public“-Blockchain bietet sich aufgrund der „verteilten Vertragslogik“ auch als Laufzeitumgebung für Programme in Form von Smart Contracts an. Mit anderen Worten: Wenn es keinen vertrauenswürdigen Dritten gibt, dem man die Ausführung seines Codes anvertrauen kann, dann kann man dies auch an eine unbekannte Vielzahl von Teilnehmern „delegieren“, denen man „verteiltes Vertrauen“ entgegenbringt. Es wird aber auch deutlich, dass die „zigfache“ parallele Ausführung des Codes bei den Teilnehmern im Rahmen des großen „Gewinnspiels“, von denen eine Ausführung (bzw. der daraus hervorgehende Block) dann später „das Rennen macht“, wenig effizient ist, d. h. die Effizienz wird zugunsten der Vertrauenswürdigkeit des Ergebnisses erheblich eingeschränkt.

Daneben sind in einer solchen Laufzeitumgebung (Blockchain) nur Smart Contracts sinnvoll, die für sämtliche Teilnehmer transparent sein dürfen, denn den Bytecode des Smart Contracts kann jeder Teilnehmer lesen und analysieren (und Schwachstellen ausnutzen). Schon wird über die Verschlüsselung des Codes auf der Blockchain nachgedacht; dabei ist es doch dann, wenn der Code vertraulich gehalten werden soll, in den meisten Anwendungsszenarien viel effizienter, ihn als „Bot“ oder „Agent“ in einer getrennten Laufzeit- bzw. Systemumgebung ablaufen zu lassen, an das Transaktionen auf der Blockchain gerichtet sein können (als Empfänger), das Transaktionen auf der Blockchain auslösen kann (als Sender) und das generell auf „Events“ im Zusammenhang mit der Blockchain (oder sonst aus der „Außenwelt“) reagieren kann.

Geht es im Bereich von Smart Contracts um „transaktionsbezogene Automatisierung“, so gibt es demnach zwei denkbare Umsetzungsmöglichkeiten außerhalb einer Laufzeitumgebung „auf der Blockchain“ selbst. Einerseits kann ein Unternehmen (bzw. ein Steuerpflichtiger) seine bisher analogen, papier- und menschengestützten Prozesse für sich selbst innerhalb seiner eigenen IT-Landschaft automatisieren. Damit dies „im Außenverhältnis“ umgesetzt werden kann, muss es entsprechende Schnittstellen (inkl. APIs) und Datenformate geben. Das beginnt mit einfachen Wenn-Dann-Beziehungen: Immer dann, wenn das Finanzamt A die beantragte Bescheinigung zum Thema X schickt, soll diese, verbunden mit weiteren Dokumenten zum Vorgang, an das Finanzamt B gereicht werden. Funktionen zur Übernahme derartiger Tätigkeiten werden derzeit unter dem Schlagwort „robotic process automation“ (RPA) entwickelt und vermarktet. Wenn die Finanzverwaltung die entsprechenden Schnittstellen und Datenformate bereitstellt, kann diese Lösung zwar auch mittels einer „public“-Blockchain oder einer von einem Dritten betriebenen „private“-Blockchain (jeweils außerhalb der Finanzverwaltung) realisiert werden; welcher Steuerpflichtige sich aber auf ein solches Laufzeitsystem, das außerhalb seiner IT-Landschaft existiert und sich auch „ungefragt“ verändern kann, verlassen möchte, ist eine andere Frage. Andererseits kann natürlich auch die Finanzverwaltung eine Laufzeitumgebung für derartige Skripte zur Verfügung stellen, die dann (nach entsprechender Autorisierung etc.) auf entsprechende Datenbanken der Finanzverwaltung zugreifen, auf Ereignisse aus der Außen- oder Innenwelt reagieren und Daten an ihren „Auftraggeber“ weiterleiten können. Diese Möglichkeit soll aber hier nur aufgezeigt werden, um die in der Theorie denkbaren Ansätze darzustellen; in der Praxis wird keine Finanzverwaltung eine Laufzeitumgebung für ausführbare Inhalte von Steuerpflichtigen (inkl. Viren und Trojaner) zur Verfügung stellen und damit zu einem Anbieter von Cloud-Rechenleistung werden.

Identitätsmanagement

Als Zwischenergebnis kann daher nicht verwundern, dass die bislang unterbreiteten Vorschläge für „Steuer-Blockchains“ – also neudeutsch „use cases“ – wenig konkret sind. Hinzu kommt, dass jegliches Vertrauen der Finanzverwaltung auf eine externe Blockchain-Lösung sowie jede Entwicklung einer verwaltungseigenen Blockchain, mit der Steuerpflichtige irgendwie interagieren müssen, eines entsprechenden Gesetzes bedürfte. Derartige Gesetze erfordern viel Vorarbeit, insbesondere im Bereich der Evaluierung verschiedener Lösungsansätze, und müssten auch genau die bei den Steuerpflichtigen notwendigen Investitionen bewerten. Die Historie zeigt, dass in der Vergangenheit die Schätzungen des Aufwands der Wirtschaft für die Umsetzung von Gesetzen und Gesetzesänderungen tendenziell unterschätzt wurden (und auch keiner Nachbetrachtung – im Sinne von „lessons learned“ – unterliegen). Rein verwaltungsinterne Lösungen auf Blockchain-Basis (etwa um KI-Algorithmen nutzbar zu machen) ohne Schnittstellen gegenüber Dritten sind ohnehin nicht interessant, denn eine Blockchain „nur für sich selbst“ erfordert einen Implementationsaufwand, der außer Verhältnis zum (internen) Nutzen steht. Wie oben gesagt, ist für die Übermittlung steuerlicher Informationen von und zur Finanzverwaltung die Blockchain nicht notwendig und sie vermittelt auch keine absolute Manipulationssicherheit, solange sie nicht von der Verwaltung selbst exklusiv geführt wird. Die Idee, ein europaweites digitales Postfachsystem für steuerlich relevanten Dokumenten- und Nachrichtentransfer zu schaffen, könnte sich eher an sicheren Übertragungssystemen wie dem besonderen elektronischen Anwaltspostfach (beA) mit stetig wachsenden Möglichkeiten der Berechtigungsvergabe orientieren. Die Blockchain als solche ist kein Übermittlungsmedium.

Ein weiteres Argument, mit dem häufig Steuer-Blockchain-Lösungen begründet werden, ist das digitale Identitätsmanagement. Dieses beruht auf der Signatur-Technologie. Die Blockchain als solche macht digitale Identitäten nicht sicherer oder besser verwaltbar. Im Gegenteil: Da die EuGH-Rechtsprechung zur Frage, wann genau bei Verwendung von „Identifiern“ (Pseudonymen) der Personenbezug endet, diffus ist (sog. Breyer-Entscheidung zu dynamischen IP-Adressen), kann derzeit nicht mit Sicherheit gesagt werden, welche „identitätsvermittelnden“ Daten in einer Blockchain unter die DSGVO (und damit das datenschutzrechtliche Löschgebot) fallen und welche nicht.

Dienste zur Identitätsverifikation und „Beglaubigungsdienste“ für beliebige Informationen (im Sinne der Signierung mit Zeitstempel) können über eine einfache API zu einem staatlichen digitalen Service-Angebot abgewickelt werden, hinter dem keine Blockchain, sondern „gewöhnliche“ Datenbanktechnologie steckt. Entscheidend für derartige Dienste wäre, dass derjenige, dem die jeweilige Information zugeordnet ist, darüber entscheiden kann, wer auf die Information (lesend) zugreifen kann, sodass auch andere Teilnehmer im Rechtsverkehr (widerruflich) dauerhaft oder ad hoc berechtigt sind, bei der vertrauenswürdigen Stelle eine als inhaltlich richtig zertifizierte Information abzufragen. Selbst die Apologeten der Blockchain geben zu, dass datensouveränes Identitätsmanagement („self-sovereign identity“ – SSI) als solches keiner Blockchain bedarf, pochen aber darauf, dass ein dezentralisiertes System die vollen Potenziale solcher Konzepte besser ausschöpfen könne. Dies wird damit begründet, dass im Rahmen einer Blockchain ein identitätsgesichertes Handeln ohne Intermediäre oder zentrale Stellen möglich sei, obwohl doch sämtliche diesbezüglichen Konzepte immer wieder auf eine „trusted entity“ zurückverweisen (müssen), welche für die Richtigkeit der übermittelten Identitätsinformation „bürgt“.

Warum verschwinden viele Blockchain-Projekte wieder in der Schublade?

Es gibt sowohl in der Privatwirtschaft als auch in der Finanzverwaltung verschiedene (Pilot-) Projekte, auf die hier nicht im Einzelnen eingegangen werden soll, deren Ziel es zu sein scheint, möglichst intensiv mit dem Etikett „Blockchain“ zu werben oder eine Blockchain als Selbstzweck zu konzeptionieren, (nur) um sich als Blockchain-Konzeptionierer hervortun zu können. Was solche Projekten bisweilen auszeichnet, ist der Hang zur Überkomplexität: Die Einbindung von Techniken, die neben der Blockchain „en vogue“ sind (wie z. B. „zero knowledge proofs“, „differential privacy“, Verfahren der künstlichen Intelligenz), ohne dass deutlich wäre, weshalb diese Techniken konzeptionell erforderlich sind, um das – oft sehr einfache – Ziel zu erreichen. Die Leitlinie „keep it small and simple“ wird dabei zugunsten des Einsatzes „hipper“ Techniken, die entsprechende Aufmerksamkeit und Anerkennung versprechen, verletzt. Es kann daher nicht verwundern, dass derartige Projekte trotz großer Publizität wieder in der Versenkung verschwinden. Und selbst wenn eines einmal Erfolg haben würde, entspräche es der üblichen kognitiven Verzerrung („survivorship bias“), zu negieren, dass sich dahinter hunderte von erfolglosen Projekten – mit entsprechendem Aufwand, auch in Form von Steuergeldern – verbergen.

Schon im nationalen Rahmen erfordern derartige Projekte, sofern sie breitflächig in die Realität „ausgerollt“ werden sollen, in aller Regel die Anpassung bestehender rechtlicher Vorgaben. Das gilt natürlich insbesondere für Machbarkeitsstudien und „Planspiele“, die (auch und insbesondere) von staatlicher Seite betrieben werden. Neben technischer oder akademisch induzierter Überkomplexität, die den praxisgerechten Einsatz erheblich erschwert, droht hier zusätzlich, dass solche Pläne bei politischen Ränkespielen unter die Räder kommen und bis zur Unkenntlichkeit „zurechtgeschliffen“ werden. Inmitten solcher zeitaufwendigen „Schleifprozesse“, um Komplexität abzubauen oder naheliegende Schwachstellen abzustellen, werden derartige Lösungen dann links überholt. Die Probleme potenzieren sich, wenn die Lösung länderübergreifend umgesetzt werden soll. Innerhalb der EU wären einheitliche Lösungen auf Basis von Richtlinien oder Verordnungen denkbar; hier bestehen „nur“ die vorstehend skizzierten Probleme. Sobald aber steuerlich relevante Daten etwa in international betriebenen Blockchains (wie beispielsweise im Verbund mit den USA, Indien und/oder China) gehalten werden sollen, bedarf es daneben entsprechender zwischenstaatlicher Verträge und darauf basierender Ausführungsgesetze. Es liegt auf der Hand, dass die Frage der Machtverteilung, der Rechtsmittel, der Datenhoheit, der Berechtigungen, der Gerichtsbarkeit etc. nicht einfach zu lösen sind. Das zeigt etwa im Bereich Datenschutzrecht das „Privacy Shield“ zwischen der EU und der USA, das vom EuGH nach Jahren der praktischen Anwendung für unanwendbar, weil in den USA nicht ausreichend effektiv rechtsstaatlich geschützt, erklärt wurde.

Ein Ergebnis

Wenn es darum geht, steuerliche Sachverhalte stärker als bisher digital und vernetzt abzubilden und zu administrieren, insbesondere im Austausch zwischen der Finanzverwaltung, dem Steuerpflichtigen und ggf. Dritten, die in Geschäftsbeziehung mit dem Steuerpflichtigen stehen, gibt es keine zwingenden Gründe, warum dafür ausgerechnet eine Blockchain verwendet werden sollte. Im Gegenteil: Die Verwendung einer Blockchain wirft mehr Fragen auf, als sie beantworten kann – und hier wurden noch gar nicht einmal alle Fragen gestellt –, und sie erscheint eher als modebedingtes „Over-Engineering“ mit zweifelhaften Folgeeffekten.

Die Digitalisierung des Steuerrechts muss vielmehr von den Dateninhalten und den Datenflüssen her entwickelt werden. Viel wichtiger als der Einsatz eines Instruments, das für einen gänzlich anderen Einsatzzweck entwickelt wurde, ist es, Datenformate zu standardisieren (wie etwa das DSFinV-K-Format der Finanzverwaltung), Übertragungsschnittstellen für Datenkommunikation zu definieren und diese in die Weiterentwicklung der Unternehmens-Software (wie ERP-Systeme) zu integrieren. Die Finanzverwaltung muss irgendwann in der Lage sein, sämtliche Input- und Output-Informationen, welche das Gesetz vorsieht, in digitaler, strukturierter Form zu empfangen und zu versenden. Dort, wo Missbrauchsrisiken bestehen (etwa durch Fälschungen), müssen diese konkret im Rahmen einer dokumentierten Risikobewertung benannt werden und dann zur Abmilderung der Risiken beispielsweise sichere Übertragungswege oder Signaturen (und Signaturprüfungen) vorgegeben werden. Dass dann auf dieser Basis „hinter den Schnittstellen“ (also in ihrem Innenbereich) sowohl die Finanzverwaltung selbst als auch die Unternehmen alles, was an Verarbeitungstätigkeit automatisierbar ist, irgendwann auch automatisieren werden, steht außer Frage. Eine Blockchain – zumal als nicht beherrschbare „public“-Blockchain – ist dafür weder notwendig noch zweckmäßig.