From 6b4262b55ca53592468164fdb0a3cef151223633 Mon Sep 17 00:00:00 2001 From: Pierre Krieger Date: Tue, 26 Dec 2023 20:35:04 +0100 Subject: [PATCH] Enforce one transaction per notification in the networking (#56) [Rendered](https://github.com/tomaka/RFCs-1/blob/one-tx-per-notif/text/0056-one-transaction-per-notification.md) This RFC is pretty small, and I expect it to be pretty uncontroversial. Just because something is currently designed a certain way doesn't mean that it is so for a good reason, and sometimes, like in this RFC, things just need to be cleaned up. --- text/0056-one-transaction-per-notification.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 text/0056-one-transaction-per-notification.md diff --git a/text/0056-one-transaction-per-notification.md b/text/0056-one-transaction-per-notification.md new file mode 100644 index 000000000..545752e88 --- /dev/null +++ b/text/0056-one-transaction-per-notification.md @@ -0,0 +1,96 @@ +# RFC-0056: Enforce only one transaction per notification + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | 2023-11-30 | +| **Description** | Modify the transactions notifications protocol to always send only one transaction at a time| +| **Authors** | Pierre Krieger | + +## Summary + +When two peers connect to each other, they open (amongst other things) a so-called "notifications protocol" substream dedicated to gossiping transactions to each other. + +Each notification on this substream currently consists in a SCALE-encoded `Vec` where `Transaction` is defined in the runtime. + +This RFC proposes to modify the format of the notification to become `(Compact(1), Transaction)`. This maintains backwards compatibility, as this new format decodes as a `Vec` of length equal to 1. + +## Motivation + +There exists three motivations behind this change: + +- It is technically impossible to decode a SCALE-encoded `Vec` into a list of SCALE-encoded transactions without knowing how to decode a `Transaction`. That's because a `Vec` consists in several `Transaction`s one after the other in memory, without any delimiter that indicates the end of a transaction and the start of the next. Unfortunately, the format of a `Transaction` is runtime-specific. This means that the code that receives notifications is necessarily tied to a specific runtime, and it is not possible to write runtime-agnostic code. + +- Notifications protocols are already designed to be optimized to send many items. Currently, when it comes to transactions, each item is a `Vec` that consists in multiple sub-items of type `Transaction`. This two-steps hierarchy is completely unnecessary, and was originally written at a time when the networking protocol of Substrate didn't have proper multiplexing. + +- It makes the implementation way more straight-forward by not having to repeat code related to back-pressure. See explanations below. + +## Stakeholders + +Low-level developers. + +## Explanation + +To give an example, if you send one notification with three transactions, the bytes that are sent on the wire are: + +``` +concat( + leb128(total-size-in-bytes-of-the-rest), + scale(compact(3)), scale(transaction1), scale(transaction2), scale(transaction3) +) +``` + +But you can also send three notifications of one transaction each, in which case it is: + +``` +concat( + leb128(size(scale(transaction1)) + 1), scale(compact(1)), scale(transaction1), + leb128(size(scale(transaction2)) + 1), scale(compact(1)), scale(transaction2), + leb128(size(scale(transaction3)) + 1), scale(compact(1)), scale(transaction3) +) +``` + +Right now the sender can choose which of the two encoding to use. This RFC proposes to make the second encoding mandatory. + +The format of the notification would become a SCALE-encoded `(Compact(1), Transaction)`. +A SCALE-compact encoded `1` is one byte of value `4`. In other words, the format of the notification would become `concat(&[4], scale_encoded_transaction)`. +This is equivalent to forcing the `Vec` to always have a length of 1, and I expect the Substrate implementation to simply modify the sending side to add a `for` loop that sends one notification per item in the `Vec`. + +As explained in the motivation section, this allows extracting `scale(transaction)` items without having to know how to decode them. + +By "flattening" the two-steps hierarchy, an implementation only needs to back-pressure individual notifications rather than back-pressure notifications and transactions within notifications. + +## Drawbacks + +This RFC chooses to maintain backwards compatibility at the cost of introducing a very small wart (the `Compact(1)`). + +An alternative could be to introduce a new version of the transactions notifications protocol that sends one `Transaction` per notification, but this is significantly more complicated to implement and can always be done later in case the `Compact(1)` is bothersome. + +## Testing, Security, and Privacy + +Irrelevant. + +## Performance, Ergonomics, and Compatibility + +### Performance + +Irrelevant. + +### Ergonomics + +Irrelevant. + +### Compatibility + +The change is backwards compatible if done in two steps: modify the sender to always send one transaction per notification, then, after a while, modify the receiver to enforce the new format. + +## Prior Art and References + +Irrelevant. + +## Unresolved Questions + +None. + +## Future Directions and Related Material + +None. This is a simple isolated change.