Supporting the Smart Contract Economy with Zero Trust Architecture

Published in

CLC Group

8 min readMay 9, 2019

Introduction

There is specific terminology for indivisible spaces between objects: gunk. No single object exists as anything but gunk, unless qualitative properties are assigned to them by a perceiver. Little effort (for the casual reader) is required to attribute the same paradigm to knowledge and trust. Zero Knowledge Proofs provide trustless verification of information being known by an agent, without disclosing said information. For the purposes of smart contract ecosystems, it would be ideal to trustlessly verify that the information delivered in a Zero Knowledge Proof has not been revealed to unintended parties. Said functionality would allow for ideologically sound implementations of a growing trend in network security: Zero Trust Architecture.

This article will explore the tenants of Zero Trust Architecture as they relate to the smart contract economy and the centralized networks that interact with them. Currently there is one major barrier that prevents centralized networks from reaching fully trustless implementations of Zero Trust Networks: a mechanism is needed for verification of proposed truths without deferring to trust in a verifier.

Zero Trust Networks: Are Centralized Systems Prepared for the Smart Contract Economy?

“Don’t Trust, Verify.”

The above quote is the core principle of Zero Trust Architecture and should not be unfamiliar to anyone who has researched decentralized oracle networks thoroughly. In a moment, we will introduce the foundations of Zero Trust Networks (ZTNs) as they relate to Honeycomb Node Operators & API Providers as well as decentralized oracle networks overall. Further, detailed information on Zero Trust Networks can be found here:

A Zero Trust Network is built upon these principles (Palo Alto Networks):

Data can only be accessed security. All interactions with data must be verified through validation of user and connection data.
Least privilege strategies for user permissions. No user should have any more access than they need to a centralized network.
All traffic and logs must be verified. Efficiency mandates that this be done at established inspection checkpoints. This item in particular will become important later in the article.
Multiple authentication methods required for access.
Never trust. Zero Trust Architecture can always be improved through consistent audit of permissions & logs and development of new contexts for minimizing permissions.

The following discussion will assess the implementations and benefits of Zero Trust Architecture in regards to one main goal: Eliminating trust in centralized actors across a smart contract economy without eliminating their presence.

Excluding the smart contract economy, the current incentives of cybercrime are projected to incur $6 trillion in damages by 2021. (Herjavec Group) A centralized actor of enterprise scale would currently allocate their security resources to mitigate disaster impact, overall risk, or regulatory discipline. Presently there are few cases where centralized infrastructure directly generates revenue from its security measures. We expect a direct correlation between the influx of revenue for enterprises interacting with smart contracts and the overall security capital of organizations over the next decade.

The major vector of attack on a centralized system serving high-risk/value contracts is undetected tampering of data at the source, before it is relayed to a smart contract. Aggregation will circumvent these security concerns for contracts interacting with precise data in particular, however reaching appropriate levels of aggregation requires circumnavigation of some key barriers for regulated data. See this article for more information on how CLC Group plans to accelerate this process. Other smart contract scenarios will not have the luxury of aggregation of like kind data. For example, sensor data in a smart contract will always remain one centralized data source. When a node operator stakes that they are returning data that the smart contract will deem correct, the smart contract is blind to the context of the returned data. There is presently no recourse for node operators who have been penalized for the security oversights of the centralized actors their node interacts with as well. Until such recourse can be integrated into smart contracts, there is a loopback of trust among all centralized parties that interact with a smart contract. This article will describe the network context that smart contracts are presently blind to as nodal gunk.

Types of Centralized Actors Interacting with a Decentralized Oracle Network

API Providers: Centralized data sources that are bridged to the ecosystem will need to be trusted to be secure from data tampering and abuse of access whether authorized or not
Individual Node Instances: Each node interacting with the Chainlink Network is centralized in regards to authentication and security at an infrastructure level as well as from the perspective of a Sybil Attack.
3rd-Party Marketplaces, Certification Providers & Other Services: For services like Honeycomb or Nodary the aspects of user permissions, authentication, node interaction, adaptors, payments, and overall security cannot be left to trust.

All of the above centralized actors can leverage the functionalities introduced by a smart contract ecosystem, and more specifically Zero Knowledge Proofs, to implement the tenants of Zero Trust Architecture, despite their individual responsibilities for supporting it.

Zero-Trust for API Providers

Remember that many agreements and contracts in practice today are not one sided. Risk intensive smart contracts will need to ensure that no manipulation of data has been performed on the centralized network in cases where cross-provider aggregation is unavailable. Even better, would be for smart contracts to have clauses for appeal or overall validation of centralized actors passing various security & compliance tests. Presently these tests would involve trust in an organization or audit process, however results of penetration tests and network audits carried out from a Trustless Execution Environment would be a useful bit of information for most enterprise level smart contract developers, even if they plan to mitigate risk through aggregation of multiple sources.

We are interested in watching for industry developments on these fronts and hope to find ways that CLC Group can expand & integrate with these processes over the coming years. This paradigm of trustless attestation of can be applied to any validator needed for a centralized data provider. Compliance audits, panic triggers, and even legal rulings can be factored into these types of attestations as well. Node operators aren’t the only parties who will need be certified when interacting with a smart contract ecosystem. Centralized data sources are already subject to regulation, we see no reason not to improve upon auditing methods to ensure that all centralized networks can be trustlessly verified for compliance as well.

We will discuss at length the measures that must be taken by a node operator to implement a secure, zero-trust environment for their node instances in an upcoming article. This will be an ongoing discussion as CLC Group trains potential node operators on the proper protocols for administering their node. Education is the only way for individual operators to eliminate trust in their environment.

Honeycomb & Nodary - No Gunk, No Lag, No Trust

When a Honeycomb Node Operator’s node calls out to a Honeycomb Adaptor, it would be nice for the node operator to be able to know exactly what calls were made, in both real time and retroactively. There are a few indivisible interactions on the Chainlink network. In this case, an interaction is divisible if more granular context can be made available for an interaction at an assigned inspection checkpoint. Checkpoint assignments are a game of sacrificing efficiency & latency for security. CLC Group is introducing an alternative solution to implementing checkpoints: contextual data for smart contracts that is logged concurrently throughout the life of a job-run that can be directly fed to a smart contract for further validation and scrutiny.

Without Honeycomb, a node operator who has rolled their own adaptor or purchased one from another provider would have an extremely customized level of logging to reach any level verification that would allow for trustlessness in their operator network. Each indivisible interaction, or contextual gunk, would need individual & deployment-specific remediation to allow for validation to be done at these levels without sacrificing node latency. The purpose of this section is to discuss how Honeycomb & Nodary Node Operators will be much better equipped to face these challenges.

The number of movements on a network, even lateral, between inspection points on a Zero Trust Network interacting with smart contracts results in contextual junk. Logging the data from each call between these points can allow for safe remediation within the network at the next checkpoint, but this measure is not fully applicable for a decentralized oracle network. The decision of which actions to trigger for real time checkpoints are not CLC Group's to make, however by filling in nodal gunk with these concurrent processes, these decisions can be made at a smart contract level. These decisions can be made on-chain as well as through calls to Trustless Execution Environments that act as verifiers with contextual data fed in real-time, post-job, or retroactively through adapters that connect to these processes or their records on CLC Group services. Many use-cases requiring this level of granular detail are fitting for Nodary contracts & operators especially.

Each call to a Honeycomb adaptor from a Honeycomb node, and vice versa, will be able to have its contextual data verified trustlessly. CLC Group will provide protocols for smart contracts to verify these interactions at a more granular and trustless level than a self-hosted adapter can be. Multiple contextual data points will be available for smart contract developers to prevent manipulation at an adapter level, via node mirroring, and other malpractices on the network. This implementation is especially useful for situations where legal action would become necessary in the event of a maligned action towards a smart contract. Post-manipulation remediation & recovery, especially for contracts leveraging regulated data, will need the ability to react legally to such attempts no matter the actor. Another example would be helping data providers to identify illegal re-selling of their data in a smart contract economy.

We hope to provide further technical detail and development milestones in implementing these features as they are built into the platform. For the sake of security, many of these details will be left proprietary for the time being.

Wrapping Up

The first article on individual node security will be released in the coming weeks. It is exciting to see what trustlessness and blockchain technologies can bring to cybersecurity standards across all industries.

In practice, CLC Group aims to ensure that SC developers are able to write reusable attestation contracts for use in other contracts that improve upon blanket certifications like TLS. Similar to DLT-based supply-chain solutions, SC devs will be able to see the distribution pipeline for all data reported to a contract from nodes and make decisions accordingly as to whether the data should be used in an outcome.

Trusting trustlessness is an anti-pattern of great magnitude, one that must be prevented early on in the evolution of a smart contract economy. All decisions made by high-stake/risk contracts need a trustless manner of verification and recourse. Eventually this attestation toolset would allow for the first forms of reputation to be developed.