Everywhere one turns, there are papers, books, and blogs arguing the fundamentally transformative nature of blockchain technology. Consider this quote from a book called Blockchain Revolution by Don Tapscott and Alex Tapscott:
“If business, government, and civil society innovators get this [blockchain] right, we will move from an Internet driven primarily by the falling costs of search, coordination, data collection, and decision making — where the name of the game was monitoring, mediating, and monetizing information and transactions on the web — to one driven by the falling costs of bargaining, policing, and enforcing social and commercial agreements, where the name of the game will be integrity, security, collaboration, the privacy of all transactions, and the creation and distribution of value. That’s a 180-degree turn in strategy.”
The only thing that blockchain seemingly won’t be able to do is to obtain lasting world peace.
When you combine the scale of these claims with a widespread lack of understanding of what blockchain is, it is easy to see this phenomenon as a bonanza for consultants and new investment. And for fraud.
Let’s talk about how blockchain can change the way sourcing and procurement work. This is a deep dive into the way blockchain works, written in plain English, so that sourcing professionals can make up their own minds about when and how to adopt it, armed with an understanding of the underlying process.
I warn you upfront. It’s a little long.
Start with some first principles about data. You can’t understand blockchain without agreeing to some fundamental assumptions about the status quo blockchain seeks to displace.
The guts of the modern corporation are built with data. This data is stored in a structured way, typically in a centralized location, with controls in place on who can access it. Some people can read it, fewer people can add to it, and even fewer people can change the data that is already in place.
Sometimes the data is messy which means that it is full of “incorrect, incomplete, inaccurate, or irrelevant parts” in which case organizations need a trusted individual or group to edit it (determining what to include and what to leave out) before its use can enable the generation of actionable intelligence.
Anyone using the data needs to understand its origin. Some sources are more credible than others. People and entities are self-interested. Establishing ancestry is called data provenance: “records of the inputs, entities, systems, and processes that influence data of interest, providing a historical record of the data and its origins … [that] supports forensic activities such as data-dependency analysis, error/compromise detection, and recovery, auditing, and compliance analysis.”
The more unique, the more comprehensive, and the more trustworthy the data is, the more potentially valuable it is because data is only as useful as the quality of the decisions it enables.
This has three immediate implications.
First, whoever controls the database has massive power.
Second, the broader an individual’s access to a unique, clean, comprehensive data set, the greater their influence over the people who make decisions.
Third, organizations will take great pains to maintain and signal the integrity and quality of their data because it translates directly to the organization’s ability to create value. Trust is critical to modern commerce.
How Does Blockchain Technology Work?
A blockchain is exactly what it says it is: a chain of blocks. And a block is just a collection of data.
The blocks are chained together in an ingenious, sequential manner so that the order of the blocks is fixed and unchangeable. Together these blocks constitute a database. The data can be anything. It can be clean, or it can be dirty, structured or unstructured. The best way to think of a block is as a set of one or more transactions. Perhaps transactions in bitcoin, a “digital currency,” is the easiest example, but it could be anything. Some of these databases record nothing but transactions; one can think of these as ledgers.
If it is a public blockchain, anyone can see the individual blocks. By contrast, IBM has a good definition of a private blockchain: “A private blockchain network requires an invitation and must be validated by either the network starter or by a set of rules put in place by the network starter.” Somebody (or some set of rules) controls access; in a private blockchain, only entities with permission get to see the blocks.
The elegance of this technology comes from the way in which it stitches together the blocks, in either the public or the private blockchain context.
It takes advantage of something called a hash function. All we need to know is that this function can map data of any size to another combination of data of fixed size. I could take this entire article and, using a hash function, convert it into a 64-character combination of letters and numbers. One cannot go backwards and convert the 64-character hash into the original article. It is possible that different data could generate the same hash in what is called a “collision,” but blockchain technology applies mathematical techniques from the field of cryptography that make collisions highly unlikely.
Note that if I change one letter or one space in this article and run it through a hash function, the hash function will give me a completely different hash that bears no apparent relationship to the original hash.
Each block in the chain gets its own hash. But, it also contains the hash for the previous block in the sequence. This means that I cannot take one block and try to move it to another part of the sequence.
So, a block is characterized by the data it contains, the hash of the previous block in the chain, and its own hash.
A network of users maintains the blockchain. In a public network, anyone can join. In a private network, the organization that starts the network (or, the network members themselves) invites entities to join. And everyone is anonymous.
On the blockchain an employee in a large multinational corporation may be indistinguishable from a thirteen-year old girl in the middle of Iowa.
First, someone must validate the individual transactions that compose the block. Then, this person must create a block of these validated transactions. Finally, the network must accept the block and add it to the blockchain.
For an individual transaction to be valid, the person proposing the transaction must communicate sufficient information for a third party to validate it. In the case of bitcoin, the individual sending the transaction transmits a bitcoin wallet that consists of two things: a history of the individual’s bitcoin transactions, and something from public key cryptography called a public key. The history of bitcoin transactions effectively tells anyone what the person’s balance is, so that’s why it is called a “wallet.”
At this point, it is useful to learn how public key-private key encryption works. In this framework any individual has two keys: a public key and a private key. This individual uses both keys to encrypt a message, but anyone else only needs one key to decrypt a message. A sender keeps the private key to herself, while distributing the public key to anyone she gives permission to decrypt the sender’s messages. Note that here cryptography is as secure as she keeps the private key.
For example, if Person J wants to send a message to Person K, J would encrypt her message with both of J’s keys and K would decrypt the message with J’s public key, verifying that it came uniquely from J.
A digital signature involves one further step, combining hash functions and public key-private key encryption. In our previous example, person J generates a unique hash for the message and then encrypts this hash with both of J’s keys. J sends the unencrypted message, J’s public key and the encrypted hash to K. K decrypts the hash using J’s public key, and then recalculates the hash for the unencrypted message. If the hashes are the same, then K has verified that J sent the document and the document is true, in effect “signing” the document digitally.
Let’s consider a person named Alice trying to send 1 bitcoin to someone named Bob.
Alice inputs her private key and transaction details into her bitcoin software. (Recall the bitcoin software already contains her public key.) The software generates a digital signature for the transaction and sends the digitally signed transaction along with a copy of Alice’s digital wallet (which includes her public key, recall) to the network for validation and a script to verify the transaction. Of course, nobody knows that Alice is Alice and that Bob is Bob. Each of them is represented by a string of letters and numbers; they are just accounts.
People in the network consolidate transactions they receive and validate into blocks of transactions and add the hash for the most recent block.
But, the blockchain is decentralized in the sense that the network of computers must agree to add the block. How do you add blocks in this decentralized context?
There’s one way called the Proof-of-Work scheme, the best example of which is bitcoin. There are others such as Proof-of-Stake, Delegated Proof-of-Stake, and the Practical Byzantine Fault Tolerance Algorithm which you can find here. For the purposes of simplicity, I will stick with Proof-of-Work.
For the network to agree to add a block to a chain, members of the network examine the hash generated by the block. This hash must have a specific characteristic: it needs to have a specified number of zeroes at the beginning of the hash. (At the time of this writing, it is 17 zeroes.)
To do this, one needs to add a number (a number used once or “Nonce”) to the bottom of the block (in addition to adding a transaction that pays the person seeking to add the block to the chain a reward — currently 12.5 freshly-minted bitcoins per block, but declining as the number of bitcoins in circulation hits certain higher breakpoints — and a transaction fee for every transaction in the block) so that the hash for the block starts with the requisite number of zeroes. Solving this problem requires generating a random number, adding it to the candidate block, calculating the hash, and seeing if it meets the test. If not, then rinse and repeat. This process of calculating the correct random number is called “mining.” There is no analytic solution produced by an equation. Miners just apply brute force computing power. This is a race in which first prize is the combination of the bitcoin reward and the transactions fees. Second prize is nothing.
Once the first person in the network has mined the correct number, he sends it to the rest of the network for verification. Others calculate the hash for the block including the proposed nonce and verify that the hash has the requisite number of zeroes; this is straightforward. Each node adds the block to its local version of the blockchain. Since each node is following the rules, each local blockchain will be identical. “There actually isn’t anything that is ‘the blockchain,’ rather it is just that all nodes who are following the same consensus rules will accept and reject the same blocks so all nodes using those consensus rules have the same blockchain.”
Mining is spectacularly energy intensive. The degree of difficulty in mining, i.e. the specific requirements on the hash to be accepted by the network, can introduce delays and costs. This is a feature of the approach to avoid fraudulent manipulation, for example. Public blockchains are much more technically difficult than private blockchains for this reason in that the test they impose on minders needs to be more demanding for security purposes.
One interesting possibility is that of a so-called 51% attack.
If an attacker can control more than half of the computing power of the network, then they can do several things. They can block others from mining new blocks successfully because of the network’s requirement for consensus, in so doing theoretically monopolizing the creation of new blocks and the associated fees. They can refuse to include transactions into their blocks. They could destroy confidence in the network by “double-spending”: sending a transaction and then immediately reversing it so that they could spend the relevant coin again.
Some vendors may not accept payment until they see the a certain number of confirmations: subsequent blocks with more transactions added to the chain after the block containing the transaction in question. The more subsequent blocks that rely on the original block, the more reliable the pending transaction is deemed to be, because it would take a bad actor an increased computational effort for each additional block. Of course, this adds time to process the transaction.
What Are the Properties of a Blockchain?
There is a proliferation of blockchain approaches differing in terms of the way transactions and blocks are verified, for example. However, the properties are largely the same.
· Distributed: there are common versions of the database held on every node in the network
· Decentralized: no individual authority controls the database; anyone in the network can propose additions to the database
· Unchangeable: it is very difficult to change a block once it has been added to the chain and it gets exponentially more difficult to change a block, the older the block is (because of the requirement to change all subsequent blocks)
· Potentially Open: if the blockchain is open, anyone can see it
· Auditable: because of the sequential nature of the blockchain, users can audit the flow of transactions from start-to-finish
· Anonymous: on the blockchain, nobody knows who you are
· Energy Intensive: the brute force nature of mining makes it very computationally intensive, using a great deal of energy (successful miners earn rewards and fees to compensate them for the energy they expend and for the risk of not winning)
· Potential Delays: the difficulty threshold of the proof-of-work and other measures to interdict attacks can slow down transactional processing times
The appeal of the blockchain is that one can transact with anyone else, without knowing anything about them, and without an intermediary because of the trust everyone in the network puts into the blockchain process.
How does this compare to the status quo that blockchains seek to replace?
· Concentrated: the database exists in one place
· Centralized: one agent controls the database and may restrict who can add to the database
· Changeable: the centralized agent can edit what goes in and what comes out of the database, including historical additions and deletions
· Likely Closed: most traditional databases are closed with limited access
· Auditable: using best-of-breed data provenance methodologies, centralized databases can still be auditable
· Named: typically, these databases do not conceal identities, although there are techniques to anonymize data, if necessary
· Not Energy Intensive: accessing or editing the database does not require massive computational power
· Instantaneous: there are no delays in adding to or retrieving records from a database
The principal calculus when choosing whether to replace a traditional database with a blockchain comes down to trust in the process.
· What is the cost of having a central authority in control of the database? How much of a transaction tax do they impose? What are the benefits that a centralized authority figure brings to the table?
· How much value does the operator of the centralized database capture for himself? Is this acceptable?
· Will the central authority manipulate the database for their own purposes by removing data, or adding other data?
· What is the nature of the data in the database? Is it clean? Is it structured? Is it uniform?
· What is the cost of having an incompetent central authority in control of the database? If they make mistakes in operating the database, how costly is it to fix? Is fraud more of a risk in a centralized database?
· Do I care about the counterparties with whom I transact? Is this a one-off transaction, or will I have an ongoing relationship with the other person? What is the impact on my reputation from the way I deal with others?
· Will transaction processing be faster with a blockchain? Will it be less energy expensive?
What Applications Make Sense for Sourcing and Procurement?
At least initially, I think that there are four types of application for blockchain in sourcing and procurement:
· Reputation Assessment
· Transparent Supply Chains
· Smart Contracts
Users Could Award One Another Tokens to Reward Outstanding Reputation Assessment
In strategic sourcing, buyers research a market for a good or service they are looking to purchase; solicit competitive bids from vendors; and select a winning submission based on criteria in the original request for proposals. One of the key things that intelligent buyers should look for is information tied to the prior performance of the vendor. How have they performed on similar contracts in the past? With whom have they worked previously? Who can I trust to give me useful information about vendors in a space?
One could imagine a token issued and traded through a blockchain where buyers can award tokens to others based on the quality of the information exchanged. For example, if Buyer A asked Buyer B for information about Vendor 123 and Buyer B’s information turned out to be correct and useful, A could award reputation tokens in the same way that one would send bitcoin to another user. Here the tokens may not have any monetary value, but they could carry non-pecuniary import if Buyer B wanted to create a reputation as someone professionally competent in the community of buyers.
Transparent Supply Chains Could Help Buyers Meet Governance Guarantees
Currently, it is difficult for many buyers to look through their supply chains to verify the sourcing of goods upstream. How can a jeweler verify that the diamonds she is purchasing were not mined in prohibited locations? Or, how can a buyer of textiles guarantee that no child labor was used in fabrication?
One could imagine using the blockchain to tag the movement of goods through the supply chain in a transparent manner.
Blockchain Could Cut Costs in Procure-to-Pay Transactions
Procure-to-pay involves purchasing goods and services from vendors, usually in the context of a pre-established catalog or set of approved products, typically below a specified threshold of contract value (say, $100,000), and it also includes processes such as the exchange of invoices, delivery, and payment.
A blockchain implementation could mean faster and more efficient processing of invoices, with attendant faster payment cycles, all within the context of an easy audit process. This obviates the need for conventional distributor-reseller models, for example. This would be even easier with shared standardized invoice and payment processing procedures.
Smart Contracts Can Automate Contract Management
Deloitte defines a blockchain-based smart contract as “self-executing code on a blockchain that automatically implements the terms of agreement between parties.”
Put more simply, smart contracts are a way of programming business.
If a contract is a set of rights and responsibilities, then a smart contract is a way of translating these into code in the blockchain so that actions happen in response automatically to performance over the life of the contract.
For example, Company A may contract with Vendor B for the construction of a building, including a payment schedule driven by the successful completion of certain milestones (lay the foundation, build the frame of the building, etc.). In theory, a smart contract can react to changes in the blockchain that prove the accomplishment of these goals by making the relevant payment.
Blockchain May Not Be Suited for Broader Strategic Sourcing
Beyond the reputation application, the fundamental problem EdgeworthBox has identified with strategic sourcing is the absence of trust, not in the identity of the participants, but in their intent.
Buyers do not trust sellers. They worry that vendors, particularly in the intelligence-gathering phase, will try to “shape” the request for proposals to favor the vendor solution disproportionately, even if it is not the optimal solution for the buyer’s problem. That is, after all, how so many salespeople today are trained to behave.
Vendors do not trust buyers. Vendors believe that, in many cases, the process is “wired” for one company, that buyers are going through the compliance motions of soliciting competitive bids, and that the process is a waste of their time and expense in preparing what can be very detailed proposals. Suppliers also do not trust buyers to keep their responses confidential. Suppliers worry that buyers will take their proprietary information and share it with their competitors.
This mutually assured distrust manifests itself in dilatory and expensive bureaucracy designed to protect buyers’ interests, discouraging vendors from bidding. Fewer vendors responding means less competition on price and service and, more expensively, fewer solutions from which to choose. Lose/lose, indeed.
As this Deloitte study shows, 92% of the 26,000 blockchain projects on Github over the past two years are dead. Just because you can put something on a blockchain doesn’t mean you should, apparently.
Should the strategic sourcing process be on blockchain?
Here’s a great flowchart from UC Berkeley to think about whether to go on the blockchain or not.
Let’s say that we had a database that users were employing to improve their strategic sourcing process. This is part of the EdgeworthBox approach. In our case, there is only one entity updating the database, so it needs to be centralized.
But, let’s suppose that we let our users update the database. EdgeworthBox still doesn’t require users to trust one another because, in our platform, we act as gatekeepers to the network. We pre-screen buyers and suppliers in our network with the same criteria and documented evidence that large organization buyers use to qualify vendor partners. Buyers and vendors on the EdgeworthBox network don’t need to trust one another if they can trust and verify the EdgeworthBox vetting process.
Alternatively, one could imagine a scenario, eventually, in which vendors could send to buyers directly all the required information and evidence, in a standard format, wrapped with a digital signature.
And, in our case, there is no issue with our curation of the database. EdgeworthBox has no incentive to remove or manipulate the data in the database; we are motivated to get as much clean, valuable information into our database as possible to deepen our users’ engagement.
Nor, do our transactions depend on one another. If the City of XXX buys trucks from Vendor 123, such a transaction has nothing to do with the last transaction in which Vendor 123 sold trucks to anyone else. It’s not like a digital wallet in a cryptocurrency transaction where I need to verify balances by checking all prior transactions for the sender.
Therefore, we haven’t used blockchain in our technology to date.
In Strategic Sourcing, Solving the Right Problem Is More Important than Using the Sexiest New Tool
We have thought about blockchain intensively and we will be careful about adding this functionality. We do not believe that such a radical change in business processes is necessary to obtain a better sourcing outcome.
Our approach is to flip the script on what sourcing has become from being a function of minimizing risk subject to the requirement that the buyers needs to purchase something to be a function of optimizing the outcome subject to the constraint that buyers need to minimize risk. At EdgeworthBox, we think that the best way to do that is by enhancing the trust that both buyers and sellers have in the process through networks of people with aligned interests and chaperoned transparency.
Perhaps the more important prior objective should be to get people using one standard database, as in this example of competing and self-defeating blockchains-for-blockchains’ sake in the shipping space. Then, switching them over to a blockchain, leveraging the maturation of the technology and its increased adoption, may make more sense for conservative sourcing professionals who know how much is at stake.
Time will tell. We’d love to talk to you.