diff --git a/CIP-0137/README.md b/CIP-0137/README.md index 65cddeda7d..d3e312d25e 100644 --- a/CIP-0137/README.md +++ b/CIP-0137/README.md @@ -151,7 +151,7 @@ messageList = [ * message ] messageSizeInBytes = word32 kesSignature = bstr kesPeriod = word32 -operationalCertificate = [ bstr, word64, word64, bstr ] +operationalCertificate = [ bstr .size 32, word64, word64, bstr .size 64 ] coldVerificationKey = bstr .size 32 expiresAt = word32 @@ -162,9 +162,9 @@ messagePayload = [ , expiresAt ] message = [ - bstr .cbor messagePayload + messagePayload , kesSignature - , bstr .cbor operationalCertificate + , operationalCertificate , coldVerificationKey ] ``` @@ -245,7 +245,7 @@ For a total of **3,100** Cardano SPOs on the `mainnet`, on an average **50%** of ##### Message authentication mechanism -The payload part of the message (message id, message body, KES period and expiration timestamp fields encoded as CBOR) is signed with the KES key of the SPO. The message is composed of the aforementioned payload (encoded as CBOR bytes), the KES signature (raw bytes), the operational certificate (the KES public key, the issue number of the operational certificate, the KES period at the time of creation of the operational certificate and their cold signing key signature, encoded as CBOR bytes) and the cold verification key (raw bytes) are appended to the message. +The payload part of the message (message id, message body, KES period and expiration timestamp fields) is signed with the KES key of the SPO (the message signed is the CBOR encoding of the payload: `bstr .cbor messagePayload`). The message is composed of the aforementioned payload (encoded as an array), the KES signature (raw bytes), the operational certificate (the KES public key, the issue number of the operational certificate, the KES period at the time of creation of the operational certificate and their cold signing key signature, encoded as an array) and the cold verification key (raw bytes) are appended to the message. Before being diffused to other peers, an incoming message must be verified by the receiving node. This is done with the following steps: @@ -479,7 +479,7 @@ messageId = bstr messageBody = bstr kesSignature = bstr kesPeriod = word64 -operationalCertificate = [ bstr, word64, word64, bstr ] +operationalCertificate = [ bstr .size 32, word64, word64, bstr .size 64 ] coldVerificationKey = bstr .size 32 expiresAt = word32 @@ -490,9 +490,9 @@ messagePayload = [ , expiresAt ] message = [ - bstr .cbor messagePayload + messagePayload , kesSignature - , bstr .cbor operationalCertificate + , operationalCertificate , coldVerificationKey ] ``` @@ -511,10 +511,6 @@ The protocol follows a simple request-response pattern: #### State machine -| Agency | | -| ----------------- | ---------------------------------------- | -| Client has Agency | StIdle | -| Server has Agency | StBusyNonBlocking,StBusyBlocking, StDone | | Agency | | | ----------------- | ---------------------------------------- | | Client has Agency | StIdle | @@ -568,15 +564,15 @@ localMessageNotificationMessage / msgClientDone msgRequestMessages = [0, isBlocking] -msgReplyMessagesNonBlocking = [1, messages, hasMore] -msgReplyMessagesBlocking = [2, messages] +msgReplyMessagesNonBlocking = [1, [* message], hasMore] +msgReplyMessagesBlocking = [2, [+ message]] msgClientDone = [3] messageId = bstr messageBody = bstr kesSignature = bstr kesPeriod = word64 -operationalCertificate = [ bstr, word64, word64, bstr ] +operationalCertificate = [ bstr .size 32, word64, word64, bstr .size 64 ] coldVerificationKey = bstr .size 32 expiresAt = word32 @@ -587,15 +583,14 @@ messagePayload = [ , expiresAt ] message = [ - bstr .cbor messagePayload + messagePayload , kesSignature - , bstr .cbor operationalCertificate + , operationalCertificate , coldVerificationKey ] hasMore = false / true isBlocking = false / true -messages = [* message] ``` ## Rationale: how does this CIP achieve its goals? @@ -706,15 +701,15 @@ the KES key. - [x] Validate protocol behaviour with all relevant parties (Network and Node teams). - [x] Make the current Cardano Network Diffusion Layer general and reusable so a new, separate Mithril Diffusion Layer can be instantiated. - See [here](https://github.com/IntersectMBO/ouroboros-network/wiki/Reusable-Diffusion-Investigation) and [here](https://github.com/IntersectMBO/ouroboros-network/pull/5016) -- [ ] Implement DMQ Node that is able to run general diffusion (i.e. without the mini-protocols). +- [x] Implement DMQ Node that is able to run general diffusion (i.e. without the mini-protocols). - See [here](https://github.com/IntersectMBO/ouroboros-network/pull/5109) -- [ ] Implement the n2n and n2c mini-protocols: - - [ ] Haskell DMQ Node: - - [ ] n2c mini-protocols - - [ ] n2n mini-protocols - - [ ] Pallas Library (TxPipe): +- [x] Implement the n2n and n2c mini-protocols: + - [x] Haskell DMQ Node: + - [x] n2c mini-protocols + - [x] n2n mini-protocols + - [x] Pallas Library (TxPipe): - [x] n2c mini-protocols - - [ ] n2n mini-protocols + - [x] ~~n2n mini-protocols~~ (will be done in a separate stream of work) - [x] Implement the n2c mini-protocols in Mithril nodes: - [x] Mithril signer - [x] Mithril aggregator