From 335e812f2d9fc8a21d0cfbedcbaeec6897a0be74 Mon Sep 17 00:00:00 2001 From: pablo Date: Thu, 11 Apr 2024 17:29:23 +0300 Subject: [PATCH] small typos --- standards/core/relay-sharding.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/standards/core/relay-sharding.md b/standards/core/relay-sharding.md index 8372bd2..6b0b08e 100644 --- a/standards/core/relay-sharding.md +++ b/standards/core/relay-sharding.md @@ -49,14 +49,14 @@ Assigning content topics to specific shards is up to app protocols, but the discovery of these shards is managed by Waku. Static shards are managed in shard clusters of 1024 shards per cluster. -Waku static sharding can manage $2^16$ shard clusters. -Each shard cluster is identified by its index (between $0$ and $2^16-1$). +Waku static sharding can manage $2^{16}$ shard clusters. +Each shard cluster is identified by its index (between $0$ and $2^{16}-1$). A specific shard cluster is either globally available to all apps, specific for an app protocol, or reserved for automatic sharding (see next section). -> *Note:* This leads to $2^16 * 1024 = 2^26$ shards for which Waku manages discovery. +> *Note:* This leads to $2^{16} * 1024 = 2^{26}$ shards for which Waku manages discovery. App protocols can either choose to use global shards, or app specific shards. @@ -128,6 +128,7 @@ Nodes MAY interpret `rs` in such ENRs, but MUST ignore `rsv`. The ENR key is `rs`. The value is comprised of + * a two-byte shard cluster index in network byte order, concatenated with * a one-byte length field holding the number of shards in the given shard cluster, concatenated with * two-byte shard indices in network byte order