5 Myths of Blockchain for Government

Blockchain-based solutions hold enormous potential for government agencies. Federal leaders understand that blockchain could help their agencies effectively deliver public services, process payments, share data securely, reduce inefficiencies in the supply chain, and more. Yet, as they start to pilot public-sector applications using this emerging technology, chief information officers may have preconceived notions about what blockchain is, what it isn’t, and what it can help them achieve.

Here are five key myths about blockchain for federal organizations—and the reality.

Myth No. 1: Building blockchain solutions only involves instantiating a blockchain and implementing blockchain-specific software.

The Reality: Actually, the majority of the software implemented to support a blockchain solution is considered “off-chain,” or software not running on the blockchain itself. Every blockchain solution needs a core set of components for robust transaction handling, secure key storage and cryptographic operations, fast lookups based on secondary indices, and business logic that governs how users interact with the blockchain solution. In addition, your organization may need to implement purpose-built components that enable functionality specific to the use case such as decentralized file storage or secure key exchange mechanisms.

Myth No. 2: Blockchain integrates cryptography, so the platforms are inherently difficult to hack.

The Reality: A blockchain’s security is in part centered on the confidentiality of private keys. They let users confidentially identify themselves on and interact with a blockchain network. Should these keys be compromised, malicious parties could impersonate users and change data on the blockchain without users’ permission. A core design element of blockchain solution architectures is to minimize key compromise while maintaining system usability and adoption. Relying on users to manage their own keys using easily compromised wallet software is often not the answer.

Myth No. 3: We’ll be able to easily integrate blockchain with our existing, real-world systems and processes. Achieving interoperability won’t be difficult.

The Reality: It’s true that developers can easily create smart contracts that enforce complex rules and agreements that rely on data users have supplied directly for this purpose. However, the real challenge comes with enforcing rules that rely on information external to the blockchain. The standard technique for incorporating external information into smart contracts is to implement custom, off-chain services that work alongside a blockchain. Once data leaves a blockchain system, however, it becomes extremely difficult to control what an external system may do with that data. For example, it would be hard for a blockchain system to enforce the number of widgets a factory is licensed to produce when the factory already has the schematics necessary to produce the exact number it wants.

Myth No. 4: We’ll be able to rely exclusively on the contemporary methods and approaches common in the blockchain community to build our blockchain solutions.

The Reality: In fact, when your organization builds its blockchain solutions, a lot of the design and engineering work is focused on custom software and tooling. The most widely used blockchain implementations that support smart contracts, Ethereum and Hyperledger, have only been around for about 3 years. This means that they’re still far from being fully mature platforms with robust tools, patterns, approaches, and a clear sense for how to solve a broad range of industry and government use cases.

Myth No. 5: We’ll be able to simply design and implement software that runs on a blockchain in ways that allow for agility and frequent business process changes.

The Reality: Changing processes and how stakeholders interact with them are a reality of supply chain and should be embraced as part of the engineering that goes into any blockchain solution. For example, smart contract systems can be designed with change in mind, but that must be factored into how the contracts are designed and developed. That said, after smart contracts are deployed and start to be used, they begin accumulating information that’s difficult to migrate to a new set of contracts if a change needs to be made to the contract code itself. That’s why the most successful blockchain systems and smart contracts in production are built for applications whose business processes have reached a reasonable degree of stability.