What should governments consider when engaging in blockchain?
Last September, Chief Security Engineer Dr. Evan Sultanik was on a panel hosted by the Naval Postgraduate School’s Distributed Consensus: Blockchain & Beyond (DC:BB) movement, where faculty and students there seek opportunities to learn and share knowledge, research, funding, and events focused on distributed consensus technology.
The panel of nine government, academia and industry experts discussed how blockchains, digital assets and other Web3 technologies intersect with national security challenges. Dr. Sultanik discussed how the United States could help push global adoption and take a broader strategic view of blockchain and Web3 technologies.
He talked about the inherent limitations of blockchain technologies and the Web3 movement and also made suggestions from a training perspective that could lead to a more robust ecosystem. We have summarized the most important parts of that discussion here.
What are some important things to consider when using blockchain technologies for a project?
It is fundamental to better understand the trade-offs one must make when using a blockchain and its security implications. Everyone at this point is aware that using a blockchain has significant additional costs in terms of distribution and the cost of interacting with smart contracts. The costs are gradually decreasing with the transitions to the new forms of consensus and higher-level protocols, but there is still a significant difference.
You must realize that all data stored on a public blockchain is publicly available. Anyone can review the entire history of each account or contract and understand the implications of those actions. You must do something extra to ensure privacy if it is a requirement for your system.
The majority of participants in a public blockchain are not trusted. You shift trust from what would otherwise be a central authority to other entities that you may or may not have control over. Not only do you trust the developers of the smart contracts that your system interacts with, but you also inherently trust the developers of the technology stack that runs the blockchain in question. You trust the node software, the mining hardware, the mining software, the mining pool protocol, and everything else. A failure in any part of that stack can cause the whole thing to collapse.
Blockchains allow developers to prototype new ideas quickly. You don’t have to worry about things like setting up infrastructure, and you don’t have to worry much about DevOps because it’s all handled by the blockchain itself. It allows you to significantly reduce the time between when an idea is created and when it is in the hands of users. But that cycle also comes with risks because a tight development cycle can lead to poorly tested or designed protocols or sloppy development, leading to errors with significant consequences, such as being a major target for attackers.
Another thing that makes DeFi, blockchain and Web3 so appealing is that you can prototype quickly and instantly connect your application to the entire ecosystem. Since the blockchain acts as a vast shared database, contracts and assets created by competitors can be made to interact with each other in ways that would be discouraged if implemented on a traditional centralized platform.
This composition has a price. It’s hard to reason about the system because you suddenly have to understand all the different contracts that created these tokens. There is a different code in each case. And your code suddenly interacts with the entire code universe on the blockchain. So you need to be aware of all these other externalities and third-party components that your app might interact with.
We’ve seen this complexity play out recently with new types of financial instruments and technology that have become available, especially on Ethereum, such as flash loans or maximum recoverable value, which are really deep technical concepts. Yet millions of dollars have been lost because a bunch of different DeFi apps have been put together in a single transaction in a way that no one intended to be put together.
Computer scientist Leslie Lamport wrote in 1987, “A distributed system is a system where bugs in a computer you didn’t even know existed can render your computer useless.” This is still true today and will always be true in blockchains.
Should the US care about blockchain technologies, and if so, what is the best application for government?
It’s a matter of national security for the US government to get involved in blockchains: Aside from perhaps lost tax revenue, Uncle Sam doesn’t really care if you lose your Bitcoin. But Uncle Sam should don’t care if North Korea steals it. US adversaries are already exploiting these technologies to circumvent sanctions and undermine our markets.
It is more productive to ask, “Can blockchain and Web3 technology ever be made secure? If so, how?” The US government must promote research and innovation to answer this question in order to remain relevant and remain a world leader in distributed ledger technology.
How should the US handle the training regime needed in the Web3 area?
There is a great need to change how we train the incoming workforce because traditional software development expertise does not directly translate to Web3. I have friends who have no background in computer science, but they learned a programming language, wrote a mobile app and are now millionaires. They have no technical knowledge of what a phone does, how iOS or Android runs, or how the hardware works. They only needed to know one programming language and that was enough for them to build something very popular and effective.
That is not true for Web3. Knowing the whole stack is useful when creating smart contracts, because you need to understand the compiler you’re using. You need to understand the virtual machine that is running. You need to understand Byzantine, fault tolerant and consensus protocols. You should understand zero-knowledge proofs or zk-SNARKs. You should understand all these esoteric technologies, and very few experts know any of them, let alone all of them. You have to be an expert at them to avoid all the pitfalls and footguns.
We need policies that motivate people to enter the workforce with these necessary skills. At Trail of Bits, we have developed a Blockchain Security Apprenticeship because it is difficult to find people with all the necessary skills in this competitive market. Some security professionals know how to analyze a C++ program or a mobile app, but they have no idea about blockchain. And then you have blockchain people who have no background in security. So we developed this internal program.
For mobile app stores, there has always been a low barrier to entry for people who want to get involved in the app economy. With Web3, that doesn’t seem to be the case, but there is a lot of activity in this area. What more needs to be done to bring developers to a level where blockchain is mature from a security perspective, and which entities or organizations should lead that effort?
The barrier to entry is surprisingly low for Web3 as well, which is part of the problem: Web3 development toolchains have been modeled after familiar toolchains from traditional app development. Developer friendliness has been prioritized at the expense of security. We need to modernize and improve the tool to turn the balance in this priority.
Conclusion
It is not enough for governments to simply express interest in securing blockchain technologies. Real, targeted investments must be made. Beyond the design of secure architectures, languages, compilers, and protocols, these investments should also include training a robust workforce to meet tomorrow’s Web3 demands.
If you’re considering whether a blockchain could be the solution to a problem you’re trying to solve, we recommend our operational risk assessment titled “Do You Really Need Blockchain?” This will give you a thorough review of the benefits and risks you can take.
Finally, if you want to hear more from the other experts on the panel about blockchain technologies and national security, you can watch the discussion in its entirety at:
*** This is a Security Bloggers Network syndicated blog from Trail of Bits Blog written by Trail of Bits. Read the original post at:
