Guest interview: by Michael McClary, Director of Partner Development at Microsoft
How Evident Proof’s evidence verification technology can be integrated with enterprise systems.
Michael McClary, Director of Partner Development at Microsoft, talks to Evident Proof’s Adrian Clarke, CEO, and Matt Roden, CTO, about how easily their platform can be deployed by systems integrators (SIs), integrated software vendors (ISV) and developers.
Michael McClary: What is the 60-second overview of Evident Proof?
Adrian Clarke: Evident Proof is a new and unique database service that helps optimise data the verification and proof requirements of organisations, enabling them to meet their risk management, compliance and data verification obligations. The platform uses blockchain technology for greater data security and to provide access to immutable and unhackable proof certificates. Businesses can add existing data transactions to the platform, and the engine will generate cryptographic Ethereum tokens from the information being installed on it.
Matt Roden: Evident Proof is an enterprise-accessible platform which can receive any transactional data sent to it via an API. It records that transaction of data in a schema of evidence in an immutable manner using blockchain technology. It allows a user to obtain a proof certificate by using the receipt ID and an Ethereum token generated when they first upload data.
Our offering is introducing the power of blockchain’s immutable storage to enterprise customers who wish to outsource their blockchain needs — we provide a range of services and APIs to that end.
MM: How long does it take for clients to learn to integrate with the platform?
AC: We’ve used a ‘Platform-as-a-Service’ model, so developers don’t need to learn new languages — if bespoke solutions are needed, then we can walk users through them.
The APIs are intuitive, and don’t have much by way of a learning curve. These are standard graph format APIs with Swagger documentation — our standard can write to DPAPI, IPAPI and W7.
MR: In terms of technical logistics, when a client is happy for us to store the source data, there’s not a lot of knowledge required of the client-side infrastructure. If a client doesn’t wish to store data on our servers, and prefers to only send the hashes, then proficiency with database hydration in SL, MySQL and Mongo is preferable.
MM: What are the steps required to scope and build a solution — and how long does it take?
AC: Our developers meet with the client, examine the data sets, and identify which need to be appended to the immutable platform. Then they look at the schema and consider the client’s provenance requirements — once the data structures and requirements are understood, it generally takes only a few days to provide a proof-of-concept with the correct data.
An example of this methodology in use is for a local government we’re working with. It’s a simple search and discovery process — the same as the proof-of-concept architectural project being used at MTC.
MR: The first part of our approach is consultancy-based; what does evidence mean in the context of that organisation and their goals?
Key questions we ask to get the right solution for the client include:
· What will need to be stored as evidence? Do we just need to store that someone created a record or are there more fields?
· What is the organisation trying to prove?
· Do they just want to push through transactions as they come?
· Does evidence mean creating compound transactions, where the full evidence transaction is triggered by a set of transactions?
· What are the data structures? Are they linear, multiple steps that are dependent on each other? Do we need to create or restructure a workflow in order to build the proof?
In a simple system — a flat file database which just stores basic records — it would just write the call to the Evident Proof system into the program or an SQL trigger, wait for the receipt and write that into the flat row in the database. Something like this could take only a few days to develop.
For larger, more involved systems that need a modification to the data structure, the distributed application and an in-depth consultation, the process can take from days to weeks.
The skills required are a combination of systems integrator, a business analyst and a database administrator (DBA).
MM: Would clients need to engage expert help for the data discovery step?
AC: This depends entirely on the type of data, and how well the client understands it. If they’re unsure of the data model, or don’t have pre-built schemas or reporting models, for example, we can assist with some consultancy on that front, alongside the developers — we can provide training for SIs and developers as well.
MM: For a transactional or analysis services database, would any changes need to be made?
AC: Changes shouldn’t be needed because it’s more to do with the connection and the API involved as the data goes into the database. If it were a simple, column-based database, then we’d only need to map the schemas and record IDs.
MM: If I’m using a transactional database, will using the platform and the encryption requirements slow down data storage?
AC: A lot of clients will use Evident Proof as a database that complements their existing platform, as opposed to relying on it as a standalone solution. The data stored on both the private and public blockchains will be encrypted for storage.
We will have clients that use EP as their sole platform, in which case there will be some lag in retrieving data. This isn’t overly cumbersome, however, and we’re speeding it up with multiple data centres around the globe.
MR: We create asynchronous integration which shouldn’t cause any significant disruption to a business’s workflow. It only observes what it needs to observe, and collects the requisite data. There is the option to push the data to the API in the Line of Business process, and then compile evidence into a queue (which can be asynchronously processed).
The local evidence agent (which we provide) allows them to store the evidence token on the local system in the event that they only wish to send us their seals. The return from the API call is a receipt ID which needs to be kept. These are used to request proof in the future.
There are two ways in which one can retain the receipt IDs: it can be returned directly in the call as the client waits for the response, or the client can hit an end point to fetch paged receipt IDs from the transactions — but that can be more complex to process on the client side.
We should always be able to find ways to avoid slowing down transactional data.
MM: What are the top verticals you’re targeting?
AC: We’re not particularly targeting verticals — due to the wide range of use cases, we fully expect to see Evident Proof rolled out across industry sectors, catering to anyone requiring data verification, compliance and auditing.
If I had to list the top five industries that it will be rolled out in, I’d say manufacturing, pharmaceuticals, local government, legal, and financial services.
We can help clients prove they have achieved GDPR compliance, by showing immutably that they have removed data sets from their personal information data and keys which enable access, so that they only have obscured and inaccessible versions of the stored data.
In the pharmaceutical industry, Section 16 of the EU Medicine Directive dictates that the provenance and identification of drugs that move through a supply chain must be accessible. They have used the term ‘immutable’ in the directive as a requirement. The Evident Proof solution is able to provide such guarantees to drug companies, suppliers and companies transporting drugs.
MR: It’s not verticals that we’re targeting, but rather organisations wishing to store proof efficiently. There are a wealth of use cases across industries, and I expect we’ll see a lot revolve around GDPR compliance.
MM: Do you have a partner program for generating leads?
AC: We’re raising funds to enable us to build a partner, ISV and SI strategy. When a client approaches us to build a data application atop Evident Proof, we would prefer to be working with SI and ISV partners to create their product. We intend on providing training for these partners.
MM: Is there a benefit to incorporating Evident Proof technology if you are going through a system and application upgrade?
MR: We provide an SDK for many languages, to ensure that Evident Proof’s technology is flexible in adapting to existing architectures. Companies don’t often have an immutable proof chain, but there are many benefits to incorporating this into existing systems.
MM: What maintenance will be required for an SI?
MR: Upgrades to the API and databases will require maintenance. Of course, this is highly dependent on the client and the infrastructure they’re working with — simplistic systems that are not updated frequently will not necessitate the same degree of maintenance as a large and more complex system. Evident Proof will provide clients with maintenance support to ensure everything runs smoothly.
MM: As an SI, how do I see the ‘value’ from the data storage?
AC: When you store data, an ERC-20 token is generated (ERC-20 is the widely recognised standard for building on the Ethereum network). The owner of the data simply processes their data through the engine in order to create a receipt and generate a token. Therefore, the owner of the data becomes the owner of the token. They can either store these in their own wallet, or we will keep them in an interim ledger to which we will supply the keys.
MR: The utility of the token is probably the best way to look at this. When data is stored on the platform, it generates and returns a receipt and a token. The data transaction itself is what mints the token, and the record of this contains the receipt that you stored evidence. In this case, the token is providing the fundamental immutability due to its operation on the Ethereum network.
We provide a service layer for organisations to request proof and, at the base of that service, is a public smart contract on the blockchain. That contract has no notion of billable relationships — we don’t call out to oracles so that we can remain deterministic and stay within the blockchain. We therefore need a mechanism to say “ok, you have your receipt and you have an included call to get your certificate”.
If you need to call the smart contract again to verify the evidence, then you also need a utility token as that’s what allows you to retrieve your verification.
The connection between the token and the initial transaction is what provides the value. The more data which is stored on the service, and the more nodes that are created, and the more integrity the network has. The entity that owns the data also owns the token.
MM: Should an SI would start with the implementation, the immutability, as the principal focus, rather than token value?
AC: Exactly. It’s all about delivering services that add value to existing data sets whilst reducing risk on the client’s end.
MM: What support will you put in place to help partners get up to the required knowledge base?
AC: We’ve got online code snippets and training available online. There will be tech evangelists to sit with clients and SIs and their development teams, to run training sessions, or even work with them to analyse their existing requirements and schemas.
MR: The nature of the blockchain and evidence-based enterprise is such that we do need to help SI, ISVs and developers to understand the business, particularly in the consultancy phase as one gathers the user requirements. For developers, the API documentation is a comprehensive start as it offers a clear set of interfaces.
Blockchain tech is quite complicated, and some services lack enough clarity. With Evident Proof, we can talk you through what it is that’s operating under the hood.
For more information on Evident Proof, visit evident-proof.io
Join our community:
Telegram: t.me/EvidentProofOfficial
Twitter: @EvidentProof
LinkedIn: linkedin.com/company/evident-proof
Facebook: facebook.com/evidentprooftoken
Reddit: reddit.com/r/EvidentProofToken/
Medium: https://medium.com/@EvidentProof