Submit a reassignment command for acceptance to the ledger.

To complete a reassignment, first a submission of an unassign command followed by an assign command is required. The com.digitalasset.canton.ledger.participant.state.ReassignmentCommand.Assign command must include the unassign ID which can be observed in the accepted event marking the corresponding successful unassign command.

Submit a transaction for acceptance to the ledger.

This method must be thread-safe.

The result of the transaction submission is communicated asynchronously via a sequence of com.digitalasset.canton.ledger.participant.state.Update implementation backed by the same participant state as this com.digitalasset.canton.ledger.participant.state.SyncService. Successful transaction acceptance is communicated using a com.digitalasset.canton.ledger.participant.state.Update.TransactionAccepted message. Failed transaction acceptance is communicated when possible via a com.digitalasset.canton.ledger.participant.state.Update.CommandRejected message referencing the same submitterInfo as provided in the submission. There can be failure modes where a transaction submission is lost in transit, and no com.digitalasset.canton.ledger.participant.state.Update.CommandRejected is generated. See the comments on com.digitalasset.canton.ledger.participant.state.Update for further details.

A note on ledger time and record time: transactions are submitted together with a ledgerTime provided as part of the transactionMeta information. The ledger time is used by the Daml Engine to resolve calls to the getTime :: Update Time function. Letting the submitter freely choose the ledger time is though a problem for the other stakeholders in the contracts affected by the submitted transaction. The submitter can in principle choose to submit transactions that are effective far in the past or future relative to the wall-clock time of the other participants. This gives the submitter an unfair advantage and make the semantics of getTime quite surprising. We've chosen the following solution to provide useful guarantees for contracts relying on getTime.

The ledger is charged with (1) associating record-time stamps to accepted transactions and (2) to provide a guarantee on the maximal skew between the ledger effective time and the record time stamp associated to an accepted transaction. The ledger is also expected to provide guarantees on the distribution of the maximal skew between record time stamps on accepted transactions and the wall-clock time at delivery of accepted transactions to a ledger participant. Thereby providing ledger participants with a guarantee on the maximal skew between the ledger effective time of an accepted transaction and the wall-clock time at delivery to these participants.

Concretely, we typically expect the allowed skew between record time and ledger time to be in the minute range. Thereby leaving ample time for submitting and validating large transactions before they are timestamped with their record time.

The com.digitalasset.canton.ledger.participant.state.SyncService is responsible for deduplicating commands with the same com.digitalasset.canton.ledger.participant.state.SubmitterInfo.changeId within the com.digitalasset.canton.ledger.participant.state.SubmitterInfo.deduplicationPeriod.