You may have heard people in the blockchain space throwing the term Inter-Blockchain Communication or IBC around lately. This term refers to any technology that allows transactions across multiple blockchains.
It’s not that simple though. There are actually two sub-categories of cross-chain transactions that need to be differentiated.
Homogeneous IBC: transactions across two different operating on the same core protocol.
Heterogeneous IBC: transactions across two different chains on different core protocols.
This is really a rabbit hole! What’s a core protocol? Essentially if two chains share the same core protocol which can natively verify and utilize the state of another blockchain using that core protocol. This is more complex than it appears at first glance.
Homogeneous IBC:
In chains such as Cosmos, all have different security models and do not all share the same consensus mechanism. Despite this, all Cosmos Blockchains are compatible with the inter-blockchain communication protocol which provides “reliable & secure inter-module communication between deterministic processes that running on independent distributed ledgers”. Additionally in chains such as Polkodot there IS a shared security module. In that case, a relay chain makes it possible for state changes on one Polkodot “parachain” to be ingested by and compatible with another parachain.
Heterogeneous IBC:
Most Blockchain ecosystems that offer Homogeneous IBC between chains operating on the same core protocol also offer some possibility for interacting with external chains that are “economically and technically sovereign”. In the case of Polkodot these chains are called Bridges. The Cosmos ecosystem uses a functionality called the “peg zone” to enable Heterogeneous IBC.
An in-depth discussion of how these functionalities work deserves its own post.
Will my donation arrive at the people in need? Or will it get lost, somewhere in the administration costs of a humanitarian organization? Today, intransparent systems confront donors with a high degree of uncertainty, which diminishes their overall willingness to donate. Therefore, we at Datarella teamed up with the YOU Stiftung to create the next generation of donation platform for sustainable aid projects – SmartAid.
SmartAid is reinventing online charitable giving by implementing our Traceable Donation Technology – powered by Blockchain. SmartAid offers its users a unique donation experience with three distinct key value propositions:
An effortless donation experience
An engaging donation experience
A trustless donation experience
An Effortless Donation Experience
The first barrier, which hinders people from supporting impactful aid projects is the haze related to donating. Our goal is to make supporting these projects, which are often located on the other side of the world, as easy as buying a coffee. No login, no IBANS, no SWIFTs, no hidden fees, no subscriptions, no minimum amount, no bs. Simply scan a QR-Code, whether it is on a billboard at the metro station or on your computer screen or click a link and you will find yourself on the highly intuitive donation home page of SmartAid. Just a few clicks are required to conduct your good deed. Simply choose your favorite payment method and you help to create prospects for less privileged people.
An Engaging Donation Experience
After your payment was processed, you will be rewarded with a unique QR-Code. Share this code and the attached link with your friends and family to show them the journey of your donation. Sending it to your community will also make it easy for you to find it back in your messaging history. Also, since SmartAid is a web app, you can download it to your home screen – just like a traditional app but without the hassle of downloading it from the app store.
A Trustless Donation Experience
The received QR-Code makes it not only easy to find your donation ID back in your message history, but it holds all the information required to track your very own donation among all others. At this point, SmartAid differentiates to traditional donation platforms – no trust is required since everything is documented immutably and transparently on the SmartAid Blockchain.
Traditional donation systems vs. SmartAid’s traceable donations
As illustrated in the graphic above, traditional donation systems allocate fiat currencies, like EUR, USD, in one pot, and distributed to different cost centers of an aid organization. Therefore, traditional donation platforms cannot provide donors visibility about the usage of their funds.
In contrast, on SmartAid each incoming donation is documented on the private Ethereum SmartAid Blockchain. To enable full transparency of the whereabout and usage of each individual donation, each payment will be represented by its own ERC-20 token contract. Each of these token contracts are distinguishable by their contract address. As visualized in the graphic above by different colors, this allows granting SmartAid donors blockchain secured clarity about how their funds will be used.
The donation tracker then provides the user an overview of the status of his donation. Here she will also be informed about the actual usage of her kind donation.
Donating hard-earned money to charity is a noble gesture. It requires a high amount of trust and transfers a significant amount of responsibility to the receiving party. Unfortunately, intransparent systems confront donors, as well as aid organizations, with a high degree of opaqueness. Donors face a high degree of uncertainty about the usage of their givings, which in turn diminishes their overall willingness to donate. At the same time, aid organizations are suffering from high costs of reporting to and providing their donors with formal audits. In both cases, the value which arrives at the people in need is significantly reduced. Therefore, we at Datarella are working with our partners on SmartAid to create the next generation of donation platform.
We are proud to announce that SmartAid is also among the winners of the EU funded H2020 accelerator Blockchers. Here we are going to extend the functionalities of SmartAid for aid organizations. Stay tuned!
Last October during the Outlier Ventures Diffusion Hackathon, we built a Proof of Concept of a Parking Agent System – Effortless Parking, which could solve the coordination problem of parking in crowded cities. In this post, we will look at the individual components of the promising technology stack upon which we build this project – Fetch.ai.
Do you remember Agent Smith from the Matrix trilogy? If not, let us fresh up your memory. The Matrix is a science fiction movie in which mankind almost lost the war against the machines. Most of the living human population is stacked up in energy farming towers by machines overloads in order to harvest their biologically produced energy. The consciousness of these “human batteries” is hooked up into “the Matrix”, a computer program that simulates the experience of the world how we know it today. This keeps the “human batteries” docile, sedated, and entertained. Agent Smith is a software agent living in the Matrix. His job is to hunt down humans, like the protagonist Neo and other individuals of the last reminding human resistance, which reenter the Matrix to free other individuals. Mr. Smith and other agents act autonomously to reach their goals. Further, over the trilogy, he even manages to learn a new skill, which allows him to transform other “Matrix inhabitants” into copies of himself to fight Neo.
You might be asking, what does this have to do Fetch.Ai?
Autonomous Economic Agents
The core element of Fetch.Ai is software agents, so-called Autonomous Economic Agents (AEA) which are living in Fetch’s digital world, the Open Economic Framework (OEF). Similar to Agent Smith, these software agents operate, interact, and even learn new skills autonomously. However, the goal of these agents is to actively search and discover other agents to generate economic value. An agent can represent an actor or thing in today’s economy. They can serve as a data provider, such as a sensor, which offers its data to other agents. Vise versa, agents can request data from these sources and do computations to generate valuable information. All the search and discovery takes place in Fetch.Ai’s Matrix, the Open Economic Framework. As the world ”Open” in OEF reveals, it is open, so any business or individual can join the network to offer information and services. To establish trust in a network without a gatekeeper, Fetch.ai included a Self Sovereign Identity solution (SSI) for its software agents. This allows agents to earn a good, respectively bad reputation, depending on the quality of service they provided to other network participants.
Fetch’s software agents can independently acquire new skills, which are required to conduct their tasks. Let’s say, an agent has been tasked with buying concert tickets at the cheapest price on your behalf. It already has the negotiation skill but can autonomously acquire a betting skill to participate in an auction for you. These agents are not, however, General Artificial Intelligent (AGI), since their capabilities are limited to a certain field of activity.
Fetch Ledger & Token
The legal tender in the world of Fetch.ai is the native token FET. It is used as a digital currency to pay for all transactions, e.g. buying/selling of data, network operations, e.g. deploying new agents or conduction computations, and secure communication. The state of the Fetch.Ai world – the answers to who owns what and who is who to a given point in time – is documented by its Smart Ledger. This state-of-the-art ledger technology uses 6 separate chains that synchronize in order to ensure state consensus. Using multiple synchronized blockchains makes the Smart Ledger highly scalable and capable of processing over 30k transactions per second.
As a consensus mechanism, Fetch uses Proof-of-Stake – in which any token holder can participate to secure the network. Token owners can stake their FET to secure the network and earn staking rewards paid in FET:
Participate in a staking auction directly.
Fetch.Ai offers 200 staking slots, which can be won through actions. The winners are entitled to run one or more validator nodes for which they are rewarded with 7500 FET per slot. For participating at the auction, a minimum amount of over 750k FET is required
Join a staking pool
FET owners, who don’t want to run a validator node or not have sufficient tokens to participate in the action, can delegate their stake and join a staking pool. Participants will be rewarded with a 10% annual return on their delegated stake.
Binance
Also, it is possible to earn staking rewards, by holding tokens in your Binance account. This option is probably the most convenient and is rewarded with a 1-4% annual yield.
Fetch.Ai is made up of three core elements, the Autonomous Economic Agents, which generate value by acting as a data provider or consumer, the Open Economic Framework, the digital world, which connects agents with each other and a highly scalable Smart Ledger, keeping track of the current state. In the next post, we will look at possible use cases, and elaborate on how networks built on Fetch.ai can offer lower transaction costs than today’s web2.0 multi-sided markets.
Faced with the imminent Wirecard accounting scandal, and an apparent lack of diligence by audit firms, regulatory bodies, and the government have realized that financial accounting must be improved significantly. However, previous improvements in financial accounting were aimed at an intensification of financial controls that, in turn, led corporations to intensify their internal bookkeeping creativity, and limited positive results. However, we need something different: We need Traceable Accounting -A blockchain-based automated real-time accounting approach.
A new approach to financial accounting is needed. An approach that eliminates fraudulent behavior from the start. Traceable, immutable financial transactions, processed on secure, transparent distributed ledgers – this is what governments should require from all publicly listed companies.
Blockchain technology may represent the next level of accounting: Instead of keeping separate records based on transaction receipts, companies can write their transactions directly into a shared ledger, creating a system of historically consistent, enduring accounting records. All entries are distributed and cryptographically sealed, therefore falsifying or destroying them to conceal activity is practically impossible.
Benefits Companies would benefit in many ways from this real-time traceable auditing:
Automation: A high degree of standardization enables auditors to verify a large portion of the most critical data behind the financial statements automatically
Minimized Costs: The cost and time necessary to conduct an audit would decline considerably
Value Add: Companies and auditors could spend freed-up time adding value to the company’s controlling: e.g. data analysis and algorithmic predictions on the future company (and market) development
Inclusion: The auditor and compliance officer can be included in the entire accounting process by running a trust node
It is not feasible to start with a joint register for all accounting entries. The Blockchain, as a source of trust, can also be beneficial in today’s accounting structures. It can be gradually integrated with typical accounting procedures: starting from securing the integrity of records to completely traceable audit trails. At the end of the road, fully automated audits may be the reality.
Trust in Public and Private Blockchains Whereas Public Blockchains are designed as truly decentralized, or ‘trust-less” systems; i.e. networks that don’t need a specific trust anchor since they come with integrated trust through algorithm-based consensus mechanisms, Private Blockchains are lacking this integral trust. Private Blockchains are mostly run as centralized networks, by companies or organizations, that have full control of the data flow. Blockchain technology provides historically consistent immutable data records – but under the sole responsibility and control of the respective company. Governance Models, in which rules and processes of the Blockchain are defined, allow for a wide acceptance of the system with all participants. However, third parties that are prevented from participating in the permissioned network, can’t falsify or verify the data output.
Step 1: Adding Trust With A Trust Node Datarella’s Traceable Accounting concept adds trust to Private Blockchains by integrating a ‘trust node’ run by a trusted third party, s.a. an audit firm or compliance officer. Additionally to the nodes run by the company itself, an audit firm runs a node with full access to the network, therefore servicing as a notary in the first place. The auditor conducts a real-time audit to verify a large portion of the most critical data. Through smart contracts, this audit can be automated to a high degree and save time and money. The audit engagement is mapped in a Governance Model, which allows for full transparency among the network’s participants as well as towards external stakeholders, s.a. stockholders, etc..
By adding trust to a Private Blockchain system through a trust node, a key inherent weakness of a partly-decentralized system is eliminated: Through the integration of audit firms in the company’s data flow, its accounting becomes trustworthy, and innovative at the same time: Traceable Accounting allows companies to run AI-based data analyses that provide valuable data to the finance department for improved controlling capabilities.
Step 2: A Fully Trustless System At a later stage, the Private Blockchain should be morphed into a Public Blockchain that provides all interested parties with access and audit opportunities. The architecture and mechanisms of a Public Blockchain allow for the participation of entities in the network that do not have to trust each other – a Public Blockchain is designed as a ‘trustless’ system: it works without the existence of trust between the parties.
A Public Blockchain can be designed as a permissioned or a permissionless system. In a permissioned system, there is a regulatory body that sets-up a governance model defining the rules for access and behavior in the network. In a permissionless system, anyone can participate.
Traceable Accounting – A Blockchain-Based Automated Real-time Accounting Approach
Developing a fully trustless system must be the final goal for regulatory and legal bodies when envisioning a new framework for financial auditing. It meets all due diligence criteria, especially those that have fraudulently been bypassed in the Wirecard scandal.
Today, the long-awaited Covid-19 tracing app will be released in Germany, which should help to detect infection chains and warn potentially infected people that they were in contact with someone infected with the virus at some point recently. The decentralized approach of the app raises some questions: Are there parallels to the concept of Self-Sovereign Identity? And if so, are we witnessing the first broadly useable application for SSI in Germany? I will face these questions in this blog post.
Even though the app is already delayed, as it was promised to be released almost two months earlier, it still comes at the right time since life in Germany is getting back to normal again. The app was released in Germany so long after other countries due to many reasons, one of them being privacy. There should be no possibility that this app holds any form of personal information for anything beyond its actual purpose. In fact, the developed app is overall pretty solid. It respects the users’ privacy, it is simple to use, and no central institution has too much control over the data. Let’s analyze some criteria from an SSI point of view to determine if it is a self-sovereign identity:
Control
To begin with, we need to look at who has control over the identifiers. These are designed to be self-creating on the user’s device and frequently automatically changing. The user doesn’t have to create and register them manually. In fact, the user has no control over how the identifiers are being created or exchanged with others. Therefore, randomly created ids violate the principle of control over the identifier since the user does not influence it.
Forming of Connections
As the next criteria, I want to take a look at how connections are established. In the SSI ecosystem, connections with others are formed via the DID Auth protocol, which verifies that the user holds valid keys for a DID. In the tracing app, this is done via Bluetooth. The device automatically recognizes other devices in Bluetooth-range and stores their ID, timestamp, and signal-strength for 14 days. If an infected person was later identified, all the IDs would be sent to a central server from which the user’s devices are frequently polling. If the IDs match up, the app warns the user that he or she might be infected. This is also contrary to an SSI approach were connections are formed with explicit consent, and exists for as long as one party terminates the connection.
Even though more criteria help to determine if the tracing app is a Self-Sovereign Identity, it is already clear that it is not a Self-Sovereign Identity, even if it is much closer than a centralized approach. However, it would be possible to align it more with SSI principles.
Tracing App with Blockchain Integration?
Let’s say the user downloads an app that has the functionality of creating compatible key pairs for an underlying blockchain or DLT. These would also not be human-readable and would further allow interactions with the underlying blockchain. If a person was diagnosed with Covid-19, the device could perform a transaction to the ledger and its IDs would be stored in a central revocation registry that the devices pull from. Therefore, there would be no need for a centralized server that is run by a single institution. Using a blockchain here would bring some benefits as well as it could work across borders and probably for less than what SAP and T-Systems, a subsidiary from the Deutsche Telekom, charge.
In short, I hope that this app has the most success and that people will use it to combat this pandemic and end it as soon as possible. I further hope that decentralized approaches, where the privacy of the user is the main priority, are becoming more popular and allows people to see that we don’t always have to provide sensitive personal information to anyone that offers an online service. And last but not least, I hope to see more people are aware of the benefits of Self-Sovereign Identity so that its public adoption is achieved earlier than expected. The concept of this app is a step in the right direction, and I hope there will be more to come!
Do you want to know more about Self-Sovereign Identity? Read my series, watch a webinar I held recently, or contact me!
Last week, Martin Schäffner gave an introduction to blockchain-enabled Self-Sovereign Identity at the Crypto and Blockchain Meetup bdvb HG Bayreuth. Did you miss it? No problem! Re-watch his webinar on YouTube (link below).
Self-Sovereign Identity is a trending topic in the blockchain-scene. It aims to take away dependency on classic online identity providers such as Google, Facebook, or common online services that require to create an account to use it. This is achieved by letting the user create and manage its own identifiers through independently creating decentralized identifiers (DID), that don’t require a centralized institution. Information can be asserted to these identifiers by issuing Verifiable Credentials to the identity owner, which can then be presented with third parties in a privacy-preserving and fully automated manner.
In the webinar, Martin speaks about the differences between conventional online- and self-sovereign identities. He further introduces key elements in relation to Self-Sovereign Identity and reflects an overall picture of the SSI architecture and process flows for issuing and presenting verifiable credentials. He also gives an outlook on which use cases can benefit from implementing SSI.
Are you hooked? Watch it here again on YouTube:
For more content about Self-Sovereign Identity, I can recommend reading my series about Self-Sovereign Identity, starting with the first part.
Do you have questions about SSI or just want to leave feedback? Contact me!
On 8 June, the Proof-of-Stake EUPos Working Group within the European Blockchain Association EBA has published its Staking Infrastructure Position Paper (PDF) over the course of a website relaunch with a new, fresh look & feel. The Position Paper aims to give policymakers the tools necessary to craft wise regulation of blockchain infrastructure that benefits the European Union and its member states.
The Position Paper’s goal is to achieve a level of regulation that incentivises blockchain infrastructure providers to choose the EU over competing jurisdictions, as in particular China, Russia, or the USA. This will allow the EU to shape the development of globally relevant blockchain networks according to its federal values. As all EBA Working Groups, the EUPoS Working Group is open for all aspiring participants, willing to comply with the general EBA Governance and respective working group requirements.
Empowering The European Blockchain Ecosystem
The European Blockchain Association aims to become a partner of choice for organisations, corporations, institutions, and policymakers working in the field of blockchain and DLT in the European Union. We combine, synchronize, and leverage blockchain-related activities of European corporations, startups, venture capitalists, and scientific institutes. We serve as a superior, neutral body to aggregate and coordinate blockchain activities throughout Europe and to provide Non-European parties access into the European blockchain ecosystem. By building bridges, s.a. by creating the EUPos Position Paper, the EBA lowers hurdles and reduces obstacles that stand in the way of innovation in the field of decentralisation.
The New EBA Website
Besides the publication of the EUPoS Position Paper, EBA has launched its new website. Great EBA features, s.a. EBA Engagements, EBAx, or EBA Tenders, have achieved higher visibility and better access for interested visitors. We at Datarella like the new look & feel very much and love to support EBA as active members in several working groups!
Since 2015, Datarella has been active in building enterprise blockchain solutions in the humanitarian sector, in the fields of supply chain and mobility, and in finance and real estate. Leveraging combined resources from Munich, Germany, and its Gdansk, Poland, Baltic Data Science team, has allowed for highly agile, interdisciplinary teamwork which has been a significant success factor especially during the Coronavirus crisis. Now, Datarella expands the blockchain development team to Macedonia.
Blockchain and distributed ledger technology are emerging technologies that will have a significant impact on the economy and society. The implications of Blockchain technologies are expected to be industry spanning and are not restricted by geographical boundaries. To raise the awareness and potential of this technology in my home country Macedonia last year on 02 August 2019 I create the meetup group “Macedonia Blockchain Group”.The first presentation was in December at the Faculty of Computer Science and Engineering in Skopje. The Interest of the students about the topic was impressive. For the students to get practical knowledge, they need to be exposed to Blockchain projects. To do this, we were searching for industry partners that will cooperate with the group and allow the students to work on blockchain projects.
I am happy to announce that we now have finalized cooperation with our industry partner Datarella from Munich, Germany. Datarella is a company that is an early adopter of the blockchain technology and already has finished successful projects in this domain. We started the cooperation this month, and the developers will work on three different projects additionally represented in the form of seminar work. We are looking forward to a successful partnership!
Datarella’s Munich and Gdansk teams have already started with the integration of the Skopje team and are delighted about this significant strengthening of our development stack. We would like to thank Dimche Risteski and his Macedonian team for entering this cooperation and look forward to a our joined journey!
Last week we started a series of articles for an introduction to Self-Sovereign Identity components. In the first article, we have taken a look at some of the fundamental elements of SSI – Decentralized Identifiers (DIDs), their corresponding DID Documents and Verifiable Credentials. We now understand that DIDs are the digital and sovereign representation of an identity, that is further described in the DID Document and from and to which we can issue Verifiable Credentials. Part 2 of the series, we face the question of how DID Documents are technically associated with a DID and how we can authenticate using DIDs.
If you want to know what SSI is in general and how it could affect our online environment and behavior, take a look at the introduction article to SSI.
DID Resolution
DID resolution describes the process of getting from the DID to its associated DID Document. It is the basis for creating connections, initiating interactions, and proving ownership via DID Auth (see below). DIDs should be globally resolvable, allowing others to look up the DID document, for example, to start an interaction. Since every DID method works somehow differently and has different ways of creating and storing a DID document, resolving them works differently for each DID method.
There are three main ways of how DID Methods, which define how to create a DID, and manage DID Documents. They could either be publicly stored somewhere and referenced in the transaction itself – like in Bitcoin Reference (did:btcr:) or generated by gathering events of a transaction to an authorized account – like in uPort’s ETHR DID Method (did:ethr:). The third way is to automatically generate the DID Document by the ledger itself like in Sovrin (did:sov:).
To create an interoperable SSI ecosystem, it would be useful to dynamically resolve the DIDs of any DID method. By doing so, DIDs from different blockchains could interact with each other. One system that does this is the “Universal Resolver”, which is illustrated in the following figure. Here, Webservices, Apps, or other services can resolve any DID Document that has a driver implemented in the Universal Resolver.
Model of the Universal Resolver
DID Auth
Cryptographically authenticating an identity owner, is a central goal in the SSI ecosystem. To establish trusted connections, proving control over a specific DID as long as the DID exists. In SSI, this specification is called DID Auth and relies on a challenge-response authentication protocol where the identity owner signs the response to authenticate. DID Auth uses the authorized public keys listed in the DID Document for authentication.
The challenge-response cycle can be implemented with multiple protocols. One of the preferred ones is using a JSON Web Token. However, it also works with other protocols such as the TLS handshake protocol, OpenID Connect, or even HTTP.
The following figure shows a simplified process of DID Auth.
Source: Introduction to DID Auth (Sabadello, et al.)
At first, the Web-Site of a relying party displays a QR on the Identity Owner’s Web browser that contains the DID-Auth Challenge. In the next step, the Identity Owner scans the QR Code and sends a DID-Auth Response with the signature of the Identity Owner’s private key to the Relying Party’s web server. Based on this private key signature, the creation of an proof signature indicates control over a DID. The web server receives the response and can validate that the identity owner controls the DID by resolving the DID document and validate the public key. After the successful authentication, the relying party’s web page polls this information and displays its content. For a more detailed description of DID Auth, I recommend taking a look at this document.
Conclusion
In this second article about the introduction to Self-Sovereign Identity components, we got to know DID Resolution and DID Auth.
To summarize, DID Resolution describes the process of getting from a DID to a DID Document. This process is essential as the DID Document contains important information about the DID, such as authorized public keys or service endpoints. This information is crucial to start an interaction like proving ownership or control over a DID, which describes the process of DID Auth. By implementing a challenge-response cycle, an identity owner can prove ownership or control over a DID and therefore creates trust between both parties. It’s worth mentioning that, in this case, only requires these two parties, and no additional identity provider needs to be involved. As a result, DID Auth creates a trusted fundament for further interactions, such as issuing credentials or other data exchange.
In the third part of this series, we will take a more in-depth look at Verifiable Credentials. How can these be issued, how can they be trusted, or how can they be managed will be questions we are going to face and answer.
If you have any questions about SSI or want to leave feedback, feel free to contact me.
