first clear research dir

.cspell.json

@@ -76,6 +76,7 @@
     "faucet",
     "concat",
     "certonly",
+    "txid",
   ],
   "flagWords": [],
   "ignorePaths": [

README.md

@@ -42,7 +42,7 @@ yarn check:spell
 Create a production build locally to check for errors:
 
 ```shell
-yarn build # Run 'node fetch-content.js' and then 'docusaurus build'
+yarn build # Runs 'node fetch-content.js' and then 'docusaurus build'
 # The 'fetch-content.js' script fetches documents from the nwaku and research repositories.
 
 # test the build

docs/research/benchmarks/cspell.json

@@ -0,0 +1,20 @@
+{ "words":
+    [
+        "pubsubtopic",
+        "jmeter",
+        "analyzed",
+        "queryc",
+        "wakudev",
+        "statusim",
+        "queryc",
+        "wakudev",
+        "statusim",
+        "chronos",
+        "libpqis",
+        "Conn",
+        "messageindex",
+        "storedat",
+        "pubsubtopic",
+        "wakudev"
+    ]
+}

docs/research/benchmarks/postgres-adoption.md

@@ -109,7 +109,7 @@ Notice that the two `nwaku` nodes run the very same version, which is compiled l
 
 #### Comparing archive SQLite & Postgres performance in [nwaku-b6dd6899](https://github.com/waku-org/nwaku/tree/b6dd6899030ee628813dfd60ad1ad024345e7b41)
 
-The next results were obtained by running the docker-compose-manual-binaries.yml from [test-waku-queryc078075](https://github.com/waku-org/test-waku-query/tree/c07807597faa781ae6c8c32eefdf48ecac03a7ba) in the sandbox machine (metal-01.he-eu-hel1.wakudev.misc.statusim.net.)
+The next results were obtained by running the docker-compose-manual-binaries.yml from [test-waku-query-c078075](https://github.com/waku-org/test-waku-query/tree/c07807597faa781ae6c8c32eefdf48ecac03a7ba) in the sandbox machine (metal-01.he-eu-hel1.wakudev.misc.statusim.net.)
 
 **Scenario 1**
 
@@ -155,7 +155,7 @@ In this case, the performance is similar regarding the timings. The store rate i
 
 This nwaku commit is after a few **Postgres** optimizations were applied.
 
-The next results were obtained by running the docker-compose-manual-binaries.yml from [test-waku-queryc078075](https://github.com/waku-org/test-waku-query/tree/c07807597faa781ae6c8c32eefdf48ecac03a7ba) in the sandbox machine (metal-01.he-eu-hel1.wakudev.misc.statusim.net.)
+The next results were obtained by running the docker-compose-manual-binaries.yml from [test-waku-query-c078075](https://github.com/waku-org/test-waku-query/tree/c07807597faa781ae6c8c32eefdf48ecac03a7ba) in the sandbox machine (metal-01.he-eu-hel1.wakudev.misc.statusim.net.)
 
 **Scenario 1**
 

docs/research/research-and-studies/cspell.json

@@ -0,0 +1,11 @@
+{ "words":
+    [
+        "deanonymise",
+        "filecoin",
+        "hopr",
+        "incentivisation",
+        "ipfs",
+        "lightpush",
+        "waku"
+    ]
+}

docs/research/research-and-studies/incentivisation.md

@@ -1,6 +1,10 @@
-Waku is a family of decentralized communication protocols.
+---
+title: Incentivisation
+---
+
+Waku is a family of decentralised communication protocols.
 The Waku Network (TWN) consists of independent nodes running Waku protocols.
-TWN needs incentivization (shortened to i13n) to ensure proper node behavior.
+TWN needs incentivisation (shortened to i13n) to ensure proper node behaviour.
 
 The goal of this document is to outline and contextualize our approach to TWN i13n.
 After providing an overview of Waku and relevant prior work,
@@ -8,10 +12,10 @@ we focus on Waku Store - a client-server protocol for querying historical messag
 We introduce a minimal viable addition to Store to enable i13n,
 and list research directions for future work.
 
-# Incentivization in decentralized networks
-## Incentivization tools
+# Incentivisation in decentralised networks
+## Incentivisation tools
 
-We can think of incentivization tools as a two-by-two matrix:
+We can think of incentivisation tools as a two-by-two matrix:
 - rewards vs punishment;
 - monetary vs reputation.
 
@@ -25,11 +29,11 @@ Reputation only works if high reputation brings tangible benefits.
 For example, if nodes chose neighbors based on reputation, low-reputation nodes miss out on potential revenue.
 Reputation scores may be local (a node assigns scores to its neighbors) or global (each node gets a uniform score).
 Global reputation in its simplest form involves a trusted third party,
-although decentralized approaches are also possible.
+although decentralised approaches are also possible.
 
 ## Prior work
 
-We may split incentivized decentralized networks into early file-sharing, blockchains, and decentralized storage.
+We may split incentivized decentralised networks into early file-sharing, blockchains, and decentralised storage.
 
 ### Early P2P file-sharing
 
@@ -46,16 +50,16 @@ PoW miners are automatically assigned newly mined coins for generating blocks.
 Miners must expend physical resources to generate a block.
 If the block is invalid, these expenses are not compensated (implicit monetary punishment).
 Proof-of-stake (PoS), used in Ethereum and many other cryptocurrencies, introduces explicit monetary punishments.
-PoS validators lock up (stake) native tokens and get rewarded for validating blocks or slashed for misbehavior.
+PoS validators lock up (stake) native tokens and get rewarded for validating blocks or slashed for misbehaviour.
 
-### Decentralized storage
+### Decentralised storage
 
-Post-Bitcoin decentralized storage networks include Codex, Storj, Sia, Filecoin, IPFS.
+Post-Bitcoin decentralised storage networks include Codex, Storj, Sia, Filecoin, IPFS.
 Their i13n methods combine techniques from early P2P file-sharing with blockchain-inspired reward mechanisms.
 
 # Waku background
 
-Waku is a [family of protocols](https://waku.org/about/architect) for a modular privacy-preserving censorship-resistant decentralized communication network.
+Waku is a [family of protocols](https://waku.org/about/architect) for a modular privacy-preserving censorship-resistant decentralised communication network.
 The backbone of Waku is the Relay protocol (and its spam-protected version [RLN-Relay](https://rfc.vac.dev/spec/17/)).
 Additionally, there are light protocols: Store, Filter, and Lightpush.
 Light protocols are also referred to as client-server protocols and request-response protocols.
@@ -72,12 +76,12 @@ In light protocols, a client sends a request to a server, and a server performs
 
 ## Waku i13n challenges
 
-Waku has no consensus and no native token, which brings it closer to reputation-incentivized file-sharing networks.
+Waku has no consensus and no native token, which brings it closer to reputation-incentivised file-sharing networks.
 As of late 2023, Waku only operates under reputation-based rewards and punishments.
 While [RLN-Relay](https://rfc.vac.dev/spec/17/) adds monetary punishments for spammers, slashing is yet to be activated.
 
-Monetary rewards and punishments should ideally be atomically linked with the node's behavior.
-A benefit of blockchains in this respect is that the desired behavior of miners or validators can be verified automatically.
+Monetary rewards and punishments should ideally be atomically linked with the node's behaviour.
+A benefit of blockchains in this respect is that the desired behaviour of miners or validators can be verified automatically.
 Enforcing atomicity in a communication network is more challenging:
 it is non-trivial to prove that a given piece of data has been relayed.
 
@@ -96,9 +100,9 @@ The response may be split into multiple parts, as specified by pagination parame
 We define a _relevant_ message as a message that matches client-defined criteria (e.g., relayed within a given time frame).
 Upon receiving a request, a server should quickly send back a response containing all and only relevant messages.
 
-# Waku Store incentivization
+# Waku Store incentivisation
 
-An incentivized Store protocol has the following extra steps:
+An incentivised Store protocol has the following extra steps:
 1. pricing:
 	1. cost calculation
 	2. price advertisement
@@ -155,7 +159,7 @@ The client gives proof of payment before it receives the response.
 Other options could be:
 1. the client pays after the fact;
 2. the client pays partly upfront and partly after the fact;
-3. a centralized third party (either trusted or semi-trusted, like a smart contract) ensures atomicity;
+3. a centralised third party (either trusted or semi-trusted, like a smart contract) ensures atomicity;
 4. cryptographically ensured atomicity (similar to atomic swaps, Lightning, or Hopr).
 
 Our design considerations are:
@@ -165,7 +169,7 @@ Our design considerations are:
 
 In light of these criteria, we suggest that the client pays first.
 This is simpler than splitting the payment, or involving an extra atomicity-enforcing mechanism.
-Moreover, pre-payment is arguably more privacy-preserving than post-payment, which encourages servers to deanonymize clients to prevent fraud.
+Moreover, pre-payment is arguably more privacy-preserving than post-payment, which encourages servers to deanonymise clients to prevent fraud.
 
 ### Future work
 
@@ -179,7 +183,7 @@ Moreover, pre-payment is arguably more privacy-preserving than post-payment, whi
 We use reputation to discourage the server from taking the payment and not responding.
 The client keeps track of the server's reputation:
 - all servers start with zero reputation points;
-- if the server honors the request, it gets `+n` points;
+- if the server honours the request, it gets `+n` points;
 - if the server does not respond before a timeout, it gets `-m` points.
 - if the server's reputation drops below `k` points, the client will never query it again.
 
@@ -189,7 +193,7 @@ Optionally, a client may treat a given server as trusted, assigning it a constan
 
 Potential issues:
 - An attacker can establish new server identities and continue running away with clients' money. Countermeasures:
-	- a client only queries trusted servers (which however leads to centralization);
+	- a client only queries trusted servers (which however leads to centralisation);
 	- when querying a new server, a client first sends a small (i.e. cheap) request as a test;
 	- more generally, the client selects a server on a case-by-case basis, weighing the payment amount against the server's reputation.
 - The ban mechanism can theoretically be abused. For instance, a competitor may attack the victim server and cause the clients who were awaiting the response to ban that server. Countermeasure: prevent DoS-attacks.
@@ -213,11 +217,11 @@ Cross-checking is absent in PoC but may be considered later.
 
 # Evaluation
 
-We should think about what the success metrics for an incentivized protocol are, and how to measure them both in simulated settings, as well as in a live network.
+We should think about what the success metrics for an incentivised protocol are, and how to measure them both in simulated settings, as well as in a live network.
 
 # Longer-term future work
 
 - Analyze privacy issues - see https://github.com/waku-org/research/issues/61
-- Analyze decentralized storage protocols and their relevance e.g. as back-end storage for Store servers - see https://github.com/waku-org/research/issues/34
+- Analyze decentralised storage protocols and their relevance e.g. as back-end storage for Store servers - see https://github.com/waku-org/research/issues/34
 - Analyze the role of message senders, in particular, whether they should pay for sending non-ephemeral messages - see https://github.com/waku-org/research/issues/32
-- Generalize incentivization protocol to other Waku light protocols (Lightpush and Filter) - see https://github.com/waku-org/research/issues/67.
+- Generalise incentivisation protocol to other Waku light protocols (Lightpush and Filter) - see https://github.com/waku-org/research/issues/67.

fetch-content.js

@@ -72,6 +72,8 @@ const repositories = [
     }
 ];
 
+fs.rmSync('docs/research/', { recursive: true, force: true });
+
 repositories.forEach(repo => {
     fetchDirectoryContents(repo.baseUrl, repo.baseSavePath, repo.prefixToRemove);
 });

sidebars.js

@@ -85,21 +85,20 @@ const sidebars = {
 		"learn/waku-vs-libp2p",
 		"learn/glossary",
 	],
-  research: [
-    {
-      type: "category",
-      label: "Research and Studies",
-      collapsed: false,
-      items: ["research/research-and-studies/incentivization"],
-    },
-    {
-      type: "category",
-      label: "nwaku Benchmarks",
-      collapsed: false,
-      items: ["research/benchmarks/postgres-adoption"],
-    },
-  ],
-
+	research: [
+		{
+			type: "category",
+			label: "Research and Studies",
+			collapsed: false,
+			items: ["research/research-and-studies/incentivisation"],
+		},
+		{
+			type: "category",
+			label: "Nwaku Benchmarks",
+			collapsed: false,
+			items: ["research/benchmarks/postgres-adoption"],
+		},
+	],
 };
 
 module.exports = sidebars;