mirror of
https://github.com/vacp2p/vac.dev.git
synced 2026-08-30 19:51:12 +00:00
1 line
29 KiB
JavaScript
1 line
29 KiB
JavaScript
"use strict";(self.webpackChunkresearch_logos_co=self.webpackChunkresearch_logos_co||[]).push([[2863],{7386:e=>{e.exports=JSON.parse('{"permalink":"/rlog/introducing-nwaku","source":"@site/rlog/2022-04-12-introducing-nwaku.mdx","title":"Introducing nwaku","description":"Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.","date":"2022-04-12T10:00:00.000Z","tags":[],"readingTime":13.26,"hasTruncateMarker":true,"authors":[{"name":"Hanno Cornelius","twitter":"4aelius","github":"jm-clius","key":"hanno","page":null}],"frontMatter":{"layout":"post","name":"Introducing nwaku","title":"Introducing nwaku","date":"2022-04-12T10:00:00.000Z","authors":"hanno","published":true,"slug":"introducing-nwaku","categories":"research","discuss":"https://forum.research.logos.co/","toc_min_heading_level":2,"toc_max_heading_level":5},"unlisted":false,"prevItem":{"title":"Waku v2 Ambient Peer Discovery","permalink":"/rlog/wakuv2-apd"},"nextItem":{"title":"Opinion: Pseudo-ethics in the Surveillance Tech Industry","permalink":"/rlog/ethics-surveillance-tech"}}')},28453:(e,n,i)=>{i.d(n,{R:()=>t,x:()=>a});var s=i(96540);const r={},o=s.createContext(r);function t(e){const n=s.useContext(o);return s.useMemo((function(){return"function"==typeof e?e(n):{...n,...e}}),[n,e])}function a(e){let n;return n=e.disableParentContext?"function"==typeof e.components?e.components(r):e.components||r:t(e.components),s.createElement(o.Provider,{value:n},e.children)}},34377:(e,n,i)=>{i.r(n),i.d(n,{assets:()=>c,contentTitle:()=>a,default:()=>h,frontMatter:()=>t,metadata:()=>s,toc:()=>d});var s=i(7386),r=i(74848),o=i(28453);const t={layout:"post",name:"Introducing nwaku",title:"Introducing nwaku",date:new Date("2022-04-12T10:00:00.000Z"),authors:"hanno",published:!0,slug:"introducing-nwaku",categories:"research",discuss:"https://forum.research.logos.co/",toc_min_heading_level:2,toc_max_heading_level:5},a=void 0,c={authorsImageUrls:[void 0]},d=[{value:"Background",id:"background",level:2},{value:"1. <em><strong>nim-waku</strong></em> is now known as <em><strong>nwaku</strong></em>",id:"1-nim-waku-is-now-known-as-nwaku",level:2},{value:"2. Improvements in stability and performance",id:"2-improvements-in-stability-and-performance",level:2},{value:"3. Improvements in interoperability",id:"3-improvements-in-interoperability",level:2},{value:"4. Peer discovery",id:"4-peer-discovery",level:2},{value:"DNS-based discovery",id:"dns-based-discovery",level:3},{value:"GossipSub peer exchange",id:"gossipsub-peer-exchange",level:3},{value:"Waku Node Discovery Protocol v5",id:"waku-node-discovery-protocol-v5",level:3},{value:"5. Spam protection using RLN",id:"5-spam-protection-using-rln",level:2},{value:"Future work",id:"future-work",level:2},{value:"Reaching out to operators:",id:"reaching-out-to-operators",level:3},{value:"Better conversational security layer guarantees",id:"better-conversational-security-layer-guarantees",level:3},{value:"Protocol incentivization",id:"protocol-incentivization",level:3},{value:"Improved store capacity",id:"improved-store-capacity",level:3},{value:"Multipurpose discovery",id:"multipurpose-discovery",level:3},{value:"<em>Capability discovery:</em>",id:"capability-discovery",level:4},{value:"<em>Improvements in Discovery v5</em>",id:"improvements-in-discovery-v5",level:4},{value:"<em>Generalized peer exchange</em>",id:"generalized-peer-exchange",level:4},{value:"References",id:"references",level:2}];function l(e){const n={a:"a",br:"br",code:"code",em:"em",h2:"h2",h3:"h3",h4:"h4",hr:"hr",li:"li",ol:"ol",p:"p",strong:"strong",ul:"ul",...(0,o.R)(),...e.components};return(0,r.jsxs)(r.Fragment,{children:[(0,r.jsx)(n.p,{children:"Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas."}),"\n","\n",(0,r.jsx)(n.h2,{id:"background",children:"Background"}),"\n",(0,r.jsxs)(n.p,{children:["If you've been following our ",(0,r.jsx)(n.a,{href:"https://research.logos.co/research-log/",children:"research log"}),",\nyou'll know that many things have happened in the world of Waku v2 since ",(0,r.jsx)(n.a,{href:"/waku-v2-ethereum-coscup",children:"our last general update"}),".\nIn line with our ",(0,r.jsx)(n.a,{href:"https://research.logos.co/#about",children:"long term goals"}),",\nwe've introduced new protocols,\ntweaked our existing protocols\nand expanded our team.\nWe've also shown ",(0,r.jsx)(n.a,{href:"/waku-v1-v2-bandwidth-comparison",children:"in a series of practical experiments"})," that Waku v2 does indeed deliver on some of the ",(0,r.jsx)(n.a,{href:"/waku-v2-plan",children:"theoretical advantages"})," it was designed to have over its predecessor, Waku v1.\nA ",(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/vac-sustainability-and-business-workshop/116",children:"sustainability and business workshop"})," led to the formulation of a clearer vision for Logos Research as a team."]}),"\n",(0,r.jsxs)(n.p,{children:["From the beginning, our protocol development has been complemented by various client implementations of these protocols,\nfirst in ",(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku",children:"Nim"}),",\nbut later also in ",(0,r.jsx)(n.a,{href:"https://github.com/status-im/js-waku",children:"JavaScript"}),"\nand ",(0,r.jsx)(n.a,{href:"https://github.com/status-im/go-waku",children:"Go"}),".\nA follow-up post will clarify the purposes, similarities and differences between these three clients.\nThe ",(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku/tree/d2fccb5220144893f994a67f2cc26661247f101f/waku/v2",children:"Nim client"}),", is our reference implementation,\ndeveloped by the research team in parallel with the specs\nand building on a home-grown implementation of ",(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-libp2p",children:(0,r.jsx)(n.code,{children:"libp2p"})}),".\nThe Nim client is suitable to run as ",(0,r.jsx)(n.a,{href:"/waku-update",children:"a standalone adaptive node"}),",\nmanaged by individual operators\nor as an encapsulated service node in other applications.\nThis post looks at some recent developments within the Nim client."]}),"\n",(0,r.jsxs)(n.h2,{id:"1-nim-waku-is-now-known-as-nwaku",children:["1. ",(0,r.jsx)(n.em,{children:(0,r.jsx)(n.strong,{children:"nim-waku"})})," is now known as ",(0,r.jsx)(n.em,{children:(0,r.jsx)(n.strong,{children:"nwaku"})})]}),"\n",(0,r.jsxs)(n.p,{children:['Pronounced NWHA-koo.\nYou may already have seen us refer to "',(0,r.jsx)(n.code,{children:"nwaku"}),'" on Logos Research communication channels,\nbut it is now official:\nThe ',(0,r.jsx)(n.code,{children:"nim-waku"})," Waku v2 client has been named ",(0,r.jsx)(n.code,{children:"nwaku"}),".\nWhy? Well, we needed a recognizable name for our client that could easily be referred to in everyday conversations\nand ",(0,r.jsx)(n.code,{children:"nim-waku"})," just didn't roll off the tongue.\nWe've followed the example of the closely related ",(0,r.jsxs)(n.a,{href:"https://github.com/status-im/nimbus-eth2",children:[(0,r.jsx)(n.code,{children:"nimbus"})," project"]})," to find a punchier name\nthat explicitly links the client to both the Waku set of protocols and the Nim language."]}),"\n",(0,r.jsx)(n.h2,{id:"2-improvements-in-stability-and-performance",children:"2. Improvements in stability and performance"}),"\n",(0,r.jsxs)(n.p,{children:["The initial implementation of Waku v2 demonstrated how the suite of protocols can be applied\nto form a generalized, peer-to-peer messaging network,\nwhile addressing a wide range of adaptive requirements.\nThis allowed us to lift several protocol ",(0,r.jsx)(n.a,{href:"https://rfc.vac.dev/",children:"specifications"})," from ",(0,r.jsx)(n.code,{children:"raw"})," to ",(0,r.jsx)(n.code,{children:"draft"})," status,\nindicating that a reference implementation exists for each.\nHowever, as internal dogfooding increased and more external applications started using ",(0,r.jsx)(n.code,{children:"nwaku"}),",\nwe stepped up our focus on the client's stability and performance.\nThis is especially true where we want ",(0,r.jsx)(n.code,{children:"nwaku"})," to run unsupervised in a production environment\nwithout any degradation in the services it provides."]}),"\n",(0,r.jsx)(n.p,{children:"Some of the more significant productionization efforts over the last couple of months included:"}),"\n",(0,r.jsxs)(n.ol,{children:["\n",(0,r.jsxs)(n.li,{children:["\n",(0,r.jsxs)(n.p,{children:["Reworking the ",(0,r.jsx)(n.code,{children:"store"})," implementation to maintain stable memory usage\nwhile storing historical messages\nand serving multiple clients querying history simultaneously.\nPreviously, a ",(0,r.jsx)(n.code,{children:"store"})," node would see gradual service degradation\ndue to inefficient memory usage when responding to history queries.\nQueries that often took longer than 8 mins now complete in under 100 ms."]}),"\n"]}),"\n",(0,r.jsxs)(n.li,{children:["\n",(0,r.jsxs)(n.p,{children:["Improved peer management.\nFor example, ",(0,r.jsx)(n.code,{children:"filter"})," nodes will now remove unreachable clients after a number of connection failures,\nwhereas they would previously keep accumulating dead peers."]}),"\n"]}),"\n",(0,r.jsxs)(n.li,{children:["\n",(0,r.jsxs)(n.p,{children:["Improved disk usage.\n",(0,r.jsx)(n.code,{children:"nwaku"})," nodes that persist historical messages on disk now manage their own storage size based on the ",(0,r.jsx)(n.code,{children:"--store-capacity"}),".\nThis can significantly improve node start-up times."]}),"\n"]}),"\n"]}),"\n",(0,r.jsxs)(n.p,{children:["More stability issues may be addressed in future as ",(0,r.jsx)(n.code,{children:"nwaku"})," matures,\nbut we've noticed a marked improvement in the reliability of running ",(0,r.jsx)(n.code,{children:"nwaku"})," nodes.\nThese include environments where ",(0,r.jsx)(n.code,{children:"nwaku"})," nodes are expected to run with a long uptime.\nLogos Research currently operates two long-running fleets of ",(0,r.jsx)(n.code,{children:"nwaku"})," nodes, ",(0,r.jsx)(n.code,{children:"wakuv2.prod"})," and ",(0,r.jsx)(n.code,{children:"wakuv2.test"}),",\nfor internal dogfooding and\nto serve as experimental bootstrapping nodes.\nStatus has also recently deployed similar fleets for production and testing based on ",(0,r.jsx)(n.code,{children:"nwaku"}),".\nOur goal is to have ",(0,r.jsx)(n.code,{children:"nwaku"})," be stable, performant and flexible enough\nto be an attractive option for operators to run and maintain their own Waku v2 nodes.\nSee also the ",(0,r.jsx)(n.a,{href:"#future-work",children:"future work"})," section below for more on our general goal of ",(0,r.jsxs)(n.em,{children:[(0,r.jsx)(n.code,{children:"nwaku"})," for operators"]}),"."]}),"\n",(0,r.jsx)(n.h2,{id:"3-improvements-in-interoperability",children:"3. Improvements in interoperability"}),"\n",(0,r.jsxs)(n.p,{children:["We've implemented several features that improve ",(0,r.jsx)(n.code,{children:"nwaku"}),"'s usability in different environments\nand its interoperability with other Waku v2 clients.\nOne major step forward here was adding support for both secure and unsecured WebSocket connections as ",(0,r.jsx)(n.code,{children:"libp2p"})," transports.\nThis allows direct connectivity with ",(0,r.jsx)(n.code,{children:"js-waku"}),"\nand paves the way for native browser usage.\nWe've also added support for parsing and resolving DNS-type ",(0,r.jsx)(n.code,{children:"multiaddrs"}),",\ni.e. multiaddress protocol schemes ",(0,r.jsxs)(n.a,{href:"https://github.com/multiformats/multiaddr/blob/b746a7d014e825221cc3aea6e57a92d78419990f/protocols.csv#L8-L11",children:[(0,r.jsx)(n.code,{children:"dns"}),", ",(0,r.jsx)(n.code,{children:"dns4"}),", ",(0,r.jsx)(n.code,{children:"dns6"})," and ",(0,r.jsx)(n.code,{children:"dnsaddr"})]}),".\nA ",(0,r.jsx)(n.code,{children:"nwaku"})," node can now also be ",(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku/tree/d2fccb5220144893f994a67f2cc26661247f101f/waku/v2#configuring-a-domain-name",children:"configured with its own IPv4 DNS domain name"}),"\nallowing dynamic IP address allocation without impacting a node's reachability by its peers."]}),"\n",(0,r.jsx)(n.h2,{id:"4-peer-discovery",children:"4. Peer discovery"}),"\n",(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.em,{children:"Peer discovery"})," is the method by which nodes become aware of each other\u2019s existence.\nThe question of peer discovery in a Waku v2 network has been a focus area since the protocol was first conceptualized.\nSince then several different approaches to discovery have been proposed and investigated.\nWe've implemented three discovery mechanisms in ",(0,r.jsx)(n.code,{children:"nwaku"})," so far:"]}),"\n",(0,r.jsx)(n.h3,{id:"dns-based-discovery",children:"DNS-based discovery"}),"\n",(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.code,{children:"nwaku"})," nodes can retrieve an authenticated, updateable list of peers via DNS to bootstrap connection to a Waku v2 network.\nOur implementation is based on ",(0,r.jsx)(n.a,{href:"https://eips.ethereum.org/EIPS/eip-1459",children:"EIP-1459"}),"."]}),"\n",(0,r.jsx)(n.h3,{id:"gossipsub-peer-exchange",children:"GossipSub peer exchange"}),"\n",(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.a,{href:"https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/pubsub/gossipsub/gossipsub-v1.1.md#prune-backoff-and-peer-exchange",children:"GossipSub Peer Exchange (PX)"})," is a GossipSub v1.1 mechanism\nwhereby a pruning peer may provide a pruned peer with a set of alternative peers\nwhere it can connect to reform its mesh.\nThis is a very suitable mechanism to gradually discover more peers\nfrom an initial connection to a small set of bootstrap peers.\nIt is enabled in a ",(0,r.jsx)(n.code,{children:"nwaku"})," node by default."]}),"\n",(0,r.jsx)(n.h3,{id:"waku-node-discovery-protocol-v5",children:"Waku Node Discovery Protocol v5"}),"\n",(0,r.jsxs)(n.p,{children:["This is a DHT-based discovery mechanism adapted to store and relay ",(0,r.jsx)(n.em,{children:"node records"}),".\nOur implementation is based on ",(0,r.jsx)(n.a,{href:"https://github.com/ethereum/devp2p/blob/fa6428ada7385c13551873b2ae6ad2457c228eb8/discv5/discv5-theory.md",children:"Ethereum's Discovery v5 protocol"}),"\nwith some ",(0,r.jsx)(n.a,{href:"https://rfc.vac.dev/waku/standards/core/33/discv5",children:"minor modifications"})," to isolate our discovery network from that of Ethereum.\nThe decision to separate the Waku Discovery v5 network from Ethereum's was made on considerations of lookup efficiency.\nThis comes at a possible tradeoff in network resilience.\nWe are considering merging with the Ethereum Discovery v5 network in future,\nor even implement a hybrid solution.\n",(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/waku-v2-discv5-roadmap-discussion/121/8",children:"This post"})," explains the decision and future steps."]}),"\n",(0,r.jsx)(n.h2,{id:"5-spam-protection-using-rln",children:"5. Spam protection using RLN"}),"\n",(0,r.jsxs)(n.p,{children:["An early addition to our suite of protocols was ",(0,r.jsxs)(n.a,{href:"https://rfc.vac.dev/vac/32/rln-v1",children:["an extension of ",(0,r.jsx)(n.code,{children:"11/WAKU-RELAY"})]}),"\nthat provided spam protection using ",(0,r.jsx)(n.a,{href:"https://rfc.vac.dev/vac/32/rln-v1",children:"Rate Limiting Nullifiers (RLN)"}),".\nThe ",(0,r.jsx)(n.code,{children:"nwaku"})," client now contains a working demonstration and integration of RLN relay.\nCheck out ",(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku/blob/ee96705c7fbe4063b780ac43b7edee2f6c4e351b/docs/tutorial/rln-chat2-live-testnet.md",children:"this tutorial"})," to see the protocol in action using a toy chat application built on ",(0,r.jsx)(n.code,{children:"nwaku"}),".\nWe'd love for people to join us in dogfooding RLN spam protection as part of our operator incentive testnet.\nFeel free to join our ",(0,r.jsx)(n.a,{href:"https://discord.gg/KNj3ctuZvZ",children:"Logos Research Discord"})," server\nand head to the ",(0,r.jsx)(n.code,{children:"#rln"})," channel for more information."]}),"\n",(0,r.jsx)(n.h2,{id:"future-work",children:"Future work"}),"\n",(0,r.jsxs)(n.p,{children:["As we continue working towards our goal of a fully decentralized, generalized and censorship-resistant messaging protocol,\nthese are some of the current and future focus areas for ",(0,r.jsx)(n.code,{children:"nwaku"}),":"]}),"\n",(0,r.jsx)(n.h3,{id:"reaching-out-to-operators",children:"Reaching out to operators:"}),"\n",(0,r.jsxs)(n.p,{children:["We are starting to push for operators to run and maintain their own Waku v2 nodes,\npreferably contributing to the default Waku v2 network as described by the default pubsub topic (",(0,r.jsx)(n.code,{children:"/waku/2/default-waku/proto"}),").\nAmongst other things, a large fleet of stable operator-run Waku v2 nodes will help secure the network,\nprovide valuable services to a variety of applications\nand ensure the future sustainability of both Logos Research as a research organization and the Waku suite of protocols."]}),"\n",(0,r.jsxs)(n.p,{children:["We are targeting ",(0,r.jsx)(n.code,{children:"nwaku"})," as the main option for operator-run nodes.",(0,r.jsx)(n.br,{}),"\n","Specifically, we aim to provide through ",(0,r.jsx)(n.code,{children:"nwaku"}),":"]}),"\n",(0,r.jsxs)(n.ol,{children:["\n",(0,r.jsx)(n.li,{children:"a lightweight and robust Waku v2 client.\nThis client must be first in line to support innovative and new Waku v2 protocols,\nbut configurable enough to serve the adaptive needs of various operators."}),"\n",(0,r.jsx)(n.li,{children:"an easy-to-follow guide for operators to configure,\nset up and maintain their own nodes"}),"\n",(0,r.jsx)(n.li,{children:"a set of operator-focused tools to monitor and maintain a running node"}),"\n"]}),"\n",(0,r.jsx)(n.h3,{id:"better-conversational-security-layer-guarantees",children:"Better conversational security layer guarantees"}),"\n",(0,r.jsxs)(n.p,{children:["Conversational security guarantees in Waku v2 are currently designed around the Status application.\nDevelopers building their own applications on top of Waku would therefore\neither have to reimplement a set of tools similar to Status\nor build their own security solutions on the application layer above Waku.\nWe are working on ",(0,r.jsx)(n.a,{href:"https://github.com/vacp2p/research/issues/97",children:"a set of features"})," built into Waku\nthat will provide the general security properties Waku users may desire\nand do so in a modern and simple way.\nThis is useful for applications outside of Status that want similar security guarantees.\nAs a first step, we've already made good progress toward ",(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/noise-handshakes-as-key-exchange-mechanism-for-waku2/130",children:"integrating noise handshakes"})," as a key exchange mechanism in Waku v2."]}),"\n",(0,r.jsx)(n.h3,{id:"protocol-incentivization",children:"Protocol incentivization"}),"\n",(0,r.jsxs)(n.p,{children:["We want to design incentivization around our protocols to encourage desired behaviors in the Waku network,\nrewarding nodes providing costly services\nand punishing adversarial actions.\nThis will increase the overall security of the network\nand encourage operators to run their own Waku nodes.\nIn turn, the sustainability of Logos Research as an organization will be better guaranteed.\nAs such, protocol incentivization was a major focus in our recent ",(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/vac-sustainability-and-business-workshop/",children:"Logos Research Sustainability and Business Workshop"}),".\nOur first step here is to finish integrating RLN relay into Waku\nwith blockchain interaction to manage members,\npunish spammers\nand reward spam detectors.\nAfter this, we want to design monetary incentivization for providers of ",(0,r.jsx)(n.code,{children:"store"}),", ",(0,r.jsx)(n.code,{children:"lightpush"})," and ",(0,r.jsx)(n.code,{children:"filter"})," services.\nThis may also tie into a reputation mechanism for service nodes based on a network-wide consensus on service quality.\nA big challenge for protocol incentivization is doing it in a private fashion,\nso we can keep similar metadata protection guarantees as the Waku base layer.\nThis ties into our focus on ",(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/vac-3-zk/97",children:"Zero Knowledge tech"}),"."]}),"\n",(0,r.jsx)(n.h3,{id:"improved-store-capacity",children:"Improved store capacity"}),"\n",(0,r.jsxs)(n.p,{children:["The ",(0,r.jsx)(n.code,{children:"nwaku"})," store currently serves as an efficient in-memory store for historical messages,\ndimensioned by the maximum number of messages the store node is willing to keep.\nThis makes the ",(0,r.jsx)(n.code,{children:"nwaku"})," store appropriate for keeping history over a short term\nwithout any time-based guarantees,\nbut with the advantage of providing fast responses to history queries.\nSome applications, such as Status, require longer-term historical message storage\nwith time-based dimensioning\nto guarantee that messages will be stored for a specified minimum period.\nBecause of the relatively high cost of memory compared to disk space,\na higher capacity store, with time guarantees, should operate as a disk-only database of historical messages.\nThis is an ongoing effort."]}),"\n",(0,r.jsx)(n.h3,{id:"multipurpose-discovery",children:"Multipurpose discovery"}),"\n",(0,r.jsxs)(n.p,{children:["In addition to ",(0,r.jsx)(n.a,{href:"#4-peer-discovery",children:"the three discovery methods"})," already implemented in ",(0,r.jsx)(n.code,{children:"nwaku"}),",\nwe are working on improving discovery on at least three fronts:"]}),"\n",(0,r.jsx)(n.h4,{id:"capability-discovery",children:(0,r.jsx)(n.em,{children:"Capability discovery:"})}),"\n",(0,r.jsx)(n.p,{children:"Waku v2 nodes may be interested in peers with specific capabilities, for example:"}),"\n",(0,r.jsxs)(n.ol,{children:["\n",(0,r.jsx)(n.li,{children:"peers within a specific pubsub topic mesh,"}),"\n",(0,r.jsxs)(n.li,{children:["peers with ",(0,r.jsx)(n.strong,{children:"store"})," capability,"]}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.strong,{children:"store"})," peers with x days of history for a specific content topic, etc."]}),"\n"]}),"\n",(0,r.jsxs)(n.p,{children:["Capability discovery entails mechanisms by which such capabilities can be advertised and discovered/negotiated.\nOne major hurdle to overcome is the increased complexity of finding a node with specific capabilities within the larger network (a needle in a haystack).\nSee the ",(0,r.jsx)(n.a,{href:"https://github.com/vacp2p/rfc/issues/429",children:"original problem statement"})," for more."]}),"\n",(0,r.jsx)(n.h4,{id:"improvements-in-discovery-v5",children:(0,r.jsx)(n.em,{children:"Improvements in Discovery v5"})}),"\n",(0,r.jsxs)(n.p,{children:["Of the implemented discovery methods,\nDiscovery v5 best addresses our need for a decentralized and scalable discovery mechanism.\nWith the basic implementation done,\nthere are some improvements planned for Discovery v5,\nincluding methods to increase security such as merging with the Ethereum Discovery v5 network,\nintroducing explicit NAT traversal\nand utilizing ",(0,r.jsx)(n.a,{href:"https://github.com/ethereum/devp2p/blob/fa6428ada7385c13551873b2ae6ad2457c228eb8/discv5/discv5-theory.md#topic-advertisement",children:"topic advertisement"}),".\nThe ",(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/waku-v2-discv5-roadmap-discussion/121",children:"Waku v2 Discovery v5 Roadmap"})," contains more details."]}),"\n",(0,r.jsx)(n.h4,{id:"generalized-peer-exchange",children:(0,r.jsx)(n.em,{children:"Generalized peer exchange"})}),"\n",(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.code,{children:"nwaku"})," already implements ",(0,r.jsx)(n.a,{href:"https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/pubsub/gossipsub/gossipsub-v1.1.md#prune-backoff-and-peer-exchange",children:"GossipSub peer exchange"}),".\nWe now need a general request-response mechanism outside of GossipSub\nby which a node may learn about other Waku v2 nodes\nby requesting and receiving a list of peers from a neighbor.\nThis could, for example, be a suitable way for resource-restricted devices to request a stronger peer\nto perform a random Discovery v5 lookup on their behalf\nor simply to be informed of a subset of the peers known to that neighbor.\nSee ",(0,r.jsx)(n.a,{href:"https://github.com/vacp2p/rfc/issues/495",children:"this issue"})," for more."]}),"\n",(0,r.jsx)(n.hr,{}),"\n",(0,r.jsxs)(n.p,{children:["This concludes a general outline of some of the main recent developments in the ",(0,r.jsx)(n.code,{children:"nwaku"})," client\nand a summary of the current and future focus areas.\nMuch more is happening behind the scenes, of course,\nso for more information, or to join the conversation,\nfeel free to join our ",(0,r.jsx)(n.a,{href:"https://discord.gg/KNj3ctuZvZ",children:"Logos Research Discord"})," server\nor to check out the ",(0,r.jsxs)(n.a,{href:"https://github.com/status-im/nim-waku",children:[(0,r.jsx)(n.code,{children:"nwaku"})," repo on Github"]}),".\nYou can also view the changelog for past releases ",(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku/releases",children:"here"}),"."]}),"\n",(0,r.jsx)(n.h2,{id:"references",children:"References"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://rfc.vac.dev/waku/standards/core/17/rln-relay",children:"17/WAKU-RLN-RELAY"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://rfc.vac.dev/vac/32/rln-v1",children:"32/RLN"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://rfc.vac.dev/waku/standards/core/33/discv5",children:"33/WAKU2-DISCV5"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/vacp2p/rfc/issues/429",children:"Capabilities advertising"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku/tree/d2fccb5220144893f994a67f2cc26661247f101f/waku/v2#configuring-a-domain-name",children:"Configuring a domain name"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/vacp2p/research/issues/97",children:"Conversational security"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/ethereum/devp2p/blob/fa6428ada7385c13551873b2ae6ad2457c228eb8/discv5/discv5-theory.md#topic-advertisement",children:"Discovery v5 Topic Advertisement"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://eips.ethereum.org/EIPS/eip-1459",children:"EIP-1459"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/pubsub/gossipsub/gossipsub-v1.1.md#prune-backoff-and-peer-exchange",children:"GossipSub Peer Exchange"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/status-im/go-waku",children:"go-waku"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/status-im/js-waku",children:"js-waku"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsxs)(n.a,{href:"https://github.com/multiformats/multiaddr/blob/b746a7d014e825221cc3aea6e57a92d78419990f/protocols.csv#L8-L11",children:[(0,r.jsx)(n.code,{children:"multiaddr"})," formats"]})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/status-im/nimbus-eth2",children:"nimbus-eth2"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-libp2p",children:"nim-libp2p"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku",children:"nim-waku"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku/releases",children:"nim-waku releases"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/ethereum/devp2p/blob/fa6428ada7385c13551873b2ae6ad2457c228eb8/discv5/discv5-theory.md",children:"Node Discovery Protocol v5 - Theory"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/noise-handshakes-as-key-exchange-mechanism-for-waku2/130",children:"Noise handshakes"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/status-im/nim-waku/blob/ee96705c7fbe4063b780ac43b7edee2f6c4e351b/docs/tutorial/rln-chat2-live-testnet.md",children:"RLN tutorial"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsxs)(n.a,{href:"https://forum.research.logos.co/t/vac-3-zk/97",children:["Logos Research ",(0,r.jsx)(n.code,{children:"<3"})," ZK"]})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://research.logos.co/#about",children:"Logos Research About page"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://research.logos.co/research-log/",children:"Logos Research Research log"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://rfc.vac.dev/",children:"Logos Research RFC site"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/vac-sustainability-and-business-workshop/",children:"Logos Research Sustainability and Business Workshop"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"/waku-update",children:"Waku Update"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"/waku-v1-v2-bandwidth-comparison",children:"Waku v1 vs Waku v2: Bandwidth Comparison"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://github.com/vacp2p/rfc/issues/495",children:"Waku v2 Peer Exchange"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"https://forum.research.logos.co/t/waku-v2-discv5-roadmap-discussion/121",children:"Waku v2 Discovery v5 Roadmap"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"/waku-v2-plan",children:"What's the Plan for Waku v2?"})}),"\n"]})]})}function h(e={}){const{wrapper:n}={...(0,o.R)(),...e.components};return n?(0,r.jsx)(n,{...e,children:(0,r.jsx)(l,{...e})}):l(e)}}}]); |