Trust Boundary

A trust boundary [ /trʌst ˈbaʊndəri/ ] is the point in a system where the level of trust changes: on one side a component can rely on how the rest behaves, and on the other it has to check what it receives. In blockchains, each ledger is its own trust boundary, which is why moving an asset from one chain to another needs a bridge.

In security engineering

Threat modelling draws trust boundaries on a data-flow diagram of the system. OWASP’s threat modelling process defines a boundary as “any location where the level of trust changes”, and places one wherever data enters or leaves the application: a login form, a network firewall, or the interface between two processes running with different privileges. Checks such as authentication, input validation and access control sit at the boundary, because nothing on the far side is assumed to behave.

Between blockchains the far side is another ledger with its own validators. A burn-and-mint bridge destroys or locks a token on one chain and issues a wrapped copy on the other, and the copy is only as good as whoever attests that the first step happened.

Radix and the single-ledger trust boundary

Most blockchains scale by adding ledgers, such as sidechains, rollups or app-chains, and each new ledger draws a new trust boundary. Radix is designed to scale by splitting one ledger instead.

Today that ledger is not split. Babylon, live since 28 September 2023, runs Cerberus as a single shard group, so every account, component and resource sits inside one trust boundary and any transaction can touch any of them atomically.

Xi’an, the planned next release, would spread the ledger across many shard groups that remain one network. In hyperscale-rs, the community project building it, every validator works out from the beacon chain which shards a transaction involves; the nodes holding that state share it, and each executes the transaction independently. Assets do not cross a bridge between shards or turn into wrapped copies. The Cerberus whitepaper proposed braiding the shards’ consensus together for cross-shard transactions; hyperscale-rs does not, and its lead developer gave the reason as “braiding is a terrible idea. makes shards co-dependent on each other for liveness”.

Splitting the ledger keeps one boundary around the network, but each shard has to trust the others’ validators. A shard does not hold another shard’s state, so it cannot check that shard’s work: “if they did - it would not be a sharded system”. A group holding a two-thirds quorum inside any one shard could write that shard’s state as it chose, and because XRD exists in every shard, the damage would reach the whole network. hyperscale-rs therefore puts its security design into how validators are assigned to shards, described on its own page. Xi’an has no release date.