tip: 8
title: Milestone Payload
description: Coordinator issued milestone structure with Ed25519 authentication
author: Angelo Capossele (@capossele) , Wolfgang Welz (@Wollac) 
discussions-to: https://github.com/iotaledger/tips/pull/19
status: Replaced
type: Standards
layer: Core
created: 2020-07-28
superseded-by: TIP-29

Summary

In IOTA, nodes use the milestones issued by the Coordinator to reach a consensus on which transactions are confirmed. This RFC proposes a milestone payload for the messages described in the IOTA protocol TIP-6. It uses Edwards-curve Digital Signature Algorithm (EdDSA) to authenticate the milestones.

Motivation

In the current IOTA protocol, milestones are authenticated using a ternary Merkle signature scheme. In the Chrysalis update, ternary transactions are replaced with binary messages containing different payload types. In order to address these new requirements, this RFC proposes the use of a dedicated payload type for milestones. It contains the same essential data fields that were previously included in the milestone bundle. Additionally, this document also describes how Ed25519 signatures are used to assure authenticity of the issued milestones. In order to make the management and security of the used private keys easier, simple multisignature features with support for key rotation have been added.

Detailed design

The BLAKE2b-256 hash of the Milestone Essence, consisting of the actual milestone information (like its index number or position in the tangle), is signed using the Ed25519 signature scheme as described in the IRTF RFC 8032. It uses keys of 32 bytes, while the generated signatures are 64 bytes.

To increase the security of the design, a milestone can (optionally) be independently signed by multiple keys at once. These keys should be operated by detached signature provider services running on independent infrastructure elements. This assist in mitigating the risk of an attacker having access to all the key material necessary for forging milestones. While the Coordinator takes responsibility for forming Milestone Payload Messages, it delegates signing in to these providers through an ad-hoc RPC connector. Mutual authentication should be enforced between the Coordinator and the signature providers: a client-authenticated TLS handshake scheme is advisable. To increase the flexibility of the mechanism, nodes can be configured to require a quorum of valid signatures to consider a milestone as genuine.

In addition, a key rotation policy can also be enforced by limiting key validity to certain milestone intervals. Accordingly, nodes need to know which public keys are applicable for which milestone index. This can be provided by configuring a list of entries consisting of the following fields:

• Index Range providing the interval of milestone indices for which this entry is valid. The interval must not overlap with any other entry.
• Applicable Public Keys defining the set of valid public keys.
• Signature Threshold specifying the minimum number of valid signatures. Must be at least one and not greater than the number of Applicable Public Keys.

Structure

The following table describes the entirety of a Milestone Payload in its serialized form following the notation from TIP-21:

Generation

• Generate a new Milestone Essence corresponding to the Coordinator milestone.
• Transmit the serialized Milestone Essence to the corresponding number of signature service providers.
  • The signature provider service will sign the received serialized bytes as-is.
  • The signature provider will serialize the signature bytes and return them to the Coordinator.
• Fill the Signatures field of the milestone payload with the received signature bytes.
• Generate a Message as defined in TIP-6 using the same Parents as in the created Milestone Payload.

Syntactical validation

• Parents of the payload must match Parents of the encapsulating Message.
• PoW score:
  • If Next Pow Score is zero, Next PoW Score Milestone Index must also be zero.
  • Otherwise Next PoW Score Milestone Index must be larger than Index Number.
• Keys:
  • Keys Count must be at least the Signature Threshold and at most the number of Applicable Public Keys for the current milestone index.
  • Keys must be sorted in lexicographical order.
  • Each Public Key must be unique.
  • Keys must form a subset of the Applicable Public Keys for the current milestone index.
• Payload (if present):
  • Payload Type must match one of the values described under Payloads.
  • Data fields must be correctly parsable in the context of the Payload Type.
  • The payload itself must pass syntactic validation.
• Signatures:
  • Signatures Count must match Keys Count.
  • Signature at index i must be valid with respect to the Public Key at the same index.
• Given the type and length information, the Milestone Payload must consume the entire byte array of the Payload field of the Message.

Payloads

The Milestone Payload itself can contain another payload as described in general in TIP-6. The following table lists all the payloads types that can be nested inside a Milestone Payload as well as links to the corresponding specification:

Rationale and alternatives

• Instead of using EdDSA we could have chosen ECDSA. Both algorithms are well supported and widespread. However, signing with ECDSA requires fresh randomness while EdDSA does not. Especially in the case of milestones where essences are signed many times using the same key, this is a crucial property.
• Due to the layered design of messages and payloads, it is practically not possible to prevent reattachments of Milestone Payloads. Hence, this payload has been designed in a way to be independent from the message it is contained in. A milestone should be considered as a virtual marker (referencing Parents) rather than an actual message in the Tangle. This concept is compatible with reattachments and supports a cleaner separation of the message layers.
• Forcing matching Parents in the Milestone Payload and its Message makes it impossible to reattach the same payload at different positions in the Tangle. This does not prevent reattachments in general (a different, valid Nonce, for example would lead to a new Message ID) and it violates a strict separation of payload and message. However, it simplifies milestone processing as the position of the Message will be the same as the possition encoded in the Milestone Payload. Having this clear structural properties seem to be more desirable than a strict separation of layers.

Copyright

Copyright and related rights waived via CC0.