Distributing Business Processes using Finite State Machines in the Blockchain

Having disctinct, even competing organisations with a common goal and no shared technical infrastructure represent a perfect use case pattern for blockchain usage.

The quest for the holy business use case

As many blockchain enthusiasts we are constantly searching for use cases for establishing Distributed Ledger Technology (DLT) or even real blockchain technology in enterprises as solutions for common business problems.

[Business *]

This turns out to be difficult, since each single aspect of this technology is already solved by several – established and well known – products. 

In this post we will present a use case, or even a use case pattern, which we think is ubiquitous and can best be solved by blockchain technology.

For these type of use cases the other technologies, even though being more mature, seem themselves like workarounds for the natural technological solution, which is blockchain-based.

Our definition is the use case pattern is:

Several distinct, competing organisations have a common goal and don't share technical infrastructure.

distinct, even competing organisations

Distinct organisations are not related to each other and therefore have no existing technical or organisational processes. To pursue a common goal, these processes would have to be established first, which is costly and time-consuming.

[Competing teams *]

The second aspect, competition, implies that there is no mutual trust. Obviously, this aspect is a crucial one. Blockchain technology might even make sense if just the other aspects of the pattern match, but it only is a perfect fit if this aspect is important, since the blockchain itself is inherently trust-less.

common goal

This is the fundamental requirement, if there is no common goal, there is no need to establish any collaboration. It is important to note, that the common goal is most likely not related to the core competence of the organisations, but to some crosscutting concerns, which have to be addressed by all organisations, but are just cost factors.

no existing shared technical infrastructure

To put it contrary: if there already exists a shared technical infrastructure, also organisational processes exist to establish new technology. Given this, there are several great technology products which implement each aspect of the blockchain technology (namely distributed data storage, immutability, security), and most likely even more performant, more mature, with less maintenance and evident responsibilities.

Ok, this is quite abstract and complex, let’s find an easy example.

…want a securities account with your new account?

There is one universal retail bank, FriendlyBank, which wants people to open accounts. And there are three deposit banks, FriendlyDeposit, EasyDeposit and NiceDeposit. There is also the Regulator, who must be able to audit all transactions between the parties.


common goal: make money

The common goal of universal and deposit banks is to open accounts. The universal bank can be intermediary to deposit account opening, so you can open a securities account at one of the three deposit banks with your new account at FriendlyBank. This way, it is a win-win-situation for both parties, the intermediary gets commissions, the deposit banks get new customers.

FriendlyBank and FriendlyDeposit are related to each other, they have the same ownership structure, but are separated entities. Since the deposit banks are in competition with each other, the other deposit banks besides FriendlyBank want to be sure that not very valuable customers are transferred to FriendlyDeposit or the deposit account opening is “accidentally forgotten”, if not FriendlyDeposit is chosen.
Since the parties do not really trust each other, a trust-less (ie. no trust necessary) solution is needed.

the wonderful world of finance IT today

As we said, the depicted scenario exists quite often. Also, technical “solutions” for these scenarios exist.

They look similar to this one:


We wan’t go in detail what all this means, but to become trust-less, as well as assure that the data is in sync in each organisation, a lot has to be implemented and still, shortcomings of these solutions are quite common:

  • reconciliation processes are always necessary, but still, due to missing transaction support in flat file exchange, which is almost always chosen as the “simplest” integration pattern, errors occur.
  • adapters have to be built for each party, so there will soon exist a many-to-many problem.
  • special adapters have to be built for regulators.
  • crosscutting concerns have to be implemented: security, authentication, auditing, transaction support

Compared to a natural solution in the blockchain

Below is the blockchain solution, it fits naturally and implements all requirements.bcsample

Abstracting from the use case

Why is this solution matching so well, what is the pattern “behind”?

Different actors change the state of a business process on some event in a transactional way.

[Old cigarette machine *]

You certainly know this pattern, it is describing a finite state machine, more exactly a distributed, secured by cryptoeconomics finite state machine, which events are transactions.

After all, the blockchain itself is a state transition system, it somes quite naturally to implement a simple state machine on the Ethereum EVM, it even is mentioned as a common pattern in the Solidity docs.


Approaching the finite state machine

How would the organisations collaborate? This could look like this informally:



or like this (more) formally:


so we actually can built this state machine and its transitions really easy using the blockchain, here in pseudo-Solidity, derived from the common pattern in the Solidity docs:

contract AccountDepositStateMachine {
enum Stages { Init, AccountOpened, DepositOpened, DepositConfirmed, AccountConfirmed } Stages public stage = Stages.Init; modifier atStage(Stages _stage) { if (stage != _stage) throw; _ } function nextStage() internal { stage = Stages(uint(stage) + 1); } // Order of the modifiers matters here! function openAccount() atStage(Stages.Init)
{ if (msg.sender != FRIENDLY_BANK) throw; } function openDeposit() atStage(Stages.AccountOpened)
if (msg.sender != FRIENDLY_BANK) throw;
function confirmDeposit()
if (msg.sender != DEPOSIT_BANK) throw;
modifier transitionNext() { _ nextStage(); } }

Great, so that’s it, we can build any business process using the blockchain, QED.

Leaving the ivory tower

As you might guess, it is not that simple. Let’s review the actual process:

  1. Account is opened 
  2. Deposit Account is opened
  3. Deposit Confirmed
  4. Account Confirmed

Ever saw an IT-process in real life? Exactly, it’s not like this, not even close. Let’s see a more real life example:

  1. Account is opened
  2. An Email is send to whoever feels responsible
  3. The Product Owner’s Excel has to be updated
  4. The new reporting engine must have its data updated, it is runnig with MongoDB, which has to be updated
  5. Revision wants to have it’s auditing data in their Oracle DB (must use 2PC)
  6. … (ok, you got it already…)

None of the tasks in bold red can be accomplished from the Ethereum blockchain, since calls from “inside” to “outside” are prohibited. Let’s hope this will never change, the separation of “inside” and “outside” is essential for the stability and security of the Ethereum blockchain

We could use Oracles for this, but it would be a kind of usage which is highly inappropriate for this type of external information retrieval.

Teaser: “Mastering the Flow: Blending Reality with the Blockchain”

This post is way too long already, so here comes a teaser for two posts next to come: “Mastering the Flow: Blending Reality with the Blockchain”

The idea is really simple: let’s just recentralize the business process (we are in eager anticipation for the comments to come…)

But we think this can make sense. Look at the sample above, illustrated as a flow:


The flow was created with Node-RED, an excellent and highly undervalued tool of IBM Emerging Technologies for flows in IoT. It could be very easily adapted to Ethereum with smart contract access by usage of web3.js, which itself can be integrated in node.js, which is the basis of Node-RED, hence the name.

We make the following assertion:

More than 80% of all use cases can be realized by a centralized business process engine as a first layer, eg. implemented in Node-RED, and a state machine implemented in the blockchain as a second layer

The business process engine is the glue between the transactional blockchain state transitions and the secondary business processes.

What do you think of it? Please let us know in the comments, we really appreciate feedback, positive or negative.

And stay tuned for the next episode, we will get to the nitty-gritty there.

[Business] Business by Christophe BENOIT under CC
[Competing teams] Competing teams by Denis De Mesmaeker under CC
[Old cigarette machine] Old cigarette machine by Walter Baxter under CC

Ethereum Usecase: Online Identitätsprüfung

Die Identitätsprüfung des Kunden bei Onlinegeschäften ist in der Regel ein Prozess, der mehrere Tage in Anspruch nimmt. Die Identifizierung wird zum großen Teil über das PostIdent Verfahren abgewickelt, das von dem Kunden verlangt zur Postfiliale zu fahren, um sich vor Ort identifizieren zu lassen. Die schnellste (mir bekannte) Onlineidentifizierungsmethode bietet idnow, das z.B. von Number26 bei der Kontoeröffnung benutzt wird. Dabei wird in einem Video-Chat die Identität des Kunden überprüft. Der Prozess nimmt etwa 5 Minuten in Anspruch und ist mit gängigen Smartphones durchführbar.

Was wäre aber, wenn man den Identitfikationsprozess noch schneller und mit noch weniger Intermediären durchführen könnte? Das Zauberwort heißt Ethereum.

Der große Anspruch von Ethereum ist es einen offen zugägnlichen Welt-Computer zu schaffen, der in der Lage ist die Programme, die er ausführt und den Laufzeitzustand, der sich aus der Ausführung dieser Programme ergibt, in eine Blockchain so zu verpacken, dass es keine Möglichkeit gibt die Programme oder deren Laufzeitzustand zu verfälschen.

Jeder Benutzer und jedes Programm in Ethereum haben eine oder mehrere öffentlich bekannte Adressen. Zusätzlich zu der öffentlichen Adresse hat jeder Benutzer einen privaten (geheimen) Schlüssel mit dem er Transaktionen in Ethereum signieren kann.

Welche Möglichkeiten würden sich ergeben, wenn die Behörde bei der Ausstellung eines neuen Personalausweises für alle Ausweisdaten (Name, Vorname, Geburtsdatum, Adresse, …), einen Hash-Wert berechnen und in einem öffentlich zugänglichen Identitätsverzeichnis an die Ethereum-Adresse des Kartenbesitzers binden würde?

In Ethereum kann man so ein Identitätsverzeichnis mit wenigen Codezeilen durch den folgenden Contract abbilden:

contract IdentityRegistry {
    address owner; // Der Besitzerer der Registry (die Behörde)
    string name;   // Der Name der Registry
    // Abbildung von Ethereum Adresse
    // zu dem Hash-Wert der Personalausweisdaten
    mapping(address => uint256) idHashes;  
    // der Konstruktor wird einmalig beim Anlegen des Contracts ausgeführt
    function IdentityRegistry(string _name) {
        owner = msg.sender;   // hier merken wir uns den Contract-Ersteller als Besitzer
        name = _name;         // den Namen der Registry setzen
    // Liefert den Namen der Registry, verändert nicht den Zustand
    function getName() constant returns (string) {
        return name;
    // Beschreibt wie der Hash-Wert für die Daten gebildet wird
    // Alle Informationen werden durch "/" getrennt, hintereinander abgelegt
    // Es wird SHA-1 Hashwert der Zeichenkette berechnet
    function getIdHashFormat() constant returns (string) {
    // Diese Methode kann nur von dem Besitzer (Bürgeramt) aufgerufen werden.
    // das "throw" rollt die Transaktion zurück, wenn die Transaktion
    // nicht vom Besitzer der Registry (Bürgeramt) aufgerufen wurde.
    // Die Funktion bindet den Hash-Wert an die Ethereum Adresse des Ausweisbesitzers
    function registerIdHash(address who, uint256 hash) {
        if(owner != msg.sender) throw;
        idHashes[who] = hash;
    // Wird vom Gegenüber (z.b. Bank) aufgerufen, um den Hash-Wert einer
    // Ethereum Adresse zu überprüfen
    function verifyIdentity(address who, uint256 hash)
    constant returns(bool) {
        return idHashes[who] == hash;
    // Falls keine der oben definierten Methoden aufgerufen wurde,
    // sorgt diese Funktion, dass die Transaktion zurückgerollt wird.
    function() {

Beantrag beispielsweise Max Mustermann, geboren am 01.01.1990 aus Musterstrasse 12, Musterhausen den Ausweis, berechnet das Amt zunächst den Hash-Wert aus allen oben genannten Daten, z.B.:

sha1("MUSTERMANN/MAX/01.01.1990/MUSTERHAUSEN/DEUTSCH/MUSTERHAUSEN/MUSTERSTRASSE 12") = 1417400950720517943593210833135938663929334829119

Dieser Hash-Wert wird anschliessend vom Amt im Identitätsverzeichnis an Maxs öffentliche Ethereum-Adresse (0xDBEc37…) gebunden, z.B.:


Hierbei ist es wichtig anzumerken, dass aus dem Hash-Wert der Daten keine Rückschlüsse auf die Daten selbst gezogen werden können.

Möchte Max ein Konto bei der Musterbank eröffnen, könnte er nun über ein Onlineformular der Musterbank seine persönlichen Daten eingeben und zusätzlich seine öffentliche Ethereum-Adresse senden. Mit diesen Informationen kann die Musterbank bereits überprüfen, ob der Datensatz korrekt ist. Genauso wie das Bürgeramt, berechnet die Musterbank den Hash-Wert und vergleicht diesen mit dem Hash-Wert aus dem Identitätsverzeichnis des Bürgeramts. Z.B.:

bool res = identityRegistry.verifyIdentity(

Damit ist überprüft, ob der Datensatz valide ist, aber noch nicht ob Max auch der tatsächliche Absender der Information ist. Um auch das zu überprüfen, instantiiert die Musterbank einen weiteren Contract auf Ethereum und wartet darauf, dass Max mit seinem privaten (geheimen) Schlüssel die Bestätigungsmethode aus dem Contract aufruft und damit beweist, dass er tatsächlich der Besitzer des Ethereum Kontos mit der öffentlichen Adresse 0xDBEc37… ist. Der Contract sieht wie folgt aus:

contract IdentityConfirmation {
    address createdBy;    // Ersteller des Contracts (Musterbank)
    address who;          // Wer soll sich identifizieren (Max)
    bool confirmed;       // wurde die Identität bestätigt?
    // dieses Event wird verschickt,
    // wenn Max die Funktion "confirm" aufruft
    event IdentityConfirmed(address who);
    function IdentityConfirmation(address _who) {
        who = _who;
        createdBy = msg.sender;
        confirmed = false;
    // wenn die Methode von Max aufgerufen wird, d.h.,
    // der Aufruf mit dem privaten Schlüssel von Max signiert wurde
    // bekommt die Musterbank die Bestätigung über
    // die erfolgreiche Authentifizierung
    function confirm() {
        if(who == msg.sender) {
            confirmed = true;
    function() {

Anbei der gesamte Vorgang zusammengefasst in einem Sequenzdiagramm:

Sequence Diagram

Weitere Überlegungen

Das vorgestellte Konzept ist eine grobe Skizze. Ein produktives System bräuchte noch weitere Feature wie z.B Aktualisierung / Sperrung / Entsperrung des Eintrags im Umzugsfall oder beim Verlust des privaten Schlüssels bzw. beim Ablauf des Ausweises.

Falls die Behörden nicht die Blockchain-Technologie adaptieren sollten, kann man sich auch folgende Alternativen vorstellen:

  • Es existiert ein Intermediär vergleichbar zu idnow, der den Aufbau des Identitätsverzeichnisses übernimmt und den Dienst gegen Gebühr anbietet.
  • Das Identitätsverzeichnis wird innerhalb des Konsortiums/Verbands aufgebaut und benutzt.

Schließlich wäre noch zu untersuchen, ob man mit dem privaten Ethereum Schlüssel außerhalb von Ethereum Daten signieren kann (public/private-key Verfahren). Das würde den zweiten Contract überflüssig machen.

Book Review – “Cryptocurrency: Wie virtuelles Geld unsere Gesellschaft verändert” von Michael Casey und Paul Vigna

Anfang Februar ist das Buch „The Age of Cryptocurrency“ in der deutschen Übersetzung erschienen. Die Gretchenfrage bei einem Buch mit 400 Seiten ist: Soll ich die Zeit investieren es zu lesen ?

Anzugträger: ja
IT Coder: optional
Auf einer Scala von 1 bis 10 bekommt das Buch von mir eine 6.

Die Autoren sind Journalisten, keine Techis. In dem Buch findet man keine wirkliche Beschreibung wie Bitcoin und Blockchain in der Tiefe funktionieren. Die Autoren sind eher der Meinung, dass es nicht notwendig ist die Wirkungsweise eines Ottomotors zu verstehen, wenn man Auto fahren will.

Gut gefallen hat mir die Darstellung, dass jeder, der sich mit den Bitcoins beschäftigt 5 Phasen der der „Kryptoakzeptanz“ durchläuft: Geringschätzung – Skepsis – Neugierde – Verständnis – Akzeptanz. Der Leser wird im Laufe des Buches seine eigene Position wahrnehmen und vermutlich eine Treppenstufe höher steigen.

Anhand von vielen bunten Geschichten, werden sinnvolle Anwendungsgebiete des Bitcoins beschrieben. Bitcoins lösen in vielen Ländern ohne stabiles Banken- und Währungssystem Probleme die es in Deutschland so gar nicht gibt. Was durchaus dazu führen kann, dass man links von anderen Ländern überholt wird. Beispiel China: dort gibt es Unternehmen, deren Unternehmenswert über Blockchains gehandelt werden und die Zentralbank arbeitet an einer eignen Blockchain.
Generell ist das Buch sehr Bitcoin-lastig. Die englische Version des Buchs ist ein Jahr älter, vor dem Hintergrund ist es verständlich das Beispiele für Smartcontract Anwendungen noch weniger konkret behandelt wurden. Ripple oder Ethereum werden am Rande erwähnt.

Im Buch sind persönliche Erfahrungen des Autors verarbeitet, der einige Zeit in Argentinien gelebt hat und selber erfahren musste welche Einschränkungen man in einem bankrotten Land ohne funktionierende Währung unterlegen ist.

Die Autoren holen sehr weit aus. Sie gehen auf die Entstehung des Geldes ein und auf die Fragestellung was Geldscheine wertvoll macht, oder warum Gold einen hohen Wert hat. Wenn man darüber nachdenkt, dass ein Geldschein auch nur ein Schuldschein des Staates ist, relativiert es doch das ein oder andere. Auch war es ein geschickter Kunstgriff von Satoshi bei Bitcoins in Analogie zum Gold das Minen einzuführen.

Des weiteren wird die Bitcoin Historie inklusive der Vorgänger und der Cypherpunk Bewegung beleuchtet, ich fand es spannend anschließend im Bitcoin Blog die Posts von Satoshi nachzulesen. Es erscheint so als wenn Satoshi, oder wie auch immer die Person oder Gruppe heißt, nur geschickt bekannte Ideen neu zusammen geführt hat. Die Zeit war nach dem Crash 2008 einfach reif für ein dezentrales System ohne Banken. Eine Erfindung wie Bitcoin erscheint als eine unausweichliche logische Notwendigkeit.

Den visionäre Schlussteil kann man sich sparen. Hier wagen sich die Autoren nicht, konkrete Prognosen zu treffen. Sie zeigen nur mögliche Szenarien auf.

Wir stehen ganz am Anfang des Umgangs mit dezentralen Anwendungen, Werten und Unternehmen. Man hätte auch die Ingenieure, die die ersten Computer mit Netzwerkkabeln verbanden nach Facebook fragen können. Dabei wollten sie nur, ohne ein Speichermedium von A nach B tragen zu müssen, Dateien kopieren können.

Zusammenfassend kann man sagen, das Buch ist gute amerikanische Unterhaltung, die man auch im halb wachem Zustand, oder am Strand verdauen kann. Faktenorientierte Leser wären mit einer auf 20 Seiten komprimierten Version zufriedener, aber die kann man schlecht für den gleichen Preis verkaufen. Es reiht sich ein in die Reihe der netten Bücher, die in bunten Bildern Wirtschaftsjournalismus betreiben. Die Qualität von „Cybercurrency“ ist nicht vergleichbar mit Christensens „Innovator’s Dilemma“ oder Ries „Lean Startup“. Also liebe Autoren es ist noch Platz ein wirklich gutes Business Buch über Bitcoins und Blockchains zu schreiben, bis dahin lesen wir dieses.

— Andreas Albrecht