CheckpointSummary

open class CheckpointSummary : Disposable, AutoCloseable, CheckpointSummaryInterface

A header for a Checkpoint on the IOTA blockchain.

On the IOTA network, checkpoints define the history of the blockchain. They are quite similar to the concept of blocks used by other blockchains like Bitcoin or Ethereum. The IOTA blockchain, however, forms checkpoints after transaction execution has already happened to provide a certified history of the chain, instead of being formed before execution.

Checkpoints commit to a variety of state including but not limited to:

• The hash of the previous checkpoint.
• The set of transaction digests, their corresponding effects digests, as well as the set of user signatures which authorized its execution.
• The object's produced by a transaction.
• The set of live objects that make up the current state of the chain.
• On epoch transitions, the next validator committee.

CheckpointSummarys themselves don't directly include all of the above information but they are the top-level type by which all the above are committed to transitively via cryptographic hashes included in the summary. CheckpointSummarys are signed and certified by a quorum of the validator committee in a given epoch in order to allow verification of the chain's state.

BCS

The BCS serialized form for this type is defined by the following ABNF:

checkpoint-summary = u64                            ; epoch
u64                            ; sequence_number
u64                            ; network_total_transactions
digest                         ; contents_digest
(option digest)                ; previous_digest
gas-cost-summary               ; epoch_rolling_gas_cost_summary
u64                            ; timestamp_ms
(vector checkpoint-commitment) ; checkpoint_commitments
(option end-of-epoch-data)     ; end_of_epoch_data
bytes                          ; version_specific_data

Constructors

CheckpointSummary	constructor(epoch: ULong, sequenceNumber: ULong, networkTotalTransactions: ULong, contentsDigest: CheckpointContentsDigest, previousDigest: CheckpointDigest?, epochRollingGasCostSummary: GasCostSummary, timestampMs: ULong, checkpointCommitments: List<CheckpointCommitment>, endOfEpochData: EndOfEpochData?, versionSpecificData: ByteArray)

Functions

Name	Summary
checkpointCommitments	open override fun checkpointCommitments(): List<CheckpointCommitment> Commitments to checkpoint-specific state.
close	@Synchronized open override fun close()
contentsDigest	open override fun contentsDigest(): CheckpointContentsDigest The hash of the CheckpointContents for this checkpoint.
destroy	open override fun destroy()
digest	open override fun digest(): CheckpointDigest
endOfEpochData	open override fun endOfEpochData(): EndOfEpochData? Extra data only present in the final checkpoint of an epoch.
epoch	open override fun epoch(): ULong Epoch that this checkpoint belongs to.
epochRollingGasCostSummary	open override fun epochRollingGasCostSummary(): GasCostSummary The running total gas costs of all transactions included in the current epoch so far until this checkpoint.
networkTotalTransactions	open override fun networkTotalTransactions(): ULong Total number of transactions committed since genesis, including those in this checkpoint.
previousDigest	open override fun previousDigest(): CheckpointDigest? The hash of the previous CheckpointSummary.
sequenceNumber	open override fun sequenceNumber(): ULong The height of this checkpoint.
signingMessage	open override fun signingMessage(): ByteArray
signingMessageHex	open override fun signingMessageHex(): String
timestampMs	open override fun timestampMs(): ULong Timestamp of the checkpoint - number of milliseconds from the Unix epoch Checkpoint timestamps are monotonic, but not strongly monotonic - subsequent checkpoints can have same timestamp if they originate from the same underlining consensus commit
versionSpecificData	open override fun versionSpecificData(): ByteArray CheckpointSummary is not an evolvable structure - it must be readable by any version of the code. Therefore, in order to allow extensions to be added to CheckpointSummary, we allow opaque data to be added to checkpoints which can be deserialized based on the current protocol version.