Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Milestone Payload #19

Merged
merged 33 commits into from
Oct 27, 2021
Merged
Changes from 4 commits
Commits
Show all changes
33 commits
Select commit Hold shift + click to select a range
67d53a6
milestone payload initial
Jul 28, 2020
7ad5770
Address open questions of draft document
Wollac Jul 28, 2020
b7e8553
Fix RFC number
Wollac Jul 28, 2020
67b88b7
Fix typos
Wollac Jul 28, 2020
4bf065a
use fixed size integers
luca-moser Sep 4, 2020
e0d72b9
fixes payload type to uint32
luca-moser Sep 7, 2020
7b1812a
Milestone MultiSig Extension (#1)
karimodm Oct 19, 2020
7ae0fad
Remove post-quantum open questions
Wollac Oct 19, 2020
5f6302b
Use ByteArray for consistency
Wollac Oct 19, 2020
f50ed56
Clarify the key intervals
Wollac Oct 19, 2020
23c79e6
Prevent milestone payload malleabilty
Wollac Oct 20, 2020
1178902
Update text/0019-milestone-payload/0019-milestone-payload.md
Wollac Oct 20, 2020
ad7a6cf
Fix number of hash bits
Wollac Oct 20, 2020
c999565
Fix array types
Wollac Oct 20, 2020
002b8db
Switch Index Number to 32-bit
Wollac Oct 21, 2020
dc0121c
clarify public key uniqueness
Wollac Nov 18, 2020
325d6f1
improve description
Wollac Dec 1, 2020
33bf058
Update text/0019-milestone-payload/0019-milestone-payload.md
Wollac Jan 13, 2021
da659ba
change parent 1 and parent 2 to parents
Mar 29, 2021
3354792
add next Pow Score
Mar 29, 2021
b091a94
use index and not delta
Mar 30, 2021
8a55c29
Array is not specified message rfc
Mar 30, 2021
a75034b
Update 0019-milestone-payload.md
Wollac Oct 25, 2021
544868b
Update 0019-milestone-payload.md
Wollac Oct 25, 2021
fdbe8ce
Update 0019-milestone-payload.md
Wollac Oct 25, 2021
56a28d2
Fix typo
Wollac Oct 25, 2021
824d05f
Merge remote-tracking branch 'origin/master' into jakubcech-milestone…
Wollac Oct 25, 2021
b7f4275
update link in merged RFC
Wollac Oct 25, 2021
00d5fd4
update link in merged RFC
Wollac Oct 25, 2021
90e8808
Fix typo
Wollac Oct 25, 2021
d69a5c3
Add nested payloads
Wollac Oct 26, 2021
4482d4a
Update 0019-milestone-payload.md
Wollac Oct 26, 2021
cc461bb
Fix typo
Wollac Oct 27, 2021
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 58 additions & 0 deletions text/0019-milestone-payload/0019-milestone-payload.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
+ Feature name: `Milestone Payload`
Wollac marked this conversation as resolved.
Show resolved Hide resolved
+ Start date: 2020-07-28
+ RFC PR: [iotaledger/protocol-rfcs#0019](https://github.com/iotaledger/protocol-rfcs/pull/19)
+ Author: Angelo Capossele

# Summary

In the IOTA protocol, nodes use the milestones issued by the Coordinator to reach a consensus on which transactions are confirmed.
This RFC proposes a new milestone payload as well as the EdDSA signature algorithm as a replacement to the current Coordinator digital signature scheme to authenticate the issued milestones.

thibault-martinez marked this conversation as resolved.
Show resolved Hide resolved
# Motivation
The current signature scheme used to authenticate milestones issued by the Coordinator has been designed with ternary and quantum robustness in mind. Due to the switch to binary, the new message layout as well as the upcoming Coordicide (i.e., Coordinator removal), we now have the opportunity to revisit such a mechanism and replace it with a more simple, well-vetted and standardized one. Although the proposed digital signature scheme, EdDSA, does not provide quantum robustness, its simplicity and easier key-managment make it a good candidate for the time being.
Wollac marked this conversation as resolved.
Show resolved Hide resolved

# Detailed design

The EdDSA signature algorithm in its variants **Ed25519** and **Ed448** (providing a security level of 128-bit and 224-bit respectively) are technically described in the IRTF [RFC 8032](https://tools.ietf.org/html/rfc8032).
Wollac marked this conversation as resolved.
Show resolved Hide resolved
Size of both private and public keys are of 32 or 57 bytes depending on the curve used. Similarly, the signature size is of 64 or 114 bytes.

- The Ed25519 key generation can be fed with a given random sequence of bytes (i.e., seed) of length 32 bytes. Output of the key generation is the pair of private and public keys. Note that the generation of the seed is out of the scope of this RFC, but in general, any cryptographic pseudo-random function (PRF) would suffice.
- The Ed25519 signature function takes a Ed25519 private key, a sequence of bytes of arbitrary size and produces an Ed25519 signature of length 64 bytes. The given sequence of bytes should then be internally hashed (using sha512) by the same function.
Wollac marked this conversation as resolved.
Show resolved Hide resolved
Wollac marked this conversation as resolved.
Show resolved Hide resolved
- The Ed25519 verification function takes a public key, a sequence of bytes of arbitrary size, a Ed25519 signature, and returns true/false based on the signature validity.

To generate a valid milestone, the Coordinator *MUST*:
1. Generate a *Message* as defined in [RFC-0017 (draft)](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md).
2. Generate a new [milestone payload](#Milestone-payload) without filling the signature field.
3. Sign the serialized bytes given by the concatenation of the following fields:
- Version, Parent1, Parent2, Payload Length of the Message;
Wollac marked this conversation as resolved.
Show resolved Hide resolved
Wollac marked this conversation as resolved.
Show resolved Hide resolved
- Payload Type, Index Number, Timestamp, Inclusion Merkle Proof of the Milestone Payload.
Wollac marked this conversation as resolved.
Show resolved Hide resolved
4. Fill the signature field of the milestone payload with the generated signature.
5. Perform the PoW over the Message to compute the value for the Nonce field.

To verify a given milestone, a node *MUST*:
- Verify the validity of the Message containing the Milestone Payload as in [RFC-0017 (draft)](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md).
- The payload type *MUST* be 1.
- The milestone payload must consume the entire byte array the Payload Length field in the Message defines.
- Verify the milestone signature against the Coordinator public key by using the exact same ByteArray used to sign the milestone.
- Validate Inclusion Merkle Proof as described in [RFC-0012](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0012-milestone-merkle-validation/0012-milestone-merkle-validation.md).

# Milestone payload

| Field Name | Type | Description |
| ---------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Payload Type | varint | Must be set to **1**. |
| Index Number | varint | The index number of the milestone. |
| Timestamp | uint64 | The Unix timestamp at which the milestone was issued. The unix timestamp is specified in seconds. |
| Inclusion Merkle Proof | Array<byte>[64] | Specifies the merkle proof which is computed out of all the tail transaction hashes of all the newly confirmed state-mutating bundles. ([RFC-0012](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0012-milestone-merkle-validation/0012-milestone-merkle-validation.md)) |
Wollac marked this conversation as resolved.
Show resolved Hide resolved
| Signature | Array<byte>[64] | The signature signing the entire message excluding the nonce and the signature itself. |

# Rationale and alternatives

Instead of going with EdDSA we could have chosen ECDSA. Both algorithms are well supported and widespread. However, signing with ECDSA requires fresh randomness while EdDSA does not. Moreover, we could have used a commit-reveal mechanism to update and commit the Coordinator public key at each next milestone. This method would make a quantum-based attack aimed at breaking the "current" Coordinator private-key more difficult. On the other hand, key management as well as verification of the milestone chain would become more complex.

# Unresolved questions

- Should we add support for multi-signature or multi-stage signature? Could that be a desired feature from a devOps perspective?
- Are we sure we want to lose quantum-robustness? We could have used a hash-based signature scheme, such as [XMSS](https://tools.ietf.org/html/rfc8391) or [LMS](https://tools.ietf.org/html/rfc8554) that provide quantum robustness at the price of increasing both communication and computation overhead. For more detail, please refer to this [document](https://docs.google.com/document/d/15_FkOhHFR4arxBBl07H_ETUGjPbf5jlJOiyYwZ7zKOg/edit?usp=sharing).
- Do we want to pick Ed25519 or Ed448? They provide a security level of 128-bit and 224-bit respectively. Size of both private and public keys are of 32 or 57 bytes depending on the curve used. Similarly, the signature size is of 64 or 114 bytes. Ed25519 has better library-wise support with respect to Ed448.
- Should we add a Network ID field to the payload? If yes, is the ID a string or a uint64?
Wollac marked this conversation as resolved.
Show resolved Hide resolved