Type Members

1.  final case class ApproximateTime(value: CantonTimestamp) extends Product with Serializable
2.  final case class AuthorizationChainX(identifierDelegation: Seq[AuthorizedIdentifierDelegationX], namespaceDelegations: Seq[AuthorizedNamespaceDelegationX], unionspaceDefinitions: Seq[AuthorizedUnionspaceDefinitionX]) extends Product with Serializable

   authorization data

   authorization data

   this type is returned by the authorization validator. it contains the series of transactions that authorize a certain topology transaction.

   note that the order of the namespace delegation is in "authorization order".

3.  trait AuthorizationCheckX extends AnyRef
4.  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.
5.  class AuthorizationGraphX extends AuthorizationCheckX with 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 a 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 is 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.
6.  final case class AuthorizedTopologyTransaction[T <: TopologyMapping](uniquePath: UniquePath, mapping: T, transaction: SignedTopologyTransaction[TopologyChangeOp]) extends Product with Serializable

   An authorized topology transaction

7.  final case class AuthorizedTopologyTransactionX[T <: TopologyMappingX](signedTransaction: SignedTopologyTransactionX[TopologyChangeOpX, T]) extends Product with Serializable

   An authorized topology transaction

8.  trait DomainTopologyTransactionMessageValidator extends AnyRef

   Validate 2.x domain topology transaction messages

   Validate 2.x domain topology transaction messages

   The domain topology manager distributes the topology state through domain topology messages to all registered and active members. This class is used to verify the correctness of the given signature.

   Some care is required when validating the signature, as the key used by the domain topology dispatcher is actually defined by the state that it changes.

   When a new participant connects for the first time, it will receive a first message which is self-consistent, where the message is signed by a key for which we get all topology transactions in the message itself.

   Therefore, a participant can be sure to talk to the right domain by defining the domain-id on the domain connection, because we will check the topology state against this domain-id too.

   Replay attacks are prevented using a max-sequencing timestamp which prevents that a message is replayed to different recipients at a later point in time.

9.  final case class EffectiveTime(value: CantonTimestamp) extends Product with Serializable
10.  class IncomingTopologyTransactionAuthorizationValidator extends NamedLogging with TransactionAuthorizationValidator

    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"
11.  class IncomingTopologyTransactionAuthorizationValidatorX extends NamedLogging with TransactionAuthorizationValidatorX

    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 keys are 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"
12.  final case class SequencedTime(value: CantonTimestamp) extends Product with Serializable
13.  class SnapshotAuthorizationValidator extends TransactionAuthorizationValidator with NamedLogging with FlagCloseable

    Compute the authorization chain for a certain UID

14.  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 evaluating 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

15.  trait TopologyTransactionProcessingSubscriber extends TopologyTransactionProcessingSubscriberCommon
16.  trait TopologyTransactionProcessingSubscriberCommon extends AnyRef
17.  trait TopologyTransactionProcessingSubscriberX extends TopologyTransactionProcessingSubscriberCommon
18.  class TopologyTransactionProcessor extends TopologyTransactionProcessorCommonImpl[SignedTopologyTransaction[TopologyChangeOp]] with HasCloseContext

    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

19.  trait TopologyTransactionProcessorCommon extends NamedLogging with FlagCloseable
20.  abstract class TopologyTransactionProcessorCommonImpl[M] extends TopologyTransactionProcessorCommon

    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

21.  class TopologyTransactionProcessorX extends TopologyTransactionProcessorCommonImpl[TopologyTransactionsBroadcastX]
22.  trait TransactionAuthorizationValidator extends AnyRef

    common functionality shared between incoming transaction authorization validator and the auth computation

23.  trait TransactionAuthorizationValidatorX extends AnyRef

    common functionality shared between incoming transaction authorization validator and the auth computation

24.  final case class UnionspaceAuthorizationGraphX(us: UnionspaceDefinitionX, direct: AuthorizationGraphX, ownerGraphs: Seq[AuthorizationGraphX]) extends AuthorizationCheckX with Product with Serializable