Blockchains: Catalysts For Innovation In Content Digital Asset Management – Part 1
This article was written by Digital Asset News editor, Ralph Windsor and is the first of a two part series.
In this article, I will describe what blockchains are and explain how they can be applied to Content Digital Asset Management. I contend that there is a lack of appreciation of the wider implications of blockchains which I intend to address in this piece, along with the misunderstanding that they are exclusively Fintech-related (and therefore the exclusive concern of banks or financial interests). In part two, I will also outline what opportunities they offer for innovation in this segment as well as assess the risks that will need to be mitigated for that to be realised. Finally, I will consider Content Digital Asset Services Exchanges and how these could have a significant role to play in the future of Content Digital Asset Management.
What Is A Blockchain And Why Do They Matter?
For those unfamiliar with what a blockchains is, in simple terms they are a ledger or log of transactions. In a conventional accounting ledger, once an entry has been made, it should be immutable (i.e. never changed). Mistakes are corrected by appending new entries to reverse the invalid ones so there is full transparency about who did what and when. In paper ledgers there are a wide range of different methods the unscrupulous or incompetent can use to insert or modify entries to cover up fraud or mistakes. With the introduction of database technology to replace paper records, the theoretical risk of data getting changed after it has been entered becomes far greater because there is no visible trace that a modification has occurred. To prevent this, a variety of techniques have been devised to ensure immutability so there can be a greater degree of trust in the data held.
At this point, some might wonder what relevance accounting has to Content Digital Asset Management (which is primarily concerned with content/media assets like images, video etc). The reason is that the computer databases which hold metadata about digital assets (as well as user information and asset auditing records) are derived from work into developing digital replacements for accounting ledgers. The main purpose of transaction logs in databases is less about preventing fraud (although that can still be a factor) and is more about ensuring that the data has not become corrupted through some system failure or programming error. One reason why this might be needed is to allow records to be accurately replicated from one database to another in real-time, so if a server where they are held goes off-line, another can pick up where it left off and nothing is lost.
The biggest issue with these transactional approaches is that they are generally custom and for a single database only, i.e. they are not interoperable. My application’s transaction log will probably use a different method to your one and we can’t exchange information without developing methods to translate between the two. This problem is repeated across all the different database applications in-use (even if the underlying technology is the same). A significant amount of integration effort (and therefore cost) is required to get two systems to talk to each other, as well as a never-ending stream of problems and bugs which grows exponentially as more counterparties get added.
Blockchains use similar principles to accounting ledgers and transactional databases. Each entry is only appended to the chain so there is a full record of activity and they have built-in redundancy by making multiple copies of the data to many different nodes. To enforce immutability, blockchains use cryptographic techniques to generate a reference from the current record to the previous one in a way which cannot be modified without the mathematics employed to generate them becoming invalid (and the transaction being rejected while being checked or ‘confirmed’ by other nodes). This is the ‘chain’ part. The user of the blockchain does not need to have knowledge or even awareness of how all this works, the service is provided as part of the blockchain protocol.
The data that each transaction refers to is held inside a block, hence ‘blockchain’. The identifiers that regulate the integrity of the records are the header and the block contains data relating to the transaction. The contents of the block is arbitrary (as is the case with a database). Different blockchains support maximum block sizes (i.e. how much data each node can store) but once the data is committed, the data is retained in perpetuity and the main risk is not the data being erased, but instead losing the reference to where it is stored, i.e. a ‘needle in a haystack’ kind of issue.
Unlike conventional databases blockchains are ‘distributed’, i.e. the data is held in a number of different locations (or nodes) which each have a copy. This means they can exist independently of any specific application.
There are several attributes of blockchains:
- They use a standardised protocol for reading and writing blocks of data and record them as transactions.
- They can exist independently of any entity which reads or writes transactions to or from them.
- They might be completely public (i.e. accessible to anyone who wants to use them) or they could be private.
- They can be distributed and de-centralised, so there is no single point of failure and the blockchain will continue to operate even if one or more copies of the data is lost.
With the exception of item one, all the other items are design choices made by whoever implemented them.
It is the development of public blockchains and their role as means of value exchange (or ‘money’) which has contributed to the recent upsurge in interest. In some ways. this use of blockchains returns databases back to their original purpose as an accounting system (albeit a globally accessible one). As I will explain, however, the range of scenarios they are getting applied to is growing in the same way that the use-case for database technology also expanded.
Using Blockchains To Deliver Applications
Some blockchains have added a number of more advanced features which are more sophisticated than simply storing records and verifying that they have not been subsequently modified. Below is a description of some of these other associated innovations:
Smart Contracts are procedural logic (or ‘computer programs’). These can be stored on the blockchain and initiated when a transaction triggers them. For example, if a request for a content digital asset like a logo is made, they can check to see if the requestor has permissions. Those with some knowledge of databases might note the similarity between smart contracts and either stored procedures or executable programs such as Java etc which can run inside some databases.
Distributed Filesystems are techniques whereby files (or arbitrary binary data) can be stored on the blockchain by those who agree to provide storage capacity. Some blockchains provide this as an integral component while others are dedicated to this problem alone (and some use a different method that does not rely on a blockchain). Currently, many Content Digital Asset Management solutions use cloud storage providers such as Amazon, Microsoft etc and access to their data depends on both the survival and discretion of the aforementioned firms. If they (or some powerful third party who can influence them) decides to foreclose on a customer, getting data back from them is likely to require the assistance of a lawyer. This is currently quite a low risk possibility, but a hidden and potentially more significant issue occurs if the Content DAM solution vendor has elected to only hold their data with a single Cloud storage provider and only in one geographical region or data centre. If that location is destroyed due to some external issue (e.g. adverse weather) so is the data. This is one of the reasons why using a single Cloud hosting provider to hold all your digital asset data can be more risky than it first appears. Distributed file systems split data into multiple encrypted fragments, so redundancy is a built-in design feature and the theoretical risk of total data loss is reduced. Note that just as with blockchains, the risk moves from total loss of data to being more about not knowing where exactly your data is (the ‘needle in a haystack’ problem). As such, distributed file systems are not risk-free either, but they are redundant by default, unlike cloud storage.
Instead of writing blocks of data as a method of exchanging information between applications, some blockchains provide non-retained messaging for low-latency communications (e.g. ‘chat’ style applications or streaming data services).
Distributed applications bring together all of the above to create complete applications which users can interact with:
- Data (stored on blockchains)
- Back-end logic (smart contracts)
- Front-end interfaces (stored on a distributed file system)
- Messaging for sending low-latency signals between instances (not stored, e.g. chat, streaming data etc)
- Content binary data (aka ‘asset files’ – also stored on distributed file systems).
Those who have some knowledge of software development will be able to see that this is more or less the entire ‘stack’ or suite of technologies required to deliver applications – including Content Digital Asset Management.
Distributed applications are more likely to be scalable and highly fault-tolerant because not only the data but everything else required to deliver the application is replicated many times (in some cases on every participating node on the blockchain). There is the robustness and security of an infrastructure designed for financial transactions but the capability to deliver diverse kinds of transactional applications which can also potentially interact with any kind of digital asset stored on the blockchain, whether they are content/media oriented or something entirely different.
One particular attribute of Content DAM solutions delivered as blockchain applications is that without any special effort being required, it is possible using smart contracts (or similar techniques) to mix and match application services without them necessarily having knowledge of each other. Over on DAM News, we have described how Content Digital Asset Supply Chains are incrementally replacing stand-alone Content DAM solutions. Going much further back to nearly five years ago, we described Digital Asset Value Chains which were prototypical form of distributed blockchain Content Digital Asset Management platforms.
Blockchains Leverage More Value From Content Digital Assets Contextualising Them
As described in the first Digital Asset News article defining digital assets, there are many different kinds of digital assets, of which the content variety are but only one example. In much the same way as databases can be used for many more applications than Content Digital Asset Management, so too can blockchains for other types of digital asset. As well as currently popular examples like tradable cyprographic tokens there is also authentication (which relates to digital assets like social media accounts), Internet of Things digital assets, storage, digital intellectual property commodities, media (such as images, documents or videos), domain names, advertising keywords any numerous others.
The difference with a blockchain is that all of these can co-exist together and be accessed in a standardised manner. Where in the past, users of either digital assets or the applications that managed them were contained within silos that needed the willing assistance of whoever developed the applications where they resided to connect them together for you, now it is possible to do this independently. If one development team either cannot assist to provide an application service you require (or lack the skills to do so) you could get another one to provide the missing functionality, leaving the existing services to continue untouched and functioning exactly as they did before.
The implications of this are profound because it means that different kinds of digital asset might well be used and managed interchangeably in a way that has not happened previously. For example, Internet of Things digital assets contain usage information about physical items and how frequently they get re-ordered which can be correlated with data about what content digital assets were used on the packaging to judge the effectiveness of a recent design change.
Organising that kind of complex multi-application analysis currently is difficult to achieve and involves obtaining data from numerous separate systems, each of them with data sources that will almost certainly be incompatible with each other. If one party decides not to cooperate for political or commercial reasons (or both) the exercise becomes even more challenging, to the extent that many would consider it not worth undertaking.
A digital asset which exists on a blockchain is far easier from the perspective of the problem described because no single application (or the interest group it represents) controls it. At present, the metadata component of a content digital asset is held ‘inside’ the system’s database. If you want to get access to this data, you have to have the permission of whoever manages it, wait for them to give you access and provide some technical documentation (or at least hints about how to transact on the required digital asset). While it is the case that the majority of recently released enterprise applications now have an API, this is a ‘grace and favour’ style arrangement where the vendor grants the application users access to their data, but only using methods they deem appropriate. If the API is unsatisfactory for the task or the user wants to move their data somewhere else, they are obliged to ask permission. While providers of software applications are typically contractually bound to fulfil them, they can be highly obstructive if they so wish and some costly fees may be applied which the end user might find it difficult to argue against.
Having data on a public (or private shared) blockchain bypasses this problem. The current owner of the blocks of data can invite whoever they like to access this data. Blockchains can offer a number of the benefits of an on-premise solution (i.e, control) but with the same scalability and potential redundancy advantages of cloud-based deployments. This is not to say they are not without risks (a point I will cover in part two) but they present some highly compelling reasons why they are likely to gradually replace current methods of delivering many multi-user software applications, including Content DAM solutions. This process will take time to manifest itself, but both the advantages it offers (and the risk capital being sunk into the technology) make it an increasingly likely prospect.
The Transactional Internet As A Catalyst For Content DAM Innovation
I have heard blockchains and the technologies built using them called ‘The Internet of Money’. I believe a more accurate description would be ‘Transactional Internet’. Money and currencies cannot exist without human beings to assign value (or ‘meaning’) to them. From a reductionist perspective (of the kind an engineer requires to develop something) money is no more than a series of transactions represented by tokens which two parties both agreed to use as mutually acceptable medium of exchange.
De-coupling ‘money’ from blockchains (or at least allowing it to become an optional attribute for those who are interested in that purpose) opens up a wide range of potential use-cases which far exceeds the narrow range they are being applied to at present. The history of software applications demonstrates that the while investment in a given technology by financial interests is the catalyst for it to get adopted, it doesn’t take long for others to take the know-how and techniques in order to re-use them for something else. In more cases than many people first realise, the measurement and tracking of value (in a wider sense) is equally important as it is for those who need to count beans, gold, dollars, bitcoins or any other token you care to mention.
Most of the major early work on database technology was paid for by those who had to implement systems to carry out accounting tasks. After defence, large-scale financial data processing requirements like payroll, order-processing and tracking bank account balances were the major early uses of databases. This is the reason why people still use terms like ‘file’, ‘transaction’, ‘audit’ etc even for activities that ostensibly have nothing to do with accounting or banking/finance.
I would suggest that a Content Digital Asset Management system is essentially an accounting system for media digital assets. While many of the end users may not regard themselves as having an a role which is an accounting-related one, what they actually do (in terms of activities) is not remarkably different from many of the tasks that bookkeepers, auditors and accountants are engaged in. I have met a number of Content Digital Asset Managers who were originally placed under the stewardship of the accounting department in organisations they have worked for in the past.
Many of the users and developers of Content DAM technology implicitly grasp this fact, which is why they give their products names like ‘Asset Bank’, ‘Media Bank’ etc. It is not just the fact that the Content DAM system is supposed to be a ‘vault of media’, but the whole activity of depositing, withdrawing, auditing and analysing digital assets is similar to what goes on in a bank that deals with money or other more conventionally defined financial assets.
Although the origins of blockchains are to solve finance-oriented problems, this does not mean they cannot (nor will not) get used by other groups who have information management requirements that are similar. As discussed in the earlier section explaining what blockchains are, there is strong evidence that this follows a pattern repeated throughout the history of software applications, in general.
Blockchains are a foundational technology in much the same way that TCP/IP is for the internet. The fact that the internet was originally designed as a military network which could remain operational in the event of a nuclear conflict does not mean that it’s role is exclusively defence-oriented. As has been proven for well over 40 years, the core protocol can be used for a very diverse range of purposes and underpins many other subsidiary technologies.
Just as writing TCP/IP off as an innovation only of interest to the military in the 1970s would have been exceptionally short-sighted, so it is the same with blockchains in 2017. It isn’t about who uses a technology, or even what it is called, it’s about what value you can create with it that should determine whether you pay attention to it or not.