Adds a new party to the set managed by the ledger.

Caller specifies a party identifier suggestion, the actual identifier allocated might be different and is implementation specific.

In particular, a ledger may: - Disregard the given hint and choose a completely new party identifier - Construct a new unique identifier from the given hint, e.g., by appending a UUID - Use the given hint as is, and reject the call if such a party already exists

Successful party allocations will result in a Update.PartyAddedToParticipant message. See the comments on ReadService.stateUpdates and Update for further details.

Prune the participant ledger specifying the offset up to which participant ledger events can be removed.

As this interface applies only to the local participant unlike other administrator services, returns a (completion stage of a) PruningResult rather than a SubmissionResult.

Ledgers that do not elect to support participant pruning, return NotPruned(Status.UNIMPLEMENTED). Returning an error also keeps the ledger api server from pruning its index.

Ledgers whose participants hold no participant-local state, but want the ledger api server to prune, return ParticipantPruned.

For pruning implementations to be fault tolerant, the following aspects are important: - Consider failing a prune request before embarking on destructive operations for example if certain safety conditions are not met (such as being low on resources). This helps minimize the chances of partially performed prune operations. If the system cannot prune up to the specified offset, the call should not alter the system and return NotPruned rather than prune partially. - Implement pruning either atomically (performing all operations or none), or break down pruning steps into idempotent pieces that pick up after retries or system recovery in case of a mid-pruning crash. - To the last point, be aware that pruning of the ledger api server index happens in such an idempotent follow-up step upon successful completion of each prune call. To reach eventual consistency upon failures, be sure to return ParticipantPruned even if the specified offset has already been pruned to allow ledger api server index pruning to proceed in case of an earlier failure.

Submit a new configuration to the ledger. If the configuration is accepted a Update.ConfigurationChanged event will be emitted to all participants. In case of rejection a Update.ConfigurationChangeRejected will be emitted.

The Configuration contains the identity of the participant that is allowed to further change the configuration. The initial configuration can be submitted by any participant.

If configuration changes are not supported by the implementation then the SubmissionResult.SynchronousError should be returned. *

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 ReadService implementation backed by the same participant state as this WriteService. Successful transaction acceptance is communicated using a Update.TransactionAccepted message. Failed transaction acceptance is communicated when possible via a 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 Update.CommandRejected is generated. See the comments on ReadService.stateUpdates 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 WriteService is responsible for deduplicating commands with the same SubmitterInfo.changeId within the SubmitterInfo.deduplicationPeriod.

Upload a collection of Daml-LF packages to the ledger.

This method must be thread-safe, not throw, and not block on IO. It is though allowed to perform significant computation.

Successful archives upload will result in a Update.PublicPackageUpload message. See the comments on ReadService.stateUpdates and Update for further details.

Note: we accept Archives rather than parsed packages, because we want to be able to get the byte size of each individual ArchivePayload, which is information that the read / index service need to provide. Moreover this information should be consistent with the payload that the com.daml.ledger.api.v1.package_service.GetPackageResponse contains. If we were to consume packages we'd have to re-encode them to provide the size, and the size might potentially be different from the original size, which would be quite confusing.