Blockchain + Streaming Analytics = Smart Distributed Applications

We are really pleased to publish a guest contribution by Kai Wähner about Smart Distributed Applications.
Kai is Technology Evangelist and Community Director for TIBCO Software. His expertise lies within the fields of Big Data, Advanced Analytics, Machine Learning, Integration, SOA, Microservices, BPM, Cloud, Internet of Things, Blockchain and Programming Languages such as Java EE, Scala, Groovy, Go or R. He regularly writes about new technologies, articles and conference talks on his blog.

We are approaching Blockchain 3.0 these days. You ask “3.0”? Seriously? Blockchain is still in the early adoption phase! Yes, that is true. Nevertheless, while we are moving forward to real world use cases in various industries, we see that you need more than just a blockchain infrastructure. You need to build decentralized applications. These include blockchains, smart contracts plus other applications plus integration and analytics on top of these solutions.

Middleware is Key for Success in Blockchain Projects

Blockchain is the next big thing for middleware! There is no question around this. You need to interconnect other applications, microservices and cloud offerings with a blockchain infrastructure to get real value out of it. In addition, visual analytics and machine learning have to be leveraged to find insights and patterns in blockchain and non-blockchain data. Finally, streaming analytics is used to apply these insights and patterns to new events in a blockchain infrastructure. There is a variety of use cases like fraud detection, compliance issues, optimization of manufacturing or supply chain processes, or any kind of scenarios with the Internet of Things (IoT).

Reference Architecture for Blockchain and Middleware

Variety of Blockchain Platforms including Hyperledger and Ethereum

The blockchain market is growing significantly these days. You need to think about various blockchain characteristics for your next blockchain project.

  • Who are the users of the blockchain? Is it public or private? Which partners do you need to work with?
  • Do you want to build your own blockchain infrastructure (based on a framework such as Hyperledger and one if its implementations like IBM’s Hyperledger Fabric, Iroha, Intel’s Sawtooth Lake) or leverage an existing platform (like Ethereum)?
  • Do you want to host the infrastructure yourself or leverage a cloud service like IBM’s Bluemix with focus on Hyperledger or Microsoft’ Azure with focus on Ethereum?
  • What development environment and tooling do you want to use (like Truffle or BlockApps on top of Ethereum)
  • Which characteristics are important for your scenario? What about speed, security, consensus algorithms, integration of non-blockchain services, and other important aspects? Maybe an add-on on top of a blockchain is needed, like the Raiden Network to leverage off-chain state networks to extend Ethereum with some nice properties like scalability or high performance for asset transfers?
  • Or do you want to focus on a industry-specific blockchain solution like R3 Corda or Ripple for financial services?
  • What middleware do you need? Do you need Application Integration or API Management to interconnect everything? Visual Analytics to find insights and patterns in historical blockchain data? Streaming Analytics to apply rules to action in (near) real time for new blockchain events?

The following shows how to leverage Streaming Analytics together with blockchain events. This example uses TIBCO StreamBase in conjunction with the public Ethereum test network. Note that similar scenarios can be build with any other blockchain infrastructure. A follow-up post about how to leverage middleware with Hyperledger will come soon, too.

Streaming Analytics for Correlation of Blockchain and Non-Blockchain Events

The scenario uses a Smart Contract to define a Coin system. You can mine coins and transfer them to other users (i.e. blockchain addresses). This example is similar to Bitcoin concepts to show how to leverage streaming analytics with any custom blockchain application and smart contracts. The goal is not to show the power of smart contracts (other articles are available for this). The programming language used to develop this Smart Contract is Solidity; more or less the de facto standard to write smart contracts for Ethereum.

Here is the Smart Contract built and deployed with Browser Solidity:

Smart Contract ‘Coin’ developed and deployed with Browser Solidity

MetaMask, a bridge to run Ethereum dApps in your Chrome browser, is running in the background to connect to the Ethereum network and commit the transactions developed with Browser Solidity. You could also use Streaming Analytics to deploy smart contracts, of course. However, in this example TIBCO StreamBase was only used for the following two parts:

  • Receive new events from the blockchain network: You can filter, aggregate, analyse or transform any events like pending transactions, logs or blockchain blocks – and also combine this information with non-blockchain events, of course. For example, you could build a streaming analytics process to analyze just the logs relevant for your specific transaction IDs to spot issues and act proactively, let’s say if a pending transaction takes too long or fails.
  • Execute transactions on the blockchain network via smart contracts: You can mine new coins, send coins to other blockchain addresses and also check the balance of an address. Anything what the smart contract allows can be included into the streaming analytics process.

The streaming analytics process monitors all Ethereum events continuously. This is not as trivial as you might know it from classical messaging systems. You cannot just listen to a topic or queue, but you have to pull information out of the blockchain. Depending on the use case, you have to implement some solution which solves your problem but also does not consume too many resources. This is always a trade-off, which has to be thought through when building your streaming analytics process. This also highly depends on the blockchain infrastructure you use and its feature set.

Please note that security considerations are not part of this example. In the real world, you would integrate encryption and other security requirements into the streaming process, of course. In this demo, we use “hardcoded” private keys for sending transactions. A no-go in a real world project.

Let’s now take a look at an implementation of this process.

TIBCO StreamBase + Ethereum Blockchain

Here is the demo setup:

Architecture with TIBCO StreamBase + Ethereum Blockchain

The Ethereum test network is a distributed peer to peer ledger. It runs on various Ethereum clients. We used one of the most mature ones on our local laptop: The geth client implement in Golang. This is synced and also part of the Ethereum test network.

TIBCO StreamBase is used to build the streaming analytics process:

TIBCO StreamBase Connectors for Ethereum

The web3j Java API is used to connect TIBCO StreamBase with the Ethereum network through our local geth client. You just need to write the connector once and can reuse it in all your streaming processes via drag&drop and configuration. These behave “just” like any other connector (such as messaging via MQTT or Apache Kafka)  and components to build streaming logic (like filter, aggregate or transform).

For more details, please check out my live demo of combining streaming analytics and Ethereum blockchain

Building this process was actually a pretty easy task with TIBCO StreamBase. In the same way, you can build much more sophisticated blockchain processes in your real world project. Let’s also think about some other next steps.

Next Steps: Application Integration, API Management, Machine Learning, and more

A real world blockchain projects needs streaming analytics to correlate blockchain and non-blockchain events to fight fraud or compliance issues, to improve efficiency in manufacturing or supply chain processes, to combine Internet of Things with blockchain infrastructures, and for many other use cases.

Though, Streaming Analytics is just one piece of the puzzle. Here are some more thoughts about why you might combine blockchain with middlware and analytics:

  • Live Visualization for Real Time Monitoring and Proactive Actions
  • Cross-Integration with Ethereum and Hyperledger Blockchains
  • Data Discovery for Historical Analysis to Find Insights and Patterns
  • Machine Learning to Build of Analytic Models
  • Application Integration with other Applications (Legacy, Cloud Services, …)
  • API Management to expose blockchain services and handle caching / throttling challenges
  • Native Hardware Integration with Internet of Things Devices

I will do more posts about these ideas and show more live demos in the next weeks and months. In the meantime, first customer projects also kicked off, already. Blockchain and middleware have a great and interesting future…


Blockchain, Ethereum, Hyperledger, Middleware, Integration, Streaming Analytics, TIBCO, StreamBase, Live Datamart, Smart Contracts, Cloud, web3j

Marketing usecase based on blockchain

This week I stumbled upon the following article:

Liverpool gets its own currency 

The company colu from Tel Aviv  has generated a local digital currency for Liverpool. Local currencies are not new. Many municipalities use some kind of local coupons to buy in the suburb, often linked to local festivals that take place in limited periods.

To map such actions digitally so far was extremely complicated and finally not done, since it’s technical to complicated so you quickly missed any ROI. With a public blockchain comes almost everything therefore what you need. It still lacks a nice front end for the user and for the point of sales, that’s it.

The costs for the infrastructure go against zero, the investment costs are very low and the system is safe.

If you thinks about this use case, you quickly come to the conclusion that you can simplify various marketing processes with blockchain technology. In some countries, less in Germany, couponing is a huge business. Customers collect coupons in advertising or cut out from newspapers and get a discount at the supermarket checkout for special items. You can save a lot of infrastructure by mapping this with the blockchain.

As a rule, these data are collected and analyzed with marketing databases. If you link the use case with the preceding “claim to endorse” article, you can see that you can not only manage coupon values, but also assign these to the registered users.

In order to depict such systems conventionally large databases are necessary, the blockchain reduces the most infrastructural costs dramatically.

The couponing example can be perfectly combined with the customer card idea, which is no longer physical output, but only as a wallet that would make the processes really slim and fast.

Marketing based on blockchain is in a really undeveloped early state, it has the potential to become the blockchain killer use case. 

An overview of the blockchain universe

The blockchain universe is evolving very fast. New products and platforms are announced daily. This post should help you to get a rough overview about the existing blockchain technologies.

wich BC.001

I categorize the blockchain technologies into 3 tiers:

tier 1The market leaders.Bitcoin, Ripple, Ethereum
tier 2The challengers, upcoming blockchains where we see the potential to reach tier 1 during the next 6 month.Hyperledger, Quorum, Stellar
tier 3Promissing technololgies and conceptsMonero, Corda


Tier 1:

Main application areavalue transfer, crypto-currency
Characteristicsstable, secure
Consensusproof of work
Governanceopen source, 5 committers, non commercial
DescriptionBitcoin is the first blockchain implementation. The network has started in 2009 and the consensus mechanism has not been hacked yet, despite countless attacks. Bitcoin does not support smart contracts like Ethereum do, however, it offers limited scripting possibilities, which haven been applied in various Bitcoin extensions (e.g. Coloured Coins).

Very often we hear the criticism about performance of the Bitcoin blockchain, the lightning networks shows a possible solution.

In any case, everyone new to blockchain should put his hands on bitcoin and try it at least. The book of Andreas Antonopoulos gives a good introduction to it.
Main application areacurrency independent money and security exchange
Consensusprobabilistic voting consensus
Governanceopen source managed by Ripple Labs
DescriptionThe ripple concept is based on IOUs and trust relations between network participants. For instance, if a person B trusts that a person A will pay his debts, and C trusts that B will be paying his debts, A will be able to send money to C by introducing following debts (IOUs): 1) A owes money to B, 2) B owes money to C. The network is only managing the ledger of IOUs, the concrete payment is done outside of the network. Moreover, Ripple offers a FX market for transferring between currencies. The FX is offered directly by Ripple. The idea of the systems is, to always use the cheapest liquidity provider.

Ripple is used by several banks as an alternative for the classic correspondent bank based international money transfer. The implementations I looked at still look experimental.
Main application areaprogrammable blockchain (smart contracts)
Characteristicsflexible smart contract implementation
ConsensusProof of Work, Proof of Stake in preparation
Governanceopen source, maintained by a foundation
DescriptionEthereum is the leading smart contract platform with a turing completed virtual machine. This means that you can implement every kind of algorithm in this smart contract. If you hear the first time about smart contract concepts, it's a little bit complicated to understand the universal power of this kind of tool. The members of the foundation call it the “world computer”. If you think of the bitcoin blockchain as a large distributed Excel spread sheet, Ethereum would be like having the ability to script every single cell of your spread sheet. Disadvantage of this flexibility is that Ethereum has a large attack surface as we already experienced by recent attack. The good news is that the consensus algorithm didn't fail yet at any point in time.

It is not recommended to implement complex algorithms in Ethereum. Every execution step costs a predefined amount of gas and is much more expensive than the cost of your own CPU at home. It is easy to prototype your own ideas with Ethereum.


Tier 2

Interesting links
Main application areano specific
Characteristicsblockchain tool box
Gouvernanceopen source, Linux Foundation
DescriptionHyperledger is not a public Blockchain like Ethereum or Bitcoin, it is more an blockchain building kit under the roof of the linux foundation. The focus of this tool box is building business blockchain apps in private networks. The most active participant seems to be the IBM, they offer also a lot of useful services and extensions around Hyperledger. The IBM bluemix cloud services offers a low entrance level to the technology.
The tool box concepts makes it little bit complicated to define the main characteristics of hyperledger, because you can implement a lot of different kind of distributed ledgers or blockchains.
Main application areacurrency independent money and security exchange
ConsensusStellar Consensus Protocol
Gouvernanceopen source,, nonprofit
DescriptionStellar started as a fork of the ripple network. If you look from a distance to both networks you see parallels in the functionality and features. The participance of the stellar network should be individuals, ripple focuses on institutional partners. The consensus algorithm was also changed in the stellar implementation. Stellar could also become a SWIFT competitor like ripple.
Main application areaprivate blockchain for business apps
Characteristicstrust, speed
Consensusmajority voting
Gouvernanceopen source, JP Morgan
DescriptionQuorum is the shooting star of the last months. JPM extended Ethereum with privacy and a voting consensus mechanism. These two extensions match the requirements in the financial industry pretty well. I am excited to see what will happened with this technology in the next months. Most probably, JPM will come up with new business applications and processes based on their new platform.


Tier 3

Interesting links
Main application areaFocus on banking applications
Characteristicsno blockchain, just distributed ledger technology
Gouvernanceopen source, Linux Foundation
DescriptionCorda is not really a blockchain it is a distributed ledger system. It comes from the R3 consortiums. R3 started noisy, now first members already left the group. Corda moved under the hyperledger project umbrella, at the moment Hyperledger and Corda are not technical connected, some function exists in both tool boxes in different implementations.
The focus of corda is to become a distributed backend database for the banking industry. Today in the institutes you find different IT systems which are loose coupled by enterprise bus systems. The vision of Corda is, to bring this systems to the same distributed database. From my point of view it is a nice vision from a childlike architecture view, but it will not be realistic. I think the technology can be used to realize a new class of distributed backend systems, like distributed Master Data Management or distributed Business Process Management systems in decentral organized enterprise structures.
Interesting links
Main application areaexchanging coins
Consensusproof of work
Gouvernanceopen source
DescriptionMonero's focus is on exchanging the Monero coin. The anonymization level is much higher the in the most other crypto currencies. This could also be useful for legal usage. The ideas behind this crypto are similar to bitcoin, but it’s completely new coded. Monero uses an own protocol which is different to all other blockchain implementations. It’s also not possible to see inside the blockchain without the private key or a special view key. This feature enables also an absolutely private communication between the participants. The transactions will also be splintered and merged, so it is not possible to reproduce a single transaction again.

In general, blockchain is a new technology, using it will feel experimental. You’ll have all problems you can get with new technologies in early stages.

In this post we have not discussed all the tokens based of Ethereum. This would be a good content for a follow-up article. 

A generic “Claim and Endorse” Contract

Did you already endorse someone at LinkedIn? For instance, someone claims that he knows C++ and you endorse this claim because you know it’s true.

A large number of processes can be modelled in this way:

A simple Solidity contract for managing claims and endorsements could look like below.

contract ClaimAndEndorse {
uint creationTime;

struct CLAIM {
uint creationTime;
uint claimHash;
mapping (address => ENDORSEMENT) endorsements;

mapping (address =>
mapping (uint /* CLAIM GUID */ => CLAIM)) claims;

function setClaim(uint claimGuid, uint claimHash) {
CLAIM c = claims[msg.sender][claimGuid];
if(c.claimHash > 0) throw; // unset first!
c.creationTime = now;
c.claimHash = claimHash;

function unsetClaim(uint claimGuid) {
delete claims[msg.sender][claimGuid];

function setEndorsement(
address claimer, uint claimGuid, uint expectedClaimHash
) {
CLAIM c = claims[claimer][claimGuid];
if(c.claimHash != expectedClaimHash) throw;
ENDORSEMENT e = c.endorsements[msg.sender];
e.creationTime = now;

function unsetEndorsement(address claimer, uint claimGuid) {
delete claims[claimer][claimGuid]

function checkClaim(
address claimer, uint claimGuid, uint expectedClaimHash
) constant returns (bool) {
return claims[claimer][claimGuid].claimHash
== expectedClaimHash;

function checkEndorsement(
address claimer, uint claimGuid, address endorsedBy
) constant returns (bool) {
return claims[claimer][claimGuid]
.endorsements[endorsedBy].creationTime > 0;

The fantastic thing about this very simple contract is that we now can answer the following question:

Who claims what and who endorses it?

Usecase – Skill/Degree Endorsements

John claims that he holds a PhD in computer science at the Stanford university.

3000010 /* GUID for PhD in CS */,
HASH("PhD in Computer Science at Stanford University"))

The Stanford university confirms this fact.

contract.setEndorsement(JOHN, 3000010)
Usecase – Identity Verification

Step 1. John claims facts about his personal data by binding hashes to his ethereum address. The corresponding pseudo code is:

// RND is a random sequence introduced for making it impossible to restore the initial data from the hash by brute force lookups.

contract.setClaim(1000010 /*guid firstname*/,

contract.setClaim(1000011 /*guid surename */,

contract.setClaim(1000012 /*guid bday */,

contract.setClaim(1000013 /*gender */,

Step 2. John visits his bank, which endorses these facts about his identity:

contract.setEndorsement(JOHN, 1000010 /*guid firstname*/);
contract.setEndorsement(JOHN, 1000011 /*guid surename */);
contract.setEndorsement(JOHN, 1000012 /*guid bday */);
contract.setEndorsement(JOHN, 1000013 /*guid gender */);

Now consider that JOHN wants to open A) an  account at ACME Inc, B) buy alcohol in the bar and C) register at a dating site. If all three trust John’s bank, he’ll be able to digitally prove his claims on his personal data. Moreover, he only needs to present the relevant pieces of data. For instance at the bar, he only has to prove the claim that he’s older than 18.

Related: ShoCard, uPort 

Usecase – Approving existence of documents

ACME Inc. wants to publish a new financial product. The hashes of the required documents are stored on the blockchain. The authorities and the exchanges are confirming the existence and the correctness of these documents.

Related: Luxembourg Stock Exchange OAM

Usecase – Managing Memberships

John wants to become a member in his local bowling club. He stores this fact on the blockchain and the club confirms this fact. With the first step, John manifests his will to enter the club. In the second step, the club confirms that they are accepting John as a member.

Try it yourself on Ropsten Testnet


Rebuilding Ripple on Ethereum

Ripple is a P2P payment network with an integrated foreign exchange market. It supports any possible currency. In it’s core it is based on a public distributed ledger containing liabilities between individuals and organisations (IOUs). The network depends on the trust relations between its members. Transferring a value within the network between A and B requires a direct or indirect path in this web of trust. Moreover, the ledger  contains a distributed foreign exchange market, which makes it possible to convert between currencies in real-time.

In this blog post, I want to sketch how a Ripple-like implementation could look like in Ethereum.

Asset Contract

First of all we need a contract to represent an asset that network participants can agree on. This could be a fiat or a crypto currency, but it also could be bonus miles, loyalty points or similar.

contract Asset {
string public description;
string public id;
uint public decimalUnits;

mapping (address => bool) public accepted;

function Asset(string _description, string _id, uint _decimalUnits) {
description = _description;
id = _id;
decimalUnits = _decimalUnits;

function accept() {
accepted[msg.sender] = true;

function reject() {
delete accepted[msg.sender];

An asset has a description, an id, and how many decimal units are used. For instance, we would model US Dollar and European Euro as:

Asset USD = new Asset("USD Currency", "USD", 2)
Asset EUR = new Asset("EUR Currency", "EUR", 2)

With the accept function, network participants are agreeing upon a specific Asset instance. Network participants can only use assets that they have accepted.

EthRipple Contract

data model

After defining the Asset contract, we can now specify the data model for the EthRipple contract itself. We’ll need the following model elements:


Every participant in the network needs an ACCOUNT struct storing his ASSETs. The assets are identified with their contract addresses.

struct ACCOUNT {
mapping (address /* of an Asset */ => ASSET) assets;

mapping (address => ACCOUNT) accounts;

An ASSET consists of all IOUs that a participant holds and of all his asset exchange offers (XCHG).

struct ASSET {
mapping (address => IOU) ious;
mapping (address /* of an target Asset */ => XCHG) xchgs;

xchgs – Offers for exchanging this asset for another asset.
ious – list of debtors for this asset.

IOU – “I owe you”
struct IOU {
uint amountOwed;
uint maxAllowed;

The IOU struct describes how much of a specific asset (e.g. USD) a debtor owes to the lender (amountOwed). Moreover, it describes how much a lender trusts that a potential debtor is going to pay him back (maxAllowed). During a transfer, amountOwed will always be less than or equal to maxAllowed.


IOU iou = accounts[JOHN].assets[EUR].ious[ANDY];
iou.maxAllowed = 100;
iou.amountOwed = 10;

iou.maxAllowed = 100 – JOHN trusts ANDY that he’ll pay his debts up to 100 units of the EUR asset.

iou.amountOwed = 10 – currently ANDY owes to JOHN 10 units of the EUR asset.

XCHG – Asset Exchange
struct XCHG {
uint validUntil;
uint exchangeRateInMillionth;

This struct represents the offer to exchange an Asset for another Asset at a specific exchangeRate which is equal to exchangeRateInMillionth/1,000,000. Note that here we have to work with unsigned integers since Ethereum’s Solidity Compiler has no support for decimals yet. validUntil is used to limit an offer to a specific period of time.


XCHG xchg = accounts[JOHN].assets[EUR].xchgs[USD];
xchg.exchangeRateInMillionth = 1100000;

xchg.exchangeRateInMillionth = 1100000 – JOHN offers to exchange EUR for USD at a rate of 1100000/1000000 (1,10).


The minimal interface for the contract offers methods to modify IOUs and asset exchange offers. And finally, there is a ripple method for sending assets through the web of trust to a specific destination. Note that sending a value in this case means changing the IOU records along the path in the web of trust. If required, the sent asset can also be exchanged for another asset (e.g. converting EUR to USD).

 function modifyIOU(address debtor,
Asset asset,
uint newAmountOwed,
uint newMaxAllowed);

function modifyXCHG(Asset fromAsset,
Asset toAsset,
uint exchangeRateInMillionth,
uint validUntil);

function ripple(address[] chain,
Asset[] assetFlow,
uint amount);

function modifyIOU(address debtor, Asset asset, uint newAmountOwed, uint newMaxAllowed) – with this function the msg.sender can reduce the amount owed by a debtor or he can change the maxAllowed amount for this asset/debtor. The amountOwned can only be reduced, never increased.

function modifyXCHG(Asset fromAsset, Asset toAsset, uint exchangeRateInMillionth, uint validUntil) – with this function the msg.sender can publish new offers for converting fromAsset to toAsset at an exchangeRate which is exchangeRateInMillionth/1000000.

function ripple(address[] chain, Asset[] assetFlow, uint amount) – this function is the main workhorse. It allows the msg.sender to transfer an asset to a destination address, which is reachable within the web of trust that is encoded via IOU relations.

Considering the relations below, JOHN can send money to ALEX via ANDY.

// JOHN and ANDY trust each other that they'll be paying their debts up to 1000 units of the EUR asset.
accounts[JOHN].assets[EUR].ious[ANDY].maxAllowed = 1000;
accounts[ANDY].assets[EUR].ious[JOHN].maxAllowed = 1000;

// same for ANDY and ALEX
accounts[ANDY].assets[EUR].ious[ALEX].maxAllowed = 1000;
accounts[ALEX].assets[USD].ious[ALEX].maxAllowed = 1000;

If JOHN want to send 10 units of the EUR asset to ALEX, he would call the ripple function like this

ripple([JOHN, ANDY, ALEX], [EUR, EUR], 10) 

The second array parameter means that JOHN is transferring EUR to ANDY and that ANDY is also transferring  EUR to ALEX. There is no conversion between assets. After the transaction has been committed to the blockchain, we would see the following changes in the IOU records.

// JOHN and ANDY trust each other that they'll be paying their debts up to 1000 units of the EUR asset.
accounts[ANDY].assets[EUR].ious[JOHN].amountOwed = 10;
accounts[ALEX].assets[EUR].ious[ANDY].amountOwed = 10;

If JOHN wants to send EUR, but ALEX wants to receive USD, the transfer would work if ANDY would have an active asset exchange offer for exchanging EUR to USD. Moreover, there also has to be an established trust relation between ANDY and ALEX for the USD asset.

The function call would be:

ripple([JOHN, ANDY, ALEX], [EUR, USD], 10) 

Note that the path within the web of trust is calculated off-chain and passed as input to the ripple function. There is no need to do this expensive calculation on-chain.

Try it yourself

I deployed this contract on the Morden Testnet. Feel free to try it yourself.

Contract Addresses

EUR Asset 0x110c1b256c180ddBBFF384cA553Bf7683Ce8a02c
USD Asset 0xFa33639783B5ae93795A4aeCF86985eB95EA0B39
Ripple 0x33f03cea07586f42900fbf46df6a7f596345bec1

Asset Interface

[ { "constant": true, "inputs": [], "name": "decimalUnits", "outputs": [ { "name": "", "type": "uint256" } ], "payable": false, "type": "function" }, { "constant": false, "inputs": [], "name": "accept", "outputs": [], "payable": false, "type": "function" }, { "constant": false, "inputs": [], "name": "reject", "outputs": [], "payable": false, "type": "function" }, { "constant": true, "inputs": [], "name": "description", "outputs": [ { "name": "", "type": "string" } ], "payable": false, "type": "function" }, { "constant": true, "inputs": [], "name": "id", "outputs": [ { "name": "", "type": "string" } ], "payable": false, "type": "function" }, { "constant": true, "inputs": [ { "name": "a", "type": "address" } ], "name": "isAcceptedBy", "outputs": [ { "name": "", "type": "bool" } ], "payable": false, "type": "function" }, { "inputs": [ { "name": "_description", "type": "string" }, { "name": "_id", "type": "string" }, { "name": "_decimalUnits", "type": "uint256" } ], "type": "constructor" }, { "payable": false, "type": "fallback" } ] 

EthRipple Interface

[ { "constant": false, "inputs": [ { "name": "fromAsset", "type": "address" }, { "name": "toAsset", "type": "address" }, { "name": "exchangeRateInMillionth", "type": "uint256" }, { "name": "validUntil", "type": "uint256" } ], "name": "modifyXCHG", "outputs": [], "payable": false, "type": "function" }, { "constant": true, "inputs": [ { "name": "fxAddr", "type": "address" }, { "name": "fromAsset", "type": "address" }, { "name": "toAsset", "type": "address" } ], "name": "queryXCHG", "outputs": [ { "name": "", "type": "uint256" }, { "name": "", "type": "uint256" } ], "payable": false, "type": "function" }, { "constant": false, "inputs": [ { "name": "fromAsset", "type": "address" }, { "name": "toAsset", "type": "address" } ], "name": "deleteXCHG", "outputs": [], "payable": false, "type": "function" }, { "constant": false, "inputs": [ { "name": "debitor", "type": "address" }, { "name": "asset", "type": "address" } ], "name": "deleteIOU", "outputs": [], "payable": false, "type": "function" }, { "constant": true, "inputs": [ { "name": "lender", "type": "address" }, { "name": "asset", "type": "address" }, { "name": "debitor", "type": "address" } ], "name": "queryIOU", "outputs": [ { "name": "", "type": "uint256" }, { "name": "", "type": "uint256" } ], "payable": false, "type": "function" }, { "constant": false, "inputs": [ { "name": "debitor", "type": "address" }, { "name": "asset", "type": "address" }, { "name": "newAmountOwed", "type": "uint256" }, { "name": "newMaxAllowed", "type": "uint256" } ], "name": "modifyIOU", "outputs": [], "payable": false, "type": "function" }, { "constant": false, "inputs": [ { "name": "chain", "type": "address[]" }, { "name": "assetFlow", "type": "address[]" }, { "name": "expectedExchangeRateInMillionth", "type": "uint256[]" }, { "name": "amount", "type": "uint256" } ], "name": "ripple", "outputs": [], "payable": false, "type": "function" }, { "inputs": [], "type": "constructor" }, { "payable": false, "type": "fallback" }, { "anonymous": false, "inputs": [ { "indexed": false, "name": "lender", "type": "address" }, { "indexed": false, "name": "debitor", "type": "address" }, { "indexed": false, "name": "asset", "type": "address" }, { "indexed": false, "name": "newCurrent", "type": "uint256" }, { "indexed": false, "name": "newMax", "type": "uint256" } ], "name": "EventUpdateIOU", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": false, "name": "lender", "type": "address" }, { "indexed": false, "name": "debitor", "type": "address" }, { "indexed": false, "name": "asset", "type": "address" } ], "name": "EventDeleteIOU", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": false, "name": "xchgAddr", "type": "address" }, { "indexed": false, "name": "fromAsset", "type": "address" }, { "indexed": false, "name": "toAsset", "type": "address" }, { "indexed": false, "name": "exchangeRateInMillionth", "type": "uint256" }, { "indexed": false, "name": "validUntil", "type": "uint256" } ], "name": "EventUpdateXCHG", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": false, "name": "xchgAddr", "type": "address" }, { "indexed": false, "name": "fromAsset", "type": "address" }, { "indexed": false, "name": "toAsset", "type": "address" } ], "name": "EventDeleteXCHG", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": false, "name": "xchgAddr", "type": "address" }, { "indexed": false, "name": "fromAsset", "type": "address" }, { "indexed": false, "name": "toAsset", "type": "address" }, { "indexed": false, "name": "exchangeRateInMillionth", "type": "uint256" } ], "name": "EventExecuteXCHG", "type": "event" } ]


Full Source Code

Ethereum Usecase: Identity Management (Take 2)

Identity verification is one of the hottest usecases for the blockchain. I already wrote on this topic few months ago with the idea of a fictive government binding hashed identity data to citizen’s ethereum address.

Recently, I ran into ShoCard, a mobile app which is able to locally store user’s identities (driver’s license, passport, tickets, credits cards, online accounts, …) on the mobile phone and seal this data by putting the hashes via the BlockCypher API on the blockchain. Furthermore, institutions, like banks for instance, can verify user’s identities and store this fact on blockchain too, effectively confirming that the sealed id record is correct.

I did the experiment of implementing ShoCard’s concept on the Ethereum blockchain. A very interesting point is that we only need one simple contract for the implementation of the concept. It simply binds a hash value to an address:

contract DataSeal {
address owner;
uint256 dataHash;
function DataSeal(uint256 _dataHash) {
owner = msg.sender;
dataHash = _dataHash;

First, for every user’s identity record of the form

idRecord = {idData_1, ..., idData_n, randomValue} 

we create in Ethereum a DataSeal instance storing idRecord‘s hash value.

idRecordSeal = new DataSeal(<idRecord hash>)

From now on, idRecord can not be modified without breaking idRecordSeal.

If we want to prove to X that our idRecord has been sealed by us, we will send to X the idRecordSeal address and idRecord signed with the private key of the Ethereum account used to instantiate idRecordSeal. Having this informaton, X can verify that idRecord matches the hash value in idRecordSeal contract and that the signature matches its owner.

So far, we have the proof that idRecord was created and sealed by us, but we have no proof yet that idRecord matches our real identity as documented on our id card. For instance, we could steal the id card from someone else and  seal it on the blockchain. In order to make the idRecord trustworthy, we need a trustworthy witness verifying our idRecord and committing the proof to the blockchain.

The most direct witness for this proof would be the public authority issuing the id cards to the citizens. The next best instance, could be a commonly accepted institution like the mailing company (see POSTIDENT solution of Deutsche Post AG) or a bank.

If the user has been successfully authenticated, the witness will produce

witnessRecord = {idRecordSeal, secretKey}

and create a new instance of the DataSeal contract with the hash of it:

witnessRecordSeal = new DataSeal(<witnessRecord hash>)

Finally the witness shares the following record with the user:

{witnessPublicAddress, witnessRecordSeal, secretKey}

Assuming that X is trusting W, and that we already were authenticated by W, we can pass to X

  1. the witness data {witnessPublicAddress, witnessRecordSeal, secretKey}
  2. our idRecord signed with the corresponding private key
  3. our idRecordSeal address

Now X, can check that idRecord hasn’t been modified, that we’re the owner of the record and it’s blockchain seal, and that we already were successfully authenticated by W. If X trusts W, then he doesn’t need any further verification of our identity and he can do business with us.

The concept is universal and it works with any kind of document. There are also usecases where no witness is needed at all. For instance I can seal my credit card data like this:

creditCardDataSeal = new DataSeal(<hashed credit card data>)

Every time I purchase something, I also sign my purchase with my Ethereum private key and the merchant can verify that credit card data is in my ownership. So even if someone steals my credit card, he won’t be able to purchase something with it, because the thief can not prove he’s the owner of the credit card.

KW 39 – Weekly Blockchainers Recap

The kind of blockchain news are rapidly changing these days.

  • Two years ago: Bitcoin is some dirty stuff for anarchists and criminals. 
  • One year ago: Hmm, the blockchain behind Bitcoin, it sounds interesting, lets have a look on it.
  • Half year ago: Let’s start some prototyping to find out how to use it for us, if we can’t stop the technical progress let it work in our direction.  
  • And today? I see more and more commercial projects or productive systems using the BC, DLT how ever they call it. It’s really inspiring to be a part of the development of this disruptive technology, let us have a look on some brand new examples: 

Static Type Safety for DApps without JavaScript

DApps, starting professionally…

You might not be aware, but despite its similarities to JavaScript, Solidity is actually a statically, strongly typed language, more similar to Java than to JavaScript.

static type check in browsersolidity

…and ending in frontend-chaos

Sadly, for a long time, there has only be one interface to Ethereum nodes, web3.js (besides JSON/RPC), which is, as its name implies, written in JavaScript.

Though providing this API in a web-native language is really a brilliant idea in terms of fast development, seperation of concerns and ease of use, it is a nightmare for professional, multi-developer, multi-year, enterprise products.

You may not agree with me here, but as there are currently no 10 year old 1.000.000 LoC enterprise projects in node.js/JavaScript out there, you should at least consider that such projects are nearly impossible to maintain with a dynamically, weakly typed language like JavaScript (JS).

So, we have this situation, where JS defines the lowest common denominator (dynamically, weakly typed

JavaScript_1 (2)

when we really would like to have this situation, where Java (C#, Haskell) defines the lowest common denominator (statically, strongly typed)

JavaScript_2 (2)

Removing chaos

The problem is was, that up to now only web3.js existed. However, today there is also a (which is Python and therefore at least strongly typed, but still dynamically) and, brandnew, web3j.

With the latter, we can easily model the call chain above, where we only use statically, strongly typed Java and omit JavaScript altogether. Welcome to hassle-free integration into existing Java/JEE-environments without workarounds. Finally: using the Ethereum Blockchain with Java.

If you want to actually get deeper and use Java with no RPC at all, you can also switch to EthereumJ, which is a Ethereum Node implemented in Java, like Eth (C++), Geth (Go), PyEthApp (Python) or Parity (Rust). It is crucial to understand the difference between web3j and EthereumJ. If you just want to use some Ethereum Node from a Java application, web3j is your choice, you are limited to the Web DApp API then, which should be enough for all “Ethereum user” use cases.

We will not explain in detail how to use web3j, it should be familiar to any Java developer how this library can be used just by adding Maven-dependencies to your project.

Fixing the front-end

We could stop here, since using JavaScript for the frontend is not really problematic and a common use today.

However, if you use JavaScript in your frontend, it might really make more sense to stay with web3.js. So, we want to go further: how are we going to create the GUI if we want to have no JavaScript at all?

This is just a PoC, but if you think of any other client to the Ethereum Blockchain other than a web site (let’s say: Batchjobs, Web Services, Message Queues, Databases, other proprietary software with Java adapters (there are some!)), this should make sense to you – you really wouldn’t want to use them from web3.js (hopefully).

Using templates: Thymeleaf and Spring Boot for slim enterprisy software

We will do a step-by-step guide for creating a No-JS-Dapp. Even without any Java experience, you will be able to follow without problems. Java is not that complicated anymore!

  • Get an account and key, so you don’t have to mess around with starting your own Ethereum node
  • Clone this repo:
  • Install Maven
  • Edit these files:

    pom.xml (add these dependency to section dependencies and add the repo, beware that web3j is a fast moving target, check for new versions)




src/main/resources/templates/hello.html (change name to balance.html)

<!DOCTYPE html>
<html lang="en" xmlns:th="">
<meta charset="UTF-8"/>
<title>Your Static Strongly Typed Wallet</title>
<p th:text="'The balance of account ' + ${address} + ' is ' + ${balance}" />

src/main/java/com/hellokoding/springboot/ (change name to

public class EthereumController {

public String balance(Model model, @RequestParam(value="address", required=false, defaultValue="0xe1f0a3D696031E1F8ae7823581BB38C600aFF2BE") String address) throws IOException {
Web3j web3 = HttpService("{YOUR_INFURA_KEY}"));
EthGetBalance web3ClientVersion = web3.ethGetBalance(address, DefaultBlockParameter.valueOf("latest")).send();
String balance = web3ClientVersion.getBalance().toString();
model.addAttribute("address", address);
model.addAttribute("balance", balance);
return "balance";


…that’s it. Start with mvn spring-boot:run

If you encounter an connection/handshake error, you may have to import the infura certificate into your local Java keystore (I didn’t have to)

$JAVA_HOME/Contents/Home/jre/bin/keytool -import -noprompt -trustcacerts -alias -file ~/Downloads/ -keystore $JAVA_HOME/Contents/Home/jre/lib/security/cacerts -storepass changeit

Look Ma! Displaying the wallet balance with no JavaScript!

You can call the spring-boot web application with http://localhost:8080/balance (then the defined default argument is used) or with your address (in the consensys testnet) as parameter address= 

walletOf course, you can change the Ethereum net like you want in file EthereumController to morden or mainnet, just read the welcome mail from Or you can just use a local Ethereum node like geth with RPC enabled (geth –rpc) and http://localhost:8545 as the constructor for HttpService of the Web3j-Factory in EthereumController.

Have fun, with or without JavaScript!

Steem – community building and social interaction with cryptocurrency rewards

This week I came across Steem and I instantly got sucked into it. In this post am trying to summarize what I learned about it so far. 

You can think of Steem as a Facebook-like platform where authors and curators can earn cryptocurrency rewards by writing posts, up-voting posts, commenting on posts and up-voting comments.

To understand how this process works, first of all we need to understand the currencies circulating in this process. According to the whitepaper we have:

Steem – the fundamental unit of account on the Steem blockchain. All other tokens derive their value from the value of STEEM. Generally speaking STEEM should be held for short periods of time when liquidity is needed. Someone looking to enter or exit the Steem platform will have to buy or sell STEEM. Once STEEM has been purchased it should be converted into Steem Power (SP) or Steem Dollar (SMD) to mitigate the impact of dilution over the long-term (100% inflation annually). 

Steem Power (SP) – Steem can be instantly converted to Steem Power. It is a long-term investment and can only be converted back to Steem via 104 weekly payments over a period of 2 years. This long-term commitment gives the owner two advantages:

  1. the user can participate on the platform by voting or posting articles/comments. This is rewarded by more Steem Power (SP) and Steem Dollars (SMD). How much everyone gets, depends on his Steem Power and the voting algorithm.
  2. The inflation is not 100% anymore like with Steem, but only ~10% per year because for every 1 Steem generated as reward, 9 new Steem are distributed among Steem Power holders. If the platform grows faster than the inflation, investors make a win, otherwise they’ll be losing money.

Steem Dollar (SMD) – represents a number of Steem tokens having a value of ~1 USD. It can be used to trade goods/services with the stability of the USD. SMD pays holders interest (currently 10% per year). The interest rate is set by the same people who publish the price feed so that it can adapt to changing market conditions.

The two main reward mechanisms in Steem are curation and author rewards. Both are equally important in Steem.

Author Rewards are gained by posting articles that are upvoted by others. Curation Awards are gained by early upvoting articles that grow popular later. The rewards are payed out in Steem Power and Steem Dollars. In general the more Steem Power someone holds, the more weight his vote has. If one of developers is upvoting a post, it can instantly bring more than $100 value to the post. A new account on the other side with ~3 Steem Power will only bring a fraction of a cent. The final value of a post is distributed among the author and curators depending on how early they participated in the voting process and how much Steem Power their accounts hold.

The money for the reward pool is coming from the inflation. Instead of taking a tax on existing accounts for generating the reward pools, the protocol generates continuously new Steem where 1 is going to the reward pool and  9 are redistributed to Steem Power holders. This basically results in a ~10% inflation annually.

Lot of people are asking the question if this model is sustainable. One could expect that the model can only be profitable as long as more investors are jumping in. At the moment where supply gets greater than demand the whole system could break together like a Ponzi-Schema. This could be very painful for late-adoptors because of the 2 year payout mechanism. One of the main critical voices claiming that Steem is actually scam is Tone Vays.

My personal impression so far is that this could be the first DLT application with good user experience and the potential to go viral. It reminds me a little bit on 2007 and the gold rush with the AppStore. At the time of writing this post, the platform has around 70k accounts.

Try it yourself at or read more about it at Currently every new account gets Steem Power worth ~$4 for free.

Further reading: