The discussion and debate around the DAO vulnerability raises questions about trust and the human factor in the evolving realm of distributed ledger technology, Sean Neville, co-founder and president of Circle, noted in a Medium blog. Trust in the safety of assets and data in blockchain…
The discussion and debate around the DAO vulnerability raises questions about trust and the human factor in the evolving realm of distributed ledger technology, Sean Neville, co-founder and president of Circle, noted in a Medium blog.
Trust in the safety of assets and data in blockchain systems does not depend on human gatekeepers, Neville noted. But governance over software deployment of specific implementations still requires votes of trust.
Everyone in a peer-to-peer network implicitly if not explicitly executes trust decisions in the software, its infrastructure and the contracts and apps that run on top of the software, Neville observed. Everyone who joins the network makes such trust decisions by investing in assets, running nodes and relying on the asset data in the ledger(s), depending on the network’s executed logic, and adding quality-of-service (latency, throughput, etc.) dependencies between the system or other systems in their professional and personal lives.
But Neville asks: what happens when the system works as designed based on votes made with assets and CPUs but crosses a threshold that invested counterparties and humans view as a breach of fiduciary duty? Can one intervene to change the system to add safety controls to apply retroactively and change the history that has been agreed upon and must be immutable with regard to such human interference?
Can one make retroactive changes if the infrastructure is in “beta”? In order to preserve the future health of the system, its promise to be the greatest global distributed VM and its health, extraordinary measures might be required that would later be unacceptable. Is the system’s health compromised by such decisions during this period?
Neville observed that the issue is similar to classic thought experiments that are popular in the artificial intelligence community, such as the “fat man” variant in “The Trolley Problem,” if the “fat man” is the type of trust in human gatekeepers that should or should not be surrendered. The community is on the train together and can vote on the decision.
As for what should happen with Ethereum and DAO, Neville does not presume to say. But he remains bullish on Ethereum as a distributed computing platform.
Neville asserted, however, that the discussion over trusting app code that runs on blockchain infrastructure and around the governance of blockchain software development is important and fascinating. It remains rooted in a small Venn diagram of humans, not software, including node runners, vocal community members, developers and investors in distributed ledger assets.
That everyone participates in a consensus system does not yet remove trust in fallible humans for governance, Neville noted. This is not to say the trust is misplaced, but only that it simply exists and that technology has not magically removed it in the way it has created a way to eliminate the requirement to trust humans to control asset data.
It is possible, in theory, to enforce safeguards with a type of smart contract container, or by means of a review process around the way smart contracts integrate and deploy, or to have a type of risk assessment manager or clever tooling on top of improving the programming semantics around developing a smart contract app code.
However, if or when those controls become insufficient, and the majority in a consensus-based system choose to include a bug in the contract code, and the bug is irreversible and costly, what governance will address it?
What legal implications exist of such a smart contract bug? Will regulators address smart contract code enforcement to protect consumers?
We might be ahead of our skis on the smart contract and app side, Joi Ito has written. Certain critical core infrastructure aspects have to be addressed before going as far as funding and depending on contracts and apps written on top of the infrastructure.
The community would not build an Amazon before agreeing on TCP/IP, let alone SSL. The community is not yet at the stage of basic protocol agreement, nor has it completed the infrastructure layers that call for extreme trust in apps built on top of it.
Layers for deploying smart contracts will improve, and blockchain as a pattern and many of its implementations (public or private) will improve the world. But in the meantime, there is a lot of core work ahead before trusting and investing so heavily.
While many have said this is similar to the late 90s web, it really looks more like the one of the early 90s or late 80s, Neville noted. The community must be careful with trust, with assets, with votes and with code. This is especially true when it comes to using apps and smart contracts atop of today’s infrastructure.
Such things take longer than expected to develop. On the other hand, the positive effect is often much greater than expected.
The debates and reviews of direction and code don’t diminish prospects, Neville observed. But they do increase awareness of trust and how its decisions change rather than leave entirely in the new systems. When this occurs, the community grows, not only in pontificating, predicting and dreaming about the future, but in engaging in the more satisfying job of creating it.
Featured image from Shutterstock and Twitter/Sean Neville.
Last modified: January 25, 2020 11:47 PM UTC