Trust anchors

1 Abstract

Trust anchors are the primary abstractions on which computationally verifiable trust among intentional actors are based. Trust anchors are computer programs and related runtime data structures within a computing environment (CE) capable of executing them. Trust anchors, together with the trustworthy messaging protocols invoking them, are replacements for trusted third parties (TTPs), and enable various real-world verticals where trusting an intentional actor acting as a TTP is not acceptable or desirable.

In this article, we introduce some CEs, along with their salient features which affect the trust invariants offered by the trust anchors deployed on them.

2 Introduction

Trust anchors are computer programs and runtime data structures which have precise semantics within the computing environment (CE) in which they are deployed. The engineering considerations which go into the design of trust anchors are affected mainly by the unique characteristics of the CE, shaped by the real-world verticals they are used for. We consider various CEs below, along with how they affect the trust invariants offered by the trust anchors deployed within those CEs.

3 Computing environments and related trust anchors

All modern digital computer systems are driven by one or more clock signals. These clock signals drive the decoding and execution of instructions in the central processing unit (CPU), as well as the fetching of instructions and data from memory. Modern digital computers typically implement a Turing machine, and are typically programmed using tools and semantics provided by higher-level computing environments (CEs) built on top of those machines.

Computing environments may be provided by a single computer, or may be provided by multiple computers with a shared state, such as common time, a blockchain, or a distributed database.

In this article, we consider a non-exhaustive list of different CEs classified according to the nature of shared state leveraged by the digital computer(s) providing the CE. The first two are real-world CEs in use today. The third represents a minimally viable CE built on top of intentional actors (IAs) capable of message-passing. No practical real-world system based on the third CE is known to be in use, as of the time of the initial publication of this article.

3.1 CE on a single computer, multiple IAs on the same computer

This setup is typical of a time-shared UNIX environment - with different IAs spawning different processes on the same computer. Within a single physical computer, the clock signals driving the computations within the CE as well as within the IAs are the same, and the trust anchors are simply various user-space and kernel-space programs and runtime abstractions which enable the actors to computationally check the validity of various statements about actions or messages from other IAs visible to them.

3.2 Consensus-backed CE across multiple computers, with IAs also on multiple computers

This setup is typical of various existing Internet-scale “world computers”, such as Solana and Ethereum. With multiple computers, ensuring the consistency and byzantine-fault-tolerance (BFT) of shared state underlying the CE used by different IAs becomes a non-trivial engineering problem. Examples of such shared state include a blockchain. The shared state may or may not include an explicit common time which may be used for performing computations within the CE. World computers like Solana or Ethereum typically address fault-tolerance via the use of consensus algorithms among multiple computers (sometimes designated as validator nodes), and then building an appropriate CE on top. Some of these CEs can run non-trivial computer programs (e.g., smart contracts or bitcoin scripts).

The trust invariants offered by computer programs and associated runtime data structures (e.g., records of transactions within the underlying blockchain) within these CEs are affected by the mathematical guarantees associated with the consensus algorithms providing BFT for the shared state. In particular, the trust invariants provided by the trust anchors need trust assumptions about the shared state which are not observable/mathematically verifiable within the compute environment (CE) itself.

3.3 Barebones CE across multiple computers, with IAs also on multiple computers

The main difference of this CE from the CE in Section 3.2 is that there is no dependence on a BFT shared state underlying the CE provided by the digital computers. This enables the trust invariants provided by the trust anchors deployed within the CE to be completely independent of anything external to the CE seen by each intentional actor. In particular, there are no additional trust assumptions that need to be made due to the use of majority consensus algorithms for BFT shared state.

In such a CE, given the engineering constraint to avoid dependence on a BFT shared state, a common time may be constructed by each group of intentional actors using message-passing and local timestamps of observable events. This common time can then be used to sequence various concurrent computations within the CE and computationally verify statements related to observable actions from intentional actors within the CE. More complex shared state within the CE may also be built on top of common time and notions related to the temporal ordering of observable events (e.g., changes in state) within the CE, without relying on majority consensus algorithms for BFT.

4 Summary

In this article, we described salient properties of various computing environments (CEs), as well as how they affect the trust invariants offered by trust anchors deployed on them. We pointed out specific shortcomings of an Internet-scale CE backed by consensus algorithms for Byzantine Fault Tolerance (BFT), and discussed the possibility of a more barebones CE, developed from first principles and built on top of intentional actors with message-passing, which offers trust invariants which are computationally verifiable using mindfully designed abstractions provided by the CE itself.

5 Changelog

This document was first published on December 28, 2025. It was last modified on December 29, 2025.

6 Feedback

The author of this article would love to hear your feedback at hello@milaneum.io. In your message, please consider including the name of the article, the listed identity of the Milaneal author of this article, and the semantic version.