CIP-0137 | Fix protocol specifications

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