—–BEGIN HASHED POST BLOCK—–
Part II: Networked Smart Contracts
Since the beginning of my winter break from Columbia SIPA, I’ve had the opportunity to do some fairly extensive dev work on some personal smart contract projects. Among my aims was exploring the possibility of networked smart contracts (“NSC”). By NSC, I am not referring simply to contracts with public function calls of their peers, but rather to contracts that make public function calls to other contracts on other chains.
Currently, contracts written in Solidity have external visibility, and function parameters can be declared so that they may be accessed externally by other contracts. Should a contract need to pull in a function that is defined elsewhere, it can do so by creating an EVM function call and have that brought over to the current contract that is being executed. This has obvious advantages as some contracts may be complex and require segmentation for organization, or more practically, to ensure that gas is spent in an efficient and easily-auditable manner.
An oversimplified call can be seen in the following example:
However, the downsides of this system is that contracts can only reference others if they are operating on the same blockchain, such as ethereum. For now, given the relative infancy of the technology, this isn’t a problem as smart contracts are comparatively simple relative to their physical counterparts, and don’t require massive computations or complex logic. This will eventually change as time progresses and blockchains are incorporated into and built by more industries.
The reason that this functionality should be implemented is due to this future adoption, as well as the high likelihood that proprietary chains will be built to handle different processes and solve different issues. While a number of companies and projects are attempting to lead the future of blockchain development and design what will be the eventual standards of blockchain, there isn’t mass adoption of one set (even though there is certainly heavy sway towards technologies such as ethereum). Over the past year, I’ve consulted on a number of different blockchain projects and have identified a common theme in my work: while everyone wants their own “chain” to satisfy the same requirements as their peers, several clients (and especially larger institutions) need some intercompatibility with their partners. If everyone is using different blockchains, we’ve accomplished little more than overcomplicating extant proven systems.
Eventually what I see happening is that the number of available and competing blockchain technologies will get smaller. Hobby projects will eventually get abandoned, some of the more innovative chains produced by smaller firms and startups will be acquired, and several institutional collaborative efforts (such as Hyperledger) will remain as the enterprise-class options. Further, I envision that multiple chains will still exist, and this is especially true in industries where larger organizations have a good argument for implementing their own proprietary versions of blockchains (such as the financial industry).
Going back to my original point, there is no current way for these various blockchains to talk to one another. One might argue that the security provided by decentralization obviates the need for multiple blockchain implementations, and that all data that might need to be transacted on a blockchain could be transacted on a single chain. There are obvious disincentives. For example, in a highly-regulated industry such as banking, financial institutions would need their own ledgers to ensure adherence to incredibly complex auditing requirements. Organizations that require exceptional security such as governments might need to run their data in-house with each agency maintaining their own chain. Instances even as simple as a separation between corporate sales and manufacturing departments might have a decent argument to maintain separate blockchains. If chains are implemented independently, we need to design protocols and standards for NSC to facilitate secure and reliable communication and connectivity between them.
It’s important that the blockchain community writ large makes two important policy decisions. First, the community needs to decide on a clear and defined set of standards to abide by in the development of various blockchains. This is difficult given that interested companies, project collaborations, and open source efforts are constantly expanding the limits and possibilities of the technology. Everyone is moving outward in various directions to be first-to-market with their respective inventions and improvements. However, those moving in substantially similar or even parallel directions need to agree on a set of structural standards to ensure that if both chains get adopted, there are commonalities between them. An example of this is the Bitcoin Improvement Proposal (“BIP”) process where standards for Bitcoin go through a lengthy path of submission, evaluation, and implementation.
Second, in these standards, the blockchain community needs to implement robust communication protocols for these chains to communicate with one another. Chains will eventually replace many legacy systems but will likely do so independently rather than cumulatively, and they will need to be capable of “smart” conversations with their counterparts. There will be an eventual need to have movement by and between chains, either in the generation of new contracts on other chains, or simultaneous execution of contract terms on chains implemented parallel to one another.
If blockchain truly is the future (which I firmly contend that it is), the community should also look ahead to future challenges for the technology. Regardless of how many chains will exist within the ecosystem, they will eventually need the ability to interact with each other to guarantee advanced functionality. Designing blockchain products that are completely isolated from one another may seem like good business practices today, and may help businesses realize significant market shares, but it will hinder the technology’s overall potential going forward.
If you have feedback on this idea, I’d love to hear it! I can be reached via firstname.lastname@example.org.
—–END HASHED POST BLOCK—–
Featured Image Credit: Gerd Altmann, “untitled”. Public Domain Work. Modified, Desaturated.