github/vac.dev
1
1
Fork 0
mirror of https://github.com/vacp2p/vac.dev.git synced 2026-01-07 22:03:55 -05:00
Code Issues Packages Projects Releases Wiki Activity

use blog plugin for research docs

Browse Source
This commit is contained in:
Hossein Mehrabi
2023-06-13 18:29:56 +03:30
parent a8de26546f
commit 60abe1a89b
33 changed files with 683 additions and 724 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
data/authors.js
View File

@@ -1,65 +0,0 @@
/** @type {import('@acid-info/logos-docusaurus-theme').ThemeOptions['docs'][string]['content']['authors']} */
const authors = [
{
key: 'circe',
name: 'Circe',
twitter: 'vacp2p',
github: 'thecirce',
},
{
key: 'dean',
name: 'Dean',
twitter: 'DeanEigenmann',
github: 'decanus',
website: 'https://dean.eigenmann.me',
},
{
key: 'franck',
name: 'Franck',
twitter: 'fryorcraken',
github: 'fryorcraken',
},
{
key: 'hanno',
name: 'Hanno Cornelius',
twitter: '4aelius',
github: 'jm-clius',
},
{
key: 'kaiserd',
name: 'Daniel',
github: 'kaiserd',
},
{
key: 'oskarth',
name: 'Oskar',
twitter: 'oskarth',
github: 'oskarth',
},
{
key: 'rramos',
name: 'Richard',
twitter: 'richardramos_me',
github: 'richard-ramos',
website: 'https://richard-ramos.github.io/',
},
{
key: 's1fr0',
name: 's1fr0',
github: 's1fr0',
},
{
key: 'sanaz',
name: 'Sanaz',
twitter: 'sanaz2016',
github: 'staheri14',
},
{
key: 'sanaz',
name: 'Sanaz',
twitter: 'sanaz2016',
github: 'staheri14',
},
]
module.exports = authors

30
docs/sidebars.js
View File

@@ -8,36 +8,6 @@ module.exports = {
'publications',
'contribute',
'media',
{
Research: [
'2023-04-24-device-pairing-in-js-waku-and-go-waku',
'2023-04-03-waku-as-a-network',
'2022-11-08-waku-for-all-decentralize-applications',
'2022-11-04-building-privacy-protecting-infrastructure',
'2022-07-22-relay-anonymity',
'2022-05-17-noise',
'2022-05-09-ambient-peer-discovery',
'2022-04-12-introducing-nwaku',
'2021-12-03-ethics-surveillance-tech',
'2021-10-25-waku-v1-vs-waku-v2',
'2021-08-06-coscup-waku-ethereum',
'2021-06-04-presenting-js-waku',
'2021-03-03-rln-relay',
'2020-11-10-waku-v2-ethereum-messaging',
'2020-09-28-waku-v2-update',
'2020-07-01-waku-v2-pitch',
'2020-04-27-feasibility-discv5',
'2020-04-16-wechat-replacement-need',
'2020-04-9-kademlia-to-discv5',
'2020-02-14-waku-update',
'2020-02-7-dns-based-discovery',
'2019-12-03-fixing-whisper-with-waku',
'2019-11-08-feasibility-semaphore-rate-limiting-zksnarks',
'2019-10-04-remote-log',
'2019-08-02-vac-overview',
'2019-07-19-p2p-data-sync-for-mobile',
],
},
{
type: 'category',
label: 'Resources',

2
docs/terms.md
View File

@@ -1,5 +1,5 @@
---
displayed_sidebar: main
displayed_sidebar: null
---
# Terms of Use

48
docusaurus.config.js
View File

@@ -2,8 +2,6 @@
// Note: type annotations allow type checking and IDEs autocompletion
require('dotenv').config()
const authors = require('./data/authors')
const math = require('remark-math')
const katex = require('rehype-katex')
@@ -35,20 +33,10 @@ const config = {
name: 'default',
options: {
customCss: [require.resolve('./src/css/custom.scss')],
docs: {
default: {
content: {
authors,
authorPage: {
sidebar: 'main',
},
},
},
},
},
},
docs: {
routeBasePath: '/',
routeBasePath: '/about',
sidebarPath: 'docs/sidebars.js',
remarkPlugins: [math],
rehypePlugins: [katex],
@@ -57,9 +45,41 @@ const config = {
],
],
themes: ['@docusaurus/theme-mermaid'],
plugins: [
[
'@docusaurus/plugin-content-blog',
/** @type {import('@docusaurus/plugin-content-blog').PluginOptions} */
({
id: 'blog',
routeBasePath: '/',
path: 'research',
blogSidebarCount: 'ALL',
blogSidebarTitle: 'All our posts',
authorsMapPath: 'authors.yml',
remarkPlugins: [math],
rehypePlugins: [katex],
}),
],
],
themeConfig:
/** @type {import('@acid-info/logos-docusaurus-preset').ThemeConfig} */
({
navbar: {
items: [
{
type: 'search',
},
{
label: 'About',
to: '/about',
},
{
label: 'Research',
to: '/',
},
],
},
footer: {
links: [
{
@@ -90,7 +110,7 @@ const config = {
},
{
label: 'Terms & Conditions',
to: '/terms',
to: '/about/terms',
},
],
},

2
package.json
View File

@@ -15,7 +15,7 @@
"typecheck": "tsc"
},
"dependencies": {
"@acid-info/logos-docusaurus-preset": "^1.0.0-alpha.34",
"@acid-info/logos-docusaurus-preset": "^1.0.0-alpha.44",
"@docusaurus/core": "2.4.1",
"@docusaurus/preset-classic": "2.4.1",
"@docusaurus/theme-mermaid": "^2.4.1",

9
docs/2019-07-19-p2p-data-sync-for-mobile.mdx → research/2019-07-19-p2p-data-sync-for-mobile.mdx
View File

@@ -1,20 +1,19 @@
---
title: "P2P Data Sync for Mobile"
title: 'P2P Data Sync for Mobile'
date: 2019-07-19 12:00:00
author: oskarth
authors: oskarth
published: true
slug: p2p-data-sync-for-mobile
categories: research
summary: A research log. Reliable and decentralized, pick two.
image: /img/mvds_interactive.png
toc_min_heading_level: 2
toc_max_heading_level: 5
---
import { DocMetadata } from '@site/src/components/mdx'
A research log. Reliable and decentralized, pick two.
<DocMetadata />
<!--truncate-->
Together with decanus, I've been working on the problem of data sync lately.

46
docs/2019-08-02-vac-overview.mdx → research/2019-08-02-vac-overview.mdx
View File

@@ -1,48 +1,47 @@
---
layout: post
name: "Vac - A Rough Overview"
title: "Vac - A Rough Overview"
date: 2019-08-02 12:00:00
author: oskarth
name: 'Vac - A Rough Overview'
title: 'Vac - A Rough Overview'
date: 2019-08-02 12:00:00
authors: oskarth
published: true
slug: vac-overview
categories: research
summary: Vac is a modular peer-to-peer messaging stack, with a focus on secure messaging. Overview of terms, stack and open problems.
---
import { DocMetadata } from '@site/src/components/mdx'
Vac is a modular peer-to-peer messaging stack, with a focus on secure messaging. Overview of terms, stack and open problems.
<DocMetadata />
<!--truncate-->
Vac is a **modular peer-to-peer messaging stack, with a focus on secure messaging**. What does that mean? Let's unpack it a bit.
## Basic terms
*messaging stack*. While the initial focus is on [data sync](https://vac.dev/p2p-data-sync-for-mobile), we are concerned with all layers in the stack. That means all the way from underlying transports, p2p overlays and routing, to initial trust establishment and semantics for things like group chat. The ultimate goal is to give application developers the tools they need to provide secure messaging for their users, so they can focus on their domain expertise.
_messaging stack_. While the initial focus is on [data sync](https://vac.dev/p2p-data-sync-for-mobile), we are concerned with all layers in the stack. That means all the way from underlying transports, p2p overlays and routing, to initial trust establishment and semantics for things like group chat. The ultimate goal is to give application developers the tools they need to provide secure messaging for their users, so they can focus on their domain expertise.
*modular*. Unlike many other secure messaging applications, our goal is not to have a tightly coupled set of protocols, nor is it to reinvent the wheel. Instead, we aim to provide options at each layer in the stack, and build on the shoulders of giants, putting a premimum on interoperability. It's similar in philosophy to projects such as [libp2p](https://libp2p.io/) or [Substrate](https://www.parity.io/substrate/) in that regard. Each choice comes with different trade-offs, and these look different for different applications.
_modular_. Unlike many other secure messaging applications, our goal is not to have a tightly coupled set of protocols, nor is it to reinvent the wheel. Instead, we aim to provide options at each layer in the stack, and build on the shoulders of giants, putting a premimum on interoperability. It's similar in philosophy to projects such as [libp2p](https://libp2p.io/) or [Substrate](https://www.parity.io/substrate/) in that regard. Each choice comes with different trade-offs, and these look different for different applications.
*peer-to-peer*. The protocols we work on are pure p2p, and aim to minimize centralization. This too is in opposition to many initiatives in the secure messaging space.
_peer-to-peer_. The protocols we work on are pure p2p, and aim to minimize centralization. This too is in opposition to many initiatives in the secure messaging space.
*messaging*. By messaging we mean messaging in a generalized sense. This includes both human to human communication, as well machine to machine communication. By messaging we also mean something more fundamental than text messages, we also include things like transactions (state channels, etc) under this moniker.
_messaging_. By messaging we mean messaging in a generalized sense. This includes both human to human communication, as well machine to machine communication. By messaging we also mean something more fundamental than text messages, we also include things like transactions (state channels, etc) under this moniker.
*secure messaging*. Outside of traditional notions of secure messaging, such as ensuring end to end encryption, forward secrecy, avoiding MITM-attacks, etc, we are also concerned with two other forms of secure messaging. We call these *private messaging* and *censorship-resistance*. Private messaging means viewing privacy as a security property, with all that entails. Censorship resistance ties into being p2p, but also in terms of allowing for transports and overlays that can't easily be censored by port blocking, traffic analysis, and similar.
_secure messaging_. Outside of traditional notions of secure messaging, such as ensuring end to end encryption, forward secrecy, avoiding MITM-attacks, etc, we are also concerned with two other forms of secure messaging. We call these _private messaging_ and _censorship-resistance_. Private messaging means viewing privacy as a security property, with all that entails. Censorship resistance ties into being p2p, but also in terms of allowing for transports and overlays that can't easily be censored by port blocking, traffic analysis, and similar.
*Vāc*. Is a Vedic goddess of speech. It also hints at being a vaccine.
_Vāc_. Is a Vedic goddess of speech. It also hints at being a vaccine.
## Protocol stack
What does this stack look like? We take inspiration from [core](https://tools.ietf.org/html/rfc793) [internet architecture](https://www.ietf.org/rfc/rfc1122.txt), existing [survey work](https://css.csail.mit.edu/6.858/2020/readings/secure-messaging.pdf) and other [efforts](https://code.briarproject.org/briar/briar/wikis/A-Quick-Overview-of-the-Protocol-Stack) that have been done to decompose the problem into orthogonal pieces. Each layer provides their own set of properties and only interact with the layers it is adjacent to. Note that this is a rough sketch.
| Layer / Protocol | Purpose | Examples |
|-------------------|-----------------------------------|----------------------|
| Application layer | End user semantics | 1:1 chat, group chat |
| Data Sync | Data consistency | MVDS, BSP |
| Secure Transport | Confidentiality, PFS, etc | Double Ratchet, MLS |
| Transport Privacy | Transport and metadata protection | Whisper, Tor, Mixnet |
| P2P Overlay | Overlay routing, NAT traversal | devp2p, libp2p |
| | |
| Trust Establishment | Establishing end-to-end trust | TOFU, web of trust |
| Layer / Protocol | Purpose | Examples |
| ------------------- | --------------------------------- | -------------------- |
| Application layer | End user semantics | 1:1 chat, group chat |
| Data Sync | Data consistency | MVDS, BSP |
| Secure Transport | Confidentiality, PFS, etc | Double Ratchet, MLS |
| Transport Privacy | Transport and metadata protection | Whisper, Tor, Mixnet |
| P2P Overlay | Overlay routing, NAT traversal | devp2p, libp2p |
| | |
| Trust Establishment | Establishing end-to-end trust | TOFU, web of trust |
As an example, end user semantics such as group chat or moderation capabilities can largely work regardless of specific choices further down the stack. Similarly, using a mesh network or Tor doesn't impact the use of Double Ratchet at the Secure Transport layer.
@@ -55,11 +54,13 @@ In terms of specific properties and trade-offs at each layer, we'll go deeper do
With all the pieces involved, this is quite an undertaking. Luckily, a lot of pieces are already in place and can be either incorporated as-is or iterated on. In terms of medium and long term, here's a rough sketch of priorities and open problems.
1. **Better data sync.** While the current [MVDS](https://rfc.vac.dev/spec/2/) works, it is lacking in a few areas:
- Lack of remote log for mostly-offline offline devices
- Better scalability for multi-user chat contexts
- Better usability in terms of application layer usage and supporting more transports
2. **Better transport layer support.** Currently MVDS runs primarily over Whisper, which has a few issues:
- scalability, being able to run with many nodes
- spam-resistance, proof of work is a poor mechanism for heterogeneous devices
- no incentivized infrastructure, leading to centralized choke points
@@ -71,7 +72,6 @@ In addition to these most immediate concerns, there are other open problems. Som
4. **Incentivized and spam-resistant messaging.** Reasons to run infrastructure and not relying on altruistic nodes. For spam resistance, in p2p multicast spam is a big attack vector due to amplification. There are a few interesting directions here, such as EigenTrust, proof of burn with micropayments, and leveraging zero-knowledge proofs.
5. **Strong privacy guarantees at transport privacy layer**. More rigorous privacy guarantees and explicit trade-offs for metadata protection. Includes Mixnet.
6. **Censorship-resistant and robust P2P overlay**. NAT traversal; running in the browser; mesh networks; pluggable transports for traffic obfuscation.
7. **Scalable and decentralized secure conversational security.** Strong security guarantees such as forward secrecy, post compromise security, for large group chats. Includes projects such MLS and extending Double Ratchet.

66
docs/2019-10-04-remote-log.mdx → research/2019-10-04-remote-log.mdx
View File

@@ -1,25 +1,25 @@
---
layout: post
name: "P2P Data Sync with a Remote Log"
title: "P2P Data Sync with a Remote Log"
date: 2019-10-04 12:00:00
author: oskarth
name: 'P2P Data Sync with a Remote Log'
title: 'P2P Data Sync with a Remote Log'
date: 2019-10-04 12:00:00
authors: oskarth
published: true
slug: remote-log
categories: research
summary: A research log. Asynchronous P2P messaging? Remote logs to the rescue!
summary:
image: /img/remote-log.png
---
import { DocMetadata } from '@site/src/components/mdx'
A research log. Asynchronous P2P messaging? Remote logs to the rescue!
<DocMetadata />
<!--truncate-->
A big problem when doing end-to-end data sync between mobile nodes is that most devices are offline most of the time. With a naive approach, you quickly run into issues of 'ping-pong' behavior, where messages have to be constantly retransmitted. We saw some basic calculations of what this bandwidth multiplier looks like in a [previous post](https://vac.dev/p2p-data-sync-for-mobile).
While you could do some background processing, this is really battery-draining, and on iOS these capabilities are limited. A better approach instead is to loosen the constraint that two nodes need to be online at the same time. How do we do this? There are two main approaches, one is the *store and forward model*, and the other is a *remote log*.
While you could do some background processing, this is really battery-draining, and on iOS these capabilities are limited. A better approach instead is to loosen the constraint that two nodes need to be online at the same time. How do we do this? There are two main approaches, one is the _store and forward model_, and the other is a _remote log_.
In the *store and forward* model, we use an intermediate node that forward messages on behalf of the recipient. In the *remote log* model, you instead replicate the data onto some decentralized storage, and have a mutable reference to the latest state, similar to DNS. While both work, the latter is somewhat more elegant and "pure", as it has less strict requirements of an individual node's uptime. Both act as a highly-available cache to smoothen over non-overlapping connection windows between endpoints.
In the _store and forward_ model, we use an intermediate node that forward messages on behalf of the recipient. In the _remote log_ model, you instead replicate the data onto some decentralized storage, and have a mutable reference to the latest state, similar to DNS. While both work, the latter is somewhat more elegant and "pure", as it has less strict requirements of an individual node's uptime. Both act as a highly-available cache to smoothen over non-overlapping connection windows between endpoints.
In this post we are going to describe how such a remote log schema could work. Specifically, how it enhances p2p data sync and takes care of the [following requirements](https://vac.dev/p2p-data-sync-for-mobile):
@@ -35,15 +35,15 @@ In this post we are going to describe how such a remote log schema could work. S
A remote log is a replication of a local log. This means a node can read data from a node that is offline.
The spec is in an early draft stage and can be found [here](https://github.com/vacp2p/specs/pull/16). A very basic [spike](https://en.wikipedia.org/wiki/Spike_(software_development)) / proof-of-concept can be found [here](https://github.com/vacp2p/research/tree/master/remote_log).
The spec is in an early draft stage and can be found [here](https://github.com/vacp2p/specs/pull/16). A very basic [spike](<https://en.wikipedia.org/wiki/Spike_(software_development)>) / proof-of-concept can be found [here](https://github.com/vacp2p/research/tree/master/remote_log).
### Definitions
| Term | Definition |
| ----------- | -------------------------------------------------------------------------------------- |
| CAS | Content-addressed storage. Stores data that can be addressed by its hash. |
| NS | Name system. Associates mutable data to a name. |
| Remote log | Replication of a local log at a different location. |
| Term | Definition |
| ---------- | ------------------------------------------------------------------------- |
| CAS | Content-addressed storage. Stores data that can be addressed by its hash. |
| NS | Name system. Associates mutable data to a name. |
| Remote log | Replication of a local log at a different location. |
### Roles
@@ -51,10 +51,10 @@ There are four fundamental roles:
1. Alice
2. Bob
2. Name system (NS)
3. Content-addressed storage (CAS)
3. Name system (NS)
4. Content-addressed storage (CAS)
The *remote log* is the data format of what is stored in the name system.
The _remote log_ is the data format of what is stored in the name system.
"Bob" can represent anything from 0 to N participants. Unlike Alice, Bob only needs read-only access to NS and CAS.
@@ -73,22 +73,22 @@ The remote log lets receiving nodes know what data they are missing. Depending o
A remote log is simply a mapping from message identifiers to their corresponding address in a CAS:
| Message Identifier (H1) | CAS Hash (H2) |
| ---------------- |---------------|
| H1_3 | H2_3 |
| H1_2 | H2_2 |
| H1_1 | H2_1 |
| | |
| *address to next page* |
| ----------------------- | ------------- |
| H1_3 | H2_3 |
| H1_2 | H2_2 |
| H1_1 | H2_1 |
| | |
| _address to next page_ |
The numbers here corresponds to messages. Optionally, the content itself can be included, just like it normally would be sent over the wire. This bypasses the need for a dedicated CAS and additional round-trips, with a trade-off in bandwidth usage.
| Message Identifier (H1) | Content |
| ---------------- |---------------|
| H1_3 | C3 |
| H1_2 | C2 |
| H1_1 | C1 |
| | |
| *address to next page* |
| Message Identifier (H1) | Content |
| ----------------------- | ------- |
| H1_3 | C3 |
| H1_2 | C2 |
| H1_1 | C1 |
| | |
| _address to next page_ |
Both patterns can be used in parallel, e,g. by storing the last `k` messages directly and use CAS pointers for the rest. Together with the `next_page` page semantics, this gives users flexibility in terms of bandwidth and latency/indirection, all the way from a simple linked list to a fully replicated log. The latter is useful for things like backups on durable storage.
@@ -101,13 +101,13 @@ Both patterns can be used in parallel, e,g. by storing the last `k` messages dir
The spec is still in an early draft stage, so it is expected to change. Same with the proof of concept. More work is needed on getting a fully featured proof of concept with specific CAS and NAS instances. E.g. Swarm and Swarm Feeds, or IPFS and IPNS, or something else.
For data sync in general:
- Make consistency guarantees more explicit for app developers with support for sequence numbers and DAGs, as well as the ability to send non-synced messages. E.g. ephemeral typing notifications, linear/sequential history and casual consistency/DAG history
- Make consistency guarantees more explicit for app developers with support for sequence numbers and DAGs, as well as the ability to send non-synced messages. E.g. ephemeral typing notifications, linear/sequential history and casual consistency/DAG history
- Better semantics and scalability for multi-user sync contexts, e.g. CRDTs and joining multiple logs together
- Better usability in terms of application layer usage (data sync clients) and supporting more transports
---
PS1. Thanks everyone who submitted great [logo proposals](https://explorer.bounties.network/bounty/3389) for Vac!
PPS2. Next week on October 10th decanus and I will be presenting Vac at [Devcon](https://devcon.org/agenda), come say hi :)

38
docs/2019-11-08-feasibility-semaphore-rate-limiting-zksnarks.mdx → research/2019-11-08-feasibility-semaphore-rate-limiting-zksnarks.mdx
View File

@@ -1,13 +1,12 @@
---
layout: post
name: "Feasibility Study: Semaphore rate limiting through zkSNARKs"
title: "Feasibility Study: Semaphore rate limiting through zkSNARKs"
date: 2019-11-08 12:00:00
author: oskarth
name: 'Feasibility Study: Semaphore rate limiting through zkSNARKs'
title: 'Feasibility Study: Semaphore rate limiting through zkSNARKs'
date: 2019-11-08 12:00:00
authors: oskarth
published: true
slug: feasibility-semaphore-rate-limiting-zksnarks
categories: research
summary: A research log. Zero knowledge signaling as a rate limiting mechanism to prevent spam in p2p networks.
image: /img/peacock-signaling.jpg
discuss: https://forum.vac.dev/t/discussion-feasibility-study-semaphore-rate-limiting-through-zksnarks/21
@@ -15,9 +14,9 @@ toc_min_heading_level: 2
toc_max_heading_level: 5
---
import { DocMetadata } from '@site/src/components/mdx'
A research log. Zero knowledge signaling as a rate limiting mechanism to prevent spam in p2p networks.
<DocMetadata />
<!--truncate-->
**tldr: Moon math promising for solving spam in Whisper, but to get there we need to invest more in performance work and technical upskilling.**
@@ -40,13 +39,13 @@ In addition to above, there are a lot of related problems that share similaritie
## Basic terminology
A *zero-knowledge proof* allows a *prover* to show a *verifier* that they know something, without revealing what that something is. This means you can do trust-minimized computation that is also privacy preserving. As a basic example, instead of showing your ID when going to a bar you simply give them a proof that you are over 18, without showing the doorman your id.
A _zero-knowledge proof_ allows a _prover_ to show a _verifier_ that they know something, without revealing what that something is. This means you can do trust-minimized computation that is also privacy preserving. As a basic example, instead of showing your ID when going to a bar you simply give them a proof that you are over 18, without showing the doorman your id.
*zkSNARKs* is a form of zero-knowledge proofs. There are many types of zero-knowledge proofs, and the field is evolving rapidly. They come with various trade-offs in terms of things such as: trusted setup, cryptographic assumptions, proof/verification key size, proof/verification time, proof size, etc. See section below for more.
_zkSNARKs_ is a form of zero-knowledge proofs. There are many types of zero-knowledge proofs, and the field is evolving rapidly. They come with various trade-offs in terms of things such as: trusted setup, cryptographic assumptions, proof/verification key size, proof/verification time, proof size, etc. See section below for more.
*Semaphore* is a framework/library/construct on top of zkSNARks. It allows for zero-knowledge signaling, specifically on top of Ethereum. This means an approved user can broadcast some arbitrary string without revealing their identity, given some specific constraints. An approved user is someone who has been added to a certain merkle tree. See [current Github home](https://github.com/kobigurk/semaphore) for more.
_Semaphore_ is a framework/library/construct on top of zkSNARks. It allows for zero-knowledge signaling, specifically on top of Ethereum. This means an approved user can broadcast some arbitrary string without revealing their identity, given some specific constraints. An approved user is someone who has been added to a certain merkle tree. See [current Github home](https://github.com/kobigurk/semaphore) for more.
*Circom* is a DSL for writing arithmetic circuits that can be used in zkSNARKs, similar to how you might write a NAND gate. See [Github](https://github.com/iden3/circom) for more.
_Circom_ is a DSL for writing arithmetic circuits that can be used in zkSNARKs, similar to how you might write a NAND gate. See [Github](https://github.com/iden3/circom) for more.
## Basic flow
@@ -54,28 +53,23 @@ We start with a private voting example, and then extend it to the slashable rate
1. A user registers an identity (arbitrary keypair), along with a small fee, to a smart contract. This adds them to a merkle tree and allows them to prove that they are member of that group, without revealing who they are.
2. When a user wants to send a message, they compute a zero-knowledge proof. This ensures certain invariants, have some *public outputs*, and can be verified by anyone (including a smart contract).
2. When a user wants to send a message, they compute a zero-knowledge proof. This ensures certain invariants, have some _public outputs_, and can be verified by anyone (including a smart contract).
3. Any node can verify the proof, including smart contracts on chain (as of Byzantinum HF). Additionally, a node can have rules for the public output. In the case of voting, one such rule is that a specific output hash has to be equal to some predefined value, such as "2020-01-01 vote on Foo Bar for president".
4. Because of how the proof is constructed, and the rules around output values, this ensures that: a user is part of the approved set of voters and that a user can only vote once.
5. As a consequence of above, we have a system where registered users can only vote once, no one can see who voted for what, and this can all be proven and verified.
### Rate limiting example
In the case of rate limiting, we do want nodes to send multiple messages. This changes step 3-5 above somewhat.
*NOTE: It is a bit more involved than this, and if we precompute proofs the flow might look a bit different. But the general idea is the same*.
_NOTE: It is a bit more involved than this, and if we precompute proofs the flow might look a bit different. But the general idea is the same_.
1. Instead of having a rule that you can only vote once, we have a rule that you can only send a message per epoch. Epoch here can be every second, as defined by UTC date time +-20s.
2. Additionally, if a users sends more than one message per epoch, one of the public outputs is a random share of a private key. Using Shamir's Secret Sharing (similar to a multisig) and 2/3 key share as an example threshold: in the normal case only 1/3 private keys is revealed, which is insufficient to have access. In the case where two messages are sent in an epoch, probabilistically 2/3 shares is sufficient to have access to the key (unless you get the same random share of the key).
3. This means any untrusted user who detects a spamming user, can use it to access their private key corresponding to funds in the contract, and thus slash them.
4. As a consequence of above, we have a system where registered users can only messages X times per epoch, and no one can see who is sending what messages. Additionally, if a user is violating the above rate limit, they can be punished and any user can profit from it.
### Briefly on scope of 'approved users'
In the case of an application like Status, this construct can either be a global StatusNetwork group, or one per chat, or network, etc. It can be applied both at the network and user level. There are no specific limitations on where or who deploys this, and it is thus more of a UX consideration.
@@ -126,7 +120,7 @@ See [details](https://github.com/vacp2p/research/issues/11).
#### Licensing issues
Currently Circom [uses a GPL license](https://github.com/iden3/circom/blob/master/COPYING ), which can get tricky when it comes to the App Store etc.
Currently Circom [uses a GPL license](https://github.com/iden3/circom/blob/master/COPYING), which can get tricky when it comes to the App Store etc.
See [details](https://github.com/vacp2p/research/issues/12).
@@ -156,4 +150,4 @@ For example, this might also include leveraging largely ready made solutions suc
Thanks to Barry Whitehat for patient explanation and pointers. Thanks to WJ for helping with runtime issues.
*Peacock header image from [Tonos](https://en.wikipedia.org/wiki/File:Flickr_-_lo.tangelini_-_Tonos_(1).jpg).*
_Peacock header image from [Tonos](<https://en.wikipedia.org/wiki/File:Flickr_-_lo.tangelini_-_Tonos_(1).jpg>).\_

17
docs/2019-12-03-fixing-whisper-with-waku.mdx → research/2019-12-03-fixing-whisper-with-waku.mdx
View File

@@ -1,20 +1,19 @@
---
layout: post
name: "Fixing Whisper with Waku"
title: "Fixing Whisper with Waku"
date: 2019-12-03 12:00:00
author: oskarth
name: 'Fixing Whisper with Waku'
title: 'Fixing Whisper with Waku'
date: 2019-12-03 12:00:00
authors: oskarth
published: true
slug: fixing-whisper-with-waku
categories: research
summary: A research log. Why Whisper doesn't scale and how to fix it.
image: /img/whisper_scalability.png
discuss: https://forum.vac.dev/t/discussion-fixing-whisper-with-waku/27
---
import { DocMetadata } from '@site/src/components/mdx'
A research log. Why Whisper doesn't scale and how to fix it.
<DocMetadata />
<!--truncate-->
This post will introduce Waku. Waku is a fork of Whisper that attempts to
addresses some of Whisper's shortcomings in an iterative fashion. We will also
@@ -45,7 +44,7 @@ In this post, we'll focus on the first problem, which is scalability through ban
## Whisper theoretical scalability model
*(Feel free to skip this section if you want to get right to the results).*
_(Feel free to skip this section if you want to get right to the results)._
There's widespread implicit knowledge that Whisper "doesn't scale", but it is less understood exactly why. This theoretical model attempts to encode some characteristics of it. Specifically for use case such as one by Status (see [Status Whisper usage
spec](https://specs.status.im/spec/3)).
@@ -293,6 +292,6 @@ iterative work with results on the order of weeks.
In short, we have a [Waku version 0 spec up](https://rfc.vac.dev/spec/5) as well as a [PoC](https://github.com/status-im/nim-eth/pull/120) for backwards compatibility. In the coming weeks, we are going to solidify the specs, get a more fully featured PoC for [Waku mode](https://github.com/status-im/nim-eth/pull/114). See [rough roadmap](https://github.com/vacp2p/pm/issues/5), project board [link deprecated] and progress thread on the [Vac forum](https://forum.vac.dev/t/waku-project-and-progress/24).
The spec has been rewrittten for clarity, with ABNF grammar and less ambiguous language. The spec also incorporates several previously [ad hoc implemented features](https://rfc.vac.dev/spec/6/#additional-capabilities), such as light nodes and mailserver/client support. This has already caught a few incompatibilities between the `geth` (Go), `status/whisper` (Go) and `nim-eth` (Nim) versions, specifically around light node usage and the handshake.
The spec has been rewrittten for clarity, with ABNF grammar and less ambiguous language. The spec also incorporates several previously [ad hoc implemented features](https://rfc.vac.dev/spec/6/#additional-capabilities), such as light nodes and mailserver/client support. This has already caught a few incompatibilities between the `geth` (Go), `status/whisper` (Go) and `nim-eth` (Nim) versions, specifically around light node usage and the handshake.
If you are interested in this effort, please check out [our forum](https://forum.vac.dev/) for questions, comments and proposals. We already have some discussion for better [spam protection](https://forum.vac.dev/t/stake-priority-based-queuing/26) (see [previous post](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks) for a more complex but privacy-preserving proposal), something that is likely going to be addressed in future versions of Waku, along with many other fixes and enhancement.

57
docs/2020-02-14-waku-update.mdx → research/2020-02-14-waku-update.mdx
View File

@@ -1,22 +1,21 @@
---
layout: post
name: "Waku Update"
title: "Waku Update"
date: 2020-02-14 12:00:00
author: oskarth
name: 'Waku Update'
title: 'Waku Update'
date: 2020-02-14 12:00:00
authors: oskarth
published: true
slug: waku-update
categories: research
summary: A research log. What's the current state of Waku? How many users does it support? What are the bottlenecks? What's next?
image: /img/waku_infrastructure_sky.jpg
discuss: https://forum.vac.dev/t/waku-update-where-are-we-at/34
---
import { DocMetadata } from '@site/src/components/mdx'
A research log. What's the current state of Waku? How many users does it support? What are the bottlenecks? What's next?
<DocMetadata />
<!--truncate-->
Waku is our fork of Whisper where we address the shortcomings of Whisper in an iterative manner. We've seen a in [previous post](https://vac.dev/fixing-whisper-with-waku) that Whisper doesn't scale, and why. In this post we'll talk about what the current state of Waku is, how many users it can support, and future plans.
Waku is our fork of Whisper where we address the shortcomings of Whisper in an iterative manner. We've seen a in [previous post](https://vac.dev/fixing-whisper-with-waku) that Whisper doesn't scale, and why. In this post we'll talk about what the current state of Waku is, how many users it can support, and future plans.
## Current state
@@ -55,12 +54,13 @@ We have a [simulation](https://github.com/status-im/nim-waku/blob/master/waku/v1
This is our current understanding of how many users a network running Waku can support. Specifically in the context of the Status chat app, since that's the most immediate consumer of Waku. It should generalize fairly well to most deployments.
**tl;dr (for Status app):**
- beta: 100 DAU
- v1: 1k DAU
- v1.1 (waku only): 10k DAU (up to x10 with deployment hotfixes)
- v1.2 (waku+dns): 100k DAU (can optionally be folded into v1.1)
*Assuming 10 concurrent users = 100 DAU. Estimate uncertainty increases for each order of magnitude until real-world data is observed.*
_Assuming 10 concurrent users = 100 DAU. Estimate uncertainty increases for each order of magnitude until real-world data is observed._
As far as we know right now, these are the bottlenecks we have:
@@ -87,30 +87,31 @@ For light node, bloom filter is set to almost 10% false positive (bloom filter:
**Star network:**
| Description | Peers | Valid | Invalid |
|-----------------|-------|-------|---------|
| Master node | 7 | 10001 | 0 |
| Full node 1 | 3 | 10001 | 0 |
| Full node 2 | 1 | 10001 | 0 |
| Full node 3 | 1 | 10001 | 0 |
| Full node 4 | 1 | 10001 | 0 |
| Full node 5 | 1 | 10001 | 0 |
| Light node | 2 | 815 | 0 |
| Waku light node | 2 | 1 | 0 |
| --------------- | ----- | ----- | ------- |
| Master node | 7 | 10001 | 0 |
| Full node 1 | 3 | 10001 | 0 |
| Full node 2 | 1 | 10001 | 0 |
| Full node 3 | 1 | 10001 | 0 |
| Full node 4 | 1 | 10001 | 0 |
| Full node 5 | 1 | 10001 | 0 |
| Light node | 2 | 815 | 0 |
| Waku light node | 2 | 1 | 0 |
**Full mesh:**
| Description | Peers | Valid | Invalid |
|-----------------|-------|-------|---------|
| Full node 0 | 7 | 10001 | 20676 |
| Full node 1 | 7 | 10001 | 9554 |
| Full node 2 | 5 | 10001 | 23304 |
| Full node 3 | 5 | 10001 | 11983 |
| Full node 4 | 5 | 10001 | 24425 |
| Full node 5 | 5 | 10001 | 23472 |
| Light node | 2 | 803 | 803 |
| Waku light node | 2 | 1 | 1 |
| --------------- | ----- | ----- | ------- |
| Full node 0 | 7 | 10001 | 20676 |
| Full node 1 | 7 | 10001 | 9554 |
| Full node 2 | 5 | 10001 | 23304 |
| Full node 3 | 5 | 10001 | 11983 |
| Full node 4 | 5 | 10001 | 24425 |
| Full node 5 | 5 | 10001 | 23472 |
| Light node | 2 | 803 | 803 |
| Waku light node | 2 | 1 | 1 |
Things to note:
- Whisper light node with ~10% false positive gets ~10% of total traffic
- Waku light node gets ~1000x less envelopes than Whisper light node
- Full mesh results in a lot more duplicate messages, expect for Waku light node
@@ -145,4 +146,4 @@ For the third bottleneck, a likely candidate for fixing this is Kademlia routing
## Acknowledgements
*Image from "caged sky" by mh.xbhd.org is licensed under CC BY 2.0 (https://ccsearch.creativecommons.org/photos/a9168311-78de-4cb7-a6ad-f92be8361d0e)*
_Image from "caged sky" by mh.xbhd.org is licensed under CC BY 2.0 (https://ccsearch.creativecommons.org/photos/a9168311-78de-4cb7-a6ad-f92be8361d0e)_

28
docs/2020-02-7-dns-based-discovery.mdx → research/2020-02-7-dns-based-discovery.mdx
View File

@@ -1,18 +1,17 @@
---
layout: post
name: "DNS Based Discovery"
title: "DNS Based Discovery"
date: 2020-02-7 12:00:00
author: dean
name: 'DNS Based Discovery'
title: 'DNS Based Discovery'
date: 2020-02-7 12:00:00
authors: dean
published: true
slug: dns-based-discovery
categories: research
summary: A look at EIP-1459 and the benefits of DNS based discovery.
---
import { DocMetadata } from '@site/src/components/mdx'
A look at EIP-1459 and the benefits of DNS based discovery.
<DocMetadata />
<!--truncate-->
Discovery in p2p networks is the process of how nodes find each other and specific resources they are looking for. Popular discovery protocols, such as [Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) which utilizes a [distributed hash table](https://en.wikipedia.org/wiki/Distributed_hash_table) or DHT, are highly inefficient for resource restricted devices. These methods use short connection windows, and it is quite battery intensive to keep establishing connections. Additionally, we cannot expect a mobile phone for example to synchronize an entire DHT using cellular data.
@@ -20,11 +19,11 @@ Another issue is how we do the initial bootstrapping. In other words, how does a
In summary, we have a static list that provides us with nodes we can connect to which then allows us to discover the rest of the network using something like Kademlia. But what we need is something that can easily be mutated, guarantees a certain amount of security, and is efficient for resource restricted devices. Ideally our solution would also be robust and scalable.
How do we do this?
How do we do this?
[EIP 1459: Node Discovery via DNS](https://eips.ethereum.org/EIPS/eip-1459), which is one of the strategies we are using for discovering waku nodes. [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459) is a DNS-based discovery protocol that stores [merkle trees](https://en.wikipedia.org/wiki/Merkle_tree) in DNS records which contain connection information for nodes.
*Waku is our fork of Whisper. Oskar recently wrote an [entire post](https://vac.dev/fixing-whisper-with-waku) explaining it. In short, Waku is our method of fixing the shortcomings of Whisper in a more iterative fashion. You can find the specification [here](https://rfc.vac.dev/spec/6/)*
_Waku is our fork of Whisper. Oskar recently wrote an [entire post](https://vac.dev/fixing-whisper-with-waku) explaining it. In short, Waku is our method of fixing the shortcomings of Whisper in a more iterative fashion. You can find the specification [here](https://rfc.vac.dev/spec/6/)_
DNS-based methods for bootstrapping p2p networks are quite popular. Even Bitcoin uses it, but it uses a concept called DNS seeds, which are just DNS servers that are configured to return a list of randomly selected nodes from the network upon being queried. This means that although these seeds are hardcoded in the client, the IP addresses of actual nodes do not have to be.
@@ -68,12 +67,13 @@ There are multiple reasons, but the main one is **security**. In the Bitcoin exa
Let's dive into this. Firstly, a client that is using these DNS records for discovery must know the public key corresponding to the private key controlled by the entity creating the list. This is because the entire list is signed using a secp256k1 private key, giving the client the ability to authenticate the list and know that it has not been tampered with by some external party.
So that already makes this a lot safer than the method Bitcoin uses. But how are these lists even stored? As previously stated they are stored using **merkle trees** as follows:
- The root of the tree is stored in a [`TXT` record](https://simpledns.plus/help/txt-records), this record contains the tree's root hash, a sequence number which is incremented every time the tree is updated and a signature as stated above.
Additionally, there is also a root hash to a second tree called a **link tree**, it contains the information to different lists. This link tree allows us to delegate trust and build a graph of multiple merkle trees stored across multiple DNS names.
The sequence number ensures that an attacker cannot replace a tree with an older version because when a client reads the tree, they should ensure that the sequence number is greater than the last synchronized version.
- The root of the tree is stored in a [`TXT` record](https://simpledns.plus/help/txt-records), this record contains the tree's root hash, a sequence number which is incremented every time the tree is updated and a signature as stated above.
Additionally, there is also a root hash to a second tree called a **link tree**, it contains the information to different lists. This link tree allows us to delegate trust and build a graph of multiple merkle trees stored across multiple DNS names.
The sequence number ensures that an attacker cannot replace a tree with an older version because when a client reads the tree, they should ensure that the sequence number is greater than the last synchronized version.
- Using the root hash for the tree, we can find the merkle tree's first branch, the branch is also stored in a `TXT` record. The branch record contains all the hashes of the branch's leafs.
- Once a client starts reading all the leafs, they can find one of two things: either a new branch record leading them further down the tree or an Ethereum Name Records (ENR) which means they now have the address of a node to connect to! To learn more about ethereum node records you can have a look at [EIP-778](https://eips.ethereum.org/EIPS/eip-778), or read a short blog post I wrote explaining them [here](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/#enr).

33
docs/2020-04-16-wechat-replacement-need.mdx → research/2020-04-16-wechat-replacement-need.mdx
View File

@@ -1,20 +1,19 @@
---
layout: post
name: "What Would a WeChat Replacement Need?"
title: "What Would a WeChat Replacement Need?"
date: 2020-04-16 12:00:00
author: oskarth
name: 'What Would a WeChat Replacement Need?'
title: 'What Would a WeChat Replacement Need?'
date: 2020-04-16 12:00:00
authors: oskarth
published: true
slug: wechat-replacement-need
categories: research
summary: What would a self-sovereign, private, censorship-resistant and open alternative to WeChat look like?
image: /img/tianstatue.jpg
discuss: https://forum.vac.dev/t/discussion-what-would-a-wechat-replacement-need/42
---
import { DocMetadata } from '@site/src/components/mdx'
What would a self-sovereign, private, censorship-resistant and open alternative to WeChat look like?
<DocMetadata />
<!--truncate-->
What would it take to replace WeChat? More specifically, what would a self-sovereign, private, censorship-resistant and open alternative look like? One that allows people to communicate, coordinate and transact freely.
@@ -88,11 +87,12 @@ We want something that is self-sovereign, private, censorship-resistant and open
**Open source**. Related to above, where we must be able to inspect the software to know that it functions as advertised and hasn't been compromised, e.g. by uploading private data to a third party.
Some of these are graded and a bit subtle, i.e.:
- Censorship resistance would ideally be able to absorb Internet shutdowns. This would require an extensive MANET/meshnet infrastructure, which while desirable, requires a lot of challenges to be overcome to be feasible.
- Privacy would ideally make all actions (optionally) totally anoymous, though this may incur undue costs on bandwidth and latency, which impacts user experience.
- Decentralization, certain topologies, such as DHTs, are efficient and quite decentralized but still have some centralized aspects, which makes it attackable in various ways. Ditto for blockchains compared with bearer instruments which requires some coordinating infrastructure, compared with naturally occuring assets such as precious metals.
- "Discover people" and striving for "total anonymity" might initially seem incompatible. The idea is to provide for sane defaults, and then allow people to decide how much information they want to disclose. This is the essence of privacy.
- Users often want *some* form of moderation to get a good user experience, which can be seen as a form of censorship. The idea to raise the bar on the basics, the fundamental infrastructure. If individuals or specific communities want certain moderation mechanisms, that is still a compatible requirement.
- Users often want _some_ form of moderation to get a good user experience, which can be seen as a form of censorship. The idea to raise the bar on the basics, the fundamental infrastructure. If individuals or specific communities want certain moderation mechanisms, that is still a compatible requirement.
### Counterpoint 1
@@ -119,9 +119,10 @@ Starting from the most basic: what is an account and how do you get one? With mo
Now, we could argue these app providers can do what they want. And they are right, in a very narrow sense. As apps like WeChat (and Google) become general-purpose platforms, they become more and more ingrained in our everyday lives. They start to provide utilities that we absolutely require to work to go about our day, such as paying for food or transportation. This means we need higher standard than this.
Justifications for requiring phone numbers are usually centered around three claims:
1) Avoiding spam
2) Tying your account to your real name, for various reasons
3) Using as a commonly shared identifier as a social network discovery mechanism
1. Avoiding spam
2. Tying your account to your real name, for various reasons
3. Using as a commonly shared identifier as a social network discovery mechanism
Of course, many services require more than phone numbers. E.g. email, other forms of personal data such as voice recording, linking a bank account, and so on.
@@ -250,19 +251,11 @@ Corey, Dean, Jacek.
## References
[^1]: Mandatory SIM card registration laws: https://privacyinternational.org/long-read/3018/timeline-sim-card-registration-laws
[^2]: On WeChat keyword censorship: https://citizenlab.ca/2016/11/wechat-china-censorship-one-app-two-systems/
[^3]: Net Neutrality: https://www.eff.org/issues/net-neutrality
[^4]: ISP centralization: https://ilsr.org/repealing-net-neutrality-puts-177-million-americans-at-risk/
[^5]: Incentives Build Robustness in BitTorrent bittorrent.org/bittorrentecon.pdf
[^6]: The Case for Electronic Cash: https://coincenter.org/files/2019-02/the-case-for-electronic-cash-coin-center.pdf
[^6]: The Case for Electronic Cash: https://coincenter.org/files/2019-02/the-case-for-electronic-cash-coin-center.pdf
[^7]: Money, blockchains, and social scalability: http://unenumerated.blogspot.com/2017/02/money-blockchains-and-social-scalability.html
[^8]: Zcash private transactions (partial paywall): https://www.theblockcrypto.com/genesis/48413/an-analysis-of-zcashs-private-transactions
[^9]: Shielded transactions usage (stats page 404s): https://z.cash/support/faq/

39
docs/2020-04-27-feasibility-discv5.mdx → research/2020-04-27-feasibility-discv5.mdx
View File

@@ -1,19 +1,18 @@
---
layout: post
name: "Feasibility Study: Discv5"
title: "Feasibility Study: Discv5"
date: 2020-04-27 12:00:00
author: dean
name: 'Feasibility Study: Discv5'
title: 'Feasibility Study: Discv5'
date: 2020-04-27 12:00:00
authors: dean
published: true
slug: feasibility-discv5
categories: research
summary: Looking at discv5 and the theoretical numbers behind finding peers.
discuss: https://discuss.status.im/t/discv5-feasibility-study/1632
---
import { DocMetadata } from '@site/src/components/mdx'
Looking at discv5 and the theoretical numbers behind finding peers.
<DocMetadata />
<!--truncate-->
> Disclaimer: some of the numbers found in this write-up could be inaccurate. They are based on the current understanding of theoretical parts of the protocol itself by the author and are meant to provide a rough overview rather than bindable numbers.
@@ -27,13 +26,13 @@ Namely, we want to ensure censorship resistance to state-level adversaries. One
Considering we are talking about resource restricted devices, let's look at the implications and what we need to consider:
- **Battery consumption** - constant connections like websockets consume a lot of battery life.
- **CPU usage** - certain discovery methods may be CPU incentive, slowing an app down and making it unusable.
- **Bandwidth consumption** - a lot of users will be using data plans, the discovery method needs to be efficient in order to accommodate those users without using up significant portions of their data plans.
- **Short connection windows** - the discovery algorithm needs to be low latency, that means it needs to return results fast. This is because many users will only have the app open for a short amount of time.
- **Not publicly connectable** - There is a good chance that most resource restricted devices are not publicly connectable.
- **Battery consumption** - constant connections like websockets consume a lot of battery life.
- **CPU usage** - certain discovery methods may be CPU incentive, slowing an app down and making it unusable.
- **Bandwidth consumption** - a lot of users will be using data plans, the discovery method needs to be efficient in order to accommodate those users without using up significant portions of their data plans.
- **Short connection windows** - the discovery algorithm needs to be low latency, that means it needs to return results fast. This is because many users will only have the app open for a short amount of time.
- **Not publicly connectable** - There is a good chance that most resource restricted devices are not publicly connectable.
For a node to be able to participate as both a provider, and a consumer in the discovery method. Meaning a node both reads from other nodes' stored DHTs and hosts the DHT for other nodes to read from, it needs to be publically connectable. This means another node must be able to connect to some public IP of the given node.
For a node to be able to participate as both a provider, and a consumer in the discovery method. Meaning a node both reads from other nodes' stored DHTs and hosts the DHT for other nodes to read from, it needs to be publically connectable. This means another node must be able to connect to some public IP of the given node.
With devices that are behind a NAT, this is easier said than done. Especially mobile devices, that when connected to 4G LTE networks are often stuck behind a symmetric NAT, drastically reducing the the succeess rate of NAT traversal. Keeping this in mind, it becomes obvious that most resource restricted devices will be consumers rather than providers due to this technical limitation.
@@ -42,8 +41,9 @@ In order to answer our questions, we formulated the problem with a simple method
## Overview
The main things we wanted to investigate was the overhead on finding a peer. This means we wanted to look at both the bandwidth, latency and effectiveness of this. There are 2 methods which we can use to find a peer:
- We can find a peer with a specific ID, using normal lookup methods as documented by Kademlia.
- We can find a peer that advertises a capability, this is possible using either capabilities advertised in the ENR or through [topic tables](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement).
- We can find a peer with a specific ID, using normal lookup methods as documented by Kademlia.
- We can find a peer that advertises a capability, this is possible using either capabilities advertised in the ENR or through [topic tables](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement).
## Feasbility
@@ -80,7 +80,8 @@ Research has shown that finding a node in the DHT has a relatively low effect on
One of the main blockers right now is figuring out what the CPU and memory usage of discv5 is on mobile phones, this is a large blocker as it affects one of the core problems for us. We need to consider whether discv5 is an upgrade as it allows us to simplify our current discovery process or if it is too much of an overhead for resource restricted devices. The topic table feature could largely enhance discovery however it is not yet implemented. Given that CPU and memory isn't too high, discv5 could probably be used as the other issues are more "features" than large scale issues. Implementing it would already reduce the ability for state level adversaries to censor our nodes.
## Acknowledgements
- Oskar Thoren
- Dmitry Shmatko
- Kim De Mey
- Corey Petty
- Oskar Thoren
- Dmitry Shmatko
- Kim De Mey
- Corey Petty

28
docs/2020-04-9-kademlia-to-discv5.mdx → research/2020-04-9-kademlia-to-discv5.mdx
View File

@@ -1,18 +1,17 @@
---
layout: post
name: "From Kademlia to Discv5"
title: "From Kademlia to Discv5"
date: 2020-04-9 16:00:00
author: dean
name: 'From Kademlia to Discv5'
title: 'From Kademlia to Discv5'
date: 2020-04-9 16:00:00
authors: dean
published: true
slug: kademlia-to-discv5
categories: research
summary: A quick history of discovery in peer-to-peer networks, along with a look into discv4 and discv5, detailing what they are, how they work and where they differ.
---
import { DocMetadata } from '@site/src/components/mdx'
A quick history of discovery in peer-to-peer networks, along with a look into discv4 and discv5, detailing what they are, how they work and where they differ.
<DocMetadata />
<!--truncate-->
If you've been working on Ethereum or adjacent technologies you've probably heard of [discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) or [discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md). But what are they actually? How do they work and what makes them different? To answer these questions, we need to start at the beginning, so this post will assume that there is little knowledge on the subject so the post should be accessible for anyone.
@@ -52,9 +51,10 @@ XOR 10011001
The top in decimal numbers means that the distance between `153` and `50` is `171`.
There are several reasons why `XOR` was taken:
1. The distance from one ID to itself will be `0`.
2. Distance is symmetric, A to B is the same as B to A.
3. Follows triangle inequality, if `A`, `B` and `C` are points on a triangle then the distance `A` to `B` is closer or equal to that of `A` to `C` plus the one from `B` to `C`.
1. The distance from one ID to itself will be `0`.
2. Distance is symmetric, A to B is the same as B to A.
3. Follows triangle inequality, if `A`, `B` and `C` are points on a triangle then the distance `A` to `B` is closer or equal to that of `A` to `C` plus the one from `B` to `C`.
In summary, this distance function allows a node to decide what is "close" to it and make decisions based on that "closeness".
@@ -71,11 +71,11 @@ For Kademlia nodes to support these functions, there are several messages with w
- `FINDNODE` - Returns the closest nodes requested to a given ID.
- `FINDVALUE` - The same as `FINDNODE`, except if a node stores the specific value it will return it directly.
*This is a **very** simplified explanation of Kademlia and skips various important details. For the full description, make sure to check out the [paper](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) or a more in-depth [design specification](http://xlattice.sourceforge.net/components/protocol/kademlia/specs.html)*
_This is a **very** simplified explanation of Kademlia and skips various important details. For the full description, make sure to check out the [paper](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) or a more in-depth [design specification](http://xlattice.sourceforge.net/components/protocol/kademlia/specs.html)_
## Discv4
Now after that history lesson, we finally get to discv4 (which stands for discovery v4), Ethereum's current node discovery protocol. The protocol itself is essentially based off of Kademlia, however it does away with certain aspects of it. For example, it does away with any usage of the value part of the DHT.
Now after that history lesson, we finally get to discv4 (which stands for discovery v4), Ethereum's current node discovery protocol. The protocol itself is essentially based off of Kademlia, however it does away with certain aspects of it. For example, it does away with any usage of the value part of the DHT.
Kademlia is mainly used for the organisation of the network, so we only use the routing table to locate other nodes. Due to the fact that discv4 doesn't use the value portion of the DHT at all, we can throw away the `FINDVALUE` and `STORE` commands described by Kademlia.
@@ -85,7 +85,7 @@ Additionally, discv4 adds mutual endpoint verification. This is meant to ensure
Finally, all discv4 nodes are expected to maintain up-to-date ENR records. These contain information about a node. They can be requested from any node using a discv4-specific packet called `ENRRequest`.
*If you want some more details on ENRs, check out one of my posts ["Network Addresses in Ethereum"](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/)*
_If you want some more details on ENRs, check out one of my posts ["Network Addresses in Ethereum"](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/)_
Discv4 comes with its own range of problems however. Let's look at a few of them.
@@ -107,7 +107,7 @@ Logarithmic distance means we first calculate the distance and then run it throu
log2(A xor B)
```
And the second, more important change, is that discv5 aims at solving one of the biggest issues of discv4: the differentiation of sub-protocols. It does this by adding topic tables. Topic tables are [first in first out](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) lists that contain nodes which have advertised that they provide a specific service. Nodes get themselves added to this list by registering `ads` on their peers.
And the second, more important change, is that discv5 aims at solving one of the biggest issues of discv4: the differentiation of sub-protocols. It does this by adding topic tables. Topic tables are [first in first out](<https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)>) lists that contain nodes which have advertised that they provide a specific service. Nodes get themselves added to this list by registering `ads` on their peers.
As of writing, there is still an issue with this proposal. There is currently no efficient way for a node to place `ads` on multiple peers, since it would require separate requests for every peer which is inefficient in a large-scale network.

51
docs/2020-07-01-waku-v2-pitch.mdx → research/2020-07-01-waku-v2-pitch.mdx
View File

@@ -1,24 +1,23 @@
---
layout: post
name: "What's the Plan for Waku v2?"
title: "What's the Plan for Waku v2?"
date: 2020-07-01 12:00:00
author: oskarth
name: "What's the Plan for Waku v2?"
title: "What's the Plan for Waku v2?"
date: 2020-07-01 12:00:00
authors: oskarth
published: true
slug: waku-v2-plan
categories: research
summary: Read about our plans for Waku v2, moving to libp2p, better routing, adaptive nodes and accounting!
image: /img/status_scaling_model_fig4.png
discuss: https://forum.vac.dev/t/waku-version-2-pitch/52
---
import { DocMetadata } from '@site/src/components/mdx'
Read about our plans for Waku v2, moving to libp2p, better routing, adaptive nodes and accounting!
<DocMetadata />
<!--truncate-->
**tldr: The Waku network is fragile and doesn't scale. Here's how to solve it.**
*NOTE: This post was originally written with Status as a primary use case in mind, which reflects how we talk about some problems here. However, Waku v2 is a general-purpose private p2p messaging protocol, especially for people running in resource restricted environments.*
_NOTE: This post was originally written with Status as a primary use case in mind, which reflects how we talk about some problems here. However, Waku v2 is a general-purpose private p2p messaging protocol, especially for people running in resource restricted environments._
## Problem
@@ -30,12 +29,12 @@ Based on user acquisition models, the initial goal is to support 100k DAU in Sep
With the Status Scaling Model we have studied the current bottlenecks as a function of concurrent users (CCU) and daily active users (DAU). Here are the conclusions.
****1. Connection limits****. With 100 full nodes we reach ~10k CCU based on connection limits. This can primarily be addressed by increasing the number of nodes (cluster or user operated). This assumes node discovery works. It is also worth investigating the limitations of max number of connections, though this is likely to be less relevant for user-operated nodes. For a user-operated network, this means 1% of users have to run a full node. See Fig 1-2.
\***\*1. Connection limits\*\***. With 100 full nodes we reach ~10k CCU based on connection limits. This can primarily be addressed by increasing the number of nodes (cluster or user operated). This assumes node discovery works. It is also worth investigating the limitations of max number of connections, though this is likely to be less relevant for user-operated nodes. For a user-operated network, this means 1% of users have to run a full node. See Fig 1-2.
****2. Bandwidth as a bottleneck****. We notice that memory usage appears to not be
\***\*2. Bandwidth as a bottleneck\*\***. We notice that memory usage appears to not be
the primary bottleneck for full nodes, and the bottleneck is still bandwidth. To support 10k DAU, and full nodes with an amplification factor of 25 the required Internet speed is ~50 Mbps, which is a fast home Internet connection. For ~100k DAU only cloud-operated nodes can keep up (500 Mbps). See Fig 3-5.
****3. Amplification factors****. Reducing amplification factors with better routing, would have a high impact, but it is likely we'd need additional measures as well, such as topic sharding or similar. See Fig 8-13.
\***\*3. Amplification factors\*\***. Reducing amplification factors with better routing, would have a high impact, but it is likely we'd need additional measures as well, such as topic sharding or similar. See Fig 8-13.
Figure 1-5:
@@ -54,12 +53,12 @@ What we need to do is:
Doing this means the Waku network will be able to scale, and doing so in the right way, in a robust fashion. What would a fragile way of scaling be? Increasing our reliance on a Status Pte Ltd operated cluster which would paint us in a corner where we:
- keep increasing requirements for Internet speed for full nodes
- are vulnerable to censorship and attacks
- have to control the topology in an artifical manner to keep up with load
- basically re-invent a traditional centralized client-server app with extra steps
- deliberately ignore most of our principles
- risk the network being shut down when we run out of cash
- keep increasing requirements for Internet speed for full nodes
- are vulnerable to censorship and attacks
- have to control the topology in an artifical manner to keep up with load
- basically re-invent a traditional centralized client-server app with extra steps
- deliberately ignore most of our principles
- risk the network being shut down when we run out of cash
## Appetite
@@ -83,7 +82,6 @@ Let's first look at the baseline, and then go into some of the tracks and their
Here's where we are at now. In reality, the amplification factor are likely even worse than this (15 in the graph below), up to 20-30. Especially with an open network, where we can't easily control connectivity and availability of nodes. Left unchecked, with a full mesh, it could even go as high x100, though this is likely excessive and can be dialed down. See scaling model for more details.
![](/img/waku_v1_routing_small.png)
## Track 1 - Move to libp2p
@@ -104,7 +102,6 @@ Why can't we use Waku topics for routing directly? PubSub over libp2p isn't buil
![](/img/waku_v2_routing_flood_small.png)
Moving to FloodSub over libp2p would also be an opportunity to clean up and simplify some components that are no longer needed in the Waku v1 protocol, see point below.
Very experimental and incomplete libp2p support can be found in the nim-waku repo under v2: <https://github.com/status-im/nim-waku>
@@ -205,9 +202,9 @@ The general shape of the solution is inspired by the Swarm model, where we do ac
While accounting for individual resource usage is useful, for the ultimate end user experience we can ideally account for other things such as:
- end to end delivery
- online time
- completeness of storage
- end to end delivery
- online time
- completeness of storage
This can be gradually enhanced and strengthened, for example with proofs, consistency checks, Quality of Service, reputation systems. See <https://discuss.status.im/t/network-incentivisation-first-draft/1037> for one attempt to provide stronger guarantees with periodic consistency checks and a shared fund mechanism. And <https://forum.vac.dev/t/incentivized-messaging-using-validity-proofs/51> for using validity proofs and removing liveness requirement for settlement.
@@ -231,14 +228,14 @@ In accounting phase it is largely assumed nodes are honest. What happens when th
For light nodes:
- if they don't, they get disconnected
- prepayment (especially to "high value" nodes)
- if they don't, they get disconnected
- prepayment (especially to "high value" nodes)
For full nodes:
- multiple nodes reporting to agree, where truth becomes a shelling point
- use eigentrust
- staking for discovery visibility with slashing
- multiple nodes reporting to agree, where truth becomes a shelling point
- use eigentrust
- staking for discovery visibility with slashing
### 5. Settlement PoC

37
docs/2020-09-28-waku-v2-update.mdx → research/2020-09-28-waku-v2-update.mdx
View File

@@ -1,20 +1,19 @@
---
layout: post
name: "Waku v2 Update"
title: "Waku v2 Update"
date: 2020-09-28 12:00:00
author: oskarth
name: 'Waku v2 Update'
title: 'Waku v2 Update'
date: 2020-09-28 12:00:00
authors: oskarth
published: true
slug: waku-v2-update
categories: research
summary: A research log. Read on to find out what is going on with Waku v2, a messaging protocol. What has been happening? What is coming up next?
image: /img/vac.png
discuss: https://forum.vac.dev/t/discussion-waku-v2-update/56
---
import { DocMetadata } from '@site/src/components/mdx'
A research log. Read on to find out what is going on with Waku v2, a messaging protocol. What has been happening? What is coming up next?
<DocMetadata />
<!--truncate-->
It has been a while since the last post. It is time for an update on Waku v2. Aside from getting more familiar with libp2p (specifically nim-libp2p) and some vacation, what have we been up to? In this post we'll talk about what we've gotten done since last time, and briefly talk about immediate next steps and future. But first, a recap.
@@ -76,16 +75,16 @@ Now that we know what the current state is, what is still missing? what are the
While we are getting closer to closing out work for track 1, there are still a few things missing from the initial scope:
1) Store and filter protocols need to be finished. This means basic spec, implementation, API integration and proven to work in a testnet. All of these are work in progress and expected to be done very soon. Once the store protocol is done in a basic form, it needs further improvements to make it production ready, at least on a spec/basic implementation level.
1. Store and filter protocols need to be finished. This means basic spec, implementation, API integration and proven to work in a testnet. All of these are work in progress and expected to be done very soon. Once the store protocol is done in a basic form, it needs further improvements to make it production ready, at least on a spec/basic implementation level.
2) Core integration was mentioned in scope for track 1 initially. This work has stalled a bit, largely due to organizational bandwidth and priorities. While there is a Nim Node API that in theory is ready to be used, having it be used in e.g. Status desktop or mobile app is a different matter. The team responsible for this at Status ([status-nim](https://github.com/status-im/status-nim) has been making progress on getting nim-waku v1 integrated, and is expected to look into nim-waku v2 integration soon. One thing that makes this a especially tricky is the difference in interface between Waku v1 and v2, which brings
us too...
2. Core integration was mentioned in scope for track 1 initially. This work has stalled a bit, largely due to organizational bandwidth and priorities. While there is a Nim Node API that in theory is ready to be used, having it be used in e.g. Status desktop or mobile app is a different matter. The team responsible for this at Status ([status-nim](https://github.com/status-im/status-nim) has been making progress on getting nim-waku v1 integrated, and is expected to look into nim-waku v2 integration soon. One thing that makes this a especially tricky is the difference in interface between Waku v1 and v2, which brings
us too...
3) Companion spec for encryption. As part of simplifying the protocol, the routing is decoupled from the encryption in v2 ([1](https://github.com/vacp2p/specs/issues/158), [2](https://github.com/vacp2p/specs/issues/181)). There are multiple layers of encryption at play here, and we need to figure out a design that makes sense for various use cases (dapps using Waku on their own, Status app, etc).
3. Companion spec for encryption. As part of simplifying the protocol, the routing is decoupled from the encryption in v2 ([1](https://github.com/vacp2p/specs/issues/158), [2](https://github.com/vacp2p/specs/issues/181)). There are multiple layers of encryption at play here, and we need to figure out a design that makes sense for various use cases (dapps using Waku on their own, Status app, etc).
4) Bridge implementation. The spec is done and we know how it should work, but it needs to be implemented.
4. Bridge implementation. The spec is done and we know how it should work, but it needs to be implemented.
5) General tightening up of specs and implementation.
5. General tightening up of specs and implementation.
While this might seem like a lot, a lot has been done already, and the majority of the remaining tasks are more amendable to be pursued in parallel with other efforts. It is also worth mentioning that part of track 2 and 3 have been started, in the form of moving to GossipSub (amplification factors) and basics of adaptive nodes (multiple protocols). This is in addition to things like Waku Web which were not part of the initial scope.
@@ -93,16 +92,16 @@ While this might seem like a lot, a lot has been done already, and the majority
Aside from the things mentioned above, what is coming up next? There are a few areas of interest, mentioned in no particular order. For track 2 and 3, see previous post for more details.
1) Better routing (track 2). While we are already building on top of GossipSub, we still need to explore things like topic sharding in more detail to further reduce amplification factors.
1. Better routing (track 2). While we are already building on top of GossipSub, we still need to explore things like topic sharding in more detail to further reduce amplification factors.
2) Accounting and user-run nodes (track 3). With store and filter protocol getting ready, we can start to implement accounting and light connection game for incentivization in a bottom up and iterative manner.
2. Accounting and user-run nodes (track 3). With store and filter protocol getting ready, we can start to implement accounting and light connection game for incentivization in a bottom up and iterative manner.
3) Privacy research. Study better and more rigorous privacy guarantees. E.g. how FloodSub/GossipSub behaves for common threat models, and how custom packet
format can improve things like unlinkability.
3. Privacy research. Study better and more rigorous privacy guarantees. E.g. how FloodSub/GossipSub behaves for common threat models, and how custom packet
format can improve things like unlinkability.
4) zkSnarks RLN for spam protection and incentivization. We studied this [last year](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks) and recent developments have made this relevant to study again. Create an [experimental spec/PoC](https://github.com/vacp2p/specs/issues/189) as an extension to the relay protocol. Kudos to Barry Whitehat and others like Kobi Gurkan and Koh Wei Jie for pushing this!
4. zkSnarks RLN for spam protection and incentivization. We studied this [last year](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks) and recent developments have made this relevant to study again. Create an [experimental spec/PoC](https://github.com/vacp2p/specs/issues/189) as an extension to the relay protocol. Kudos to Barry Whitehat and others like Kobi Gurkan and Koh Wei Jie for pushing this!
5) Ethereum M2M messaging. Being able to run in the browser opens up a lot of doors, and there is an opportunity here to enable things like a decentralized WalletConnect, multi-sig transactions, voting and similar use cases. This was the original goal of Whisper, and we'd like to deliver on that.
5. Ethereum M2M messaging. Being able to run in the browser opens up a lot of doors, and there is an opportunity here to enable things like a decentralized WalletConnect, multi-sig transactions, voting and similar use cases. This was the original goal of Whisper, and we'd like to deliver on that.
As you can tell, quite a lot of thing! Luckily, we have two people joining as protocol engineers soon, which will bring much needed support for the current team of ~2-2.5 people. More details to come in further updates.

63
docs/2020-11-10-waku-v2-ethereum-messaging.mdx → research/2020-11-10-waku-v2-ethereum-messaging.mdx
View File

@@ -1,22 +1,21 @@
---
layout: post
name: "[Talk] Vac, Waku v2 and Ethereum Messaging"
title: "[Talk] Vac, Waku v2 and Ethereum Messaging"
date: 2020-11-10 12:00:00
author: oskarth
name: '[Talk] Vac, Waku v2 and Ethereum Messaging'
title: '[Talk] Vac, Waku v2 and Ethereum Messaging'
date: 2020-11-10 12:00:00
authors: oskarth
published: true
slug: waku-v2-ethereum-messaging
categories: research
summary: Talk from Taipei Ethereum Meetup. Read on to find out about our journey from Whisper to Waku v2, as well as how Waku v2 can be useful for Etherum Messaging.
image: /img/taipei_ethereum_meetup_slide.png
discuss: https://forum.vac.dev/t/discussion-talk-vac-waku-v2-and-ethereum-messaging/60
---
import { DocMetadata } from '@site/src/components/mdx'
Talk from Taipei Ethereum Meetup. Read on to find out about our journey from Whisper to Waku v2, as well as how Waku v2 can be useful for Etherum Messaging.
<DocMetadata />
<!--truncate-->
*The following post is a transcript of the talk given at the [Taipei Ethereum meetup, November 5](https://www.meetup.com/Taipei-Ethereum-Meetup/events/274033344/). There is also a [video recording]( https://www.youtube.com/watch?v=lUDy1MoeYnI).*
_The following post is a transcript of the talk given at the [Taipei Ethereum meetup, November 5](https://www.meetup.com/Taipei-Ethereum-Meetup/events/274033344/). There is also a [video recording](https://www.youtube.com/watch?v=lUDy1MoeYnI)._
---
@@ -72,9 +71,9 @@ Taking a step back, what problem does Waku v2 attempt to solve compared to all t
3. **Resource restricted**. These applications often run in constrained environments, where resources or the environment is restricted in some fashion. E.g.:
- limited bandwidth, CPU, memory, disk, battery, etc
- not being publicly connectable
- only being intermittently connected; mostly-offline
- limited bandwidth, CPU, memory, disk, battery, etc
- not being publicly connectable
- only being intermittently connected; mostly-offline
4. **Privacy**. These applications have a desire for some privacy guarantees, such as pseudonymity, metadata protection in transit, etc.
@@ -90,12 +89,12 @@ It is running over libp2p and we had our second internal testnet last week or so
The main implementation is written in Nim using nim-libp2p, which is also powering Nimbus, an Ethereum 2 client. There is also a PoC for running Waku v2 in the browser. On a spec level, we have the following specifications that corresponds to the components that make up Waku v2:
- Waku v2 - this is the main spec that explains the goals of providing generalized messaging, in a p2p context, with a focus on privacy and running on resources restricted devices.
- Relay - this is the main PubSub spec that provides better routing. It builds on top of GossipSub, which is what Eth2 heavily relies on as well.
- Store - this is a 1-1 protocol for light nodes to get historical messages, if they are mostly-offline.
- Filter - this is a 1-1 protocol for light nodes that are bandwidth restricted to only (or mostly) get messages they care about.
- Message - this explains the payload, to get some basic encryption and content topics. It corresponds roughly to envelopes in Whisper/Waku v1.
- Bridge - this explains how to do bridging between Waku v1 and Waku v2 for compatibility.
- Waku v2 - this is the main spec that explains the goals of providing generalized messaging, in a p2p context, with a focus on privacy and running on resources restricted devices.
- Relay - this is the main PubSub spec that provides better routing. It builds on top of GossipSub, which is what Eth2 heavily relies on as well.
- Store - this is a 1-1 protocol for light nodes to get historical messages, if they are mostly-offline.
- Filter - this is a 1-1 protocol for light nodes that are bandwidth restricted to only (or mostly) get messages they care about.
- Message - this explains the payload, to get some basic encryption and content topics. It corresponds roughly to envelopes in Whisper/Waku v1.
- Bridge - this explains how to do bridging between Waku v1 and Waku v2 for compatibility.
Right now, all protocols, with the exception of bridge, are in draft mode, meaning they have been implemented but are not yet being relied upon in production.
@@ -113,10 +112,10 @@ There are also some changes we made to at what level content encryption happens,
More generally, beyond getting to production-ready use, there are a few bigger pieces that we are working on or will work on soon. These are things like:
- Better scaling, by using topic sharding.
- Accounting and user-run nodes, to account for and incentives full nodes.
- Stronger and more rigorous privacy guarantees, e.g. through study of GossipSub, unlinkable packet formats, etc.
- Rate Limit Nullifier for privacy preserving spam protection, a la what Barry Whitehat has presented before.
- Better scaling, by using topic sharding.
- Accounting and user-run nodes, to account for and incentives full nodes.
- Stronger and more rigorous privacy guarantees, e.g. through study of GossipSub, unlinkable packet formats, etc.
- Rate Limit Nullifier for privacy preserving spam protection, a la what Barry Whitehat has presented before.
As well as better support for Ethereum M2M Messaging. Which is what I'll talk about next.
@@ -130,12 +129,12 @@ It is easy to think that Waku v2 is only for human to human messaging, since tha
What is Ethereum M2M messaging? Going back to the Holy Trinity of Ethereum/Whisper/Swarm, the messaging component was seen as something that could facilitate messages between dapps and acts as a building block. This can help with things such as:
- Reducing on-chain transactions
- Reduce latency for operations
- Decentralize centrally coordinated services (like WalletConnect)
- Improve UX of dapps
- Broadcast live information
- A message transport layer for state channels
- Reducing on-chain transactions
- Reduce latency for operations
- Decentralize centrally coordinated services (like WalletConnect)
- Improve UX of dapps
- Broadcast live information
- A message transport layer for state channels
And so on.
@@ -143,11 +142,11 @@ And so on.
What are some examples of practical things Waku as used for Ethereum Messaging could solve?
- Multisig transfers only needing one on chain transaction
- DAO votes only needing one one chain transaction
- Giving dapps ability to direct push notifications to users
- Giving users ability to directly respond to requests from daps
- Decentralized Wallet Connect
- Multisig transfers only needing one on chain transaction
- DAO votes only needing one one chain transaction
- Giving dapps ability to direct push notifications to users
- Giving users ability to directly respond to requests from daps
- Decentralized Wallet Connect
Etc.

124
docs/2021-03-03-rln-relay.mdx → research/2021-03-03-rln-relay.mdx
View File

@@ -1,13 +1,12 @@
---
layout: post
name: "Privacy-preserving p2p economic spam protection in Waku v2"
title: "Privacy-preserving p2p economic spam protection in Waku v2"
date: 2021-03-05 12:00:00
author: sanaztaheri
name: 'Privacy-preserving p2p economic spam protection in Waku v2'
title: 'Privacy-preserving p2p economic spam protection in Waku v2'
date: 2021-03-05 12:00:00
authors: sanaz
published: true
slug: rln-relay
categories: reserach
summary: This post is going to give you an overview of how spam protection can be achieved in Waku Relay through rate-limiting nullifiers. We will cover a summary of spam-protection methods in centralized and p2p systems, and the solution overview and details of the economic spam-protection method. The open issues and future steps are discussed in the end.
image: /img/rain.png
discuss: https://forum.vac.dev/t/privacy-preserving-p2p-economic-spam-protection-in-waku-v2-with-rate-limiting-nullfiers/66
@@ -15,69 +14,82 @@ toc_min_heading_level: 2
toc_max_heading_level: 5
---
import { DocMetadata } from '@site/src/components/mdx'
This post is going to give you an overview of how spam protection can be achieved in Waku Relay through rate-limiting nullifiers. We will cover a summary of spam-protection methods in centralized and p2p systems, and the solution overview and details of the economic spam-protection method. The open issues and future steps are discussed in the end.
<DocMetadata />
<!--truncate-->
## Introduction
This post is going to give you an overview of how spam protection can be achieved in Waku Relay protocol[^2] through Rate-Limiting Nullifiers[^3] [^4] or RLN for short.
Let me give a little background about Waku(v2)[^1]. Waku is a privacy-preserving peer-to-peer (p2p) messaging protocol for resource-restricted devices. Being p2p means that Waku relies on **No** central server. Instead, peers collaboratively deliver messages in the network. Waku uses GossipSub[^16] as the underlying routing protocol (as of the writeup of this post). At a high level, GossipSub is based on publisher-subscriber architecture. That is, *peers, congregate around topics they are interested in and can send messages to topics. Each message gets delivered to all peers subscribed to the topic*. In GossipSub, a peer has a constant number of direct connections/neighbors. In order to publish a message, the author forwards its message to a subset of neighbors. The neighbors proceed similarly till the message gets propagated in the network of the subscribed peers. The message publishing and routing procedures are part of the Waku Relay[^17] protocol.
Let me give a little background about Waku(v2)[^1]. Waku is a privacy-preserving peer-to-peer (p2p) messaging protocol for resource-restricted devices. Being p2p means that Waku relies on **No** central server. Instead, peers collaboratively deliver messages in the network. Waku uses GossipSub[^16] as the underlying routing protocol (as of the writeup of this post). At a high level, GossipSub is based on publisher-subscriber architecture. That is, _peers, congregate around topics they are interested in and can send messages to topics. Each message gets delivered to all peers subscribed to the topic_. In GossipSub, a peer has a constant number of direct connections/neighbors. In order to publish a message, the author forwards its message to a subset of neighbors. The neighbors proceed similarly till the message gets propagated in the network of the subscribed peers. The message publishing and routing procedures are part of the Waku Relay[^17] protocol.
![Figure 1: An overview of privacy-preserving p2p economic spam protection in Waku v2 RLN-Relay protocol.](/img/rln-relay/rln-relay-overview.png)
## What do we mean by spamming?
In centralized messaging systems, a spammer usually indicates an entity that uses the messaging system to send an unsolicited message (spam) to large numbers of recipients. However, in Waku with a p2p architecture, spam messages not only affect the recipients but also all the other peers involved in the routing process as they have to spend their computational power/bandwidth/storage capacity on processing spam messages. As such, we define a spammer as an entity that uses the messaging system to publish a large number of messages in a short amount of time. The messages issued in this way are called spam. In this definition, we disregard the intention of the spammer as well as the content of the message and the number of recipients.
## Possible Solutions
Has the spamming issue been addressed before? Of course yes! Here is an overview of the spam protection techniques with their trade-offs and use-cases. In this overview, we distinguish between protection techniques that are targeted for centralized messaging systems and those for p2p architectures.
### Centralized Messaging Systems
In traditional centralized messaging systems, spam usually signifies unsolicited messages sent in bulk or messages with malicious content like malware. Protection mechanisms include
In traditional centralized messaging systems, spam usually signifies unsolicited messages sent in bulk or messages with malicious content like malware. Protection mechanisms include
- authentication through some piece of personally identifiable information e.g., phone number
- checksum-based filtering to protect against messages sent in bulk
- challenge-response systems
- content filtering on the server or via a proxy application
These methods exploit the fact that the messaging system is centralized and a global view of the users' activities is available based on which spamming patterns can be extracted and defeated accordingly. Moreover, users are associated with an identifier e.g., a username which enables the server to profile each user e.g., to detect suspicious behavior like spamming. Such profiling possibility is against the user's anonymity and privacy.
These methods exploit the fact that the messaging system is centralized and a global view of the users' activities is available based on which spamming patterns can be extracted and defeated accordingly. Moreover, users are associated with an identifier e.g., a username which enables the server to profile each user e.g., to detect suspicious behavior like spamming. Such profiling possibility is against the user's anonymity and privacy.
Among the techniques enumerated above, authentication through phone numbers is a some-what economic-incentive measure as providing multiple valid phone numbers will be expensive for the attacker. Notice that while using an expensive authentication method can reduce the number of accounts owned by a single spammer, cannot address the spam issue entirely. This is because the spammer can still send bulk messages through one single account. For this approach to be effective, a centralized mediator is essential. That is why such a solution would not fit the p2p environments where no centralized control exists.
### P2P Systems
What about spam prevention in p2p messaging platforms? There are two techniques, namely *Proof of Work*[^8] deployed by Whisper[^9] and *Peer scoring*[^6] method (namely reputation-based approach) adopted by LibP2P. However, each of these solutions has its own shortcomings for real-life use-cases as explained below.
What about spam prevention in p2p messaging platforms? There are two techniques, namely _Proof of Work_[^8] deployed by Whisper[^9] and _Peer scoring_[^6] method (namely reputation-based approach) adopted by LibP2P. However, each of these solutions has its own shortcomings for real-life use-cases as explained below.
#### Proof of work
The idea behind the Proof Of Work i.e., POW[^8] is to make messaging a computationally costly operation hence lowering the messaging rate of **all** the peers including the spammers. In specific, the message publisher has to solve a puzzle and the puzzle is to find a nonce such that the hash of the message concatenated with the nonce has at least z leading zeros. z is known as the difficulty of the puzzle. Since the hash function is one-way, peers have to brute-force to find a nonce. Hashing is a computationally-heavy operation so is the brute-force. While solving the puzzle is computationally expensive, it is comparatively cheap to verify the solution.
POW is also used as the underlying mining algorithm in Ethereum and Bitcoin blockchain. There, the goal is to contain the mining speed and allow the decentralized network to come to a consensus, or agree on things like account balances and the order of transactions.
POW is also used as the underlying mining algorithm in Ethereum and Bitcoin blockchain. There, the goal is to contain the mining speed and allow the decentralized network to come to a consensus, or agree on things like account balances and the order of transactions.
While the use of POW makes perfect sense in Ethereum / Bitcoin blockchain, it shows practical issues in heterogeneous p2p messaging systems with resource-restricted peers. Some peers won't be able to carry the designated computation and will be effectively excluded. Such exclusion showed to be practically an issue in applications like Status, which used to rely on POW for spam-protection, to the extent that the difficulty level had to be set close to zero.
While the use of POW makes perfect sense in Ethereum / Bitcoin blockchain, it shows practical issues in heterogeneous p2p messaging systems with resource-restricted peers. Some peers won't be able to carry the designated computation and will be effectively excluded. Such exclusion showed to be practically an issue in applications like Status, which used to rely on POW for spam-protection, to the extent that the difficulty level had to be set close to zero.
#### Peer Scoring
The peer scoring method[^6] that is utilized by libp2p is to limit the number of messages issued by a peer in connection to another peer. That is each peer monitors all the peers to which it is directly connected and adjusts their messaging quota i.e., to route or not route their messages depending on their past activities. For example, if a peer detects its neighbor is sending more than x messages per month, can drop its quota to z.x where z is less than one. The shortcoming of this solution is that scoring is based on peers' local observations and the concept of the score is defined in relation to one single peer. This leaves room for an attack where a spammer can make connections to k peers in the system and publishes k.(x-1) messages by exploiting all of its k connections. Another attack scenario is through botnets consisting of a large number of e.g., a million bots. The attacker rents a botnet and inserts each of them as a legitimate peer to the network and each can publish x-1 messages per month[^7].
The peer scoring method[^6] that is utilized by libp2p is to limit the number of messages issued by a peer in connection to another peer. That is each peer monitors all the peers to which it is directly connected and adjusts their messaging quota i.e., to route or not route their messages depending on their past activities. For example, if a peer detects its neighbor is sending more than x messages per month, can drop its quota to z.x where z is less than one. The shortcoming of this solution is that scoring is based on peers' local observations and the concept of the score is defined in relation to one single peer. This leaves room for an attack where a spammer can make connections to k peers in the system and publishes k.(x-1) messages by exploiting all of its k connections. Another attack scenario is through botnets consisting of a large number of e.g., a million bots. The attacker rents a botnet and inserts each of them as a legitimate peer to the network and each can publish x-1 messages per month[^7].
#### Economic-Incentive Spam protection
Is this the end of our spam-protection journey? Shall we simply give up and leave spammers be? Certainly not!
Waku RLN-Relay gives us a p2p spam-protection method which:
- suits **p2p** systems and does not rely on any central entity.
- is **efficient** i.e., with no unreasonable computational, storage, memory, and bandwidth requirement! as such, it fits the network of **heterogeneous** peers.
- is **efficient** i.e., with no unreasonable computational, storage, memory, and bandwidth requirement! as such, it fits the network of **heterogeneous** peers.
- respects users **privacy** unlike reputation-based and centralized methods.
- deploys **economic-incentives** to contain spammers' activity. Namely, there is a financial sacrifice for those who want to spam the system. How? follow along ...
We devise a general rule to save everyone's life and that is
We devise a general rule to save everyone's life and that is
**No one can publish more than M messages per epoch without being financially charged!**
**No one can publish more than M messages per epoch without being financially charged!**
We set M to 1 for now, but this can be any arbitrary value. You may be thinking "This is too restrictive! Only one per epoch?". Don't worry, we set the epoch to a reasonable value so that it does not slow down the communication of innocent users but will make the life of spammers harder! Epoch here can be every second, as defined by UTC date-time +-20s.
The remainder of this post is all about the story of how to enforce this limit on each user's messaging rate as well as how to impose the financial cost when the limit gets violated. This brings us to the Rate Limiting Nullifiers and how we integrate this technique into Waku v2 (in specific the Waku Relay protocol) to protect our valuable users against spammers.
The remainder of this post is all about the story of how to enforce this limit on each user's messaging rate as well as how to impose the financial cost when the limit gets violated. This brings us to the Rate Limiting Nullifiers and how we integrate this technique into Waku v2 (in specific the Waku Relay protocol) to protect our valuable users against spammers.
## Technical Terms
**Zero-knowledge proof**: Zero-knowledge proof (ZKP)[^14] allows a *prover* to show a *verifier* that they know something, without revealing what that something is. This means you can do the trust-minimized computation that is also privacy-preserving. As a basic example, instead of showing your ID when going to a bar you simply give them proof that you are over 18, without showing the doorman your id. In this write-up, by ZKP we essentially mean zkSNARK[^15] which is one of the many types of ZKPs.
**Zero-knowledge proof**: Zero-knowledge proof (ZKP)[^14] allows a _prover_ to show a _verifier_ that they know something, without revealing what that something is. This means you can do the trust-minimized computation that is also privacy-preserving. As a basic example, instead of showing your ID when going to a bar you simply give them proof that you are over 18, without showing the doorman your id. In this write-up, by ZKP we essentially mean zkSNARK[^15] which is one of the many types of ZKPs.
**Threshold Secret Sharing Scheme**: (m,n) Threshold secret-sharing is a method by which you can split a secret value s into n pieces in a way that the secret s can be reconstructed by having m pieces (m <= n). The economic-incentive spam protection utilizes a (2,n) secret sharing realized by Shamir Secret Sharing Scheme[^13].
## Overview: Economic-Incentive Spam protection through Rate Limiting Nullifiers
**Context**: We started the idea of economic-incentive spam protection more than a year ago and conducted a feasibility study to identify blockers and unknowns. The results are published in our prior [post](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks). Since then major progress has been made and the prior identified blockers that are listed below are now addressed. Kudos to [Barry WhiteHat](https://github.com/barryWhiteHat), [Onur Kilic](https://github.com/kilic), [Koh Wei Jie](https://github.com/weijiekoh/perpetualpowersoftau) for all of their hard work, research, and development which made this progress possible.
- the proof time[^22] which was initially in the order of minutes ~10 mins and now is almost 0.5 seconds
- the prover key size[^21] which was initially ~110MB and now is ~3.9MB
- the lack of Shamir logic[^19] which is now implemented and part of the RLN repository[^4]
@@ -87,87 +99,103 @@ The remainder of this post is all about the story of how to enforce this limit o
Now that you have more context, let's see how the final solution works. The fundamental point is to make it economically costly to send more than your share of messages and to do so in a privacy-preserving and e2e fashion. To do that we have the following components:
- 1- **Group**: We manage all the peers inside a large group (later we can split peers into smaller groups, but for now consider only one). The group management is done via a smart contract which is devised for this purpose and is deployed on the Ethereum blockchain.
- 2- **Membership**: To be able to send messages and in specific for the published messages to get routed by all the peers, publishing peers have to register to the group. Membership involves setting up public and private key pairs (think of it as the username and password). The private key remains at the user side but the public key becomes a part of the group information on the contract (publicly available) and everyone has access to it. Public keys are not human-generated (like usernames) and instead they are random numbers, as such, they do not reveal any information about the owner (think of public keys as pseudonyms). Registration is mandatory for the users who want to publish a message, however, users who only want to listen to the messages are more than welcome and do not have to register in the group.
- **Membership fee**: Membership is not for free! each peer has to lock a certain amount of funds during the registration (this means peers have to have an Ethereum account with sufficient balance for this sake). This fund is safely stored on the contract and remains intact unless the peer attempts to break the rules and publish more than one message per epoch.
- 2- **Membership**: To be able to send messages and in specific for the published messages to get routed by all the peers, publishing peers have to register to the group. Membership involves setting up public and private key pairs (think of it as the username and password). The private key remains at the user side but the public key becomes a part of the group information on the contract (publicly available) and everyone has access to it. Public keys are not human-generated (like usernames) and instead they are random numbers, as such, they do not reveal any information about the owner (think of public keys as pseudonyms). Registration is mandatory for the users who want to publish a message, however, users who only want to listen to the messages are more than welcome and do not have to register in the group.
- **Membership fee**: Membership is not for free! each peer has to lock a certain amount of funds during the registration (this means peers have to have an Ethereum account with sufficient balance for this sake). This fund is safely stored on the contract and remains intact unless the peer attempts to break the rules and publish more than one message per epoch.
- **Zero-knowledge Proof of membership**: Do you want your message to get routed to its destination, fine, but you have to prove that you are a member of the group (sorry, no one can escape the registration phase!). Now, you may be thinking that should I attach my public key to my message to prove my membership? Absolutely Not! we said that our solution respects privacy! membership proofs are done in a zero-knowledge manner that is each message will carry cryptographic proof asserting that "the message is generated by one of the current members of the group", so your identity remains private and your anonymity is preserved!
- **Slashing through secret sharing**: Till now it does not seem like we can catch spammers, right? yes, you are right! now comes the exciting part, detecting spammers and slashing them. The core idea behind the slashing is that each publishing peer (not routing peers!) has to integrate a secret share of its private key inside the message. The secret share is deterministically computed over the private key and the current epoch. The content of this share is harmless for the peer's privacy (it looks random) unless the peer attempts to publish more than one message in the same epoch hence disclosing more than one secret share of its private key. Indeed two distinct shares of the private key under the same epoch are enough to reconstruct the entire private key. Then what should you do with the recovered private key? hurry up! go to the contract and withdraw the private key and claim its fund and get rich!! Are you thinking what if spammers attach junk values instead of valid secret shares? Of course, that wouldn't be cool! so, there is a zero-knowledge proof for this sake as well where the publishing peer has to prove that the secret shares are generated correctly.
A high-level overview of the economic spam protection is shown in Figure 1.
## Flow
## Flow
In this section, we describe the flow of the economic-incentive spam detection mechanism from the viewpoint of a single peer. An overview of this flow is provided in Figure 3.
## Setup and Registration
A peer willing to publish a message is required to register. Registration is moderated through a smart contract deployed on the Ethereum blockchain. The state of the contract contains the list of registered members' public keys. An overview of registration is illustrated in Figure 2.
For the registration, a peer creates a transaction that sends x amount of Ether to the contract. The peer who has the "private key" `sk` associated with that deposit would be able to withdraw x Ether by providing valid proof. Note that `sk` is initially only known by the owning peer however it may get exposed to other peers in case the owner attempts spamming the system i.e., sending more than one message per epoch.
For the registration, a peer creates a transaction that sends x amount of Ether to the contract. The peer who has the "private key" `sk` associated with that deposit would be able to withdraw x Ether by providing valid proof. Note that `sk` is initially only known by the owning peer however it may get exposed to other peers in case the owner attempts spamming the system i.e., sending more than one message per epoch.
The following relation holds between the `sk` and `pk` i.e., `pk = H(sk)` where `H` denotes a hash function.
![Figure 2: Registration](/img/rln-relay/rln-relay.png)
## Maintaining the membership Merkle Tree
The ZKP of membership that we mentioned before relies on the representation of the entire group as a [Merkle Tree](/#). The tree construction and maintenance is delegated to the peers (the initial idea was to keep the tree on the chain as part of the contract, however, the cost associated with member deletion and insertion was high and unreasonable, please see [Feasibility and Open Issues](#Feasibility-and-Open-Issues) for more details). As such, each peer needs to build the tree locally and sync itself with the contract updates (peer insertion and deletion) to mirror them on its tree.
Two pieces of information of the tree are important as they enable peers to generate zero-knowledge proofs. One is the root of the tree and the other is the membership proof (or the authentication path). The tree root is public information whereas the membership proof is private data (or more precisely the index of the peer in the tree).
Two pieces of information of the tree are important as they enable peers to generate zero-knowledge proofs. One is the root of the tree and the other is the membership proof (or the authentication path). The tree root is public information whereas the membership proof is private data (or more precisely the index of the peer in the tree).
## Publishing
In order to publish at a given epoch, each message must carry a proof i.e., a zero-knowledge proof signifying that the publishing peer is a registered member, and has not exceeded the messaging rate at the given epoch.
In order to publish at a given epoch, each message must carry a proof i.e., a zero-knowledge proof signifying that the publishing peer is a registered member, and has not exceeded the messaging rate at the given epoch.
Recall that the enforcement of the messaging rate was through associating a secret shared version of the peer's `sk` into the message together with a ZKP that the secret shares are constructed correctly. As for the secret sharing part, the peer generates the following data:
1. `shareX`
2. `shareY`
3. `nullifier`
The pair (`shareX`, `shareY`) is the secret shared version of `sk` that are generated using Shamir secret sharing scheme. Having two such pairs for an identical `nullifier` results in full disclosure of peer's `sk` and hence burning the associated deposit. Note that the `nullifier` is a deterministic value derived from `sk` and `epoch` therefore any two messages issued by the same peer (i.e., using the same `sk`) for the same `epoch` are guaranteed to have identical `nullifier`s.
The pair (`shareX`, `shareY`) is the secret shared version of `sk` that are generated using Shamir secret sharing scheme. Having two such pairs for an identical `nullifier` results in full disclosure of peer's `sk` and hence burning the associated deposit. Note that the `nullifier` is a deterministic value derived from `sk` and `epoch` therefore any two messages issued by the same peer (i.e., using the same `sk`) for the same `epoch` are guaranteed to have identical `nullifier`s.
Finally, the peer generates a zero-knowledge proof `zkProof` asserting the membership of the peer in the group and the correctness of the attached secret share (`shareX`, `shareY`) and the `nullifier`. In order to generate a valid proof, the peer needs to have two private inputs i.e., its `sk` and its authentication path. Other inputs are the tree root, epoch, and the content of the message.
Finally, the peer generates a zero-knowledge proof `zkProof` asserting the membership of the peer in the group and the correctness of the attached secret share (`shareX`, `shareY`) and the `nullifier`. In order to generate a valid proof, the peer needs to have two private inputs i.e., its `sk` and its authentication path. Other inputs are the tree root, epoch, and the content of the message.
**Privacy Hint:** Note that the authentication path of each peer depends on the recent list of members (hence changes when new peers register or leave). As such, it is recommended (and necessary for privacy/anonymity) that the publisher updates her authentication path based on the latest status of the group and attempts the proof using the updated version.
An overview of the publishing procedure is provided in Figure 3.
## Routing
Upon the receipt of a message, the routing peer needs to decide whether to route it or not. This decision relies on the following factors:
1) If the epoch value attached to the message has a non-reasonable gap with the routing peer's current epoch then the message must be dropped (this is to prevent a newly registered peer spamming the system by messaging for all the past epochs).
2) The message MUST contain valid proof that gets verified by the routing peer.
If the preceding checks are passed successfully, then the message is relayed. In case of an invalid proof, the message is dropped. If spamming is detected, the publishing peer gets slashed (see [Spam Detection and Slashing](#Spam-Detection-and-Slashing)).
1. If the epoch value attached to the message has a non-reasonable gap with the routing peer's current epoch then the message must be dropped (this is to prevent a newly registered peer spamming the system by messaging for all the past epochs).
2. The message MUST contain valid proof that gets verified by the routing peer.
If the preceding checks are passed successfully, then the message is relayed. In case of an invalid proof, the message is dropped. If spamming is detected, the publishing peer gets slashed (see [Spam Detection and Slashing](#Spam-Detection-and-Slashing)).
An overview of the routing procedure is provided in Figure 3.
### Spam Detection and Slashing
In order to enable local spam detection and slashing, routing peers MUST record the `nullifier`, `shareX`, and `shareY` of any incoming message conditioned that it is not spam and has valid proof. To do so, the peer should follow the following steps.
1. The routing peer first verifies the `zkProof` and drops the message if not verified.
2. Otherwise, it checks whether a message with an identical `nullifier` has already been relayed.
+ a) If such message exists and its `shareX` and `shareY` components are different from the incoming message, then slashing takes place (if the `shareX` and `shareY` fields of the previously relayed message is identical to the incoming message, then the message is a duplicate and shall be dropped).
+ b) If none found, then the message gets relayed.
In order to enable local spam detection and slashing, routing peers MUST record the `nullifier`, `shareX`, and `shareY` of any incoming message conditioned that it is not spam and has valid proof. To do so, the peer should follow the following steps.
1. The routing peer first verifies the `zkProof` and drops the message if not verified.
2. Otherwise, it checks whether a message with an identical `nullifier` has already been relayed.
- a) If such message exists and its `shareX` and `shareY` components are different from the incoming message, then slashing takes place (if the `shareX` and `shareY` fields of the previously relayed message is identical to the incoming message, then the message is a duplicate and shall be dropped).
- b) If none found, then the message gets relayed.
An overview of the slashing procedure is provided in Figure 3.
![Figure 3: Publishing, Routing and Slashing workflow.](/img/rln-relay/rln-message-verification.png)
## Feasibility and Open Issues
We've come a long way since a year ago, blockers resolved, now we have implemented it end-to-end. We learned lot and could identify further issues and unknowns some of which are blocking getting to production. The summary of the identified issues are presented below.
We've come a long way since a year ago, blockers resolved, now we have implemented it end-to-end. We learned lot and could identify further issues and unknowns some of which are blocking getting to production. The summary of the identified issues are presented below.
## Storage overhead per peer
Currently, peers are supposed to maintain the entire tree locally and it imposes storage overhead which is linear in the size of the group (see this [issue](https://github.com/vacp2p/research/issues/57)[^11] for more details). One way to cope with this is to use the light-node and full-node paradigm in which only a subset of peers who are more resourceful retain the tree whereas the light nodes obtain the necessary information by interacting with the full nodes. Another way to approach this problem is through a more storage efficient method (as described in this research issue[^12]) where peers store a partial view of the tree instead of the entire tree. Keeping the partial view lowers the storage complexity to O(log(N)) where N is the size of the group. There are still unknown unknowns to this solution, as such, it must be studied further to become fully functional.
## Cost-effective way of member insertion and deletion
Currently, the cost associated with RLN-Relay membership is around 30 USD[^10]. We aim at finding a more cost-effective approach. Please feel free to share with us your solution ideas in this regard in this [issue](https://github.com/vacp2p/research/issues/56).
Currently, the cost associated with RLN-Relay membership is around 30 USD[^10]. We aim at finding a more cost-effective approach. Please feel free to share with us your solution ideas in this regard in this [issue](https://github.com/vacp2p/research/issues/56).
## Exceeding the messaging rate via multiple registrations
While the economic-incentive solution has an economic incentive to discourage spamming, we should note that there is still **expensive attack(s)**[^23] that a spammer can launch to break the messaging rate limit. That is, the attacker can pay for multiple legit registrations e.g., k, hence being able to publish k messages per epoch. We believe that the higher the membership fee is, the less probable would be such an attack, hence a stronger level of spam-protection can be achieved. Following this argument, the high fee associated with the membership (which we listed above as an open problem) can indeed be contributing to a better protection level.
While the economic-incentive solution has an economic incentive to discourage spamming, we should note that there is still **expensive attack(s)**[^23] that a spammer can launch to break the messaging rate limit. That is, the attacker can pay for multiple legit registrations e.g., k, hence being able to publish k messages per epoch. We believe that the higher the membership fee is, the less probable would be such an attack, hence a stronger level of spam-protection can be achieved. Following this argument, the high fee associated with the membership (which we listed above as an open problem) can indeed be contributing to a better protection level.
## Conclusion and Future Steps
As discussed in this post, Waku RLN Relay can achieve a privacy-preserving economic spam protection through rate-limiting nullifiers. The idea is to financially discourage peers from publishing more than one message per epoch. In specific, exceeding the messaging rate results in a financial charge. Those who violate this rule are called spammers and their messages are spam. The identification of spammers does not rely on any central entity. Also, the financial punishment of spammers is cryptographically guaranteed.
In this solution, privacy is guaranteed since: 1) Peers do not have to disclose any piece of personally identifiable information in any phase i.e., neither in the registration nor in the messaging phase 2) Peers can prove that they have not exceeded the messaging rate in a zero-knowledge manner and without leaving any trace to their membership accounts.
Furthermore, all the computations are light hence this solution fits the heterogenous p2p messaging system. Note that the zero-knowledge proof parts are handled through zkSNARKs and the benchmarking result can be found in the RLN benchmark report[^5].
As discussed in this post, Waku RLN Relay can achieve a privacy-preserving economic spam protection through rate-limiting nullifiers. The idea is to financially discourage peers from publishing more than one message per epoch. In specific, exceeding the messaging rate results in a financial charge. Those who violate this rule are called spammers and their messages are spam. The identification of spammers does not rely on any central entity. Also, the financial punishment of spammers is cryptographically guaranteed.
In this solution, privacy is guaranteed since: 1) Peers do not have to disclose any piece of personally identifiable information in any phase i.e., neither in the registration nor in the messaging phase 2) Peers can prove that they have not exceeded the messaging rate in a zero-knowledge manner and without leaving any trace to their membership accounts.
Furthermore, all the computations are light hence this solution fits the heterogenous p2p messaging system. Note that the zero-knowledge proof parts are handled through zkSNARKs and the benchmarking result can be found in the RLN benchmark report[^5].
**Future steps**:
We are still at the PoC level, and the development is in progress. As our future steps,
- we would like to evaluate the running time associated with the Merkle tree operations. Indeed, the need to locally store Merkle tree on each peer was one of the unknowns discovered during this PoC and yet the concrete benchmarking result in this regard is not available.
- We would also like to pursue our storage-efficient Merkle Tree maintenance solution in order to lower the storage overhead of peers.
- In line with the storage optimization, the full-node light-node structure is another path to follow.
- Another possible improvement is to replace the membership contract with a distributed group management scheme e.g., through distributed hash tables. This is to address possible performance issues that the interaction with the Ethereum blockchain may cause. For example, the registration transactions are subject to delay as they have to be mined before being visible in the state of the membership contract. This means peers have to wait for some time before being able to publish any message.
We are still at the PoC level, and the development is in progress. As our future steps,
- we would like to evaluate the running time associated with the Merkle tree operations. Indeed, the need to locally store Merkle tree on each peer was one of the unknowns discovered during this PoC and yet the concrete benchmarking result in this regard is not available.
- We would also like to pursue our storage-efficient Merkle Tree maintenance solution in order to lower the storage overhead of peers.
- In line with the storage optimization, the full-node light-node structure is another path to follow.
- Another possible improvement is to replace the membership contract with a distributed group management scheme e.g., through distributed hash tables. This is to address possible performance issues that the interaction with the Ethereum blockchain may cause. For example, the registration transactions are subject to delay as they have to be mined before being visible in the state of the membership contract. This means peers have to wait for some time before being able to publish any message.
## Acknowledgement
Thanks to Onur Kılıç for his explanation and pointers and for assisting with development and runtime issues. Also thanks to Barry Whitehat for his time and insightful comments. Special thanks to Oskar Thoren for his constructive comments and his guides during the development of this PoC and the writeup of this post.
## References
@@ -187,9 +215,9 @@ Thanks to Onur Kılıç for his explanation and pointers and for assisting with
[^13]: Shamir Secret Sharing Scheme: [https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing)
[^14]: Zero Knowledge Proof: [https://dl.acm.org/doi/abs/10.1145/3335741.3335750](https://dl.acm.org/doi/abs/10.1145/3335741.3335750) and [https://en.wikipedia.org/wiki/Zero-knowledge_proof](https://en.wikipedia.org/wiki/Zero-knowledge_proof)
[^15]: zkSNARKs: [https://link.springer.com/chapter/10.1007/978-3-662-49896-5_11](https://link.springer.com/chapter/10.1007/978-3-662-49896-5_11) and [https://coinpare.io/whitepaper/zcash.pdf](https://coinpare.io/whitepaper/zcash.pdf)
[^16]: GossipSub: [https://docs.libp2p.io/concepts/publish-subscribe/](https://docs.libp2p.io/concepts/publish-subscribe/)
[^16]: GossipSub: [https://docs.libp2p.io/concepts/publish-subscribe/](https://docs.libp2p.io/concepts/publish-subscribe/)
[^17]: Waku Relay: https://rfc.vac.dev/spec/11/
[^18]: Prior blockers of RLN-Relay: [https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks)
[^18]: Prior blockers of RLN-Relay: [https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks)
[^19]: The lack of Shamir secret sharing in zkSNARKs: [https://github.com/vacp2p/research/issues/10](https://github.com/vacp2p/research/issues/10)
[^20]: The MPC required for zkSNARKs trusted setup: [https://github.com/vacp2p/research/issues/9](https://github.com/vacp2p/research/issues/9)
[^21]: Prover key size: [https://github.com/vacp2p/research/issues/8](https://github.com/vacp2p/research/issues/8)

32
docs/2021-06-04-presenting-js-waku.mdx → research/2021-06-04-presenting-js-waku.mdx
View File

@@ -1,20 +1,19 @@
---
layout: post
name: "Presenting JS-Waku: Waku v2 in the Browser"
title: "Presenting JS-Waku: Waku v2 in the Browser"
name: 'Presenting JS-Waku: Waku v2 in the Browser'
title: 'Presenting JS-Waku: Waku v2 in the Browser'
date: 2021-06-04 12:00:00
author: franck
authors: franck
published: true
slug: presenting-js-waku
categories: platform
summary: "JS-Waku is bringing Waku v2 to the browser. Learn what we achieved so far and what is next in our pipeline!"
image: /img/js-waku-gist.png
discuss: https://forum.vac.dev/t/discussion-presenting-js-waku-waku-v2-in-the-browser/81
discuss: https://forum.vac.dev/t/discussion-presenting-js-waku-waku-v2-in-the-browser/81
---
import { DocMetadata } from '@site/src/components/mdx'
JS-Waku is bringing Waku v2 to the browser. Learn what we achieved so far and what is next in our pipeline!
<DocMetadata />
<!--truncate-->
For the past 3 months, we have been working on bringing Waku v2 to the browser.
Our aim is to empower dApps with Waku v2, and it led to the creation of a new library.
@@ -65,7 +64,7 @@ It showed how using js-libp2p with few modifications enabled access to the Waku
There was still some unresolved challenges.
For example, nim-waku only support TCP connections which are not supported by browser applications.
Hence, to connect to other node, the POC was connecting to a NodeJS proxy application using websockets,
which in turn could connect to wakunode2 via TCP.
which in turn could connect to wakunode2 via TCP.
However, to enable dApp and Wallet developers to easily integrate Waku in their product,
we need to give them a library that is easy to use and works out of the box:
@@ -113,7 +112,7 @@ and fix small nim-waku & nim-libp2p bugs
To fully access the waku network, JS-Waku needs to enable web apps to connect to nim-waku nodes.
A standard way to do so is using secure websockets as it is not possible to connect directly to a TCP port from the browser.
Unfortunately websocket support is not yet available in [nim-libp2p](https://github.com/status-im/nim-libp2p/issues/407) so
Unfortunately websocket support is not yet available in [nim-libp2p](https://github.com/status-im/nim-libp2p/issues/407) so
we ended up deploying [websockify](https://github.com/novnc/websockify) alongside wakunode2 instances.
As we built the [web chat app](https://github.com/status-im/js-waku/tree/main/examples/web-chat),
@@ -121,15 +120,18 @@ we were able to fine tune the API to provide a simple and succinct interface.
You can start a node, connect to other nodes and send a message in less than ten lines of code:
```javascript
import { Waku } from 'js-waku';
import { Waku } from 'js-waku'
const waku = await Waku.create({});
const waku = await Waku.create({})
const nodes = await getStatusFleetNodes();
await Promise.all(nodes.map((addr) => waku.dial(addr)));
const nodes = await getStatusFleetNodes()
await Promise.all(nodes.map((addr) => waku.dial(addr)))
const msg = WakuMessage.fromUtf8String("Here is a message!", "/my-cool-app/1/my-use-case/proto")
await waku.relay.send(msg);
const msg = WakuMessage.fromUtf8String(
'Here is a message!',
'/my-cool-app/1/my-use-case/proto',
)
await waku.relay.send(msg)
```
We have also put a bounty at [0xHack](https://0xhack.dev/) for using JS-Waku

17
docs/2021-08-06-coscup-waku-ethereum.mdx → research/2021-08-06-coscup-waku-ethereum.mdx
View File

@@ -1,22 +1,21 @@
---
layout: post
name: "[Talk at COSCUP] Vac, Waku v2 and Ethereum Messaging"
title: "[Talk at COSCUP] Vac, Waku v2 and Ethereum Messaging"
date: 2021-08-06 12:00:00
author: oskarth
name: '[Talk at COSCUP] Vac, Waku v2 and Ethereum Messaging'
title: '[Talk at COSCUP] Vac, Waku v2 and Ethereum Messaging'
date: 2021-08-06 12:00:00
authors: oskarth
published: true
slug: waku-v2-ethereum-coscup
categories: research
summary: Learn more about Waku v2, its origins, goals, protocols, implementation and ongoing research. Understand how it is used and how it can be useful for messaging in Ethereum.
image: /img/coscup-waku/talk.png
discuss: https://forum.vac.dev/t/discussion-talk-at-coscup-vac-waku-v2-and-ethereum-messaging/95
---
import { DocMetadata } from '@site/src/components/mdx'
Learn more about Waku v2, its origins, goals, protocols, implementation and ongoing research. Understand how it is used and how it can be useful for messaging in Ethereum.
<DocMetadata />
<!--truncate-->
*This is the English version of a talk originally given in Chinese at COSCUP in Taipei.*
_This is the English version of a talk originally given in Chinese at COSCUP in Taipei._
[video recording with Chinese and English subtitles.](https://www.youtube.com/watch?v=s0ATpQ4_XFc)
@@ -174,7 +173,7 @@ For more on topics, see https://rfc.vac.dev/spec/23/
In the Status protocol, content topics - topics in Whisper/Waku v1 - are used for several things:
- Contact code topic to discover X3DH bundles for perfect forward secrecy
- Partitioned into N (currently 5000) content topics to balance privacy with efficiency
- Partitioned into N (currently 5000) content topics to balance privacy with efficiency
- Public chats correspond to hash of the plaintext name
- Negotiated topic for 1:1 chat with DHKE derived content topic

48
docs/2021-10-25-waku-v1-vs-waku-v2.mdx → research/2021-10-25-waku-v1-vs-waku-v2.mdx
View File

@@ -1,20 +1,19 @@
---
layout: post
name: "Waku v1 vs Waku v2: Bandwidth Comparison"
title: "Waku v1 vs Waku v2: Bandwidth Comparison"
date: 2021-11-03 10:00:00
author: hanno
name: 'Waku v1 vs Waku v2: Bandwidth Comparison'
title: 'Waku v1 vs Waku v2: Bandwidth Comparison'
date: 2021-11-03 10:00:00
authors: hanno
published: true
slug: waku-v1-v2-bandwidth-comparison
categories: research
summary: A local comparison of bandwidth profiles showing significantly improved scalability in Waku v2 over Waku v1.
image: /img/waku1-vs-waku2/waku1-vs-waku2-overall-network-size.png
discuss: https://forum.vac.dev/t/discussion-waku-v1-vs-waku-v2-bandwidth-comparison/110
---
import { DocMetadata } from '@site/src/components/mdx'
A local comparison of bandwidth profiles showing significantly improved scalability in Waku v2 over Waku v1.
<DocMetadata />
<!--truncate-->
## Background
@@ -41,7 +40,7 @@ and compares bandwidth usage for similar message propagation scenarios.
## Theoretical improvements in Waku v2
Messages are propagated in Waku v1 using [flood routing](https://en.wikipedia.org/wiki/Flooding_(computer_networking)).
Messages are propagated in Waku v1 using [flood routing](<https://en.wikipedia.org/wiki/Flooding_(computer_networking)>).
This means that every peer will forward every new incoming message to all its connected peers (except the one it received the message from).
This necessarily leads to unnecessary duplication (termed _amplification factor_),
wasting bandwidth and resources.
@@ -69,23 +68,24 @@ Hybrid topologies similarly show only a difference between Waku v1 and Waku v2 f
where routing decisions need to be made.
For this reason, the following approach applies to all iterations:
1. Simulations are run **locally**.
This limits the size of possible scenarios due to local resource constraints,
but is a way to quickly get an approximate comparison.
This limits the size of possible scenarios due to local resource constraints,
but is a way to quickly get an approximate comparison.
2. Nodes are treated as a **blackbox** for which we only measure bandwidth,
using an external bandwidth monitoring tool.
In other words, we do not consider differences in the size of the envelope (for v1) or the message (for v2).
using an external bandwidth monitoring tool.
In other words, we do not consider differences in the size of the envelope (for v1) or the message (for v2).
3. Messages are published at a rate of **50 new messages per second** to each network,
except where explicitly stated otherwise.
except where explicitly stated otherwise.
4. Each message propagated in the network carries **8 bytes** of random payload, which is **encrypted**.
The same symmetric key cryptographic algorithm (with the same keys) are used in both Waku v1 and v2.
The same symmetric key cryptographic algorithm (with the same keys) are used in both Waku v1 and v2.
5. Traffic in each network is **generated from 10 nodes** (randomly-selected) and published in a round-robin fashion to **10 topics** (content topics for Waku v2).
In practice, we found no significant difference in _average_ bandwidth usage when tweaking these two parameters (the number of traffic generating nodes and the number of topics).
In practice, we found no significant difference in _average_ bandwidth usage when tweaking these two parameters (the number of traffic generating nodes and the number of topics).
6. Peers are connected in a decentralized **full mesh topology**,
i.e. each peer is connected to every other peer in the network.
Waku v1 is expected to flood all messages across all existing connections.
Waku v2 gossipsub will GRAFT some of these connections for full-message peerings,
with the rest being gossip-only peerings.
i.e. each peer is connected to every other peer in the network.
Waku v1 is expected to flood all messages across all existing connections.
Waku v2 gossipsub will GRAFT some of these connections for full-message peerings,
with the rest being gossip-only peerings.
7. After running each iteration, we **verify that messages propagated to all peers** (comparing the number of published messages to the metrics logged by each peer).
For Waku v1, nodes are configured as "full" nodes (i.e. with full bloom filter),
@@ -124,7 +124,6 @@ Bandwidth usage in Waku v2 has increased only slightly from the smaller network
This is because there are only a few more full-message peerings than before.
Compare this to the much higher increase in bandwidth usage for Waku v1, which now requires more than 4000 kbps on average.
### Iteration 3: 50 nodes
For an even larger network of 50 highly connected nodes,
@@ -151,7 +150,7 @@ The local Waku v2 simulation maintains the message throughput rate without any p
Finally, we simulate message propagation in a network of 150 nodes.
Due to local resource constraints, we run this simulation at a lower rate -
35 messages per second -
and for a shorter amount of time.
and for a shorter amount of time.
![](//img/waku1-vs-waku2/waku1-vs-waku2-150-nodes.png)
@@ -192,9 +191,9 @@ A similar traffic increase in Waku v2 requires on average 40kbps more bandwidth
## Conclusions
- **Waku v2 scales significantly better than Waku v1 in terms of average bandwidth usage**,
especially for densely connected networks.
especially for densely connected networks.
- E.g. for a network consisting of **150** or more densely connected nodes,
Waku v2 provides more than **10x** better average bandwidth usage rates than Waku v1.
Waku v2 provides more than **10x** better average bandwidth usage rates than Waku v1.
- As the network continues to scale, both in absolute terms (number of nodes) and in network traffic (message rates) the disparity between Waku v2 and Waku v1 becomes even larger.
## Future work
@@ -202,6 +201,7 @@ Waku v2 provides more than **10x** better average bandwidth usage rates than Wak
Now that we've confirmed that Waku v2's bandwidth improvements over its predecessor matches theory,
we can proceed to a more in-depth characterisation of Waku v2's resource usage.
Some questions that we want to answer include:
- What proportion of Waku v2's bandwidth usage is used to propagate _payload_ versus bandwidth spent on _control_ messaging to maintain the mesh?
- To what extent is message latency (time until a message is delivered to its destination) affected by network size and message rate?
- How _reliable_ is message delivery in Waku v2 for different network sizes and message rates?
@@ -218,4 +218,4 @@ and continually improve the efficiency of our suite of protocols.
- [GossipSub vs flood routing](https://hackmd.io/@vac/main/%2FYYlZYBCURFyO_ZG1EiteWg#11WAKU2-RELAY-gossipsub)
- [Network topologies: star](https://www.techopedia.com/definition/13335/star-topology#:~:text=Star%20topology%20is%20a%20network,known%20as%20a%20star%20network.)
- [Network topologies: mesh](https://en.wikipedia.org/wiki/Mesh_networking)
- [Waku v2 original plan](https://vac.dev/waku-v2-plan)
- [Waku v2 original plan](https://vac.dev/waku-v2-plan)

17
docs/2021-12-03-ethics-surveillance-tech.mdx → research/2021-12-03-ethics-surveillance-tech.mdx
View File

@@ -1,22 +1,22 @@
---
layout: post
name: "Opinion: Pseudo-ethics in the Surveillance Tech Industry"
title: "Opinion: Pseudo-ethics in the Surveillance Tech Industry"
date: 2021-12-03 10:00:00
author: circe
name: 'Opinion: Pseudo-ethics in the Surveillance Tech Industry'
title: 'Opinion: Pseudo-ethics in the Surveillance Tech Industry'
date: 2021-12-03 10:00:00
authors: circe
published: true
slug: ethics-surveillance-tech
categories: research
summary: A look at typical ethical shortfalls in the global surveillance tech industry.
summary:
image: /img/vac.png
discuss:
---
import { DocMetadata } from '@site/src/components/mdx'
A look at typical ethical shortfalls in the global surveillance tech industry.
<DocMetadata />
<!--truncate-->
_This is an opinion piece by pseudonymous contributor, circe._
_This is an opinion piece by pseudonymous contributor, circe._
## Preface
@@ -202,7 +202,6 @@ Targets of increasingly invasive governmental snooping are too often chosen prec
the consent of ordinary civilians.
Free and fair elections, free speech, free media, freedom of thought are all at risk.
## References
- [Status Principles](https://our.status.im/our-principles/)

39
docs/2022-04-12-introducing-nwaku.mdx → research/2022-04-12-introducing-nwaku.mdx
View File

@@ -1,22 +1,21 @@
---
layout: post
name: "Introducing nwaku"
title: "Introducing nwaku"
date: 2022-04-12 10:00:00
author: hanno
name: 'Introducing nwaku'
title: 'Introducing nwaku'
date: 2022-04-12 10:00:00
authors: hanno
published: true
slug: introducing-nwaku
categories: research
summary: Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.
image: /img/vac.png
discuss: https://forum.vac.dev/
toc_min_heading_level: 2
toc_max_heading_level: 5
---
import { DocMetadata } from '@site/src/components/mdx'
Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.
<DocMetadata />
<!--truncate-->
## Background
@@ -68,19 +67,19 @@ without any degradation in the services it provides.
Some of the more significant productionization efforts over the last couple of months included:
1. Reworking the `store` implementation to maintain stable memory usage
while storing historical messages
and serving multiple clients querying history simultaneously.
Previously, a `store` node would see gradual service degradation
due to inefficient memory usage when responding to history queries.
Queries that often took longer than 8 mins now complete in under 100 ms.
while storing historical messages
and serving multiple clients querying history simultaneously.
Previously, a `store` node would see gradual service degradation
due to inefficient memory usage when responding to history queries.
Queries that often took longer than 8 mins now complete in under 100 ms.
2. Improved peer management.
For example, `filter` nodes will now remove unreachable clients after a number of connection failures,
whereas they would previously keep accumulating dead peers.
For example, `filter` nodes will now remove unreachable clients after a number of connection failures,
whereas they would previously keep accumulating dead peers.
3. Improved disk usage.
`nwaku` nodes that persist historical messages on disk now manage their own storage size based on the `--store-capacity`.
This can significantly improve node start-up times.
`nwaku` nodes that persist historical messages on disk now manage their own storage size based on the `--store-capacity`.
This can significantly improve node start-up times.
More stability issues may be addressed in future as `nwaku` matures,
but we've noticed a marked improvement in the reliability of running `nwaku` nodes.
@@ -102,7 +101,7 @@ This allows direct connectivity with `js-waku`
and paves the way for native browser usage.
We've also added support for parsing and resolving DNS-type `multiaddrs`,
i.e. multiaddress protocol schemes [`dns`, `dns4`, `dns6` and `dnsaddr`](https://github.com/multiformats/multiaddr/blob/b746a7d014e825221cc3aea6e57a92d78419990f/protocols.csv#L8-L11).
A `nwaku` node can now also be [configured with its own IPv4 DNS domain name](https://github.com/status-im/nim-waku/tree/d2fccb5220144893f994a67f2cc26661247f101f/waku/v2#configuring-a-domain-name)
A `nwaku` node can now also be [configured with its own IPv4 DNS domain name](https://github.com/status-im/nim-waku/tree/d2fccb5220144893f994a67f2cc26661247f101f/waku/v2#configuring-a-domain-name)
allowing dynamic IP address allocation without impacting a node's reachability by its peers.
## 4. Peer discovery
@@ -164,10 +163,10 @@ We are targeting `nwaku` as the main option for operator-run nodes.
Specifically, we aim to provide through `nwaku`:
1. a lightweight and robust Waku v2 client.
This client must be first in line to support innovative and new Waku v2 protocols,
but configurable enough to serve the adaptive needs of various operators.
This client must be first in line to support innovative and new Waku v2 protocols,
but configurable enough to serve the adaptive needs of various operators.
2. an easy-to-follow guide for operators to configure,
set up and maintain their own nodes
set up and maintain their own nodes
3. a set of operator-focused tools to monitor and maintain a running node
### Better conversational security layer guarantees

80
docs/2022-05-09-ambient-peer-discovery.mdx → research/2022-05-09-ambient-peer-discovery.mdx
View File

@@ -1,34 +1,32 @@
---
layout: post
name: "Waku v2 Ambient Peer Discovery"
title: "Waku v2 Ambient Peer Discovery"
name: 'Waku v2 Ambient Peer Discovery'
title: 'Waku v2 Ambient Peer Discovery'
date: 2022-05-09 10:00:00
author: kaiserd
authors: kaiserd
published: true
slug: wakuv2-apd
categories: research
summary: Introducing and discussing ambient peer discovery methods currently used by Waku v2, as well as future plans in this area.
image: /img/waku_v2_discv5_random_walk_estimation.svg
discuss: https://forum.vac.dev/t/discussion-waku-v2-ambient-peer-discovery/133
_includes: [math]
---
import { DocMetadata } from '@site/src/components/mdx'
Introducing and discussing ambient peer discovery methods currently used by Waku v2, as well as future plans in this area.
<DocMetadata />
<!--truncate-->
[Waku v2](https://rfc.vac.dev/spec/10/) comprises a set of modular protocols for secure, privacy preserving communication.
Avoiding centralization, these protocols exchange messages over a P2P network layer.
In order to build a P2P network, participating nodes first have to discover peers within this network.
This is where [*ambient peer discovery*](https://docs.libp2p.io/concepts/publish-subscribe/#discovery) comes into play:
This is where [_ambient peer discovery_](https://docs.libp2p.io/concepts/publish-subscribe/#discovery) comes into play:
it allows nodes to find peers, making it an integral part of any decentralized application.
In this post the term *node* to refers to *our* endpoint or the endpoint that takes action,
while the term *peer* refers to other endpoints in the P2P network.
In this post the term _node_ to refers to _our_ endpoint or the endpoint that takes action,
while the term _peer_ refers to other endpoints in the P2P network.
These endpoints can be any device connected to the Internet: e.g. servers, PCs, notebooks, mobile devices, or applications like a browser.
As such, nodes and peers are the same. We use these terms for the ease of explanation without loss of generality.
In Waku's modular design, ambient peer discovery is an umbrella term for mechanisms that allow nodes to find peers.
Various ambient peer discovery mechanisms are supported, and each is specified as a separate protocol.
Where do these protocols fit into Waku's protocol stack?
@@ -40,8 +38,8 @@ Gossipsub implements many improvements overcoming the shortcomings typically ass
The gossipsub mesh network is managed in a decentralized way, which requires each node to know other participating peers.
Waku v2 may use any combination of its ambient discovery protocols to find appropriate peers.
Summarizing, Waku v2 comprises a *peer management layer* based on libp2p gossipsub,
which manages the peers of nodes, and an *ambient peer discovery layer*,
Summarizing, Waku v2 comprises a _peer management layer_ based on libp2p gossipsub,
which manages the peers of nodes, and an _ambient peer discovery layer_,
which provides information about peers to the peer management layer.
We focus on ambient peer discovery methods that are in line with our goal of building a fully decentralized, generalized, privacy-preserving and censorship-resistant messaging protocol.
@@ -69,7 +67,6 @@ Also, updating static peer information introduces significant administrative ove
code and/or config files have to be updated and released.
Typically, static node lists only hold a small number of bootstrap nodes, which may lead to high load on these nodes.
## DNS-based Discovery
Compared to static node lists,
@@ -84,7 +81,6 @@ However, changing and updating the list of bootstrap nodes still requires admini
While this method of discovery still requires centralized elements,
node list management can be delegated to various DNS zones managed by other entities mitigating centralization.
## Discovery V5
A much more dynamic method of ambient peer discovery is [Discovery v5](https://github.com/ethereum/devp2p/blob/6b0abc3d956a626c28dce1307ee9f546db17b6bd/discv5/discv5.md), which is Ethereum's peer discovery protocol.
@@ -97,7 +93,7 @@ Discv5 also offers mitigation techniques for various attacks, which we cover lat
Using a DHT (structured P2P network) as a means for ambient peer discovery, while using the gossipsub mesh network (unstructured P2P network) for transmitting actual messages,
Waku v2 leverages advantages from both worlds.
One of the main benefits of DHTs is offering a global view over participating nodes.
One of the main benefits of DHTs is offering a global view over participating nodes.
This, in turn, allows sampling random sets of nodes which is important for equally distributing load.
Gossipsub, on the other hand, offers great robustness and resilience against attacks.
Even if discv5 discovery should not work in advent of a DoS attack, Waku v2 can still operate switching to different discovery methods.
@@ -124,7 +120,7 @@ However, discv5 introduced various practical mitigation techniques.
### Random Walk Discovery
While discv5 is based on the Kademlia DHT, it only uses the *distributed node set* aspect of DHTs.
While discv5 is based on the Kademlia DHT, it only uses the _distributed node set_ aspect of DHTs.
It does not map values (items) into the distributed hash space.
This makes sense, because the main purpose of discv5 is discovering other nodes that support discv5, which are expected to be Ethereum nodes.
Ethereum nodes that want to discover other Ethereum nodes simply query the discv5 network for a random set of peers.
@@ -132,9 +128,9 @@ If Waku v2 would do the same, only a small subset of the retrieved nodes would s
A first naive solution for Waku v2 discv5 discovery is
* retrieve a random node set, which is achieved by querying for a set of randomly chosen node IDs
* filter the returned nodes on the query path based on Waku v2 capability via the [Waku v2 ENR](https://rfc.vac.dev/spec/31/)
* repeat until enough Waku v2 capable nodes are found
- retrieve a random node set, which is achieved by querying for a set of randomly chosen node IDs
- filter the returned nodes on the query path based on Waku v2 capability via the [Waku v2 ENR](https://rfc.vac.dev/spec/31/)
- repeat until enough Waku v2 capable nodes are found
This query process boils down to random walk discovery, which is very resilient against attacks, but also very inefficient if the number of nodes supporting the desired capability is small.
We refer to this as the needle-in-the-haystack problem.
@@ -145,19 +141,19 @@ This subsection provides a rough estimation of the overhead introduced by random
Given the following parameters:
* $n$ number of total nodes participating in discv5
* $p$ percentage of nodes supporting Waku
* $W$ the event of having at least one Waku node in a random sample
* $k$ the size of a random sample (default = 16)
* $\alpha$ the number of parallel queries started
* $b$ bits per hop
* $q$ the number of queries
- $n$ number of total nodes participating in discv5
- $p$ percentage of nodes supporting Waku
- $W$ the event of having at least one Waku node in a random sample
- $k$ the size of a random sample (default = 16)
- $\alpha$ the number of parallel queries started
- $b$ bits per hop
- $q$ the number of queries
A query takes $log_{2^b}n$ hops to retrieve a random sample of nodes.
$P(W) = 1 - (1-p/100)^k$ is the probability of having at least one Waku node in the sample.
$P(W^q) = 1 - (1-p/100)^{kq}$ is the probability of having at least one Waku node in the union of $q$ samples.
$P(W^q) = 1 - (1-p/100)^{kq}$ is the probability of having at least one Waku node in the union of $q$ samples.
Expressing this in terms of $q$, we can write:
$$P(W^q) = 1 - (1-p/100)^{kq} \iff q = log_{(1-p/100)^k}(1-P(W^q))$$
@@ -175,12 +171,11 @@ Choosing $b=3$ would reduce the number to $\approx 144 * 6 = 864$.
Even when choosing $\alpha = 10$ we would have to wait at least 80 RTTs.
This effort is just for retrieving a single Waku node. Ideally, we want at least 3 Waku nodes for bootstrapping a Waku relay.
[The discv5 doc](https://github.com/ethereum/devp2p/blob/6b0abc3d956a626c28dce1307ee9f546db17b6bd/discv5/discv5-theory.md#ad-placement-and-topic-radius) roughly estimates $p=1%$ to be the threshold for acceptably efficient random walk discovery.
[The discv5 doc](https://github.com/ethereum/devp2p/blob/6b0abc3d956a626c28dce1307ee9f546db17b6bd/discv5/discv5-theory.md#ad-placement-and-topic-radius) roughly estimates $p=1%$ to be the threshold for acceptably efficient random walk discovery.
This is in line with our estimation:
$$0.9 = 1 - (1-1/100)^{16q} => q \approx 14$$
The number of necessary queries is linearly dependent on the percentage $p$ of Waku nodes.
The number of hops per query is logarithmically dependent on $n$.
Thus, random walk searching is inefficient for small percentages $p$.
@@ -189,14 +184,12 @@ Still, random walks are more resilient against attacks.
We can conclude that a Waku node concentration below 1% renders vanilla discv5 unfit for our needs.
Our current solution and future plans for solving this issue are covered in the next subsections.
### Simple Solution: Separate Discovery Network
The simple solution we currently use for [Waku v2 discv5](https://rfc.vac.dev/spec/33/) is a separate discv5 network.
All (well behaving) nodes in this network support Waku v2, resulting in a very high query efficiency.
However, this solution reduces resilience because the difficulty of attacking a DHT scales with the number of participating nodes.
### Discv5 Topic Discovery
We did not base our solution on the [current version of discv5 topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement),
@@ -231,7 +224,7 @@ These attacks are mainly used for denial of service (DoS),
but can also used as parts of more sophisticated attacks, e.g. deanonymization attacks.
A future post on this research log will cover security aspects of ambient peer discovery with a focus on privacy and anonymity.
*Sybil Attack*
_Sybil Attack_
The power of an attacker in a DHT is proportional to the number of controlled nodes.
Controlling nodes comes at a high resource cost and/or requires controlling a botnet via a preliminary attack.
@@ -250,8 +243,7 @@ which, however, comes with a set of shortcomings, e.g. relatively high costs on
[The discv5 doc](https://github.com/ethereum/devp2p/blob/6b0abc3d956a626c28dce1307ee9f546db17b6bd/discv5/discv5-rationale.md#sybil-and-eclipse-attacks)
describes both Sybil and eclipse attacks, as well as concrete mitigation techniques employed by discv5.
*Eclipse Attack*
_Eclipse Attack_
In an eclipse attack, nodes controlled by the attacker poison the routing tables of other nodes in a way that parts of the DHT become eclipsed, i.e. invisible.
When a controlled node is asked for the next step in a path,
@@ -263,13 +255,12 @@ One mitigation technique is increasing $\alpha$, the number of parallel queries,
The eclipse attack becomes very powerful in combination with a successful Sybil attack;
especially when the attacker can freely choose the position of the Sybil nodes.
The aforementioned new topic discovery of discv5 provides a good balance between protection against eclipse attacks and query performance.
## Peer Exchange Protocol
While discv5 based ambient peer discovery has many desirable properties, resource restricted nodes and nodes behind restrictive NAT setups cannot run discv5 satisfactory.
With these nodes in mind, we started working on a simple *peer exchange protocol* based on ideas proposed [here](https://github.com/libp2p/specs/issues/222).
With these nodes in mind, we started working on a simple _peer exchange protocol_ based on ideas proposed [here](https://github.com/libp2p/specs/issues/222).
The peer exchange protocol will allow nodes to ask peers for additional peers.
Similar to discv5, the peer exchange protocol will also support capability discovery.
@@ -279,23 +270,20 @@ Rendezvous tends to introduce centralized elements as rendezvous peers have a su
In the future, we will investigate resource usage of [Waku v2 discv5](https://rfc.vac.dev/spec/33/) and provide suggestions for minimal resources nodes should have to run discv5 satisfactory.
## Further Protocols Related to Discovery
Waku v2 comprises further protocols related to ambient peer discovery. We shortly mention them for context, even though they are not strictly ambient peer discovery protocols.
### Gossipsub Peer Exchange Protocol
Gossipsub provides an integrated [peer exchange](https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/pubsub/gossipsub/gossipsub-v1.1.md#prune-backoff-and-peer-exchange) mechanism which is also supported by Waku v2.
Gossipsub peer exchange works in a *push* manner. Nodes send peer lists to peers they prune from the active mesh.
This pruning is part of the gossipsub peer management, blurring the boundaries of *peer management* and *ambient peer discovery*.
Gossipsub peer exchange works in a _push_ manner. Nodes send peer lists to peers they prune from the active mesh.
This pruning is part of the gossipsub peer management, blurring the boundaries of _peer management_ and _ambient peer discovery_.
We will investigate anonymity implications of this protocol and might disable it in favour of more anonymity-preserving protocols.
Sending a list of peers discloses information about the sending node.
We consider restricting these peer lists to cached peers that are currently not used in the active gossipsub mesh.
### Capability Negotiation
Some of the ambient peer discovery methods used by Waku2 will support capability discovery.
@@ -303,10 +291,10 @@ This allows to narrow down the set of retrieved peers to peers that support spec
This is efficient because it avoids establishing connections to nodes that we are not interested in.
However, the ambient discovery interface does not require capability discovery, which will lead to nodes having peers with unknown capabilities in their peer lists.
We work on a *capability negotiation protocol* which allows nodes to ask peers
We work on a _capability negotiation protocol_ which allows nodes to ask peers
* for their complete list of capabilities, and
* whether they support a specific capability
- for their complete list of capabilities, and
- whether they support a specific capability
We will investigate security implications, especially when sending full capability lists.
@@ -330,10 +318,9 @@ This is one of the nice resilience related properties of flooding based routing
For mobile nodes, which suffer from changing IP addresses and double NAT setups, we plan using the peer exchange protocol to ask peers for more peers.
Besides saving resources on resource restricted devices, this approach works as long as peers are in less restrictive environments.
## Conclusion and Future Prospects
*Ambient peer discovery* is an integral part of decentralized applications. It allows nodes to learn about peers in the network.
_Ambient peer discovery_ is an integral part of decentralized applications. It allows nodes to learn about peers in the network.
As of yet, Waku v2 supports DNS-based discovery and a slightly modified version of discv5.
We are working on further protocols, including a peer exchange protocol that allows resource restricted nodes to ask stronger peers for peer lists.
Further, we are working on adding capability discovery to our ambient discovery protocols, allowing nodes to find peers with desired properties.
@@ -377,4 +364,3 @@ To mitigate information leakage by transmitting peer lists, we plan to only repl
- [NAT-PMP](https://datatracker.ietf.org/doc/html/rfc6886)
- [PCP](https://datatracker.ietf.org/doc/html/rfc6887).
- [Discv5 topic efficiency issue](https://github.com/ethereum/devp2p/issues/199)

91
docs/2022-05-17-noise.mdx → research/2022-05-17-noise.mdx
View File

@@ -1,46 +1,45 @@
---
layout: post
name: "Noise handshakes as key-exchange mechanism for Waku"
title: "Noise handshakes as key-exchange mechanism for Waku"
name: 'Noise handshakes as key-exchange mechanism for Waku'
title: 'Noise handshakes as key-exchange mechanism for Waku'
date: 2022-05-17 10:00:00
author: s1fr0
authors: s1fr0
published: true
slug: wakuv2-noise
categories: research
summary: We provide an overview of the Noise Protocol Framework as a tool to design efficient and secure key-exchange mechanisms in Waku2.
summary:
image: /img/noise/NM.png
discuss: https://forum.vac.dev/t/discussion-noise-handshakes-as-key-exchange-mechanism-for-waku/137
_includes: [math]
---
import { DocMetadata } from '@site/src/components/mdx'
We provide an overview of the Noise Protocol Framework as a tool to design efficient and secure key-exchange mechanisms in Waku2.
<DocMetadata />
<!--truncate-->
## Introduction
In this post we will provide an overview of how [Waku v2](https://rfc.vac.dev/spec/10/) users can adopt [Noise handshakes](http://www.noiseprotocol.org/noise.html) to agree on cryptographic keys used to securely encrypt messages.
This process belongs to the class of _key-exchange_ mechanisms, consisting of all those protocols that, with different levels of complexity and security guarantees, allow two parties to publicly agree on a secret without letting anyone else know what this secret is.
But why do we need key-exchange mechanisms in the first place?
But why do we need key-exchange mechanisms in the first place?
With the advent of [public-key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography), it become possible to decouple encryption from decryption through use of two distinct cryptographic keys: one _public_, used to encrypt information and that can be made available to anyone, and one _private_ (kept secret), which enables decryption of messages encrypted with its corresponding public key. The same does not happen in the case of [symmetric encryption schemes](https://en.wikipedia.org/wiki/Symmetric-key_algorithm) where, instead, the same key is used for both encryption and decryption operations and hence cannot be publicly revealed as for public keys.
In order to address specific application needs, many different public, symmetric and hybrid cryptographic schemes were designed: [Waku v1](https://rfc.vac.dev/spec/6/) and [Waku v2](https://rfc.vac.dev/spec/10/), which inherits part of their design from the Ethereum messaging protocol [Whisper](https://ethereum.org/en/developers/docs/networking-layer/#whisper), provide [support](https://rfc.vac.dev/spec/26/) to both public-key primitives ([`ECIES`](https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme), [`ECDSA`](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)) and symmetric primitives ([`AES-256-GCM`](https://en.wikipedia.org/wiki/Galois/Counter_Mode), [`KECCAK-256`](https://en.wikipedia.org/wiki/SHA-3)), used to sign, hash, encrypt and decrypt exchanged messages.
In order to address specific application needs, many different public, symmetric and hybrid cryptographic schemes were designed: [Waku v1](https://rfc.vac.dev/spec/6/) and [Waku v2](https://rfc.vac.dev/spec/10/), which inherits part of their design from the Ethereum messaging protocol [Whisper](https://ethereum.org/en/developers/docs/networking-layer/#whisper), provide [support](https://rfc.vac.dev/spec/26/) to both public-key primitives ([`ECIES`](https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme), [`ECDSA`](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)) and symmetric primitives ([`AES-256-GCM`](https://en.wikipedia.org/wiki/Galois/Counter_Mode), [`KECCAK-256`](https://en.wikipedia.org/wiki/SHA-3)), used to sign, hash, encrypt and decrypt exchanged messages.
In principle, when communications employ public-key based encryption schemes (`ECIES`, in the case of Waku), there is no need for a key-agreement among parties: messages can be directly encrypted using the recipient's public-key before being sent over the network. However, public-key encryption and decryption primitives are usually very inefficient in processing large amount of data, and this may constitute a bottleneck for many of today's applications. Symmetric encryption schemes such as `AES-256-GCM`, on the other hand, are much more efficient, but the encryption/decryption key needs to be shared among users beforehand any encrypted messages is exchanged.
In principle, when communications employ public-key based encryption schemes (`ECIES`, in the case of Waku), there is no need for a key-agreement among parties: messages can be directly encrypted using the recipient's public-key before being sent over the network. However, public-key encryption and decryption primitives are usually very inefficient in processing large amount of data, and this may constitute a bottleneck for many of today's applications. Symmetric encryption schemes such as `AES-256-GCM`, on the other hand, are much more efficient, but the encryption/decryption key needs to be shared among users beforehand any encrypted messages is exchanged.
To counter the downsides given by each of these two approaches while taking advantage of their strengths, hybrid constructions were designed. In these, public-key primitives are employed to securely agree on a secret key which, in turn, is used with a symmetric cipher for encrypting messages. In other words, such constructions specify a (public-key based) key-agreement mechanism!
Waku, up to [payload version 1](https://rfc.vac.dev/spec/14/#payload-encryption), does not implement nor recommend any protocol for exchanging symmetric ciphers' keys, leaving such task to the application layer. It is important to note that the kind of key-agreement employed has a direct impact on the security properties that can be granted on later encrypted messages, while security requirements usually depend on the specific application for which encryption is needed in the first place.
In this regard, [Status](https://status.im), which builds on top of Waku, [implements](https://specs.status.im/spec/5) a custom version of the [X3DH](https://signal.org/docs/specifications/x3dh/) key-agreement protocol, in order to allow users to instantiate end-to-end encrypted communication channels. However, although such a solution is optimal when applied to (distributed) E2E encrypted chats, it is not flexible enough to fit or simplify the variety of applications Waku aims to address.
In this regard, [Status](https://status.im), which builds on top of Waku, [implements](https://specs.status.im/spec/5) a custom version of the [X3DH](https://signal.org/docs/specifications/x3dh/) key-agreement protocol, in order to allow users to instantiate end-to-end encrypted communication channels. However, although such a solution is optimal when applied to (distributed) E2E encrypted chats, it is not flexible enough to fit or simplify the variety of applications Waku aims to address.
Hence, proposing and implementing one or few key-agreements which provide certain (presumably _strong_) security guarantees, would inevitably degrade performances of all those applications for which, given their security requirements, more tailored and efficient key-exchange mechanisms can be employed.
Guided by different examples, in the following sections we will overview Noise, a protocol framework we are [currently integrating](https://rfc.vac.dev/spec/35/) in Waku, for building secure key-agreements between two parties. One of the great advantage of using Noise is that it is possible to add support to new key-exchanges by just specifying users' actions from a predefined list, requiring none to minimal modifications to existing implementations. Furthermore, Noise provides a framework to systematically analyze protocols' security properties and the corresponding attacker threat models. This allows not only to easily design new key-agreements eventually optimized for specific applications we want to address, but also to easily analyze or even [formally verify](https://noiseexplorer.com/) any of such custom protocol!
We believe that with its enormous flexibility and features, Noise represents a perfect candidate for bringing key-exchange mechanisms in Waku.
## The Diffie-Hellman Key-exchange
@@ -52,11 +51,11 @@ Diffie-Hellman (DH) key-exchange is largely used today and represents the main c
In turn, the security of DH is based on a mathematical problem called [discrete logarithm](https://en.wikipedia.org/wiki/Discrete_logarithm) which is believed to be hard when the agreement is practically instantiated using certain [elliptic curves](https://en.wikipedia.org/wiki/Elliptic_curve) $E$ defined over finite fields $\mathbb{F}_p$.
Informally, a DH exchange between Alice and Bob proceeds as follows:
- Alice picks a secret scalar $s_A\in\mathbb{F}_p$ and computes, using the underlying [curve's arithmetic](https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication), the point $P_A = s_A\cdot P\in E(\mathbb{F}_p)$ for a certain pre-agreed public generator $P$ of the elliptic curve $E(\mathbb{F}_p)$. She then sends $P_A$ to Bob.
- Similarly, Bob picks a secret scalar $s_B\in\mathbb{F}_p$, computes $P_B = s_B\cdot P\in E(\mathbb{F}_p)$ and sends $P_B$ to Alice.
- By commutativity of scalar multiplication, both Alice and Bob can now compute the point $P_{AB} = s_As_B\cdot P$, using the elliptic curve point received from the other party and their secret scalar.
The assumed hardness of computing discrete logarithms in the elliptic curve, ensures that it is not possible to compute $s_A$ or $s_B$ from $P_A$ and $P_B$, respectively. Another security assumption (named [Computational Diffie-Hellman assumption](https://en.wikipedia.org/wiki/Computational_Diffie%E2%80%93Hellman_assumption)) ensures that it is not possible to compute $P_{AB}$ from $P$, $P_A$ and $P_B$. Hence the point $P_{AB}$ shared by Alice and Bob at the end of the above protocol cannot be efficiently computed by an attacker intercepting $P_A$ and $P_B$, and can then be used to generate a secret to be later employed, for example, as a symmetric encryption key.
On a side note, this protocol shows the interplay between two components typical to public-key based schemes: the scalars $s_A$ and $s_B$ can be seen as _private keys_ associated to the _public keys_ $P_A$ and $P_B$, respectively, which allow Alice and Bob only to compute the shared secret point $P_{AB}$.
@@ -68,6 +67,7 @@ Although we assumed that it is practically impossible for an attacker to compute
To mitigate such issues, multiple DH operations can be combined using two different types of exchanged elliptic curve points or, better, _public keys_: _ephemeral keys_, that is random keys used only once in a DH operation, and long-term _static keys_, used mainly for authentication purposes since employed multiple times.
Just to provide an example, let us suppose Alice and Bob perform the following custom DH-based key-exchange protocol:
- Alice generates an ephemeral key $E_A=e_A\cdot P$ by picking a random scalar $e_A$ and sends $E_A$ to Bob;
- Similarly, Bob generates an ephemeral key $E_B=e_B\cdot P$ and sends $E_B$ to Alice;
- Alice and Bob computes $E_{AB} = e_Ae_B \cdot P$ and from it derive a secret encryption key $k$.
@@ -79,7 +79,7 @@ In this protocol, if Alice's and/or Bob's static keys get compromised, it would
## The Noise Protocol Framework
In previous section we gave a small intuition on how multiple DH operations over ephemeral and static users' public keys can be combined to create different key-exchange protocols.
In previous section we gave a small intuition on how multiple DH operations over ephemeral and static users' public keys can be combined to create different key-exchange protocols.
The [Noise Protocol Framework](http://www.noiseprotocol.org/noise.html), defines various rules for building custom key-exchange protocols while allowing easy analysis of the security properties and threat models provided given the type and order of the DH operations employed.
@@ -107,27 +107,30 @@ Two letters tokens, instead, denotes DH operations over the two users' public ke
Since, in order to perform any DH operations users need to share (or pre-share) the corresponding public keys, Noise compactly represents messages' exchanges using the two direction `->` and `<-`, where the `->` denotes a message (arbitrary and/or DH public key) from the initiator to the responder, while `<-` the opposite.
Hence a _message pattern_ consisting of a direction and one or multiple tokens such as `<- e, s, es` has to be interpreted one token at a time: in this example, the responder is sending his ephemeral and static key to the initiator and is then executing a DH operation over the initiator's ephemeral key `e` (shared in a previously exchanged message pattern) and his static key `s`. On the other hand, such message indicates also that the initiator received the responder's ephemeral and static keys `e` and `s`, respectively, and performed a DH operation over his ephemeral key and the responder's just received static key `s`. In this way, both parties will be able to derive at the end of each message pattern processed the same shared secret, which is eventually used to update any derived symmetric encryption keys computed so far.
Hence a _message pattern_ consisting of a direction and one or multiple tokens such as `<- e, s, es` has to be interpreted one token at a time: in this example, the responder is sending his ephemeral and static key to the initiator and is then executing a DH operation over the initiator's ephemeral key `e` (shared in a previously exchanged message pattern) and his static key `s`. On the other hand, such message indicates also that the initiator received the responder's ephemeral and static keys `e` and `s`, respectively, and performed a DH operation over his ephemeral key and the responder's just received static key `s`. In this way, both parties will be able to derive at the end of each message pattern processed the same shared secret, which is eventually used to update any derived symmetric encryption keys computed so far.
In some cases, DH public keys employed in a handshake are pre-shared before the handshake itself starts. In order to chronologically separate exchanged keys and DH operations performed before and during a handshake, Noise employs the `...` delimiter.
In some cases, DH public keys employed in a handshake are pre-shared before the handshake itself starts. In order to chronologically separate exchanged keys and DH operations performed before and during a handshake, Noise employs the `...` delimiter.
For example, the following message patterns
```
<- e
...
-> e, ee
```
indicates that the initiator knew the responder's ephemeral key before he sends his own ephemeral key and executes a DH operation between both parties ephemeral keys (similarly, the responder receives the initiator's ephemeral key and does a `ee` DH operation).
At this point it should be clear how such notation is able to compactly represent a large variety of DH based key-agreements. Nevertheless, we can easily define additional tokens and processing rules in order to address specific applications and security requirements, such as the [`psk`](http://www.noiseprotocol.org/noise.html#handshake-tokens) token used to process arbitrary pre-shared key material.
At this point it should be clear how such notation is able to compactly represent a large variety of DH based key-agreements. Nevertheless, we can easily define additional tokens and processing rules in order to address specific applications and security requirements, such as the [`psk`](http://www.noiseprotocol.org/noise.html#handshake-tokens) token used to process arbitrary pre-shared key material.
As an example of Noise flexibility, the custom protocol we detailed [above](#Ephemeral-and-Static-Public-Keys) can be shortly represented as _(Alice is on the left)_:
```
-> e
<- e, ee, s
-> s, ss
```
where after each DH operation an encryption key is derived (along with the secrets computed by all previously executed DH operations) in order to encrypt/decrypt any subsequent sent/received message.
Another example is given by the possibility to replicate within Noise the well established Signal's [X3DH](https://signal.org/docs/specifications/x3dh/) key-agreement protocols, thus making the latter a general framework to design and study security of many practical and widespread DH-based key-exchange protocols.
@@ -142,22 +145,20 @@ The Handshake State object stores the user's and other party's received ephemera
The Symmetric State, instead, stores a handshake hash value `h`, iteratively updated with any message read/received and DH secret computed, and a chaining key `ck`, updated using a key derivation function every time a DH secret is computed. This object further embeds a Cipher State.
Lastly, the Cipher State stores a symmetric encryption `k` key and a counter `n` used to encrypt and decrypt messages exchanged during the handshake (not only static keys, but also arbitrary payloads). These key and counter are refreshed every time the chaining key is updated.
Lastly, the Cipher State stores a symmetric encryption `k` key and a counter `n` used to encrypt and decrypt messages exchanged during the handshake (not only static keys, but also arbitrary payloads). These key and counter are refreshed every time the chaining key is updated.
While processing each handshake's message pattern token, all these objects are updated according to some specific _processing rules_ which employ a combination of public-key primitives, hash and key-derivation functions and symmetric ciphers. It is important to note, however, that at the end of each processed message pattern, the two users will share the same Symmetric and Cipher State embedded in their respective Handshake States.
Once a handshake is complete, users derive two new Cipher States and can then discard the Handshake State object (and, thus, the embedded Symmetric State and Cipher State objects)
employed during the handshake.
Once a handshake is complete, users derive two new Cipher States and can then discard the Handshake State object (and, thus, the embedded Symmetric State and Cipher State objects)
employed during the handshake.
These two Cipher states are used to encrypt and decrypt all outbound and inbound after-handshake messages, respectively, and only to these will be granted the confidentiality, authenticity, integrity and identity-hiding properties we detailed above.
For more details on processing rules, we refer to [Noise specifications](http://www.noiseprotocol.org/noise.html).
## Supported Noise Handshakes in Waku
The Noise handshakes we provided support to in Waku address four typical scenarios occurring when an encrypted communication channel between Alice and Bob is going to be created:
The Noise handshakes we provided support to in Waku address four typical scenarios occurring when an encrypted communication channel between Alice and Bob is going to be created:
- Alice and Bob know each others' static key.
- Alice knows Bob's static key;
@@ -170,14 +171,12 @@ Nonetheless, due to the pure _token-based_ nature of handshake processing rules,
On a side note, we already mentioned that identity-hiding properties can be guaranteed against a passive attacker that only reads the communication occurring between Alice and Bob. However, an active attacker who compromised one party's static key and actively interferes with the parties' exchanged messages, may lower the identity-hiding security guarantees provided by some handshake patterns. In our security model we exclude such adversary, but, for completeness, in the following we report a summary of possible de-anonymization attacks that can be performed by such an active attacker.
For more details on supported handshakes and on how these are implemented in Waku, we refer to [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/) RFC.
### The K1K1 Handshake
If Alice and Bob know each others' static key (e.g., these are public or were already exchanged in a previous handshake) , they MAY execute a `K1K1` handshake. In Noise notation *(Alice is on the left)* this can be sketched as:
If Alice and Bob know each others' static key (e.g., these are public or were already exchanged in a previous handshake) , they MAY execute a `K1K1` handshake. In Noise notation _(Alice is on the left)_ this can be sketched as:
```
K1K1:
-> s
@@ -187,6 +186,7 @@ If Alice and Bob know each others' static key (e.g., these are public or were al
<- e, ee, es
-> se
```
We note that here only ephemeral keys are exchanged. This handshake is useful in case Alice needs to instantiate a new separate encrypted communication channel with Bob, e.g. opening multiple parallel connections, file transfers, etc.
**Security considerations on identity-hiding (active attacker)**: no static key is transmitted, but an active attacker impersonating Alice can check candidates for Bob's static key.
@@ -196,6 +196,7 @@ We note that here only ephemeral keys are exchanged. This handshake is useful in
Here, Alice knows how to initiate a communication with Bob and she knows his public static key: such discovery can be achieved, for example, through a publicly accessible register of users' static keys, smart contracts, or through a previous public/private advertisement of Bob's static key.
A Noise handshake pattern that suits this scenario is `XK1`:
```
XK1:
<- s
@@ -204,24 +205,25 @@ A Noise handshake pattern that suits this scenario is `XK1`:
<- e, ee, es
-> s, se
```
Within this handshake, Alice and Bob reciprocally authenticate their static keys `s` using ephemeral keys `e`. We note that while Bob's static key is assumed to be known to Alice (and hence is not transmitted), Alice's static key is sent to Bob encrypted with a key derived from both parties ephemeral keys and Bob's static key.
**Security considerations on identity-hiding (active attacker)**: Alice's static key is encrypted with forward secrecy to an authenticated party. An active attacker initiating the handshake can check candidates for Bob's static key against recorded/accepted exchanged handshake messages.
### The XX and XXpsk0 Handshakes
If Alice is not aware of any static key belonging to Bob (and neither Bob knows anything about Alice), she can execute an `XX` handshake, where each party tran**X**mits to the other its own static key.
If Alice is not aware of any static key belonging to Bob (and neither Bob knows anything about Alice), she can execute an `XX` handshake, where each party tran**X**mits to the other its own static key.
The handshake goes as follows:
```
XX:
-> e
<- e, ee, s, es
-> s, se
```
We note that the main difference with `XK1` is that in second step Bob sends to Alice his own static key encrypted with a key obtained from an ephemeral-ephemeral Diffie-Hellman exchange.
We note that the main difference with `XK1` is that in second step Bob sends to Alice his own static key encrypted with a key obtained from an ephemeral-ephemeral Diffie-Hellman exchange.
This handshake can be slightly changed in case both Alice and Bob pre-shares some secret `psk` which can be used to strengthen their mutual authentication during the handshake execution. One of the resulting protocol, called `XXpsk0`, goes as follow:
@@ -231,8 +233,8 @@ This handshake can be slightly changed in case both Alice and Bob pre-shares som
<- e, ee, s, es
-> s, se
```
The main difference with `XX` is that Alice's and Bob's static keys, when transmitted, would be encrypted with a key derived from `psk` as well.
The main difference with `XX` is that Alice's and Bob's static keys, when transmitted, would be encrypted with a key derived from `psk` as well.
**Security considerations on identity-hiding (active attacker)**: Alice's static key is encrypted with forward secrecy to an authenticated party for both `XX` and `XXpsk0` handshakes. In `XX`, Bob's static key is encrypted with forward secrecy but is transmitted to a non-authenticated user which can then be an active attacker. In `XXpsk0`, instead, Bob's secret key is protected by forward secrecy to a partially authenticated party (through the pre-shared secret `psk` but not through any static key), provided that `psk` was not previously compromised (in such case identity-hiding properties provided by the `XX` handshake applies).
@@ -242,23 +244,21 @@ When two users complete a Noise handshake, an encryption/decryption session - or
By identifying Noise session with a `session-id` derived from the handshake's cryptographic material, we can take advantage of the [PubSub/GossipSub](https://github.com/libp2p/specs/tree/master/pubsub) protocols used by Waku for relaying messages in order to manage instantiated Noise sessions.
The core idea is to exchange after-handshake messages (encrypted with a Cipher State specific to the Noise session), over a content topic derived from the (secret) `session-id` the corresponding session refers to.
The core idea is to exchange after-handshake messages (encrypted with a Cipher State specific to the Noise session), over a content topic derived from the (secret) `session-id` the corresponding session refers to.
This allows to decouple the handshaking phase from the actual encrypted communication, thus improving users' identity-hiding capabilities.
This allows to decouple the handshaking phase from the actual encrypted communication, thus improving users' identity-hiding capabilities.
Furthermore, by publicly revealing a value derived from `session-id` on the corresponding session content topic, a Noise session can be marked as _stale_, enabling peers to save resources by discarding any eventually [stored](https://rfc.vac.dev/spec/13/) message sent to such content topic.
One relevant aspect in today's applications is the possibility for users to employ different devices in their communications. In some cases, this is non-trivial to achieve since, for example, encrypted messages might be required to be synced on different devices which do not necessarily share the necessary key material for decryption and may be temporarily offline.
One relevant aspect in today's applications is the possibility for users to employ different devices in their communications. In some cases, this is non-trivial to achieve since, for example, encrypted messages might be required to be synced on different devices which do not necessarily share the necessary key material for decryption and may be temporarily offline.
We address this by requiring each user's device to instantiate multiple Noise sessions either with all user's other devices which, in turn, all together share a Noise session with the other party, or by directly instantiating a Noise session with all other party's devices.
We address this by requiring each user's device to instantiate multiple Noise sessions either with all user's other devices which, in turn, all together share a Noise session with the other party, or by directly instantiating a Noise session with all other party's devices.
We named these two approaches $N11M$ and $NM$, respectively, which are in turn loosely based on the paper [“Multi-Device for Signal”](https://eprint.iacr.org/2019/1363.pdf) and [Signal’s Sesame Algorithm](https://signal.org/docs/specifications/sesame/).
![](//img/noise/N11M.png)
Informally, in the $N11M$ session management scheme, once the first Noise session between any of Alice’s and Bob’s device is instantiated, its session information is securely propagated to all other devices using previously instantiated Noise sessions. Hence, all devices are able to send and receive new messages on the content topic associated to such session.
Informally, in the $N11M$ session management scheme, once the first Noise session between any of Alice’s and Bob’s device is instantiated, its session information is securely propagated to all other devices using previously instantiated Noise sessions. Hence, all devices are able to send and receive new messages on the content topic associated to such session.
![](//img/noise/NM.png)
@@ -279,14 +279,15 @@ The possibility to manage Noise sessions over multiple devices and the fact that
## Future steps
The available [implementation](https://github.com/status-im/nwaku/tree/master/waku/v2/waku_noise) of Noise in `nwaku`, although mostly complete, is still in its testing phase. As future steps we would like to:
- have an extensively tested and robust Noise implementation;
- formalize, implement and test performances of the two proposed $N11M$ and $NM$ session management mechanisms and their suitability for common use-case scenarios;
- provide Waku network nodes a native protocol to readily support key-exchanges, strongly-encrypted communication and multi-device session management mechanisms with none-to-little interaction besides applications' connection requests.
## References
- [6/WAKU1](https://rfc.vac.dev/spec/6/)
- [10/WAKU2](https://rfc.vac.dev/spec/10/)
- [10/WAKU2](https://rfc.vac.dev/spec/10/)
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/)
- [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/)
- [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/)
@@ -306,8 +307,8 @@ The available [implementation](https://github.com/status-im/nwaku/tree/master/wa
- [The Discrete Logarithm Problem](https://en.wikipedia.org/wiki/Discrete_logarithm)
- [Computational Diffie-Hellman Assumption](https://en.wikipedia.org/wiki/Computational_Diffie%E2%80%93Hellman_assumption)
- [The ECIES Encryption Algorithm](https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme)
- [The ECDSA Signature Algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)
- [The Galois Counter Mode mode of operation](https://en.wikipedia.org/wiki/Galois/Counter_Mode)
- [The ECDSA Signature Algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)
- [The Galois Counter Mode mode of operation](https://en.wikipedia.org/wiki/Galois/Counter_Mode)
- [The ChaChaPoly AEAD Cipher](https://datatracker.ietf.org/doc/html/rfc7539)
- [The BLAKE2b Hash Function](https://datatracker.ietf.org/doc/html/rfc7693)
- [The SHA-3 Hash Function](https://en.wikipedia.org/wiki/SHA-3)
- [The SHA-3 Hash Function](https://en.wikipedia.org/wiki/SHA-3)

116
docs/2022-07-22-relay-anonymity.mdx → research/2022-07-22-relay-anonymity.mdx
View File

@@ -1,13 +1,12 @@
---
layout: post
name: "Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay"
title: "Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay"
name: 'Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay'
title: 'Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay'
date: 2022-07-22 10:00:00
author: kaiserd
authors: kaiserd
published: true
slug: wakuv2-relay-anon
categories: research
summary: Introducing a basic threat model and privacy/anonymity analysis for the Waku v2 relay protocol.
image: /img/anonymity_trilemma.svg
discuss: https://forum.vac.dev/t/discussion-waku-privacy-and-anonymity-analysis/149
_includes: [math]
@@ -16,9 +15,9 @@ toc_min_heading_level: 2
toc_max_heading_level: 5
---
import { DocMetadata } from '@site/src/components/mdx'
Introducing a basic threat model and privacy/anonymity analysis for the Waku v2 relay protocol.
<DocMetadata />
<!--truncate-->
[Waku v2](https://rfc.vac.dev/spec/10/) enables secure, privacy preserving communication using a set of modular P2P protocols.
Waku v2 also aims at protecting the user's anonymity.
@@ -43,11 +42,11 @@ The concepts of security, privacy, and anonymity are linked and have quite a bit
### Security
Of the three, [Security](https://en.wikipedia.org/wiki/Information_security) has the clearest agreed upon definition,
at least regarding its key concepts: *confidentiality*, *integrity*, and *availability*.
at least regarding its key concepts: _confidentiality_, _integrity_, and _availability_.
* confidentiality: data is not disclosed to unauthorized entities.
* integrity: data is not modified by unauthorized entities.
* availability: data is available, i.e. accessible by authorized entities.
- confidentiality: data is not disclosed to unauthorized entities.
- integrity: data is not modified by unauthorized entities.
- availability: data is available, i.e. accessible by authorized entities.
While these are the key concepts, the definition of information security has been extended over time including further concepts,
e.g. [authentication](https://en.wikipedia.org/wiki/Authentication) and [non-repudiation](https://en.wikipedia.org/wiki/Non-repudiation).
@@ -57,8 +56,8 @@ We might cover these in future posts.
Privacy allows users to choose which data and information
* they want to share
* and with whom they want to share it.
- they want to share
- and with whom they want to share it.
This includes data and information that is associated with and/or generated by users.
Protected data also comprises metadata that might be generated without users being aware of it.
@@ -78,23 +77,22 @@ They also provide good metadata protection properties.
However, we do not have a metadata protection analysis as of yet,
which is part of our privacy/anonymity roadmap.
### Anonymity
Privacy and anonymity are closely linked.
Both the identity of a user and data that allows inferring a user's identity should be part of the privacy policy.
For the purpose of analysis, we want to have a clearer separation between these concepts.
We define anonymity as *unlinkablity of users' identities and their shared data and/or actions*.
We define anonymity as _unlinkablity of users' identities and their shared data and/or actions_.
We subdivide anonymity into *receiver anonymity* and *sender anonymity*.
We subdivide anonymity into _receiver anonymity_ and _sender anonymity_.
#### Receiver Anonymity
We define receiver anonymity as *unlinkability of users' identities and the data they receive and/or related actions*.
We define receiver anonymity as _unlinkability of users' identities and the data they receive and/or related actions_.
The data transmitted via Waku relay must be a [Waku message](https://rfc.vac.dev/spec/14/), which contains a content topic field.
Because each message is associated with a content topic, and each receiver is interested in messages with specific content topics,
receiver anonymity in the context of Waku corresponds to *subscriber-topic unlinkability*.
receiver anonymity in the context of Waku corresponds to _subscriber-topic unlinkability_.
An example for the "action" part of our receiver anonymity definition is subscribing to a specific topic.
The Waku message's content topic is not related to the libp2p pubsub topic.
@@ -122,8 +120,8 @@ Similar to topic sharding, it would maintain receiver anonymity leveraging [part
#### Sender Anonymity
We define sender anonymity as *unlinkability of users' identities and the data they send and/or related actions*.
Because the data in the context of Waku is Waku messages, sender anonymity corresponds to *sender-message unlinkability*.
We define sender anonymity as _unlinkability of users' identities and the data they send and/or related actions_.
Because the data in the context of Waku is Waku messages, sender anonymity corresponds to _sender-message unlinkability_.
In summary, Waku offers weak sender anonymity because of [Waku's strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy),
which has its origins in the [Ethereum consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#why-are-we-using-the-strictnosign-signature-policy).
@@ -134,13 +132,13 @@ We will cover this in more detail in later sections.
### Anonymity Trilemma
[The Anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) states that only two out of *strong anonymity*, *low bandwidth*, and *low latency* can be guaranteed in the global on-net attacker model.
[The Anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) states that only two out of _strong anonymity_, _low bandwidth_, and _low latency_ can be guaranteed in the global on-net attacker model.
Waku's goal, being a modular set of protocols, is to offer any combination of two out of these three properties, as well as blends.
An example for blending is an adjustable number of pubsub topics and peers in the respective pubsub topic mesh; this allows tuning the trade-off between anonymity and bandwidth.
![Figure 2: Anonymity Trilemma: pick two. ](/img/anonymity_trilemma.svg)
A fourth factor that influences [the anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) is *frequency and patterns* of messages.
A fourth factor that influences [the anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) is _frequency and patterns_ of messages.
The more messages there are, and the more randomly distributed they are, the better the anonymity protection offered by a given anonymous communication protocol.
So, incentivising users to use the protocol, for instance by lowering entry barriers, helps protecting the anonymity of all users.
The frequency/patterns factor is also related to the above described k-anonymity.
@@ -269,7 +267,7 @@ Further, replay attacks will be punished by [RLN](https://rfc.vac.dev/spec/17/)
### Neighbourhood Surveillance
This attack can be performed by a single node attacker that is connected to all peers of the victim node $v$ with respect to a specific topic mesh.
This attack can be performed by a single node attacker that is connected to all peers of the victim node $v$ with respect to a specific topic mesh.
The attacker also has to be connected to $v$.
In this position, the attacker will receive messages $m_v$ sent by $v$ both on the direct path from $v$, and on indirect paths relayed by peers of $v$.
It will also receive messages $m_x$ that are not sent by $v$. These messages $m_x$ are relayed by both $v$ and the peers of $v$.
@@ -308,8 +306,8 @@ Combined with just a few nodes controlled by the attacker, the actual message as
An active single node attacker could run a disruption attack by
* (1) dropping messages that should be relayed
* (2) flooding neighbours with bogus messages
- (1) dropping messages that should be relayed
- (2) flooding neighbours with bogus messages
While (1) has a negative effect on availability, the impact is not significant.
A linearly scaling botnet attacker, however, could significantly disrupt the network with such an attack.
@@ -328,14 +326,14 @@ This also includes k-anonymity towards legitimate members of the same topic.
Waku v2 relay offers sender anonymity in the single node attacker model with its [strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy).
Currently, Waku v2 does not guarantee sender anonymity in the multi node and stronger attacker models.
However, we are working on modular anonymity-preserving protocols and building blocks as part of our privacy/anonymity roadmap.
The goal is to allow tunable anonymity with respect to trade offs between *strong anonymity*, *low bandwidth*, and *low latency*.
The goal is to allow tunable anonymity with respect to trade offs between _strong anonymity_, _low bandwidth_, and _low latency_.
All of these cannot be fully guaranteed as the [the anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) states.
Some applications have specific requirements, e.g. low latency, which require a compromise on anonymity.
Anonymity-preserving mechanisms we plan to investigate and eventually specify as pluggable anonymity protocols for Waku comprise
* [Dandelion++](https://arxiv.org/abs/1805.11060) for lightweight anonymity;
* [onion routing](https://en.wikipedia.org/wiki/Onion_routing) as a building block adding a low latency anonymization layer;
* [a mix network](https://en.wikipedia.org/wiki/Mix_network) for providing strong anonymity (on top of onion routing) even in the strongest attacker model at the cost of higher latency.
- [Dandelion++](https://arxiv.org/abs/1805.11060) for lightweight anonymity;
- [onion routing](https://en.wikipedia.org/wiki/Onion_routing) as a building block adding a low latency anonymization layer;
- [a mix network](https://en.wikipedia.org/wiki/Mix_network) for providing strong anonymity (on top of onion routing) even in the strongest attacker model at the cost of higher latency.
These pluggable anonymity-preserving protocols will form a sub-set of the Waku v2 protocol set.
As an intermediate step, we might directly employ Tor for onion-routing, and [Nym](https://nymtech.net/) as a mix-net layer.
@@ -343,42 +341,40 @@ As an intermediate step, we might directly employ Tor for onion-routing, and [Ny
In future research log posts, we will cover further Waku v2 protocols and identify anonymity problems that will be added to our roadmap.
These protocols comprise
* [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/), which can violate receiver anonymity as it allows filtering by content topic.
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/), which can violate receiver anonymity as it allows filtering by content topic.
A countermeasure is using the content topic exclusively for local filters.
* [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/), which discloses nodes' interest in topics;
* [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/), which also discloses nodes' interest in topics and links the lightpush client as the sender of a message to the lightpush service node;
* [21/WAKU2-FTSTORE](https://rfc.vac.dev/spec/21/), which discloses nodes' interest in specific time ranges allowing to infer information like online times.
- [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/), which discloses nodes' interest in topics;
- [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/), which also discloses nodes' interest in topics and links the lightpush client as the sender of a message to the lightpush service node;
- [21/WAKU2-FTSTORE](https://rfc.vac.dev/spec/21/), which discloses nodes' interest in specific time ranges allowing to infer information like online times.
While these protocols are not necessary for the operation of Waku v2, and can be seen as pluggable features,
we aim to provide alternatives without the cost of lowering the anonymity level.
## References
* [10/WAKU2](https://rfc.vac.dev/spec/10/)
* [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/)
* [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
* [Security](https://en.wikipedia.org/wiki/Information_security)
* [Authentication](https://en.wikipedia.org/wiki/Authentication)
* [Non-repudiation](https://en.wikipedia.org/wiki/Non-repudiation)
* [Noise Protocol Framework](https://noiseprotocol.org/)
* [plausible deniability](https://en.wikipedia.org/wiki/Plausible_deniability#Use_in_cryptography)
* [Waku v2 message](https://rfc.vac.dev/spec/14/)
* [partitioned topics](https://specs.status.im/spec/10#partitioned-topic)
* [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)
* [Dolev-Yao model](https://en.wikipedia.org/wiki/Dolev%E2%80%93Yao_model)
* [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/)
* [33/WAKU2-DISCV5](https://vac.dev/wakuv2-apd)
* [strict no sign policy](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#why-are-we-using-the-strictnosign-signature-policy)
* [Waku v2 strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy)
* [17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/)
* [anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
* [18/WAKU2-SWAP](https://rfc.vac.dev/spec/18/)
* [Pluggable Transports](https://www.pluggabletransports.info/about/)
* [Nym](https://nymtech.net/)
* [Dandelion++](https://arxiv.org/abs/1805.11060)
* [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/)
* [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/)
* [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/)
* [21/WAKU2-FTSTORE](https://rfc.vac.dev/spec/21/)
- [10/WAKU2](https://rfc.vac.dev/spec/10/)
- [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/)
- [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
- [Security](https://en.wikipedia.org/wiki/Information_security)
- [Authentication](https://en.wikipedia.org/wiki/Authentication)
- [Non-repudiation](https://en.wikipedia.org/wiki/Non-repudiation)
- [Noise Protocol Framework](https://noiseprotocol.org/)
- [plausible deniability](https://en.wikipedia.org/wiki/Plausible_deniability#Use_in_cryptography)
- [Waku v2 message](https://rfc.vac.dev/spec/14/)
- [partitioned topics](https://specs.status.im/spec/10#partitioned-topic)
- [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)
- [Dolev-Yao model](https://en.wikipedia.org/wiki/Dolev%E2%80%93Yao_model)
- [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/)
- [33/WAKU2-DISCV5](https://vac.dev/wakuv2-apd)
- [strict no sign policy](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#why-are-we-using-the-strictnosign-signature-policy)
- [Waku v2 strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy)
- [17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/)
- [anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
- [18/WAKU2-SWAP](https://rfc.vac.dev/spec/18/)
- [Pluggable Transports](https://www.pluggabletransports.info/about/)
- [Nym](https://nymtech.net/)
- [Dandelion++](https://arxiv.org/abs/1805.11060)
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/)
- [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/)
- [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/)
- [21/WAKU2-FTSTORE](https://rfc.vac.dev/spec/21/)

25
docs/2022-11-04-building-privacy-protecting-infrastructure.mdx → research/2022-11-04-building-privacy-protecting-infrastructure.mdx
View File

@@ -1,27 +1,26 @@
---
layout: post
name: "Building Privacy-Protecting Infrastructure"
title: "Building Privacy-Protecting Infrastructure"
date: 2022-11-04 12:00:00
author: oskarth
name: 'Building Privacy-Protecting Infrastructure'
title: 'Building Privacy-Protecting Infrastructure'
date: 2022-11-04 12:00:00
authors: oskarth
published: true
slug: building-privacy-protecting-infrastructure
categories: research
summary: What is privacy-protecting infrastructure? Why do we need it and how we can build it? We'll look at Waku, the communication layer for Web3. We'll see how it uses ZKPs to incentivize and protect the Waku network. We'll also look at Zerokit, a library that makes it easier to use ZKPs in different environments. After reading this, I hope you'll better understand the importance of privacy-protecting infrastructure and how we can build it.
image: /img/building_private_infra_intro.png
discuss: https://forum.vac.dev/t/discussion-building-privacy-protecting-infrastructure/161
---
import { DocMetadata } from '@site/src/components/mdx'
What is privacy-protecting infrastructure? Why do we need it and how we can build it? We'll look at Waku, the communication layer for Web3. We'll see how it uses ZKPs to incentivize and protect the Waku network. We'll also look at Zerokit, a library that makes it easier to use ZKPs in different environments. After reading this, I hope you'll better understand the importance of privacy-protecting infrastructure and how we can build it.
<DocMetadata />
<!--truncate-->
*This write-up is based on a talk given at DevCon 6 in Bogota, a video can be found [here](https://www.youtube.com/watch?v=CW1DYJifdhs)*
_This write-up is based on a talk given at DevCon 6 in Bogota, a video can be found [here](https://www.youtube.com/watch?v=CW1DYJifdhs)_
### Intro
In this write-up, we are going to talk about building privacy-protecting
infrastructure. What is it, why do we need it and how can we build it?
infrastructure. What is it, why do we need it and how can we build it?
We'll look at Waku, the communication layer for Web3. We'll look at how we are
using Zero Knowledge (ZK) technology to incentivize and protect the Waku
@@ -162,7 +161,7 @@ for and consumed.
![Adaptive Nodes](/img/building_private_infra_adaptive.png)
### Waku - protocol interactions
### Waku - protocol interactions
There are many protocols that interact. Waku Relay protocol is based on libp2p
GossipSub for p2p messaging. We have filter for bandwidth-restricted nodes to
@@ -308,7 +307,7 @@ also keeps track of relevant metadata and merkle tree. Metadata is needed to be
able to detect double signaling and perform slashing.
Before forwarding a message, it does some verification checks to ensure there
are no duplicate messages, ZKP is valid and no double signaling has occured. It
are no duplicate messages, ZKP is valid and no double signaling has occured. It
is worth noting that this can be combined with peer scoring, for example for
duplicate messages or invalid ZK proofs.
@@ -414,7 +413,7 @@ Waku is p2p infrastructure running in many different environments, such as
Nim/JS/Go/Rust, so this a requirement for us.
Circom and JS strengths are access to Dapp developers, tooling, generating
verification code, circuits etc. Rust strengths is that it is systems-based and
verification code, circuits etc. Rust strengths is that it is systems-based and
easy to interface with other language runtime such as Nim, Go, Rust, C. It also
gives access to other Rust ZK ecosystems such as arkworks. This opens door for
using other constructs, such as Halo2. This becomes especially relevant for
@@ -489,6 +488,6 @@ things mentioned in this article, and more, is available as
discussions on our [forum](forum.vac.dev/) or [Github](github.com/vacp2p/).
If you find any of this exciting to work on, feel free to reach out on our
Discord. We are also [hiring](https://jobs.status.im/), and we have started
Discord. We are also [hiring](https://jobs.status.im/), and we have started
expanding into other privacy infrastructure tech like private and provable
computation with ZK-WASM.

50
docs/2022-11-08-waku-for-all-decentralize-applications.mdx → research/2022-11-08-waku-for-all-decentralize-applications.mdx
View File

@@ -1,29 +1,26 @@
---
layout: post
name: "Waku for All Decentralized Applications and Infrastructures"
title: "Waku for All Decentralized Applications and Infrastructures"
name: 'Waku for All Decentralized Applications and Infrastructures'
title: 'Waku for All Decentralized Applications and Infrastructures'
date: 2022-11-08 00:00:00
author: franck
authors: franck
published: true
slug: waku-for-all
categories: waku, dapp, infrastructure, public good, platform, operator
summary: |
Waku is an open communication protocol and network. Decentralized apps and infrastructure can use Waku for their
communication needs. It is designed to enable dApps and decentralized infrastructure projects to have secure, private,
scalable communication. Waku is available in several languages and platforms, from Web to mobile to desktop to cloud.
Initially, We pushed Waku adoption to the Web ecosystem, we learned that Waku is usable in a variety of complex applications
and infrastructure projects. We have prioritized our effort to make Waku usable on various platforms and environments.
image: /img/black-waku-logo-with-name.png
discuss: https://forum.vac.dev/t/discussion-waku-for-all-decentralized-applications-and-infrastructures/163
---
import { DocMetadata } from '@site/src/components/mdx'
Waku is an open communication protocol and network. Decentralized apps and infrastructure can use Waku for their
communication needs. It is designed to enable dApps and decentralized infrastructure projects to have secure, private,
scalable communication. Waku is available in several languages and platforms, from Web to mobile to desktop to cloud.
Initially, We pushed Waku adoption to the Web ecosystem, we learned that Waku is usable in a variety of complex applications
and infrastructure projects. We have prioritized our effort to make Waku usable on various platforms and environments.
<DocMetadata />
<!--truncate-->
## Background
We have built Waku to be the communication layer for Web3. Waku is a collection of protocols to chose from for your
messaging needs. It enables secure, censorship-resistant, privacy-preserving, spam-protected communication for its user.
It is designed to run on any device, from mobile to the cloud.
@@ -39,7 +36,7 @@ for the adoption of Waku. This started back in 2021.
Waku is the communication component of the Web3 trifecta. This trifecta was Ethereum (contracts), Swarm
(storage) and Whisper (communication). Hence, it made sense to first target dApps which already uses one of the pillars:
Ethereum.
Ethereum.
As most dApps are web apps, we started the development of [js-waku for the browser](https://vac.dev/presenting-js-waku).
@@ -56,18 +53,21 @@ and [PoCs](https://github.com/status-iM/gnosis-safe-waku).
By discussing with Waku users and watching it being used, we learned a few facts:
1. The potential use cases for Waku are varied and many:
- Wallet &lt;&gt; dApp communication: [WalletConnect](https://medium.com/walletconnect/walletconnect-v2-0-protocol-whats-new-3243fa80d312), [XMTP](https://xmtp.org/docs/dev-concepts/architectural-overview/)
- Off-chain (and private) marketplace:
[RAILGUN](https://twitter.com/RAILGUN_Project/status/1556780629848727552?s=20&t=NEKQJiJAfg5WJqvuF-Ym_Q) &
[Decentralized Uber](https://twitter.com/TheBojda/status/1455557282318721026)
- Signature exchange for a multi-sign wallet: [Gnosis Safe x Waku](https://github.com/status-im/gnosis-safe-waku)
- Off-chain Game moves/actions: [Super Card Game (EthOnline 2021)](https://showcase.ethglobal.com/ethonline2021/super-card-game)
- Decentralized Pastebin: [Debin](https://debin.io/)
- Wallet &lt;&gt; dApp communication: [WalletConnect](https://medium.com/walletconnect/walletconnect-v2-0-protocol-whats-new-3243fa80d312), [XMTP](https://xmtp.org/docs/dev-concepts/architectural-overview/)
- Off-chain (and private) marketplace:
[RAILGUN](https://twitter.com/RAILGUN_Project/status/1556780629848727552?s=20&t=NEKQJiJAfg5WJqvuF-Ym_Q) &
[Decentralized Uber](https://twitter.com/TheBojda/status/1455557282318721026)
- Signature exchange for a multi-sign wallet: [Gnosis Safe x Waku](https://github.com/status-im/gnosis-safe-waku)
- Off-chain Game moves/actions: [Super Card Game (EthOnline 2021)](https://showcase.ethglobal.com/ethonline2021/super-card-game)
- Decentralized Pastebin: [Debin](https://debin.io/)
2. Many projects are interested in having an embedded chat in their dApp,
3. There are complex applications that need Waku as a solution. Taking RAILGUN as an example:
- Web wallet
- \+ React Native mobile wallet
- \+ NodeJS node/backend.
- Web wallet
- \+ React Native mobile wallet
- \+ NodeJS node/backend.
(1) means that it is not that easy to create SDKs for common use cases.
@@ -151,7 +151,7 @@ These two devices could be:
- Alice's phone and Bob's phone for any kind of secure communication,
- Mobile wallet and desktop/browser dApp for transaction and signature exchange.
Check [js-waku#950](https://github.com/waku-org/js-waku/issues/950) for the latest update on this.
Check [js-waku#950](https://github.com/waku-org/js-waku/issues/950) for the latest update on this.
## Get Involved
@@ -186,6 +186,6 @@ What you can expect next:
- \[1\] Waku is modular; it is a suite of protocols; hence some Waku protocols may be mature, while
new protocols are still being designed. Which means that research continues to be _ongoing_ while
Waku is already used in production.
Waku is already used in production.
- [[2]](https://community.optimism.io/docs/how-optimism-works/#block-production) The Optimism Foundation runs the only block produce on the Optimism network.
- [[3]](https://l2beat.com/) Top 10 L2s are documented has having a centralized operator.

16
docs/2023-04-03-waku-as-a-network.mdx → research/2023-04-03-waku-as-a-network.mdx
View File

@@ -1,21 +1,20 @@
---
layout: post
name: "The Future of Waku Network: Scaling, Incentivization, and Heterogeneity"
title: "The Future of Waku Network: Scaling, Incentivization, and Heterogeneity"
date: 2023-04-03 00:00:00
author: franck
name: 'The Future of Waku Network: Scaling, Incentivization, and Heterogeneity'
title: 'The Future of Waku Network: Scaling, Incentivization, and Heterogeneity'
date: 2023-04-03 00:00:00
authors: franck
published: true
slug: future-of-waku-network
categories: platform, operator, network
summary: Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.
image: /img/black-waku-logo-with-name.png
discuss: https://forum.vac.dev/t/discussion-the-future-of-waku-network-scaling-incentivization-and-heterogeneity/173
hide_table_of_contents: false
---
import { DocMetadata } from '@site/src/components/mdx'
# The Future of Waku Network: Scaling, Incentivization, and Heterogeneity
Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.
<DocMetadata />
<!--truncate-->
Waku is preparing for production with a focus on the Status Communities use case. In this blog post, we will provide an
overview of recent discussions and research outputs, aiming to give you a better understanding of how the Waku network
@@ -73,6 +72,7 @@ We anticipate witnessing various scenarios across the spectrum: from users shari
Another perspective is to consider whether the Waku network will resemble Ethereum or Cosmos.
For those not familiar with the difference between both, in a very concise manner:
- Ethereum is a set of protocols and software that are designed to operate on one common network and infrastructure
- Cosmos is a set of protocols and software (SDKs) designed to be deployed in separate yet interoperable networks and infrastructures by third parties

21
docs/2023-04-24-device-pairing-in-js-waku-and-go-waku.mdx → research/2023-04-24-device-pairing-in-js-waku-and-go-waku.mdx
View File

@@ -1,20 +1,17 @@
---
layout: post
name: "Device Pairing in Js-waku and Go-waku"
title: "Device Pairing in Js-waku and Go-waku"
date: 2023-04-24 12:00:00
author: rramos
name: 'Device Pairing in Js-waku and Go-waku'
title: 'Device Pairing in Js-waku and Go-waku'
date: 2023-04-24 12:00:00
authors: rramos
published: true
slug: device-pairing-in-js-waku-and-go-waku
categories: platform
summary: Device pairing and secure message exchange using Waku and noise protocol
---
import { DocMetadata } from '@site/src/components/mdx'
Device pairing and secure message exchange using Waku and noise protocol.
# Device Pairing in Js-waku and Go-waku
<DocMetadata />
<!--truncate-->
As the world becomes increasingly connected through the internet, the need for secure and reliable communication becomes paramount. In [this article](https://vac.dev/wakuv2-noise) it is described how the Noise protocol can be used as a key-exchange mechanism for Waku.
@@ -26,7 +23,7 @@ One of the key benefits of using Noise is that it provides end-to-end encryption
### Device Pairing
In today's digital world, device pairing has become an integral part of our lives. Whether it's connecting our smartphones with other computers or web applications, the need for secure device pairing has become more crucial than ever. With the increasing threat of cyber-attacks and data breaches, it's essential to implement secure protocols for device pairing to ensure data privacy and prevent unauthorized access.
In today's digital world, device pairing has become an integral part of our lives. Whether it's connecting our smartphones with other computers or web applications, the need for secure device pairing has become more crucial than ever. With the increasing threat of cyber-attacks and data breaches, it's essential to implement secure protocols for device pairing to ensure data privacy and prevent unauthorized access.
To demonstrate how device pairing can be achieved using Waku and Noise, we have examples available at https://examples.waku.org/noise-js/. You can try pairing different devices, such as mobile and desktop, via a web application. This can be done by scanning a QR code or opening a URL that contains the necessary data for a secure handshake.
@@ -45,13 +42,15 @@ Actors:
The above example demonstrates device pairing using js-waku. Additionally, You can also try building and experimenting with other noise implementations like nwaku, or go-waku, with an example available at https://github.com/waku-org/go-waku/tree/master/examples/noise in which the same flow described before is done with Bob (the receiver) using go-waku instead of js-waku.
### Conclusion
With its easy to use API built on top of the Noise Protocol framework and the LibP2P networking stack, if you are a developer looking to implement secure messaging in their applications that are both decentralized and censorship resistant, Waku is definitely an excellent choice worth checking out!
Waku is also Open source with a MIT and APACHEv2 licenses, which means that developers are encouraged to contribute code, report bugs, and suggest improvements to make it even better.
Don't hesitate to try the live example at https://examples.waku.org/noise-js and build your own webapp using https://github.com/waku-org/js-noise, https://github.com/waku-org/js-waku and https://github.com/waku-org/go-waku. This will give you a hands-on experience of implementing secure communication protocols using the Noise Protocol framework in a practical setting. Happy coding!
Don't hesitate to try the live example at https://examples.waku.org/noise-js and build your own webapp using https://github.com/waku-org/js-noise, https://github.com/waku-org/js-waku and https://github.com/waku-org/go-waku. This will give you a hands-on experience of implementing secure communication protocols using the Noise Protocol framework in a practical setting. Happy coding!
### References
- [Noise handshakes as key-exchange mechanism for Waku](https://vac.dev/wakuv2-noise)
- [Noise Protocols for Waku Payload Encryption](https://rfc.vac.dev/spec/35/)
- [Session Management for Waku Noise](https://rfc.vac.dev/spec/37/)

44
research/authors.yml Normal file
View File

@@ -0,0 +1,44 @@
circe:
name: 'Circe'
twitter: 'vacp2p'
github: 'thecirce'
dean:
name: 'Dean'
twitter: 'DeanEigenmann'
github: 'decanus'
website: 'https://dean.eigenmann.me'
franck:
name: 'Franck'
twitter: 'fryorcraken'
github: 'fryorcraken'
hanno:
name: 'Hanno Cornelius'
twitter: '4aelius'
github: 'jm-clius'
kaiserd:
name: 'Daniel'
github: 'kaiserd'
oskarth:
name: 'Oskar'
twitter: 'oskarth'
github: 'oskarth'
rramos:
name: 'Richard'
twitter: 'richardramos_me'
github: 'richard-ramos'
website: 'https://richard-ramos.github.io/'
s1fr0:
name: 's1fr0'
github: 's1fr0'
sanaz:
name: 'Sanaz'
twitter: 'sanaz2016'
github: 'staheri14'

28
yarn.lock
View File

@@ -2,13 +2,13 @@
# yarn lockfile v1
"@acid-info/logos-docusaurus-preset@^1.0.0-alpha.34":
version "1.0.0-alpha.34"
resolved "https://registry.yarnpkg.com/@acid-info/logos-docusaurus-preset/-/logos-docusaurus-preset-1.0.0-alpha.34.tgz#714aa2f0de27ad285d3b1655bf9e9e8e924aadc9"
integrity sha512-P15D3v8hc1+wVpvR1pgFo4Kz7pFlE3hJtTC+XeSE6hCITNeIkyNkVhbNF+Q4YP/ODbSSjnCHw0qtQg8aTR4+8Q==
"@acid-info/logos-docusaurus-preset@^1.0.0-alpha.44":
version "1.0.0-alpha.44"
resolved "https://registry.yarnpkg.com/@acid-info/logos-docusaurus-preset/-/logos-docusaurus-preset-1.0.0-alpha.44.tgz#989dfc7d691565c3d6cfdc1c97b2703938df1f24"
integrity sha512-3xXVln6L9tq7wA3FJuQMRTVPJ23v7bqzVwKMI9WKeTa83ieVXCarC152vQVyBpPzTfQdtEttnuFCFI5lWoKTaw==
dependencies:
"@acid-info/logos-docusaurus-search-local" "^1.0.0-alpha.19"
"@acid-info/logos-docusaurus-theme" "^1.0.0-alpha.34"
"@acid-info/logos-docusaurus-theme" "^1.0.0-alpha.44"
"@docusaurus/core" "^2.4.1"
"@docusaurus/module-type-aliases" "^2.4.1"
"@docusaurus/preset-classic" "^2.4.1"
@@ -34,12 +34,12 @@
"@easyops-cn/docusaurus-search-local" "^0.33.6"
lodash "^4.17.21"
"@acid-info/logos-docusaurus-theme@^1.0.0-alpha.34":
version "1.0.0-alpha.34"
resolved "https://registry.yarnpkg.com/@acid-info/logos-docusaurus-theme/-/logos-docusaurus-theme-1.0.0-alpha.34.tgz#b8c78266139435892053bb5e848465bf6d97707a"
integrity sha512-Poe4y4mNjKwUWODl7O1fAUgFYq8fbbSNPnfMfu/zBi6cLn40ksZAWaJPGueDbrePRkK2bKEMMgad8qj1YZnTHw==
"@acid-info/logos-docusaurus-theme@^1.0.0-alpha.44":
version "1.0.0-alpha.44"
resolved "https://registry.yarnpkg.com/@acid-info/logos-docusaurus-theme/-/logos-docusaurus-theme-1.0.0-alpha.44.tgz#3fb99ad050de29de8ed475143e2c7a7c04f233e9"
integrity sha512-nohxT0FwUpVzSt0Uu6q2KZvo+R8ye45useR7squ+7A9Z9BFmij+Xl4frT1b2lI8GLSa4ULHbdcY7EblZUjoJ6w==
dependencies:
"@acid-info/lsd-react" "^0.1.0-alpha.13"
"@acid-info/lsd-react" "^0.1.0-alpha.15"
"@docusaurus/core" "^2.4.1"
"@docusaurus/mdx-loader" "^2.4.1"
"@docusaurus/module-type-aliases" "^2.4.1"
@@ -74,10 +74,10 @@
three-stdlib "^2.23.4"
utility-types "^3.10.0"
"@acid-info/lsd-react@^0.1.0-alpha.13":
version "0.1.0-alpha.13"
resolved "https://registry.yarnpkg.com/@acid-info/lsd-react/-/lsd-react-0.1.0-alpha.13.tgz#83a947aef6bf0597bb94389382bce72eda9d262e"
integrity sha512-bEtCygGvEabxr7a/0s2n9LLbs7RUY5YXFIEzxKeDH52UNhzLODY6hpOELWfpDxfd2Q0yxnMKSaG+yI7/FqjnlA==
"@acid-info/lsd-react@^0.1.0-alpha.15":
version "0.1.0-alpha.16"
resolved "https://registry.yarnpkg.com/@acid-info/lsd-react/-/lsd-react-0.1.0-alpha.16.tgz#cf635df44bc6ec63990d16fee38908d646a47701"
integrity sha512-U91Hp3Km/tAeExsMhAJvsocg37wImXlNN4Xo4R+lVJD3oTTF0cTLsB+32IbyimqELyXluUv2gwsyo2nHtEcY4Q==
dependencies:
"@emotion/react" "^11.10.5"
"@emotion/styled" "^11.10.5"