mirror of
https://github.com/vacp2p/vac.dev.git
synced 2026-01-05 04:44:49 -05:00
feat: upgrade docusaurus version to v3
This commit is contained in:
jinhojang6
@@ -10,8 +10,8 @@ You can use [Frontmatter](https://docusaurus.io/docs/markdown-features#front-mat
|
||||
|
||||
## CI/CD
|
||||
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/vac.dev/) `master` and pushes to `deploy-master` branch, which is hosted at <https://vac.dev//>.
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/dev.vac.dev/) `develop` and pushes to `deploy-develop` branch, which is hosted at <https://dev.vac.dev//>.
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/vac.dev/) `master` and pushes to `deploy-master` branch, which is hosted at https://vac.dev/.
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/dev.vac.dev/) `develop` and pushes to `deploy-develop` branch, which is hosted at https://dev.vac.dev/.
|
||||
|
||||
The hosting is done using [Caddy server with Git plugin for handling GitHub webhooks](https://github.com/status-im/infra-misc/blob/master/ansible/roles/caddy-git).
|
||||
|
||||
|
||||
@@ -12,9 +12,7 @@ import { Grid, Box, SocialCard } from '/src/components/mdx'
|
||||
# Join the community
|
||||
|
||||
<Box bottom={24}>
|
||||
Join the Vac Community!
|
||||
<br/>
|
||||
<br/>
|
||||
Join the Vac Community!<br/>
|
||||
Keep up to date with our latest research by connecting with us on our communities channels.
|
||||
</Box>
|
||||
|
||||
|
||||
@@ -163,10 +163,10 @@ const config = {
|
||||
|
||||
stylesheets: [
|
||||
{
|
||||
href: 'https://cdn.jsdelivr.net/npm/katex@0.13.24/dist/katex.min.css',
|
||||
href: 'https://cdn.jsdelivr.net/npm/katex@0.16.4/dist/katex.min.css',
|
||||
type: 'text/css',
|
||||
integrity:
|
||||
'sha384-odtC+0UGzzFL/6PNoE8rX/SPcQDXBJ+uRepguP4QkPCm2LBxH3FA3y+fKSiJ+AmM',
|
||||
'sha384-vZTG03m+z5ZkWZJgN+5RqqznB0TjvHahcGq1+EK7Y5xnepK84VHe5F4I9xgDnUHg',
|
||||
crossorigin: 'anonymous',
|
||||
},
|
||||
],
|
||||
|
||||
23
package.json
23
package.json
@@ -15,28 +15,25 @@
|
||||
"typecheck": "tsc"
|
||||
},
|
||||
"dependencies": {
|
||||
"@acid-info/logos-docusaurus-preset": "^1.0.0-alpha.199",
|
||||
"@docusaurus/core": "2.4.1",
|
||||
"@docusaurus/plugin-client-redirects": "^2.4.1",
|
||||
"@docusaurus/preset-classic": "2.4.1",
|
||||
"@docusaurus/theme-mermaid": "^2.4.1",
|
||||
"@acid-info/logos-docusaurus-preset": "^1.0.2-alpha.2",
|
||||
"@docusaurus/plugin-client-redirects": "^3.7.0",
|
||||
"@emotion/react": "^11.11.0",
|
||||
"@emotion/styled": "^11.11.0",
|
||||
"@mdx-js/react": "^1.6.22",
|
||||
"@mdx-js/react": "^3.0.0",
|
||||
"clsx": "^1.2.1",
|
||||
"dotenv": "^16.0.3",
|
||||
"hast-util-is-element": "1.1.0",
|
||||
"katex": "^0.16.22",
|
||||
"prism-react-renderer": "^1.3.5",
|
||||
"react": "^17.0.2",
|
||||
"react-dom": "^17.0.2",
|
||||
"rehype-katex": "5",
|
||||
"remark-math": "3",
|
||||
"sass": "^1.62.1",
|
||||
"tsdx": "^0.14.1"
|
||||
"react": "^19.0.0",
|
||||
"react-dom": "^19.0.0",
|
||||
"rehype-katex": "^7.0.1",
|
||||
"remark-math": "^6.0.0",
|
||||
"sass": "^1.62.1"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@docusaurus/module-type-aliases": "2.4.1",
|
||||
"@tsconfig/docusaurus": "^1.0.5",
|
||||
"@docusaurus/tsconfig": "^3.7.0",
|
||||
"typescript": "^4.7.4"
|
||||
},
|
||||
"browserslist": {
|
||||
|
||||
@@ -13,7 +13,7 @@ toc_max_heading_level: 5
|
||||
|
||||
A research log. Reliable and decentralized, pick two.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
Together with decanus, I've been working on the problem of data sync lately.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ categories: research
|
||||
|
||||
Vac is a modular peer-to-peer messaging stack, with a focus on secure messaging. Overview of terms, stack and open problems.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ image: /img/remote-log.png
|
||||
|
||||
A research log. Asynchronous P2P messaging? Remote logs to the rescue!
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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).
|
||||
|
||||
@@ -35,7 +35,7 @@ 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
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ toc_max_heading_level: 5
|
||||
|
||||
A research log. Zero knowledge signaling as a rate limiting mechanism to prevent spam in p2p networks.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.**
|
||||
|
||||
@@ -90,7 +90,7 @@ The above repo was used to exercise the basic paths and to gain intution of feas
|
||||
|
||||
#### Proof time
|
||||
|
||||
Prove time for Semaphore (<https://github.com/kobigurk/semaphore>) zKSNARKs using circom, groth and snarkjs is currently way too long. It takes on the order of ~10m to generate a proof. With Websnark, it is likely to take 30s, which might still be too long. We should experiment with native code on mobile here.
|
||||
Prove time for Semaphore (https://github.com/kobigurk/semaphore) zKSNARKs using circom, groth and snarkjs is currently way too long. It takes on the order of ~10m to generate a proof. With Websnark, it is likely to take 30s, which might still be too long. We should experiment with native code on mobile here.
|
||||
|
||||
See [details](https://github.com/vacp2p/research/issues/7).
|
||||
|
||||
@@ -150,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).\_
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/discussion-fixing-whisper-with-waku/27
|
||||
|
||||
A research log. Why Whisper doesn't scale and how to fix it.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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
|
||||
@@ -239,9 +239,9 @@ for more detail on the model and its assumptions.
|
||||
The results are summarized in the graph above. Notice the log-log scale. The
|
||||
colored backgrounds correspond to the following bandwidth usage:
|
||||
|
||||
- Blue: <10mb/d (<~300mb/month)
|
||||
- Green: <30mb/d (<~1gb/month)
|
||||
- Yellow: <100mb/d (<~3gb/month)
|
||||
- Blue: 10mb/d (~300mb/month)
|
||||
- Green: 30mb/d (~1gb/month)
|
||||
- Yellow: 100mb/d (~3gb/month)
|
||||
- Red: >100mb/d (>3gb/month)
|
||||
|
||||
These ranges are somewhat arbitrary, but are based on [user
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/waku-update-where-are-we-at/34
|
||||
|
||||
A research log. What's the current state of Waku? How many users does it support? What are the bottlenecks? What's next?
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ categories: research
|
||||
|
||||
A look at EIP-1459 and the benefits of DNS based discovery.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/discussion-what-would-a-wechat-replacement-need
|
||||
|
||||
What would a self-sovereign, private, censorship-resistant and open alternative to WeChat look like?
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ discuss: https://discuss.status.im/t/discv5-feasibility-study/1632
|
||||
|
||||
Looking at discv5 and the theoretical numbers behind finding peers.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ categories: research
|
||||
|
||||
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.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/waku-version-2-pitch/52
|
||||
|
||||
Read about our plans for Waku v2, moving to libp2p, better routing, adaptive nodes and accounting!
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
**tldr: The Waku network is fragile and doesn't scale. Here's how to solve it.**
|
||||
|
||||
@@ -44,7 +44,7 @@ Figure 1-5:
|
||||
|
||||
|
||||
|
||||
See <https://colab.research.google.com/drive/1Fz-oxRxxAFPpM1Cowpnb0nT52V1-yeRu#scrollTo=Yc3417FUJJ_0> for the full report.
|
||||
See https://colab.research.google.com/drive/1Fz-oxRxxAFPpM1Cowpnb0nT52V1-yeRu#scrollTo=Yc3417FUJJ_0 for the full report.
|
||||
|
||||
What we need to do is:
|
||||
|
||||
@@ -88,7 +88,7 @@ Here's where we are at now. In reality, the amplification factor are likely even
|
||||
|
||||
Moving to PubSub over libp2p wouldn't improve amplification per se, but it would be stepping stone. Why? It paves the way for GossipSub, and would be a checkpoint on this journey. Additionally, FloodSub and GossipSub are compatible, and very likely other future forms of PubSub such as GossipSub 1.1 (hardened/more secure), EpiSub, forwarding Kademlia / PubSub over Kademlia, etc. Not to mention security This would also give us access to the larger libp2p ecosystem (multiple protocols, better encryption, quic, running in the browser, security audits, etc, etc), as well as be a joint piece of infrastructured used for Eth2 in Nimbus. More wood behind fewer arrows.
|
||||
|
||||
See more on libp2p PubSub here: <https://docs.libp2p.io/concepts/publish-subscribe/>
|
||||
See more on libp2p PubSub here: https://docs.libp2p.io/concepts/publish-subscribe/
|
||||
|
||||
As part of this move, there are a few individual pieces that are needed.
|
||||
|
||||
@@ -104,11 +104,11 @@ Why can't we use Waku topics for routing directly? PubSub over libp2p isn't buil
|
||||
|
||||
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>
|
||||
Very experimental and incomplete libp2p support can be found in the nim-waku repo under v2: https://github.com/status-im/nim-waku
|
||||
|
||||
### 2. Simplify the protocol
|
||||
|
||||
Due to Waku's origins in Whisper, devp2p and as a standalone protocol, there are a lot of stuff that has accumulated (<https://rfc.vac.dev/waku/standards/legacy/6/waku1/>). Not all of it serves it purpose anymore. For example, do we still need RLP here when we have Protobuf messages? What about extremely low PoW when we have peer scoring? What about key management / encryption when have encryption at libp2p and Status protocol level?
|
||||
Due to Waku's origins in Whisper, devp2p and as a standalone protocol, there are a lot of stuff that has accumulated (https://rfc.vac.dev/waku/standards/legacy/6/waku1/). Not all of it serves it purpose anymore. For example, do we still need RLP here when we have Protobuf messages? What about extremely low PoW when we have peer scoring? What about key management / encryption when have encryption at libp2p and Status protocol level?
|
||||
|
||||
Not everything has to be done in one go, but being minimalist at this stage will the protocol lean and make us more adaptable.
|
||||
|
||||
@@ -120,7 +120,7 @@ As early as possible we want to integrate with Core via Stimbus in order to miti
|
||||
|
||||
### 4. Topic interest behavior
|
||||
|
||||
While we target full node traffic here, we want to make sure we maintain the existing bandwidth requirements for light nodes that Waku v1 addressed (<https://vac.dev/fixing-whisper-with-waku>). This means implementing topic-interest in the form of Waku topics. Note that this would be separate from app topics notes above.
|
||||
While we target full node traffic here, we want to make sure we maintain the existing bandwidth requirements for light nodes that Waku v1 addressed (https://vac.dev/fixing-whisper-with-waku). This means implementing topic-interest in the form of Waku topics. Note that this would be separate from app topics notes above.
|
||||
|
||||
### 5. Historical message caching
|
||||
|
||||
@@ -128,7 +128,7 @@ Basically what mailservers are currently doing. This likely looks slightly diffe
|
||||
|
||||
Also see section below on adaptive nodes and capabilities.
|
||||
|
||||
### 6. Waku v1 <\> Libp2p bridge
|
||||
### 6. Waku v1 `<\>` Libp2p bridge
|
||||
|
||||
To make the transition complete, there has to a be bridge mode between current Waku and libp2p. This is similar to what was done for Whisper and Waku, and allows any nodes in the network to upgrade to Waku v2 at their leisure. For example, this would likely look different for Core, Desktop, Research and developers.
|
||||
|
||||
@@ -140,7 +140,7 @@ This is where we improve the amplification factors.
|
||||
|
||||
This is a subprotocol of FloodSub in the libp2p world. Moving to GossipSub would allow traffic between full nodes to go from an amplification factor of ~25 to ~6. This basically creates a mesh of stable bidirectional connections, together with some gossiping capabilities outside of this view.
|
||||
|
||||
Explaining how GossipSub works is out of scope of this document. It is implemented in nim-libp2p and used by Nimbus as part of Eth2. You can read the specs here in more detail if you are interested: <https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md> and <https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md>
|
||||
Explaining how GossipSub works is out of scope of this document. It is implemented in nim-libp2p and used by Nimbus as part of Eth2. You can read the specs here in more detail if you are interested: https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md and https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md
|
||||
|
||||
|
||||
|
||||
@@ -160,7 +160,7 @@ This one is slightly more speculative in terms of its ultimate impact. The basic
|
||||
|
||||
|
||||
|
||||
Note that this means a light node that listens to several topics would have to be connected to more full nodes to get connectivity. For a more exotic version of this, see <https://forum.vac.dev/t/rfc-topic-propagation-extension-to-libp2p-pubsub/47>
|
||||
Note that this means a light node that listens to several topics would have to be connected to more full nodes to get connectivity. For a more exotic version of this, see https://forum.vac.dev/t/rfc-topic-propagation-extension-to-libp2p-pubsub/47
|
||||
|
||||
This is orthogonal from the choice of FloodSub or GossipSub, but due to GossipSub's more dynamic nature it is likely best combined with it.
|
||||
|
||||
@@ -172,11 +172,11 @@ Not a primary focus, but worth a look. Looking at the scaling model, there might
|
||||
|
||||
This is where we make sure the network isn't fragile, become a true p2p app, get our users excited and engaged, and allow us to scale the network without creating an even bigger cluster.
|
||||
|
||||
To work in practice, this has a soft dependency on node discovery such as DNS based discovery (<https://eips.ethereum.org/EIPS/eip-1459>) or Discovery v5 (<https://vac.dev/feasibility-discv5>).
|
||||
To work in practice, this has a soft dependency on node discovery such as DNS based discovery (https://eips.ethereum.org/EIPS/eip-1459) or Discovery v5 (https://vac.dev/feasibility-discv5).
|
||||
|
||||
### 1. Adaptive nodes and capabilities
|
||||
|
||||
We want to make the gradation between light nodes, full nodes, storing (partial set of) historical messages, only acting for a specific shard, etc more flexible and explicit. This is required to identify and discover the nodes you want. See <https://github.com/vacp2p/specs/issues/87>
|
||||
We want to make the gradation between light nodes, full nodes, storing (partial set of) historical messages, only acting for a specific shard, etc more flexible and explicit. This is required to identify and discover the nodes you want. See https://github.com/vacp2p/specs/issues/87
|
||||
|
||||
Depending on how the other tracks come together, this design should allow for a desktop node to identify as a full relaying node for some some app topic shard, but also express waku topic interest and retrieve historical messages itself.
|
||||
|
||||
@@ -190,7 +190,7 @@ This is based on a few principles:
|
||||
2. We can account for the difference in contribution in some fashion
|
||||
3. We want to incentivize nodes to tell the true, and be incentivized not to lie
|
||||
|
||||
Accounting here is a stepping stone, where accounting is the raw data upon which some settlement later occurs. It can have various forms of granularity. See <https://forum.vac.dev/t/accounting-for-resources-in-waku-and-beyond/31> for discussion.
|
||||
Accounting here is a stepping stone, where accounting is the raw data upon which some settlement later occurs. It can have various forms of granularity. See https://forum.vac.dev/t/accounting-for-resources-in-waku-and-beyond/31 for discussion.
|
||||
|
||||
We also note that in GossipSub, the mesh is bidrectional. Additionally, it doesn't appears to be a high priority issue in terms of nodes misreporting. What is an issue is having people run full nodes in the first place. There are a few points to that. It has to be possible in the end-user UX, nodes have to be discovered, and it has to be profitable/visible that you are contributing. UX and discovery are out of scope for this work, whereas visibility/accounting is part of this scope. Settlement is a stretch goal here.
|
||||
|
||||
@@ -206,7 +206,7 @@ While accounting for individual resource usage is useful, for the ultimate end u
|
||||
- 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.
|
||||
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.
|
||||
|
||||
All of this is optional at this stage, because our goal here is to improve the status quo for user run nodes. Accounting at this stage should be visible and correspond to the net benefit a node provides to another.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ discuss: https://forum.vac.dev/t/discussion-waku-v2-update/56
|
||||
|
||||
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?
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
@@ -24,7 +24,7 @@ In the last post ([Waku v2 plan](https://vac.dev/waku-v2-plan)) we explained the
|
||||
2. Track 2 - Better routing
|
||||
3. Track 3 - Accounting and user-run nodes
|
||||
|
||||
As well as various rough components for each track. The primary initial focus is track 1. This means things like: moving to FloodSub, simplify the protocol, core integration, topic interest behavior, historical message caching, and Waku v1<\>v2 bridge.
|
||||
As well as various rough components for each track. The primary initial focus is track 1. This means things like: moving to FloodSub, simplify the protocol, core integration, topic interest behavior, historical message caching, and Waku v1`<\>`v2 bridge.
|
||||
|
||||
## Current state
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/discussion-talk-vac-waku-v2-and-ethereum-messag
|
||||
|
||||
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.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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)._
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ toc_max_heading_level: 5
|
||||
|
||||
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.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -84,7 +84,7 @@ The remainder of this post is all about the story of how to enforce this limit o
|
||||
|
||||
**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].
|
||||
**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
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/discussion-presenting-js-waku-waku-v2-in-the-br
|
||||
|
||||
JS-Waku is bringing Waku v2 to the browser. Learn what we achieved so far and what is next in our pipeline!
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/discussion-talk-at-coscup-vac-waku-v2-and-ether
|
||||
|
||||
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.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
_This is the English version of a talk originally given in Chinese at COSCUP in Taipei._
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/discussion-waku-v1-vs-waku-v2-bandwidth-compari
|
||||
|
||||
A local comparison of bandwidth profiles showing significantly improved scalability in Waku v2 over Waku v1.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Background
|
||||
|
||||
@@ -40,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.
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss:
|
||||
|
||||
A look at typical ethical shortfalls in the global surveillance tech industry.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
_This is an opinion piece by pseudonymous contributor, circe._
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ toc_max_heading_level: 5
|
||||
|
||||
Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Background
|
||||
|
||||
@@ -283,7 +283,7 @@ You can also view the changelog for past releases [here](https://github.com/stat
|
||||
- [Node Discovery Protocol v5 - Theory](https://github.com/ethereum/devp2p/blob/fa6428ada7385c13551873b2ae6ad2457c228eb8/discv5/discv5-theory.md)
|
||||
- [Noise handshakes](https://forum.vac.dev/t/noise-handshakes-as-key-exchange-mechanism-for-waku2/130)
|
||||
- [RLN tutorial](https://github.com/status-im/nim-waku/blob/ee96705c7fbe4063b780ac43b7edee2f6c4e351b/docs/tutorial/rln-chat2-live-testnet.md)
|
||||
- [Vac <3 ZK](https://forum.vac.dev/t/vac-3-zk/97)
|
||||
- [Vac `<3` ZK](https://forum.vac.dev/t/vac-3-zk/97)
|
||||
- [Vac About page](https://vac.dev/#about)
|
||||
- [Vac Research log](https://vac.dev/research-log/)
|
||||
- [Vac RFC site](https://rfc.vac.dev/)
|
||||
|
||||
@@ -14,7 +14,7 @@ _includes: [math]
|
||||
|
||||
Introducing and discussing ambient peer discovery methods currently used by Waku v2, as well as future plans in this area.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
[Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2) comprises a set of modular protocols for secure, privacy preserving communication.
|
||||
Avoiding centralization, these protocols exchange messages over a P2P network layer.
|
||||
|
||||
@@ -15,7 +15,7 @@ _includes: [math]
|
||||
|
||||
We provide an overview of the Noise Protocol Framework as a tool to design efficient and secure key-exchange mechanisms in Waku2.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ toc_max_heading_level: 5
|
||||
|
||||
Introducing a basic threat model and privacy/anonymity analysis for the Waku v2 relay protocol.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
[Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2) enables secure, privacy preserving communication using a set of modular P2P protocols.
|
||||
Waku v2 also aims at protecting the user's anonymity.
|
||||
|
||||
@@ -13,7 +13,7 @@ discuss: https://forum.vac.dev/t/discussion-building-privacy-protecting-infrastr
|
||||
|
||||
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.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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)_
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ scalable communication. Waku is available in several languages and platforms, fr
|
||||
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.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Background
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ hide_table_of_contents: false
|
||||
|
||||
Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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
|
||||
|
||||
@@ -11,7 +11,7 @@ categories: platform
|
||||
|
||||
Device pairing and secure message exchange using Waku and noise protocol.
|
||||
|
||||
<!--truncate-->
|
||||
{/* 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.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ toc_max_heading_level: 5
|
||||
|
||||
Nescience, a privacy-first blockchain zkVM.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ toc_max_heading_level: 5
|
||||
|
||||
GossipSub Improvements: Evolution of Overlay Design and Message Dissemination in Unstructured P2P Networks
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Motivitation
|
||||
We have been recently working on analyzing and improving the performance of the GossipSub protocol for large messages,
|
||||
|
||||
@@ -13,7 +13,7 @@ toc_max_heading_level: 4
|
||||
|
||||
Rate Limiting Nullifiers in practice, applied to an anonymous p2p network, like Waku.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ toc_max_heading_level: 4
|
||||
|
||||
How resource-restricted devices can verify RLN proofs fast and efficiently.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ toc_max_heading_level: 4
|
||||
|
||||
Improving on the previous version of RLN by allowing dynamic epoch sizes.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ toc_max_heading_level: 4
|
||||
|
||||
We examine two data structures: Bloom filters and Cuckoo filters.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Membership with Bloom Filters and Cuckoo Filters
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ toc_max_heading_level: 5
|
||||
|
||||
Nescience: A user-centric state-separation architecture.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
_Disclaimer: This content is a work in progress. Some components may be updated, changed, or expanded as new research findings become available._
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
|
||||
# Introduction
|
||||
|
||||
@@ -12,7 +12,7 @@ toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
# Introduction
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
In this post, we introduce a common technique used to convert interactive protocols to their noninteractive variant.
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
This post provides quick insights into the IDONTWANT message performance and highlights minor tweaks that can further contribute to performance gains.
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ toc_max_heading_level: 5
|
||||
|
||||
Large Message Handling in GossipSub: Potential Improvements
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Motivation
|
||||
The challenge of large message transmissions in GossipSub leads to longer than expected network-wide message dissemination times (and relatively higher fluctuations).
|
||||
|
||||
@@ -13,7 +13,7 @@ toc_max_heading_level: 5
|
||||
|
||||
In this post, we recap Vac's achievements in 2024 and look forward to 2025.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
With 2024 now behind us and a new year ahead,
|
||||
Vac is proud to reflect on the milestones and breakthroughs that defined another year of researching and developing free and open digital public goods for the [Institute of Free Technology](https://free.technology/) and wider web3 ecosystem.
|
||||
|
||||
@@ -12,7 +12,7 @@ toc_max_heading_level: 4
|
||||
|
||||
In this post, we introduce a crucial data structure used throughout web3.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ This article introduces MDSECheck method — a novel approach
|
||||
to checking square MDS matrices for unconditional security
|
||||
as the components of affine permutation layers of P-SP-networks.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
{
|
||||
// This file is not used in compilation. It is here just for a nice editor experience.
|
||||
"extends": "@tsconfig/docusaurus/tsconfig.json"
|
||||
"extends": "@docusaurus/tsconfig",
|
||||
"compilerOptions": {
|
||||
"baseUrl": "."
|
||||
}
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user