If you ever come to the conclusion, for whatever reason, that pushing Excel data to the Blockchain is what you need, we are happy to help!
We recently read about the Azure Blockchain Development Kit and had to cringe about the samples. But, who are we to judge those important enterprise business use cases requiring to get data from Excel to the Blockchain?
Therefore, we took a look at the prerequisites, setup, initialisations and finally the execution of this with the new Microsoft Azure templates. And, to be clear, we love the idea of Microsoft getting involved into Blockchains and Ethereum and pushing Azure as a starter kit, that’s really great.
However, the whole procedure seemed quite long and exhaustive, that’s why we want to show how easy this is with standard development methods. Of course, these are lacking a lot of features and cool stuff you get with Azure then. But, they can help you to understand better what happens under the hood. So, let’s go for it.
No, wait, Excel to Blockchain, honestly? Why?
//TODO: Insert suitable reason here.
Ok then, but how?
Due to web3j it is really easy to connect to an arbitrary Ethereum Node, even Infura and Ganache, as simple as it is with web3.js or web3.py. All the other stuff is common Java dev tools, like Glueing with Maven, Excelling with Apache POI, etc. This is where Java shines, it’s really good at enterprisey integration stuff.
You can start directly and import the sources as a Maven project in your IDE or build it without an IDE and start it from the command line. See the details here.
As you can see, ExcelStorage is a class which can used like any other Java class. It has been generated by a Maven plugin (web3j-maven-plugin) during build time. It is statically typed with methods resembling the Solidity functions of the smart contract and with all the nice aspects this has: compile time checks instead of runtime checks and brilliant IDE support (code completion, type checking, static code analysis).
With great IDE and build tool support, you can try this out yourself, you will be surprised how lightweight and easy Ethereum smart contract usage is from Java. Even more, integration with your existing (“legacy”) software and infrastructure is straightforward.
Have fun!
Addendum: This is a Testsetup only! What about the real Blockchain?
Where does the private key in the current Java sources come from? If you start Ganache with the mnemonic mentioned, everytime the same accounts are generated. The first one being 0x627306090abaB3A6e1400e9345bC60c78a8BEf57. This address has one private key which is set into the Java sources to create the Credentials for contract deployment and transactions.
This post is inspired by the book with the same title, which we found in in this nice summary post by Alex Preukschat. In that blog post and especially in the book you will find all information about Self-Sovereign Identity. We will only refer to the concepts if they are feasible for our samples.
This is not a Blockchain-bullshit-only post. Head to https://github.com/ice09/identity for a sample implementation of the “federated” claim issuer sample.
The Story of Alice, Booze and her local Bank
Alice just turned 18 years old, being in good ol’ Germany she wants to celebrate this with a lot of booze, but her parents refused to buy it for her, since she can do this on her own now.
Currently, she can do this easily by showing her identity card when buying the drinks. The dealer would check her birthdate and verify her age.
This obviously has major shortcomings:
The ID could easily be altered, stolen or otherwise not belonging to the person showing it
The dealer gets a lot more information than necessary for this transaction, including a lot of sensitive personal data: name, address, height, etc.
So, the dealer would just have to verify that the person is older than 18 years, how could this work with Alice and eg. her local bank?
The book differentiates between identity and statements about this identity (claims), which entitle the person to do things. In our example, the fact that Alice turned 18 years old entitles her to buy and drink alcohol (in certain legislations). However, showing the identity card to the dealer mixes up two aspects very badly: the dealer has to check the identity information to derive the entitlement. This he has to do by himself, if for whatever reason (eg. the dealer not being able to calculate the age) he cannot derive the entitlement, Alice’s intention would be rejected. Also, only information which can be derived from the identity information can be used, if eg. Alice would be incapacitated and therefore not allowed to buy alcohol, the dealer wouldn’t know, since this information is not stated on her identity card.
In the world of cryptography and decentralized data storage (read: DLT), Alice’s bank could easily help her with an identity or better: entitlement verification service. Since Alice participated at the bank’s KYC process, the bank has a lot of information about Alice, one of these being her age. Now, if the local bank is trusted by the shop owner, this information would be enough for the owner: “As your local trusted bank, we verify that this customer is older than 18 years.”
Setup for Ethereum
In Ethereum, the easiest setup would be to use ERC 725/735. These standards (requests) provide all necessary equipment for identity creation and claims/endorse mechanism. Other standards and products are provided by uPort and standard bodies like the W3C DID.
The initial setup Alice has to execute, together with the claim issuers like the bank, a utility provider, an insurance company, etc. consists mainly of three steps which could easily be embedded into a mobile app:
Alice creates an identity ERC 725/735 (which might be one of multiple identities she has)
As a claim issuer, the bank adds a claim (using ERC 735 addClaim(…)) about Alice being older than 18 years. This claim is signed by the private key of the bank. The claim is stored with a returned ID and must be approved by Alice (1, 2).
Alice approves (using ERC 725 approve(claimId)) the bank’s claim on her identity.
Now, anyone can verify the claim about the topic she is interested in, eg. the fact that the identity is older than 18 years (4).
After the setup the process of verifying a claim is depicted below:
Alice signs a challenge of the shop owner with her private key (3).
With the derived public key of Alice, the shop owner can identify the claim in ERC 735 and check the signature of the trusted party, which is Alice’s bank (4), against the publicly available public key of the bank.
This would make a great use case for banks desperately looking for their next Blockchain use case: forget about value transfer, asset creation, settlement and whatnot, you are fighting against proven and established systems which might be embedded in complex processes but have been running stable, reliable and performant for years.
Identity verification on the contrary could be a completely new service offering and banks have the great advantage of having identified thousands of customers in strongly regulated processes, they have valuable data at their hand. The same is true for insurances, mobile providers, utility providers, governmental companies, etc.
But let’s say we want to decentralize even more, how could we go on?
Incentivizing Identity Verification
Couldn’t we incentivize people for doing something only they are able to do right: prove the identities of their social network?
There are some assumptions:
People know their social environment best, especially their direct environment like family, best friends and neighbors.
People want to earn (even few) money with something they – and only they – can do easily following a simple procedure
The process is almost equal to the process above, except that notaries are slashed if they defraud and earn fees if they behave according to the protocol. The slashing is complex and would have to be implemented by some governance mechanism. This step adds complexity, but is solvable and will be very similar to PoS. Most likely there will be a incentivization for detecting and proving fraud included into the protocol.
Incentivization is a great means for getting anonymous parties to agree on a fact. This works great for Blockchains and has also been proven theoretically by eg. game theory and the Nash equilibrium.
Therefore, with incentivization of notaries, their advantage of doing fraud is minimized.
Build a Social Network based on Trust
Trustlines is a decentralized, permissionless, open platform to host currency networks in which money is represented as IOUs issued by its participants. Trustlines implements money as bilateral peer-to-peer issued blockchain-based credit.
In the example above Bob gave Alice a creditline of 20 EUR and Alice Bob of 100 EUR, so they have bilateral creditlines which is a trustline. Bob gave Charly 30 EUR credit and Charly Bob 50 EUR. Now if Alice wants to pay Charly, whom she doesn’t know personally, the system finds a path between Alice and Charly (via Bob) and the creditlines will be used. If Alice pays Charly 10 EUR, Bob afterwards owes Charly 10 EUR and Alice owes Bob 10 EUR. The creditlines have been used and the remaining credit is lower or higher, depending on the direction of the payment.
There is no settlement in the system, if it is necessary or wanted by some party to settle, this is done outside of the system and then reflected in the system by an opposite transaction.
More information about the project is available on trustlines.network, we encourage you to inform yourself about its concepts of people powered money and complementary currencies and its potential to boost cryptocurrencies adoption and enhance accessibility for cryptocurrencies for all people.
Extra Trustlines Benefit: Socially proven Identity
However, for this blog post, a secondary aspect of Trustlines is more important: if you have a social network of trust, you have a social network of identities. This is immediately obvious by the simple fact that if you trust someone with a certain amount of money, you certainly know and trust this person, because you are in risk of losing money if your creditline is used. Depending on the social context this can be family members, good friends, co-workers and the amount of credit you give will mirror your amount of trust in these people.
Given a network with creditlines, people will most likely have creditlines with different people and a identity (and reputation) algorithm could value the amount of credit given and the number of creditlines for a probabilistic identity verification.
This might even be pseudonymous, as someone offering a service for money, I am most interested in a receiver to pay me money, which is related to his trustworthyness and therefore to the amount of creditlines given, not so much who this person actually is. If 10 people who have medium sized networks of creditlines have creditlines with the receiver, I am tending to assume that:
This person actually exists
This person is trustworthy for some amount to other people
For now, this is the only attribute of identity which Trustlines helps solving, but with very high accuracy: if a person actually exists and that this person is trustworthy to some degree.
We won’t have information about other identity attributes like gender, age, wealth, educational degrees and so on.
Let’s fix Identity now!
If you didn’t know a good use case for Blockchain technology, now you have it. This is one of the most natural use cases for a decentral, immutable database accessible by everyone without central control and the possibility to incentivize people.
This is a win for all involved parties, enhancing privacy and security and enabling service providers to make use of their already available data. As there is no “disruption” of any existing business model, but a creation of a completely new one, public identity management can only get better.
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.
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.
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{ enumStages{
Init,
AccountOpened,DepositOpened,
DepositConfirmed,AccountConfirmed}Stagespublicstage=Stages.Init;modifieratStage(Stages_stage){if(stage!=_stage)throw;_}functionnextStage()internal{stage=Stages(uint(stage)+1);}// Order of the modifiers matters here!function openAccount()atStage(Stages.Init) transitionNext{
if (msg.sender != FRIENDLY_BANK) throw;
}functionopenDeposit()atStage(Stages.AccountOpened) transitionNext{ if (msg.sender != FRIENDLY_BANK) throw;} function confirmDeposit() atStage(Stages.DepositOpened) transitionNext { if (msg.sender != DEPOSIT_BANK) throw; } modifiertransitionNext(){_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:
Account is opened
Deposit Account is opened
Deposit Confirmed
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:
Account is opened
An Email is send to whoever feels responsible
The Product Owner’s Excel has to be updated
The new reporting engine must have its data updated, it is runnig with MongoDB, which has to be updated
Revision wants to have it’s auditing data in their Oracle DB (must use 2PC)
… (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.
How to create a provably-fair high risk financial product with live data feeds provided by oracles.
Introducing Binary Options
This time, we gonna gamble. We will construct a financial product, more specifcally: a binary option, European style, cash-or-nothing.
[binary*]
Binary options are “a type of option in which the payoff is structured to be either a fixed amount of compensation if the option expires in the money, or nothing at all if the option expires out of the money” [1], therefore cash-or-nothing. European style means the option “can only be exercised at the end of its life, at its maturity” [2].
This is a high risk product which is “most likely traded over the Internet on platforms existing outside of regulations” [1], so “the customer is betting against the broker, who is acting as a bucket shop.” [3]
In general, this means that “because these platforms operate outside of regulations, investors are at greater risk of fraud” [1] and “manipulation of price data to cause customers to lose is common” [1].
So, in contrast to common regulated financial products we have a really comprehensible option, which is mostly valued as high-risk, because there is a real clash of interests if the broker also evaluates the stock against the strike price and thus is highly motivated to manipulate this evaluation.
Smart Contracts to the Rescue
So, can smart contracts help here? You bet! The blockchain is trust-less, so you just don’t have to trust anyone, be it broker or bucket shop or both, but you can just prove if everything’s ok.
If a smart contract guarantees you that you will get 195% if you predict correctly and 0% if not, this rule has to be implemented in the contract.
Meeting the Oracle
Given that we can trust the contract, it should be easy to implement a binary option like this:
After deploying the contract, you have 1 hour to invest Ether on calls or puts on the contracts conditions (eg. DAX is above the strike price in 1 hour). After the 1 hour offering period, it's rien ne va plus, no purchase of calls or puts are possible. At this point of time, the current value of the DAX is stored. After exactly 1 hour the DAX is evaluated against the stored DAX value.
if the value is above or equal to the stored value, all calls are returned 195% of their investment, all puts lose all invested money
if the value is below the stored value, all puts are returned 195% of their investment, all calls lose all invested money
Sounds simple? It is!
[oracle*]
You can easily prove that the contract actually implements the described rules, but there are two problems: how does the contract know the DAX spot? Contracts in Ethereum intentionally cannot connect to the outside world, therefore the outside world has to call the contract and provide the necessary data. Who tells the contract the exact time it has to retrieve the DAX spot? There must be some callback mechanism, since Ethereum smart contracts are not able to call themselves, have a Daemon, Threading etc.
Let’s gonna oraclize.it
There is a startup solving this problems in a elegant way: oraclize.it
You should look up and understand how oraclize.it works and helps us to solve our problems. In short, callbacks are used by oraclize.it and you can determine the exact data feed of the data which oraclize.it will provide at a certain point of time to our contract.Here the two problems are addressed:
The contract has to provide a callback for the oracle to call. The data feed is configured when the callback is provided, as well as the time interval.
The oracle facilitates a scheduling to call the provided smart contract callback at the configured time interval.
Both solutions require the user and the contract owner to actually trust the “trusted datasource” (the contract’s user can decide if he trusts this datasource) and the oracle itself to have a working scheduling and not to manipulate the data. In contrast to the “broker” above, the oracle has no interest in manipulating the data.
However, oraclize.it not only offers a service, but even more defines a protocol, so there will most likely be more than one oracle to choose from to offer redundancy in the future.
Building Binary Options in Ethereum Studio
…in the next post.
Realizing how long this post already is, we decided to split the tutorial and the theoretical part. The tutorial will follow soon! Please let us know in the comments if you’d like to have this tutorial and what you expect of it.
Meanwhile, try out this ether.camp tutorial which describes the integration of oraclize.it into Ethereum Studio.
Nach der Entdeckung der neuen Welt und dem Überwinden der ersten Hindernisse wollen wir uns nun sesshaft machen und anfangen, Applikationen und Smart Contracts jenseits von “Hello World” zu entwickeln.
Aber wie fangen wir an? Die ersten Erfahrungen mit dem fantastischen Tool cosmo.to waren viel versprechend, leider ist das Tool mittlerweile online nicht mehr verfügbar. Der wahrscheinliche Grund ist die Tatsache, dass das Standard-Ethereum-Wallet von ethereum.org die gleiche Funktionalität und noch viel mehr bietet. Allerdings zu Lasten der Übersichtlichkeit.
Wir wollen deshalb hier einen Überblick der bekanntesten Entwicklungsumgebungen geben, mit einer subjektiven Einordnung in Architekturstile:
Minimalismus: minimal, übersichtlich, aber auch schlicht: der Solidity Browser. Super zum Erlernen der Sprache Solidity, aber das war’s dann auch schon. Persistierung? Versionierung? Alles nicht vorgesehen. Super für den Einstieg.
Bauhaus: funktional und praktisch: das Ethereum Wallet dient nicht nur als Wallet selbst, sondern ermöglicht die Erstellung und das Deployment von Smart Contracts und die Verwaltung von eigenen Tokens.
Gotik: opulent, gut strukturiert, mächtig: Truffle ist ein reines Javascript-Framework und verwendet alle Komponenten, die moderne Javascript-Entwicklung bietet: Gulp, Mocha, Chai, etc. Sehr gut dokumentiert, ebenfalls gut für den Einstieg geeignet, bietet darüber hinaus aber auch viel mehr.
Kubismus: ganz anders, aber erfolg- und einflussreich: die Entwicklungsumgebung von Microsoft, Visual Studio (Community) oder der neue Open Source Editor Visual Studio Code zusammen mit BlockApps STRATO, einer zentralisierten Blockchain. Leicht zu nutzen, mit automatischer Frontenderstellung. Etwas für den anderen, schnellen Einstieg in private Chains mit Microsoft Azure.
Dekonstruktivismus: das “new kid on the block”, das Ethereum Studio von <ether.camp> macht alles etwas anders, nach unserer Meinung auch besser: eine verteilte Entwicklungsumgebung auf Basis von cloud9, ein integrierter Sandbox-Ethereum-Node, eine Deploymentmöglichkeit in alle möglichen Umgebungen (die JSON-RPC verstehen). Leider auf Dauer nicht kostenlos, Preise sind noch nicht bekannt.
In den nächsten Wochen werden wir die hier erwähnten (es gibt noch zahlreiche andere!) Entwicklungsumgebungen genauer testen, immer mit dem gleichen Tokenbeispiel. Stay tuned!
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) {
return "sha-1(NAME/GIVENNAMES/DATEOFBIRTH/PLACEOFBIRTH/NATIONALIY/ADDRESS1/ADDRESS2/ADDRESS3)";
}
// 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() {
throw;
}
}
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.:
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(
0xDBEc371775c57f59fDA5BBa2c9FC8876968F34E3,
1417400950720517943593210833135938663929334829119)
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;
IdentityConfirmed(msg.sender);
suicide(createdBy);
}
}
function() {
throw;
}
}
Anbei der gesamte Vorgang zusammengefasst in einem Sequenzdiagramm:
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.
![[casino kurhaus*]](http://blockchainers.org/wp-content/uploads/2016/06/16135779895_fdea2ef33c_z-e1465673411204.jpg)
So, in contrast to common regulated financial products we have a really comprehensible option, which is mostly valued as high-risk, because there is a real clash of interests if the broker also evaluates the stock against the strike price and thus is highly motivated to manipulate this evaluation.![[oracle*]](http://blockchainers.org/wp-content/uploads/2016/06/5822220225_0af0d40df4_m.jpg)
Here the two problems are addressed: