Dear David, I been following recent threads on Blockchain technology, and
since I have been conducting some research into how the Blockchain
technology operates I am offering some thoughts below in response to your
post.
1. You say, "Another concern is for organizations that create their own
documents/records as part of the greater process environment. In the
Blockchain structure, don't they release this product to everyone? Won't
multiple copies go out beyond their control? Once it is out there that
organization has no more say in what happens to their information. Good
luck with retention and disposition.²
Letıs first be clear on what information will be released. It will only
be a hash of a record (a hash function takes an input or 'message' and
returns a fixed-size alphanumeric string, which is called the hash value,
sometimes called a message digest, a digital fingerprint, a digest or a
checksum). The hash, just being an mathematically generated numeric string
does not reveal anything of the content of the originating record. To
draw an analogy to medieval record keeping practices, it is akin to
signing and sealing a charter, with the sign and seal being stored
separately. At a later date, if you want to authenticate the document,
you can compare the sign and seal stored separately or in your possession
with the sign and seal on the charter. The main difference between this
example and how the blockchain operates, however, is that, in medieval
times, when I signed and sealed something, I was also attesting to its
reliability, or factual truth. This is not the case for the blockchain,
wherein unreliable (documents containing factual errors or misleading
facts) can still be digitally signed, encrypted, and stored on the
blockchain.
It is impossible to reverse engineer the hash to produce the record from
its hash. Thus, the contents of actual record itself will not be revealed.
That said, the hashes will be out on different distributed ³nodes² in the
network that will be beyond the control of the originating organization,
unless the blockchain as been set up as a ³permissioned² blockchain
(something like the equivalent of a private cloud). To authenticate a
record using the blockchain you need to have a (1) the original record and
(2) the hash from the blockchain. The bigger challenge, therefore, will be
in how to ensure that the link between the original record and its hash is
maintained over time so that records can be ³proved².
2. You mention the costly and duplicative nature of a distributed
environment.
This is true, each node in the network retains the entire block. One
solution to this is to produce a Merkle tree (aka A tree constructed by
hashing paired data (the leaves), then pairing and hashing the results
until a single hash remains, the merkle root
<https://bitcoin.org/en/glossary/merkle-root>. In Bitcoin, the leaves are
almost always transactions from a single block
<https://bitcoin.org/en/glossary/block>). This reduces the amount of space
required for storage of complete chains. But more to the point, because
organizations do not own and operate the nodes in the network, they do not
bear the cost (and pain) of inefficient modes of storage, unless of
course they are operating the blockchain networks themselves as private
blockchains. Thus, there is no strong centralized incentive to be
efficient in terms of storage, though individual processors may wish to be
efficient.
3. You say, "And finally, is Blockchain a product designed to enhance
security and privacy? I read that it is encrypted but there are many who
have that key; everyone on the system. And all of the content is
everywhere, not just in a central control environment. Does this enhance
the data security or hurt it? If it is possible to steal information from
any location that would seem to increase the risk, not reduce it.²
There are many security concerns that one can point to with respect to
Blockchain. These include vulnerability to DDOS attacks, 51% attacks
(where the independence of nodes is overpowered), software bugs that
create ³hard forks² in the blockchain and operational problems. As you
allude to key management is also a problem in any technology that relies
on encryption. There are many more risks that could be cited, but suffice
it to say that this is an area of concern, as it is with many systems
these days.
4. You say, "I also see benefits. There is incredible redundancy which
increases preservation ability.²
Actually, Blockchain technology does nothing to increase preservation of
the original records from which the hashes on the blockchain are produced.
These records must be separately preserved, and without their
preservation the redundant hashes on the blockchain are useless since you
need both the original record and the hash to authenticate, and, in any
case, it would be pointless to preserve potential proof of the
authenticity of something that no longer exists.
I hope that this information can be of some assistance to you as you
consider the pros and cons of blockchain technology for particular
applications that might be relevant to your situation.
Best wishes,
Victoria Lemieux
Associate Professor, Archival Science
The University of British Columbia
On 2016-05-10, 10:22 AM, "Records Management Program on behalf of Steward,
David" <[log in to unmask] on behalf of
[log in to unmask]> wrote:
>Thanks Gary. I have seen the flurry of Blockchain messages over the last
>week or two. This was the first one I read, thinking I should probably
>spend a few minutes educating myself.
>
>At the risk of being perceived a Luddite...
>
>I realize the comments/questions I write here will have zero consequences
>on Blockchain use and technology nor should they. But this sounds like
>an idea that is designed to speed up production while minimizing quality
>assurance, to use a manufacturing comparison. Demming developed a
>similar model for production in the middle of the last century. In it,
>he taught that by having each person in the production chain inspect his
>or her own work that overall quality would be enhanced. It could be
>higher quality than the typical production-quality control model used by
>most of the industrial world. And it worked very well in environments
>where workers were dedicated to producing a great product. See Japanese
>products in the 80s.
>
>Before I spin off too far from Blockchain let me tie it back in. Using
>this technology to verify a transaction makes sense from a speed and
>verification perspective. Using previously agreed upon rules, the
>consensus tool doesn't have bias or emotions. It simply matches a
>numeric value to determine if what it found is what it expected. This
>part of Blockchain seems to be a pretty solid concept.
>
>My concerns are around Information Governance. In this article posted by
>Gary, and the only one I have read on the technology, the writer
>illustrates how information is duplicated and distributed across the
>entire permitted environment. Haven't we seen this before?
>
>Think about paper in organizations that had no centralized Records
>policy. Everyone made copies of anything they deemed important. This
>was because they didn't trust the system. Nor should they. If I had a
>document and thought I might need it again I would make a copy before I
>sent the original on to the next stage in the process.
>
>We hated these environments for good reason. They were costly,
>duplicative, and impossible to manage from a Governance perspective. It
>was a target-rich environment for discovery. And now we are looking at a
>similar structure in digital format.
>
>Another concern is for organizations that create their own
>documents/records as part of the greater process environment. In the
>Blockchain structure, don't they release this product to everyone? Won't
>multiple copies go out beyond their control? Once it is out there that
>organization has no more say in what happens to their information. Good
>luck with retention and disposition.
>
>And finally, is Blockchain a product designed to enhance security and
>privacy? I read that it is encrypted but there are many who have that
>key; everyone on the system. And all of the content is everywhere, not
>just in a central control environment. Does this enhance the data
>security or hurt it? If it is possible to steal information from any
>location that would seem to increase the risk, not reduce it.
>
>I also see benefits. There is incredible redundancy which increases
>preservation ability. It sounds like it improves the customer
>experience. And it drives some costs down by not having the
>clearinghouse or central authority. But are these benefits worth the
>exposure created by such a system? Will the desire to make information
>cheap and easy once again defeat the responsibility to do things right?
>I'm not saying that Blockchain won't work. I am asking if the
>fundamental concerns I have listed can be addressed in a manner that
>makes it a logical choice to manage our information. Beyond business
>transactions, what if this is seen as a good solution for health
>information, intellectual property, and personal financial details such
>as stock trades?
>
>Thanks for any insight from the List. Perhaps the entire discussion is
>moot as Blockchain might never take off beyond a few uses. Maybe it will
>never be anything more than a transactional tool and very little content
>will be shared. What is the potential? What are the markets? And what
>kind of information will be shared?
>
>Thanks for any insight and learning provided on this topic.
>
>David B. Steward, CRM IGP
>Director of Records
>
>HUSCH BLACKWELL LLP
>4801 Main Street,Suite 1000
>Kansas City, MO 64112-2551
>Direct: 816.983.8860
>Fax: 816.983.8080
>[log in to unmask]
>huschblackwell.com
>
>View Bio
>|
>View VCard
>
>List archives at http://lists.ufl.edu/archives/recmgmt-l.html
>Contact [log in to unmask] for assistance
>To unsubscribe from this list, click the below link. If not already
>present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of
>the message.
>mailto:[log in to unmask]
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|
