Block chain

Blockchain as understood from an Expert

I have been working in distributed systems for decades. The fundamental problem when we have multiple active sources of information is finding a way to achieve consensus – agreement about what has happened. The simplest way to reach a consensus is to have one decision-maker. If there is only a single source of “truth” as to what happened, anyone else that wants to know queries that truth.

However, disparate decision-makers often control individual resources in the real world. The challenge is to ensure that all decision-makers involved in a given event agree on the outcome. In Computer Science, it is databases that first had to face this problem.

A single database can practice techniques that ensure the consistency of events. What this means is that even if multiple pieces of information within the database need to be modified to carry out a particular operation, it is possible to ensure that even in the face of failures, the information within the database is consistent and thus definitive.

A typical model I have used when teaching this basic concept is a bank machine that dispenses cash. If you walk up to that machine, insert your card, enter your pin, and ask to withdraw $20, multiple distinct bits of information must all happen, or none happen:

  • You need to authenticate yourself (card + pin)
  • Your account needs to be debited $20
  • You need to be given $20 in currency

If anything fails in any of these steps, nothing should change: your card is returned to you, your account is not debited, and you don’t receive your cash. Such an “in balance” system is said to be consistent.

Let’s suppose that you use the ATM of a different bank than where your money is stored. Now we have distinct actors:

  • You, with your card and pin
  • The bank machine you are using
  • The bank that owns the bank machine you are using
  • The network that coordinates between the bank that owns the bank machine you are using
  • Your bank, notably your account with that bank.

Everything needs to work correctly, but now you have distinct actors. Each bank trusts the network and has presumably been vetted so that the banks and the network are all trusted. So, when the bank machine you are using verifies that you have the card and know the PIN, however, that is done is enough for the network and your bank to trust that you are who you say you are. Then the steps to dispense your funds are the same. You don’t get any cash if anything goes wrong, and your account isn’t debited.

I chose a bank as the example because banks routinely use ledgers – a list of transactions that move funds between accounts – or into your hand. Electronic ledgers are a bit different than paper ledgers in that the latter is more difficult to change after the fact since that often leaves marks. Indeed, the best practice is not to change an incorrect entry but rather to add another transaction to the ledger to correct the previous error. So, for example, we might void a transaction by posting the inverse transaction to the ledger.

How can we know when an electronic ledger has been modified? First, we could record it in something difficult to change after the fact, such as write-once media. Another approach we can use is to break our ledger up into sets of transactions. Logically, you can think of this as being like a page within a ledger. For a computer, we can then compute a “checksum” over the values within that ledger. I won’t bore you with the details, but it is possible to calculate such checksums to make it very difficult to change the records within the set and still end up with the same checksum. So, one way to protect an electronic ledger is to compute an additional value, called the “hash” or “checksum,” that depends upon all of the ledger entries within a given set. If we publish the checksums in some fashion, we now have a way to know that the ledger has not been modified after the point the checksum has been published.

A blockchain adds one more bit of information to the ledger entries: it also incorporates the checksum of the prior set of ledger entries. In other words, if we think of our ledger as being a series of pages, the first entry on each new page happens to be the checksum of the previous page. Then we compute a checksum for the new page with all the transactions. This “chains together” these sets of transactions. Now, to change the value of an older ledger page requires changing every page after it. So we actually only need to publish the most recent checksum to verify the entire chain.

This is what creates a “blockchain.” A “block” consists of:

  • The checksum of the previous block
  • A set of transactions;
  • Any other data we want in the block;

From this, we can compute the checksum of the current block. The key to “preserving” this “blockchain” is publishing those checksums. That is (more or less) how blockchains like Bitcoin and Ethereum function. They have some additional steps, but they work by publishing the ledger pages with their checksums – the blocks that make up the chain. When enough “nodes” (computers) in the network accept a new block, it becomes “confirmed” and challenging to change. Since it is easy to compute those checksums, the blocks are easy to confirm. Changing an existing block on this chain does not work because nodes do not permit changing history. Anyone with the blockchain can confirm it. The other nodes will ignore someone that attempts to change it since the changes won’t match the published information.

Thus, the real benefit of using a blockchain is that it provides a way to reach consensus and then confirm that consensus that is resilient in the face of bad actors. The simple implementations of blockchain generally require at least a majority of the participants to collude in order to rewrite the blockchain. On top of that, the cost of re-computing the blockchain, which is required to “change the past,” goes up as the blockchain proceeds.

There is a fair bit of hype around blockchain; some are deserved. In future posts, I will discuss more about some of those uses, with an eye towards how I consider them as an expert.


Effective Mechanisms for Authorship Determination

Recently one of my clients contacted me and asked about what I know concerning “determining authorship.” I pointed out that I have a published paper on the subject (Plagiarism Reduction). An integral part of doing that work was learning how the tools we use to detect plagiarism actually work. But, of course, my work was about code plagiarism (a common problem in education and my practice) and not prose plagiarism. The case my client asked about was attempting to determine the authorship of a written work. The facts of the case involve collaboration between a group of authors that is being unravelled (by lawyers, of course). Thus the question arose if there is a way to automatically identify which sections were written by which authors.

Thus, I agreed to write about this area to provide some background and point to potential tools. First, I want to touch on the fundamental reason this becomes a legal issue: any work of authorship, whether it is for entertainment, business, course work, or a computer program, comes with a significant right: Copyright. While the laws about copyright vary somewhat from country to country, overall, there is pretty broad agreement about these rights and their international interpretation. This is based upon an agreement (the “Berne Convention“) first signed in 1886, though amended over the past few years. Since most of my work is in the United States, I am most familiar with Copyright law from a U.S. perspective. Copyright protects a specific expression. In that regard, it is a narrow intellectual property right. Thus, if we each write a piece of computer software that does the same thing, we would each have a copyright on our implementation. If part of the code turns out to be the same, that could be because there’s only one way to express something, or it could be since one of us copied it from the other.

How do we tell when “identical” copyright material is, in fact, the same? Suppose I write a computer program in FORTRAN. In that case, I then use a unique piece of software called a compiler that translates the instructions in the programming language into instructions that the processor in the computer understands. The compiled version of my program is a derivative work. The rights of the original author are not eliminated in the derivation process. This is important because software, in particular, is often re-used. Indeed used software is generally better than new software because the latter is more likely to contain errors (“bugs”) that will need to be found and fixed.

Thus, we usually consider the compiled version of the computer program to be “the same.” A small change to a literary work does not eliminate the copyright. We’d consider them to be “the same” even though they are not strictly identical. So, when we’re trying to figure out who wrote something, the question becomes how to determine that. A wealth of techniques have been developed over the years to do authorship analysis. These are motivated by historical concerns (e.g., “who wrote this anonymous text,”) legal concerns (“is this the same code,”) and authorship questions (“did the student submit work they copied from elsewhere.”)

Commercial services, such as Turnitin and Grammarly, have productized some of the techniques that have been developed over the years and can draw upon a plethora of public and private sources, so they can take a written work and map it to other examples they have seen previously. For instance, in the CS 6200 course at Georgia Tech, which is the one where I implemented the plagiarism reduction intervention that was effective, we used a well-known tool called MOSS (“Measure of Software Similarity”). MOSS uses an interesting technique: it compares the program’s abstract syntax tree against other implementations. Doing this strips away the elements that are not germane to the program and instead focuses on what the program does as captured by the signature of the abstract syntax tree (AST). Once a piece of software source code is “big enough,” it becomes possible to say that matches in the ASTs are unlikely to be coincidental. So, small bits of code can be identical, but one cannot conclude much. However, when we have 100+ of those small bits of code, and it turns out that 50% of the code has the same AST, then we have strong evidence of shared heritage.

One approach I have seen in more traditional literary works is similar to this AST style comparison, but it is not the only technique. Since I periodically review the literature on this topic, I took this opportunity to highlight some interesting papers that I found in my most recent search. Increasingly, I see statistical machine learning techniques used to facilitate rapid, automated detection.

In “Authorship Identification on Limited Samplings,” the authors refined machine learning? (ML) techniques to find those that are “the most efficient method of authorship identification using the least amount of samples.” They do an excellent job of summarizing the ML techniques in use today: Naive Bayes, SVMs, and neural networks. Those go beyond the scope of what I want to write about today, but they are effective and frequently used techniques for finding patterns in large data sets, such as written works.

In “A Framework for Authorial Clustering of Shorter Texts in Latent Semantic Spaces,” the authors look at using unsupervised learning (a technique in machine learning that does not rely upon prior data for “training”) on document clusters to identify similarity for short pieces of text (around a paragraph long). This technique could help take a single document and split it into sections and then apply these techniques to the collection. One would expect the works of multiple authors to form “clusters” due to the similarity between different paragraphs attributable to each author. This work is intriguing though the authors do caution: “[t]horough experimentation with standard metrics indicates that there still remains an ample room for improvement for authorial clustering, especially with shorter texts.” From my reading, I suspect their techniques would be appropriate for a small number of authors. This could then be applied either to the case my client first asked about (joint authors in a large document) or an educational setting (to identify “patchworking” of a few different documents together into a single document submitted by a student.)

Another intriguing approach I found was the idea of using contextual considerations. For example, in “Semantic measure of plagiarism using a hierarchical graph model,” the authors extracted “topic feature terms” and used them to construct an acyclic graph (“hierarchical”) of these terms. They then used graph analytic techniques to identify the similarity of specific sub-graphs [admittedly, I have concerns that this approach may not scale well since my recollection, since confirmed, is that sub-graph isomorphism (“these two subgraphs are equivalent”) is known to be difficult.]. One intriguing outcome of this is that it allowed the authors to find plagiarism where the words were changed, but the meaning was not – much like MOSS does with computer programs by examining the ASTs rather than the plain text.

This described technique reminded me of Carmine Guida’s work at Georgia Tech for plagiarism detection. His Master’s Thesis was “PLAGO: A system for plagiarism detection and intervention in massive courses.” I was peripherally involved in his work while he was doing it, and aspects stand out in my mind today. The tool that he constructed (and I had an opportunity to use) related to using explicit techniques for identifying common authorship: n-grams (a technique for splitting text into sets of n words for analysis), stop words (used to detect sentence structure), structural matching (using the stop words), and stemming (using the root stem of an analysis word, rather than the full term). However, one of the most intriguing aspects of his work was stylistic evaluations. When the style of writing changes in a text, it often indicates a switch in authorship. For example, he talked about changes in sentence length being one indicator in our discussion about this. Word complexity is another. Thus, structural techniques like this can identify structural similarity and stylistic shifts suggesting a change in authorship.

Oren Halvani’s Ph.D. thesis also seems relevant: “Practice-Oriented Authorship Verification.” Halvani focuses on authorship verification, which is truly core to the original question that my client asked and prompted me to go back and look at current work in the fields. Again, Dr. Halvani’s work is directly relevant: “these characteristics can be used to assess the extent to which AV methods are suitable for practical use, regardless of their detection accuracy.” His work explores specific mechanisms for verifying authorship, providing both a theoretical and empirical basis for employing these techniques.

This stroll through current work confirmed what I had known was previously valid: this is an active area of research. Tools such as Turnitin and Grammarly may be sufficient to my client’s objective, but if not, there is a vast body of recent work that shows it is possible to do this. Of course, if there’s a commercial solution available that can be used, it is likely the best thing to do. I did note that Turnitin had some reasonably significant limits to the amount of analysis one could do in this regard. From my reading of their website, the size of the text being compared had size limits and required commercial accounts (see their page about iThenticate, which would be used for comparing a small set of non-public texts.)

In my use of plagiarism detection tools, I find that I still have to confirm the findings of the tools. Sometimes there are “boilerplate” aspects that the tools do not detect and exclude. Sometimes, the tools do not consider things that support claims of similarity to me (e.g., in code, the comments and debug strings are often clear examples of code re-use). In the end, having a tool alone is not sufficient for having an expert use the tools to find suspect areas and then explain why specific regions represent plagiarism.

In this post, I have discussed some of the background related to document plagiarism. However, this is not the only way others can co-opt that information. In patents, the author provides a detailed description of an invention in exchange for a limited monopoly on using the invention. In trade secrets, the owner of the secrets does not describe them publicly and relies upon their secrecy. If someone else independently discovers the secret, their protection is lost.

In my IP expert practice, much of my work is related to trade secrets. There are two common scenarios that I see routinely: (1) someone thinks what they know is new and innovative and a secret, or (2) someone thinks what they learned is well-known and not secret. Trade secrets can be powerful and fragile but common in technology cases. Many technologies are “well known” yet aren’t known to someone who rediscovers them. This is a discussion for a future post!