Type Members

1.  final case class ApproximateTime(value: CantonTimestamp) extends AnyVal with Product with Serializable
2.  class AuthorizationGraph extends NamedLogging

   maintain a dependency graph for the namespace delegations

   maintain a dependency graph for the namespace delegations

   namespace delegations are a bit tricky as there can be an arbitrary number of delegations before we reach the actual key that will be used for authorizations. think of it as a certificate chain where we get a series of certificates and we need to figure out a path from one certificate to the root certificate.

   NOTE: this class is not thread-safe

   properties of the graph:

   • the nodes are the target key fingerprints
   • the node with fingerprint of the namespace is the root node
   • the edges between the nodes are the authorizations where key A authorizes key B to act on the namespace in this case, the authorization is outgoing from A and incoming to B.
   • the graph SHOULD be directed acyclic graph, but we MIGHT have cycles (i.e. key A authorizing B, B authorizing A). we don't need to make a fuss about cycles in the graph. we just ignore / report them assuming it was an admin mistake, but we don't get confused.
   • root certificates are edges pointing to the node itself. they are separate such that they don't show up in the list of incoming / outgoing.
   • we track for each node the set of outgoing edges and incoming edges. an outgoing edge is a delegation where the source node is authorizing a target node. obviously every outgoing edge is also an incoming edge.

   computation task:

   • once we've modified the graph, we compute the nodes that are somehow connected to the root node.

   purpose:

   • once we know which target keys are actually authorized to act on this particular namespace, we can then use this information to find out which resulting mapping is properly authorized and which one not.

   authorization checks:

   • when adding "single transactions", we do check that the transaction is properly authorized. otherwise we "ignore" it (returning false). this is used during processing.
   • when adding "batch transactions", we don't check that all of them are properly authorized, as we do allow temporarily "nodes" to be unauthorized (so that errors can be fixed by adding a replacement certificate)
   • when removing transactions, we do check that the authorizing key is authorized. but note that the authorizing key of an edge REMOVAL doesn't need to match the key used to authorized the ADD.
3.  final case class AuthorizedTopologyTransaction[T <: TopologyMapping](uniquePath: UniquePath, mapping: T, authorizingKey: Fingerprint) extends Product with Serializable
4.  final case class EffectiveTime(value: CantonTimestamp) extends AnyVal with Product with Serializable
5.  class IncomingTopologyTransactionAuthorizationValidator extends NamedLogging

   validate incoming topology transactions

   validate incoming topology transactions

   NOT THREAD SAFE. Note that this class is not thread safe

   we check three things: (1) are the signatures valid (2) are the signatures properly authorized

   1. load current set of authorized keys b. for each transaction, verify that the authorization key is valid. a key is a valid authorization if there is a certificate chain that originates from the root certificate at the time when the transaction is added (one by one). c. if the transaction is a namespace or identifier delegation, update its impact on the authorization set this means that if we add or remove a namespace delegation, then we need to perform a cascading update that activates or deactivates states that depend on this delegation. (3) finally, what we compute as the "authorized graph" is then used to compute the derived table of "namespace delegations"
6.  final case class SequencedTime(value: CantonTimestamp) extends AnyVal with Product with Serializable
7.  class TopologyTimestampPlusEpsilonTracker extends NamedLogging with TimeAwaiter with FlagCloseable

   Compute and synchronise the effective timestamps

   Compute and synchronise the effective timestamps

   Transaction validation and processing depends on the topology state at the given sequencer time. Therefore, we would have to inspect every event first if there is a topology state and wait until all the topology processing has finished before evaluation the transaction. This would be slow and sequential.

   Therefore, we future date our topology transactions with an "effective time", computed from the sequencerTime + domainParameters.topologyChangeDelay.

   However, the domainParameters can change and so can the topologyChangeDelay. Therefore we need to be a bit careful when computing the effective time and track the changes to the topologyChangeDelay parameter accordingly.

   This class (hopefully) takes care of this logic

8.  trait TopologyTransactionProcessingSubscriber extends AnyRef
9.  class TopologyTransactionProcessor extends NamedLogging with FlagCloseable

   Main incoming topology transaction validation and processing

   Main incoming topology transaction validation and processing

   The topology transaction processor is subscribed to the event stream and processes the domain topology transactions sent via the sequencer.

   It validates and then computes the updates to the data store in order to be able to represent the topology state at any point in time.

   The processor works together with the StoreBasedDomainTopologyClient