Sub Zones

From a Node’s Perspective

From the perspective of a node a compatibility zone is defined by the Identity Manager and Network Map services it is configured to connect to. It has no comprehension of sub zones. It simply connects to the services configured within its configuration file and, once registered with both, interacts with other nodes and the apps deployed upon it via the RPC clients. This is summarised below:

node zone view The node is unaware of other sub zones, seeing only those nodes registered with the network map service it itself has registered with.

From the Perspective of the Zone

From the perspective of the operator of that zone however, things are a lot more interesting:

simple sub zones

In this example the zone operator is operating two public sub zones, each with a different min platform version (the other network parameters shared by the two zones are omitted for brevity). Each sub zone has a single notary, operated by the zone operator, whose nodeInfo is included in the whitelist of the network parameters representing that zone.

Interesting features

  • All nodes are registered with the zone’s Identity Manager service. (This includes the notaries)
  • Each sub zone is represented by a network map, each with its own database and network parameters file
  • Node 1 is on the “older” sub zone using a minimum platform version of 3, it is unaware Nodes 2 and 3 even exist (just as they are unaware of it) but can use Notary 1.
  • Nodes 2 and 3 and Notary 2 can all intercommunicate as one would expect

Segregated Sub Zones

The fundamental difference between a public sub zone and a segregated one is the operation of the notaries is deferred to a third party.

This is shown in the following diagram:

simple seg zones

Sub Zones vs Private Network Maps

Private Network Maps, see Private Network Map, differ from sub zones in several fundamental ways. Indeed, there is nothing to prevent the two features being deployed along side one another to address the differing needs of a zones members.

An example Compatibility Zone, with several Private Network Maps and Sub Zones, both public and segregated, is shown below:

zones and private networks The Compatibility Zone in our example has

  • 1 Identity Manager Service

  • 4 Network Map Services

  • 1 Public Sub Zone

    • 4 Notaries
    • This Zone has 2 Private Network Maps
      • PNM 1 has 3 Nodes and 1 Notary shared with the public Network Map
      • PNM 2 has 5 Nodes and 1 Notary shared with the public Network Map
  • 3 Segregated Sub Zones

    • Seg Zone 1 has a single Notary and 3 Nodes
    • Seg Zone 2 has 3 Notaries and 3 Nodes
    • Seg Zone 3 has a single Notary and 5 Nodes

Notaries used by a Private Network Map are still available to the rest of the Sub Zone to which they belong whilst notaries running as part of a Seg Zone can only be used by the nodes within that Zone. Each Sub Zone must have its own Network Map Service, whilst the Zone as a whole has a single Identity Manager service.

Members of a zone are completely unaware of any node outside of the zone to which they have joined.

Which Nodes can communicate with one another.

NodeNotaryOther Nodes
A1, 2, 3, 4B, C, I, J, K, L, M
B1, 2, 3, 4A, C, I, J, K, L, M
C1, 2, 3, 4A, B, I, J, K, L, M
D3E, F, G, H
E3D, F, G, H
F3D, E, G, H
G3D, E, F, H
H3D, E, F, G
I1, 2, 3, 4A, B, C, J, K, L, M
J1, 2, 3, 4A, B, C, I, K, L, M
K1, 2, 3, 4A, B, C, I, J, L, M
L1, 2, 3, 4A, B, C, Im J, K, M
M1, 2, 3, 4A, B, C, I, J, K, L
N1O, P
O1N, P
P1N, O
Q6R, S, T
R6Q, S, T
S6Q, R, T
T6Q, R, S
U5V, W
V5U, W
W5U, V
X7, 8, 9Y, Z
Y7, 8, 9X, Y

We can also picture the Zone in terms of which Notary will notarise transactions for which nodes

Notary will notarise transactions for

NotaryNodes
1A, B, C, I, J, K, L, M, N, O, P
2A, B, C, I, J, K, L, M
3A, B, C, D, E, F, G, H, I, J, K, L, M
4A, B, C, I, J, K, L, M
5U, V, W
6Q, R, S, T
7X, Y, Z
8X, Y, Z
9X, Y, Z