diff --git a/sitemap.xml b/sitemap.xml index e3a9315e9..3b2dcd5ed 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -630,5 +630,5 @@ 2023-11-14T22:27:32.542Z https://roadmap.logos.co/waku/updates/2023-11-20 - 2023-11-21T01:11:16.745Z + 2023-11-21T22:41:37.225Z \ No newline at end of file diff --git a/static/contentIndex.json b/static/contentIndex.json index e6c0097d0..287cc33ec 100644 --- a/static/contentIndex.json +++ b/static/contentIndex.json @@ -1 +1 @@ -{"acid/index":{"title":"Comms Roadmap Overview","links":["acid/milestones-overview","tags/acid-updates"],"tags":["overview"],"content":"Welcome to the Comms Roadmap Overview\n\nMilestones\nweekly updates\n"},"acid/milestones-overview":{"title":"Comms Milestones Overview","links":[],"tags":["milestones"],"content":"\nComms Roadmap\nComms Projects\nComms planner deadlines\n"},"acid/updates/2023-08-02":{"title":"2023-08-02 Acid weekly","links":[],"tags":["acid-updates"],"content":"Leads roundup - acid §\nAl / Comms\n\nStatus app relaunch comms campaign plan in the works. Approx. date for launch 31.08.\nLogos comms + growth plan post launch is next up TBD.\nWill be waiting for specs for data room, raise etc.\nHires: split the role for content studio to be more realistic in getting top level talent.\n\nMatt / Copy\n\nInitiative updating old documentation like CC guide to reflect broader scope of BUs\nBrand guidelines/ modes of presentation are in process\nWikipedia entry on network states and virtual states is live on\n\nEddy / Digital Comms\n\nLogos Discord will be completed by EOD.\nCodex Discord will be done tomorrow.\nLPE rollout plan, currently working on it, will be ready EOW\nPodcast rollout needs some\nOverarching BU plan will be ready in next couple of weeks as things on top have taken priority.\n\nAmir / Studio\n\nStarted execution of LPE for new requirements, broken down in smaller deliveries. Looking to have it working and live by EOM.\nHires: still looking for 3 positions with main focus on developer side.\n\nJonny / Podcast\n\nPodcast timelines are being set. In production right now. Nick delivered graphics for HiO but we need a full pack.\nFirst HiO episode is in the works. Will be ready in 2 weeks to fit in the rollout of the LPE.\n\nLouisa / Events\n\nGlobal strategy paper for wider comms plan.\nTemplate for processes and executions when preparing events.\nDecision made with Carl to move Network State event to November in satellite of other events. Looking into ETH Lisbon / Staking Summit etc.\nSeoul Q4 hackathon is already in the works. Needs bounty planning.\n"},"acid/updates/2023-08-09":{"title":"2023-08-09 Acid weekly","links":[],"tags":["acid-updates"],"content":"Top level priorities: §\nLogos Growth Plan\nStatus Relaunch\nLaunch of LPE\nPodcasts (Target: Every week one podcast out)\nHiring: TD studio and DC studio roles\nMovement Building: §\n\nLogos collective comms plan skeleton ready - will be applied for all BUs as next step\nGoal is to have plan + overview to set realistic KPIs and expectations\nDiscord Server update on various views\nStatus relaunch comms plan is ready for input from John et al.\nReach out to BUs for needs and deliverables\n\nTD Studio §\nFull focus on LPE:\n\nOn track, target of end of august\nreview of options, more diverse landscape of content\nEpisodes page proposals\nPlayers in progress\nrefactoring from prev code base\nstructure of content ready in GDrive\n\nCopy §\n\nContent around LPE\nContent for podcast launches\nStatus launch - content requirements to receive\nOrganization of doc sites review\nTBD what type of content and how the generation workflows will look like\n\nPodcast §\n\nGood state in editing and producing the shows\nFirst interview edited end to end with XMTP is ready. 2 weeks with social assets and all included.\nLSP is looking at having 2 months of content ready to launch with the sessions that have been recorded.\n3 recorded for HIO, motion graphics in progress\nFirst E2E podcast ready in 2 weeks for LPE\nLSP is looking at having 2 months of content ready to launch with the sessions that have been recorded.\n\nDC Studio §\n\nBrand guidelines for HiO are ready and set. Thanks Shmeda!\nLogos State branding assets are being developed\nPresentation templates update\n\nEvents §\n\nNetwork State event probably in Istanbul in November re: Devconnect will confirm shortly.\nProgram elements and speakers are top priority\nHackathon in Seoul in Q1 2024 - late Febuary probably\nJarrad will be speaking at HCPP and EthRome\nGlobal event strategy written and in review\nLou presented social media and event KPIs on Paris event\n\nCRM & Marketing tool §\n\nGet feedback from stakeholders and users\nPM implementation to be planned (+- 3 month time TBD) with working group\nLPE KPI: Collecting email addresses of relevant people\nCareful on how we manage and use data, important for BizDev\nCareful on which segments of the project to manage using the CRM as it can be very off brand\n"},"acid/updates/2023-08-29":{"title":"2023-08-29 Comms weekly","links":[],"tags":["acid-updates"],"content":"Leads roundup - acid §\nAl - Comms §\n\nLPE & Podcast are almost there. Content needs to be polished and reviewed by Carl and Jarrad. Might have an impact on the deadline but we start testing phase tomorrow.\nPlan for marketing and promotion of the podcast needs a bit more work. Teasers for Snowden will be released. Next episode drops next week.\nStatus app comms campaign. We are aligned with John and Status team. Needs pre-launch work for content and pending some items and confirmations from John.\nDigital designer will be joining us soon for Content team. We are still looking for a Motion designer.\nTownhall: Dmitry and Santiago will be talking re: Codex + Logos culture.\n\nAmir - Tech and Design §\n\nLPE is ready. Content is being populated. Soft launch is 30/08. Then stress test, debug, etc.\nNotion page is up and running for listing errors, bugs and feedback. Amir will move to GitHub https://www.notion.so/f9fef49cc74c46b19ceb9c14a2003062?v=3eb563f28fc448bd836d16da1272d620&pvs=4\nWiki: codebase will be ready in a day or two, then once infra team deploys we have kick off meeting for structure, content etc. Then design team can redesign based on what we need. Timeframe: end of September\n\nMatt - Copy §\n\nContent from the LPE is getting there, pending review as mentioned above.\nCleaning up the documentation sites etc.\nStatus comms campaign is coming so articles in planning will be drafted and\n\nChristian - Podcast §\n\nPodcast release plan is being solidified and reviewed https://docs.google.com/document/d/1ppSb_Fkdw3iirwzlEgTvYpkq3n00ds4Xz5KE3mgqA-E/edit?usp=sharing\nReview process is set up and open for feedback.\n\nNick - Content §\n\nDecks for townhall are coming and will be ready for next week.\nImages for LPE content is being vetted. We are looking to establish a style for the first article to set the tone for the following. This is holding it back a bit but once it is set we can move it from there.\n\nLouisa - Events §\n\nBy the end of next week we will launch global event strategy post-review. Includes templates and structures for the future.\nNetwork State Event needs to lock down the potential event speakers, how to communicate with them and basically get a review. Nimbus and Waku and Codex will be there. We need to fix the program and agree on it. Venues shortlisted by the end of the week.\n8 agencies have been briefed as event organisers. Needs to be locked and set by end of week.\nETH Rome, Logos and Waku are sponsoring and Jarrad is talking. Paralelni Polis is happening late September. Working on the details to hit production deadlines.\nBeginning work on hacakthon in Seoul end of February 2024.\n\nMovement Building - Santiago §\n\nComms plans LPE, Status and Logos Community plans are on good track. Carl reviewed and asked for 90 day plans plus timelines.\nLogos community structure is being developed to guide people through an engagement/leadership ladder that serves our purpose. First community coming in will be our testing phase pre-growth.\nLPE launch plan is being reviewed and has a budget verbally approved to push via paid ads. Focus mostly on Snowden on episode as a roundabout way to support awareness for Logos.\nBU Plans, pretty much done, will send them to Al asap for review.\n"},"acid/updates/2023-09-21":{"title":"2023-09-18 Acid Update","links":[],"tags":["acid-updates"],"content":"Overview/Priorities §\n\nAl departure\n\nShort term - We need to stabilise, Al brought a lot of value, we may have to step up a little bit, will meet with Carl and Jarrad weekly.\nLong term - positive changes internally, open culture, open feedback, etc.\nTownhalls - Christian will be point of contact. With Santiago to support. The idea is plan 3-6 months in advance.\nComms strategy - Adjusting it to be more strategic and concise. with focus on Brand Awareness & BU Needs, measuring Impact & clear timeline.\nVirtual office - Available for anyone to join Santiago and Ned to discuss, ask questions, hangout.\nTo team leads: please implement feedback mechanisms that are safe for people. Open up first about shortcomings and promote healthy criticism and exchange. Copy the After Action Review model if necessary for each project delivery and a regular one at your discretion. We want to be better together and trust each other. It is a marker of a successful organisation.\n\n\n\nAmir - Tech & Design §\n\nImprovements on LPE. RSS feed, Discord bot integration, X threads can be previewed\nIntegration of Odoo for email client is with infra.\nLogos System Design (LSD) is being optimised.\n\nMatt / Sterlin - Copy §\n\nPlethora of words to the LPE. Focus there. Make sure the content looks and feels good. Sterlin feels writing looks good in relation with other similar projects.\nMatt and Sterlin are working on the Status blog posts for the upcoming launch.\nAmelia is working on the BU updates.\nRick is the social media master, making really good progress on setting up a solid base and communication with the BUs in regards to their needs.\n\nNick - Digital Content Studio §\n\nNew meeting with Jarrad to get his involvement in the day to day things, he has clarity re: guests, shifting content and style. Objective is to have conversations that inform our thinking about network states, governance, etc. Cater content for Jarrad to build his skill as a speaker and host.\nProduction value is an important improvement point.\nLooking for more people to join as motion designer for video help.\nSwag for ETH Rome needs feedback but is on it’s way and on time.\nPodcast: we have a solid buffer of interviews for HiO and Logos that allows us to have time for strategic changes.\nPodcast: New stream/recording subscription needs to be approved by someone else to move forward.\n\nSantiago - Movement Building §\n\nComms strategies - overall, as a master guideline, we should be creating a movement around network states and not a network state, as a key player and a thought leader. From people developing privacy tech, charter cities, etc. To invest all our resources to creating spaces (physical x digital) for the different parties.\nJarrad: We want authentic organic interaction and conversations like a learning community.\nNick feedback : To approach which conversations/guests are more appropriately placed in which formats, because production time need to be mindful (podcast, twitter space, etc.)\nLPE launch awaits Comms strategy realignment.\n\nLouisa - Events §\n\nHolding back on global guidelines and event strategy once comms strategy is in place.\nJarrad is speaking at POW and HCCP. Decks coming ASAP.\nETH Rome: investing in bounties, smaller meetups are coming. We need booth, merch, swag design this week. Railgun collab with Waku.\nIstanbul: Just some alignment needed re: names and others. Vac, Nimbus and Waku will be there, think about how to overlay design work.\n"},"acid/updates/2023-10-03":{"title":"2023-10-10 Comms weekly","links":[],"tags":["acid-updates"],"content":"Overview/Priorities §\n\nComments from the BUs about blockers and miscommunications - Reevaluation of our comms strategy: BUs are responsible for DevRel, BD, and technical content. We’re responsible for QC of outgoing content (wordsmiths, video editing, and packaging) and non-technical content. This will be communicated with them and consolidated along with the strategy asap.\nNew Mantra: Brand awareness and Learning Communities, which are both measurable by proxy. This means we focus more on performance and growth KPIs and reporting these clearly to C/J.\nWith clear success metrics in place + costs and resources used we can finally focus on optimise our efforts and use it as a way to guide conversations about prioritising requests. This includes things like revisiting the creation of swag for each event etc.\nNew champions model for each BU. https://miro.com/app/board/uXjVPOFj6t8=/. We have an account manager/ implement, test it and iterate as soon as possible\n\nAmir - Tech & Design §\n\nLogos System Design new version (design) is done. Development continue with Joao. Will move on to documentation.\nLPE project is done. Optimising the scoring system for the search pending a lot of content. V1 is officially done. Renamed to Network State Press\nIhor working on sketches and directing of Institute of Free Tech. Will share soon.\nBDP - brand design portal, we designed and managed the dev before but now on hold. For now focus on Brand Guidelines in Docusauraus for BUs.\n\nNick - Digital Content Studio §\n\nPresentations, swag work with Veronika & Video for events.\nJonny has presented a few options for the podcast\n\nChristian - Podcast §\n\nOpen to doing Twitter spaces, in another category to keep it more streamlined and controlled. He wants interactive discussions, open quesitons, brainstorming etc.\nCurrently QC of Snowden\nNo new interviews, just doing checks of Ameen, Baylina and Assange. Will have it ready\nJarrad will present the townhall\n\nMatt - Copy §\n\nStatus articles - Sterlin and Matt.\nBU Docs sites - Amelia. - good to go.\nMode of presentation guidelines (part of brand guidelines) for BUs - by Matt.\nDevelp site for Nimbus - Rick\nIFT landing page - Rick\nCollectively, series of articles about beginner’s guide to Network States.\n\nSantiago - Movement Building §\n\nFocusing on brand awareness and growth - we will set up reporting structures for Carl and Jarrad that are numbers based in relation to cost effectiveness.\nOdoo Email tool is with infra - configuration needed of the external SMTP server.\nFinding a PR moments for the raise.\nNext week and a half will be focused on updating the Logos server to have a proper onboarding strategy to optimise for a learning community experience. Will meet with Eddy and Jen to do this. Jen is currently updated all the all the Discord servers.\n\nLouisa - Events §\n\nPOW and HCCP done - challenge not enough brand awareness\nMetrics and dashboards to get a clear impact on KPIs related to events.\n\nJ&F - Project Management §\n\nAssessment for workspace, work/information flow and dashboard optimization intra and inter teams and projects.\nOrganize around BUs and content pipelines\nTools assessment\n"},"acid/updates/2023-10-17":{"title":"2023-10-25 Comms weekly","links":[],"tags":["acid-updates"],"content":"ACID ROUND UP - OCT. 17\nOverview/Priorities\n\nWorkflows / Champions model: Reporting structure necessary.\nReporting to C+J: ClickUp dashboards.\nBrand Guidelines: In process of improvements.\nIstanbul NSF event cancelled. Will find more opportunities in first half of 2024.\n\nTech & Design\n\nLSD finetuning.\nNomos team requested executable code inside documentation website.\nDocumentation for Docusaurus site. Every BU can deploy their own documentation\nIntegrating the Logos job listings on IFT website - working with JB and Flo.\nNo integrated requirement checklist for what the roadmap should be for all the org. It is not clear if this is one project or several. Different reporting structures per BU makes this complex. Focus on task / “bounty” list\nFinish up guidelines pages\n\nDigital Content Studio\n\nAna (new visual designer) joined last week. Helping on branding designs.\nPodcast templates for cutout animations are good to go. Match options for outputs.\nTwitter Spaces has an overlap with podcast pipeline. Jarrad also wants a easy going convo type setup for his own thinking and this is a bit. Needs to sync with MF.\nMatt and Nick sign off on LPE Article Headers/Social images\n\nPodcast\n\nQuality control got version of Jordi Baylina episode with new graph. Will be ready soon.\nSnowden episode needs a change in the graph at the beginning and needs date change when we know it will launch\n\nCopy\n\nDoc sites are all live except for Waku - pending some small changes.\nNimbus websites might be getting close to launch.\nCarl asked for a beginner series for the network state concept, including a call to action that makes it easy for them to get to the beginner friendly content.\nIFT copy is in Carl’s hands and we are waiting for review.\n3 tech one pagers for Matt and the fundraising team are done.\n\nMovement Building\n\nTwitter Spaces idea for each BU is being discussed internally. Ideas to use https://docs.google.com/document/d/1yOPPsZqKzf6__zuCsFYRsDDkk-lYX—vjRoz6e7OYK4/edit\nWorking on events stuff and postponing Network State Forum event for next year\nWe are running and testing ads on promoting our Twitter Spaces and have pivoted to growing our brand following online to lead into a big event. Potentially hackathon around the all hands meeting etc.\nPR company: onboarding is happening, they are asking good questions there\nStatus: Launch the community campaign. John wants to launch Nov 1.\nPaid Twitter Ads: Carl asked to run test ad. 2k for Logos space tweet. so far, 800k impressions. 125 followers gained so far. We will use this for benchmarking.\nNSP: held up as Jarrad is reviewing content and Carl is pending.\nWaku: feedback from Rome, mentioned that people come to them what is Waku/Status/Logos and how does everything fit. They don’t have a clear answer. We are fixing this.\nTalking to Lou re: events, we can approach Waku marketing as short term campaigns initially November-December. Will propose an awareness campaign to see what can be done with existing resources.\n\nEvents\n\nDifferent scenarios for Istanbul. Looking at whether we co-sponsor EthGlobal Istanbul.\nWaku will be doing EthGlobal India. EthGlobal Istanbul too expensive (40k) for Waku alone so we might co-sponsor.\nSpeaking to EthDenver for next year + an Africa strategy for Waku.\nSet up and manage events and KPIs and reporting in Click Up via forms that external people to the comms team can fill in.\nWe need a proper lead time for activation campaigns to maximise participation, social awareness etc. This is in planning.\nVideo footage from EthCC Paris event still unedited. If there are requests, we can edit it for that purpose.\nWriting a brief for event managers\n\nProject Management\n\nWorkflows reviews and optimizations based on strategy, goals and champions model\nPM and reporting set-up in ClickUp\n"},"acid/updates/2023-10-24":{"title":"2023-10-25 Comms weekly","links":[],"tags":["acid-updates"],"content":"Overview/Priorities\n\nWe are on the right track re: reporting, champions model and outputs. Full update here: https://doc.clickup.com/9009185920/p/h/8cfuh40-13894/965f96f62ea5053\n\nTech & Design\n\nIFT website desktop version almost ready\nLogos Brand Guidelines are being updated\nDocusauraus updates - workshop for BUs to enable them to do content updates\nJobs will be added to every BU website and IFT\n\nDigital Content Studio\n\nContent guidelines in the works, summarising everything and putting it all together to make it functional.\nSwag and presentations are coming in according to plan - nothing of note.\nJonny working on proposal for NPS UX/structure in Figma based on conversation with nick and Amir yesterday\n\nPodcast\n\nPulling together detailed rollout doc with assets and exact copy for Al to send to Snowden and Assange for approvals and coordination.\nGet Stella out - audio quality is much better than Snowden’s so it’s good to go.\n\nCopy\n\nIFT is ready and getting published by EOW.\nNo news for copy re: NSP. Soft launch projected for this week for NSP.\nBeginner friendly piece by Rick for NSP is in production.\nEvent promotion for Logos EthGlobal Pragma presence.\nSocial buffer for Logos is set and ready. In depth threads re: philosophy and connection with each part of the tech stack.\n\nMovement Building\n\nLogos Discord structure: https://docs.google.com/document/d/1N0vgj7GIHllJ9YI912WdMetSEELMBzuWbRKl8NXjXCA/edit#heading=h.ebfdikfy2j9v\nLogos Forum gets traffic due to paid ads, please pay attention and move discussions there as much as is natural.\nFeedback from Jarrad: we need to focus on creating shareable cultural artifacts. For example, transcribing Twitter spaces into forums. Lazar suggested using the radical _anarchy salon content too.\nSoft launch of NSP will happen this end of week. Next week we go with main launch.\nTwitter paid ads were running on space. Report is complete and ready to be shared.\nGrowth strategy with Logos paid ads and Network state paid ads will be completed soon and shared with all.\nLegal: long story short is they will ask to have the least possible changes to the privacy policy but changes we asked for should be ready to be implemented.\n\nEvents\n\nWaku will be the main brand at ETHGlobal Istanbul to avoid confusion and to optimise\nLogos will be present at Pragma - we maximise brand awareness and want to test\nWider event marketing campaign needs to be clear. Distinct posts, tracking impact.\nDashboard on ClickUp for KPIs is in the works. Focus on optimising event attendance vs cost and resources.\n2024 is in the works. Africa events outline for Waku, ETH Denver already contacted.\n\nProject Management\n\nSetting up workspace, PM and reporting in click up with teams and get audit with Clickup experts. Onboarding next week.\n"},"codex/milestones-overview":{"title":"Codex Milestones Overview","links":[],"tags":["milestones-overview"],"content":"Milestones §\n\nZenhub Tracker\nMiro Tracker\n"},"codex/monthly-reports/2023-oct":{"title":"2023 October Codex Monthly Report","links":["codex/updates/2023-10-23"],"tags":["monthly-report","codex"],"content":"Executive Summary §\nIn the first half of the month, the team had an Offsite which focused on concretizing solutions around the MVP and planning out the required work to deliver the MVP by the end of the year.\nAll work after the offsite this month has been focused on the tasked out work that was planned during the offsite.\nThe Ethereum Foundation collaboration on Data Availability Sampling is coming to an end, all of the work associated with it was summed up here.\nKey Updates §\nPersonnel §\nA new job role was put up for a Technical Business Development Lead for Codex. This work will be dedicated to establishing and maintaining relationships with business partners interacting with the Codex Network. As the MVP and testnet get closer to launch, it is expected that these core relationships will need to be forged and cultivated.\n\nlots of upskilling and training new CCs (all people on client < 4 months old).\n\nMilestones §\nThere was only one weekly update this month so it can be referenced for milestone updates, the link is down below.\nThe Ethereum Foundation collaboration on Data Availability Sampling is coming to an end, all of the work associated with it was summed up here. A subsequent report will be created that looks at the pros and cons of the engagement to inform both other Logos projects and future similar Codex engagements.\n\nfat trimmed that wasn’t required for MVP (maybe get a list of these things).\n\nPerceived Changes in Project Risk §\nThe project maintains its track to deliver the Codex MVP by the end of the year. The offsite that took place mapped out the specific work to be done, and who is tasked to do it within the team.\nmore confident that it will be delivered on time based on scope of work and current team makeup and planning from off-site\nthere is no expected delay to delivering the MVP and testnet by the end of the year. and debugging infra for monitoring failures with testnet.\nFuture Plans §\nInsight §\nThe Codex roadmap has yet to be ported over to this website, but now that the offsite is complete and the roadmap is more concrete, that transition should happen quickly within the next month.\nThis should allow us to ramp up the automated monitoring and create development activity dashboards. It is hoped that we have a development dashboard established by next month and a section within the monthly report that describes quantitative measurements of project development.\nProject §\nall focus is on current MVP and associated testnet\ncurrent MVP is minimum marketplace integrated with client and proving scheme. Proving scheme needs coding out and plugged into client. Need client itself to reflect recent changes in merkelization and block transfer.\nget testnet up and running, internal (logos/status) dogfooding for this year’s MVP, then to build monitoring and participation metrics over next year to prep for mainnet launch.\nSources and Useful Links §\nWeekly Reports\n\n2023-10-23\n"},"codex/monthly-reports/2023-sept":{"title":"2023 September Codex Monthly Report","links":["codex/updates/2023-09-15","content/codex/updates/2023-09-29"],"tags":["monthly-report","codex"],"content":"Executive Summary §\nSeptember updates for the Codex project were main focused on the ongoing research and analysis of the proofing schemes and their impact on the overall architecture and network economy.\nKey Updates §\nPersonnel §\nA new Business Development (BD) job description was posted and candidates are currently being interviewed. This role is expected to help facilitate strategy around the much needed partnerships for Codex and liaise with the other BD related resources we have within Logos to ensure efficient communications.\nMilestones §\nThe Codex team is broken up into 5 sections, and the weekly reports give details on how each of them have performed. Currently the Milestone definitions are not in line with this reporting process and will be worked on in the subsequent month. The teams are broken up into the following sections:\n\nClient\nInfra\nMarketplace\nResearch\nDAS\n\nBelow is summary of key updates to these sections over the month of September 2023\nClient §\nThe client continues to push towards Milestone 1.3: Codex v1.0 - Katana, which is slotted to be completed by the end of the year. Significant work has been done on merkelization which is required in order to integrate the proving system, and can be followed in this working branch.\nThe Block Exchange protocol got some attention and refinement. Notes on the associated thoughts can be found in these two writeups:\n\nBlock Discovery Problem\nCodex Swarm Overlays\n\nIn an effort to focus on the critical development path, this work is paused in lieu of attention on the distributed systems testing work.\nProgress was made on the ability for Codex to manage asynchronous and threaded disk IO. In the process of doing this work, a bug within Nim’s SharedPtr was discovered and fixed.\nInfra §\nA Grafana and Kibana instance were deployed in order to facilitate the various testing being done.\nMarketplace §\nIn order to alleviate a concurrency issue with Data Availabilities in the contract, a Reservation System has been proposed and worked on. This removes the previous constraint that current downloads was limited by the number of Availabilities.\nResearch §\nThe Codex Whitepaper v0.1 was drafted and scheduled for release in October 2023. It is currently under review and improving based on feedback.\nThere has been a large discussion this month around Erasure Coding (EC) for sampling. An analysiswas performed which looked at the various effects Erasure Coding schemes have on the sampling process and associated data guarantees. A quote of the conclusion on parameter choices is below:\n\n\n \n Quote \n \n \n\nwe cannot have a small slot size, because that would mean too many proofs by a node (≈ 1 Tb seems to be a minimum)\nwe cannot have a too small block size, because the Merkle tree of the commitments will take too much space (say a minimum of 1024 bytes)\nwe cannot have a too big “checked sample” size, because we cannot do proofs for large amount of data (say a maximum of 65536 bytes)\nwe cannot have too much sampling checks per slot, because we cannot do proofs for many samples (depends on the block size and SNARK tech)\nwe probably want as big N, K parameters as possible, but actual implementations have limit\n\n\nA short review of the Interleaving Schemes for Multidimensional Cluster Errors was performed here and some general notes on Erasure Coding as it pertains to Codex was written up here. Much of these thoughts is being captured in the Erasure Coding Proofing document here. The conclusion section (at time of writing) is copied here for convenience:\n\n\n \n Quote \n \n \nIt is likely that with the current state of the art in SNARK design and erasure coding implementations we can only support slot sizes up to 4GB. There are two design directions that allow an increase of slot size. One is to extend or implement an erasure coding implementation to use a larger field size. The other is to use existing erasure coding implementation in a multi-dimensional setting.\nTwo concrete options are:\n\nErasure code with a field size that allows for 2^28 shards. Check 20 shards per proof. For 1TB this leads to shards of 4KB. This means the SNARK needs to hash 80KB plus the Merkle paths for a storage proof. Requires custom implementation of Reed-Solomon, and requires at least 1 GB of memory while performing erasure coding.\nErasure code with a field size of 2^16 in two dimensions. Check 160 shards per proof. For 1TB this leads to a shards of 256 bytes. This means that the SNARK needs to hash 40KB plus the Merkle paths for a storage proof. We can use the leopard library for erasure coding and keep memory requirements for erasure coding to a negligable level.\n\n\nIt appears as though the team is preferring to go with the multi-dimensional approach to EC.\nDAS §\nWork continues on the DAS research in coordination with the Ethereum Foundation (EF). As a result of SBC, a blog post was written by the EF that discussed a forward thinking proposal for PeerDAS - a simpler DAS approach using battle-tested p2p components which the team has contributed to (referenced inside). Conversations of relevancy continue.\nA Codex Blog post was published discussing two by-products of the DAS research: the characterization of big block diffusion latency on the existing Ethereum Mainnet and the existence of big organic blocks on Ethereum Mainnet and its implications. The conclusion is quoted below:\n\n\n \n Quote \n \n \nWe have discovered a large number of big blocks (>250 KB) that occur organically every day in the Ethereum Mainnet. We have measured the propagation time of those blocks in three different world regions and compared their latency based on geographical location as well as block size. We have analysed how these propagation differences are reflected in the five CL clients separately, as they have different ways of reporting blocks. The empirical results measured in Ethereum Mainnet and presented in this work give us the first clear idea of how block propagation times might look when EIP-4844 is deployed, and 1 MB blocks become the standard and not the exception.\nIn the future, we plan to continue with these block propagation measurements and monitor the behaviour of big blocks in the Ethereum network. Additionally, we want to help different CL clients harmonise their event recording and publication systems in order to be able to compare CL clients between them.\n\nDiscussions with Felix Lange began around some fixes for Discv5.\nOther §\nA Codex YouTube channel has been setup and many tutorial videos and conference talks were uploaded. Go like and subscribe!\nPerceived Changes in Project Risk §\nIn an effort to meet the MVP launch by the end of the year, significant resources have been diverted to engineering efforts. Jessie has taken on more responsibility in the administration and project management duties while Dmitriy has started to focus more on the research and engineering needs\nThe ongoing research around the Data Availability Proof system still has potential to have drastic changes to the overall architecture of the system and associated resource costs of the various participants within the Codex Network. It is unclear how “locked in” parts of the system are that are included in the MVP launch.\nFuture Plans §\nInsight §\nBecause of the mismatch of weekly updates with Milestone definitions, it is difficult to assess the impact of any given update. Next month should have all milestone definitions within this site and a reporting structure that is more intuitively associated with it. It has been noted that the current structure makes it difficult to track cross-team work which the changes next month hope to fix.\nA Logos Collaborations section will be included next month to highlight differences in alignment with the Logos Collective as well as cross project collaboration updates.\nThe reporting process has missed a lot of work around the network simulation and modeling of Codex, which we expect to be corrected by next month by previously mentioned actions.\nDepending on the uptake and viability of the Waku reporting process to other projects, then a myriad of quantitative measures will be included in the next monthly report.\nProject §\nNEED INPUT HERE\nSources and Useful Links §\n\nZenhub tracker - mapping of milestones -> epics -> issues\nMay 2023 - Codex Project Status Report - list of risks and details on the milestones\n\nWeekly Reports\n\n2023-09-15\n2023-09-29\n"},"codex/overview":{"title":"Codex Roadmap Overview","links":["codex/monthly-reports/2023-sept","codex/milestones-overview","tags/codex-updates"],"tags":["overview"],"content":"Welcome to the Codex Roadmap Overview\n\n2023 September Report\nMilestones\nweekly updates\n"},"codex/updates/2023-07-21":{"title":"2023-07-21 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex update 07/12/2023 to 07/21/2023 §\nOverall we continue working in various directions, distributed testing, marketplace, p2p client, research, etc…\nOur main milestone is to have a fully functional testnet with the marketplace and durability guarantees deployed by end of year. A lot of grunt work is being done to make that possible. Progress is steady, but there are lots of stabilization and testing & infra related work going on.\nWe’re also onboarding several new members to the team (4 to be precise), this will ultimately accelerate our progress, but it requires some upfront investment from some of the more experienced team members.\nDevOps/Infrastructure: §\n\nAdopted nim-codex Docker builds for Dist Tests.\nOrdered Dedicated node on Hetzner.\nConfigured Hetzner StorageBox for local backup on Dedicated server.\nConfigured new Logs shipper and Grafana in Dist-Tests cluster.\nCreated Geth and Prometheus Docker images for Dist-Tests.\nCreated a separate codex-contracts-eth Docker image for Dist-Tests.\nSet up Ingress Controller in Dist-Tests cluster.\n\nTesting: §\n\nSet up deployer to gather metrics.\nDebugging and identifying potential deadlock in the Codex client.\nAdded metrics, built image, and ran tests.\nUpdated dist-test log for Kibana compatibility.\nRan dist-tests on a new master image.\nDebugging continuous tests.\n\nDevelopment: §\n\nWorked on codex-dht nimble updates and fixing key format issue.\nUpdated CI and split Windows CI tests to run on two CI machines.\nContinued updating dependencies in codex-dht.\nFixed decoding large manifests (PR #479).\nExplored the existing implementation of NAT Traversal techniques in nim-libp2p.\n\nResearch §\n\nExploring additional directions for remote verification techniques and the interplay of different encoding approaches and cryptographic primitives\n\nhttps://eprint.iacr.org/2021/1500.pdf\nhttps://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html\nhttps://eprint.iacr.org/2021/1544.pdf\n\n\nOnboarding Balázs as our ZK researcher/engineer\nContinued research in DAS related topics\n\nRunning simulation on newly setup infrastructure\n\n\nDevised a new direction to reduce metadata overhead and enable remote verification https://github.com/codex-storage/codex-research/blob/master/design/metadata-overhead.md\nLooked into NAT Traversal (issue #166).\n\nCross-functional (Combination of DevOps/Testing/Development): §\n\nFixed discovery related issues.\nPlanned Codex Demo update for the Logos event and prepared environment for the demo.\nDescribed requirements for Dist Tests logs format.\nConfigured new Logs shipper and Grafana in Dist-Tests cluster.\nDist Tests logs adoption requirements - Updated log format for Kibana compatibility.\nHetzner Dedicated server was configured.\nSet up Hetzner StorageBox for local backup on Dedicated server.\nConfigured new Logs shipper in Dist-Tests cluster.\nSetup Grafana in Dist-Tests cluster.\nCreated a separate codex-contracts-eth Docker image for Dist-Tests.\nSetup Ingress Controller in Dist-Tests cluster.\n\n\nConversations §\n\nzk_id — 07/24/2023 11:59 AM\n\n\nWe’ve explored VDI for rollups ourselves in the last week, curious to know your thoughts\n\n\ndryajov — 07/25/2023 1:28 PM\n\n\nIt depends on what you mean, from a high level (A)VID is probably the closest thing to DAS in academic research, in fact DAS is probably either a subset or a superset of VID, so it’s definitely worth digging into. But I’m not sure what exactly you’re interested in, in the context of rollups…\n\n\n\nzk_id — 07/25/2023 3:28 PM\nThe part of the rollups seems to be the base for choosing proofs that scale linearly with the amount of nodes (which makes it impractical for large numbers of nodes). The protocol is very simple, and would only need to instead provide constant proofs with the Kate commitments (at the cost of large computational resources is my understanding). This was at least the rationale that I get from reading the paper and the conversation with Bunz, one of the founders of the Espresso shared sequencer (which is where I found the first reference to this paper). I guess my main open question is why would you do the sampling if you can do VID in the context of blockchains as well. With the proofs of dispersal on-chain, you wouldn’t need to do that for the agreement of the dispersal. You still would need the sampling for the light clients though, of course.\n\n\ndryajov — 07/25/2023 8:31 PM\n\nI guess my main open question is why would you do the sampling if you can do VID in the context of blockchains as well. With the proofs of dispersal on-chain, you wouldn’t need to do that for the agreement of the dispersal.\n\nYeah, great question. What follows is strictly IMO, as I haven’t seen this formally contrasted anywhere, so my reasoning can be wrong in subtle ways.\n\n(A)VID - dispersing and storing data in a verifiable manner\nSampling - verifying already dispersed data\n\ntl;dr Sampling allows light nodes to protect against dishonest majority attacks. In other words, a light node cannot be tricked to follow an incorrect chain by a dishonest validator majority that withholds data. More details are here - https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html ------------- First, DAS implies (A)VID, as there is an initial phase where data is distributed to some subset of nodes. Moreover, these nodes, usually the validators, attest that they received the data and that it is correct. If a majority of validators accepts, then the block is considered correct, otherwise it is rejected. This is the verifiable dispersal part. But what if the majority of validators are dishonest? Can you prevent them from tricking the rest of the network from following the chain?\nDankrad Feist\nData availability checks\nPrimer on data availability checks\n\n\n[8:31 PM]\nDealing with dishonest majorities §\nThis is easy if all the data is downloaded by all nodes all the time, but we’re trying to avoid just that. But lets assume, for the sake of the argument, that there are full nodes in the network that download all the data and are able to construct fraud proofs for missing data, can this mitigate the problem? It turns out that it can’t, because proving data (un)availability isn’t a directly attributable fault - in other words, you can observe/detect it but there is no way you can prove it to the rest of the network reliably. More details here https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding So, if there isn’t much that can be done by detecting that a block isn’t available, what good is it for? Well nodes can still avoid following the unavailable chain and thus be tricked by a dishonest majority. However, simply attesting that data has been publishing is not enough to prevent a dishonest majority from attacking the network. (edited)\n\n\ndryajov — 07/25/2023 9:06 PM\nTo complement, the relevant quote from https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding, is:\n\nHere, fraud proofs are not a solution, because not publishing data is not a uniquely attributable fault - in any scheme where a node (“fisherman”) has the ability to “raise the alarm” about some piece of data not being available, if the publisher then publishes the remaining data, all nodes who were not paying attention to that specific piece of data at that exact time cannot determine whether it was the publisher that was maliciously withholding data or whether it was the fisherman that was maliciously making a false alarm.\n\nThe relevant quote from from https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html, is:\n\nThere is one gap in the solution of using fraud proofs to protect light clients from incorrect state transitions: What if a consensus supermajority has signed a block header, but will not publish some of the data (in particular, it could be fraudulent transactions that they will publish later to trick someone into accepting printed/stolen money)? Honest full nodes, obviously, will not follow this chain, as they can’t download the data. But light clients will not know that the data is not available since they don’t try to download the data, only the header. So we are in a situation where the honest full nodes know that something fishy is going on, but they have no means of alerting the light clients, as they are missing the piece of data that might be needed to create a fraud proof.\n\nBoth articles are a bit old, but the intuitions still hold.\n\n\nJuly 26, 2023\n\n\nzk_id — 07/26/2023 10:42 AM\nThanks a ton @dryajov ! We are on the same page. TBH it took me a while to get to this point, as it’s not an intuitive problem at first. The relationship between the VID and the DAS, and what each is for is crucial for us, btw. Your writing here and your references give us the confidence that we understand the problem and are equipped to evaluate the different solutions. Deeply appreciate that you took the time to write this, and is very valuable.\n\n\n[10:45 AM]\nThe dishonest majority is critical scenario for Nomos (essential part of the whole sovereignty narrative), and generally not considered by most blockchain designs\n\n\nzk_id\nThanks a ton @dryajov ! We are on the same page. TBH it took me a while to get to this point, as it’s not an intuitive problem at first. The relationship between the VID and the DAS, and what each is for is crucial for us, btw. Your writing here and your references give us the confidence that we understand the problem and are equipped to evaluate the different solutions. Deeply appreciate that you took the time to write this, and is very valuable.\ndryajov — 07/26/2023 4:42 PM §\nGreat! Glad to help anytime\n\n\nzk_id\nThe dishonest majority is critical scenario for Nomos (essential part of the whole sovereignty narrative), and generally not considered by most blockchain designs\ndryajov — 07/26/2023 4:43 PM\nYes, I’d argue it is crucial in a network with distributed validation, where all nodes are either fully light or partially light nodes.\n\n\n[4:46 PM]\nBtw, there is probably more we can share/compare notes on in this problem space, we’re looking at similar things, perhaps from a slightly different perspective in Codex’s case, but the work done on DAS with the EF directly is probably very relevant for you as well\n\n\nJuly 27, 2023\n\n\nzk_id — 07/27/2023 3:05 AM\nI would love to. Do you have those notes somewhere?\n\n\nzk_id — 07/27/2023 4:01 AM\nall the links you have, anything, would be useful\n\n\nzk_id\nI would love to. Do you have those notes somewhere?\ndryajov — 07/27/2023 4:50 PM\nA bit scattered all over the place, mainly from @Leobago and @cskiraly @cskiraly has a draft paper somewhere\n\n\nJuly 28, 2023\n\n\nzk_id — 07/28/2023 5:47 AM\nWould love to see anything that is possible\n\n\n[5:47 AM]\nOur setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us\n\n\nzk_id\nOur setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us\ndryajov — 07/28/2023 4:07 PM\nYes, we’re also working in this direction as this is crucial for us as well. There should be some result coming soon(tm), now that @bkomuves is helping us with this part.\n\n\nzk_id\nOur setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us\nbkomuves — 07/28/2023 4:44 PM\nmy current view (it’s changing pretty often :) is that there is tension between:\n\ncommitment cost\nproof cost\nand verification cost\n\nthe holy grail which is the best for all of them doesn’t seem to exist. Hence, you have to make tradeoffs, and it depends on your specific use case what you should optimize for, or what balance you aim for. we plan to find some points in this 3 dimensional space which are hopefully close to the optimal surface, and in parallel to that figure out what balance to aim for, and then choose a solution based on that (and also based on what’s possible, there are external restrictions)\n\n\nJuly 29, 2023\n\n\nbkomuves\nmy current view (it’s changing pretty often :) is that there is tension between: \n\ncommitment cost\nproof cost\nand verification cost\n\n the holy grail which is the best for all of them doesn’t seem to exist. Hence, you have to make tradeoffs, and it depends on your specific use case what you should optimize for, or what balance you aim for. we plan to find some points in this 3 dimensional space which are hopefully close to the optimal surface, and in parallel to that figure out what balance to aim for, and then choose a solution based on that (and also based on what’s possible, there are external restrictions)\nzk_id — 07/29/2023 4:23 AM\nI agree. That’s also my understanding (although surely much more superficial).\n\n\n[4:24 AM]\nThere is also the dimension of computation vs size cost\n\n\n[4:25 AM]\nie the VID scheme (of the paper that kickstarted this conversation) has all the properties we need, but it scales n^2 in message complexity which makes it lose the properties we are looking for after 1k nodes. We need to scale confortably to 10k nodes.\n\n\n[4:29 AM]\nSo we are at the moment most likely to use KZG commitments with a 2d RS polynomial. Basically just copy Ethereum. Reason is:\n\nOur rollups/EZ leader will generate this, and those are beefier machines than the Base Layer. The base layer nodes just need to verify and sign the EC fragments and return them to complete the VID protocol (and then run consensus on the aggregated signed proofs).\nIf we ever decide to change the design for the VID dispersal to be done by Base Layer leaders (in a multileader fashion), it can be distributed (rows/columns can be reconstructed and proven separately). I don’t think we will pursue this, but we will have to if this scheme doesn’t scale with the first option.\n\n\n\nAugust 1, 2023\n\n\ndryajov\nA bit scattered all over the place, mainly from @Leobago and @cskiraly @cskiraly has a draft paper somewhere\nLeobago — 08/01/2023 1:13 PM\nNote much public write-ups yet. You can find some content here:\n\n\nhttps://blog.codex.storage/data-availability-sampling/\n\n\nhttps://github.com/codex-storage/das-research\n\n\n\n\nWe also have a few Jupiter notebooks but they are not public yet. As soon as that content is out we can let you know \nCodex Storage Blog\nData Availability Sampling\nThe Codex team is busy building a new web3 decentralized storage platform with the latest advances in erasure coding and verification systems. Part of the challenge of deploying decentralized storage infrastructure is to guarantee that the data that has been stored and is available for retrieval from the beginning until\nGitHub\nGitHub - codex-storage/das-research: This repository hosts all the …\nThis repository hosts all the research on DAS for the collaboration between Codex and the EF. - GitHub - codex-storage/das-research: This repository hosts all the research on DAS for the collabora…\n\n\n\n\nzk_id\nSo we are at the moment most likely to use KZG commitments with a 2d RS polynomial. Basically just copy Ethereum. Reason is: \n\nOur rollups/EZ leader will generate this, and those are beefier machines than the Base Layer. The base layer nodes just need to verify and sign the EC fragments and return them to complete the VID protocol (and then run consensus on the aggregated signed proofs).\nIf we ever decide to change the design for the VID dispersal to be done by Base Layer leaders (in a multileader fashion), it can be distributed (rows/columns can be reconstructed and proven separately). I don’t think we will pursue this, but we will have to if this scheme doesn’t scale with the first option.\n\ndryajov — 08/01/2023 1:55 PM\nThis might interest you as well - https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a\nMedium\nCombining KZG and erasure coding\nThe Hitchhiker’s Guide to Subspace  — Episode II\n\n\n\n\n[1:56 PM]\nThis is a great analysis of the current state of the art in structure of data + commitment and the interplay. I would also recoment reading the first article of the series which it also links to\n\n\nzk_id — 08/01/2023 3:04 PM\nThanks @dryajov @Leobago ! Much appreciated!\n\n\n[3:05 PM]\nVery glad that we can discuss these things with you. Maybe I have some specific questions once I finish reading a huge pile of pending docs that I’m tackling starting today…\n\n\nzk_id — 08/01/2023 6:34 PM\n@Leobago @dryajov I was playing with the DAS simulator. It seems the results are a bunch of XML. Is there a way so I visualize the results?\n\n\nzk_id\n@Leobago @dryajov I was playing with the DAS simulator. It seems the results are a bunch of XML. Is there a way so I visualize the results?\nLeobago — 08/01/2023 6:36 PM\nYes, checkout the visual branch and make sure to enable plotting in the config file, it should produce a bunch of figures \n\n\n[6:37 PM]\nYou might find also some bugs here and there on that branch \n\n\nzk_id — 08/01/2023 7:44 PM\nThanks!\n\n"},"codex/updates/2023-08-01":{"title":"2023-08-01 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex update Aug 1st §\nClient §\nMilestone: Merkelizing block data §\n\nInitial design writeup https://github.com/codex-storage/codex-research/blob/master/design/metadata-overhead.md\n\nWork break down and review for Ben and Tomasz (epic coming up)\nThis is required to integrate the proving system\n\n\n\nMilestone: Block discovery and retrieval §\n\nSome initial work break down and milestones here - https://docs.google.com/document/d/1hnYWLvFDgqIYN8Vf9Nf5MZw04L2Lxc9VxaCXmp9Jb3Y/edit\n\nInitial analysis of block discovery - https://rpubs.com/giuliano_mega/1067876\nInitial block discovery simulator - https://gmega.shinyapps.io/block-discovery-sim/\n\n\n\nMilestone: Distributed Client Testing §\n\nLots of work around log collection/analysis and monitoring\n\nDetails here https://github.com/codex-storage/cs-codex-dist-tests/pull/41\n\n\n\nMarketplace §\nMilestone: L2 §\n\nTaiko L2 integration\n\nThis is a first try of running against an L2\nMostly done, waiting on related fixes to land before merge - https://github.com/codex-storage/nim-codex/pull/483\n\n\n\nMilestone: Reservations and slot management §\n\nLots of work around slot reservation and queuing https://github.com/codex-storage/nim-codex/pull/455\n\nRemote auditing §\nMilestone: Implement Poseidon2 §\n\nFirst pass at an implementation by Balazs\n\nprivate repo, but can give access if anyone is interested\n\n\n\nMilestone: Refine proving system §\n\nLost of thinking around storage proofs and proving systems\n\nprivate repo, but can give access if anyone is interested\n\n\n\nDAS §\nMilestone: DHT simulations §\n\nImplementing a DHT in Python for the DAS simulator.\nImplemented logical error-rates and delays to interactions between DHT clients.\n"},"codex/updates/2023-08-11":{"title":"2023-08-11 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex update August 11 §\n\nClient §\nMilestone: Merkelizing block data §\n\nInitial Merkle Tree implementation - https://github.com/codex-storage/nim-codex/pull/504\nWork on persisting/serializing Merkle Tree is underway, PR upcoming\n\nMilestone: Block discovery and retrieval §\n\nContinued analysis of block discovery and retrieval - https://hackmd.io/_KOAm8kNQamMx-lkQvw-Iw?both=#fn5\n\nReviewing papers on peers sampling and related topics\n\nWormhole Peer Sampling paper\nSmoothcache\n\n\n\n\nStarting work on simulations based on the above work\n\nMilestone: Distributed Client Testing §\n\nContinuing working on log collection/analysis and monitoring\n\nDetails here https://github.com/codex-storage/cs-codex-dist-tests/pull/41\nMore related issues/PRs:\n\nhttps://github.com/codex-storage/infra-codex/pull/20\nhttps://github.com/codex-storage/infra-codex/pull/20\n\n\n\n\nTesting and debugging Condex in continuous testing environment\n\nDebugging continuous tests cs-codex-dist-tests/pull/44\npod labeling cs-codex-dist-tests/issues/39\n\n\n\n\nInfra §\nMilestone: Kubernetes Configuration and Management §\n\nMove Dist-Tests cluster to OVH and define naming conventions\nConfigure Ingress Controller for Kibana/Grafana\nCreate documentation for Kubernetes management\nConfigure Dist/Continuous-Tests Pods logs shipping\n\nMilestone: Continuous Testing and Labeling §\n\nWatch the Continuous tests demo\nImplement and configure Dist-Tests labeling\nSet up logs shipping based on labels\nImprove Docker workflows and add ‘latest’ tag\n\nMilestone: CI/CD and Synchronization §\n\nSet up synchronization by codex-storage\nConfigure Codex Storage and Demo CI/CD environments\n\n\nMarketplace §\nMilestone: L2 §\n\nTaiko L2 integration\n\nDone but merge is blocked by a few issues - https://github.com/codex-storage/nim-codex/pull/483\n\n\n\nMilestone: Marketplace Sales §\n\nLots of cleanup and refactoring\n\nFinished refactoring state machine PR link\nAdded support for loading node’s slots during Sale’s module start link\n\n\n\n\nDAS §\nMilestone: DHT simulations §\n\nImplementing a DHT in Python for the DAS simulator - https://github.com/cortze/py-dht.\n\nNOTE: Several people are/where out during the last few weeks, so some milestones are paused until they are back"},"codex/updates/2023-08-31":{"title":"2023-08-31 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex Update August 21-31 §\nClient §\nMilestone: Block Merkelization §\n\nStoring and retrieving data using merkle trees\nCoders for merkle trees\nRefine merkle tree construction\n\nMilestone: Block Exchange protocol refinements and simulations §\n\nTracker simulation implementation\nBlock exchange protocol thoughts\n\nhttps://hackmd.io/ydT3AiliS8q2vdixBUXvCQ\n\n\nFollow swarmsim repo for updates\n\nMilestone: Async Disc Access & Threading support §\n\nTests on sharing thread data with refc\nerrorVariable and thread safety\n\nFix error binding in without statement on multiple threads\n\n\nWIP: Prototype proxy IO threadpool\n\nMilestone: Client stability and debugging §\n\nMajor effort to stabilize the Codex client through continuous automated testing\n\nStart discovery after announce address is updated\nStart discovery after announce address is updated\nRetrieve empty blocks\n\n\n\nInfra §\nMilestone: Monitoring and Metrics §\n\nInstall Node exporter and Prometheus in Dist-Tests cluster\nGrafana Dashboard updates\nAutomated metrics scraping\n"},"codex/updates/2023-09-15":{"title":"2023-09-15 Codex weekly","links":[],"tags":["codex-updates"],"content":"Client §\nMilestone: Block Merkelization §\n\nContinuing work on merkelization\n\nStoring and retrieving data using merkle trees\nCoders for merkle trees\nRefine merkle tree construction\n\n\n\nMilestone: Block Exchange protocol refinements and simulations §\n\nTracker simulation implementation\nBlock exchange protocol thoughts\n\nhttps://rpubs.com/giuliano_mega/1067876\nhttps://rpubs.com/giuliano_mega/1082104\n\n\nFollow swarmsim repo for updates\n\nMilestone: Async Disc Access & Threading support §\n\nWork on IO threads support\n\nhttps://github.com/codex-storage/nim-datastore/pulls\nSome early integration here - https://github.com/codex-storage/nim-codex/pull/552\n\nBased mostly on https://github.com/codex-storage/nim-codex/pull/545 and prev work by @elcritch\n\n\n\n\n\nMilestone: Client stability and debugging §\n\nMajor effort to stabilize the Codex client through continuous automated testing\n\nInfra §\nMilestone: Monitoring and Metrics §\n\nInstall Node exporter and Prometheus in Dist-Tests cluster\nGrafana Dashboard updates - waiting for public DNS to be setup\nAutomated metrics scraping - waiting for public DNS to be setup\n\nMarketplace §\nMilestone: Availabilities and Reservations §\n\nWork ongoing in\n\nhttps://github.com/codex-storage/nim-ethers\nhttps://github.com/codex-storage/codex-contracts-eth\nhttps://github.com/codex-storage/nim-codex\n\n\nSome recent PRs\n\nhttps://github.com/codex-storage/nim-ethers/pull/54\nhttps://github.com/codex-storage/nim-codex/pull/535\n\n\n\nResearch §\nMilestone: Publications §\n\nWhite paper - https://docs.google.com/document/d/1LCy23m90IHf32aUVhRT4r4772w1BfVcSLaJ0z9VTw9A/edit#heading=h.qs3bayckj5u4\nVarious publications incoming from Csaba\n\nDAS §\nMilestone: DAS Design §\n\nOngoing discussions around - https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541\n\nMilestone: Measurments and simulations §\n\nWork continues on simulating various aspects of the DHT in https://github.com/cortze/py-dht\nCsaba discussed/suggested fixes for Discv5 with Felix Lange\n"},"codex/updates/2023-09-29":{"title":"2023-09-29 Codex weekly","links":[],"tags":["codex-updates"],"content":"Client §\nMilestone: Block Merkelization §\n\nMerkelization current working branch\n\nhttps://github.com/codex-storage/nim-codex/tree/sending-blocks-with-proofs-over-the-network\n\n\n\nMilestone: Block Exchange protocol refinements and simulations §\n\nNot much done on it this past couple of weeks, progress can be tracked here when it resumes\n\nhttps://github.com/codex-storage/swarmsim\n\n\n\nMilestone: Async Disc Access & Threading support §\n\nWork on IO threads support\n\nAll related PRs are here https://github.com/codex-storage/nim-datastore/pulls\n\nWe now have a clear idea of how to implement and integrate it - https://github.com/codex-storage/nim-codex/pull/552\n\n\nfound a leak in Nim’s SharedPtr https://github.com/nim-lang/threading/issues/45 and fix https://github.com/nim-lang/threading/pull/46\n\n\n\nMilestone: Client stability and debugging §\n\nMajor effort to stabilize the Codex client through continuous automated testing\n\nMost team members are working on this on and off, testing is ongoing\n\n\n\nInfra §\n\nInstalled cert-manager in Dist-Tests cluster\nImplemented External OAUTH Authentication for Grafana/Kibana (need to adjust internal authentication)\nExposed Grafana and Kibana\nLosing the logs during Continuous Tests run\n\nResearch §\nMilestone: Publications §\n\nWhite paper ongoing - https://docs.google.com/document/d/1LCy23m90IHf32aUVhRT4r4772w1BfVcSLaJ0z9VTw9A/edit#heading=h.qs3bayckj5u4\n\nMilestone: Sampling for storage proofs §\n\nLarge discussion around erasure coding for sampling\n\nhttps://github.com/codex-storage/zk-research-artifacts/blob/master/sampling/sampling.pdf\nhttps://hackmd.io/DxJzAuTZROulBhPWqScmCg?view\nhttps://github.com/codex-storage/codex-research/pull/184\nhttps://hackmd.io/kxSF8wjPS3arDFcqFJrNDw\n\n\n\nDAS §\nMilestone: DAS Design §\n\nOngoing discussions around - https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541\nspace-DAS (don’t have link), a proposal to use spacefilling curves for sample placement\n\nMilestone: Measurements and simulations §\n\nWork continues on simulating various aspects of the DHT in https://github.com/cortze/py-dht\n"},"codex/updates/2023-10-23":{"title":"2023-10-25 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Oct 2 - 23 §\n\nWe had a teamwide offsite in Crete from October 6th to the 12th, during which we were able to discuss and come up with concrete solutions around several important pieces of the project aspects such as the proving system and the contract start interactions, as well as plan out outstanding work for our upcoming testnet launch at the end of the year. The meeting was very productive and it helped align the team around the current and future outstanding work in order to hit our big end of year milestone.\n\nClient §\nMilestone: Block Merkelization §\n\nMerkelization concrete PR in review\n\nhttps://github.com/codex-storage/nim-codex/pull/566\n\n\n\nMilestone: Block Exchange protocol refinements and simulations §\n\nSome results were presented during the offsite\n\nhttps://rpubs.com/giuliano_mega/codex-swarms\n\n\n\nMilestone: Async Disc Access & Threading support §\n\nWork on IO threads support (not much progress due to offsite, will be picked up asap)\n\nAll related PRs are here https://github.com/codex-storage/nim-datastore/pulls\n\nWe now how a clear idea of how to implement and integrated it - https://github.com/codex-storage/nim-codex/pull/552\n\n\n\n\n\nMilestone: Sampling and Storage Proofs §\n\nWork on storage proofs is ongoing under https://github.com/codex-storage/zk-research-artifacts/tree/master/storage_proofs\n\nA circom implementation is being worked on in https://github.com/codex-storage/zk-research-artifacts/tree/master/storage_proofs/MVP/circuit\nReference/testing implementation to consume the circuits is done here https://github.com/codex-storage/zk-research-artifacts/tree/master/storage_proofs/MVP/reference\n\n\nAnalysis of the sampling strategies are available here https://github.com/codex-storage/zk-research-artifacts/tree/master/sampling\n\nMilestone: Client stability and debugging §\n\nMajor effort to stabilize the Codex client through continuous automated testing\n\nWork on better log analysis is being done here https://github.com/gmega/logtools\nRunning several load tests with ˜100 nodes using the dist testing framework https://github.com/codex-storage/cs-codex-dist-tests\n\n\n\nInfra §\n\nInvestigating and fixing issues related to Elasticsearch logshipping\n\nInstall Loki in Dist-Tests cluster\nFix Vector errors related to the Kubernetes logs shipping\nConfigure Vector to ship Dist/Continuous-Tests logs to Loki\n\n\n\nResearch §\nMilestone: Publications §\n\nWhite paper ongoing - https://docs.google.com/document/d/1LCy23m90IHf32aUVhRT4r4772w1BfVcSLaJ0z9VTw9A/edit#heading=h.qs3bayckj5u4\n\nDAS §\nMilestone DAS §\n\nOur current engagement with the EF is coming to an end a summary of the work done has been collected here\n\nhttps://hackmd.io/TYqF-wj2SIWwpS2F_PhWzg\n\n\n"},"codex/updates/2023-11-03":{"title":"2023-11-03 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Oct 24th - Nov 3rd §\n\nThe team is working towards deploying a beta testnet by the end of the year, and most work is centered around finishing all the required functionality for that.\n\nClient §\nEpic: Block Merkelization §\n\nMerkelization concrete PR in review\n\nhttps://github.com/codex-storage/nim-codex/pull/566\n\nUnifying the flows\nMaking treeCid to be the same as treeRoot\nStoring proofs in key/value storage\n\n\n\n\n\nEpic: Wiring the Proving System §\n\nWork on storage proofs is ongoing in https://github.com/codex-storage/codex-storage-proofs-circuits\nWork on Poseidon2 is being done in - https://github.com/codex-storage/nim-poseidon2\n\nEpic: Improve Client Stability §\n\nExplored using CI flow for cloud-based benchmark harness, settled on Packer for image scripts Packer scripts - private repo\nSimple logging filtering/merging tool: logtools\nMicrobenchmark of Sql backend in two separate VMs\nRan remaining benchmarks, summary at Benchmark Summary\nExploring behavior of nim-datastore and sqlite\nContinued working on a “quick-and-dirty” test setup, managed to get it working\nQuick PoC for a codex net deployed with Terraform on VMs: Terraform main.tf\nAsync Profiling\n\nMarketplace §\nEpic: End-to-end Testing §\n\nFurther work on multinode integration testing\n\nprevent stuck transactions by async locking nonce sequencing (+ estimate gas)\nOn transaction failure, fetch revert reason with replayed transaction \nSupport logging to file\n[fix] Ensure AsyncLock is released in case of exception \n\n\nfeat: ensure block expiry\n\nInfra §\n\nCreated Testnet Kubernetes cluster 56\nDeployed Testnet cluster basic components 57\nConfigured DNS name for Testnet cluster 76\nCreated Service Accounts in Testnet cluster 77\nChecked CORS issue on Codex Demo 79\nConfigured TCP/UDP port forwarding for Testnet deployment 80\n"},"codex/updates/2023-11-10":{"title":"2023-11-10 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Nov 6th - Nov 10th §\n\nThe team is working towards deploying a beta testnet by the end of the year, and most work is centered around finishing all the required functionality for that.\n\nClient §\nEpic: Block Merkelization §\n\nMerkelization concrete PR in review - mostly ready for merging\n\nhttps://github.com/codex-storage/nim-codex/pull/566\n\n\nWorking on nim-datasotre to support atomic updates\n\nhttps://github.com/codex-storage/nim-datastore/pull/58\n\n\n\nEpic: Wiring the Proving System §\n\nMerged conversion from field elements into bytes in nim-poseidon2\n\nhttps://github.com/codex-storage/nim-poseidon2/pull/6\n\n\nAdded streaming API for Balazs’s sponge in nim-poseidon2\n\nhttps://github.com/codex-storage/nim-poseidon2/pull/9\n\n\nFixed merkle root construction for odd number of elements in nim-poseidon2\n\nhttps://github.com/codex-storage/nim-poseidon2/pull/8\n\n\n2D erasure coding WIP\n\nhttps://github.com/codex-storage/nim-codex/pull/608\n\n\n\nEpic: Improve Client Stability §\n\nAsync profiling (it might actualy work)\n\nhttps://github.com/codex-storage/nim-codex/pull/600\nPrometheus metrics collector completed with tests\n\n\n\nMarketplace §\nEpic: End-to-end Testing §\n\nAddressed access issues within the marketplacesuite template, pinpointing a problem with a provider declared in ethertest and overcoming the challenge through deep template layer analysis.\nDiscussions about improving the repostore maintenance module, specifically the method for returning bytes to Availabilities.\nOptimizing multinode integration tests, streamlining the process to enhance efficiency and performance.\nIntegration test for the proving loop in the sales state module that was previously causing hang-ups, ensuring smoother operation.\nProgressed towards a cleaner integration test structure with the creation of a draft PR, setting the stage for more structured testing and deployment.\n\nInfra §\n\nConfigure TCP/UDP port forwarding for Testnet deployment 80\nOrganize Grafana Dashboards 82\nConfigure Continuous Tests automation 69\nRun Continuous Tests and check metrics\nOrganize Grafana Dashboards\nConfigure Continuous Tests automation enhancement\nUpdate Vector config\nConfigure TCP/UDP port forwarding for Testnet deployment\n"},"index":{"title":"","links":["terms-of-use","tags/monthly-report","waku/","codex/overview","nomos/","vac/","acid/","insight/","innovation_lab/"],"tags":[],"content":"This site attempts to inform the previous, current, and future work required to fulfill the requirements of the projects under the Logos Collective, a complete tech stack that provides infrastructure for the self-sovereign network state. To learn more about the motivation, please visit the Logos Collective Site.\nThis site is an ongoing work in progress. The links within are an attempt to capture a lot of moving targets. This means that the information here may or may not be the bleeding edge of what is true with respect to the development within the Logos Collective projects. Your use of this Website is subject to the following terms of use which we ask you to read carefully prior to your use of the Website.\nNavigation §\n\nMonthly Project Reports\n\nProjects §\n\nWaku\nCodex\nNomos\n\nServices §\n\nVac\nComms (Acid Info)\nInsight\n\nSkunk works §\n\nInnovation Lab\n"},"innovation_lab/index":{"title":"Innovation Lab Roadmap Overview","links":["innovation_lab/milestones-overview","tags/ilab-updates"],"tags":["overview"],"content":"Welcome to the Innovation lab Roadmap Overview\n\nMilestones\nweekly updates\n"},"innovation_lab/milestones-overview":{"title":"Innovation Lab Milestones Overview","links":[],"tags":["milestones"],"content":"iLab Milestones can be found on the Notion Page"},"innovation_lab/updates/2023-07-12":{"title":"2023-07-12 Innovation Lab Weekly","links":[],"tags":["ilab-updates"],"content":"Logos Lab 12th of July\nCurrently working on the Waku Objects prototype, which is a modular system for transactional chat objects.\nMilestone: deliver the first transactional Waku Object called Payggy (attached some design screenshots).\nIt is now possible to make transactions on the blockchain and the objects send notifications over the messaging layer (e.g. Waku) to the other participants. What is left is the proper transaction status management and some polishing.\nThere is also work being done on supporting external objects, this enables creating the objects with any web technology. This work will guide the separation of the interfaces between the app and the objects and lead us to release it as an SDK.\nNext milestone: group chat support\nThe design is already done for the group chat functionality. There is ongoing design work for a new Waku Object that would showcase what can be done in a group chat context.\nDeployed version of the main branch:\nhttps://waku-objects-playground.vercel.app/\nLink to Payggy design files:\nhttps://scene.zeplin.io/project/64ae9e965652632169060c7d\nMain development repo:\nhttps://github.com/logos-innovation-lab/waku-objects-playground\nContact:\nYou can find us at https://discord.com/channels/973324189794697286/1118949151225413872 or join our discord at https://discord.gg/UtVHf2EU\n\nConversation §\n\n\npetty — 07/15/2023 5:49 AM\nthe waku-objects repo is empty. Where is the code storing that part vs the playground that is using them?\n\n\npetty\nthe waku-objects repo is empty. Where is the code storing that part vs the playground that is using them?\n\n\nattila🍀 — 07/15/2023 6:18 AM\nat the moment most of the code is in the waku-objects-playground repo later we may split it to several repos here is the link: https://github.com/logos-innovation-lab/waku-objects-playground\n\n"},"innovation_lab/updates/2023-08-02":{"title":"2023-08-02 Innovation Lab weekly","links":[],"tags":["ilab-updates"],"content":"Logos Lab 2nd of August\nCurrently working on the Waku Objects prototype, which is a modular system for transactional chat objects.\nThe last few weeks were a bit slower than usual because there were vacations, one team member got married, there was EthCC and a team offsite.\nStill, a lot of progress were made and the team released the first version of a color system in the form of an npm package, which lets the users to choose any color they like to customize their app. It is based on grayscale design and uses luminance, hence the name of the library. Try it in the Playground app or check the links below.\nMilestone: group chat support\nThere is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation.\nNext milestone: Splitter Waku Object supporting group chats and smart contracts\nThis will be the first Waku Object that is meaningful in a group chat context. Also this will demonstrate how to use smart contracts and multiparty transactions.\nDeployed version of the main branch:\nhttps://waku-objects-playground.vercel.app/\nMain development repo:\nhttps://github.com/logos-innovation-lab/waku-objects-playground\nGrayscale design:\nhttps://grayscale.design/\nLuminance package on npm:\nhttps://www.npmjs.com/package/@waku-objects/luminance\nContact:\nYou can find us at https://discord.com/channels/973324189794697286/1118949151225413872 or join our discord at https://discord.gg/ZMU4yyWG\n\nConversation §\n\n\nfryorcraken — Yesterday at 10:58 PM\n\nThere is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation.\n\nWhile status-js does implement chat features, I do not know how nice the API is. Waku is actively hiring a chat sdk lead and golang eng. We will probably also hire a JS engineer (not yet confirmed) to provide nice libraries to enable such use case (1:1 chat, group chat, community chat).\n\n\nAugust 3, 2023\n\n\nfryorcraken\n\n > There is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation. While status-js does implement chat features, I do not know how nice the API is. Waku is actively hiring a chat sdk lead and golang eng. We will probably also hire a JS engineer (not yet confirmed) to provide nice libraries to enable such use case (1:1 chat, group chat, community chat).\n\n\n\nattila🍀 — Today at 4:21 AM\nThis is great news and I think it will help with adoption. I did not find a JS API for status (maybe I was looking at the wrong places), the closest was the status-js-api project but that still uses whisper and the repo recommends to use js-waku instead https://github.com/status-im/status-js-api Also I also found the 56/STATUS-COMMUNITIES spec: https://rfc.vac.dev/spec/56/ It seems to be quite a complete solution for community management with all the bells and whistles. However our use case is a private group chat for your existing contacts, so it seems to be a bit overkill for that.\n\n\nfryorcraken — Today at 5:32 AM\nThe repo is status-im/status-web\n\n\n[5:33 AM]\nSpec is https://rfc.vac.dev/spec/55/\n\n\nfryorcraken\nThe repo is status-im/status-web\n\n\nattila🍀 — Today at 6:05 AM\nAs constructive feedback I can tell you that it is not trivial to find it and use it in other projects It is presented as a React component without documentation and by looking at the code it seems to provide you the whole chat UI of the desktop app, which is not necessarily what you need if you want to embed it in your app It seems to be using this package: https://www.npmjs.com/package/@status-im/js Which also does not have documentation I assume that package is built from this: https://github.com/status-im/status-web/tree/main/packages/status-js This looks promising, but again there is no documentation. Of course you can use the code to figure out things, but at least I would be interested in what are the requirements and high level architecture (does it require an ethereum RPC endpoint, where does it store data, etc.) so that I can evaluate if this is the right approach for me. So maybe a lesson here is to put effort in the documentation and the presentation as well and if you have the budget then have someone on the team whose main responsibility is that (like a devrel or dev evangelist role)\n\n"},"innovation_lab/updates/2023-08-11":{"title":"2023-08-17 weekly","links":[],"tags":["team-updates"],"content":"Logos Lab 11th of August §\nCurrently working on the Waku Objects prototype, which is a modular system for transactional chat objects.\nWe merged the group chat but it surfaced plenty of issues that were not a problem with 1on1 chats, both with our Waku integration and from product perspective as well. Spent the bigger part of the week with fixing these. We also registered a new domain, wakuplay.im where the latest version is deployed. It uses the Gnosis chain for transactions and currently the xDai and Gno tokens are supported, but it is easy to add other ERC-20 tokens now.\nNext milestone: Splitter Waku Object supporting group chats and smart contracts\nThis will be the first Waku Object that is meaningful in a group chat context. Also this will demonstrate how to use smart contracts and multiparty transactions. The design is ready and the implementaton has started.\nNext milestone: Basic Waku Objects website\nWork started toward having a structure for a website and the content is shaping up nicely. The implementation has been started on it as well.\nDeployed version of the main branch:\nhttps://www.wakuplay.im/\nMain development repo:\nhttps://github.com/logos-innovation-lab/waku-objects-playground\nContact:\nYou can find us at https://discord.com/channels/973324189794697286/1118949151225413872 or join our discord at https://discord.gg/eaYVgSUG"},"insight/business-analysis/index":{"title":"Insight Business Analysis Overview","links":[],"tags":[],"content":"insight:business-analysis: §\n\ndatalake-repo-ingestion §\nreal-opt-keycard §"},"insight/dao/index":{"title":"Insight DAO Overview","links":[],"tags":[],"content":"insight:dao: §\n\nspiff-process-growth §\nspiff-bounty-experiment §"},"insight/index":{"title":"Insight Team Overview","links":["insight/monthly-reports/2023-oct","insight/dao/","insight/project-reporting/","insight/business-analysis/"],"tags":[],"content":"Description §\nThe insight team acts as a glue within the Logos Collective. They serve development projects by helping to track development activity and aiding in resource allocation. They serve the broader service units within the organization by helping them understand who’s doing what, how much effort is going into each chunk of work, how much it costs, and future projections of milestone delivery.\nThis page tracks the various work that they engage in throughout the org. As this is a service unit and not a project, it does not strictly work off a milestone based approach and has consistent service work to the various groups within the Logos Collective.\nMonthly Reports §\n\n2023 October\n\nCurrent work §\ndao: details §\nproject-reporting: details §\nbusiness-analysis: details §"},"insight/monthly-reports/2023-oct":{"title":"2023 October Insights Monthly Report","links":[],"tags":[],"content":"Executive Summary §\nKey Updates §\nPersonnel §\nA senior and junior software engineer have been brought on to support the ongoing development of SpiffWorkflow.\n\nMichael is a senior python developer with years of experience. He also contributed to SpiffWorkflow in the past by giving it an external security review before it was launched. He will be leading the internal development and mentoring the junior dev.\nKayvon joined as a junior dev to contribute to the ongoing development and web3-ification of SpifWorkflow.\n\nMonthly Highlights §\nSpiffWorkflow §\nThe project has received two new in-house developers so that ongoing maintenance and development can continue. The entire Kanban board is currently held in Notion but may move to somewhere more public in the near future.\nA new release happened that brought about a bunch of bug fixes and improvements, namely (copy/paste from Sasha’s Discord post):\n\nUI/UX changes across the site have been made to make it cleaner and easier to navigate\nNo more copying and sending process instance ID and sending it to someone. There is now a shareable link on each process instance that produces a short link to share.\nA new way to quickly understand where the process is upto. Rather than just seeing in-progress, you will now see things like “Pending Approval - Insights” or “Request Approved” etc. You will see this on the home page and all tables across the platform, under the column name: Last milestone\nHow many times have you wanted to look at the data previously entered into forms? You can now do this with the addition of a new section called My completed tasks, which can be found on the Process Instance Detailed page. This is one of the most requested features!\nWe now support the ability of parallel processing for tasks. Things like calling 3 different APIs can be done in parallel now, significantly speeding up all processes.\nSpiff now allows external systems to call it using APIs. I.e. on some trigger, external systems calls Spiff to start a process or complete a task for an existing process. This will be extremely powerful when integrating with of our systems.\nREADME files about a process are now embedded in Spiff. When you head to the process model page, you will see the About tab, which has a readme.md file with everything you need to know about a process.\nMarkdown support added across the platform\nAdded a tooltip component to the checkboxes in forms to enhance the user experience. Now, when you submit a travel request and are unsure about the Per Diem, simply hover over the checkbox and the help text will appear.\nAuto-approvals for processes. In order to reduce approval time, when someone holds both the role of Budget Owner and is part of the SME group, double-approval is not required. For example, if an Infra Lead provides approval as a Budget Owner for software and licenses, the Infra team review step will be automatically completed (approved). You can find the list of Budget Owners here.\nAdded Event categories to the Request Goods/Services process. The list of purchase categories can be found here\nFixed bugs and errors\nImplemented admin functionality to improve the support team’s ability to assist users when needed\nWe can now invite any external user to complete one/multiple steps in a process, without that user being created within Keycloak/Spiff. This allows us to do things like ask a vendor being onboarded to complete a form or perform a step in process, by simply sending them an email with all instructions. The access is time based password protected.\nIf you come across a missing City in the Travel request drop-down, simply inform the support team. They can add it for you, allowing you to proceed with your request.\n\nKudos to the team for such an awesome amount of work.\nA technical roadmap has begun to be developed which outlines the process of “DAOification” of the organization. The initial focus is on understanding the time-cost of the project and required resources.\nContract Extension Negotiations with Sartography §\n\nSummarizations provided by Eric in legal:\nJust to summarise where we’re at with Sartography as of the latest agreement, Sartography has indicated that they will develop additional SpiffWorkflow components called “SpiffWorkflow Extensions”. The negotiations with Sartography revolve around the issue ownership and licensing of the IP for these SpiffWorkflow Extensions as developed for Status. The points are as follows:\n\n(i) Commercial license instead of an open source license: Originally all Spiffworkflow software would either be open source or be delivered to Status for its ownership. Sartography are insisting on deviating from this approach for the Extensions and intend to apply a commercial license to it. This is an unacceptable position. If they develop IP with Status’ money, then it must align with the original approach.\n(ii) Waiver of fee for commercial license: Sartography have indicated that they are willing to “waive” the fee for any commercial license for the Extensions (referring this as a “gift” to Status). The terms of the commercial license will still need to be negotiated and are unknown to us right now. The waiver of a fee for a commercial license which we don’t have any view on may not be worth much if it turns out to be very restrictive.\n\n\n\nAn image of what Sartography aims to do, important to note this is not funded by Status:\n\nFor the avoidance of doubt, all “original” Spiffworkflow Software still aligns with our original agreed approach i.e. Sartography is obliged to keep it open source and any thing it delivers to Status will belong to Status who is obliged to make it open source.\nPath Forward - Still needs to be finalized by legal; however, Sartography is building an ability to commercialize features that they are developing outside of development with Status. They will extend a commercial license to us and waive all fees associated if Status uses any of those features. All feature they’ve expressed they are building are not features Status would leverage. For example, datastores for personal data and data stores for financial data.\nReal Options Analysis §\nFrederico lead the way on developing a framework (and explainer) for performing Real Options Analysis on Keycard. Keycard was chosen based on its smaller project size and traditional evaluation methodology as a project (the easiest one to start with) with the goal in mind of generalizing the framework for all projects within Logos and Status. The current analysis and framework can be found in Notion for now. Once finalized and reviewed, it may be released for public consumption.\nThis framework is expected to allow us to identify performance and evaluation trends for projects within their respective ecosystems, thus adding valuable insight to the decisions we as an org can make to steer them in the direction of success. More info on this can be seen in Jarrad’s previous townhall (Org internal link - sorry - picture below for public) where he discussed it.\n\nRevamping Accounting with Finance §\nWork continues with the Finance team to revamp the budgeting process for projects and services. The dashboard (mentioned below) being developed has helped track and monitor how money is being spent and allocated across the org.\nProject Dashboards §\nA lot of work has been done to create various dashboards for cohorts across the org. The project dashboards are mainly created from the development activity we can glean from Github thus is heavily dependent upon the team’s reporting and Github tagging process at the moment.\nCurrently, the following dashboards are being worked on and iterated with their respective teams to ensure they’re providing appropriate and correct information (ask Lalo if access if you feel you should have it and don’t):\n\nProject Reporting (Waku)\nProject Reporting (Status)\nBudget Reporting\nMilestone Table\nProcess Performance for Spiff\nWaiting for Twitter API v2 access to be purchased to complete the social engagement dashboard.\n\nThe Waku team gave a presentation on their adapted project reporting process to the PMs across the org and work has been started to adapt projects to something similar to allow for more automation and dashboard creation.\nThe Waku team has reported usefulness in their dashboard already despite it being incomplete (no weighting of work done yet, only tagging issues to epics and epics to milestones).\nFuture Plans §\nNext month, the insights team plans to focus on increasing the coverage of project roadmaps within this website as well as the backend development activity automation coverage for projects.\nThe more we cover projects development activity, the better dashboards we can make to serve them.\nNEED MORE HERE"},"insight/project-reporting/index":{"title":"Insight Project Reporting Overview","links":[],"tags":[],"content":"insight:project-reporting: §\n\nmilestone-publishing: §\n\ncodex\nnomos\nwaku\nvac\n\nmonthly-reports §\nllm-dev-activity §"},"nomos/base-layer-spec/data-availability/index":{"title":"Nomos Data Availability Details","links":[],"tags":[],"content":"nomos:data-availability: §\n\nDescription §\nNomos Data Availability design:\n\nOur Base Layer doesn’t have execution. Only the (global) Coordination Layer has a minimal set of operations.\nOur rollups are quasi-sovereign, meaning that they do not prove their state to the Base Layer, but they have to prove asset deposit/withdrawals, as well as implement the mechanism to pay for using the Base Layer DA+consensus. Note that full sovereignty means no bridging and implementing a client of the DA for the payments.\nWe also have a form of PBS, but enshrined in the L2s. The Base Layer only performs consensus on data that has been dispersed by the Builder. The Proposer is a node in the Base Layer, and the Builder is a node of the Execution Zone.\n\nResearch §\n\nData Availability Specification: https://www.notion.so/Data-Availability-Specification-wip-c3961b681eba4ccdab2be9181e4207b4\n\nEngineering §\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n - Initial data availability implementation: In progress, 2023-09-01, 2023-11-30\n"},"nomos/base-layer-spec/index":{"title":"Nomos Milestone: Full Base Layer Specification","links":["nomos/base-layer-spec/network-privacy/","nomos/base-layer-spec/priv-pos/","content/nomos/base-layer-spec/data-availability/","vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation","vac/tke/g/nomos/economic-analysis"],"tags":[],"content":"nomos:base-layer-spec: §\n\nDescription §\nThe initial milestone of the Nomos project is a full specification of the Base Layer. This entails detailed explanations of the working parts of the architecture and how they lay the groundwork for future layers to be built on top. The working parts are:\n\nA private P2P network\nData availability\nA private Proof-of-State model leveraging a scalable, lightweight consensus algorithm\n\nThis work can be tracked via the following epics.\nKey Epics §\nnetwork-privacy: details §\n\ndue:\nprogress:\nshort description: Creation of a privacy preserving network underlay\n\nprivate-pos: details §\n\nnext deliverable: Sept 29, 2023\nprogress: 99%\nshort description: Creation of a Proof-of-Stake model that preserves the privacy of the stakers within the network\n\ndata-availability: details §\n\ndue:\nprogress:\nshort description: Definition of how Nomos makes data available to network participants, and its reference implementation for the Base Layer.\n\nDependent Upon: §\nvac:dr:carnot-aggregation-spec §\n\ncarnot-2-3rds-vote-aggregation\n\nvac:tke:stake-rewards §\n\neconomic-analysis\n"},"nomos/base-layer-spec/network-privacy/index":{"title":"Nomos Network Privacy Details","links":[],"tags":[],"content":"nomos:network-privacy: §\n\nCurrent Focus §\nMixnet 1.0 - a technology/system that helps keep information sent over the internet private and secure. It does so by mixing up data from different sources before sending it to its destination. In Nomos chain:\n\nMixnet nodes opt-in by publishing their IP and providing stake.\nThe mixnet topology of layers is public and defined on-chain (by some deterministic algorithm using the random-beacon for example).\nAfter certain number of epochs (to be determined), a new set of nodes is chosen and a new topology of Mixnet layers is defined. Nodes need to renew their stake and their keys (for security).\n\nFor more information, check https://www.notion.so/Private-Routing-Mixnet-Network-Privacy-Component-1-613f53cf11a245098c50af6b191d31d2\nResearch §\nCurrent Tasks §\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Viability analysis of the Embedded Mixnet: In progress, 2023-09-18, 2023-10-06\n\nEngineering §\nCurrent Tasks §\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 7day\n dateFormat YYYY-MM-DD \n section Status\n Mixnet 1.0 Stabilization: In progress, 2023-09-18, 2023-09-30\n"},"nomos/base-layer-spec/priv-pos/index":{"title":"Nomos Private Proof of Stake Details","links":[],"tags":[],"content":"Description §\nIn PoS systems, preserving stake privacy is vital to avoid exposing users’ wealth. Different approaches to achieve this include leveraging confidential assets, such as or coin mixing protocols applied to staking.\nCurrent Status §\nResearch phase: writing Private Proof of Stake Specifications:\nDue Date: 2023-09-29\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n PPoS Specifications: In progress, 2023-06-25, 2023-09-29\n"},"nomos/base-layer-testnet/index":{"title":"Nomos Milestone: Base Layer Testnet Implementation","links":["nomos/base-layer-testnet/testnet/","vac/dst/wakurtosis/nomos/ci-integration"],"tags":[],"content":"nomos:base-layer-testnet: §\n\nDescription §\nKey Epics §\ntestnet: index §\n\ndue: October 27th\nprogress: 66% (unstable testnet)\nshort description: deployment of the initial testnet for the Nomos network\n\nDependent Upon: §\nvac:dst:node-cicd §\n\nci-integration\n"},"nomos/base-layer-testnet/testnet/index":{"title":"Nomos Testnet Details","links":[],"tags":[],"content":"nomos:testnet: §\n\nDescription §\nWe aim for having an unstable testnet (asap) with no guarantees on breaking changes:\n\nData can be wiped out at every new rollout\nAccounts may disappear at some point\nThere are no incentives initially (ie no token as it requires data permanence)\nA good first functionality target would be to implement something like Bitcoin’s ordinals (NFTs), since they are just signed data.\n\nMore information: https://www.notion.so/Testnet-55049d959a6145fd9c542c5b3999c65a\nResearch §\nEngineering §\nCurrent Focus §\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Node for Testnet: In progress, 2023-08-28, 2023-10-27\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Client for Testnet: In progress, 2023-09-11, 2023-10-27\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 7day\n dateFormat YYYY-MM-DD \n section Status\n DevOps for Testnet: In progress, 2023-09-11, 2023-09-30\n"},"nomos/consensus-def/index":{"title":"Nomos Milestone: Scalable Consensus Definition","links":[],"tags":[],"content":"nomos:consensus-def: §\n\nDescription §\nThis tracks the work of the initial discovery effort that lays the groundwork for all other work, consensus. A survey of options was undertaken, explored and documented. The product of all the work is Carnot.\nMain whitepaper:\nPseudocode specification of Carnot: https://github.com/logos-co/nomos-specs/blob/master/carnot/spec.md\nStatus: Delivered"},"nomos/index":{"title":"Nomos Roadmap Overview","links":["nomos/monthly-reports/2023-oct","nomos/monthly-reports/2023-sept","nomos/base-layer-spec/","nomos/base-layer-testnet/","nomos/consensus-def/"],"tags":["nomos","roadmap","overview"],"content":"Nomos Overview §\nThe Nomos project is an attempt to make a scalable, modular, and private L1. To learn more about the project, please visit the website\nNomos is currently in its initial phase as a project within Logos, namely the research and architecture design phase.\nLatest Monthly Reports §\n\n2023 October\n2023 September\n\nCurrent Key Milestones §\nbase-layer-spec: details §\n\ndue: 2024 Q1\nstatus: in progress\ndescription: Full specification of the Nomos Base Layer along with accompanying research and justification.\n\nbase-layer-testnet: details §\n\ndue: 2024 Q3\nstatus: in progress\ndescription:\n\ncoord-layer-spec: §\n\ndue: 2024 Q4\nstatus: pending\ndescription:\n\ncoord-layer-testnet: §\n\ndue: 2025 Q1\nstatus: pending\ndescription:\n\n\nDelivered Milestones §\nconsensus-def: details §\n\ndue: 2023 Q3\nstatus: complete\ndescription: Research and specification of an underlying consensus algorithm to be used as foundation for Nomos.\n\n\nUseful Links §\n\nMilestones Overview Notion Page: where the team updates their milestones before being transferred here.\n"},"nomos/monthly-reports/2023-sept":{"title":"2023 September Nomos Monthly Report","links":["vac/acz/","","vac/zkvm/","vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation","nomos/updates/2023-09-04","nomos/updates/2023-09-11","nomos/updates/2023-09-19","nomos/updates/2023-09-26"],"tags":["monthly-report","nomos"],"content":"Executive Summary §\nThe Nomos team continues to stay focused on research related to the fine-grained details of the Base Layer specification and implementation. The addition of a Project Manager is expected to not only expedite the research by allowing the lead to dive deeper into the issues involved but also make that work and progress more transparent.\nMehmet joins the team next month to fulfill a long needed dedicated role in research privacy and zero-knowledge technology as it pertains to the Nomos requirements.\nThe whitepapers plan to be polished and published by early next month which not only details the current specifications but also known problems that need to be solved.\nKey Updates §\nPersonnel §\n\nFilip has joined as a Project Manager (last month) to assist in various activities. His position is to sit in between the Insights team and the Nomos project to facilitate development tracking and resource allocation. It is anticipated that his involvement will speed up development as current resources are then freed to focus on research and development. Until demands within Nomos require full-time engagement from him, he will also be assisting with Vac Program Management.\nAfter a lot of candidate interviews, Mehmet was offered a position and accepted to focus on the privacy and cryptography research needs within the project. His background in cryptography and security auditing of popular zero-knowledge platforms is expected to be very useful in aiding to architect Nomos. Mehmet’s starting date is Oct 2\n\nAnother candidate for this role that was considered, Ramses, has joined the Vac team and will initially be aiding in this work and growing the relationship with their Applied Crypto and Zero-Knowledge team. Ramses started in\n\n\nAn offer has been extended to a candidate for the open role of Applied Network Researcher. He passed all interview rounds but unfortunately passed on the final offer for another opportunity.\nThe roles of Applied Network Researcher and Distributed Systems Researcher are still open and candidates are being interviewed.\n\nMilestones §\nNomos’ roadmap is currently composed of five main sections, each of which is broken up into Research and Development. Obviously, Development lags behind the Research section. These five areas are as follows:\n\nWhitepapers\nNetwork Privacy and Mixnet\nTestnet\nPrivate PoS\nData Availability\n\nThe Milestone definitions and timelines are not yet ported to this site, and as such, are private to Logos. They are planned to be publicized on this site by the end of the this month, potentially bleeding into the beginning of October. For those with Notion access, you can view the Milestone definitions here.\nThe following sections will outline key activity across these milestones. If more information and detail is desired, links can be found under the associated heading among the Sources and Useful Links Weekly updates section.\nWhitepapers §\nThe current Whitepaper drafts are almost ready for publication. They require only “beautification” and a listing of detailed “current unsolved problems” that need to be explored later in the total project. This will be done following the current prioritization of mixnet specification.\nThis milestone will be completed next month.\nNetwork Privacy and Mixnet §\nThe specification of the mixnet is currently underway and expected to wrap up soon (next month??). This initial specification is modeled after the current State of the Art in the mixnet industry. This is chosen to be critical path based on all the depending architectural decisions that stem from decisions of the networking layer.\nReview and analysis of current mixnet literature continues. Throughout this review, a modeling framework was developed in order to help evaluate future (v2) speculative mixnet architectures as compared to the current one. This theoretical framework has already been able to reproduce known results within the industry, such as deriving that the probability of an anonymity failure:\n\ndecreases when increasing the number of layers\nincreases when increasing the number of nodes within a single layer.\n\nFramework and analysis details can be found in the overleaf document.\nWhile research explores subtleties in the mixnet specification, development has tackled the foundations of its implementation on top of libp2p within the nomos-node repository. They’ve logically setup how it connects to the rest of the pieces of the node, setup testing frameworks and node monitoring hooks, and generally got it provisioned for the upcoming testnet.\nTestnet §\nA PoC/Draft Testnet was created and merged via Docker-Compose, then general exploration was done to identify what to measure and how to do it within the nomos-node software.\nSimulations of the branch overlay with 1 committee was conducted. Initial results discovered a bug in reproducibility that was fixed. Additional simulations resulted in discovery of inter-module errors with the leader selection. This is currently being explored along with integration of mixnet developments.\nPrivate PoS §\nResearch was conducted in a variety of areas around a Private Proof of Stake spec relevant to the architecture of Nomos. All details can be found in the Whitepaper descriptions.\nThe initial design was created based on Zcash designs with section details around how “stake” is considered for the Base Layer of Nomos, how “restaking” could work, and various consensus modifications around Carnot. An introduction of “shadows” was done which presents the ideas around the initial voting process. The logic of these “shadows” is currently being fleshed out so that they’re more intuitive to understand. One result is that they’re now called “Validators” in an effort to keep naming conventions reasonable across the industry.\nMuch attention was spent on a discovered issue with vote propagation within this construction. This issue is around the implications of vote withholding and how they change as you move up the overlay. The solution being to propagate a map of seen votes upstream alongside the vote, thus increasing transparency of participation.\nThe concept of “Hastiness” has been introduced to describe the leader’s ability to decide whether or not to include votes from the root committee if the threshold is reached before they’ve had the opportunity to conclude. More research is underway to detail the implications of this decisions with respect to payout, latency, and security.\nMost notably, an extension (or more constrained parameterization) of Carnot was initiated and is underway (expected by end of Oct) as a consequence of needing to mitigate a signature aggregation issue. This extension requires 2/3 votes to be collected before a decisions is made.\nData Availability §\nResearch continues on the various available Data Availability schemes and their trade-offs which resulted in the ability to make some decisions on the Nomos specification and identified a more specific personnel requirement for specialized cryptographic expertise. This research demand will now be filled by the new addition to the team and progress is expected to accelerate.\nAn analysis of the impact of node decay in Data Availability was performed and presented in a Logos Research Seminar. This research resulted in a draft specification of private DA. This then lead to the first draft of a complete privacy solution for the networking layer for consensus and DA.\nThe architecture of Data Availability services was fleshed out within nomos-node software. Data dissemination implementation was completed and the mempool for certificates is currently in progress.\nPerceived Changes in Project Risk §\nPrivacy remains at the forefront of this project’s desired requirements. As such, it is important to define what types of privacy the project can offer and then detail exactly how various technology provides it. This is a “ground up” process that starts at the lowest layers and propagates up through the stack. Due to the continued exploration and designing of the Base Layer, it remains to be seen how the currently designs will impact upper layers, namely “Execution Zones.” The on-going development of the zkVM incubation project within Vac raises the risk of incompatibility between the two as both projects are optimizing for their respective domains in parallel and without much communication.\nFuture Plans §\nInsight §\nIt is expected that the entire Nomos roadmap will be specified within this site and the weekly reporting process will be in line with the Milestones defined therein.\nA Logos Collaborations section will be included next month to highlight differences in alignment with the Logos Collective as well as cross project collaboration updates.\nDepending on the uptake and viability of the Waku reporting process to other projects, then a myriad of quantitative measures will be included in the next monthly report.\nProject §\nNext month focuses on finalizing and publishing:\n\nthe first version of the Whitepapers\n\nemphasis that specification details will focus on the Base Layer implementation, leaving unknowns and explicit detail of above layers to be explored as open problems.\n\n\na Nomos Testnet Client and Node implementation\na viability analysis of an embedded mixnet\na specification and pseudocode for the extended 2/3-vote aggregation Carnot consensus algorithm (Vac dependency: carnot-2-3rds-vote-aggregation)\n\nSources and Useful Links §\nWeekly updates referenced\n\n2023-09-04\n2023-09-11\n2023-09-19\n2023-09-26\n"},"nomos/monthly-reports/index":{"title":"Nomos Monthly Reports","links":[],"tags":[],"content":"Here are the monthly reports that are generated for Nomos."},"nomos/updates/2023-07-24":{"title":"2023-07-24 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Research\n\nMilestone 1: Understanding Data Availability (DA) Problem\nHigh-level exploration and discussion on data availability problems in a collaborative offsite meeting in Paris.\nExplored the necessity and key challenges associated with DA.\nIn-depth study of Verifiable Information Dispersal (VID) as it relates to data availability.\nBlocker: The experimental tests for our specific EC scheme are pending, which is blocking progress to make final decision on KZG + commitments for our architecture.\nMilestone 2: Privacy for Proof of Stake (PoS)\nAnalyzed the capabilities and limitations of mixnets, specifically within the context of timing attacks in private PoS.\nInvested time in understanding timing attacks and how Nym mixnet caters to these challenges.\nReviewed the Crypsinous paper to understand its privacy vulnerabilities, notably the issue with probabilistic leader election and the vulnerability of anonymous broadcast channels to timing attacks.\n\nDevelopment\n\nMilestone 1: Mixnet and Networking\nInitiated integration of libp2p to be used as the full node’s backend, planning to complete in the next phase.\nBegun planning for the next steps for mixnet integration, with a focus on understanding the components of the Nym mixnet, its problem-solving mechanisms, and the potential for integrating some of its components into our codebase.\nMilestone 2: Simulation Application\nCompleted pseudocode for Carnot Simulator, created a test pseudocode, and provided a detailed description of the simulation. The relevant resources can be found at the following links:\n\nCarnot Simulator pseudocode (https://github.com/logos-co/nomos-specs/blob/Carnot-Simulation/carnot/carnot_simulation_psuedocode.py)\nTest pseudocode (https://github.com/logos-co/nomos-specs/blob/Carnot-Simulation/carnot/test_carnot_simulation.py)\nDescription of the simulation (https://www.notion.so/Carnot-Simulation-c025dbab6b374c139004aae45831cf78)\n\n\nImplemented simulation network fixes and warding improvements, and increased the run duration of integration tests. The corresponding pull requests can be accessed here:\n\nSimulation network fix (https://github.com/logos-co/nomos-node/pull/262)\nVote tally fix (https://github.com/logos-co/nomos-node/pull/268)\nIncreased run duration of integration tests (https://github.com/logos-co/nomos-node/pull/263)\nWarding improvements (https://github.com/logos-co/nomos-node/pull/269)\n\n\n"},"nomos/updates/2023-07-31":{"title":"2023-07-31 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos 31st July\n[Network implementation and Mixnet]:\nResearch\n\nInitial analysis on the mixnet Proof of Concept (PoC) was performed, assessing components like Sphinx for packets and delay-forwarder.\nConsidered the use of a new NetworkInterface in the simulation to mimic the mixnet, but currently, no significant benefits from doing so have been identified.\nDevelopment\nFixes were made on the Overlay interface.\nNear completion of the libp2p integration with all tests passing so far, a PR is expected to be opened soon.\nLink to libp2p PRs: https://github.com/logos-co/nomos-node/pull/278, https://github.com/logos-co/nomos-node/pull/279, https://github.com/logos-co/nomos-node/pull/280, https://github.com/logos-co/nomos-node/pull/281\nStarted working on the foundation of the libp2p-mixnet transport.\n\n[Private PoS]:\nResearch\n\nDiscussions were held on the Privacy PoS (PPoS) proposal, aligning a general direction of team members.\nReviews on the PPoS proposal were done.\nA proposal to merge the PPoS proposal with the efficient one was made, in order to have both privacy and efficiency.\nDiscussions on merging Efficient PoS (EPoS) with PPoS are in progress.\n\n[Carnot]:\nResearch\n\nAnalyzing Bribery attack scenarios, which seem to make Carnot more vulnerable than expected.\n\nDevelopment\n\nImproved simulation application to meet test scale requirements (https://github.com/logos-co/nomos-node/pull/274).\nCreated a strategy to solve the large message sending issue in the simulation application.\n\n[Data Availability Sampling (or VID)]:\nResearch\n\nConducted an analysis of stored data “degradation” problem for data availability, modeling fractions of nodes which leave the system at regular time intervals\nContinued literature reading on Verifiable Information Dispersal (VID) for DA problem, as well as encoding/commitment schemes.\n"},"nomos/updates/2023-08-07":{"title":"2023-08-07 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos weekly report §\nNetwork implementation and Mixnet: §\nResearch §\n\nResearched the Nym mixnet architecture in depth in order to design our prototype architecture.\n(Link: https://github.com/logos-co/nomos-node/issues/273#issuecomment-1661386628)\nDiscussions about how to manage the mixnet topology.\n(Link: https://github.com/logos-co/nomos-node/issues/273#issuecomment-1665101243)\n\nDevelopment §\n\nImplemented a prototype for building a Sphinx packet, mixing packets at the first hop of gossipsub with 3 mixnodes (+ encryption + delay), raw TCP connections between mixnodes, and the static entire mixnode topology.\n(Link: https://github.com/logos-co/nomos-node/pull/288)\nAdded support for libp2p in tests.\n(Link: https://github.com/logos-co/nomos-node/pull/287)\nAdded support for libp2p in nomos node.\n(Link: https://github.com/logos-co/nomos-node/pull/285)\n\nPrivate PoS: §\nResearch §\n\nWorked on PPoS design and addressed potential metadata leakage due to staking and rewarding.\nFocus on potential bribery attacks and privacy reasoning, but not much progress yet.\nStopped work on Accountability mechanism and PPoS efficiency due to prioritizing bribery attacks.\n\nCarnot: §\nResearch §\n\nAddressed two solutions for the bribery attack. Proposals pending.\nWork on accountability against attacks in Carnot including Slashing mechanism for attackers is paused at the moment.\nModeled data decimation using a specific set of parameters and derived equations related to it.\nProposed solutions to address bribery attacks without compromising the protocol’s scalability.\n\nData Availability Sampling (VID): §\nResearch §\n\nAnalyzed data decimation in data availability problem.\n(Link: https://www.overleaf.com/read/gzqvbbmfnxyp)\nDA benchmarks and analysis for data commitments and encoding. This confirms that (for now), we are on the right path.\nExplored the idea of node sharding: https://arxiv.org/abs/1907.03331 (taken from Celestia), but discarded it because it doesn’t fit our architecture.\n\nTesting and Node development: §\n\nFixes and enhancements made to nomos-node.\n(Link: https://github.com/logos-co/nomos-node/pull/282)\n(Link: https://github.com/logos-co/nomos-node/pull/289)\n(Link: https://github.com/logos-co/nomos-node/pull/293)\n(Link: https://github.com/logos-co/nomos-node/pull/295)\nRan simulations with 10K nodes.\nUpdated integration tests in CI to use waku or libp2p network.\n(Link: https://github.com/logos-co/nomos-node/pull/290)\nFix for the node throughput during simulations.\n(Link: https://github.com/logos-co/nomos-node/pull/295)\n"},"nomos/updates/2023-08-14":{"title":"2023-08-17 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos weekly report 14th August §\n\nNetwork Privacy and Mixnet §\nResearch §\n\nMixnet architecture discussions. Potential agreement on architecture not very different from PoC\nMixnet preliminary design [https://www.notion.so/Mixnet-Architecture-613f53cf11a245098c50af6b191d31d2]\n\nDevelopment §\n\nMixnet PoC implementation starting [https://github.com/logos-co/nomos-node/pull/302]\nImplementation of mixnode: a core module for implementing a mixnode binary\nImplementation of mixnet-client: a client library for mixnet users, such as nomos-node\n\nPrivate PoS §\n\nNo progress this week.\n\n\nData Availability §\nResearch §\n\nContinued analysis of node decay in data availability problem\nImproved upper bound on the probability of the event that data is no longer available given by the (K,N) erasure ECC scheme [https://www.overleaf.com/read/gzqvbbmfnxyp]\n\nDevelopment §\n\nLibrary survey: Library used for the benchmarks is not yet ready for requirements, looking for alternatives\nRS & KZG benchmarking for our use case https://www.notion.so/2D-Reed-Solomon-Encoding-KZG-Commitments-benchmarking-b8340382ecc741c4a16b8a0c4a114450\nStudy documentation on Danksharding and set of questions for Leonardo [https://www.notion.so/2D-Reed-Solomon-Encoding-KZG-Commitments-benchmarking-b8340382ecc741c4a16b8a0c4a114450]\n\n\nTesting, CI and Simulation App §\nDevelopment §\n\nSim fixes/improvements [https://github.com/logos-co/nomos-node/pull/299], [https://github.com/logos-co/nomos-node/pull/298], [https://github.com/logos-co/nomos-node/pull/295]\nSimulation app and instructions shared [https://github.com/logos-co/nomos-node/pull/300], [https://github.com/logos-co/nomos-node/pull/291], [https://github.com/logos-co/nomos-node/pull/294]\nCI: Updated and merged [https://github.com/logos-co/nomos-node/pull/290]\nParallel node init for improved simulation run times [https://github.com/logos-co/nomos-node/pull/300]\nImplemented branch overlay for simulating 100K+ nodes [https://github.com/logos-co/nomos-node/pull/291]\nSequential builds for nomos node features updated in CI [https://github.com/logos-co/nomos-node/pull/290]\n"},"nomos/updates/2023-08-21":{"title":"2023-08-21 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos weekly report 21st Oct §\n(delayed as I was on holidays and then took me some time to clarify some things with the team)\nNetwork Privacy and Mixnet §\n\nImproved the mixnet implementation based on latest discussion. https://github.com/logos-co/nomos-node/pull/307\nBase implementation of Mixnet PoC: https://github.com/logos-co/nomos-node/pull/302\nRefactor to encapsulate message body creation&write&read: https://github.com/logos-co/nomos-node/pull/308\nNew issues related to mixnet: https://github.com/logos-co/nomos-node/issues?q=is%3Aopen+is%3Aissue+label%3Amixnet\n\nPrivate PoS §\n\nUpdated draft addressing comments related to shielded and transparent transaction types.\nDefined an opportunistic voting problem.\nContinuing analysis on zCash transaction’s construction.\nThis is currently the project that is going slowest and needs more attention going forward. It’s also the most complex and with the most unknowns.\n\nSimulations app §\n\nGraceful shutdown of simulations.\nCreated a new repository for simulations configurations and test results: https://github.com/logos-co/nomos-simulations\nUpdates and discussed test runs: https://github.com/logos-co/nomos-simulations/pull/3\nChanges to support CSV format output of simulation data: https://github.com/logos-co/nomos-node/pull/304 and https://github.com/logos-co/nomos-node/pull/306\nMinor issue on integration tests fixed: https://github.com/logos-co/nomos-node/pull/315\n\nData Availability Sampling §\n\nStudied RS+KZG in context of our DA architecture.\nRS: basic encoding/decoding lib. Created a basic wrapper around reed-solomon-encoding library to work with arbitrary bytearrays with the simples API possible. Created basic tests and docs as well.\nKZG: basic commitment + proof creation, also proof verification lib. Same here, created a simplistic API that abstract from the confusing types in the underlaying used library.\nCreated a simplistic API for RS: https://github.com/logos-co/nomos-node/pull/303\nCreated a simplistic API for KZG: https://github.com/logos-co/nomos-node/pull/309\n"},"nomos/updates/2023-08-29":{"title":"2023-08-29 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos weekly report §\nMilestone 1: Network Privacy and Mixnet §\nResearch §\n\nA Mixnet PoC was conducted to gauge end-to-end latency, revealing a slight latency increase when utilizing mixnet. Several potential optimization areas have been identified.\n\nDevelopment §\n\nVarious enhancements for the Mixnet have been developed, including the addition of delays for Sphinx packets, auto port for integration tests, and introducing a graceful shutdown for mixnode elements.\nThere’s an ongoing shift from channels to streams in mixnet message handling.\nRefactoring of Mixnet Node & Client: https://github.com/logos-co/nomos-node/pull/320\nMixnet PoC Architecture Documents: https://www.notion.so/Mixnet-and-Network-Privacy-Architecture-613f53cf11a245098c50af6b191d31d2\nMixnet Measurements Documentation: https://www.notion.so/Mixnet-Measurements-551ade11ae4d44ca9f3d947ea6950c67\nSphinx Packet Delay Support: https://github.com/logos-co/nomos-node/pull/321\nAuto Port for Tests: https://github.com/logos-co/nomos-node/pull/327\nMixnet Criterion Measurement: https://github.com/logos-co/nomos-node/pull/328\nGraceful Shutdown for Mixnet: https://github.com/logos-co/nomos-node/pull/330\n\n\nMilestone 2: Private PoS §\nResearch §\n\nDiscussions were held about token-engineering and staking in private settings, resulting in documentation that delves into the validation and delegation aspects of PPoS. Current considerations involve the integration of the ZeroCash/zCash construction into the staking model.\n\n\nMilestone 3: Data Availability Sampling (RS, KZG) §\nResearch §\n\nLimitations discovered during RS and KZG implementation, notably with RS library scalability issues and bls12_381 curve finite field challenges. Found KZG libraries are primarily designed for Ethereum, which constrains the blob size.\nBenchmarks for KZG implementation were carried out, and simulation runs were conducted for different configurations.\nNode decay in relation to data availability was analyzed, leading to the derivation of an equation for understanding node averages in the network.\n\nDevelopment §\n\nKZG Library: https://github.com/logos-co/nomos-node/pull/325\nKZG Base Layer initial approach: https://github.com/logos-co/nomos-node/pull/309\nDetailed KZG Operation Benchmarks: https://github.com/logos-co/nomos-node/tree/da-kzg-benches\nNode Decay Analysis & Results: https://www.overleaf.com/read/gzqvbbmfnxyp\n"},"nomos/updates/2023-09-04":{"title":"2023-09-04 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"nomos: §\n\nnetwork privacy and mixnet: §\nresearch §\n\nNo specific research tasks reported this week related to this milestone.\n\ndevelopment §\n\nMade mixnet tests stable: https://github.com/logos-co/nomos-node/pull/334\nFinished the delay implementation: https://github.com/logos-co/nomos-node/pull/362\nMigrated the mixnode binary to Overwatch for better integration: https://github.com/logos-co/nomos-node/pull/339\nAdded a retry mechanism to the libp2p backend for transient errors: https://github.com/logos-co/nomos-node/pull/332\nFixed network tests failing with mixnet: https://github.com/logos-co/nomos-node/pull/338\nFix panic for RandomDelayIter: https://github.com/logos-co/nomos-node/pull/335\nConnection cache for mixnet: https://github.com/logos-co/nomos-node/pull/343\nImplemented mempool network adapters for libp2p: https://github.com/logos-co/nomos-node/pull/344\nImplemented the libp2p version of the addtx endpoint: https://github.com/logos-co/nomos-node/pull/345\n\n\ntestnet: §\ndevelopment: §\n\nPOC/Draft for testnet using Docker Compose: https://github.com/logos-co/nomos-node/pull/364\nDNS Multiaddr parsing and peer id configuration: https://github.com/logos-co/nomos-node/pull/346, https://github.com/logos-co/nomos-node/pull/361\n\n\nprivate PoS: §\nresearch: §\n\nIntroduced the Base Design section, focusing on the ZCash design’s constructions, building an understanding of the data structures and algorithms, and presenting relevant algorithms with comprehensive descriptions.\nDeveloped the Staking Extension section, leveraging Base Design constructions to introduce staking mechanics, defining the “Stake” algorithm that transforms shielded coins into voting “staking coins”, and the “Reward” algorithm that distributes rewards and restakes coins back into the pool.\nCreated the Consensus Modifications section, detailing modifications to the Carnot Consensus algorithm based on the Staking Extension, introducing mapping of staking coins to validator “shadows”, presenting the initial voting construction, introducing a vote aggregation mechanism, and elaborating on vote dissemination and aggregation through a tree overlay.\n\n\ndata availability: §\nresearch: §\n\nStudied more options for DA verification schemes: https://www.notion.so/Data-Availability-Specification-WIP-c3961b681eba4ccdab2be9181e4207b4\nReached some conclusions that allow us to make progress in implementing the architecture. Blocker: we need specialized cryptographic expertise to make further progress on this. I will personally keep working on it later on, but privacy matters are more important now as they have a higher impact on the architecture.\nAnalysis of node decay in the data availability problem is complete: https://www.overleaf.com/read/gzqvbbmfnxyp\n\ndevelopment: §\n\nIncluded BL blobs in the block: https://github.com/logos-co/nomos-node/pull/368\n"},"nomos/updates/2023-09-11":{"title":"2023-09-11 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"nomos: §\n\nnetwork privacy and mixnet: §\nresearch: §\n\nRevised mathematical methods, such as the Poisson point process, etc., used in analysis of mixnets.\nExplored literature related to mixnets where approaches from differential privacy are used. The latter could lead to a more general privacy guarantee which is relevant to not only current but also future attacks on privacy.\n\ndevelopment: §\n\nFixed a bug in the connection pool implementation https://github.com/logos-co/nomos-node/pull/373\nFixed Cargo.toml for nomos-network https://github.com/logos-co/nomos-node/pull/380\nAdded defaults to libp2p settings https://github.com/logos-co/nomos-node/pull/388\nFixed request handling in mixnode: https://github.com/logos-co/nomos-node/pull/372\nAdded benchmark code (in localhost): https://github.com/logos-co/nomos-node/pull/375\nAfter trying to find existing solutions to routing strategies (routing first, privacy later), and not finding a proper solution, moved to thinking about a naive approach: https://www.notion.so/WIP-Proposal-Routing-7b034dcac64940eda25ee415806d0ec8\nFound using sync Mutex will lead to a block. https://github.com/logos-co/nomos-node/pull/370\nFinish implementing the first version of retry for mixnode and mixclient https://github.com/logos-co/nomos-node/pull/386\n\n\ntestnet: §\ndevelopment: §\n\nNode config via environment variables: https://github.com/logos-co/nomos-node/pull/382\nObservability and node configuration in testnet work in progress: https://github.com/logos-co/nomos-node/pull/364 (Same draft PR as last week WIP).\nResolving more GH Actions related issues:\n\nhttps://github.com/logos-co/nomos-node/pull/385\nhttps://github.com/logos-co/nomos-node/pull/389\n\n\n\n\nprivate PoS: §\nresearch: §\n\nFound an issue in vote propagation of the PPoS construction: When a vote is propagated upstream to the higher committee there is a chance that a malicious shadow in committee decides not to broadcast their vote to the committee members and send it only upstream. Then this “unseen” vote will block the possibility of reconstructing the most common committee_vote, and at the same time prove that other shadows have voted. The solution for that is to propagate a map of seen votes upstream alongside the vote, this enables the higher committee to select only the votes that are most commonly seen for building the committee_vote thus making that kind of malicious behavior detectable.\nImproving the PPoS description: working on selecting proper naming conventions, as currently there are voters, shadows, coins which are confusing. That is done in pair with revising the logic.\n\n\ndata availability: §\nresearch: §\n\nA draft for private DA can be found here: https://www.notion.so/Data-Availability-Specification-c3961b681eba4ccdab2be9181e4207b4?d=d4e8d1bcd6224682ba74737100106e48#0c70202794214cbab626e51f7f1f7c24\n\ndevelopment: §\n\nBlobs in block: https://github.com/logos-co/nomos-node/pull/368\nDA service architecture: https://github.com/logos-co/nomos-node/pull/376\nDa service backend implementation: https://github.com/logos-co/nomos-node/pull/381\n"},"nomos/updates/2023-09-19":{"title":"2023-09-19 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"nomos: §\n\nnetwork privacy and mixnet: §\nresearch: §\n\nReview of the “Untraceable electronic mail, return addresses, and digital pseudonyms” paper. Review of the “The Loopix anonymity system” paper.\nNotes provided in the overleaf document https://www.overleaf.com/read/rybwvjftfrrg\n\ndevelopment: §\n\nPolishing mixnet to make it ready for the testnet:\nHelping preparing mixnet deployments: https://github.com/logos-co/nomos-node/pull/408\nReviewed mixnet connection management\nRefactor the libp2p network backend: https://github.com/logos-co/nomos-node/tree/libp2p-refactor-yjlee and based on that prepare to measure the quality of unobservability - https://github.com/logos-co/nomos-node/issues/391\nBlock building: https://github.com/logos-co/nomos-node/pull/401\nFountain codes: https://github.com/logos-co/nomos-node/pull/407\nGot the mixnet retry PR merged: https://github.com/logos-co/nomos-node/pull/386\nFinish the concrete error implementation for mixnet and ready for merge: https://github.com/logos-co/nomos-node/pull/405\nWIP: fan-in message passing model for mixnode: https://github.com/logos-co/nomos-node/tree/mixnet-fan-in\n\n\ntestnet: §\ndevelopment: §\n\nTestnet preparation: https://github.com/logos-co/nomos-node/pull/410\nTestnet POC with libp2p merged: https://github.com/logos-co/nomos-node/pull/364\nThe POC for testnet using etcd and docker compose was reviewed and merged. The mixnet functionality will be added on top of this.\nSimulation branch overlay with 1 committee fix: https://github.com/logos-co/nomos-node/pull/402\nA bug where branch overlay results different from tree overlay with one committee blocked research team to use simulations results. Fixed it.\nImprovements in CI:\n\nhttps://github.com/logos-co/nomos-node/pull/409\nhttps://github.com/logos-co/nomos-node/pull/411\nhttps://github.com/logos-co/nomos-node/pull/412\n\n\nMinor improvements to remove annoying red x’s from our CI\n\n\nprivate PoS: §\nresearch: §\n\nShadows logic: Looking at how to describe the logic of the shadow in the most clear way: It will be divided into a set of modules, each module taking care of processing a separate communication channel.\nAll channels have their logic described in adequate modules and with references to self-descripting functions. However, some of them (like how exactly to aggregate votes) must yet to be defined.\nHastiness issues: In short, the leader, in order to limit the cost of vote aggregation can decide to not to include votes from top committees (and root in particular). This is an acceptable strategy and will lead to a correctly formed aggregation proof. The proof will include a global threshold of votes from lower committees but not from the top committees (and root committee in particular). The impact of this leader’s hastiness does not break the security of the protocol as a threshold of votes is correctly gathered. However, it may limit rewards from the top committees (and root in particular), as the votes from those committees may not be needed to reach the threshold. More on that under the issues section of the PPoS doc.\n\n\ndata availability: §\nresearch: §\n\nFirst stab at privacy solution for the network layer for consensus and DA: https://www.notion.so/Practical-Private-Addressing-Network-Privacy-Component-2-2b9b4923124a4fdb81dba5d2bba1d289?d=99166164267a46589c5715175e1b3657#5e27d2010d30468f9d8f0d0928b9c639\nInit survey of SoA in network privacy alternative solutions\n\ndevelopment: §\n\nDA nomos core kickstart, added different pieces that were missing for abstractions: https://github.com/logos-co/nomos-node/pull/390\nAdded attestation trait\nAdded certificate trait\nAdded DaProtocol trait that abstracts encoding/decoding, and put the pieces together for blob+attestation+certificate handling.\nRefactored (moved and restructured) da modules\nRefactor and improve common traits - https://github.com/logos-co/nomos-node/pull/395\nImplement a simple da protocol with full replication - https://github.com/logos-co/nomos-node/pull/400\nImplement a command to disseminate blobs through the network - https://github.com/logos-co/nomos-node/pull/396\nAdded da-service to nomos node - https://github.com/logos-co/nomos-node/pull/404\nHousekeeping:\n\nhttps://github.com/logos-co/nomos-node/pull/403\nhttps://github.com/logos-co/nomos-node/pull/388\nhttps://github.com/logos-co/nomos-node/pull/399\n\n\n"},"nomos/updates/2023-09-26":{"title":"2023-09-26 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"nomos: §\n\nnetwork privacy and mixnet: §\nresearch: §\n\nWith the assumption that nodes of a mixnet are selected without replacement, we performed analysis with Byzantine node presence (for specific widths and lengths). This gives the probability that there is at least one path where all nodes are Byzantine (“anonymity” failure)\nEvaluation in the “Loopix” paper used the mixnet with n1=2 and L=5\nConclusion: probability of anonymity failure decreases when increasing length and increases with increasing width\nNotes provided in the overleaf document https://www.overleaf.com/read/rybwvjftfrrg\nDiscussions on how to model the network privacy for analysis; viability of the embedded mixnet design\nNotes (WIP): https://www.notion.so/Network-Privacy-2dabf0aa878744e299b2ebb97120876f\n\ndevelopment: §\n\nMaking integration tests work with FlatOverlay and RandomBeacon:\n\nhttps://github.com/logos-co/nomos-node/pull/425\nhttps://github.com/logos-co/nomos-node/pull/426\n\n\nSome integration tests are randomly failed. Debugging them: https://github.com/logos-co/nomos-node/pull/437\nRefactoring libp2p network layer: https://github.com/logos-co/nomos-node/pull/417\nAdd missing error handlings in mixnet: https://github.com/logos-co/nomos-node/pull/436 (+ more coming soon)\nTrying to enable gathering metrics for libp2p (but needs to be discussed about how this can be used with our existing metrics service): https://github.com/logos-co/nomos-node/pull/431\nNew mixnet message handle PR: https://github.com/logos-co/nomos-node/pull/435\nQC checks: https://github.com/logos-co/nomos-node/pull/430\n\n\ntestnet: §\ndevelopment: §\n\nTreeOverlay in Nomos node:\n\nhttps://github.com/logos-co/nomos-node/pull/415\nhttps://github.com/logos-co/nomos-node/pull/423\n\n\nAfter adding tree overlay to Nomos node, integration tests started failing. Main reason was that the leader didn’t spawn in time and nodes failed to send their votes. This mainly affected the happy path test. Work will be merged once the issues are fixed.\nTestnet with mixnode: WIP\nWork on the mixnet node in testnet continues. Ongoing inter-team discussions in regards to how we should monitor and extract info from the network. The PR for libp2p metrics might be the way to go.\nCI chores: https://github.com/logos-co/nomos-node/pull/432\n\n\nprivate PoS: §\nresearch: §\n\nAdd missing function descriptions and finalize structure definitions.\nDefined/redefined structures used in all algorithms that required a rewrite.\nUpdated the terminology and made the Shadows name obsolete, and now they are called Validators (for synchronization with other PoS designs).\nThe validators logic was redesigned, improved and updated accordingly.\nThe same was with the ledger/transactions part, and now they form a complete logic.\nReadability: the specification part was updated. The rest of the document is out of sync and needs to be revised as the focus was put on the specification.\nCritical analysis: an issue was identified and described (under the issues section) that touches on a problem where insufficient number of votes are aggregated and the need for an additional voting round before commencing an overlay tree reconstruction. This can be mitigated with an additional votes collection from late voters (before the tree timeout) or increased level of votes that are collected during initial voting collection.\nReview of the Delegation and Validation rewards document by Frederico.\n\n\ndata availability: §\ndevelopment: §\n\nDissemination ready\n\nhttps://github.com/logos-co/nomos-node/pull/416\nhttps://github.com/logos-co/nomos-node/pull/400\nhttps://github.com/logos-co/nomos-node/pull/404\n\n\nMempool for certificates in progress\n"},"nomos/updates/2023-10-09":{"title":"2023-10-09 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet: §\nresearch: §\n\nDerived asymptotic expressions for anonymity and communication failure probabilities, when taking into account certain values for population size and network size. Used simulations and analytic framework to study failure probabilities in mixnets of different sizes. Assuming delays between sending and receiving messages are independent random variables from the exponential distribution, derived probability distribution of latency. Main result: one cannot have both low probability of communication and low probability of anonymity failures. The probability of anonymity failure is decreasing with the number of layers but at the expense of increasing the latency.\nFinalize research of network-level privacy solutions. Learned important information on: Framework for formalizing privacy, Nym and tokenomics of a Mixnet, Sphinx, and Loopix. Notes found at: https://www.notion.so/Network-Privacy-2dabf0aa878744e299b2ebb97120876f (summaries still WIP).\n\ndevelopment: §\n\nLock Overwatch to a specific revision in nomos: https://github.com/logos-co/nomos-node/pull/455.\nImplement and pipe services lifecycle handling in Overwatch: https://github.com/logos-co/Overwatch/pull/27.\nBash is being replaced with python due to adding mixnet to docker. At the moment, small issues with node spawning order are being resolved (for tree overlay). ETA on finishing: beginning of this week.\nAdd API to return mempool item status: https://github.com/logos-co/nomos-node/pull/449.\nMake libp2p gossipsub settings configurable: https://github.com/logos-co/nomos-node/pull/454.\nAvoid temporary gossipsub errors when bootstrapping tests: https://github.com/logos-co/nomos-node/pull/442.\n\ntestnet: §\ndevelopment: §\n\nSkeleton for nomos API service - https://github.com/logos-co/nomos-node/pull/451.\nSupport generics for overwatch derive - https://github.com/logos-co/Overwatch/pull/26.\nFix clippy warnings for rust 1.73 - https://github.com/logos-co/nomos-node/pull/452.\nRemove waku mentions from codebase - https://github.com/logos-co/nomos-node/pull/446.\nImproved integration tests.\nHandle corner cases in the unhappy path: https://github.com/logos-co/nomos-node/pull/438.\nAdd canonical ID to attestations and certificates: https://github.com/logos-co/nomos-node/pull/448.\nAdd functionalities to nomos-cli: https://github.com/logos-co/nomos-node/pull/450.\n\nprivate PoS: §\nresearch: §\n\nExploring multi-staking PPoS design for Carnot.\nIdea: a slightly modified version of PoS, unknown how much funds a single validator has and validators are grouped by the amount of stake they have. This property gives validators group-based k-anonymity, where they are indistinguishable (on the stake level). This also enables us to assign the same voting power per each group of validators, which then can be reflected on the overlay structure.\nConsidering a couple of additional stake hiding/obfuscating techniques without making the initial design too complex. We incentivize/penalize validators based not on the voting power they represent but on the stake. We can have a system that diverges from an equality between voting power and stake, to a system that approximates the voting power based on the stake but the rewarding/penalization directly follows the stake.\n\ndata availability: §\ndevelopment: §\n\nDA nomos API based on the new skeleton: https://github.com/logos-co/nomos-node/pull/456.\nAdd API to return DA blobs: https://github.com/logos-co/nomos-node/pull/453.\n"},"nomos/updates/2023-10-17":{"title":"2023-10-17 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet: §\nresearch: §\n\nFinalized the write up and summaries of the privacy network research - https://www.notion.so/Network-Privacy-2dabf0aa878744e299b2ebb97120876f (Pinned those notes that are the most important, to serve as a guidance for anyone who wants to have a quicker overview of the topic)\n\n\ntestnet: §\ndevelopment: §\n\nImproved integration tests: https://github.com/logos-co/nomos-node/pull/458\nPreparing for demo\nLifecycle handling: https://github.com/logos-co/nomos-node/pull/457\nA note on current testnet implementation. Realized that even with python code the configuration of mixnet and libp2p nodes are getting too complicated, nodes are still missing features and the glue code is not a solution in the long run. Will have more discussions.\n\n\nprivate PoS: §\nresearch: §\n\nInitial proposal for multi-staking PPoS design for Carnot: https://www.notion.so/Sketch-Approximated-PoS-with-k-anonymity-towards-multi-staking-for-Carnot-BFT-e066eb4f80114ddc862a8665aea952b6?pvs=4\n\n\ndata availability: §\nresearch: §\n\nSona polynomial commitment scheme was examined and found to be applicable to data availability. Comparisons and notes can be viewed here:https://www.notion.so/Polynomial-Commitment-Schemes-59bf8f6fe39840babe819c5c0a9628fc\nIf we continue with KZG, the method to be followed for “trusted setup” was investigated. Some methods can be found here: https://www.notion.so/Trusted-Setup-19a29ee752f14e96895328a0bd7a9634\nAdded notes on using prime field: https://www.notion.so/Notes-c4a680142a954953a2c0ea0e4b6fdcf1\n\n\nEurorust Event: §\nHere are some notes by Daniel about the event the Engineering Team attended to last weekend:\n\nFrom the ecosystem speeches we can say they are constantly making efforts on making the language mature. impl Trait in traits are coming later this year, will impact our codebase (will need some refactors). It doesn’t look like a big change but it kind of is. We use a lot of abstractions (futures + streams mostly) that force use to box everything (dynamic dispatch), that now will be statically dispatched.\nOverall keynotes and speeches were not really good. More exploratory than anything. Some of them showed tech that was mostly not relevant to us.\nGathering the team had some impact. We had some bonding on related topics that all of us enjoy. And we had some conversations that otherwise would not probably took place.\nIMO probably not worth to repeat this kind of events unless we participate in a more active way (preparing a speech ourselves and apply which I think we are totally capable of. We have a few things we could show up - Simulation app or Overwatch for example).\n"},"nomos/updates/2023-10-23":{"title":"2023-10-25 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet: §\nresearch: §\n\nSet up a calculation for the probability of anonymity (communication) failure in the mix network of a large size, sampled from a large population of nodes, such that mix network size is comparable with the node population size. The latter is the most challenging regime to analyse but potentially can give us much more accurate estimates of probabilities. Previously we have analysed regimes when mix network size is much smaller than network size and when all nodes in the network are also used in the mix network.\nNotes on “Anonymity Trilemma: Strong Anonymity, Low Bandwidth Overhead, Low Latency - Choose Two” paper provided in the overleaf document. https://www.overleaf.com/read/rybwvjftfrrg ; The latter derives necessary conditions for anonymous communication in terms of latency, amount of noise messages and some measure of anonymity.\n\ndevelopment: §\n\nMixnet development specifications: went through the Loopix paper again - writing the draft specs: https://www.notion.so/WIP-Mixnet-Development-Specifications-807b624444a54a4b88afa1cc80e100c2 (covering the current Loopix-based implementation + Future work: cover traffic, multicasting (TBD), incentivization (TBD))\n\ntestnet: §\ndevelopment: §\n\nSave block contents to storage - https://github.com/logos-co/nomos-node/pull/464\nRefactoring for future content - https://github.com/logos-co/nomos-node/pull/461\nServices state watchers - added a first version so overwatch can await for other services signal that they are ready to work. First version using relay did not work (among other things, too complicated). Second version uses an aditional handle per service, it is morestraight forward. It may add more intricated relationship among services, and they cannot be handled/caught on runtime. Testing only for now.\nFailing services status PR: https://github.com/logos-co/Overwatch/pull/29\nWorking services status PR: https://github.com/logos-co/Overwatch/pull/30\nUpdate lifecycle handling: https://github.com/logos-co/nomos-node/pull/457\nGenerics metrics API: https://github.com/logos-co/nomos-node/pull/466\nHuman readable ser/deser for array based types: https://github.com/logos-co/nomos-node/pull/468\nUpdate libp2p breaking changes: https://github.com/logos-co/nomos-node/pull/470\nFinished mixnodes in docker testnet: https://github.com/logos-co/nomos-node/pull/467 - The testnet in docker compose is now merged and has a README. There are still room for improvement, like spawning some nodes sequentially (like in https://github.com/logos-co/nomos-node/pull/425), but this will be solved in added in a new PRs or solved by other node improvements.\nImprovements for node config: https://github.com/logos-co/nomos-node/pull/460, https://github.com/logos-co/nomos-node/pull/471 - These changes were required for spawning nodes in testnet, will be useful for our endusers too\n\nprivate PoS: §\n::research §\n\nSingle-staking - reviewed and updated the design up to the construction section.\nMulti-staking - all comments have been addressed, but new are coming.\nRight now we are investigating a scenario where we are limiting the amount of validators in the Single-Staking case by diverging from the requirement of having multiples of validators by removing the economical incentives. In other words, we are considering to allow registering validators that have at least a threshold of stake (that is or is not capped) and a single (unitary) voting power. This way we are limiting the economical need for having multiple validators hosted by a single node, and at the same time limiting the network overhead of the single-staking design.\nThe “Delegation and Validation Rewards” document (WIP): https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4\nIncorporating notes in the architecture whitepapers. These readings are not as deeply technical as papers, but more about understanding the directions currently explored at the edge of blockchain architectures (namely rollups, modular architectures and intent-centric architectures).\nWorking on the problem of PPoS, one of the most critical points of focus right now, to have at least an understanding of the available options\n\nnomos::data availability §\n::research §\n\nHyrax, Dory and Dark schemes were studied, comparisons here: https://www.notion.so/Polynomial-Commitment-Schemes-59bf8f6fe39840babe819c5c0a9628fc ; It was concluded that schemes with verifier time above logarithmic are not a good option for data availability.\nFRI is a structure that should be used not for now, (at this stage especially, due to large proof size - higher than KZG), but can be used for quantum resistance in the future. Here are some sources that say this can be used in later stages (the reasons are the same as ours). - https://scroll.io/blog/kzg#user-content-fn-6 and https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Why-use-the-hash-of-the-KZG-instead-of-the-KZG-directly\n\n::development §\nnomos::miscellaneous §\n\nDavid Rusu has joined - warm welcome to him!\n"},"nomos/updates/2023-10-30":{"title":"2023-10-30 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet: §\nresearch: §\n\nAnalysis of failure probability in random partitions of networks constructed from nodes with prescribed voting “weights” - derived equations for the probability of anonymity (communication) failure in the mix network of a large size, n, sampled from a large population of nodes of the size, N, such that n is comparable with N (https://www.overleaf.com/read/rybwvjftfrrg). Analysis of these equations is currently in progress.\nSet up a model of random partitions of networks where each node has a weight (https://www.overleaf.com/read/kkmsngmcgbkj#c4de95). Derivation of probability distributions for this model is currently in progress.\nWe have agreed to put more effort into designing a fully weighted multi-staking privacy PoS design. The goal is to map the space of possible solutions (at least the subset of solutions that have been worked on and thought about lately) and their impact on the privacy, security and efficiency of the network.\n\ndevelopment: §\n\nMixnet specifications: Goals + Basic specs (implemented already) + Cover traffic - https://www.notion.so/WIP-Mixnet-Development-Specifications-807b624444a54a4b88afa1cc80e100c2\nMaking Nomos & Mixnode stable for Testnet - Investigated/resolved CI failures: https://github.com/logos-co/nomos-node/pull/49\n\ntestnet: §\ndevelopment: §\n\nTest nomos demo this week!\nSimulation overlay topology info: https://github.com/logos-co/nomos-node/pull/478 and https://github.com/logos-co/nomos-node/pull/479 - to understand better how the network topology looks inside a simulation with a large number of nodes, a way to visualise the network was added\nSimulation optional network capacity: https://github.com/logos-co/nomos-node/pull/483 - after discussing potential issues for getting baseline simulation results for networks with large number of nodes, the option to disable network capacity simulation was added. Advised the DST team to drastically increase the timeout number, so that the baseline will have all the nodes participating (happy path)\nTestnet consensus layer setup: https://github.com/logos-co/nomos-node/pull/482\nCI summary for long running integration tests: https://github.com/logos-co/nomos-node/pull/484\nDiscussion about metrics service and prometheus - current http metrics service is fine, but its design is more fitting for the UIs rather than metrics collectors like prometheus. Explored this idea with libp2p (https://github.com/logos-co/nomos-node/pull/431), it seems like a good idea to have a node-wide service like node-http-api for prometheus metrics.\nFix overwatch lifecycle refactor issue: https://github.com/logos-co/Overwatch/pull/31\nSighandler service: https://github.com/logos-co/nomos-node/pull/480\nImplement da-blob API: https://github.com/logos-co/nomos-node/pull/487\nImplement storage API: https://github.com/logos-co/nomos-node/pull/488\nImplement add cert and add tx APIs: https://github.com/logos-co/nomos-node/pull/489\nIntegrate the new HTTP backend to nomos-node: https://github.com/logos-co/nomos-node/pull/490\nAdd http API to revive block contents from storage: https://github.com/logos-co/nomos-node/pull/473\nAdd API to revive DA blobs: https://github.com/logos-co/nomos-node/pull/477\nAllow deprecated type in Swarm: https://github.com/logos-co/nomos-node/pull/486\n\nprivate PoS: §\nresearch: §\n\nRewards for validators/delegators - the live document “Delegation and Validation Rewards”: https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4\nRead up on Zarcanum (PPoS chain), not much to get inspired from them - https://www.notion.so/Private-Proof-of-Stake-182722d1bdef4894af1d56fece334eae#b8cc6b67f7334b41930bd091458dff2b\nWeighted-BRB - https://www.notion.so/Weighted-Byzantine-Reliable-Broadcast-in-front-of-PoS-consensus-d160a930522942ac98ebf42dc7c515bd\n\ndata availability: §\nresearch: §\n\nSurvey of polynomial commitment schemes - https://www.notion.so/Mehmet-5e698a9bba5d489aa058d3a695cda12f - work in progress, but-RS+KZG seems to be the more reasonable option for data availability at the first stage.\n"},"nomos/updates/2023-11-06":{"title":"2023-11-06 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\ndevelopment §\n\n\nEnriched cover traffic specs: Notion link \n\n\nAdded a fallback for the case where mixnet fails: Notion link \n\n\nNomos integration test stabilization\n\n\nTune timeouts (by heavy debugging):\n\nhttps://github.com/logos-co/nomos-node/pull/492\nhttps://github.com/logos-co/nomos-node/pull/494 \n\n\n\nPrevent Duplicate error from libp2p gossipsub broadcasting: https://github.com/logos-co/nomos-node/pull/498 \n\n\nFix port conflict: https://github.com/logos-co/nomos-node/pull/504 \n\n\nStore CI artifacts:\n\nhttps://github.com/logos-co/nomos-node/pull/508 \nhttps://github.com/logos-co/nomos-node/pull/510 \n\n\n\nMixnet implementation improvement\n\n\nMixclient reconnect: https://github.com/logos-co/nomos-node/pull/501 \n\n\ntestnet §\ndevelopment §\n\nServices APIs:\n\nhttps://github.com/logos-co/nomos-node/pull/476 \nhttps://github.com/logos-co/nomos-node/pull/487 \nhttps://github.com/logos-co/nomos-node/pull/488 \nhttps://github.com/logos-co/nomos-node/pull/489 \n\n\nMempool aware of included blocks: https://github.com/logos-co/nomos-node/pull/485\nVoter attestation: https://github.com/logos-co/nomos-node/pull/498 \nCommunity PRs - typos:\n\nhttps://github.com/logos-co/nomos-node/pull/503 \nhttps://github.com/logos-co/nomos-node/pull/481 \n\n\nHttp API integration (Made the CI all green for the integrating PRs): https://github.com/logos-co/nomos-node/pull/490 \nChat demo: https://github.com/logos-co/nomos-node/pull/495 \nNomos node types (extract common types from nomos-node crate): https://github.com/logos-co/nomos-node/pull/496 \nNomos update for demo call: Notion link \nStatic testnet configuration: https://github.com/logos-co/nomos-node/pull/499 \nIn order to reliably expose all services when deployed, static configuration was added.\nPublic deployment of temporal nomos testnet: ⁠general⁠\nTo work out all missing pieces a temporal VPS was chosen for testnet deployment. The deployment was tested with nomos-cli app\nPreparing for testnet deployment on nomos infrastructure: https://github.com/status-im/infra-misc/issues/189 \nTo have testnet properly deployed and available at nomos.tech domain, we need to deploy it on - New API: https://github.com/logos-co/nomos-node/pull/509 \nImplement a basic version concrete error for Overwatch: https://github.com/logos-co/Overwatch/pull/32 \nRemove included  blocks from mempool: https://github.com/logos-co/nomos-node/pull/485\nDA utilities: https://github.com/logos-co/nomos-node/pull/493  \nRework consensus API: https://github.com/logos-co/nomos-node/pull/502 \nInclude block ID during serialization of carnotinfo:\nhttps://github.com/logos-co/nomos-node/pull/505  \nOpened a new issue: https://github.com/logos-co/nomos-node/issues/506 \n\nprivate PoS §\nresearch §\n\nMulti-staking - prepared a discussion doc drafting a couple of ideas such as: how we can hide stake/voting power using homomorphic encryption and the consequences of that approach. The bottom line is that with Carnot and its tree structure we cannot follow the generic Proof of Stake approach and hide the voting power at the same time. We need to modify the Proof of Stake to follow the number of votes rather than the voting power during the vote aggregation phase. This modification bears consequences that need to be studied carefully, as the probability of a failure or liveness issues might be higher: Notion link \nRich Nodes Attack on Weighted Carnot worked out an attack that any private weighted-Carnot protocol will need to overcome: Notion link \nPrivate Weighted Voting w/ Ring Signatures a solution to the above attack that relies on ring signatures to break the connection between a vote and voter: Notion link \nFrom discussions on the above docs, started accumulating a summary of which behaviors to reward or penalize: List of Rewarded and Penalized Actions: Notion link \nDerived a probability distribution for the weights of committees for a scenario  when weights of nodes, modeled as random variables, are sampled in every voting round.\nA derivation of a probability distribution for a scenario when weights of nodes are only sampled once (currently in progress).\nWrote a simulation code which would  allow us  to compare failure probabilities in the above  two scenarios with the (unweighted) original Carnot version.\nDetails for probability distribution for the weights of committees for a scenario when weights of nodes, modeled as random variables, are sampled in every voting round, are provided in https://www.overleaf.com/read/kkmsngmcgbkj#c4de95 \nRewards for validators/delegators: the live document Notion link \nResearch notes on rewards for validators/delegators: Notion link \nList of Rewarded or Penalized Actions: Notion link \n\ndata availability §\nresearch §\n\nFinished the survey on the polynomial commitment schemes: Notion link  \nPCS related libraries were examined. The structures and benchmarks used were reviewed. Resources related to this were added to the research notes above. \nThis work in particular is a nice compilation:https://xn—2-umb.com/23/pc-bench/ \nStudied on EC+Commitment data structures. 1D or 1.5D structure may be more suitable for data availability within the scope of the Nomos project: Notion link \n\ndevelopment §\nmiscellaneous §\n\nNomos team will be at the offsite next week.\n"},"nomos/updates/2023-11-13":{"title":"2023-11-06 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nAnalysis of failure probability in random partitions of networks constructed from nodes with prescribed voting “weights”:\nConsidered a scenario when weights and Byzantine labels of nodes are sampled once, i.e. fixed, and then assigned to committees randomly.\nA derivation of a probability distribution for the random process is currently in progress\nConsidered designing a gradient descent algorithm which, given weights and Byzantine labels of nodes, tries to find assignments to committees with the smallest number of failures.\nAnalysis and implementation of the above algorithm is currently in progress. -reviewed literature on analysis of Loopix mixnets and implemented code for a simulation which computes fraction of de-anonymized messages.\nThe details on all of the above are provided in https://www.overleaf.com/read/kkmsngmcgbkj#c4de95\nWalked through core parts of Nym implementation again to get details of what are written in papers.\nClarified sphinx packet creation process (+ encryption): https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2#d0bbc9d1f63e43faaa30bb4c888102bd]\nClarified delay calculation in Poisson distribution (inspired to Nym impl): https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#3ae7e03fcbad461ab8d6b57e5c0e88fe\nClarified loop cover traffic creation & interval in Poisson (inspired to Nym impl): https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#14f53c5d6c844c828689f0412d5e2195\nSuggesting skipping two other types of cover traffic (at least, for now)\nDrop cover by nomos-node: https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#76993c1312ea464a88557987a2f37b60\nLoop cover by mix-node: https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#f07a473a4b5d4f338ff024a145f6b525\n\ndevelopment §\n\nNomos integration test stabilization: https://github.com/logos-co/nomos-node/pull/533\nMixnet implementation improvement\nFixed the concurrent packet handling in Mixnode: https://github.com/logos-co/nomos-node/pull/530\n\ntestnet §\ndevelopment §\n\nPublic deployment of Nomos testnet on nomos.tech infra: ⁠general, https://github.com/status-im/infra-misc/issues/189, https://github.com/logos-co/nomos-node/pull/513, https://github.com/logos-co/nomos-node/pull/520, https://github.com/logos-co/nomos-node/pull/524\nThe hardware and automation done and already running a master branch of our docker compose testnet. New tasks will be created for improving metrics, logging and stability, but this is a big milestone as we are now in control of this environment.\nPrometheus with new http api: https://github.com/logos-co/nomos-node/pull/522, https://github.com/logos-co/nomos-node/issues/523\nA proposal for metrics collection using prometheus, this will enable us to see what’s happening in the node network easier.\nSimulations finalization times debugging: The issue when views are advanced faster than they should in simulations remains, the ability to remove all network constraints didn’t resolve the issue. I still don’t know the main reason for it, hopefully this week we’ll have a breakthrough in this regard.\nFixed an issue with nomos-cli api https://github.com/logos-co/nomos-node/pull/525\nAdd options to provide custom writer for log https://github.com/logos-co/nomos-node/pull/518\nDisable logs https://github.com/logos-co/nomos-node/pull/517\nRemove process::exit(1) from library code https://github.com/logos-co/nomos-node/pull/516\nLimit carnot/blocks response size https://github.com/logos-co/nomos-node/pull/515\nDo not use 0x prefix in serialization https://github.com/logos-co/nomos-node/pull/514\nIdentified https://github.com/logos-co/nomos-node/issues/526\n\nprivate PoS §\nresearch §\n\n“Delegation and Validation Rewards” doc update: https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4\nMulti-staking: The discussion doc was discussed and we have decided that the complexities mentioned in the document are currently out of the scope.\nPrivate Leader Election: During the week it become more apparent that the private voting design is not a priority and we have decided to design a (general also multi-staking compatible) private leader election mechanism that is based on the single-staking design. The output is documented here: https://www.notion.so/Private-Leader-Election-for-Carnot-PoS-e720168ff3c44d098ec6a4aa586188da?pvs=4\nExplore interesting lines for PPoS:\n\n\n\n[Automatic Persistant Validator Identifier from Public Staking Transactions](https://www.notion.so/Public-Stake-Value-w-o-a-Persistent-Identifier-62a3237b97d44b87924ba3fff74f0362?pvs=4 “Automatic Persistant Validator Identifier from Public Staking Transactions)\n\n\nSingle Staking w/ Network Tricks\nFailed attempt: Hashed and Salted Stakes\nIs Network Privacy enough for PPoS\n\n\n\ndata availability §\nresearch §\n\n\n\ndevelopment §\nmiscellaneous §\n\nNomos team will be at the offsite this and next week (ends of 2023-11-23).\n"},"nomos/updates/index":{"title":"Nomos Weekly Updates","links":[],"tags":[],"content":"These are all the Nomos weekly updates that are reported to Logos Insight team."},"tags/component":{"title":"Components","links":["creating-components"],"tags":[],"content":"Want to create your own custom component? Check out the advanced guide on creating components for more information."},"tags/vac-updates":{"title":"Vac updates","links":[],"tags":[],"content":"Here are all files that are tagged with #vac-updates"},"terms-of-use":{"title":"Website Terms of Use","links":[],"tags":[],"content":"These terms and conditions (“Website Terms of Use”) are entered into by you and us, and they govern your access and use of the Website, including any content and functionality contained in the Website. \nIt is your responsibility to read the Website Terms of Use carefully before your use of the Website and your use of the Website means you have agreed to be bound and comply with these Website Terms of Use. \nIf you do not agree with these Website Terms of Use, you must not access or use the Website. \nDisclaimers §\nThe Website is provided by us on an ‘as is’ basis and you use the Website at your own sole discretion and risk.\nWe disclaim all warranties of any kind, express or implied, including without limitation the warranties of merchantability, fitness for a particular purpose, and non-infringement of intellectual property or other violation of rights. We do not warrant or make any representations concerning the completeness, accuracy, legality, utility, reliability, suitability or availability of the use of the Website, the content on this Website or otherwise relating to the Website, such content or on any sites linked to this site.These disclaimers will apply to the maximum extent permitted by applicable law. \nWe make no claims that the Website or any of its content is accessible, legally compliant or appropriate in your jurisdiction. Your access or use of the Website is at your own sole discretion and you are solely responsible for complying with any applicable local laws. \nThe content herein or as accessible through this Website is intended to be made available for informational purposes only and should not be considered as creating any expectations or forming the basis of any contract, commitment or binding obligation with us. No information herein shall be considered to contain or be relied upon as a promise, representation, warranty or guarantee, whether express or implied and whether as to the past, present or the future in relation to the projects and matters described herein.\nThe information contained herein does not constitute financial, legal, tax, or other advice and should not be treated as such. \nNothing in this Website should be construed by you as an offer to buy or sell, or soliciting any offer to buy or sell any tokens or any security. \nForward looking statements §\nThe Website may (or as made accessible through this Website) also contain forward-looking statements that are based on current expectations, estimates, forecasts, assumptions and projections about the technology, industry and markets in general.\nThe forward looking statements, which may include statements about the roadmap, project descriptions, technical details, functionalities, features, the development and use of tokens by projects, and any other statements related to such matters are subject to a high degree of risk and uncertainty. The forward looking statements are subject to change and are based on, among other things, market conditions, technical developments, and regulatory environment. The actual development and results, including the order and the timeline, might vary from what is presented. The information contained on this Website is a summary and does not purport to be accurate, reliable or complete and we bear no responsibility for the accuracy, reliability or completeness of information contained herein. Because of the high degree of risk and uncertainty described above, you should not place undue reliance on any matters described in this website or as accessible through this Website.\nWhile we aim to update our website regularly, all information, including the timeline and the specifics of each stage, is subject to change and may be amended or supplemented at any time, without notice and at our sole discretion.\nIntellectual property rights §\nThe Website and its contents are made available under free and open source licences. This means that anyone can use, share, and modify such content, as long as they follow the terms of the applicable licence. \nThird party website links §\nTo the extent the Website provides any links to a third party website, then their terms and conditions, including privacy policies, govern your use of those third party websites. We have no control over such third party websites and will not be liable for your use of or activities on any third party websites accessed through the Website. If you access such third party websites through the Website, it is at your own risk and you are solely responsible for your activities on such third party websites. \nThe Website may embed videos from Youtube, a service provided by Google LLC, using Youtube’s privacy-enhanced mode. When you interact with such videos, Youtube may place cookies on your personal device. The cookies do not directly identify individual users and YouTube will not store information to personalise your experience unless you are logged in to a Google account. We do not have any control over these cookies set by Youtube and it is recommended that you review YouTube’s embedding videos information page. \nLimitation of liability §\nWe will not be held liable to you under any contract, negligence, strict liability, or other legal or equitable theory for any lost profits, cost of procurement for substitute services, or any special, incidental, or consequential damages related to, arising from, or in any way connected with these Website Terms of Use, the Website, the content on the Website, or your use of the Website, even if we have been advised of the possibility of such damages. In any event, our aggregate liability for such claims is limited to EUR 100 (one hundred Euros). This limitation of liability will apply to the maximum extent permitted by applicable law.\nIndemnity  §\nYou shall indemnify us and hold us harmless from and against any and all claims, damages and expenses, including attorneys’ fees, arising from or related to your use of the Website, the content on the Website, including without limitation your violation of these Website Terms of Use. \nModifications §\nWe may modify or replace any part of this Website Terms of Use at any time and without notice. You are responsible for checking the Website periodically for any changes. The new Website Terms of Use will be effective immediately upon its posting on the Website.\nGoverning law §\nSwiss law governs these Website Terms of Use and any disputes between you and us, whether in court or arbitration, without regard to conflict of laws provisions.\nDisputes §\nIn these terms, “dispute” has the broadest meaning enforceable by law and includes any claim you make against or controversy you may have in relation to these Website Terms of Use, the Website, the content on the Website, or your use of the Website \nWe prefer arbitration over litigation as we believe it meets our principle of resolving disputes in the most effective and cost effective manner. You are bound by the following arbitration clause, which waives your right to litigation and to be heard by a judge. Please note that court review of an arbitration award is limited. You also waive all your rights to a jury trial (if any) in any and all jurisdictions. \nIf a (potential) dispute arises, you must first use your reasonable efforts to resolve it amicably with us. If these efforts do not result in a resolution of such dispute, you shall then send us a written notice of dispute setting out (i) the nature of the dispute, and the claim you are making; and (ii) the remedy you are seeking. \nIf we and you are unable to further resolve this dispute within sixty (60) calendar days of us receiving this notice of dispute, then any such dispute will be referred to and finally resolved by you and us through an arbitration administered by the Swiss Chambers’ Arbitration Institution in accordance with the Swiss Rules of International Arbitration for the time being in force, which rules are deemed to be incorporated herein by reference. The arbitral decision may be enforced in any court. The arbitration will be held in Zug, Switzerland, and may be conducted via video conference virtual/online methods if possible. The tribunal will consist of one arbitrator, and all proceedings as well as communications between the parties will be kept confidential. The language of the arbitration will be in English. Payment of all relevant fees in respect of the arbitration, including filing, administration and arbitrator fees will be in accordance with the Swiss Rules of International Arbitration. \nRegardless of any applicable statute of limitations, you must bring any claims within one year after the claim arose or the time when you should have reasonably known about the claim. You also waive the right to participate in a class action lawsuit or a classwide arbitration against us. \nAbout these Website Terms of Use §\nThese Website Terms of Use cover the entire agreement between you and us regarding the Website and supersede all prior and contemporaneous understandings, agreements, representations and warranties, both written and oral, with respect to the Website. \nThe captions and headings identifying sections and subsections of these Website Terms of Use are for reference only and do not define, modify, expand, limit, or affect the interpretation of any provisions of these Website Terms of Use. \nIf any part of these Website Terms of Use is held invalid or unenforceable, that part will be severable from these Website Terms of Use, and the remaining portions will remain in full force and effect. If we fail to enforce any of these Website Terms of Use, that does not mean that we have waived our right to enforce them."},"vac/acz/index":{"title":"Applied Cryptography and Zero-knowledge Service Unit","links":["vac/acz/rlnp2p/waku/production-readiness","vac/acz/rlnp2p/waku/rln-membership-management","vac/acz/rlnp2p/waku/rln-relay-enhancements","vac/acz/rlnp2p/waku/rln-relay-enhancements_02","vac/acz/rlnp2p/waku/rln-relay-erc20","vac/acz/rlnp2p/waku/rlnv2-relay-integration","vac/acz/rlnp2p/waku/rln-multi-epoch-constraints","vac/acz/rlnp2p/vac/rln-doc-and-outreach","vac/acz/zerokit/vac/zerokit-v0-4","vac/acz/zerokit/vac/zerokit-v0-5","vac/acz/zerokit/vac/maintenance","vac/acz/secure-channels/waku/ethereum-chat"],"tags":["acz","vac"],"content":"vac:acz: §\n\nrlnp2p:waku: §\n\n production-readiness\n rln-membership-management\n rln-relay-enhancements\nrln-relay-enhancements_02\nrln-relay-erc20\nrlnv2-relay-integration\nrln-multi-epoch-constraints\n\nrlnp2p:vac: §\n\nrln-doc-and-outreach\n\nzerokit:vac: §\n\n zerokit-v0.4\nzerokit-v0.5\nmaintenance\n\nsecure-channels:waku: §\n\nethereum-chat\n"},"vac/acz/rlnp2p/vac/rln-doc-and-outreach":{"title":"RLN Doc and Outreach","links":[],"tags":[],"content":"vac:acz:rlnp2p:vac:rln-doc-and-outreach §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n RLN doc and outreach: done, 2023-01-20, 2023-07-31\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\n\nWaku doc: How can a user setup Waku + RLN?\n\neven though Waku RLN does not support slashing yet, we can see RLN as that provides an additional datapoint regarding message validity\n\n\ndoc explaining how the components of RLN (zerokit, contract, and a project using it, e.g. Waku, work together)\n\nthis can be in notion at first\n\n\nrlog post based on the two points above\ntalk @ progcrypto and logos event in Istanbul (co-located with devconnect)\n\nJustification §\nDeliverables §"},"vac/acz/rlnp2p/waku/production-readiness":{"title":"RLNP2P Waku Pruduction Readiness Details","links":[],"tags":[],"content":"vac:acz:rlnp2p::waku:production-readiness §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tProduction Readiness :done, 2023-01-20, 2023-07-31\n\n\ndue: 2023/07/31\nstatus: 100%\n\nDescription §\nmembership management is out of scope for this milestone\nDeliverables §\nTBD"},"vac/acz/rlnp2p/waku/rln-membership-management":{"title":"Waku RLN Membership Management Details","links":["waku/"],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-membership-management §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN Membership Management :done, 2023-01-20, 2023-09-30\n\n\ndue: 2023/09/30\nstatus: 100%\n\nDescription §\nEnhancing the first simple CC membership list\nRisks §\n\ndepends on input from Waku\n\nInfo §\n2023/09/04 - 2023/09/11 §\n\nadded documentation for rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1993\n\n2023/08/28 - 2023/09/04 §\n\nfixed makefile target for rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1960\nlog the membership index out upon registration in the rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1963\n\n2023/08/21 - 2023/08/28 §\n\nDemo of rln_keystore_generator: https://github.com/waku-org/nwaku/pull/1956\nWrote a tool rln_keystore_generator\n\nhttps://github.com/waku-org/nwaku/pull/1925\nhttps://github.com/waku-org/nwaku/pull/1928\nhttps://github.com/waku-org/nwaku/pull/1931\n\n\n"},"vac/acz/rlnp2p/waku/rln-multi-epoch-constraints":{"title":"Multi Epoch Constraints","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:multi-epoch-constraints §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Multi epoch constraints: 2023-09-15, 2023-11-15\n\n\nstatus: 0%\nCC: Ramses\n\nDescription §\nCurrently, RLN v1 allows for a fixed message rate of 1/msg per epoch while RLN v2 allows for n msgs/epoch.\nThe goal of this milestone is designing the key derivation and related cryptographic components for allowing several n msgs/epoch constraints.\nFor example: 24 msg / day && 1 msg/10 seconds.\n\nthe nullifier defined in the RLN RFC has to be adapted accordingly.\n\nJustification §\nDeliverables §"},"vac/acz/rlnp2p/waku/rln-relay-enhancements":{"title":"Waku RLN-RELAY Enhancements Details","links":[],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-relay-enhancements §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN-RELAY enhancements :, 2023-06-01, 2023-09-30\n\n\ndue: 2023/09/30\nstatus: 100%\n\nDescription §\n\nsimple membership management setup (fixed CC list)\ninstruction on how to register to the membership set / setup up (for Waku CCs)\n\nGoal §\nRun RLN relay on the Waku production fleet. Waku CCs can use it\nInfo §\n2023/09/04 - 2023/09/11 §\n\nif only one key exists in the keystore, use it - https://github.com/waku-org/nwaku/pull/1984\nfix log levels for some logs - https://github.com/waku-org/nwaku/pull/1986\nupdated documentation for rln-relay - https://github.com/waku-org/nwaku/pull/1993\nclean nullifier table every MaxEpochGap - https://github.com/waku-org/nwaku/pull/1994\ncreated rln_db_inspector tool, allows inspection into merkle tree structure - https://github.com/waku-org/nwaku/pull/1999, https://github.com/waku-org/nwaku/pull/2012\nfixed missing memberships between history sync and new memberships sync with @alrevuelta - https://github.com/waku-org/nwaku/pull/2015\nremove rln from waku’s experimental features - https://github.com/waku-org/nwaku/pull/2001\nfix metric calculation for registered members - https://github.com/waku-org/nwaku/pull/2018\nuups proxy for waku-rln-registry - https://github.com/waku-org/waku-rln-contract/pull/9\n\n2023/08/28 - 2023/09/04 §\n\nrln was enabled by default in the Makefile - fixed - https://github.com/waku-org/nwaku/pull/1964\nordered pubsub validator execution - https://github.com/waku-org/nwaku/pull/1966\nfixed deserialization of valid merkle roots - https://github.com/waku-org/nwaku/pull/1973\nconfirm that the fetched credential from the keystore is registered to the membership set - https://github.com/waku-org/nwaku/pull/1980\nfixed makefile target for zerokit’s librln.a - https://github.com/waku-org/nwaku/pull/1981\nconverted zero-based indexing to 1-based indexing on vacp2p/rln-contract - https://github.com/vacp2p/rln-contract/pull/28\ndownstreamed zero-based indexing to waku-org/waku-rln-contract - https://github.com/waku-org/waku-rln-contract/pull/8 -\ndeployed new version of the registry contract on sepolia - 0xc04937d502E0ae671cedFC2A0BCD6692055520f3\n\n2023/08/21 - 2023/08/28 §\n\ntree metadata should include chainId and contractAddress - https://github.com/waku-org/nwaku/pull/1932\nset flush_interval appropriately -https://github.com/waku-org/nwaku/pull/1933\nintegrate new WakuRlnRegistry contract - https://github.com/waku-org/nwaku/pull/1943\nbump zerokit to v0.3.2\nhttps://github.com/waku-org/nwaku/pull/1951\ntree metadata should include window of roots - https://github.com/waku-org/nwaku/pull/1953\nsync tree state from contract deployed block number - https://github.com/waku-org/nwaku/pull/1955\noptimization to waku_keystore - https://github.com/waku-org/nwaku/pull/1956\nfixed a forceProgression bug in the WakuRlnRegistry contract - https://github.com/waku-org/waku-rln-contract/pull/6\n\n2023/08/14 - 2023/08/21 §\n\nrpc handler for waku rln relay - https://github.com/waku-org/nwaku/pull/1852\nfixed ganache’s change in method to manage subprocesses, fixed timeouts related to it - https://github.com/waku-org/nwaku/pull/1913\nshould error out on rln-relay mount failure - https://github.com/waku-org/nwaku/pull/1904\nfixed invalid start index being used in rln-relay - https://github.com/waku-org/nwaku/pull/1915\nconstrain the values that can be used as idCommitments in the rln-contract - https://github.com/vacp2p/rln-contract/pull/26\nassist with waku-simulator testing\nremove registration capabilities from nwaku, it should be done out of band - https://github.com/waku-org/nwaku/pull/1916\nadd deployedBlockNumber to the rln-contract for ease of fetching events from the client - https://github.com/vacp2p/rln-contract/pull/27\n\n2023/08/07 - 2023/08/14 §\n\nCreated tracking issue to manage status of this milestone - https://github.com/waku-org/nwaku/issues/1906\n\n2023/07/31 - 2023/08/07 §\n\nWaku RLN contract registry\nMark duplicated messages as spam\nUse waku-org/waku-rln-contract as a submodule in nwaku\n\nDeliverables §\n\nhttps://github.com/waku-org/nwaku/issues/1906\n"},"vac/acz/rlnp2p/waku/rln-relay-enhancements_02":{"title":"Waku RLN-RELAY Enhancements 02","links":["vac/acz/rlnp2p/waku/rln-relay-enhancements"],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-relay-enhancements §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN-RELAY enhancements :, 2023-09-01, 2023-11-31\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\n\ncontinuation of rln-relay-enhancements\ncomprises further enhancements of RLN relay, requested by the Waku team\n\nJustification §\nRisks §\nDeliverables §"},"vac/acz/rlnp2p/waku/rln-relay-erc20":{"title":"RLN relay ERC20","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:rln-relay-erc20 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Production Readiness: , ,\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\n\nfuture work\n\nJustification §\nDeliverables §"},"vac/acz/rlnp2p/waku/rlnv2-relay-integration":{"title":"RLN v2 Waku Relay Integration","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:rlnv2-relay-integration §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n RLN v2 relay integration: 2023-11-01, 2024-02-29\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\n\nalso involves\n\nTKE\nimplemenations in various Waku versions\n\n\n\nJustification §\nDeliverables §"},"vac/acz/secure-channels/waku/ethereum-chat":{"title":"Ethereum Chat","links":[],"tags":[],"content":"vac:acz:secure-channels:waku:ethereum-chat §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Ethereum Chat: 2023-09-12, 2023-11-30\n\n\nstatus: 0%\nCC: Ramses\n\nDescription §\nThe goal of this milestone is having\n\n\nusing the noise framework\n\n\nEthereum Wallet address used to derive authentication key for noise\n\n\nDesign an Ethereum address-based 1:1 chat\n\nshould be transport agnostic\ntoy eth chat: https://rfc.vac.dev/spec/20/\n\nthis milestone requires forward secrecy (see limitations section of the toy eth chat RFC)\n\n\nconsider using https://eips.ethereum.org/EIPS/eip-5564\n\n\n\nNaive Groupchat functionality (using n 1:1 chat channels)\n\n\ninvolve metamask here (metamask im team)\n\n\na follow up milestone will cover running Ethereum chat on top of Waku\n\n\nfollow up goal: develop this into an EIP\n\n\nJustification §\nDeliverables §\n\nspecification (RFC) of a secure Ethereum-based chat protocol\n"},"vac/acz/zerokit/vac/maintenance":{"title":"maintenance","links":[],"tags":[],"content":""},"vac/acz/zerokit/vac/zerokit-v0-4":{"title":"Zerokit v0.4 Release Details","links":[],"tags":[],"content":"vac:acz:zerokit::vac:zerokit-v0.4 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection zerokit\n\t\tv0.4 Release :done, 2023-01-20, 2023-09-07\n\n\ndue: 2023/09/07\nstatus: 100%\n\nDescription §\n\nRelease Planning - Github Issue #197\n\nDeliverables §\n\nhttps://github.com/vacp2p/zerokit/releases/tag/v0.4.0\n\nInfo §\n2023/08/14 - 2023/08/21 §\n\nsubstitute id_commitments for rate_commitments and update tests in rln-v2 - https://github.com/vacp2p/zerokit/pull/205\nrln-v2 working branch - https://github.com/vacp2p/zerokit/pull/204\n\n2023/08/07 - 2023/08/14 §\n\nSerde api’s updated - https://github.com/vacp2p/zerokit/pull/202\n\n2023/07/31 - 2023/08/07 §\n\nzerokit v0.4.0 release planning - https://github.com/vacp2p/zerokit/issues/197\n"},"vac/acz/zerokit/vac/zerokit-v0-5":{"title":"Zerokit v0.5 Release","links":[],"tags":[],"content":"vac:acz:zerokit::vac:zerokit-v0.5 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n\tdateFormat YYYY-MM-DD\n\tsection zerokit\n\t\tv0.5 Release: 2023-10-01, 2024-02-29\n\n\nstatus: 5%\nCC: Aaryamann\n\nDescription §\n\n\nRelease Planning issue:\n\n\nmain focus: RLN performance improvements\n\nexplore using kzg proofs\n\n\n\nDeliverables §\nInfo §\n\nWe have a benchmarking suite done\n"},"vac/dr/consensus/nomos/blockchain-security-in-crypto-economic-models":{"title":"Blockchain Security in Crypto-economic Models","links":[],"tags":[],"content":"vac:dr:consensus:vac:blockchain-security-in-crypto-economic-models §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Blockchain Security in Crypto-economic Models: 2023-11-01, 2024-02-29\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nThis research will provide a comprehensive security analysis of Carnot under the Crypto Economic Model.\nThis is a new security model for distributed consensus algorithms in which economic attacks on the protocol will be considered.\nJustification §\nThe combination of PoS and distributed consensus, necessitates a new comprehensive security model for blockchain ecosystem.\nRisks §\nThis is a new research direction.\nDeliverables §\n\nconference paper\n"},"vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation":{"title":"Carnot 2/3 Vote aggregation","links":["roadmap/vac/dst/dr-support/vac/carnot-2-3rds-executable-spec"],"tags":[],"content":"vac:dr:nomos:nomos:carnot-vote-2-3rds-vote-aggregation §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot 2/3 Vote Aggregation: 2023-08-01, 2023-10-15\n\n\nstatus: 20%\nCC: Moh\n\nDescription §\nThis research will use the Carnot flexible design to make it collect more than 2/3rd of cryptographic proof of votes cast for a block.\n\n\nwrite a research log post\n\n\ndesciption of the solution\n\n\nsupport by the DST team: carnot-2rds-executable-spec\n\n\nRisks §\nMight slightly increase the protocol overhead. But we make sure this overhead is minimal.\nJustification §\nDeliverables §\n\n Presentation slides (logos research)\nPseudocode (potentially paper in a future milestone)\nnotion doc describing the solution\nresearch log post\npython code, support by the DST team carnot-2rds-executable-spec\nRFC on rfc.vac.dev containing executable spec\n\nNote: Need to be discussed: The Pseudocode can be completed earlier so that devs can began implementation, whereas the paper can be completed later."},"vac/dr/consensus/nomos/carnot-bribary-article":{"title":"Carnot Bribary Article","links":[],"tags":[],"content":"vac:dr:consensus:nomos:carnot-bribary-article §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot Bribary Article: 2023-08-01, 2023-08-31\n\n\nstatus: ?%\nCC:\n\nDescription §\nThe article describes how multi-dimensional bribery attacks cannot be addressed at the consensus layer alone.\nA proper game theoretical, economic analysis also needs to be done. The solution to this problem will also touch on several aspects\nincluding the economy, distributed systems, and cryptography.\nThis Milestone also comprises a presentation:\nThis presentation slide describes how multi-dimensional bribery attacks cannot\nbe addressed at the consensus layer alone. By combining PoS with the\ndistributed consensus a new dimension is introduced into the ecosystem. Now the\nsecurity of the protocol should also be considered against economic attacks.\nThe presentation provides an example based on the Crypto Economic security\nmodel of how any PoS consensus protocol can fail against a bribing attack. The\npresentation emphasizes that a proper game theoretical, and economic analysis\nalso needs to be done. It also suggests a solution for addressing bribing\nattacks in Carnot consensus.\nRisks §\nThis problem has not been properly addressed for PoS protocols.\nJustification §\nDeliverables §\n\n\nA report on how bribery attacks can be addressed in PoS. This will ultimately give a new research direction.\n\n\npresentation slides\n\n\ncurrent status\n\n"},"vac/dr/consensus/nomos/carnot-paper":{"title":"Carnot Paper","links":[],"tags":[],"content":"vac:dr:consensus:nomos:carnot-paper §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot Paper: done, 2023-01-20, 2023-09-30\n\n\nstatus: 100%\nCC: Moh\n\nDescription §\nFirst version of a scientific carnot paper.\nPublish on arxiv.\nJustification §\nDeliverables §\n\nhttps://arxiv.org/pdf/2308.16016.pdf\n"},"vac/dr/consensus/nomos/carnot-paper_02":{"title":"Carnot Paper 02","links":[],"tags":[],"content":"vac:dr:consensus:nomos:carnot-paper_02 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot Paper: 2023-09-01, 2024\n\n\nstatus: 10%\nCC: Moh\n\nDescription §\n\n\ncomplete experimental results\n\n\npublish the paper at a scientific conference or journal\n\n\npresent the paper at the conference\n\n\nthe goal is to submit before end of 2023\n\n\nRisks §\n\nWe need to find a fitting conference and the respective deadlines might not align.\nreview process takes a long time\n\n(No fixed deadline because of these risks.)\nJustification §\nDeliverables §"},"vac/dr/consensus/nomos/detecting-reporting-attacks-carnot":{"title":"Detecting Reporting Attacks Carnot","links":[],"tags":[],"content":"vac:dr:consensus:nomos:detecting-reporting-attacks-carnot §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Detecting Reporting Attacks Carnot: 1970-01-01, 1970-01-02\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nThis research work will describe the mechanism of how various attacks can be detected, reported, and slashed in the consensus.\nJustification §\nDeliverables §\n\nalgorithm\npseudocode\nspec\nrlog post\n"},"vac/dr/consensus/nomos/inter-chain-protocol":{"title":"Inter Chain Protocol","links":[],"tags":[],"content":"vac:dr:consensus:nomos:inter-chain-protocol §\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nExploring the interplay between the main chain and execution zones or chains is a pivotal aspect of our research.\nOur inquiry delves into how these zones are initiated from the main chain, ensuring their security and data availability.\nAdditionally, we address the optimization of interaction among independent chains, facilitating efficient cross-chain communication and collaboration.\nJustification §\nDeliverables §\n\nAlgorithm\nspec\n"},"vac/dr/consensus/nomos/multi-leader-and-multi-overlay-carnot":{"title":"Multi-Leader and Multi-Overlay Carnot","links":[],"tags":[],"content":"vac:dr:consensus:nomos:multi-leader-and-multi-overlay-carnot §\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nIn pursuit of heightened resilience and performance optimization, our research extends to multi-leader and multi-overlay Carnot configurations.\nThis direction seeks to bolster the protocol’s resistance against Denial of Service (DoS) and bribery attacks.\nBy introducing multiple leadership nodes and overlay structures, we envision a protocol that thrives in adversarial environments while maintaining exceptional performance standards.\nAs we navigate this deep research trajectory, our collective efforts contribute to the advancement of blockchain technology, ushering in a new era of consensus, privacy, and scalability.\nHas to adhere to Nomos architecture (specific specifications)\n\nNomos Whitepaper\nhas to adhere to privacy requirements\n\nJustification §\nDeliverables §\n\nAlgorithm\nspec\n"},"vac/dr/consensus/nomos/stake-privacy-timing-attacks":{"title":"Network Privacy Stack - Stakeholder Privacy","links":[],"tags":[],"content":"vac:dr:consesus:nomos:stake-privacy-timing-attacks §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Stake Privacy - Timing Attacks:\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nThis milestone comprises component 3 of the Nomos network privacy stack\nin the context of consensus privacy:\nThe main goal of this work is finding in-protocol (carnot) mechanisms to solve the problem of timing attacks.\nUpper layer protections of the network from the sender: Simplest solution to prevent attacks to private PoS: minimum age of transaction for inclusion.\nCertain types of timing attacks and network observation to identify high stake participants are already being worked on at the network level.\nHowever, this problem should be considered at the PoS/consesus layer as well.\nmore info §\n\npaper: On the Anonymity Guarantees of Anonymous Proof-of-Stake Protocols\n\nFrom the abstract:\n[...] focus on anonymizing the\nmessages of the blockchain protocol, but suggest that potential identity leaks from the networklayer can be removed as well by employing anonymous broadcast channels.\nIn this work we show that this intuition is flawed.\n\nGenerally, our endeavor in stake privacy research centers on preserving the confidentiality of validator stakes.\nBy leveraging cryptographic techniques and innovative approaches, we aim to enhance the privacy and security of staking operations within the Carnot ecosystem.\nOlder docs:\n\nHash-based Node Id encryption Hash-based-Node-Id-encryption-7bfb11941a6840c49bfe065f535877c9?pvs=24\nCarnot PoS Discussion notion.so/Carnot-PoS-Discussion-f2ef371102f6433da81fb1b1b9213c2b?pvs=24\n\nPotential future solutions (outside the scope of this mile stone) comprise: proof of mixing + modifications to the base mixnet design. This seems like a difficult path, for long-term research if feasible.\nJustification §\nThis is and important step towards achieving the Nomos privacy requirements.\nDeliverables §\n\nspecification\n"},"vac/dr/g/nomos/reviews":{"title":"Reviews","links":[],"tags":[],"content":"vac:dr:g:nomos:reviews §\n\n\nstatus: ongoing\nCC: team\n\nDescription §\nJustification §\nDeliverables §"},"vac/dr/gsub-scaling/vac/gossipsub-improvements-paper":{"title":"Gossipsub Improvements Paper","links":[],"tags":[],"content":"vac:dr:gsub-scaling:vac:gossipsub-improvements-paper §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Gossipsub Improvements paper: 2023-06-01, 2023-10-31\n\n\nstatus: 70%\nCC: Farooq\n\nDescription §\nbackground + first results + potential improvements\n\n\ncomprehensive current/related work study on gossipsub scaling (including relevant work outside of gossipsub, in the broader area of unstructured P2P networks in general)\ncomplete technical report on gossip scaling / gossipsub improvements (containing, but not limited to, our previous research)\nresearch log post (vac.dev) based on the techreport\ntalk @ Logos research call\nscientific paper ready for publication\n\nJustification §\nDeliverables §"},"vac/dr/gsub-scaling/vac/gossipsub-simulation":{"title":"Gossipsub Simulation","links":[],"tags":[],"content":"vac:dr:gsub-scaling:vac:gossipsub-simulation §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Gossipsub Simulation: 2023-06-31, 2023-09-30\n\n\nstatus: 20%\nCC: Farooq\n\nDescription §\n\nsimple gossipsub node (in nim) for DST/Wakurtosis simulations\nPoC shadow simulation\n\nJustification §\nDeliverables §"},"vac/dr/gsub-scaling/vac/unstructured-p2p-improvements-survey":{"title":"Unstructured P2P Improvements Survey","links":[],"tags":[],"content":"vac:dr:gsub-scaling:vac:unstructured-p2p-improvements-survey §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Unstructured P2P Improvements Survey: 2023-08-15, 2023-12-31\n\n\nstatus: 20%\nCC: Farooq\n\nDescription §\n\nsurvey techreport\nsurvey scientific paper if there is enough to justify a paper\n\nJustification §\nDeliverables §"},"vac/dr/index":{"title":"Deep Research Service Unit","links":["vac/dr/valpriv/vac/tor-push-poc","vac/dr/valpriv/vac/tor-push-rel-work","vac/dr/valpriv/vac/tor-push-paper","vac/dr/valpriv/vac/tor-push-rln","vac/dr/valpriv/vac/priv-validator-network","vac/dr/valpriv/vac/mix-net-solution","vac/dr/valpriv/nomos/validator-privacy","vac/dr/gsub-scaling/vac/gossipsub-simulation","vac/dr/gsub-scaling/vac/gossipsub-improvements-paper","vac/dr/gsub-scaling/vac/unstructured-p2p-improvements-survey","vac/dr/consensus/nomos/carnot-paper","vac/dr/consensus/nomos/carnot-paper_02","vac/dr/consensus/nomos/carnot-bribary-article","vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation","vac/dr/consensus/nomos/blockchain-security-in-crypto-economic-models","vac/dr/consensus/nomos/detecting-reporting-attacks-carnot","vac/dr/consensus/nomos/stake-privacy-timing-attacks","vac/dr/consensus/nomos/inter-chain-protocol","vac/dr/consensus/nomos/multi-leader-and-multi-overlay-carnot","vac/dr/zk/codex/storage-proofs-open-problems-review","vac/dr/g/nomos/reviews"],"tags":["dr","vac"],"content":"vac:dr:valpriv:vac: §\n\ntor-push-poc\ntor-push-rel-work\ntor-push-paper\ntor-push-rln\npriv-validator-network\nmix-net-solution\n\nvac:dr:valpriv:nomos: §\n\nvalidator-privacy\n\nvac:dr:gsub-scaling:vac: §\n\ngossipsub-simulation\ngossipsub-improvements-paper\nunstructured-p2p-improvements-survey\n\nvac:dr:consensus:nomos: §\n\n carnot-paper\ncarnot-paper_02\ncarnot-bribary-article\ncarnot-2-3rds-vote-aggregation\nblockchain-security-in-crypto-economic-models\ndetecting-reporting-attacks-carnot\nstake-privacy-timing-attacks\ninter-chain-protocol\nmulti-leader-and-multi-overlay-carnot\n\nvac:dr:zk:codex: §\n\nstorage-proofs-open-problems-review\n\nvac:dr::nomos: §\n\nreviews\n"},"vac/dr/valpriv/nomos/validator-privacy":{"title":"validator-privacy","links":[],"tags":[],"content":""},"vac/dr/valpriv/vac/mix-net-solution":{"title":"mix-net-solution","links":[],"tags":[],"content":""},"vac/dr/valpriv/vac/priv-validator-network":{"title":"priv-validator-network","links":[],"tags":[],"content":""},"vac/dr/valpriv/vac/tor-push-paper":{"title":"Tor Push Paper","links":[],"tags":[],"content":"vac:dr:valpriv:vac:tor-push-paper §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Tor Push Paper: 2023-08-01, 2023-11-30\n\n\nstatus: 30%\nCC: Umar\n\nDescription §\nComprises:\n\nthorough anonymity/sec analysis of Tor push for Validator privacy\nthorough latency analysis of Tor push\npaper (for workshop) on introducing and analysing Tor-push\n\nJustification §\nDeliverables §"},"vac/dr/valpriv/vac/tor-push-poc":{"title":"Tor Push PoC","links":["vac/dr/valpriv/vac/tor-push-paper"],"tags":[],"content":"vac:rc:valpriv:vac:tor-push-poc §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Tor Push PoC: 2023-06-01, 2023-09-15\n\n\nstatus: 80%\nCC: Umar\n\nDescription §\n\n first PoC of Tor push in Nimbus (testnet Goerli) https://github.com/vacp2p/nimbus-eth2-experimental/issues/1\n\nfirst latency measurements (comprehensive analysis in next milestone)\n\n\nresearch log post on Tor push / Nimbus PoC incl first latency measurements\nadd epoch support as described in the RFC\nupdate/adjust Tor push spec\ntalk @ Logos research call\nrefine PoC (should fully cover the RFC)\nthorough latency measurements fortor-push-paper\n\nInfo §\n\nThe epochs\n\nJustification §\nDeliverables §\n\n[WIP] https://github.com/vacp2p/nimbus-eth2-experimental/pull/3\n"},"vac/dr/valpriv/vac/tor-push-rel-work":{"title":"Tor Push Related Work","links":[],"tags":[],"content":"vac:dr:valpriv:vac:tor-push-rel-work §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Tor Push Related Work: done, 2023-06-01, 2023-09-15\n\n\nstatus: 100%\nCC: Umar\n\nDescription §\nBackground and motivation here.\n\ncomprehensive current/related work study on Validator Privacy\n\nfocus on network layer but also including: network vs consesus layer privacy (SSLE), as well as combinations\n\n\n\nJustification §\nDeliverables §"},"vac/dr/valpriv/vac/tor-push-rln":{"title":"tor-push-rln","links":[],"tags":[],"content":""},"vac/dr/zk/codex/storage-proofs-open-problems-review":{"title":"Storage Proofs: Open Problems Review","links":[],"tags":[],"content":"vac:dr:zk:codex:open-problems-review §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Open Problems Review: 2023-09-20, 2023-11-30\n\n\nstatus: 0%\nCC: Marvin\n\nDescription §\n\nhttps://github.com/codex-storage/zk-research-artifacts/blob/master/storage_proofs/storage_proof_musings.md\n\nJustification §\nDeliverables §"},"vac/dst/analysis-gsub-model/status/control-messages":{"title":"Control Messages","links":[],"tags":[],"content":"vac:dst:analysis-gsub-model:status:control-messages §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Control Messages: 2023-07-01, 2023-09-15\n\n\nstatus: 85%\nCC: Ganesh\n\nDescription §\nJustification §\nInfo §\n\ndelayed because of extending Nomos analysis milestone\n\nDeliverables §"},"vac/dst/analysis-gsub-model/vac/refactoring":{"title":"Refactoring","links":[],"tags":[],"content":"vac:dst:analysis-gsub-model:vac:refactoring §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Refactoring: 2023-08-01, 2023-09-30\n\n\nstatus: 40%\nCC: Ganesh\n\nDescription §\nJustification §\nDeliverables §"},"vac/dst/analysis-shadow/vac/shadow-basic-simulation":{"title":"Basic Shadow Simulation","links":[],"tags":[],"content":"vac:dst:analysis-shadow:vac:basic-shadow-simulation §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Basic Shadow Simulation: 2023-08-01, 2023-08-31\n\n\nstatus: 90%\nCC: Jordi\n\nDescription §\n\nsimple 10k shadow sim of the gossipsub node as a PoC.\n\nJustification §\nDeliverables §"},"vac/dst/analysis-shadow/vac/shadow-gossipsub-analysis":{"title":"Shadow Gossipsub Analysis","links":[],"tags":[],"content":"vac:dst:analysis-shadow:vac:shadow-gossipsub-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Shadow Gossipsub Analysis: 2023-09-01, 2023-10-31\n\n\nstatus: 0%\nCC: Jordi\n\nDescription §\n\ndevelop a gossipsub node with allows to set desired message rates and other properties\ntry to get to a higher node number (50k?)\nresearch log post\n\nJustification §\nDeliverables §"},"vac/dst/analysis-shadow/waku/shadow-waku-relay-analysis":{"title":"Shadow Waku Relay Analysis","links":[],"tags":[],"content":"vac:dst:analysis-shadow:waku:shadow-waku-relay-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Shadow Waku Relay Analysis: done, 2023-10-01, 2023-11-30\n\n\nstatus: 0%\nCC: Jordi\n\nDescription §\nJustification §\nDeliverables §"},"vac/dst/analysis/nomos/nomos-simulation-analysis":{"title":"Simulation Analysis","links":[],"tags":[],"content":"vac:dst:analysis:nomos:simulation-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Simulation Analysis: 2023-08-01, 2023-09-15\n\n\nstatus: 70%\nCC: Ganesh\n\nDescription §\nJustification §\nInfo §\nExtended:\n\n\ninclude signature aggregation into analysis\n\n\nwrite analysis section in Carnot paper\n\n\nnomos node\n\n\nnomos simulations\n\n\nDeliverables §"},"vac/dst/dr-support/vac/carnot-executable-spec":{"title":"Carnot 2-3rds Vote Aggregation Python Implementation","links":["vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation"],"tags":[],"content":"vac:dst:dr-support:vac:carnot-2-3rds-python-impl §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot 2/3rds Python Impl: 2023-09-15, 2023-10-31\n\n\nstatus: 0%\nCC: Ganesh\n\nDescription §\n\nsupport the DR team with writing the python code for a executable specification of the Carnot 2/3rds vote aggregation\n\nsee DR milestone: carnot-2-3rds-vote-aggregation\n\n\n\nJustification §\nDeliverables §"},"vac/dst/eng-10ktool/vac/bandwidth-test":{"title":"Bandwidth Test","links":[],"tags":[],"content":"vac:dst:eng-10ktool:vac:bandwidth §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Bandwidth Test: 2023-08-01, 2023-10-31\n\n\nstatus: 80%\nCC: Alberto\n\nDescription §\nA first version of tool that allows running >10k gossipsub / waku relay nodes.\nThe tool should measure bandwidth usage per node and bundle the simulation data for analaysis.\nJustification §\nDeliverables §\n\nhttps://github.com/vacp2p/cs-codex-dist-tests\n"},"vac/dst/eng-10ktool/vac/qos":{"title":"QoS","links":[],"tags":[],"content":"vac:dst:eng-10ktool:vac:qos §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n QoS 10ktool: 2023-11-01, 2023-12-31\n\n\nstatus: 0%\nCC: Alberto\n\nDescription §\nAdd QoS parameter support to the 10k tool.\nJustification §\nDeliverables §"},"vac/dst/eng-10ktool/waku/waku-protocols":{"title":"Waku Protocols","links":[],"tags":[],"content":"vac:dst:eng-10ktool:waku:waku-protocols §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Waku Protocols: 2023-11-01, 2023-12-31\n\n\nstatus: 0%\nCC: Alberto\n\nDescription §\nSo far, we tested gossip / relay, as well as discv5.\nThis milestone comprises running further Waku protocols, namely:\n\nfilter\nlightpush\nstore\npeer exchange\n\nJustification §\nDeliverables §"},"vac/dst/eng/vac/bundle-simulation-data":{"title":"Bundle Simulation Data","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:production-readiness §\n\n\nstatus: ongoing\nCC:\n\nDescription §\nThe Vac DST engineering team runs simulations, bundles the resulting data, and delivers.\nJustification §\nDeliverables §"},"vac/dst/index":{"title":"Distributed Systems Testing Service Unit","links":["vac/dst/wakurtosis/waku/techreport","vac/dst/wakurtosis/waku/techreport_02","vac/dst/wakurtosis/waku/techreport_03","vac/dst/wakurtosis/waku/features","vac/dst/wakurtosis/waku/gossipsub-topology-analysis","vac/dst/wakurtosis/nomos/ci-integration","vac/dst/wakurtosis/vac/rlog","vac/dst/wakurtosis/vac/retrospective-rlog","vac/dst/wakurtosis/vac/maintenance","vac/dst/analysis/nomos/nomos-simulation-analysis","vac/dst/analysis-gsub-model/vac/refactoring","vac/dst/analysis-gsub-model/status/control-messages","vac/dst/analysis-shadow/vac/shadow-basic-simulation","vac/dst/analysis-shadow/vac/shadow-gossipsub-analysis","vac/dst/analysis-shadow/waku/shadow-waku-relay-analysis","roadmap/vac/dst/dr-support/vac/carnot-2-3rds-executable-spec","vac/dst/eng/vac/bundle-simulation-data","vac/dst/eng-10ktool/vac/bandwidth-test","vac/dst/eng-10ktool/vac/qos","vac/dst/eng-10ktool/waku/waku-protocols","vac/dst/software-testing/waku/test-plans","vac/dst/software-testing/waku/test-automation-js-waku","vac/dst/software-testing/waku/test-automation-nwaku","vac/dst/software-testing/waku/test-automation-go-waku","vac/dst/software-testing/waku/interop-testing"],"tags":["dst","vac"],"content":"vac:dst: §\n\nwakurtosis:waku: §\n\n techreport\n techreport_02\ntechreport_03\n wakurtosis:features\ngossipsub-topology-analysis\n\nwakurtosis:nomos: §\n\n ci-integration\n\nwakurtosis:vac: §\n\nrlog\nretrospective-rlog\n maintenance\n\nanalysis:nomos §\n\nsimulation-analysis\n\nanalysis-gsub-model:vac §\n\nrefactoring\n\nanalysis-gsub-model:status: §\n\ncontrol-messages\n\nanalysis-shadow:vac: §\n\nshadow-basic-simulation\nshadow-gossipsub-analysis\n\nanalysis-shadow:waku: §\n\nshadow-waku-relay-analysis\n\ndr-support: §\n\ncarnot-2-3rds-executable-spec\n\neng:vac: §\n\nbundle-simulation-data\n\neng-10ktool: §\n\nbandwidth-test\nQoS\nwaku-protocols\n\nsoftware-testing:waku: §\n\ntest-plans\ntest-automation-js-waku\ntest-automation-nwaku\ntest-automation-go-waku\ninterop-testing\n"},"vac/dst/software-testing/waku/interop-testing":{"title":"Interop Testing","links":[],"tags":[],"content":"vac:dst:software-testing:waku:interop-testing §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Interop Testing: 2023-09-01, 2024-02-29\n\n\nstatus: 0%\nCC: Florin, Alex, Roman\n\nDescription §\n\nfilter nwaku service node + js waku client node (t, Florin)\nnwaku <> go-waku interop (t, Alex)\n\nJustification §\nDeliverables §"},"vac/dst/software-testing/waku/test-automation-go-waku":{"title":"Test Automation go-waku","links":[],"tags":[],"content":"vac:dst:software-testing:waku:test-automation-go-waku §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Test Automation go-waku: 2023-10-01, 2024-02-29\n\n\nstatus: 0%\nCC: Roman\n\nDescription §\n\nfilter (t) ← first group of tests added in PR to JS waku\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\n\nJustification §\nDeliverables §"},"vac/dst/software-testing/waku/test-automation-js-waku":{"title":"Test Automation js-waku","links":[],"tags":[],"content":"vac:dst:software-testing:waku:test-automation-js-waku §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Test Automation js-waku: 2023-09-15, 2024-02-29\n\n\nstatus: 10%\nCC: Florin\n\nDescription §\n\nfilter (t) ← first group of tests added in PR to JS waku\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\nInteroperability (t)\n\nAdditional requirements:\nIt should be possible to choose the nwaku version the js waku test use (done via github actions inputs)\nJustification §\nDeliverables §"},"vac/dst/software-testing/waku/test-automation-nwaku":{"title":"Test Automation nwaku","links":[],"tags":[],"content":"vac:dst:software-testing:waku:test-automation-nwaku §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Test Automation nwaku: 2023-09-15, 2024-02-29\n\n\nstatus: 0%\nCC: Alex\n\nDescription §\nJustification §\nDeliverables §"},"vac/dst/software-testing/waku/test-plans":{"title":"Test Plans","links":[],"tags":[],"content":"vac:dst:software-testing:waku:test-plans §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Test Plans: 2023-09-01, 2024-02-29\n\n\nstatus: 15%\nCC: Florin\n\nDescription §\nunit + integration test\n(contains actually understanding the protocols, critically engage with the protocols)\n(instruct the engineer)\n\nfilter (t)\nlightpush (t)\nstore (t)\nrelay ()\npeer exchange\ndiscv5\npeer & connection management\ninteroperability (t, starting)\nsimulation plans\n\nJustification §\nDeliverables §\n\ntest plans\n"},"vac/dst/wakurtosis/nomos/ci-integration":{"title":"CI Integration","links":[],"tags":[],"content":"vac:dst:wakurtosis:nomos:ci-integration §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n CI Integration: done, 2023-07-01, 2023-07-31\n\n\nstatus: 100%\nCC: Alberto\n\nDescription §\nAdd Nomos integration to wakurtosis so Nomos can be also used in it.\nJustification §\nNomos is under constant developmet.\nWith this integration, each time a change is done, a continuous integration test is done, making sure the consensus protocol works properly with a few nodes.\nInfo §\nWe stopped working on a follow up milestone since we deprecated Wakurtosis in favour of our new 10ktool.\nDeliverables §\n\nfirst version of Nomos CI integration (https://github.com/vacp2p/wakurtosis/pull/141)\n"},"vac/dst/wakurtosis/vac/maintenance":{"title":"Wakurtosis Maintenance","links":[],"tags":[],"content":"vac:dst:wakurtosis:vac:maintenance §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Wakurtosis Maintenance: done, 2023-01-01, 2023-08-31\n\n\nstatus: 100%\nCC: Alberto\n\nDescription §\nKeep up to date the tool if there are crashing changes in the services that are being used in it (Waku, Nomos…)\nJustification §\nServices being used are in constant change, thus it can lead wakurtosis to break.\nInfo §\n\nWakurtosis is deprecated. We do not actively maintain it anymore.\n\nDeliverables §"},"vac/dst/wakurtosis/vac/retrospective-rlog":{"title":"Rlog: Wakurtosis Retrospective","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:retrospective-rlog §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Wakurtosis Retrospective: 2023-08-01, 2023-09-30\n\n\nstatus: 50%\nCC: Jordi\n\nDescription §\nResearch log discussing what would we have needed from Wakurtosis to make it work for us beyond our smaller solution.\nWhy did we decide to drop Kurtosis and work towards a Kubernetes-based solution now.\nJustification §\nInfo §\n\nAlberto’s Opinion\n\nDeliverables §"},"vac/dst/wakurtosis/vac/rlog":{"title":"Wakurtosis Rlog","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:rlog §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Rlog Wakurtosis: 2023-06-01, 2023-08-31\n\n\nstatus: 90%\nCC: Jordi\n\nDescription §\nResearch log post based on the Wakurtosis tech reports and addendum.\nJustification §\nInfo §\n\ndelayed because of holidays / other prios\n\nDeliverables §"},"vac/dst/wakurtosis/waku/features":{"title":"Wakurtosis Features","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:wakurtosis-features §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Wakurtosis Features: done, 2023-04-01, 2023-07-31\n\n\nstatus: 100%\nCC: Alberto\n\nDescription §\n\nFeatures requested by Waku for the simulations done in wakurtosis (e.g. discv5 support).\n\nJustification §\n\nDiscv5 is an important protocol to test. Also, we should be able to work with offline data once the simulation is finished.\n\nDeliverables §"},"vac/dst/wakurtosis/waku/gossipsub-topology-analysis":{"title":"Gossipsub Topology Analysis","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:gossipsub-topology-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Gossipsub Topology Analysis: 2023-07-01, 2023-10-15\n\n\nstatus: 60%\nCC: Ganesh\n\nDescription §\nAnalysis of the topology of a gossipsub topic mesh.\nComprises:\n\nresearch log post\nshadow integration\nLogos research call talk; also get input during the discussion regarding which areas we should go deeper into, and what would help Logos projects the most.\n\nInfo §\nExtended deadline because:\n\nadded research log post to the milestone goals + more analysis goals (e.g stability/dynamics)\nadded analysing simple gossipsub node (in addition to Waku relay)\n\nRelevant data has to be collected on the gossipsub-layer which increased the complexity of this milestone\n\n\nshadow integration\nmore focus on nomos simulation analysis + extended analysis\n\nNote: This analysis module will be usable outside of Wakurtosis, too.\nThis is the reason we continue on this milestone, even though Wakurtosis is deprecated now.\nJustification §\nDeliverables §"},"vac/dst/wakurtosis/waku/techreport":{"title":"Techreport","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:techreport §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Techreport: done, 2023-06-01, 2023-07-31\n\n\nstatus: 100%\nCC: Jordi\n\nDescription §\nJustification §\nDeliverables §\n\ntechreport\n"},"vac/dst/wakurtosis/waku/techreport_02":{"title":"Techreport_02","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:techreport_02 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Techreport_02: done, 2023-08-01, 2023-08-31\n\n\nstatus: 100%\nCC: Jordi\n\nDescription §\nRun extra batches of simulations of the non-Discv5 case with average degree K=13, and K=50.\nJustification §\nTo be able to better compare non-Discv5 and Discv5 Waku behaviours, the Waku team asked us to run new simulation batches with maximum fanout.\nCurrent simulation batches are hard to compare due to the dynamic nature of network generated by the Discv5 protocol.\nDeliverables §\n\ntechreport addendum\n"},"vac/dst/wakurtosis/waku/techreport_03":{"title":"Techreport_03","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:techreport_03 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Techreport_02: done, 2023-09-01, 2023-09-30\n\n\nstatus: 70%\nCC: Jordi\n\nDescription §\nAdd runs with 0msg/s to isolate the effect of discv5.\nJustification §\nDeliverables §\n\ntechreport addendum\n"},"vac/index":{"title":"Vac Roadmap","links":["vac/p2p/","vac/tke/","vac/dst/","vac/acz/","vac/sc/","vac/dr/","vac/rfc/","vac/nes/","tags/vac-updates"],"tags":[],"content":"vac §\nStructure §\nvac:<unit>:<tag>:<for_project>:<title>_<counter>\n\nvac indicates it is a vac milestone\nunit indicates the vac unit p2p, dst, tke, acz, sc, zkvm, dr, rfc\ntag tags a specific area / project / epic within the respective vac unit, e.g. nimlibp2p, or zerokit\nfor_project indicates which Logos project the milestone is mainly for nomos, waku, codex, nimbus, status; or vac (meaning it is internal / helping all projects as a base layer)\ntitle the title of the milestone\ncounter an optional counter; 01 is implicit; marked with a 02 onward indicates extensions of previous milestones\n\nVac Unit Roadmaps §\nR&D Service Units §\n\np2p: Peer-to-peer\ntke: Token Engineering\ndst: Distributed Systems Testing\nacz: Applied Cryptography and Zero-knowledge\nsc: Smart Contracts\n\nVac Core §\n\ndr: Deep Research\nrfc: RFC Process and Maintenance\n\nIncubator Projects §\n\nnes: Nescience\n\nWeekly Updates §\n\nweekly updates\n"},"vac/nes/index":{"title":"Nescience Incubation Project","links":["vac/nes/state-separation/vac/state-separation-doc","vac/nes/proofsystems/vac/research-existing-proofsystems","vac/nes/proofsystems/vac/benchmarks"],"tags":["zkvm","vac"],"content":"vac:nes:state-separation §\n\nstate-separation-doc\n\nvac:nes:proofsystems §\n\nresearch-existing-proofsystems\nbenchmarks\n"},"vac/nes/proofsystems/vac/benchmarks":{"title":"Benchmarks","links":[],"tags":[],"content":"vac:zkvm:proofsystems:vac:benchmarks §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Benchmarks: 2023-03-01, 2023-11-30\n\n\nstatus: 70%\nCC: team\n\nDescription §\nComprises:\n\nresearch log post\nmake benchmark repo public + README (explaining how to execute benchmarks)\nbenchmarks (recursive) for all current proof-systems (unless there is a good reason not to include one)\nscientific paper\n\nDeliverables §"},"vac/nes/proofsystems/vac/research-existing-proofsystems":{"title":"Research Existing Proofsystems","links":[],"tags":[],"content":"vac:zkvm:proofsystems:vac:research-existing-proofsystems §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Research Existing Proofsystems: 2023-01-01, 2023-11-30\n\n\nstatus: 70%\nCC: team\n\nDescription §\nDeliverables §"},"vac/nes/state-separation/vac/state-separation-doc":{"title":"State Separation Doc","links":[],"tags":[],"content":"vac:zkvm:state-separation:vac:state-separation-doc §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n State Separation: 2023-09-20, 2023-10-31\n\n\nstatus: 50%\nCC: Moudy\n\nDescription §\nDocument explaining and providing reason for Nescience state separation.\nJustification §\nDeliverables §"},"vac/p2p/index":{"title":"P2P Service Unit","links":["vac/p2p/nimlibp2p/vac/gossipsub-improvements-eip-4844","vac/p2p/nimlibp2p/vac/webrtc-transport","vac/p2p/nimlibp2p/vac/gossipsub-ddos-mitigation","vac/p2p/nimlibp2p/vac/gossipsub-stagger-send","vac/p2p/nimlibp2p/vac/maintenance","vac/p2p/nimchronos/vac/maintenance"],"tags":["p2p","vac"],"content":"vac:p2p: §\n\nnimlibp2p:vac: §\nThe P2P Service unit develops nim-libp2p.\nnim-libp2p roadmap on github: https://github.com/status-im/nim-libp2p/issues/777\n\n gossipsub-improvements-eip-4844\nwebrtc-transport\ngossipsub-ddos-mitigation\ngossipsub-stagger-send\nmaintenance\n\nnimchronos:vac: §\n\nmaintenance\n"},"vac/p2p/nimchronos/vac/maintenance":{"title":"Libchronos Maintenance","links":[],"tags":[],"content":"vac:p2p:nimchronos:vac:maintenance §\n\n\nstatus: ongoing\nCC: p2p team\n\nDescription §\n\nrepo: https://github.com/status-im/nim-chronos\n"},"vac/p2p/nimlibp2p/vac/gossipsub-ddos-mitigation":{"title":"Gossipsub DDoS Mitigation","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:gossipsub-ddos-mitigation §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n Gossipsub DDoS mitigation: 2023-07-01, 2023-10-31\n\n\nstatus: 30%\nCC: Diego\n\nDescription §\nDeliverables §"},"vac/p2p/nimlibp2p/vac/gossipsub-improvements-eip-4844":{"title":"Gossipsub Improvements EIP 4844","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:gossipsub-improvements-eip-4844 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n Gossipsub Improvements EIP 4844: done, 2023-03-01, 2023-07-31\n\n\nstatus: 100%\nCC: Tanguy\n\nDescription §\nDeliverables §"},"vac/p2p/nimlibp2p/vac/gossipsub-stagger-send":{"title":"Gossipsub Stagger Send","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:gossipsub-stagger-send §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n Gossipsub Stagger Send: 2023-06-01, 2023-10-31\n\n\nstatus: 20%\nCC: Tanguy\n\nDescription §\n\nspecification\nfirst implementation (not deployable yet, deploy version will be in a separate milestone after syncing with other implementations)\n\nDeliverables §"},"vac/p2p/nimlibp2p/vac/maintenance":{"title":"Libp2p Maintenance","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:maintenance §\n\n\nstatus: ongoing\nCC: p2p team\n\nDescription §\n\nrepo: https://github.com/status-im/nim-libp2p\n"},"vac/p2p/nimlibp2p/vac/webrtc-transport":{"title":"WebRTC Transport","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:webrtc-transport §\n\n%%{\n init: {\n 'theme': 'base',\n 'themeVariables': {\n 'primaryColor': '#BB2528',\n 'primaryTextColor': '#fff',\n 'primaryBorderColor': '#7C0000',\n 'lineColor': '#F8B229',\n 'secondaryColor': '#006100',\n 'tertiaryColor': '#fff',\n }\n }\n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n WebRTC Transport: 2023-04-01, 2023-07-31\n\n\nstatus: 70%\nCC: Diego\n\nDescription §\nDeliverables §"},"vac/rfc/index":{"title":"RFC Specifications Service Unit","links":["vac/rfc/rfc/status/port-status-specs","vac/rfc/rfc/nomos/carnot-specification","vac/rfc/rfc/nomos/carnot-threat-model-informational","vac/rfc/rfc/nomos/carnot-vote-2-3rds-vote-aggregation-specification","vac/rfc/rfc/nomos/inter-chain-protocol-specification","vac/rfc/rfc/nomos/multi-leader-and-multi-overlay-carnot-specification","vac/rfc/rfc/waku/waku-keystore"],"tags":["rfc","vac"],"content":"vac:rfc: §\n\nrfc:status: §\n\nport-status-specs\n\nrfc:nomos: §\n\ncarnot-specification\ncarnot-threat-model-informational\ncarnot-vote-2-3rds-vote-aggregation-specification\ninter-chain-protocol-specification\nmulti-leader-and-multi-overlay-carnot-specification\n\nrfc:waku: §\n\nwaku-keystore\n"},"vac/rfc/rfc/nomos/carnot-specification":{"title":"carnot-specification","links":[],"tags":[],"content":""},"vac/rfc/rfc/nomos/carnot-threat-model-informational":{"title":"carnot-threat-model-informational","links":[],"tags":[],"content":""},"vac/rfc/rfc/nomos/carnot-vote-2-3rds-vote-aggregation-specification":{"title":"carnot-vote-2-3rds-vote-aggregation-specification","links":["vac/rfc/rfc/nomos/carnot-vote-2-3rds-vote-aggregation-specification"],"tags":[],"content":"\npart of the DR roadmap: carnot-vote-2-3rds-vote-aggregation-specification\n"},"vac/rfc/rfc/nomos/inter-chain-protocol-specification":{"title":"inter-chain-protocol-specification","links":[],"tags":[],"content":""},"vac/rfc/rfc/nomos/multi-leader-and-multi-overlay-carnot-specification":{"title":"multi-leader-and-multi-overlay-carnot-specification","links":[],"tags":[],"content":""},"vac/rfc/rfc/status/port-status-specs":{"title":"Port Status Specs","links":[],"tags":[],"content":"vac:rfc:rfc:status:port-status-specs §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Port Status Spec: 2023-08-01, 2023-11-31\n\n\nstatus: 85%\nCC: Jimmy\n\nDescription §\nThis milestone comprises the first version of each of the specifications. Iterations on spec parlance and further enhancements will be covered in future milestones.\nThe goal we want to aim for is to take down and completely get rid of https://specs.status.im/ and its accompanying repo https://github.com/status-im/specs , so that all Status protocol specs are in the https://github.com/vacp2p/rfc repo\nTasks:\n\ndetermine which specs from https://specs.status.im/ are still relevant as protocol specs, and which old specs are no longer relevant and can be discarded\nout of the still relevant protocol specs that haven’t yet been moved over to the Vac RFC repo, update these specs as needed and move them into the Vac RFC repo\nonce done, take down https://specs.status.im/ and archive the https://github.com/vacp2p/rfc repo\n\nThe new Status website will have a ‘Specs’ section inside the ‘Developers’ part of the website, and this Specs section will pull in and render all specs from https://rfc.vac.dev/ with “STATUS-” in their title.\nNote that feature specs should NOT be added to the Vac RFC repo, only protocol specs should go here.\nRFCs to be moved / updates:\n\n(todo add RFCs we already ported)\n 6/PAYLOADS (needs significant update)\n 2/ACCOUNT\n 16/Keycard (discuss with keycard team)\n16/Push-Notifications (raw, needs update)\n10/waku-usage (outdated, check if we need that, update to Waku 2 if makes sense)\n\nout of scope? §\n\n14/Dapp browser API usage (this is not part of chat SDK, is this still a RFC? API doc would be more fitting here.)\n13/3RD-PARTY (investigate, most likely out-of-scope as it is not a protocol spec)\n8/EIPS (clarify if we have to port this → this should not be an RFC, needs constant updates, link EIPS in RFCs where needed)\n\nstable - deprecated §\n(just copy these; confirm this is OK)\n\n4/whisper-mailserver\n11/Waku-Mailserver\n\nJustification §\nDeliverables §\n\nhttps://rfc.vac.dev/spec/53/\nhttps://rfc.vac.dev/spec/54/\nhttps://rfc.vac.dev/spec/55/\nhttps://rfc.vac.dev/spec/56/\nhttps://rfc.vac.dev/spec/61/\nhttps://rfc.vac.dev/spec/63/\n"},"vac/rfc/rfc/waku/waku-keystore":{"title":"Waku Keystore","links":[],"tags":[],"content":"vac:rfc:rfc:waku:waku-keystore §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Waku Keystore RFC: 2023-11-01, 2023-11-31\n\n\nstatus: 0%\nCC: Jimmy\n\nDescription §\nWaku keystore offers a secure way to store RLN credentials,\nwhich consist of the user’s identityCredential,\nthe identityIndex (the index of their commitment in the tree),\nand the membershipContract (the contract to which this credential is registered).\nWe follow EIP-2335 closely, with some changes that are more evident from the code.\n\nnwaku implementation of keystore - https://github.com/waku-org/nwaku/tree/master/waku/waku_keystore\ngo-waku implementation of keystore - https://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/rln/keystore/keystore.go\njs-waku implementation of keystore - https://github.com/waku-org/js-rln/tree/master/src/keystore\nSample keystore - https://github.com/waku-org/js-rln/blob/891ee3474aa97e8fe5ac1b35b7ed7387f395a537/src/keystore/keystore.spec.ts#L16-L95\n\nThe RFC should describe the credential encryption format, the supported kdf’s, as well as a sample keystore.\nJustification §\nDeliverables §\n\nRFC\n"},"vac/sc/g/codex/review-codex-contracts":{"title":"Review Codex Contracts","links":[],"tags":[],"content":"vac:sc::codex:review-codex-contracts §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Review Codex Contracts: 2023-09-15, 2023-10-31\n\n\nstatus: 0%\nCC: r4bbit\n\nDescription §\nReview the codex smartcontract and give feedback: https://github.com/codex-storage/codex-contracts-eth\nMore info: https://github.com/codex-storage/nim-codex/blob/master/codex/contracts/Readme.md\nJustification §\nDeliverables §"},"vac/sc/g/status/community-contracts-ERC20":{"title":"Community Contracts ERC20","links":[],"tags":[],"content":"vac:sc:rlnp2p:status:community-contracts-erc20 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n Community Contracts ERC20: 2023-08-01, 2023-11-31\n\n\nstatus: 100%\nCC: Andrea\n\nDescription §\n\nhttps://github.com/status-im/communities-contracts/issues/13\n\nInfo §\nThis milestone comprises what the SC has to deliver towards the completion of Status No3 prio:\n3) work on the Status Community ownership tokenisation smart contracts is the third priority\nJustification §\nDeliverables §"},"vac/sc/g/status/community-contracts-ERC721":{"title":"Community Contracts ERC721","links":[],"tags":[],"content":"vac:sc::status:community-contracts-erc721 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Community Contracts ERC721: done, 2023-01-20, 2023-08-31\n\n\nstatus: 100%\nCC: Andrea\n\nDescription §\nJustification §\nDeliverables §"},"vac/sc/g/status/community-contracts-deployer":{"title":"Community Contracts Deployer","links":[],"tags":[],"content":"vac:sc::status:community-contracts-deployer §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Community Contracts Deployer: 2023-09-01, 2023-09-30\n\n\nstatus: 100%\nCC: r4bbit\n\nDescription §\nJustification §\nDeliverables §\n\n\nhttps://github.com/status-im/communities-contracts/commit/e7d799b761e87166ecee4efaaede0b7a6cc367ad\n\n\nhttps://goerli-optimism.etherscan.io/address/0xfFa8A255D905c909379859eA45B959D090DDC2d4\n\n\nTest-net addresses:\nCommunityTokenDeployer 0xfFa8A255D905c909379859eA45B959D090DDC2d4\nCommunityOwnerTokenRegistry 0x99F0Eeb7E9F1Da6CA9DDf77dD7810B665FD85750\nCommunityOwnerTokenFactory 0x76d0E484e7c3398922636960Ab33bDe6E9936D81\nCommunityMasterTokenFactory 0x420BE6568c6E09782CEAE1575495Cd6C1c7EA04D\n"},"vac/sc/g/status/community-contracts-maintenance":{"title":"Community Contracts Maintenance","links":[],"tags":[],"content":"vac:sc::status:community-contracts-maintenance §\n\n\nstatus: ongoing\nCC: Andrea\n\nDescription §\nJustification §\nDeliverables §"},"vac/sc/g/status/community-contracts-token-import":{"title":"Token Import","links":[],"tags":[],"content":":sc:g:status:token-import §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Production Readiness:\n\n\nstatus: 5%\nCC: Andrea\n\nDescription §\nNote: This milestones needs further details, which will be agreed apon with Status in an upcoming meeting.\nPreliminary description:\nDesign and implement a contract that offers a token import functionality to communities.\nIt should allow:\n\ndeploying a token vault for a given token\ndepositing tokens to specific token vaults\nspecific community members (token masters) can alter (e.g. airdrop) tokens in the store\ntokens in the vault can be air dropped\n\nA token vault is basically a community wallet that a community’s token masters can airdrop from.\nJustification §\nDeliverables §\n\ndesign description\nsmart contract\n"},"vac/sc/g/status/community-curation-contracts":{"title":"Community Curation dapp Contracts","links":["vac/sc/g/status/snt-optimism-bridge"],"tags":[],"content":"vac:sc::status:community-curation-dapp-contracts §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Production Readiness: 2023-09-15, 2023-10-21\n\n\nstatus: 95%\nCC: Ricardo\n\nDescription §\nDepends on finishing SNT-optimism-bridge\nThe milestone has to be completed (can be a mitigation / preliminary fix):\n\nhttps://github.com/status-im/community-dapp/issues/64\nhttps://github.com/status-im/community-dapp/issues/65\n\nInfo §\nThis milestone comprises what the SC has to deliver towards the completion of Status No2 prio:\n2) if any further work needs to be done on the Community Directory Curation dApp for the initial launch this is second priority\nJustification §\nDeliverables §"},"vac/sc/g/status/governance-contract-mvp":{"title":"Governance Contract MVP","links":[],"tags":[],"content":"vac:sc::status:governance-contract-mvp §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Governance Contract MVP: 2023-08-01, 2023-09-30\n\n\nstatus: 20%\nCC: Ricardo\n\nDescription §\n\nvoting within communities\nreplace the current community-dapp voting contracts https://github.com/status-im/community-dapp/tree/master/packages/contracts/contracts\ntesting is out of scope for that milestone\n\nJustification §\nDeliverables §"},"vac/sc/g/status/mimime-token-enhancement":{"title":"MimiMe Token Enhancements","links":[],"tags":[],"content":"vac:sc::status:minime-token-enhancement §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n SNT Optimism Bridge:\n\n\nstatus: 20%\nCC: Ricardo\n\nDescription §\nThis is future work. Not pressing atm.\n\nhttps://github.com/vacp2p/minime/issues/6\n\nlow hanging fruit regarding gas savings\nwill setup a follow up milestone for further improvements\n\n\n\nJustification §\nDeliverables §"},"vac/sc/g/status/mimime-token-maintenance":{"title":"MimiMe Token Maintenance","links":[],"tags":[],"content":"vac:sc::status:minime-token-maintenance §\n\n\nstatus: ongoing\nCC: Ricardo\n\nDescription §\nJustification §\nDeliverables §"},"vac/sc/g/status/snt-optimism-bridge":{"title":"SNT Optimism Bridge","links":["vac/sc/g/status/mimime-token-enhancement"],"tags":[],"content":"vac:sc::status:snt-optimism-bridge §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n SNT Optimism Bridge: 2023-09-01, 2023-09-30\n\n\nstatus: 100%\nCC: Ricardo\n\nDescription §\nThis milestone comprises issues that have to be completed to bridge SNT to Optimism.\nThese issues are part of enhancing the MimiMe token.\n\nhttps://github.com/vacp2p/minime/issues/19\nhttps://github.com/vacp2p/minime/issues/17\nhttps://github.com/vacp2p/minime/issues/7\nhttps://github.com/vacp2p/minime/issues/5\nhttps://github.com/vacp2p/minime/issues/31\n\nFollowing enhancments to the MimiMe token (future work) are tracked in:\nmimime-token-enhancement\nThis milestone also contains:\n\na listing of issues identified in the 1st Certora audit, which we addressed\na listing of issues that are now out of scope because we forked the MimiMe repo, and removed parts we do not need\nCertora checking\n\nInfo §\nThis milestone comprises what the SC has to deliver towards the completion of Status No1 prio:\nthe SNT contract for deployment on Optimism is top priority\nNote: This milestone includes deployment on Goerli and “manual” testing.\nIntegration tests for this milestone is out of scope for this milestone.\nIf integration tests are desired, we would track and address this in a future milestone.\nJustification §\nDeliverables §"},"vac/sc/g/status/staking-contract-maintenance":{"title":"Status Staking Contract Maintenance Details","links":[],"tags":[],"content":"%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tStaking contract maintenance :, 2023-01-20, 2023-08-31\n\n\ndue date: 2023/08/31\nstatus: 100%\n\nDescription §\nStatus staking contract MVP maintenance\nDeliverable §\nTBD"},"vac/sc/g/status/staking-contract-mvp":{"title":"Status Staking Contract MVP","links":[],"tags":[],"content":"vac:sc::status:staking-contract-mvp §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tStaking Contract :, 2023-01-20, 2023-08-31\n\n\ndue date:\nstatus: 100%\n\nDescription §\nMVP for the Status staking contract\nDeliverable §\nTBD"},"vac/sc/g/status/staking-contract":{"title":"Status Staking Contract","links":["vac/sc/g/status/staking-contract"],"tags":[],"content":"vac:sc::status:staking-contract §\nG\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Status Staking Contract: 2023-09-01, 2023-10-31\n\n\nstatus: 10%\nCC: Ricardo\n\nDescription §\nThis milestone comprises a set of improvements on and extensions to the current state of the staking contract staking-contract.\nDetails can be found here: https://www.notion.so/Implementing-SNT-Staking-Contract-Issues-Differences-2de74e7c19124e78b1c9490300a84422\nThis document is the basis for the following issues:\n\nhttps://github.com/logos-co/staking/issues/9\nhttps://github.com/logos-co/staking/issues/10\nhttps://github.com/logos-co/staking/issues/11\nhttps://github.com/logos-co/staking/issues/12\nhttps://github.com/logos-co/staking/issues/13\nhttps://github.com/logos-co/staking/issues/14\nhttps://github.com/logos-co/staking/issues/15\nhttps://github.com/logos-co/staking/issues/16\nhttps://github.com/logos-co/staking/issues/17\nhttps://github.com/logos-co/staking/issues/18\n\nThe milestone is achieved when these issues have been resolved.\nJustification §\nDeliverables §"},"vac/sc/g/vac/rln-contract-support":{"title":"Vac RLN Contract Support Details","links":[],"tags":[],"content":"%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Vac\n\t\tRLN Contract Support :, 2023-01-20, 2023-09-15\n\n\ndue date: 2023/09/15\nstatus: 10%\n\nDescription §\nKick-off task for the Vac SC Unit"},"vac/sc/g/vac/secureum-upskilling":{"title":"Secureum Upskilling","links":[],"tags":[],"content":"vac:sc::vac:secureum-upskilling §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Secureum Upskilling: 2023-08-15, 2023-10-15\n\n\nstatus: 70%\nCC: team\n\nDescription §\nJustification §\nDeliverables §"},"vac/sc/index":{"title":"Smart Contracts Service Unit","links":["vac/sc/g/status/community-contracts-ERC721","vac/sc/g/status/community-contracts-ERC20","vac/sc/g/status/community-contracts-deployer","vac/sc/g/status/community-contracts-token-import","vac/sc/g/status/community-contracts-maintenance","vac/sc/g/status/community-curation-contracts","vac/sc/g/status/snt-optimism-bridge","vac/sc/g/status/mimime-token-enhancement","vac/sc/g/status/mimime-token-maintenance","vac/sc/g/status/governance-contract-mvp","vac/sc/g/status/staking-contract-mvp","vac/sc/g/status/staking-contract","vac/sc/g/status/staking-contract-maintenance","vac/sc/g/codex/review-codex-contracts","vac/sc/g/vac/secureum-upskilling","vac/sc/g/vac/rln-contract-support"],"tags":["sc","vac"],"content":"vac:sc:: §\n\nstatus: §\n\n community-contracts-ERC721\n community-contracts-ERC20\n community-contracts-deployer\ncommunity-contracts-token-import\ncommunity-contracts-maintenance\ncommunity-curation-contracts\n SNT-optimism-bridge\nmimime-token-enhancement\nmimime-token-maintenance\ngovernance-contract-mvp\n staking-contract-mvp\nstaking-contract\nstaking-contract-maintenance\n\ncodex: §\n\nreview-codex-contracts\n\nvac: §\n\nsecureum-upskilling\nrln-contract-support\n"},"vac/tke/g/codex/economic-analysis":{"title":"Codex Economic Analysis","links":[],"tags":[],"content":"vac:tke::codex:economic-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD\n\tsection Codex\n\t\tEconomic Analysis :, 2023-01-20, 2023-08-30\n\n\nstatus: 50%\nCC: Matty\n\nDescription §\nCodex economic analysis, Codex token utility, Codex collateral management\nJustification §\nPer Dimitry and Jesse, required by Codex team for completing implementation of system and planning launch"},"vac/tke/g/nomos/economic-analysis":{"title":"Nomos Economic Analysis","links":[],"tags":[],"content":"vac:tke::nomos:economic-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Nomos\n\t\tEconomic Analysis :, 2023-05-01, 2023-10-31\n\n\nstatus: 30%\nCC: Frederico\n\nDescription §\nNomos economic analysis, Nomos token utility, requirements and constraints\nJustification §\nRequired for ensuring economic security and censorship resistance of Nomos chain"},"vac/tke/g/status/snt-governance-proposal":{"title":"SNT Governance Proposal","links":[],"tags":[],"content":"vac:tke::status:SNT-governance-proposal §\n\ndue: TDB\nstatus: TDB\nCC: Matty\nDescription §\n\ntook precedence over SNT litepaper\nfirst draft being prepared for next review with John on 2023/09/12\n\nJustification §\n\nPer John’s request, high importance for involving community for relaunch of Status app and refresh of SNT token\n"},"vac/tke/g/status/snt-litepaper":{"title":"SNT Litepaper","links":[],"tags":[],"content":"vac:tke::status:SNT-litepaper §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tSNT Litepaper: 2023-01-20, 2023-08-30\n\n\nstatus: 70% - delayed: governance proposal taking precedence\nCC: Matty\n\nDescription §\n\ndelayed, other milestones took precedence\nPer confirmation with John on 2023/08/22 litepaper is not a pressing need, much lower priority than governance proposal\n\nJustification §\n\nhelpful to support relaunch of Status app and describe SNT’s new staking features\n"},"vac/tke/g/status/snt-staking":{"title":"SNT Staking","links":["vac/sc/"],"tags":[],"content":"vac:tke::status:SNT-staking §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tSNT Staking :, 2023-01-20, 2023-08-30\n\n\nstatus: 82%\nCC: Frederico (Python), Martin\ncollab: smart contracts team\n\nDescription: §\nRisks §\n\nimplementation of the smart contract is being handed off to smart contract team\n"},"vac/tke/g/waku/economic-analysis":{"title":"Waku Economic Analysis","links":[],"tags":[],"content":"vac:tke::waku:economic-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Waku\n\t\tEconomic Analysis :, 2023-06-01, 2023-11-30\n\n\nstatus: 10%\nCC: Martin\n\nDescription §\nWaku economic analysis"},"vac/tke/index":{"title":"Token Engineering Service Unit","links":["vac/tke/g/status/snt-litepaper","vac/tke/g/status/snt-governance-proposal","vac/tke/g/status/snt-staking","vac/tke/g/codex/economic-analysis","vac/tke/g/nomos/economic-analysis","vac/tke/g/waku/economic-analysis"],"tags":["p2p","vac"],"content":"vac:tke:: §\n\nstatus: §\n\nsnt-lightpaper\nSNT-governance-proposal\nSNT-staking\n\ncodex: §\n\neconomic-analysis\n\nnomos: §\n\neconomic-analysis\n\nwaku: §\n\neconomic-analysis\n"},"vac/updates/2023-07-10":{"title":"2023-07-10 Vac Weekly","links":[],"tags":["vac-updates"],"content":"\nvc::Deep Research\n\nrefined deep research roadmaps https://github.com/vacp2p/research/issues/190, https://github.com/vacp2p/research/issues/192\nworking on comprehensive current/related work study on Validator Privacy\nworking on PoC of Tor push in Nimbus\nworking towards comprehensive current/related work study on gossipsub scaling\n\n\nvsu::P2P\n\nPrepared Paris talks\nImplemented perf protocol to compare the performances with other libp2ps https://github.com/status-im/nim-libp2p/pull/925\n\n\nvsu::Tokenomics\n\nFixing bugs on the SNT staking contract;\nDefinition of the first formal verification tests for the SNT staking contract;\nSlides for the Paris off-site\n\n\nvsu::Distributed Systems Testing\n\nReplicated message rate issue (still on it)\nFirst mockup of offline data\nNomos consensus test working\n\n\nvip::zkVM\n\nhiring\nonboarding new researcher\npresentation on ECC during Logos Research Call (incl. preparation)\nmore research on nova, considering additional options\nIdentified 3 research questions to be taken into consideration for the ZKVM and the publication\nResearched Poseidon implementation for Nova, Nova-Scotia, Circom\n\n\nvip::RLNP2P\n\nfinished rln contract for waku product - https://github.com/waku-org/rln-contract\nfixed homebrew issue that prevented zerokit from building - https://github.com/vacp2p/zerokit/commit/8a365f0c9e5c4a744f70c5dd4904ce8d8f926c34\nrln-relay: verify proofs based upon bandwidth usage - https://github.com/waku-org/nwaku/commit/3fe4522a7e9e48a3196c10973975d924269d872a\nRLN contract audit cont’ https://hackmd.io/@blockdev/B195lgIth\n\n\n"},"vac/updates/2023-07-17":{"title":"2023-07-17 Vac weekly","links":[],"tags":["vac-updates"],"content":"Last week\n\nvc\n\nVac day in Paris (13th)\n\n\nvc::Deep Research\n\nworking on comprehensive current/related work study on Validator Privacy\nworking on PoC of Tor push in Nimbus: setting up goerli nim-eth2 node\nworking towards comprehensive current/related work study on gossipsub scaling\n\n\nvsu::P2P\n\nParis offsite Paris (all CCs)\n\n\nvsu::Tokenomics\n\nBugs found and solved in the SNT staking contract\nattend events in Paris\n\n\nvsu::Distributed Systems Testing\n\nEvents in Paris\nQoS on all four infras\nContinue work on theoretical gossipsub analysis (varying regular graph sizes)\nPeer extraction using WLS (almost finished)\nDiscv5 testing\nWakurtosis CI improvements\nProvide offline data\n\n\nvip::zkVM\n\nonboarding new researcher\nPrepared and presented ZKVM work during VAC offsite\nDeep research on Nova vs Stark in terms of performance and related open questions\nresearching Sangria\nWorked on NEscience document (https://www.notion.so/Nescience-WIP-0645c738eb7a40869d5650ae1d5a4f4e)\nzerokit:\n\nworked on PR for arc-circom\n\n\n\n\nvip::RLNP2P\n\noffsite Paris\n\n\n\nThis week\n\nvc\nvc::Deep Research\n\nworking on comprehensive current/related work study on Validator Privacy\nworking on PoC of Tor push in Nimbus\nworking towards comprehensive current/related work study on gossipsub scaling\n\n\nvsu::P2P\n\nEthCC & Logos event Paris (all CCs)\n\n\nvsu::Tokenomics\n\nAttend EthCC and side events in Paris\nIntegrate staking contracts with radCAD model\nWork on a new approach for Codex collateral problem\n\n\nvsu::Distributed Systems Testing\n\nEvents in Paris\nFinish peer extraction, plot the peer connections; script/runs for the analysis, and add data to the Tech Report\nRestructure the Analysis script and start modelling Status control messages\nSplit Wakurtosis analysis module into separate repository (delayed)\nDeliver simulation results (incl fixing discv5 error with new Kurtosis version)\nSecond iteration Nomos CI\n\n\nvip::zkVM\n\nContinue researching on Nova open questions and Sangria\nDraft the benchmark document (by the end of the week)\nresearch hardware for benchmarks\nresearch Halo2 cont’\nzerokit:\n\nmerge a PR for deployment of arc-circom\ndeal with arc-circom master fail\n\n\n\n\nvip::RLNP2P\n\noffsite paris\n\n\nblockers\n\nvip::zkVM:zerokit: ark-circom deployment to crates io; contact to ark-circom team\n\n\n"},"vac/updates/2023-07-24":{"title":"2023-08-03 Vac weekly","links":[],"tags":["vac-updates"],"content":"NOTE: This is a first experimental version moving towards the new reporting structure:\nLast week\n\nvc\nvc::Deep Research\n\nmilestone (15%, 2023/11/30) paper on gossipsub improvements ready for submission\n\nrelated work section\n\n\nmilestone (15%, 2023/08/31) Nimbus Tor-push PoC\n\nbasic torpush encode/decode ( https://github.com/vacp2p/nim-libp2p-experimental/pull/1 )\n\n\nmilestone (15%, 2023/11/30) paper on Tor push validator privacy\n\n(focus on Tor-push PoC)\n\n\n\n\nvsu::P2P\n\nadmin/misc\n\nEthCC (all CCs)\n\n\n\n\nvsu::Tokenomics\n\nadmin/misc\n\nAttended EthCC and side events in Paris\n\n\nmilestone (30%, 2023/09/30) Codex economic analysis, Codex token utility, Codex collateral management\n\nKicked off a new approach for Codex collateral problem\n\n\nmilestone (50%, 2023/08/30) SNT staking smart contract\n\nIntegrated SNT staking contracts with Python\n\n\nmilestone (50%, 2023/07/14) SNT litepaper\n\n(delayed)\n\n\nmilestone(30%, 2023/09/29) Nomos Token: requirements and constraints\n\n\nvsu::Distributed Systems Testing\n\nmilestone (95%, 2023/07/31) Wakurtosis Waku Report\n\nAdd timout to injection async call in WLS to avoid further issues (PR #139 https://github.com/vacp2p/wakurtosis/pull/139)\nPlotting & analyse 100 msg/s off line Prometehus data\n\n\nmilestone (90%, 2023/07/31) Nomos CI testing\n\nfixed errors in Nomos consensus simulation\n\n\nmilestone (30%, …) gossipsub model analysis\n\nadd config options to script, allowing to load configs that can be directly compared to Wakurtosis results\nadded support for small world networks\n\n\nadmin/misc\n\nInterviews & reports for SE and STA positions\nEthCC (1 CC)\n\n\n\n\nvip::zkVM\n\nmilestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria…)\n\n(write ups will be available here: https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451)\nSolved the open questions on Nova adn completed the document (will update the page)\nReviewed Nescience and working on a document\nReviewed partly the write up on FHE\nwriteup for Nova and Sangria; research on super nova\nreading a new paper revisiting Nova (https://eprint.iacr.org/2023/969)\n\n\nmilestone (50%, 2023/08/31) new fair benchmarks + recursive implementations\nzkvm\n\nResearching Nova to understand the folding technique for ZKVM adaptation\n\n\nzerokit\n\nRostyslav became circom-compat maintainer\n\n\n\n\nvip::RLNP2P\n\nmilestone (100%, 2023/07/31) rln-relay testnet 3 completed and retro\n\ncompleted\n\n\nmilestone (95%, 2023/07/31) RLN-Relay Waku production readiness\nadmin/misc\n\nEthCC + offsite\n\n\n\n\n\nThis week\n\nvc\nvc::Deep Research\n\nmilestone (15%, 2023/11/30) paper on gossipsub improvements ready for submission\n\nworking on contributions section, based on https://hackmd.io/X1DoBHtYTtuGqYg0qK4zJw\n\n\nmilestone (15%, 2023/08/31) Nimbus Tor-push PoC\n\nworking on establishing a connection via nim-libp2p tor-transport\nsetting up goerli test node (cont’)\n\n\nmilestone (15%, 2023/11/30) paper on Tor push validator privacy\n\ncontinue working on paper\n\n\n\n\nvsu::P2P\n\nmilestone (…)\n\nImplement ChokeMessage for GossipSub\nContinue “limited flood publishing” (https://github.com/status-im/nim-libp2p/pull/911)\n\n\n\n\nvsu::Tokenomics\n\nadmin/misc:\n\n(3 CC days off)\nCatch up with EthCC talks that we couldn’t attend (schedule conflicts)\n\n\nmilestone (50%, 2023/07/14) SNT litepaper\n\nStart building the SNT agent-based simulation\n\n\n\n\nvsu::Distributed Systems Testing\n\nmilestone (100%, 2023/07/31) Wakurtosis Waku Report\n\nfinalize simulations\nfinalize report\n\n\nmilestone (100%, 2023/07/31) Nomos CI testing\n\nfinalize milestone\n\n\nmilestone (30%, …) gossipsub model analysis\n\nIncorporate Status control messages\n\n\nadmin/misc\n\nInterviews & reports for SE and STA positions\nEthCC (1 CC)\n\n\n\n\nvip::zkVM\n\nmilestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria…)\n\nRefine the Nescience WIP and FHE documents\nresearch HyperNova\n\n\nmilestone (50%, 2023/08/31) new fair benchmarks + recursive implementations\n\nContinue exploring Nova and other ZKPs and start technical writing on Nova benchmarks\n\n\nzkvm\nzerokit\n\ncircom: reach an agreement with other maintainers on master branch situation\n\n\n\n\nvip::RLNP2P\n\nmaintenance\n\ninvestigate why docker builds of nwaku are failing [zerokit dependency related]\ndocumentation on how to use rln for projects interested (https://discord.com/channels/864066763682218004/1131734908474236968/1131735766163267695)(https://ci.infra.status.im/job/nim-waku/job/manual/45/console)\n\n\nmilestone (95%, 2023/07/31) RLN-Relay Waku production readiness\n\nrevert rln bandwidth reduction based on offsite discussion, move to different validator\n\n\n\n\nblockers\n"},"vac/updates/2023-07-31":{"title":"2023-07-31 Vac weekly","links":[],"tags":["vac-updates"],"content":"\nvc::Deep Research\n\nmilestone (20%, 2023/11/30) paper on gossipsub improvements ready for submission\n\nproposed solution section\n\n\nmilestone (15%, 2023/08/31) Nimbus Tor-push PoC\n\nestablishing torswitch and testing code\n\n\nmilestone (15%, 2023/11/30) paper on Tor push validator privacy\naddressed feedback on current version of paper\n\n\nvsu::P2P\n\nnim-libp2p: (100%, 2023/07/31) GossipSub optimizations for ETH’s EIP-4844\n\nMerged IDontWant (https://github.com/status-im/nim-libp2p/pull/934) & Limit flood publishing (https://github.com/status-im/nim-libp2p/pull/911) 𝕏\nThis wraps up the “mandatory” optimizations for 4844. We will continue working on stagger sending and other optimizations\n\n\nnim-libp2p: (70%, 2023/07/31) WebRTC transport\n\n\nvsu::Tokenomics\n\nadmin/misc\n\n2 CCs off for the week\n\n\nmilestone (30%, 2023/09/30) Codex economic analysis, Codex token utility, Codex collateral management\nmilestone (50%, 2023/08/30) SNT staking smart contract\nmilestone (50%, 2023/07/14) SNT litepaper\nmilestone (30%, 2023/09/29) Nomos Token: requirements and constraints\n\n\nvsu::Distributed Systems Testing\n\nadmin/misc\n\nAnalysis module extracted from wakurtosis repo (https://github.com/vacp2p/wakurtosis/pull/142, https://github.com/vacp2p/DST-Analysis)\nhiring\n\n\nmilestone (99%, 2023/07/31) Wakurtosis Waku Report\n\nRe-run simulations\nmerge Discv5 PR (https://github.com/vacp2p/wakurtosis/pull/129).\nfinalize Wakurtosis Tech Report v2\n\n\nmilestone (100%, 2023/07/31) Nomos CI testing\n\ndelivered first version of Nomos CI integration (https://github.com/vacp2p/wakurtosis/pull/141)\n\n\nmilestone (30%, 2023/08/31 gossipsub model: Status control messages\n\nWaku model is updated to model topics/content-topics\n\n\n\n\nvip::zkVM\n\nmilestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria…)\n\nachievment :: nova questions answered (see document in Project: https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451)\nNescience WIP done (to be delivered next week, priority)\nFHE review (lower prio)\n\n\nmilestone (50%, 2023/08/31) new fair benchmarks + recursive implementations\n\nWorking on discoveries about other benchmarks done on plonky2, starky, and halo2\n\n\nzkvm\nzerokit\n\nfixed ark-circom master\nachievment :: publish ark-circom https://crates.io/crates/ark-circom\nachievment :: publish zerokit_utils https://crates.io/crates/zerokit_utils\nachievment :: publish rln https://crates.io/crates/rln (𝕏 jointly with RLNP2P)\n\n\n\n\nvip::RLNP2P\n\nmilestone (100%, 2023/07/31) RLN-Relay Waku production readiness\n\nUpdated rln-contract to be more modular - and downstreamed to waku fork of rln-contract - https://github.com/vacp2p/rln-contract and http://github.com/waku-org/waku-rln-contract\nDeployed to sepolia\nFixed rln enabled docker image building in nwaku - https://github.com/waku-org/nwaku/pull/1853\n\n\nzerokit:\n\nachievement :: zerokit v0.3.0 release done - https://github.com/vacp2p/zerokit/releases/tag/v0.3.0 (𝕏 jointly with zkVM)\n\n\n\n\n"},"vac/updates/2023-08-07":{"title":"2023-08-07 Vac weekly","links":[],"tags":["vac-updates"],"content":"More info on Vac Milestones, including due date and progress (currently working on this, some milestones do not have the new format yet, first version planned for this week):\nhttps://www.notion.so/Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac week 32 August 7th\n\nvsu::P2P\n\nvac:p2p:nim-libp2p:vac:maintenance\n\nImprove gossipsub DDoS resistance https://github.com/status-im/nim-libp2p/pull/920\n\n\nvac:p2p:nim-chronos:vac:maintenance\n\nRemove hard-coded ports from test https://github.com/status-im/nim-chronos/pull/429\nInvestigate flaky test using REUSE_PORT\n\n\n\n\nvsu::Tokenomics\n\n(…)\n\n\nvsu::Distributed Systems Testing\n\nvac:dst:wakurtosis:waku:techreport\n\ndelivered: Wakurtosis Tech Report v2 (https://docs.google.com/document/d/1U3bzlbk_Z3ZxN9tPAnORfYdPRWyskMuShXbdxCj4xOM/edit?usp=sharing)\n\n\nvac:dst:wakurtosis:vac:rlog\n\nworking on research log post on Waku Wakurtosis simulations\n\n\nvac:dst:gsub-model:status:control-messages\n\ndelivered: the analytical model can now handle Status messages; status analysis now has a separate cli and config; handles top 5 message types (by expected bandwidth consumption)\n\n\nvac:dst:gsub-model:vac:refactoring\n\nRefactoring and bug fixes\nintroduced and tested 2 new analytical models\n\n\nvac:dst:wakurtosis:waku:topology-analysis\n\ndelivered: extracted into separate module, independent of wls message\n\n\nvac:dst:wakurtosis:nomos:ci-integration_02\n\nplanning\n\n\nvac:dst:10ksim:vac:10ksim-bandwidth-test\n\nplanning; check usage of new codex simulator tool (https://github.com/codex-storage/cs-codex-dist-tests)\n\n\n\n\nvip::zkVM\n\nvac:zkvm::vac:research-existing-proof-systems\n\n90% Nescience WIP done – to be reviewed carefully since no other follow up documents were giiven to me\n50% FHE review - needs to be refined and summarized\nfinished SuperNova writeup ( https://www.notion.so/SuperNova-research-document-8deab397f8fe413fa3a1ef3aa5669f37 )\nresearched starky\n80% Halo2 notes ( https://www.notion.so/halo2-fb8d7d0b857f43af9eb9f01c44e76fb9 )\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nMore discoveries on benchmarks done on ZK-snarks and ZK-starks but all are high level\nViewed some circuits on Nova and Poseidon\nRead through Halo2 code (and Poseidon code) from Axiom\n\n\n\n\nvip::RLNP2P\n\nvac:acz:rlnp2p:waku:production-readiness\n\nWaku rln contract registry - https://github.com/waku-org/waku-rln-contract/pull/3\nmark duplicated messages as spam - https://github.com/waku-org/nwaku/pull/1867\nuse waku-org/waku-rln-contract as a submodule in nwaku - https://github.com/waku-org/nwaku/pull/1884\n\n\nvac:acz:zerokit:vac:maintenance\n\nFixed atomic_operation ffi edge case error - https://github.com/vacp2p/zerokit/pull/195\ndocs cleanup - https://github.com/vacp2p/zerokit/pull/196\nfixed version tags - https://github.com/vacp2p/zerokit/pull/194\nreleased zerokit v0.3.1 - https://github.com/vacp2p/zerokit/pull/198\nmarked all functions as virtual in rln-contract for inheritors - https://github.com/vacp2p/rln-contract/commit/a092b934a6293203abbd4b9e3412db23ff59877e\nmake nwaku use zerokit v0.3.1 - https://github.com/waku-org/nwaku/pull/1886\nrlnp2p implementers draft - https://hackmd.io/@rymnc/rln-impl-w-waku\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nzerokit v0.4.0 release planning - https://github.com/vacp2p/zerokit/issues/197\n\n\n\n\nvc::Deep Research\n\nvac:dr:valpriv:vac:tor-push-poc\n\nredesigned the torpush integration in nimbus https://github.com/vacp2p/nimbus-eth2-experimental/pull/2\n\n\nvac:dr:valpriv:vac:tor-push-relwork\n\nAddressed further comments in paper, improved intro, added source level variation approach\n\n\nvac:dr:gsub-scaling:vac:gossipsub-improvements-tech-report\n\ncont’ work on the document\n\n\n\n\n"},"vac/updates/2023-08-14":{"title":"2023-08-17 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac Milestones: https://www.notion.so/Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac week 33 August 14th §\n\nvsu::P2P §\nvac:p2p:nim-libp2p:vac:maintenance §\n\nImprove gossipsub DDoS resistance https://github.com/status-im/nim-libp2p/pull/920\ndelivered: Perf protocol https://github.com/status-im/nim-libp2p/pull/925\ndelivered: Test-plans for the perf protocol https://github.com/lchenut/test-plans/tree/perf-nim\nBandwidth estimate as a parameter (waiting for final review) https://github.com/status-im/nim-libp2p/pull/941\n\nvac:p2p:nim-chronos:vac:maintenance §\n\ndelivered: Remove hard-coded ports from test https://github.com/status-im/nim-chronos/pull/429\ndelivered: fixed flaky test using REUSE_PORT https://github.com/status-im/nim-chronos/pull/438\n\n\nvsu::Tokenomics §\n\nadmin/misc:\n\n(5 CC days off)\n\n\n\nvac:tke::codex:economic-analysis §\n\nFilecoin economic structure and Codex token requirements\n\nvac:tke::status:SNT-staking §\n\ntests with the contracts\n\nvac:tke::nomos:economic-analysis §\n\nresume discussions with Nomos team\n\n\nvsu::Distributed Systems Testing (DST) §\nvac:dst:wakurtosis:waku:techreport §\n\n1st Draft of Wakurtosis Research Blog (https://github.com/vacp2p/vac.dev/pull/123)\nData Process / Analysis of Non-Discv5 K13 Simulations (Wakurtosis Tech Report v2.5)\n\nvac:dst:shadow:vac:basic-shadow-simulation §\n\nBasic Shadow Simulation of a gossipsub node (Setup, 5nodes)\n\nvac:dst:10ksim:vac:10ksim-bandwidth-test §\n\nTry and plan on how to refactor/generalize testing tool from Codex.\nLearn more about Kubernetes\n\nvac:dst:wakurtosis:nomos:ci-integration_02 §\n\nEnable subnetworks\nPlan how to use wakurtosis with fixed version\n\nvac:dst:eng:vac:bundle-simulation-data §\n\nRun requested simulations\n\n\nvsu:Smart Contracts (SC) §\nvac:sc::vac:secureum-upskilling §\n\nLearned about\n\ncold vs warm storage reads and their gas implications\nUTXO vs account models\nDELEGATECALL vs CALLCODE opcodes, CREATE vs CREATE2 opcodes; Yul Assembly\nUnstructured proxies https://eips.ethereum.org/EIPS/eip-1967\nC3 Linearization https://forum.openzeppelin.com/t/solidity-diamond-inheritance/2694) (Diamond inheritance and resolution)\n\n\nUniswap deep dive\nFinished Secureum slot 2 and 3\n\nvac:sc::vac:maintainance/misc §\n\nIntroduced Vac’s own foundry-template for smart contract projects\n\nGoal is to have the same project structure across projects\nGithub repository: https://github.com/vacp2p/foundry-template\n\n\n\n\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:zerokit:vac:maintenance\n\nPR reviews https://github.com/vacp2p/zerokit/pull/200, https://github.com/vacp2p/zerokit/pull/201\n\n\n\n\nvip::zkVM §\nvac:zkvm::vac:research-existing-proof-systems §\n\ndelivered Nescience WIP doc\ndelivered FHE review\ndelivered Nova vs Sangria done - Some discussions during the meeting\nstarted HyperNova writeup\nstarted writing a trimmed version of FHE writeup\nresearched CCS (for HyperNova)\nResearch Protogalaxy https://eprint.iacr.org/2023/1106 and Protostar https://eprint.iacr.org/2023/620.\n\nvac:zkvm::vac:proof-system-benchmarks §\n\nMore work on benchmarks is ongoing\nPutting down a document that explains the differences\n\n\nvc::Deep Research §\nvac:dr:valpriv:vac:tor-push-poc §\n\nrevised the code for PR\n\nvac:dr:valpriv:vac:tor-push-relwork §\n\nadded section for mixnet, non-Tor/non-onion routing-based anonymity network\n\nvac:dr:gsub-scaling:vac:gossipsub-simulation §\n\nUsed shadow simulator to run first GossibSub simulation\n\nvac:dr:gsub-scaling:vac:gossipsub-improvements-tech-report §\n\nFinalized 1st draft of the GossipSub scaling article\n"},"vac/updates/2023-08-21":{"title":"2023-08-21 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac Milestones: https://www.notion.so/Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac Github Repos: https://www.notion.so/Vac-Repositories-75f7feb3861048f897f0fe95ead08b06\nVac week 34 August 21th §\nvsu::P2P §\n\nvac:p2p:nim-libp2p:vac:maintenance\n\nTest-plans for the perf protocol (99%: need to find why the executable doesn’t work) https://github.com/libp2p/test-plans/pull/262\nWebRTC: Merge all protocols (60%: slowed down by some complications and bad planning with Mbed-TLS) https://github.com/status-im/nim-webrtc/pull/3\nWebRTC: DataChannel (25%)\n\n\n\nvsu::Tokenomics §\n\nadmin/misc:\n\n(3 CC days off)\n\n\nvac:tke::codex:economic-analysis\n\nCall w/ Codex on token incentives, business analysis of Filecoin\n\n\nvac:tke::status:SNT-staking\n\nBug fixes for tests for the contracts\n\n\nvac:tke::nomos:economic-analysis\n\nNarrowed focus to: 1) quantifying bribery attacks, 2) assessing how to min risks and max privacy of delegated staking\n\n\nvac:tke::waku:economic-analysis\n\nCaught up w/ Waku team on RLN, adopting a proactive effort to pitch them solutions\n\n\n\nvsu::Distributed Systems Testing (DST) §\n\nvac:dst:wakurtosis:vac:rlog\n\nPushed second draft and figures (https://github.com/vacp2p/vac.dev/tree/DST-Wakurtosis)\n\n\nvac:dst:shadow:vac:basic-shadow-simulation\n\nRun 10K simulation of basic gossipsub node\n\n\nvac:dst:gsub-model:status:control-messages\n\nGot access to status superset\n\n\nvac:dst:analysis:nomos:nomos-simulation-analysis\n\nBasic CLI done, json to csv, can handle 10k nodes\n\n\nvac:dst:wakurtosis:waku:topology-analysis\n\nCollection + analysis: now supports all waku protocols, along with relay\nCannot get gossip-sub peerage from waku or prometheus (working on getting info from gossipsub layer)\n\n\nvac:dst:wakurtosis:waku:techreport_02\n\nMerged 4 pending PRs; master now supports regular graphs\n\n\nvac:dst:eng:vac:bundle-simulation-data\n\nRun 1 and 10 rate simulations. 100 still being run\n\n\nvac:dst:10ksim:vac:10ksim-bandwidth-test\n\nWorking on split the structure of codex tool; Working on diagrams also\n\n\n\nvsu:Smart Contracts (SC) §\n\nvac:sc::status:community-contracts-ERC721\n\ndelivered (will need maintenance and adding features as requested in the future)\n\n\nvac:sc::status:community-contracts-ERC20\n\nstarted working on ERC20 contracts\n\n\nvac:sc::vac:secureum-upskilling\n\nSecureum: Finished Epoch 0, Slot 4 and 5\nDeep dive on First Depositor/Inflation attacks\nLearned about Minimal Proxy Contract pattern\nMore Uniswap V2 protocol reading\n\n\nvac:sc::vac:maintainance/misc\n\nWorked on moving community dapp contracts to new foundry-template\n\n\n\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:rlnp2p:waku:rln-relay-enhancments\n\nrpc handler for waku rln relay - https://github.com/waku-org/nwaku/pull/1852\nfixed ganache’s change in method to manage subprocesses, fixed timeouts related to it - https://github.com/waku-org/nwaku/pull/1913\nshould error out on rln-relay mount failure - https://github.com/waku-org/nwaku/pull/1904\nfixed invalid start index being used in rln-relay - https://github.com/waku-org/nwaku/pull/1915\nconstrain the values that can be used as idCommitments in the rln-contract - https://github.com/vacp2p/rln-contract/pull/26\nassist with waku-simulator testing\nremove registration capabilities from nwaku, it should be done out of band - https://github.com/waku-org/nwaku/pull/1916\nadd deployedBlockNumber to the rln-contract for ease of fetching events from the client - https://github.com/vacp2p/rln-contract/pull/27\n\n\nvac:acz:zerokit:vac:maintenance\n\nexposed seq_atomic_operation ffi api to allow users to make use of the current index without making multiple ffi calls - https://github.com/vacp2p/zerokit/pull/206\nuse pmtree instead of vacp2p_pmtree now that changes have been upstreamed - https://github.com/vacp2p/zerokit/pull/203\nPrepared a PR to fix a stopgap introduces by PR 201 https://github.com/vacp2p/zerokit/pull/207\nPR review https://github.com/vacp2p/zerokit/pull/202, https://github.com/vacp2p/zerokit/pull/206\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nsubstitute id_commitments for rate_commitments and update tests in rln-v2 - https://github.com/vacp2p/zerokit/pull/205\nrln-v2 working branch - https://github.com/vacp2p/zerokit/pull/204\nmisc research while ooo:\nstealth commitment scheme inspired by erc-5564 - https://github.com/rymnc/erc-5564-bn254, associated circuit - https://github.com/rymnc/circom-rln-erc5564 (very heavy on the constraints)\n\n\n\nvip::zkVM §\n\nvac:zkvm::vac:research-existing-proof-systems\n\nUpdated the Nova questions document (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451 -> Projects -> Nova_Research_Answers.pdf)\nResearched ProtoStar and Nova aleternatives\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nDrafted the Nova Benchamarks document (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451 -> Projects -> Benchmarks.pdf)\nResearched hash functions\nResearched benchmarks\n\n\n\nvc::Deep Research §\n\nvac:dr:valpriv:vac:tor-push-poc\n\nReimplemented torpush without any gossip sharing\nAdded discovering peers for torpush in every epoch/10 minutes\ntorswitch directly pushes messages to separately identified peers\n\n\nvac:dr:valpriv:vac:tor-push-relwork\n\nadded quantified measures related to privacy in the paper section\n\n\nvac:dr:gsub-scaling:vac:gossipsub-improvements-tech-report\n\nExplored different unstructured p2p application architectuture\nStudied literature on better bandwidth utilization in unstructured p2p networks.\n\n\nvac:dr:gsub-scaling:vac:gossipsub-simulation\n\nWorked on GossibSup simulation in shadow simulator. Tried understanding different libp2p functions\nCreated short awk scripts for analyzing results.\n\n\nvac:dr:consensus:nomos:carnot-bribery-article\n\nContinue work on the article on bribery attacks, PoS and Carnot\nCompleted presentation about the bribery attacks and Carnot\n\n\nvac:dr:consensus:nomos:carnot-paper\n\nDiscussed Carnot tests and results with Nomos team. Some adjustment to the parameters needed to be made to accurate results.\n\n\n"},"vac/updates/2023-08-28":{"title":"2023-08-28 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac week 35 §\n\nVac Milestones: https://www.notion.so/Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac Github Repos: https://www.notion.so/Vac-Repositories-75f7feb3861048f897f0fe95ead08b06\n\nvsu::P2P §\n\nvac:p2p:nim-libp2p:vac:maintenance\n\nBecaming a Validator in the Nimbus Consensus client (95%)\nIWANT replies can be bigger than the pubsub message limit (100%, on review) https://github.com/status-im/nim-libp2p/issues/887\nImprove gossipsub DDoS resistance (98%) https://github.com/status-im/nim-libp2p/pull/920\n\n\n\nvsu::Tokenomics §\n\nadmin/misc:\nvac:tke::codex:economic-analysis\n\nTimeline of Filecoin vs competitors, IPFS vs Filecoin usage, Filip: miners perspective\n\n\nvac:tke::status:SNT-staking\n\nFurther debugging, verify Multiplier Points calculation (especially gas fee optimization, how GMX implements)\n\n\nvac:tke::nomos:economic-analysis\n\nBook seperate calls w/ Moh and Marcin to discuss helping them w/ their relative points of focus\n\n\nvac:tke::waku:economic-analysis\n\nCall w/ Aaryamann on RLN, condense our thoughts to a “proposal” for Waku\n\n\n\nvsu::Distributed Systems Testing (DST) §\n\nvac:dst:analysis:nomos:nomos-simulation-analysis\n\nAnalysis done, scales to million nodes\nExploratory sets of runs done\nDecided on the parameter set for the final runs\n\n\nvac:dst:software-testing:waku:test-plans\n\nget familiar with specs for some of the Waku protocols\n\n\nvac:dst:software-testing:waku:test-automation-js-waku\n\nSetup local env\nInvestigated how the existing tests are running and how the code is structured\n\n\nadmin/misc:\n\n2 CCs ooo\n\n\n\nvsu:Smart Contracts (SC) §\n\nvac:sc::vac:secureum-upskilling\n\nFinished Secureum Slot 6\nRead a bit into Upgradable contract patterns\n\n\nvac:sc::status:community-contracts-maintenance\n\nMoved communities-contracts repo to our Foundry template https://github.com/status-im/communities-contracts/pull/1\nAlso implemented additional tests\n\n\nvac:sc::vac:maintainance/misc\n\nFinished up moving community-dapp/contracts to foundry template\n\n\nvac:sc::status:community-contracts-deployer\n\nBrainstormed and discussed desired deployer contract with desktop team; Discussion: https://github.com/status-im/status-desktop/issues/11954#issuecomment-1694591812\nupdating ERC2470 https://eips.ethereum.org/EIPS/eip-2470\n\n\nvac:sc::status:snt-staking-contract-maintenance\n\ndiscussing issue with order of processAccount giving advantages on first callers\n\n\n\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:rlnp2p:waku:membership-management\n\nWrote a tool rln_keystore_generator : https://github.com/waku-org/nwaku/pull/1925, https://github.com/waku-org/nwaku/pull/1928, https://github.com/waku-org/nwaku/pull/1931\n\n\nvac:acz:rlnp2p:waku:rln-relay-enhancments\n\ntree metadata should include chainId and contractAddress - https://github.com/waku-org/nwaku/pull/1932\nset flush_interval appropriately -https://github.com/waku-org/nwaku/pull/1933\nintegrate new WakuRlnRegistry contract - https://github.com/waku-org/nwaku/pull/1943\nbump zerokit to v0.3.2 https://github.com/waku-org/nwaku/pull/1951\ntree metadata should include window of roots - https://github.com/waku-org/nwaku/pull/1953\nsync tree state from contract deployed block number - https://github.com/waku-org/nwaku/pull/1955\noptimization to waku_keystore - https://github.com/waku-org/nwaku/pull/1956\nfixed a forceProgression bug in the WakuRlnRegistry contract - https://github.com/waku-org/waku-rln-contract/pull/6\n\n\nvac:acz:zerokit:vac:maintenance\n\nprevent tree db from being recreated if it exists - https://github.com/vacp2p/zerokit/pull/209\nreleased zerokit v0.3.2 - https://github.com/vacp2p/zerokit/releases/tag/v0.3.2\nmerged PR to fix a stopgap introduced by PR 201 https://github.com/vacp2p/zerokit/pull/207\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nPrepared a PR to deal with message_id range check https://github.com/vacp2p/zerokit/pull/210\nResearched needed changes to rln-cli\n\n\n\nvip::zkVM §\n\nvac:zkvm::vac:research-existing-proof-systems\n\n40% update of the blog is done, working on finding smoother ways to explain findings and alternatives (focusing on a blog structure rather than a document)\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nAdded a summary table for different performances\n\n\nvac:zkvm::vac:research-existing-proof-systems\n\nFinished Plonky2 research document https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#01301b98f3af4157b932112ed998cff2\nWrite notes on Protostar\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nminor fixes plonky2 PR https://github.com/vacp2p/zk-explorations/pull/5\nREADME’s to make zk-explorations repo public https://github.com/vacp2p/zk-explorations/pull/4\nmerged and closed needed PRs for zk-explorations repo\nwork on Halo2 benchmark\n\n\n\nvc::Deep Research §\n\nvac:dr:valpriv:vac:tor-push-poc\n\ndev: fixed bugs related to initialization, changed to building async tor connections, adding direct peers, triaging/debugging issues https://github.com/vacp2p/nimbus-eth2-experimental/pull/2/commits/431a76014b3f584573329993b167fe1118eca6b3\ntest: readied setup o beacon node(s) with validator keys, test attestation transmission over tor. Planning for measuring delays\n\n\nvac:dr:valpriv:vac:tor-push-relwork\n\nsolution section refined with several updates including adding a figure for the Tor-push method.\ndedicated section on “Theoretical Analysis”\nfour different possible scenarios for the attacker to break the anonymity of the Tor network\n\n\nvac:dr:gsub-scaling:vac:gossipsub-improvements-tech-report\n\nLiterature study related to scalability, overlay design, efficient message propagation in unstructured p2p networks\nStarted writing a survey report on efficient broadcast in large scale p2p networks.\n\n\nvac:dr:gsub-scaling:vac:gossipsub-simulation\n\nExecuted different gossipsub simulations in shadow simulator\ncan now collect different metrics like packet delivery ratio, data overhead, control overhead, network bandwidth utilization, average latency & standard deviations\n\n\nvac:dr:consensus:nomos:carnot-bribery-article\nContinue work on the article on bribery attacks, PoS and Carnot. Different examples including one based on game theory were presented to show that bribery attacks are economic attacks and cannot be addressed alone in the consensus layer. Economy based solutions have to be considered at the PoS layer.\nvac:dr:consensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nBegin work on Carnot variant that aggregates the majority of votes.\nDesigning the algorithm.\n\n\nvac:dr:consensus:nomos:carnot-paper\n\nAnalyzing and discussing Carnot tests. There were variance in the latency results. We think it is due to the geographical distribution of nodes. Hence, Gusto was asked to use a single geographic zone to acheive a smooth curve while verifying that the variance is due to the latency cause by geographical distribution of nodes.\n\n\n\nvc::RFC §\n\nvac:rfc:rfc:status:port-status-specs\n\nUpdated RFC spec for Community History Archive protocol according to PR feedback\n\nhttps://github.com/vacp2p/rfc/pull/610\nThis has been reviewed more and those additional comments need to be addressed as well\n\n\n\n\nStarted porting /spec/6/PAYLOADS to Vac\n"},"vac/updates/2023-09-04":{"title":"2023-09-04 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2023/09/04 §\n\nVac Milestones\nVac Github Repos\n\nvac:p2p: §\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nOpened upstream discussion about gossipsub peer exchange (which is a DDoS vector) https://github.com/libp2p/specs/issues/570\n\n\nnimlibp2p:vac:webrtc-transport\n\nHitting roadblocks on DTLS\n\n\n\nvac:tke:: §\n\ncodex:economic-analysis\n\nPresenting Filecoin findings to Codex team\nLitepaper: assumptions on collateral\n\n\nstatus:SNT-staking\n\nHighlighted multiple design requirements not met by SC implementation for SC team notion doc\nOpen questions w/ John, epoch duration\nStaking governance proposal for when John returns Sep 12\n\n\nnomos:economic-analysis\n\nDelegated staking specifications w/Marcin, update for privacy constraints\nBribery attacks analysis, Moh asked to followup early/mid Sep\n\n\nwaku:economic-analysis\n\nFormalized RLN thoughts shared w/ Aaryamann, will push for additional feedback once Martin returns\n\n\n\nvac:dst: §\n\nanalysis:nomos:nomos-simulation-analysis\n\nTook over data generation on Tuesday\nFound a bug in simulations, working around it\nThe comparison runs are now fully automated\ngot the first full set of comparison plots: everything appears to be explainable for a fixed probability\nTree runs now scale to 15k nodes\n\n\nwakurtosis:vac:retrospective-rlog\n\nGather info and wrote summary of why we decided to stop using Kurtosis.\n\n\n10ksim:vac:10ksim-bandwidth-test\n\nCode diagrams + structurization\nChats with Ben (Codex)\n\n\nwakurtosis:nomos:ci-integration_02\n\n(hold for now, since we drop Kurtosis; will continue in November once we have the new 10k simulator tool)\n\n\nsoftware-testing:waku:test-plans\n\nAdded test plans for filter, lightpush and store: https://www.notion.so/Test-Plans-09c8c7b7f6784c459fb774792665e37c\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nMade it possible to choose the nwaku version in the js waku github actions workflow by using workflow_dispatch inputs. PR Link\n\n\n\nvac:sc:: §\n\nvac:secureum-upskilling\n\nNo progress; busy with CommunityTokenDeployer contract\n\n\nstatus:community-contracts-maintenance\n\nGas optimizations in token contracts\n\nCustom errors vs require string messages PR\nUsage of immutable properties PR\n\n\n\n\nstatus:community-contracts-deployer\n\nImplemented CommunityTokenDeployer\n\nIncludes tests and docs\nPull requests\nRan into a contract size issue; Context comment\n\n\nAdded docs for commuity token deployer contract\n\nPull Request\n\n\n\n\nstatus:governance-contract-mvp\n\nERC2470 ressurection\n\nUpdated to latest solidity\nImplemented error checking for “already deployed” (saves gas in case of user error)\nImplemented error checking for “successful deploy” (forces gas estimation to successful deploy scenario)\nIn progress upgrade on solidity compiler new outputs (from 0.5.11=>0.8.x)\n\n\nResearch on delegation vs staking contract\n\n\n\nvac:acz: §\n\nrlnp2p:waku:membership-management\n\nfixed makefile target for rln-keystore-generator - https://github.com/waku-org/nwaku/pull/1960\nlog the membership index out upon registration in the rln-keystore-generator - https://github.com/waku-org/nwaku/pull/1963\n\n\nrlnp2p:waku:rln-relay-enhancments\n\nrln was enabled by default in the Makefile - fixed - https://github.com/waku-org/nwaku/pull/1964\nordered pubsub validator execution - https://github.com/waku-org/nwaku/pull/1966\nfixed deserialization of valid merkle roots - https://github.com/waku-org/nwaku/pull/1973\nconfirm that the fetched credential from the keystore is registered to the membership set - https://github.com/waku-org/nwaku/pull/1980\nfixed makefile target for zerokit’s librln.a - https://github.com/waku-org/nwaku/pull/1981\nconverted zero-based indexing to 1-based indexing on vacp2p/rln-contract - https://github.com/vacp2p/rln-contract/pull/28\ndownstreamed zero-based indexing to waku-org/waku-rln-contract - https://github.com/waku-org/waku-rln-contract/pull/8 -\ndeployed new version of the registry contract on sepolia - 0xc04937d502E0ae671cedFC2A0BCD6692055520f3\n\n\nzerokit:vac:zerokit-v0.4\n\nMerged a PR to deal with message_id range check https://github.com/vacp2p/zerokit/pull/210\nresearched tree_size issue for the 0.4 release\nresearched idCommitment/rateCommitment issue for the 0.4 release\n\n\n\nvac:zkvm: §\n\nproofsystems:vac:research-existing-proof-systems\n\n[blog post] (https://vac.dev/rlog/Nescience-A-zkVM-leveraging-hiding-properties)\nResearched ways to achieve Goal2 and Goal3 for Nescience.\nIntegrated different techniques for Goal4 and Goal5 for Nescience.\nprepared Nova-implementation writeup (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#cce2cc365a384126b2a5041900bd3ce9)\nContinued Lasso research (https://a16zcrypto.com/posts/article/introducing-lasso-and-jolt/)\nNotes for Protogalaxy; 100%\nNotes for Protostar\n\n\nproofsystems:vac:proof-system-benchmarks\n\nAdded an introductory section for Benchmark in zk-explorations repo: https://github.com/vacp2p/zk-explorations/pull/10\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nCompleted literature study. Covered article related to overlay design (single tier, multi-tier, hybrid overlays)\npeer selection methodologies, rumor/gossiping protocols, push/pull based publishing approaches, message encoding, probablistic forwarding, overlay optimization, and peer heterogeneity/capacity based roles (super nodes and similar roles)\nStill need to review 1-2 D-regular graph based approaches. Only selected articles are added in zotero (under vacp2p)\n\n\nvalpriv:vac:tor-push-poc\n\nDebugged various appraoches(tcp, gossip, tor). Triaged why attestations not working\n\n\nvalpriv:vac:tor-push-relwork\n\ncompleted related work all\n\n\nconsensus:nomos:carnot-paper\n\nPublishing the Carnot paper (Done) https://arxiv.org/pdf/2308.16016.pdf\nBegin work on writing up Carnot’s specification in RFC format\n\n\nconsensus:nomos:carnot-bribery-article\n\nFinishing (describing research directions and their pros and cons, polishing the article) and publishing the article (Done) https://www.notion.so/WIP-Bribery-Attacks-in-Consensus-Protocols-Challenges-and-Solutions-e4e108c17dba421abe83de49076c8f25\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nCompleting the initial design and work on presentation slides. The plan will be to present the initial design on September 6 research call\n\n\n\nvac:rfc:rfc: §\n\nstatus:port-status-specs\n\nStarted porting 6/PAYLOAD to vac RFCs\n\nWork-in-progress PR is pending here\nThis RFC specifically needs a lot of work as it misses a lot of the current payload types\n\n\nUpdated 61/STATUS-community-history-archives according to feedback comments and landed it\n\nMerged PR is here\n\n\nstarted porting 16/keycard-usage to Vac (looking into status-go)\n\n\n"},"vac/updates/2023-09-11":{"title":"2023-09-11 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnim-libp2p:vac:maintenance:\n\nIWANT splitting now ready for review\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nTraffic scoring now ready for review\nPursuing upstream discussions about gossipsub Peer Exchange\n\n\nnim-chronos:vac:maintenance:\n\nContinued https://github.com/status-im/nim-chronos/pull/418\n\n\n\nvac:tke: §\n\nvac:tke::status:SNT-staking\n\nWrite first draft of staking governance proposal\nstandby to hear SC team questions\n\n\nvac:tke::nomos:economic-analysis\n\nAnalysis of rewards for delegation vs validation\n\n\n\nvac:dst: §\n\nwakurtosis:vac:rlog\n\nAddress PR feedback (https://github.com/vacp2p/vac.dev/pull/123)\n\n\nwakurtosis:waku:techreport_03\n\nbatch of simulation data with 0 msg/s rate.\n\n\nwakurtosis:vac:retrospective-rlog\n\nStarted draft/planning of document\n\n\neng-10ktool:vac:bandwidth-test\n\nWorking on adding an intermediate layer between services (Codex) and framework.\n\n\nwakurtosis:waku:techreport_02\nsoftware-testing:waku:test-plans\n\nMinor tweaks/updates on the filter test plan\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nCreated draft PR with ~60 new tests + refactoring for Filter protocol (https://github.com/waku-org/js-waku/pull/1552)\nWorked with Vaclav to run js-waku tests automatically in the nwaku CI.\n\nTests will run against the nwaku node built for the PR that triggers the CI + jswaku from master (nwaku PR: https://github.com/waku-org/nwaku/pull/2006) (js-waku PR: https://github.com/waku-org/js-waku/pull/1541)\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nGet acquainted with codebase, tests, rfcs, and nim.\nstart implementing first set of tests (Filter/SUBSCRIBER_PING).\n\n\nvac:dst:analysis:nomos:nomos-simulation-analysis\n\nDone first set of runs for different probabilities; a run takes 2+ days\nThe tree simulation now scales to 30k nodes!\nBranch runs are now fully automated\n\n\nvac:dst:wakurtosis:waku:topology-analysis\n\ntried json RPC under shadow (worked as expected); the RPC appears a bit faster compared to wakurtosis\nWaku network collection PR done : https://github.com/vacp2p/wakurtosis/pull/143\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\nif only one key exists in the keystore, use it - https://github.com/waku-org/nwaku/pull/1984\nfix log levels for some logs - https://github.com/waku-org/nwaku/pull/1986\nupdated documentation for rln-relay - https://github.com/waku-org/nwaku/pull/1993\nclean nullifier table every MaxEpochGap - https://github.com/waku-org/nwaku/pull/1994\ncreated rln_db_inspector tool, allows inspection into merkle tree structure - https://github.com/waku-org/nwaku/pull/1999, https://github.com/waku-org/nwaku/pull/2012\nfixed missing memberships between history sync and new memberships sync with @alrevuelta - https://github.com/waku-org/nwaku/pull/2015\nremove rln from waku’s experimental features - https://github.com/waku-org/nwaku/pull/2001\nfix metric calculation for registered members - https://github.com/waku-org/nwaku/pull/2018\nuups proxy for waku-rln-registry - https://github.com/waku-org/waku-rln-contract/pull/9\n\n\nzerokit:vac:zerokit-v0.4\n\nfetched artifacts from trusted setup completion, generated verfication keys and circuit’s wasm files\nfor some reason, the proof verification always results in false, needs further investigation. working branch - https://github.com/vacp2p/zerokit/pull/211\nCreated and merged a PR to fix test failings https://github.com/vacp2p/zerokit/pull/212\nReaserched test failures with new artifacts\n\n\n\nvac:sc: §\n\nstatus:snt-staking-contract-maintenance\n\nPrepared a pull request that migrates the code base to our foundry template: Pull Request #6\n\n\nstatus:community-contracts-deployer\n\nRefactored CommunityTokenDeployer contract to make use of token factory contracts: Pull Request #2\nUpdated documentation and visuals according to code changes: Pull Request #4\n\n\nvac:maintainance/misc\n\nAdded support for codecoverage analysis in our foundry template: PR: https://github.com/vacp2p/foundry-template/pull/6\nAdded basic deployment config to our template: PR: https://github.com/vacp2p/foundry-template/pull/5\nAdded slither support: PR: https://github.com/vacp2p/foundry-template/pull/4\nadded a new resource to the Smart Contract notion section about gas optimizations\n\n\n\nvac:zkvm: §\n\nproofsystems:vac:research-existing-proof-systems\n\nAddressed some questions regarding Nescience.\nWorked on compressing informations in Nescience for a future publication.\nContinued research on Jolt\nContinued writing a paper on Lasso (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#025f586e7e4c46818a0e0a1ab9a79c20)\nAttended webinars for Open Talk: Zero Knowledge (recorded talks)\nUpdate Halo2 notes\n\n\nproofsystems:vac:benchmarks\n\nPublished a complete section on Github regarding Benchmarks (https://github.com/vacp2p/zk-explorations/blob/main/benchmarks.md).\nwork on Halo2 benchmark implementation\nNova Circom: done, Nova-Scotia: there is a part left\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nCompleted the tor based gossipsub instance broadcas; the first working POC. Overcame, triaged several issues https://github.com/vacp2p/nimbus-eth2-experimental/issues/1\n\nfirst running tor-push nimbus validator\n\n\n\n\nvalpriv:vac:tor-push-paper\n\nchanges to introduction, solution section, removed not in scope papers\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on adding staggered sending suppoort in Gossipsub (still working on it)\nFormalized and improved simulation scripts for GossipSub behavior against large messages.\n\n\nconsensus:nomos:carnot-paper\n\nWork on writing up Carnot’s specification in RFC format (https://github.com/logos-co/nomos-specs/blob/RFC/carnot/spec.md)\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWork on presentation slides for Sep. 6 research call. (slides can be found at: https://www.notion.so/Roadmap-Deep-Research-DR-561a864c890549c3861bf52ab979d7ab?pvs=4#d1d3033792b443f39e47955721f9db52)\nBegin to write down the high level protocol.(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n\nvc::rfc: §\n\nstatus:port-status-specs\n\nKicked off discussion with “stakeholders” about 6/PAYLOAD spec and how it should be ported/maintained\nstarted porting parts of 6/PAYLOAD\nPorted 16/keycard-usage to 63/status-keycard-usage - https://github.com/vacp2p/rfc/pull/615\n\n\n"},"vac/updates/2023-09-18":{"title":"2023-09-18 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnim-libp2p:vac:maintenance:\n\nFixed gossipsub Direct Peers\nContinued cross-libp2p perf implementation\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nOpen eth specs issue about disabling gossipsub Peer Exchange\n\n\nnimlibp2p:vac:webrtc-transport\n\nFixed the blocking DTLS issue, continuing vertical implementation\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nReview litepaper feedback w/ Codex and identify steps to finalize Codex tokenomics\n\n\nvac:tke::status:SNT-staking\n\nReview staking governance proposal w/John in Status call\n\n\nvac:tke::nomos:economic-analysis\n\nAnalysis of rewards for delegation vs validation\nResearching ETH 2.0 emission decision rationales\n\n\n\nvac:dst: §\n\nwakurtosis:waku:techreport_03 & wakurtosis:vac:rlog\n\nAnalysis of the non-load simulations (0msgs to isolate discv5 effects)\nRecaculated efficiencies taking into account message counts instead of expectation\nGenerated new efficiency plots; Re-written discussion to account for the latter\n\n\neng-10ktool:vac:bandwidth-test\n\nCreated new repo for Python tool (https://github.com/vacp2p/10ksim)\nKubernetes configuration and documentation (https://github.com/vacp2p/10ksim/issues/1)\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAddressed comments and merged the Filter protocol tests PR (https://github.com/waku-org/js-waku/pull/1552)\nCreated new PR with ~40 new lightpush tests (https://github.com/waku-org/js-waku/pull/1571)\nExtract the testing parts of js-waku CI into reusable workflows that can be easily called cross-repo (https://github.com/waku-org/js-waku/pull/1566)\nImproved the retry-on-fail mechanism of the js-waku tests (https://github.com/waku-org/js-waku/pull/1573)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nFinished implementing waku filter ping tests; PR\nImplemented waku filter subscribe tests; Found first two wrong/unclear behaviours due to tests; PR 1; PR 2\nChecking existing tests and removing legacy/duplicated.\nBegan implementing waku filter client error tests\n\n\n\nvac:acz: §\n\nzerokit:vac:zerokit-v0.4\n\nPrepared a PR to fix test_recover_id_secret test due to incorrect serialization https://github.com/vacp2p/zerokit/pull/217\nFixed serialization in other tests\n\n\nsecure-channels:waku:ethereum-chat\n\nGetting familiar with some of the protocols, namely: X3DH, Double Ratchet, XEdDSA and Noise.\nStart defining the requirements of the secure chat protocol.\n\n\nrlnp2p:waku:rln-relay-enhancments\n\nupdated submodule, fixed metric - https://github.com/waku-org/nwaku/pull/2024\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nupdated nwaku pre-requisites docs for rln - https://github.com/waku-org/docs.waku.org/pull/115\n\n\nzerokit:vac:maintenance\n\nexposed leaves_set api to count the number of insertions into the tree - https://github.com/vacp2p/zerokit/pull/213\noptimized the batch insert to reduce insertion times - https://github.com/vacp2p/zerokit/pull/215\n\n\nzerokit:vac:zerokit-v0.4\n\nstill continuing to investigate proof verification failures. headway made, the root that the proof has is != the tree root produced by zerokit.\n\n\n\nvac:sc:: §\n\nstatus:SNT-optimism-bridge\n\nWorkin on porting legacy MiniMe token to our foundry template\n\nAlso update its code and tests; Ultimately this becomes a dependency of other projects (staking, governance etc)\n\n\nUpdated to solidity 0.8.19\nFixed linting 1 , 2\nUpgraded error-strings to error-codes\nStarted fixing auditor errors: variables->immutables, uint128 castings, check-effects-interactions\nother minor improvements (erc20, separate contracts)\n\n\nvac:misc:\n\nVisited blockchain week in Berlin\n\n\n\nvac:zkvm: §\n\nproofsystems:vac:research-existing-proof-systems\n\nWorked on the motivation of Goal 1: Why separate state is more beneficial (Document next week)\nStarted a somehow scientific article format for Nescience\nFinished a writeup on Lasso https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#e563de6778b04479a7936e2c5664c9ec\nStarted writing a writeup on Jolt\nUpdate Logos slides for presentation on 9/20. (link pending)\nBegin research recproof\n\n\nproofsystems:vac:benchmarks\n\nFinished Nova benchmark that uses Nova-Scotia https://github.com/vacp2p/zk-explorations/pull/13\nStarted working on Nova benchmark that uses bellman (original/default way to do things in Nova)\nWorked on Halo2 benchmarks\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nExtraced latency of attestations sent from gossip_sub debug level logs\nCollected around 150 or more latencies of attestations, both for normal and tor switch\nValidated tor-circuit formation on validator machine\n\n\nvalpriv:vac:tor-push-paper\n\nRevised the structure of paper, added mathematical definition\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nThe first draft of survey is ready for review\n\n\ngossipsub-improvements-paper\n\nIncorporated changes to the first draft of the improvement paper. Still a work in process.\n-consensus:nomos:carnot-vote-2-3rds-vote-aggregation\nWriting the psuedocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdded discussion and committee merging algorithm to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\ncontinued discussion of the PAYLOAD RFC; continue working on updating the RFC\n\n\n"},"vac/updates/2023-09-25":{"title":"2023-09-25 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nMerged GossipSub Traffic Scoring https://github.com/status-im/nim-libp2p/pull/920\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nContinued simulations\n\n\nnim-libp2p:vac:maintenance\n\nTried to integrate HP in nwaku, but rendezvous isn’t integrated yet\n\n\nnimlibp2p:vac:webrtc-transport\n\nContinued vertical integration of protocols\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nMeeting with Codex on Tuesday, get in sync on timeline and steps for final delivery\n\n\nvac:tke::status:SNT-staking\n\nReview goverance process itself, governance proposal template, staking gov proposal w/ John\n\n\nvac:tke::nomos:economic-analysis\n\nAnalysis of rewards for delegation vs validation\nAlvaro shared further docs to review on Private Addressing incentives and two-tiered staking\n\n\nvac:tke::waku:economic-analysis\n\nReading WAKU papers and onboarding Sergei, establishing recurring cadence\n\n\n\nvac:dst: §\n\nwakurtosis:waku:techreport_03\n\nDelivered (pending discussion with Waku team)\n\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nRun 20K simulation (resources test)\n\n\neng-10ktool:vac:bandwidth-test\n\nCheck with Slava K8s configuration, to run nodes in master aswell (K3s)\nCode first multi-node deployment\nDockerized DST node\n\n\nsoftware-testing:waku:test-plans\n\nStarted working at the Relay test plan\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAddressed all comments from last week PRs and merged them\nFixed the nwaku CI part that invokes js-waku: https://github.com/waku-org/nwaku/pull/2061\nBumped nwaku version in js-waku CI: https://github.com/waku-org/js-waku/pull/1591\nHelped investigating nwaku issues caught by the js-waku tests\nInvestigated some flaky tests and tried to fix them: https://github.com/waku-org/js-waku/pull/1592\nStarted working on adding new tests for the static sharding functionality for js-waku\nAdded a bug report found during testing and a feature request for test reporting\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nImplement service to service waku filter tests: PR\nImplement coverage for nwaku: PR\nRebase all test branches from master, fixing numerous git mishaps.\nUpdate PRs with comments.\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\nfixed a segfault issue - https://github.com/waku-org/nwaku/pull/2047\n\n\nzerokit:vac:zerokit-v0.4\n\nstill investigating the proof verification failures using the new artifacts. can confirm that the inputs for proof generation are valid, and are verified by using snarkjs.\n\n\nRemoved private message_id from compute_id_secret agruments\n\nFix RLNProofValues\n\n\nsecure-channels:waku:ethereum-chat\n\nWiP Notion doc on the specifications of the protocol\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-deployer\n\nMerged all pending PRs. This milestone is now done\nDeployed a version of token deployer contracts to optimism goerli\n\n\nstatus:community-curation-contracts\n\nDiscussed and started implementing necessary changes for beta release\n\nFoundry deployment script\nbatch processing of votes in finalization phase\n\n\n\n\nstatus:SNT-optimism-bridge\n\nSync call with Certora on audit report and next audit planning\ncreated tests for onTransfer reentrancy case https://github.com/vacp2p/minime/pull/29\n\nfixed reentrancy https://github.com/vacp2p/minime/pull/24\n\n\nrised coverage from 54.62% to 67.23% https://github.com/vacp2p/minime/pull/33\nAlter Minime to allow being extended to specialized tokens (such as OptimismMintableERC20) https://github.com/vacp2p/minime/pull/32\ncreate script for detailed gas-report https://github.com/vacp2p/minime/pull/25\nlocally optimized gas usage\n\n\n\nvac:zkvm: §\n\n\nproofsystems:vac:research-existing-proof-systems\n\nWritten a document for State Separation motivation for Nescience\nReadings to justify Goal 3\nConsidered some scientific paper format for Nescience\nWorked on Jolt writeup draft (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#fae64ac478004b749f7b211a9542f2d2)\nStarted research on Poseidon paper (https://eprint.iacr.org/2019/458.pdf) and is implementations\nLogos research call presentation.\nNotes on Recproof (WIP) and zkTree (same document).\nNotes on Poseidon2 (WIP)\n\n\n\nproofsystems:vac:benchmarks\n\nAdded an explanation for Plonky2 circuit [To add to GitHub]\nStarted reading Nova circuit to provide an explanation of what the circuit is doing\nfinish up Nova bellman benchmark https://github.com/vacp2p/zk-explorations/pull/14\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nInvestigated the issue with failing attestation, Fixed the exclusion of connected peer\nDebugged the latency script evaluation/ Recalculated stats.\n\n\nvalpriv:vac:tor-push-paper\n\nUpdated the structure of the paper and added tentative contributions to the paper.\nAdded sections on latency and security analysis in the results section along with the potential limitations of the proposed method.\n\n\ngossipsub-improvements-paper\n\nResearch log post for GossipSub improvements is ready for review\nIncorporated changes to the Introduction, and Related work. Results part is still a work in process.\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the pseudocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdding discussion to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n:nomos:review\n\nReviewing https://www.notion.so/Data-Availability-Specification-c3961b681eba4ccdab2be9181e4207b4#3df2088e8a9b4c048310e51ff8e577a8\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nporting 2/ACCOUNTS to vac rfcs (RFC 65); in review process\n63/STATUS-Keycard-Usage merged https://rfc.vac.dev/spec/63/\n\n\n"},"vac/updates/2023-10-02":{"title":"2023-10-02 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnim-chronos:vac:maintenance\n\nOpened alternative fix for closure completion issue\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nContinued simulations\n\n\nnimlibp2p:vac:webrtc-transport\n\nContinued vertical integration of protocols\n\n\nnim-libp2p:vac:maintenance\n\nMerged gossipsub IWANT fix\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nCodex pushed meeting back again, reviewing this week to get in sync on timeline and steps for final delivery\n\n\nvac:tke::status:SNT-staking\n\nJohn has reviewed goverance process itself, governance proposal template, staking gov proposal, finalize details with him this week\nComplete anonymous user matching proposal draft\nStill some differences between design and implementation in SC, Martin working on these items in order to hand off\n- Rewards should not be claim order dependent\n- Restaking mechanism, same vault vs create new vault\n- Rewards can be claimed retroactively vs GMX style model of needing to claim in real-time\n\n\nvac:tke::nomos:economic-analysis\n\nFrederico in regular communication with Alvaro, continuing on Private Addressing research\n\n\nvac:tke::waku:economic-analysis\n\nMartin follow up with Sergei on collaboration ideas and feedback on WAKU so far\n\n\n\nvac:dst: §\n\nwakurtosis:vac:retrospective-rlog\n\nDelivered for first round of reviews (https://github.com/vacp2p/vac.dev/pull/131)\n\n\nwakurtosis:vac:rlog\n\nTaken care of review comments, still issues with results (injection loss)\n\n\neng-10ktool:vac:bandwidth-test\n\nChanged dst-node code to fit a K8s environment\nPut dst-node in dockerhub\nRun as many nodes as possible on two machines with plain Kubernetes\n\n\nsoftware-testing:waku:test-plans\n\nFinished the Relay test plan: https://www.notion.so/Relay-c91b6df8d96a4527b5d2d599bf8dd54e\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAdded new tests for static sharding feature (phase 1) to cover filter, lighPush, store and relay protocol. Also changed existing methods and tests to support multiple pubSubTopics. Awaiting review: https://github.com/waku-org/js-waku/pull/1624\nStarted refactoring and adding new tests for store protocol. Draft PR: https://github.com/waku-org/js-waku/pull/1627\nHelped investigating a change in nwaku that caused issues in the js-waku lightPush tests\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nMerge coverage https://github.com/waku-org/nwaku/pull/2067\nUpdate open Filter PRs\nImplement waku filter tests (Unsubscribe, payloads, security and privacy)\n\nUnsubscribe PR\nUnsubscribe All, Payloads, and Privacy and Security PR\nNode Privacy and Security PR\n\n\nImplement returning error on “unsubscribing from non-subscribed server” (Change inside Unsubscribe PR)\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nRan Go’s coverage report to see about unit tests\nBuilt and played with Waku v2 Filter example, docker image locally\nWrote Dockerfile and test container image build workflow\ngo-waku’s test docker registry @quay.io is in preparation with jakubgs\n\n\n\nvac:acz: §\n\nzerokit:vac:zerokit-v0.4\n\nunblocked rln-v2 proof verification, pending rln-wasm bug fix\n\n\nsecure-channels:waku:ethereum-chat\n\nCompleted a first version of the WiP including an extension to group chats.\nCompleted a first approach to using Noise nomenclature for X3DH and the DH ratchet in the double ratchet.\nStudied how to approach Signal’s PQXDH in terms of Noise.\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-deployer\n\nCode clean up https://github.com/status-im/communities-contracts/pull/17\nCustom token events https://github.com/status-im/communities-contracts/pull/18\n\n\nstatus:community-curation-contracts\n\nFinish moving to foundry template https://github.com/status-im/community-dapp/pull/69\nAdd foundry deployment script https://github.com/status-im/community-dapp/pull/70\nIntroduce evaluation limit and use minime token https://github.com/status-im/community-dapp/pull/72\nSmaller additional PRs\n\nRemove safeMath/save gas https://github.com/status-im/community-dapp/pull/71\nUse OZs Ownable https://github.com/status-im/community-dapp/pull/73\nProduction parameters https://github.com/status-im/community-dapp/pull/74\n\n\n\n\nstatus:SNT-optimism-bridge\n\nMove repository to foundry template\nAdd modern minime as dependency https://github.com/logos-co/optimism-bridge-snt/pull/9\n\n\nstatus:community-contracts-ERC20\n\nAdded Owners and Master tokens to Community ERC20 contract\n\n\nstatus:SNT-optimism-bridge\n\nreport for certora\nimplement ERC2612\nimprove code and gas cost\ncoverage to almost 100%\nimprove abstraction of MiniMeBase\nwork on SNTPlaceHolder issues\n\nadd claimTokens\nremove safemath\n\n\n\n\n\nvac:zkvm: §\n\nproofsystems:vac:research-existing-proof-systems\n\nWritten a document for Proof Creation and Verification (Goal 3 for Nescience) - WIP 70%\nStarted a first draft for research article for Nescience\nStarted readings on bulding secure zkVMs\nResearched on Poseidon paper (https://eprint.iacr.org/2019/458.pdf) and is implementations\nFinished Jolt writeup (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#43de765557544ec59efa038a2d39c98b)\n\n\nproofsystems:vac:benchmarks\n\nadded ducumentation to plonky2 code (https://github.com/vacp2p/zk-explorations/pull/15)\nWork on Halo2-benchmark\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nReducing attestation miss rate, separating peerpool/conn table for torswitch\n\n\nvalpriv:vac:tor-push-paper\n\npaper updated\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nIncorporated suggested changes GossipSub improvements research log post (https://github.com/vacp2p/vac.dev/pull/130). Currently doing proofreads, and readjusting citations.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nPull request created for GossipSub shadow simulation.\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the psuedocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdding discussion to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n:nomos:review\n\nReviewing https://www.notion.so/Data-Availability-Specification-c3961b681eba4ccdab2be9181e4207b4#3df2088e8a9b4c048310e51ff8e577a8\n\n\nzk:codex:storage-proofs-open-problems-review\n\nsync with Codex on the issues\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nclean up 65/status-accounts spec, draft of test vectors which were omitted\nContinue and finish porting a version of the PAYLOADS spec https://github.com/vacp2p/rfc/pull/612\n\n\n"},"vac/updates/2023-10-09":{"title":"2023-10-09 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nContinued vertical integration of protocols\nStarted DataChannel implementation (last protocol in the stack)\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation:\n\nMerged last part of the ddos mitigation. End of this milestone, next step is to enable in nimbus\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nCodex meeting confirmed for Tuesday, reviewing this week to get in sync on timeline and steps for final delivery (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nDiscuss anonymous user matching proposal with John (@Matty)\nComplete all edits of all 3 proposals based on John’s feedback (@Matty)\nImprovements to smart contract implementation (claim order dependency), and refactoring, actively working with SC team (@Martin)\nFinance (Matt Nemer and Adam) asked for refresh of the economic model/projections this month (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nFrederico remains in regular communication with Alvaro and Marcin, continuing on Private Addressing research (@Frederico)\n\n\n\nvac:dst: §\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nBandwidth analysis with ‘plot-shadow’ (https://github.com/shadow/shadow/blob/main/src/tools/plot-shadow.py)\nTemporal graph extraction / analysis of gossipsub node\n\n\nwakurtosis:vac:rlog\n\nRunning new batch of simulations\n\n\nanalysis:nomos:simulation-analysis\n\nwork on additional set of analysis and ways to resolve the tree/branch discrepancy; analysis/data collection is priority\nAdding “realistic” network delays to the simulations is an immense memory hog and DST machine crashed repatedly for days together;\n\nspecial thanks for Jakub for promptly resetting the machine, but it still took days to figure usable parameters\n\n\nTook all week and weekend to get just one run for 10k nodes\n\n\nwakurtosis:waku:gossipsub-topology-analysis\n\nThe CollectNet PR (https://github.com/vacp2p/wakurtosis/pull/143)\n\n\neng-10ktool:vac:bandwidth-test\n\nK8s configurations https://github.com/vacp2p/10ksim/issues/1\nPOD limites per node (point 4)\n\nAvailable IPs per node (point 4)\nParallelize StatefulSets (point 5)\nSet second machine as Schedulable\n\n\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nFinished adding new tests for store protocol.\n\nIncreased coverage from 9 tests to ~60.\nDiscovered several issues/discrepancies that I’ve raised with the Waku teams.\n\n\nAdded small fix for some flaky tests\nUpdated docker hub org from where the tests fetch nwaku/gowaku images\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nBegin Relay subscribe tests\n\nMessage id (https://github.com/waku-org/nwaku/pull/2101)\nSubscribe WIP (No PR yet)\n\n\nInvestigate possible missbehaviours, diving into libp2p code.\nOpen relay subscription bug issue: https://github.com/waku-org/nwaku/issues/2114\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nGo-waku’s test docker registry @quay.io is working well\nDockerfile and test container image build workflow tested & merged https://github.com/waku-org/go-waku/pull/792\nWrote first test and found first bug - fixed by devs already https://github.com/waku-org/go-waku/commit/d900a6c81457cdb9bd264867d61064fc923a4d30 https://github.com/waku-org/go-waku/pull/794\n\n\n\nvac:acz: §\n\nzerokit:vac:zerokit-v0.4\n\nMerged PR https://github.com/vacp2p/zerokit/pull/217\nFixed ffi tests\ncompleted release, milestone complete - https://github.com/vacp2p/zerokit/releases/tag/v0.4.1\n\n\nrlnp2p:waku:multi-epoch-constraint\n\nStart working on a more concise solution for the problem\n\n\nsecure-channels:waku:ethereum-chat\n\nIncrease the level of detail in the description of the WiP towards the creation of an RFC\n\n\n\nvac:sc:: §\n\nstatus:SNT-optimism-bridge\n\nUpdate bridge repo to latest vacp2p/minime dependency\nImplemented foundry deploy script\nCustom errors over string messages\nToken controller rename\n\n\nstatus:community-contracts-ERC20\n\nHelped with adding owner/token-master access control\n\n\nstatus:community-curation-contracts\n\nDeployed contracts on goerli\n\n\nstatus:community-contracts-maintenance\n\nLanded custom minting events\nupdate the erc20 contract to have owner/master tokens\nadded CommunityOwnable contract with base auth\nFix and update failing tests and deploy erc20 implementation to testnet\nPR: https://github.com/status-im/communities-contracts/pull/19\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nResearching techniques for state separation\nStarted a new document about how to implement state separation\n\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished the document about [Proof Creation and Verification] (Goal 3 for Nescience) - To share soon\nStill doing some research on how to make Nescience compact for an article\nSeveral readings on bulding secure zkVMs\nPrepared a draft on Starky (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#4e5bc7f510c042609139bffd5534e69b)\n\n\nproofsystems:vac:benchmarks\n\nAdded an explanation for Nova-Scotia circuit\nPrepared poseidon-starky circuit generation part\nBegin code review for Nova benchmark\nContinue working on Halo2 benchmark\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nSeparating tor context from normal and implemented new PR\nFor over 4 days, monitored attestation success with near zero attestation drop rate, effectiveness varies\nwith opt incl distance, but automatically recovers to 86% on average\n\n\nvalpriv:vac:tor-push-paper\n\nmore updates to the paper\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\npushed the recommended changes for GossipSub improvement blogpost for approval\nstudied different proximity estimation, bandwidth estimation techniques for GossipSub improvements\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nUpgraded my system to execute relatively larger networks. Executed relatively larger simulations (upto 9000 nodes) to analyze the impact of D on message spread and the number of messages.\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the psuedocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdding discussion to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\nzk:codex:storage-proofs-open-problems-review\n\nGetting up to speed on Codex documents: Balazs’ sampling\nshared minor math error in Discord, Codex’s EC requirements, Preventing data loss, Block placement, Compact Proofs of Retrievability, Codex storage proofs rationale\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nmerged rfc 65\nreviewed waku-usage rfc, unclear if the old rfc can be ported as it is no longer relevant\nPAYLOADs almost done, addressing review comments\n\n\n"},"vac/updates/2023-10-16":{"title":"2023-10-16 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nStarted to implement DataChannel in WebRTC: https://github.com/status-im/nim-webrtc/pull/4\nStarted to implement the WebRTC transport in libp2p: https://github.com/status-im/nim-libp2p/pull/\nrework of UDP / Stun / Dtls / Sctp https://github.com/status-im/nim-webrtc/pull/\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nhttps://github.com/libp2p/jvm-libp2p/pull/336\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nMet w/ Codex and reviewed the marketplace workflows, identified many updates for litepaper (@Matty)\nWill update litepaper incorporating feedback, and update Codex modeling, reconnect after their offsite\n\n\nvac:tke::status:SNT-staking\n\nUpdate notion docs with links to all latest governance proposals\nAssigning issues in Github to SC team, and submit pull reqs, primarily on dependency the claims, and how restaking works (@Martin)\nContinuing revamp of economic model/projections, review early approach w/John (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nFrederico remains in regular communication with Alvaro and Marcin, continuing on Private Addressing research (@Frederico)\nReviewing similar challenges ETH is also considering, changes to economic model for adding native delegation\n\n\nvac:tke::waku:economic-analysis\n\nHad a call with Aaryamann and Sergei last week, they had followup questions on fleshing out pros/cons of various design approaches to RLN stake (@Martin)\n\n\n\nvac:dst: §\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nFixed timestamp bug\nUpdated traffic injection to continuous operation\nCreated IPFS mesh slices of arbitrary time length\n\n\nanalysis:nomos:simulation-analysis\n\nFinally zero’d in on the tree/branch bug. The pre and post-analysis are fine, the bug is in the Carnot sim.\nThe view installation time distribution with network delays is now done\n\n\ndr-support:vac:carnot-2-3rds-python-impl\n\ninvestigate Carnot sim code\n\n\neng-10ktool:vac:bandwidth-test\n\nFinish exporting metrics (delayed)\nMake sure new CIDR configuration supports 10k PODs\n\n\nwakurtosis:vac:rlog\n\nfinish simulations\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nNew tests:\n\nRelay[WIP]\n\n\nImprovements:\n\nSpeed up execution from 12m to 3.5m for 250 tests through parallelization(Significant refactoring needed to achieve this)\nFollow up fix to only allow paralellization in CI env\n\n\nFixes:\n\nUpdated tests after gowaku store fixes\nUpdated tests after remote peer rejected error\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nRelay and message id tests\n\nPR\n\n\nMerge filter subscribe PRs; Pending unsubscribe, missing one review.\nHeavily investigate issues shown on tests\n\nMax 1MB message size, no graceful handle.\nAfter stopping and restarting a relay node, can’t reconnect it with connectRelay.\nCan’t stop a relay node and send a message: Inconsistent with filter push behaviour.\nPublishing multiple messages in a row triggers the same SEGFAULT as when refreshing a subscription.\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote five tests - were added to the branch https://github.com/waku-org/go-waku/tree/chore(filterV2)-test-updates\nReported issue “Messages won’t get through with multiple pubsub topics” https://github.com/waku-org/go-waku/issues/804\nTracking coverage as notes so far -> will change to tabular form. Notion has API, we could possibly update docs during test execution? https://www.notion.so/Filter-Test-Coverage-42fc15b503ec4621980a7757d85089db?pvs=4\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\nworked on the rln rlog - https://github.com/vacp2p/vac.dev/pull/132\n\n\nmisc\n\nexplored next iteration of rln, which includes message sizes within the proof\n\n\nrlnp2p:waku:multi-epoch-constraint\n\nKeep working on a solution for the problem. (https://www.notion.so/WiP-Multi-epoch-Constraints-a5b648b98c46461187563d6c1e094468)\n\n\nsecure-channels:waku:ethereum-chat\n\nKeep improving the level of detail in the description of the WiP towards the creation of an RFC. (https://www.notion.so/WiP-Secure-Ethereum-Chat-f69ff155456c4fdeb719aba96fd7a8ab)\n\n\n\nvac:sc:: §\n\nstatus:snt-staking-contract-maintenance\n\nAdded additional tests\n\nhttps://github.com/logos-co/staking/pull/27\nhttps://github.com/logos-co/staking/pull/36\n\n\nUse custom errors over error strings\n\nhttps://github.com/logos-co/staking/pull/28\nhttps://github.com/logos-co/staking/pull/29\nhttps://github.com/logos-co/staking/pull/30\nhttps://github.com/logos-co/staking/pull/35\n\n\nSome cleanup\n\nhttps://github.com/logos-co/staking/pull/26\nhttps://github.com/logos-co/staking/pull/25\n\n\nIntroduced VaultFactory\n\nhttps://github.com/logos-co/staking/pull/38\n\n\n\n\nstatus:community-contracts-maintenance\n\nDeployed community token deployer contracts to Sepolia\n\nhttps://github.com/status-im/communities-contracts/pull/20\n\n\n\n\ncodex:review-codex-contracts\n\nDid a first quick review of the code, notes can be found here\n\nhttps://www.notion.so/Codex-Marketplace-Contracts-337a2e38fa574a2d8ffb589f4f599\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nFinished and shared a new document about state separation techniques\nKeep researching and adding updates\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStill working on Proof Creation and Verification (Goal 3 for Nescience), specifically trying to identify novel techniques\nConsidering article for Nescience\nContinuous readings on bulding secure zkVMs\ndiscussion on Sona proof system (from Lasso paper) and alternatives (Hyrax, KZG, FRI)\nReserched the connection between plonky2 and starky\n\n\nproofsystems:vac:benchmarks\n\nStarting a draft for an article (overleaf)\nworking on Halo2 benchmark\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nGetting fleet nimbus node measurements.\nFor PR, over 11 days, monitored attestation success with near zero attestation drop rate, effectiveness 89%\nInvestigating why opt. incl distance degrades occassionally\n\n\nvalpriv:vac:tor-push-paper\n\nAdded changes in https://www.overleaf.com/project/6499e467346d9f56b2971ca\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nDigged deeper into the gossipsub implementation in nim-lib-p2p.\nModified handling of large messages in the existing implementation. Modified message relaying behavior\n\nWe relay the large messages to only d_low peers and other peer are sent an IDONTWANT message.\nUnreceived large messages are requested using IWANT message.\nWe save approximately 40% bandwidth, on cost of approximately 2 RTTs to the opverall message latency\n\n\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the psuedocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdding discussion to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nreviewed waku usage of status, draft of rfc\n\n\n"},"vac/updates/2023-10-23":{"title":"2023-10-23 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nadmin\n\nrestructure\n\n\nnimlibp2p:vac:maintenance\n\nFind a fix for https://github.com/waku-org/nwaku/issues/2140\nPR: Test: Remove workflow for Nim Devel from "Daily" https://github.com/status-im/nim-libp2p/pull/968\n\nnim devel test will still be run daily, but in a separate CI workflow\n\n\n\n\nnimlibp2p:vac:webrtc-transport\n\nSuccessfully compile the full stack and start debugging.\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nhttps://github.com/status-im/nim-libp2p/pull/965\n\n\nnimlibp2p:vac:maintenance\n\nAdd arm64 support when running HP tests locally\nhttps://github.com/libp2p/test-plans/pull/311 and https://github.com/libp2p/rust-libp2p/pull/4687. (This is a blocker for: Add Hole Punching to libp2p test-plans - https://github.com/status-im/nim-libp2p/issues)\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nUpdating Codex “growth model” and migrating litepaper to notion w/ Codex feedback (@Matty)\nProviding fundraise (Matt Nemer) w/ high level summary of financials and token design (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nHelping John with final preparation for website launch, setting up Snapshot space (@Martin)\nOngoing w/ SC team for staking contract implementation (@Martin)\nDiscussed “growth model” (economic projections) w/ John, Chandler, and finance, aligning w/ Chandlers model (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nFinished drafting high level proposals on Private Addressing research, reviewing w/ Marcin (@Frederico)\nReturning to native delegated staking research, based on recent developments in ETH and Lido (@Fredico)\n\n\nvac:tke::waku:economic-analysis\n\nJoining Waku Reseach Sync calls going forward to stay up to date on progress w/ Sergei (@Martin)\nReviewing Sergei’s notes so far on waku-org/research, and completing followup requests from Aaryaman and Sergei\n\n\n\nvac:dst: §\n\nwakurtosis:vac:rlog\n\nPushed changes with new results (https://github.com/vacp2p/vac.dev/commit/c67ea09ac17a6049529983ef325ae4d9c6c24e2d)\n\n\nanalysis-shadow:waku:shadow-waku-relay-analysis\n\nInvestigating best approach for large scale (new wakunode2 with traffic vs external RPC calls)\n\n\neng-10ktool:vac:bandwidth-test\n\nFix problem in multicloud-cluster:\n\nhttps://github.com/status-im/infra-misc/issues/184\nhttps://github.com/k3s-io/k3s/discussions/8657\n\n\nCheck Prometheus metrics\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nNew tests:\n\nRelay - awaiting review\n\n\nImprovements:\n\nTest report dashboard. PR and deployment - awaiting review\n\n\nIssues found:\n\nNwaku regression around store cursor\nJS-waku possible issue around duplicate messages\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nIssues\n\nResubscription SEGFAULT\n\nReinvestigated and found it was a test case error, a futures issue.\nClosed Ticket\n\n\nPublishing multiple messages in a row triggers the same SEGFAULT as when refreshing a subscription.\n\nSame as above\n\n\nMax message sizes don’t match RFC\n\nReinvesitgated because some sizes weren’t correct.\nOpened Ticket\n\n\nAfter stopping and restarting a relay node, it can’t reconnect with connectRelay.\n\nReinvestigated because a comment by Aaryamann.\nOpened Ticket\n\n\n\n\nBegan implementing Store tests.\nGot a working GDB for NIM with VSCode integration. Not great, but it’s something.\nCleaned up Filter and Relay tests, and added missing payload size tests.\n\n[PR](https://github.com/waku-org/nwaku/pull/2138\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote five tests - were added to the branch https://github.com/waku-org/go-waku/tree/chore(filterV2)-test-updates\nReported issue “Subscription with empty contentTopic should fail” https://github.com/waku-org/go-waku/issues/810\nRetested issues #804 and #810 - learned a lot from Prem Prathi\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\ncontinued work on rlog, improvements\nprogcrypto sync with pse, presentation work - https://hackmd.io/wS2MAfSvSK-tnxzcriah9A\n\n\nadmin/misc\n\nsupporting DST, working on waku relay segfault, resolved\n\n\nsecure-channels:waku:ethereum-chat\n\nInclude some considerations on the extension to group chat revolving around asynchronous ratcheting trees.\nStart writing the raw version of the RFC.\nhttps://www.notion.so/WiP-Secure-Ethereum-Chat-f69ff155456c4fdeb719aba96fd7a\n\n\nzerokit:vac:maintenance\n\nprepared refactoring PR (https://github.com/vacp2p/zerokit/pull/219)\n\n\n\nvac:sc:: §\n\nstatus:community-curation-contracts\n\nAdjusted deploy script to mint mock SNT token on local node (this was needed for testing purposes)\n\nPR: https://github.com/status-im/community-dapp/pull/80\n\n\nFixed deployment script to ensure directory contracts are set in voting contracts\n\nhttps://github.com/status-im/community-dapp/pull/81\n\n\nFixed deployment that ensures Multicall2 is available on local nodes as well as references for production networks\n\nPR: https://github.com/status-im/community-dapp/pull/82\n\n\n\n\nvac:sc::status:snt-staking-contract_02\n\nImplement missing checks for staking lockup period\n\nPR: https://github.com/logos-co/staking/pull/39\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nResearching techniques for state separation and how to integrate different models.\nResearched and posted a document on Verkle tree.\nBegan research on ring signatures (DualRing and DualDory) (doc pending)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nPublished a new document about Proof Creation and Verification\n\n\nproofsystems:vac:benchmarks\n\nStarted a draft for an article (overleaf)\napplied feedback for the Nova-Scotia PR\nWrote the halo2 aggregation circuit (issues with testing, need more CPU power, will use DST server)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nScaled up execution of TEN multiple simultanesous torpush-validators with near zero attestation misses\nGathering measurements from other fleet nodes (blocked at)\n\n\nvalpriv:vac:tor-push-paper\n\nAdded more graphs, completed abstract, comparisons in the paper.\nStill reviewing new paper to incorporate https://www.research.ed.ac.uk/en/publications/on-the-anonymity-guarantees-of-anonymous-proof-of-stake-protocols\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nModified large message handling mechanism (outlined below) for GossipSub.\n\nNow we send large message to randomly selected (dlow-1) peers.\nRemaining peers get idontwant message\n\n\nMissed out nodes use iwant message to pull the missing large message\nApproximately 20-25% overall message reduction achieved and 1/2 RTT latency increased for approximately 5% nodes\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nStarted following discussions for current gossipsub improvement direcetions\n\n\nWriting the pseudocode and addressed comments from Nomos team (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\n\nResponded to questions raised in the high level protocol document (https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd) by the nomos team.\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nwaku usage rfc - https://github.com/vacp2p/rfc/pull/627\n\n\n"},"vac/updates/2023-10-30":{"title":"2023-10-30 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDebug a various problems and trying to make the E2E works.\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nhttps://github.com/status-im/nim-libp2p/pull/965\n\n\nnimlibp2p:vac:maintenance\n\nAdd arm64 support when running HP tests locally https://github.com/libp2p/test-plans/pull/311 and https://github.com/libp2p/rust-libp2p/pull/4687\nAdd Hole Punching to libp2p test-plans https://github.com/status-im/nim-libp2p/issues/966\nIsolated failing tests from “Daily workflow”; Full matrix is passing now, but a lot of work on failing tests ahead\n\nhttps://github.com/status-im/nim-libp2p/issues/972\nhttps://github.com/status-im/nim-libp2p/actions/runs/6663282955\n\n\nfixed code duplicity: https://github.com/status-im/nim-libp2p/pull/968\nFurther problems identified:\n\nDeprecated compiler options and code usages\nNo support for macos-arm64\nOutdated go-libp2p-daemon\n\n\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nFinish the Codex growth model and updated litepaper (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nFollowing up with recent code changes SC has made (@Martin)\nCoordinating setup of Snapshot space w/ Corey who is the owner (@Martin)\n\n\nvac:tke::nomos:economic-analysis\n\nResearching rewards for validators and delegators, evaluating new private PoS (0 or 1 stake weight design) w/ Marcin (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nMartin participating in Waku calls, follows ups on “ENS” type approach to Waku stake (@Martin)\n\n\n\nvac:dst: §\n\nwakurtosis:vac:rlog\n\nReview changes of last commits\nBuilt NWaku image to run new 600 nodes with no load simulations (https://ci.infra.status.im/job/nim-waku/job/docker-manual/69/)\n\n\nanalysis-shadow:waku:shadow-waku-relay-analysis\n\nWorked in basic simulation with 10K Waku nodes (Pub/Sub Node)\n\n\nanalysis:nomos:simulation-analysis\n\nThe analysis is stable/automated, the machine runs are stable/automated, but the simulation bug(s) still effect results. (The nomos team is working on it)\nsimulation runs cont’\n\n\neng-10ktool:vac:bandwidth-test:\n\nPush as many gossipsub nodes as deliver and deliver metrics, either by\n\nMultiple gossipsub nodes per POD\nPushing further number of PODs per node\n\n\nClean up how to run it in a single bash script\n\n\nadmin/misc\n\nRun simulations for zkvm team\n\n\nsoftware-testing:waku:test-plans\n\nAdded Interop tests section to all existing test plans. Ex: for filter\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAddressed and merged all open PRs\nFixed CI logs\nHelped reproduce, investigate and retest store cursor regression\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nStarted building the framework for nwaku <-> gowaku interop testing\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nStore tests\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 2 tests - were added to the branch chore(filterV2)-test-updates\nRefactored first batch of tests and closed related PR https://github.com/waku-org/go-waku/pull/811\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\nfinished progcrypto presentation - https://docs.google.com/presentation/d/1ZkiFVJ3jBalFwAzQVaYbWU9BiRb22-2k5xGIRd2jXvU/edit?usp=sharing\n\n\nadmin/misc:\n\nstart implementation plan on reinforced concrete hash function for zkhack\n\n\nsecure-channels:waku:ethereum-chat\n\nwork on RFC cont’\n\n\nzerokit:vac:maintenance\n\nfixed linting (https://github.com/vacp2p/zerokit/pull/219), merged PR\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nSet up multisig for our team\n\nhttps://www.notion.so/Smart-Contract-Dev-Multisig-Wallet-bdf448b8e1424e13a463e1268b2ec294\n\n\nCreated a bunch of screencasts\n\nhttps://www.notion.so/f24bc8154bfd4757989216dde0f50af0?v=eb8f6f301de94f4889ee6179d16eaf47\n\n\n\n\ncodex:review-codex-contracts\n\nHad a call with the codex team to discuss their marketplace system\n\nRecording: https://drive.google.com/file/d/16QfFpgucYjIvfq0CYVGuIjJ3p5fR5rD5/view\n\n\n\n\nstatus:SNT-optimism-bridge\n\nDeployed SNT on Optimism\n\nhttps://optimistic.etherscan.io/address/0x650AF3C15AF43dcB218406d30784416D64Cfb6B2\n\n\nSent a PR to add SNT to optimism’s superchain token list (and bridge)\n\nhttps://github.com/ethereum-optimism/ethereum-optimism.github.io/pull/559\n\n\n\n\nstatus:community-curation-contracts\n\nFixed a bug with how active voting rooms are being determined\n\nPR: https://github.com/status-im/community-dapp/pull/89\n\n\nAdd ownership capabilities to Directory contract\n\nhttps://github.com/status-im/community-dapp/pull/90\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nResearched techniques for harmonizing UTXO and based-account model for state separation. (Goal 1)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nResearched techniques for proof creation and verification for Nova. (Goal 3)\nReadings on zkVM and how to build from scratch\nUpdated Zotero with some papers and blog posts\nPreparing for Zk hack\nlook into KiloNova\ndrafting document comparing theoretical complexities of proof schemes we’ve examined (part of Nescience’s Goal 3).\n\n\nproofsystems:vac:benchmarks\n\nUpdated Nova Cricuit document\nMerged the Nova-Scotia PR\nGenerated srs for 28 and 27\nReduced the number of columns in the halo2 circut\nContinued testing of aggregation circuit\nCode Review for Nova-Bellman\nFinish Code Review for Poseidon-Starky\nProvide rough calculations for Halo2 SRS generations in discord.\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nShare the internal release of tor-push validators with team for buddy testing/aspre-alpha.\ncompared attestation misses of normal and torpush validators\n\n\nvalpriv:vac:tor-push-paper\n\nFixed abstract, intro, identified needed improvements for stats.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nAdded staggered message sending in GossipSub implementation.\nCarried out performance evaluations for staggered sending, reduced sending https://github.com/status-im/nim-libp2p/pull/969\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the unit tests and addressed comments from Nomos team(https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/test_carnot_vote_aggregation.py).\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nadded discovery usage to status-wakuv2-usage rfc - https://github.com/vacp2p/rfc/pull/627\n\n\n"},"vac/updates/2023-11-06":{"title":"2023-11-06 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\ncont. fixed segfault.\n\n\nnimlibp2p:vac:maintenance\n\nRevert https://github.com/status-im/nim-libp2p/issues/868\nfor Nimbus. A new libp2p branch was create for that https://github.com/status-im/nim-libp2p/tree/b2eac7e-and-revert-c6aa085 - https://github.com/status-im/nimbus-eth2/pull/5549\nnew Issue #975: CI workflow is failing frequently, https://github.com/status-im/nim-libp2p/issues/975, https://github.com/status-im/nim-libp2p/tree/fix/ci-workflow-stability\nin progress: PR #968: fix: move workflows for Nim Devel and legacy i386 from “Daily”\n\nnew workflows “Daily - Devel” and “Daily - Legacy Platforms” https://github.com/status-im/nim-libp2p/pull/968\nIssue #972: Daily workflow could fail randomly with [OSError] https://github.com/status-im/nim-libp2p/issues/972\n\n\n\n\n\nvac:tke: §\n\nadmin/misc: (7 CC conference days)\nvac:tke::status:SNT-staking\n\nFinalizing the setup & shape of Snapshot space (@Martin)\n\n\nvac:tke::nomos:economic-analysis\n\nResearching properties of rewards functions (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nPreparing an overview of possible revenue models (@Martin)\nMonitoring Sergei’s research (@Martin)\n\n\n\nvac:dst: §\n\nwakurtosis:vac:retrospective-rlog\n\nReviewed comments; soon to publish\n\n\nwakurtosis:vac:rlog\n\nAnalysis of new Wakurtosis simulations regarding the 600 nodes anomaly\nAnalysis of K8 simulations regarding the 600 nodes anomaly\n\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nworked on Topology slices\n(added more RAM to the server)\n\n\nanalysis-shadow:waku:shadow-waku-relay-analysis\n\nRun 600 nodes NWaku Shadow simulations with and without load\n\n\nanalysis:nomos:simulation-analysis\n\nThe network delay/bandwidth tuning, readjusting the probabilities, none of them helped. The bug(s) cannot be side-steped in any meaningful way.\nNew issue: for > 10 views, the disk usage blows up. 1.7 TERABYTES; and the output is just text files! This was quite unexpected; we now have yet another scalability issue with the nomos sim.\nspent couple of days on the Rust code and worked on adjustments. None of them helped with the bug.\n\n\nanalysis-gsub-model:vac:refactoring\n\nTuned/cleanedup to the control messages code\n\n\neng-10ktool:vac:bandwidth-test:\n\nMachines are no longer blocked\nAdded Kubernetes network policies to void having machines blocked.\n600 node simulations with Kubernetes to try to replicate 0 rate anomaly\nStarted an aproximation of waku-simulator with Kurtosis\nMeeting with Slava to investigate prometheus dropping container labeling information\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nHelped Danish with implementing the testing part of a Static Sharding PR\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nFirst PR:\n\nstart/stop waku docker nodes and connect them in a network\nsend RPC or REST API calls and validate that messages are reaching the peers\nsetup ci runs (on pr, on demand and nightly) via github actions\nallure reports via github pages that contain test and docker log attachments for failing tests\nautomated linting and code formatting\n2 basic tests for now but will extend after the initial set of reviews\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nMoved most of the PRs, missing one.\nImplement some store tests.\nFound (and fixed) issue with default values encoding/decoding for HistoryQuery.\nbug: assert false SEGFAULT.\n\nIt only triggers on some files, and imports don’t seem to be related.\n\n\nbug: Stopped filter node can receive messages\n\nIt’s actually expected behaviour.\nIssue\n\n\nbug: Filter doesn’t receive messages after subscribing and restarting\n\nIssue\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 4 tests related to filter unsubscribe and closed the PR https://github.com/waku-org/go-waku/pull/855\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\nMake changes as per review on rlog\n\n\nadmin/misc\n\nStudy the research paper on the Reinforced Concrete hash function.\nImplemented Reinforced concrete in huff - https://github.com/rymnc/reinforced-concrete-huff\n\ntl;dr: lesser gas consumed than poseidon (2 inputs)\n\n\nRC hash writeup on vacp2p/research - https://github.com/vacp2p/research/pull/196\n\n\nsecure-channels:waku:ethereum-chat\n\nKeep working on the comments from the team and finish the raw RFC.\nhttps://github.com/vacp2p/rfc/pull/626\n\n\n\nvac:sc:: §\n\nstatus:community-curation-contracts\n\nAdjusted import remappings\n\nhttps://github.com/status-im/community-dapp/pull/95\n\n\nAdded Goerli OP deployment config\n\nhttps://github.com/status-im/community-dapp/pull/96\n\n\nDeployed contracts on Goerli OP\nVerified contracts on OP Mainnet\n\n\nvac:maintainance/misc\n\nDeployed OP SNT on Goerli OP\nCreated a few screen casts on deployment\n\nhttps://www.notion.so/f24bc8154bfd4757989216dde0f50af0?v=eb8f6f301de94f4889ee6179d16eaf47\n\n\nImplemented SNT V2 which will be used to make SNT available on Sepolia\n\nhttps://github.com/status-im/status-network-token-v2/pull/1\n\n\n\n\ncodex:review-codex-contracts\n\nfinished watching the call recording\nreviewed the code again based on the knoledge from call\nsent PRs based on our review\nhttps://github.com/codex-storage/codex-contracts-eth/pull/73\nhttps://github.com/codex-storage/codex-contracts-eth/pull/74\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nKeep researching techniques for harmonizing UTXO and based-account model for state separation -> Model to model adapter (Goal 1)\nPrivacy-enhancing: Prepare document comparing Dory and IPA polynomial commitment schemes.\nResearch ring signatures that use Dory and IPA.\n\n\nproofsystems:vac:research-existing-proof-systems\n\nResearching techniques for proof creation and verification for Nova. (Goal 3)\nMore readings on zkVM and how to build from scratch\nPreparing for Zk hack\nDone slides for ProgCrypto\nPreparing a summary of a zk-Benchmark paper\n\n\nproofsystems:vac:benchmarks\n\nReviewed Starky implementation\nReviewed Nova implementation\nMerged the Nova-Bellman PR (https://github.com/vacp2p/zk-explorations/pull/14)\nMerged the posiedon-starky PR (https://github.com/vacp2p/zk-explorations/pull/16)\nReduced the number of columns in the halo2 circut\nSuccessfully ran shplonk implementation of poseidon halo2 circuit\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nInvestigated, drove measurements from other fleet nodes for latency\nGot testbed results with 10 validators, comparing and adding\n\n\nvalpriv:vac:tor-push-paper\n\nAdding scaled up execution results, revise discussion\nrevised presentation\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nCompleted small-scale simulations for large message handling\nCreated an updated PR for shadow simulation scripts https://github.com/vacp2p/dst-gossipsub-test-node/pull/3\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nCompiled things, revisited documents, and worked on presentation for logos research call on GossipSub Improvements\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nAdded the pull request for 71/STATUS-Push-Notification-Server https://github.com/vacp2p/rfc/pull/629/files (still WiP)\n\n\n"},"vac/updates/2023-11-13":{"title":"2023-11-13 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nDive into the Yamux/Relayv2 problem - https://github.com/status-im/nim-libp2p/pull/979\n\n\nnimlibp2p:vac:maintenance\n\nAdd Hole Punching to libp2p test-plans https://github.com/status-im/nim-libp2p/issues/966 and https://github.com/libp2p/test-plans/pull/322\nYamux doesn’t work in a Relayv2 connection https://github.com/status-im/nim-libp2p/pull/\nSingle-board computer (SBC) support https://github.com/status-im/nim-libp2p/issues/978\nARM64/aarch64 support https://github.com/status-im/nim-libp2p/issues/980\nTest Plans repo fork updated and resources to run tests requested https://github.com/status-im/libp2p-test-plans\nImplementing Nimble lock file functionality https://github.com/status-im/nim-libp2p/issues/975 https://github.com/status-im/nim-libp2p/tree/fix/ci-workflow-stability\nfix: move workflows for Nim Devel and legacy i386 from “Daily” -> workflows renamed to “Nim Devel” and “Legacy Platforms” https://github.com/status-im/nim-libp2p/pull/968\nDaily workflow could fail randomly with [OSError] https://github.com/status-im/nim-libp2p/issues/972\n\n\nnimlibp2p:vac:webrtc-transport\n\nFix read/write on the DTLS\nRetrieve the remote certificate\nStart creating a way to log packets behind the DTLS encryption into pcap file in order to make it readable with wireshark\nWebRTC is done. WebRTC for libp2p isn’t:\n\nchrome://webrtc-internals/ show no errors, neither wireshark.\nBut libp2p spec requires a weird handshake that I haven’t finished yet\n\n\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nMeeting with Codex on token allocation (@Matty)\nReview Codex modeling and litepaper with Codex (all)\nOne-pager draft requested by Matt Nemer for fundraising purposes (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nManaging snaphot for Status go-live this week (@Martin)\nReviewing and updating Cyprien’s governance proposal draft (all)\nStatus growth modeling followup discussion (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nContinuing research of PoS economics and token distributions (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nMonitoring Sergei’s research (@Martin)\nWaku growth monitoring (@Martin)\n\n\n\nvac:dst: §\n\nwakurtosis:waku:gossipsub-topology-analysis\n\nGenerated shadow simulation topology slices\n\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nRun 35K nodes simulation in shadow with low traffic\nImplemented constant traffic in the node\n\n\nanalysis:nomos:simulation-analysis\n\nsync with Moh and Nomos\nNomos sim team now has eveything to reproduce and fix the bug: exact configs and access to full runs\nSuggested improvements to the data output that will reduce both the memory and disk overload of nomos simulation by orders of magnitude. Moh and Gusto agree that this will work.\nWrapped up the nomos analysis for now: waiting for the sims team to finish fixing the bugs\n\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nWrote an analysis script that can read graphs generated by Shadow runs\n\n\nanalysis-gsub-model:status:control-messages\n\nstarted write up on old and new Waku-models\n\n\neng-10ktool:vac:bandwidth-test:\n\nAdd publishing waku messages with Kubernetes\nTried to fix Prometheus labeling\nKeep investigating 0 rate anomaly with Kubernetes\nMeet with Florin to talk about tool repositories\nRan 4.5k waku nodes with no traffic\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nMerged 1st PR\nDraft 2nd PR:\n\nadd more tests (17 ATOW)\nframework improvements and adjustments as the number of tests increase\n\n\ngowaku issues found:\n\nfailures with relay get-messages API\nresponse message contains extra redundant fields compared with what is published\nREST API HTTP 500 Internal Server Error when publishing messages\nDocker DEBUG logs floaded in certain conditions\n\n\nnwaku issue found : container crashes when a message is published with malformed timestamp\nrest-api-specs issue found: missing fields in the REST API schema\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nUpdated last PR, missing reviewer responses.\nInvestigating assert false: Ivan took charge of that task; found it doesn’t happen anymore (will write notes on the issue to resume investigation later)\nPicking up pace with store tests.\nInvestigate a PEER_DIAL_FAILURE error in store; Happens when archive isn’t mounted (unexpected); Not yet reported.\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 2 tests related to filter unsubscribe all https://github.com/waku-org/go-waku/pull/875\nWrote string generator functions for tests with variable data https://github.com/waku-org/go-waku/pull/879\n\n\n\nvac:acz: §\n\nadmin/misc\n\n@ devconnect, participated in zk-hack, submitted https://devfolio.co/projects/reinforced-concrete-implementations-e82e, won a bounty from polygon\nupdated rln to use RC, significantly lower constraints, we can potentially bring down proof generation ti\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nvac blog post: https://vac.dev/rlog/rln-anonymous-dos-prevention/\n\n\nsecure-channels:waku:ethereum-chat\n\nImproving the raw RFC by writing it in terms of Noise, including: X3DH. XEdDSA. Double Ratchet. ADKG. https://github.com/vacp2p/rfc/tree/ethsecpm_improvements\n\n\nrlnp2p:waku:multi-epoch-constraints\n\nKeep working on the multi-constrained epoch project.\n\n\nzerokit:vac:maintenance\n\nmerged PR 220\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nRecorded new screen casts\nStarted working on presentation for Research Call\nmostly working in the Discover bug\ncontacted dapp deployer\nstarted a postmortem that I’m updating\njust exported a full list of dapps and contact\n\n\nstatus:governance-contract-mvp\n\nreseach and development; proposal types\nimplemented delegation\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nStill researching techniques for harmonizing UTXO and based-account model for state separation (delays due to Istanbul trip)\nResearch for privacy enhancing (from state separation document): ring signatures (Dory, IPA) assuming Nova.\nFor Flexibility Operation: researching Verkle trees implementation in other blockchains.\nDrafting document for privacy enhancing.\n\n\nproofsystems:vac:research-existing-proof-systems\n\nResearching techniques for proof creation and verification for Nova. (Goal 3)\nPreparing for Zk hack\nPreparing for ProgCrypto\n\n\nproofsystems:vac:benchmarks\n\nWrote a GWC implementation of poseidon circuit for halo2\nSuccessfully ran GWC implementation of poseidon halo2 circuit\nResearched GPU halo2 enhancement for our own possible use (https://github.com/kroma-network/tachyon/tree/main/vendors/halo2)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nGot separate measurements for aggregate vs attestation, Pushed all duties’ broadcasts on tor.\nManaged to get libp2p logs from other nimbus fleet machine. Large files, need to process them\n\n\nvalpriv:vac:tor-push-paper\n\nReady to share the paper. Finishing adding new results\nUpdating presentations, simplifying the slides.\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nrevisited documents, and worked on presentation for logos research call on GossipSub Improvements.\nBased on the feedback from the logos research call, revisited nim-libp2p documentation, codebase etc.\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nStarted revisiting the GossipSub improvement paper to reflect current work and finalize writeup (Still work in progress. will need 1-2 more days to reflect in overleaf document).\nRequested the DST team for initial simulation. I intend to use the outcomes to finalize test patterns.\npublished Vac blog post: https://vac.dev/rlog/GossipSub%20Improvements/\n\n\nzk:codex:storage-proofs-open-problems-review\n\nReview Groth16 notes for Codex\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nRemoved mailserver from 71/STATUS-PUSH-NOTIFICATION RFC https://github.com/vacp2p/rfc/pull/629\nAdded references to 71/STATUS-PUSH-NOTIFICATION RFC https://github.com/vacp2p/rfc/pull/629\nDid first read of 10/WAKU-USAGE looking for improvements\n\n\nwaku:waku-keystore\n\nCreated outline\nCreated draft pull request - https://github.com/vacp2p/rfc/pull/631\n\n\n"},"vac/updates/2023-11-20":{"title":"2023-11-20 Vac weekly","links":[],"tags":["vac-updates"],"content":"Publicly Engaging Highlights §\n\npresentations @ Progcrypto https://progcrypto.org/ on\n\nRLN\nValidator Privacy\nNescience\n\n\n\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nAdd Hole Punching to libp2p test-plans - https://github.com/status-im/nim-libp2p/issues/966 and https://github.com/libp2p/test-plans/pull/322\nfix: remove unittest2 range - https://github.com/status-im/nim-libp2p/pull/986\nfix: doc workflow - https://github.com/status-im/nim-libp2p/pull/985\nfix(dcutr): make the dcutr client inbound and the server outbound - https://github.com/status-im/nim-libp2p/pull/983\nfix(interop-tests): don’t hardcode x86_64 for native - https://github.com/libp2p/rust-libp2p/pull/4862\nconflicting dependency resolution - https://github.com/nim-lang/nimble/issues/116\nimplementing Yamux update window: https://github.com/status-im/nim-libp2p/pull/987\nResearch VM hosting providers - to execute perf tests https://docs.google.com/spreadsheets/d/1VL6QpDdBgYC1Ld0Nr-cpNv9bRht3nQkBQUF1pNerBDs/edit?usp=sharing\nworking on several CI issues\n\nTesting Nimble lock file - deps download consistent across platforms; https://github.com/status-im/nim-libp2p/issues/975\nfix: move workflows for Nim Devel and legacy i386 from “Daily” -> workflows renamed to “Nim Devel” and “Legacy Platforms” https://github.com/status-im/nim-libp2p/pull/968\nDaily workflow could fail randomly with [OSError] https://github.com/status-im/nim-libp2p/issues/972\n\n\n\n\nnimlibp2p:vac:webrtc-transport\n\nLog decyphered packet\n\nFailing to directly write a pcap file (it’s far more complicated than it looks)\nFailing to use the SSLKEYLOGFILE interaction between browser & wireshark\nStart writing a self-made logger to understand where it fails\n\n\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nFinish litepaper edits from Frederico and Martin review\nPing Codex on litepaper, followup discussion (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nConfirm with Agata on responses to the governance forum posts (@Matty)\nMeet w/ John to plan out next steps post-website launch\n\n\nvac:tke::nomos:economic-analysis\n\nContinuing research of PoS economics and token distributions, participating in Nomos offsite discussions (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nDevConnect and Waku offsite (@Martin)\nResearching EigenTrust use for Waku reputation system (@Matty)\n\n\n\nvac:dst: §\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\ncont’ with various simulation runs; does not scale to larger message sizes because of RAM limit (a burst of nine 500KB msgs, 500 nodes was too much for 256GB RAM)\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nAddressed review comments and merged 2nd PR to reach 27 tests for relay publish\n\nDraft 3rd PR:\nmake framework support dynamic number of nodes\n\nadd multi-node tests (that work on any number of nodes)\n\n\n\n\nMultiple issues found:\n\ngowaku:\n\n2 regressions (container sometimes crashes + log spam) on lastest master\nREST API error handling discrepancies\n\n\nnwaku:\n\nREST API request fails if request contains meta or rate_limit_proof fields\n\n\nrest-api-specs: missing fields in the REST API schema\n\n\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAdd summary with link to report to the js-waku CI test job\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nPR Train Merged\n\nPR 2085\nPR 2095\nPR 2096\nPR 2101\nPR 2138\n\n\nFix compilation and tests failing after PR train\n\nPR 2222\nPR 2224\n\n\nImplementing store tests\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 7 tests related to filter push - valid data https://github.com/waku-org/go-waku/pull/904\nTest fixes to extend message timeout https://github.com/waku-org/go-waku/pull/911\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\npresented RLN @ Progcrypto\n\n\nsecure-channels:waku:ethereum-chat\n\nWorked towards moving the algorithms involved in the Ethereum chat to Noise terms. In particular: XEdDSA and DR.\nStart working on ADKG. https://www.notion.so/WiP-ADKG-e83e24612abc41a7bf292e96660ab833\n\n\nzerokit:vac:maintenance\n\nfixed nightly zerokit build failure\nmerged PR 223 (https://github.com/vacp2p/zerokit/pull/223)\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nReview Certora PR for OP SNT repository\n\n\nstatus:community-contracts-maintenance\n\nRedeployed contracts to Goerli for updated version https://github.com/status-im/communities-contracts/pull/23\nDeployed contracts to Arbitrum Goerli and Arbitrum Sepolia\nVerified contracts on Sepolia\n\n\nstatus:token-import\n\nstarted working on the Vault contract\n\n\n\nvac:nescience: §\n\nproofsystems:vac:benchmarks\n\npresent Nescience @ progcrypto\nPrepared a PR for a GWC implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/17\nPrepared a PR for a SHPLONK implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/18\n\n\nstate-separation:vac:state-separation-doc\n\nResearch mimblewimble (part of enhanced privacy)\nResearch verkle trees specific to kzg and ipa (part of flexibility in operations, and joint with Codex’s future needs)\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted the GossipSub improvements paper, with the exception of the results and discussion part. Reflected the feedback and current works as well.\n\n\nvalpriv:vac:tor-push-poc\n\ntalk @progcrypto\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nUpdated 71/STATUS-PUSH-NOTIFICATION RFC https://github.com/vacp2p/rfc/pull/629\n\n\nwaku:waku-keystore\n\nUpdated draft - https://github.com/vacp2p/rfc/pull/631\n\n\n"},"waku/index":{"title":"Waku Roadmap","links":["waku/monthly-reports/2023-sept","waku/milestones-overview","tags/waku-updates","waku/reports"],"tags":["waku-roadmap","overview"],"content":"Welcome to the Waku Roadmap Overview\nWaku is a family of robust, censorship-resistant communication protocols designed to enable privacy-focused messaging for Web3 apps. To learn more please visit the website and docs.\n\n2023 September Report\nMilestones\nWeekly updates\nReports\n"},"waku/milestone-waku-10-users":{"title":"Milestone: Waku Network supports 10k Users","links":[],"tags":[],"content":"%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Scaling\n\t\t10k Users :done, 2023-01-20, 2023-07-31\n\nCompletion Deliverable §\nTBD\nEpics §\n\nGithub Issue Tracker\n"},"waku/milestones-overview":{"title":"Waku Milestones Overview","links":[],"tags":[],"content":"Milestone: Waku Network can Support 1 Million Users §\nLink: https://github.com/waku-org/pm/milestone/4\nDue by: 2023-11-30\nEpic: Cater for professional operators (Status Communities)\n\n\nLink: https://github.com/waku-org/pm/issues/92\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1929\n\n\nhttps://github.com/fryorcraken/milestone-update/\n\n\nEpic: Simulation with 10k nodes\n\n\nLink: https://github.com/waku-org/pm/issues/85\n\n\nIssues in Epic:\n\n\nhttps://github.com/vacp2p/research/issues/191\n\n\nEpic: PostgreSQL in service node: Further optimisations\n\n\nLink: https://github.com/waku-org/pm/issues/84\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1894\n\n\nhttps://github.com/waku-org/nwaku/issues/1893\n\n\nhttps://github.com/waku-org/nwaku/issues/1888\n\n\nhttps://github.com/waku-org/nwaku/issues/1885\n\n\nhttps://github.com/waku-org/nwaku/issues/1842\n\n\nhttps://github.com/waku-org/nwaku/issues/1841\n\n\nhttps://github.com/waku-org/nwaku/issues/1840\n\n\nhttps://github.com/waku-org/nwaku/issues/1604\n\n\nMilestone: Waku Network Gen 0 §\nLink: https://github.com/waku-org/pm/milestone/1\nDue by: 2023-12-01\nEpic: 3.4: Production and memberships on mainnet\n\n\nLink: https://github.com/waku-org/pm/issues/87\n\n\nNo issues in Epic description.\n\n\nEpic: 3.4: Further memberships\n\n\nLink: https://github.com/waku-org/pm/issues/72\n\n\nNo issues in Epic description.\n\n\nEpic: 3.3: Membership for Status Communities\n\n\nLink: https://github.com/waku-org/pm/issues/71\n\n\nNo issues in Epic description.\n\n\nEpic: 3.2: Basic DoS protection in production\n\n\nLink: https://github.com/waku-org/pm/issues/70\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/go-waku/issues/732\n\n\nhttps://github.com/waku-org/go-waku/issues/731\n\n\nhttps://github.com/waku-org/go-waku/issues/655\n\n\nEpic: 1.5: Launch and dogfood integrated public Waku Network MVP\n\n\nLink: https://github.com/waku-org/pm/issues/68\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/research/issues/1\n\n\nEpic: 1.4: Sharded peer management and discovery\n\n\nLink: https://github.com/waku-org/pm/issues/67\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1941\n\n\nhttps://github.com/waku-org/nwaku/issues/1940\n\n\nhttps://github.com/waku-org/js-waku/issues/1505\n\n\nhttps://github.com/waku-org/js-waku/issues/1504\n\n\nhttps://github.com/waku-org/go-waku/issues/727\n\n\nhttps://github.com/waku-org/go-waku/issues/680\n\n\nhttps://github.com/waku-org/go-waku/issues/679\n\n\nhttps://github.com/waku-org/go-waku/issues/678\n\n\nEpic: 1.3: Node bandwidth management mechanism\n\n\nLink: https://github.com/waku-org/pm/issues/66\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1947\n\n\nhttps://github.com/waku-org/nwaku/issues/1946\n\n\nhttps://github.com/waku-org/nwaku/issues/1945\n\n\nhttps://github.com/waku-org/nwaku/issues/1938\n\n\nhttps://github.com/waku-org/js-waku/issues/1503\n\n\nhttps://github.com/waku-org/go-waku/issues/677\n\n\nEpic: 1.2: Autosharding for autoscaling\n\n\nLink: https://github.com/waku-org/pm/issues/65\n\n\nNo issues in Epic description.\n\n\nEpic: 2.3: Basic distributed Store services\n\n\nLink: https://github.com/waku-org/pm/issues/64\n\n\nNo issues in Epic description.\n\n\nEpic: 2.2: Sharded capability discovery for light protocols\n\n\nLink: https://github.com/waku-org/pm/issues/63\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/js-waku/issues/1506\n\n\nEpic: 2.1: Production testing of existing protocols\n\n\nLink: https://github.com/waku-org/pm/issues/49\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1950\n\n\nhttps://github.com/waku-org/nwaku/issues/1948\n\n\nhttps://github.com/waku-org/nwaku/issues/1888\n\n\nhttps://github.com/waku-org/js-waku/issues/1463\n\n\nhttps://github.com/waku-org/js-waku/issues/914\n\n\nEpic: Dogfood RLN in production\n\n\nLink: https://github.com/waku-org/pm/issues/51\n\n\nNo issues in Epic description.\n\n\nEpic: Open membership mechanism\n\n\nLink: https://github.com/waku-org/pm/issues/52\n\n\nNo issues in Epic description.\n\n\nEpic: RLN validation in production\n\n\nLink: https://github.com/waku-org/pm/issues/55\n\n\nNo issues in Epic description.\n\n\nEpic: Autosharding - dogfooding\n\n\nLink: https://github.com/waku-org/pm/issues/58\n\n\nNo issues in Epic description.\n\n\nMilestone: Quality Assurance processes are in place §\n-Link: https://github.com/waku-org/pm/milestone/3\nDue by: 2024-03-31\nEpic: Comprehensive Dev Testing\n\n\nLink: https://github.com/waku-org/pm/issues/90\n\n\nIssues in Epic:\n\n\nhttps://github.com/fryorcraken/milestone-update/\n\n\nhttps://github.com/waku-org/js-waku/issues/1589\n\n\nhttps://github.com/waku-org/js-waku/issues/1435\n\n\nhttps://github.com/waku-org/js-waku/issues/337\n\n\nhttps://github.com/waku-org/js-waku/issues/1595\n\n\nhttps://github.com/waku-org/js-waku/issues/1597\n\n\nEpic: Automated Release processes\n\n\nLink: https://github.com/waku-org/pm/issues/86\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1889\n\n\nhttps://github.com/waku-org/js-waku/issues/1543\n\n\nhttps://github.com/waku-org/waku-rust-bindings/issues/67\n\n\nEpic: End-to-end testing\n\n\nLink: https://github.com/waku-org/pm/issues/34\n\n\nIssues in Epic:\n\n\nhttps://notes.status.im/s/iylE6wdli#\n\n\nhttps://github.com/waku-org/go-waku/issues/608\n\n\nMilestone: Support Many Platforms §\nLink: https://github.com/waku-org/pm/milestone/2\nDue by: 2024-04-30\nEpic: Ship RLN as part of non-native SDKs\n\n\nLink: https://github.com/waku-org/pm/issues/88\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/go-zerokit-rln/issues/5\n\n\nhttps://github.com/waku-org/go-waku/issues/732\n\n\nhttps://github.com/waku-org/nwaku/issues/2033\n\n\nhttps://github.com/fryorcraken/milestone-update/\n\n\nEpic: REST API service node\n\n\nLink: https://github.com/waku-org/pm/issues/82\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1988\n\n\nhttps://github.com/waku-org/nwaku/issues/1985\n\n\nhttps://github.com/waku-org/nwaku/issues/1910\n\n\nhttps://github.com/waku-org/nwaku/issues/1909\n\n\nhttps://github.com/waku-org/nwaku/issues/1872\n\n\nhttps://github.com/waku-org/nwaku/issues/1652\n\n\nhttps://github.com/waku-org/nwaku/issues/1214\n\n\nhttps://github.com/waku-org/nwaku/issues/1076\n\n\nhttps://github.com/waku-org/nwaku/issues/938\n\n\nhttps://github.com/waku-org/go-waku/issues/264\n\n\nEpic: NodeJS Library\n\n\nLink: https://github.com/waku-org/pm/issues/81\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1332\n\n"},"waku/monthly-reports/2023-sept":{"title":"2023 September Monthly Waku Report","links":["vac/dst/","vac/dst/wakurtosis/vac/retrospective-rlog","waku/updates/2023-09-04","waku/updates/2023-09-11","waku/updates/2023-09-18","waku/updates/2023-09-25"],"tags":["monthly-report","waku"],"content":"Executive Summary §\nThe month of September saw an agreement and solidification of the Waku roadmap which defines the process of launching the Waku Network as an independent piece of infrastructure the broader ecosystem can rely upon. Along with this, a revamp of the process in which work is labeled and tracked was performed which has an automated part and is generally more in line with the requests from the Insights team.\nWork continues in the scaling and productionization efforts across the clients. Work previously done to enables PostgreSQL engine for WAKU-STORE in nwaku is being locally stress tested, further stress test using dev fleet is expected to be finalized next month. A Waku static sharding strategy is being integrated into Status to accommodate the first growth milestones of the re-release and adaptive sharding research and implementation is close behind.\nLocal simulation of RLN-RELAY has enabled the discovery of minor bugs which are fixed in the latest release of zerokit and nwaku and the study of the affect of RLN on performance.\nKurtosis as a platform was found to be insufficient for modeling a Waku network at the scale we wish, and the Vac team is pursuing an alternative strategy and writing up learnings from the boundaries were able to push.\nQuality Assurance practices are scheduled throughout the next year to keep all client implementations up to a threshold of continuous quality.\nThe process to add native integration APIs to nwaku is underway such that the default native library moves from go-waku to nwaku.\nKey Updates §\nPersonnel §\n\naddition of\n\nAaron as Project Manager\nSergei as Researcher\nGabriel as nwaku Engineer\n\n\nSeveral Jobs Descriptions have been reviewed this month to be opened shortly:\n\nGrowth Lead/Marketing strategist to drive Waku’s growth and liaise with Comms Hubs\nBusiness Development Lead, to further develop partnership with ecosystem projects\nSolution Engineer, to provide technical support to projects integrating Waku\n\n\nA core contributor to lead the Waku Chat SDK team has been secured, with start date in November.\n\nMilestones §\nA lot of work has been put into coalescing and finalizing the development tracking process that is in line with the Insight Reporting requirements, and Aaron’s addition to the team this month as pushed it over the edge to completion. Much of this has gone into automating the weekly reporting process via GitHub labels and comments on issues.\nFor tracking Waku maintains these Milestones in the waku-org/pm repo. Within each milestone description, you’ll find the corresponding Epics. Every Epic is distinctly labeled, and this label is affixed to each issue associated with that particular Epic. The labels are managed by the labels.yaml file located in the waku-org/pm repo.\nGiven the expansive nature of Waku and its various repositories working towards the milestones, the labels established in the labels.yaml file are replicated across each respective waku-org repo. This structure allows for seamless navigation, starting from top-level milestones down to the most granular issues.\nWaku is broken out into the following four Milestones, with Epics associated with them:\n\nWaku Network Gen0\nWaku Network Can Support 1MM Users\nQuality Assurace Processes in Place\nSupport Many Platforms\n\nMore details on the structure and progress of all Waku work can be tracked in their PM repository, specifically the milestone page. The following sections are highlighted updates on what happened this month.\nWaku Network Gen0 §\nThe Waku Network RFC was created and published on Vac as RAW which details the ideas and architecture of the Waku Network. The next version of RLN was also published on Vac as RAW.\nA benchmark of RLN was conducted and the results were discussed in a Logos Research Call presentation (See waku-org/research#23 for details). The tl;dr is copied here for convenience:\n\n\n \n TLDR: \n \n \n\nProof generation is constant-ish. 0.15 second for each proof\nProof verification is constant-ish, 0.012 seconds. In a network with 10k nodes and D=6 this would add an overhead delay of 0.06 seconds.\nGossipsub scoring drops connections from spammer peers, which acts as the punishment (instead of slashing). Validated in the simulation.\nRLN doesn’t have any impact on memory consumption.\n\n\nBased on these two specification publications and other associated work, efforts have begun to launch the first dev-testnet in time for the DevConnect event in November 2023.\nAll launch critical work for autosharding has been done in terms of RFC and nwaku.\nWaku Network Can Support 1MM Users §\nSignificant work was completed on the PostgreSQL integration and setup within nwaku, which supports the data retention and retrieval of Waku archival nodes. The implementation is currently being stress-tested to ensure production performance metrics are met.\nThe efforts in simulating a Waku Network of 10k users within a single shard continues and is tracked within Vac DST Roadmap. The performance of Wakurtosis (Kurtosis backend) was found to be insufficient for our requirements for scaling simulations. The creation of a Kubernetes orchestration tool, written in Python, has begun construction. This tool is heavily architected to mimic what Codex has created. It was chosen to reproduce this tooling in Python in order to increase usability and ease of maintenance/contribution as C# is a less known language within the org. The reasoning for this development can be tracked in retrospective-rlog.\nThe effort to understand a “professional Waku node operator” has begun and initial notes can be tracked within this minutes doc.\nA “static sharding” fleet was setup to test sharding and PostgreSQL by Waku team.\nSetup of a similar fleet dedicated to Status Communities is in progress (the first fleet may be used in the interim).\nQuality Assurance Processes in Place §\nThis milestone was created to ensure preparedness for the upcoming production client needs (specifically Waku Network Gen0 and Status Communities). A list of required processes in place was constructed and tasked out so that all implementations of Waku go through a standardized production release cycle.\nThis work is coordinating with the new Vac DST additions focused on testing rubrics for Logos Projects. This milestone is expected to be completed by Q1 2024.\nWork has started to use the js-waku CI as an integration test suite for nwaku and go-waku. This test suite can now easily be run for either client as part of their release process.\nSupport Many Platforms §\nThis is a large milestone created last month that tracks Waku’s “integration landscape” and attempting to ensure any developer seamlessly is able to integrate Waku.\nIt has started to list the work required for completion but more detail is needed to be fleshed out on prioritization and estimated resource needs. Currently, it is slotted for completion by April 2024.\nMuch of the work this month was fleshing out the available REST APIs of nwaku.\nA poll was created to query what language priority we should have was gone. They’ll be published on socials next month to boost engagement and feedback. This poll will assist with priorities for this milestone.\nPerceived Changes in Project Risk §\n\nWaku doing most integration of Waku into status-go consumes a lot of Go-related developer resources.\n\na list of needed work is tracked here\n\n\nThere effort to convert nwaku to the main native integration client requires a large effort in the implementations of C-bindings in Nim and has some unknowns associated with it. Furthermore this additional effort and uncertainty doesn’t directly contribute to the current critical path of development.\nThe first main application of the milestone reorganization within the project has made the milestones associated with it clear, thus allowing the Waku Network MVP target setup to be tracked well\n\nFuture Improvement Plans §\nInsight §\nThe insight team plans to further evaluate the value the reporting process implemented by Waku as it pertains to use within the other projects under Logos. It is expected that next month it will be finalized and ready for review by other teams to see if they’d like to adopt it.\nOne side effect of the automated reporting process is that the associate issue labels are already compatible with our data lake ingestion that was initiated by the Status project. This will allow us to create more useful dashboards and monitoring that take into account accurate development activity.\nProject §\nAs the milestones continue to be fleshed out and detailed, the ability to show progress over time will improve.\nSources and Useful Links §\nWeekly Reports\n\n2023-09-04\n2023-09-11\n2023-09-18\n2023-09-25\n"},"waku/reports":{"title":"Waku Reporting","links":[],"tags":["wakureporting"],"content":"Meetings and Weekly Updates §\nHigh level reporting overview §\n\nDaily standups are posted in the team discord.\nWeekly progress reports are submitted as comments on open issues in any public waku-org github repository. A script compiles the relevant comments and prepares for publication.\n\nWeekly updates pertaining to progress made toward active Epics and Milestones can be found here.\n\n\nMonday all-team PM meetings are held three times to accommodate all time zones.\nWaku client-team PM meetings are held throughout the week depending on the general timezone and schedules of the team.\nWeekly highlights are derived from the weekly dev updates and compiled for publication by the Comms team via the “Waku Wednesday” series on X.\n\n"},"waku/updates/2023-07-24":{"title":"2023-07-24 Waku weekly","links":[],"tags":["waku-updates"],"content":"Disclaimer: First attempt playing with the format. Incomplete as not everyone is back and we are still adjusting the milestones.\n\nDocs §\nMilestone: Foundation for Waku docs (done) §\nachieved: §\n\noverall layout\nconcept docs\ncommunity/showcase pages\n\nMilestone: Foundation for node operator docs (done) §\nachieved: §\n\nnodes overview page\nguide for running nwaku (binaries, source, docker)\npeer discovery config guide\nreference docs for config methods and options\n\nMilestone: Foundation for js-waku docs §\nachieved: §\n\njs-waku overview + installation guide\nlightpush + filter guide\nstore guide\n@waku/create-app guide\n\nnext: §\n\nimprove @waku/react guide\n\nblocker: §\n\npolyfills issue with js-waku\n\nMilestone: Docs general improvement/incorporating feedback (continuous) §\nMilestone: Running nwaku in the cloud §\nMilestone: Add Waku guide to learnweb3.io §\nMilestone: Encryption docs for js-waku §\nMilestone: Advanced node operator doc (postgres, WSS, monitoring, common config) §\nMilestone: Foundation for go-waku docs §\nMilestone: Foundation for rust-waku-bindings docs §\nMilestone: Waku architecture docs §\nMilestone: Waku detailed roadmap and milestones §\nMilestone: Explain RLN §\n\nEco Dev (WIP) §\nMilestone: EthCC Logos side event organisation (done) §\nMilestone: Community Growth §\nachieved: §\n\nWrote several bounties, improved template; setup onboarding flow in Discord.\n\nnext: §\n\nReview template, publish on GitHub\n\nMilestone: Business Development (continuous) §\nachieved: §\n\nDiscussions with various leads in EthCC\n\nnext: §\n\nBooking calls with said leads\n\nMilestone: Setting Up Content Strategy for Waku §\nachieved: §\n\nDiscussions with Comms Hubs re Waku Blog\nexpressed needs and intent around future blog post and needed amplification\ndiscuss strategies to onboard/involve non-dev and potential CTAs.\n\nMilestone: Web3Conf (dates) §\nMilestone: DeCompute conf §\n\nResearch (WIP) §\nMilestone: Autosharding v1 §\nachieved: §\n\nrendezvous hashing\nweighting function\nupdated LIGHTPUSH to handle autosharding\n\nnext: §\n\nupdate FILTER & STORE for autosharding\n\n\nnwaku (WIP) §\nMilestone: Postgres integration. §\nachieved: §\n\nnwaku can store messages in a Postgres database\nwe started to perform stress tests\n\nnext: §\n\nAnalyse why some messages are not stored during stress tests happened in both sqlite and Postgres, so maybe the issue isn’t directly related to store.\n\nMilestone: nwaku as a library (C-bindings) §\nachieved: §\n\nThe integration is in progress through N-API framework\n\nnext: §\n\nMake the nodejs to properly work by running the nwaku node in a separate thread.\n\n\ngo-waku (WIP) §\n\njs-waku (WIP) §\nMilestone: Peer management §\n_achieved: §\n\nspec test for connection manager\n\nMilestone: Peer Exchange §\nMilestone: Static Sharding §\nnext: §\n\nstart implementation of static sharding in js-waku\n\nMilestone: Developer Experience §\nachieved: §\n\njs-lip2p upgrade to remove usage of polyfills (draft PR)\n\nnext: §\n\nmerge and release js-libp2p upgrade\n\nMilestone: Waku Relay in the Browser §\n"},"waku/updates/2023-07-31":{"title":"2023-07-31 Waku weekly","links":[],"tags":["waku-updates"],"content":"Docs §\nMilestone: Docs general improvement/incorporating feedback (continuous) §\nnext: §\n\nrewrite docs in British English\n\nMilestone: Running nwaku in the cloud §\nnext: §\n\npublish guides for Digital Ocean, Oracle, Fly.io\n\n\nEco Dev (WIP) §\n\nResearch §\nMilestone: Detailed network requirements and task breakdown §\nachieved: §\n\ngathering rough network requirements\n\nnext: §\n\ndetailed task breakdown per milestone and effort allocation\n\nMilestone: Autosharding v1 §\nachieved: §\n\nupdate FILTER & STORE for autosharding\n\nnext: §\n\nRFC review & updates\ncode review & updates\n\n\nnwaku §\nMilestone: nwaku release process automation §\nnext: §\n\nsetup automation to test/simulate current master to prevent/limit regressions\nexpand target architectures and platforms for release artifacts (e.g. arm64, Win…)\n\nMilestone: HTTP Rest API for protocols §\nnext: §\n\nFilter API added\ntests to complete.\n\n\ngo-waku §\nMilestone: Increase Maintability Score. Refer to CodeClimate report §\nnext: §\n\ndefine scope on which issues reported by CodeClimate should be fixed. Initially it should be limited to reduce code complexity and duplication.\n\nMilestone: RLN updates, refer issue. §\nachieved:\n\nexpose set_tree, key_gen, seeded_key_gen, extended_seeded_keygen, recover_id_secret, set_leaf, init_tree_with_leaves, set_metadata, get_metadata and get_leaf\ncreated an example on how to use RLN with go-waku\nservice node can pass in index to keystore credentials and can verify proofs based on bandwidth usage\n\nnext: §\n\nmerkle tree batch operations (in progress)\nusage of persisted merkle tree db\n\nMilestone: Improve test coverage for functional tests of all protocols. Refer to [CodeClimate report] §\nnext: §\n\ndefine scope on which code sections should be covered by tests\n\nMilestone: C-Bindings §\nnext: §\n\nupdate API to match nwaku’s (by using callbacks instead of strings that require freeing)\n\n\njs-waku §\nMilestone: Peer management §\nachieved: §\n\nextend ConnectionManager with EventEmitter and dispatch peers tagged with their discovery + make it public on the Waku interface\n\nnext: §\n\nfallback improvement for peer connect rejection\n\nMilestone: Peer Exchange §\nnext: §\n\nrobusting support around peer-exchange for examples\n\nMilestone: Static Sharding §\nachieved: §\n\nWIP implementation of static sharding in js-waku\n\nnext: §\n\ninvestigation around gauging connection loss;\n\nMilestone: Developer Experience §\nachieved: §\n\nimprove & update @waku/react\nmerge and release js-libp2p upgrade\n\nnext: §\n\nupdate examples to latest release + make sure no old/unused packages there\n\nMilestone: Maintenance §\nachieved: §\n\nupdate to libp2p@0.46.0\n\nnext: §\n\nsuit of optional tests in pipeline\n\n"},"waku/updates/2023-08-06":{"title":"2023-08-06 Waku weekly","links":[],"tags":["waku-updates"],"content":"Milestones for current works are created and used. Next steps are:\n\nRefine scope of research work for rest of the year and create matching milestones for research and waku clients\nReview work not coming from research and setting dates\nNote that format matches the Notion page but can be changed easily as it’s scripted\n\nnwaku §\nRelease Process Improvements {E:2023-qa}\n\nachieved: fixed a bug in release CI workflow, enhanced the CI workflow to build and push a docker image on each PR to make simulations per PR more feasible\nnext: document how to run PR built images in waku-simulator, adding Linux arm64 binaries and images\nblocker:\n\nPostgreSQL {E:2023-10k-users}\n\nachieved: Docker compose with nwaku + postgres + prometheus + grafana + postgres_exporter https://github.com/alrevuelta/nwaku-compose/pull/3\nnext: Carry on with stress testing\n\nAutosharding v1 {E:2023-1mil-users}\n\nachieved: feedback/update cycles for FILTER & LIGHTPUSH\nnext: New fleet, updating ENR from live subscriptions and merging\nblocker: Architecturally it seams difficult to send the info to Discv5 from JSONRPC for the Waku app.\n\nMove Waku v1 and Waku-Bridge to new repos {E:2023-qa}\n\nachieved: Removed v1 and wakubridge code from nwaku repo\nnext: Remove references to v2 from nwaku directory structure and documents\n\nnwaku c-bindings {E:2023-many-platforms}\n\nachieved:\n\nMoved the Waku execution into a secondary working thread. Essential for NodeJs.\nAdapted the NodeJs example to use the libwaku with the working-thread approach. The example had been receiving relay messages during a weekend. The memory was stable without crashing.\n\n\nnext: start applying the thread-safety recommendations https://github.com/waku-org/nwaku/issues/1878\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added.\nnext: Extend Rest Api interface for new v2 filter. Get v2 filter service supported from node.\n\n\njs-waku §\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: robustness around peer-exchange, and highlight discovery vs connections for PX on the web-chat example\nnext: saving successfully connected PX peers to local storage for easier connections on reload\n\nWaku Relay scalability in the Browser {NO EPIC}\n\nachieved: draft of direct browser-browser RTC example https://github.com/waku-org/js-waku-examples/pull/260\nnext: improve the example (connection re-usage), work on contentTopic based RTC example\n\n\ngo-waku §\nC-Bindings Improvement: Callbacks and Duplications {E:2023-many-platforms}\n\nachieved: updated c-bindings to use callbacks\nnext: refactor v1 encoding functions and update RFC\n\nImprove Test Coverage {E:2023-qa}\n\nachieved: Enabled -race flag and ran all unit tests to identify data races.\nnext: Fix issues reported by the data race detector tool\n\nRLN: Post-Testnet3 Improvements {E:2023-rln}\n\nachieved: use zerokit batch insert/delete for members, exposed function to retrieve data from merkle tree, modified zerokit and go-zerokit-rln to pass merkle tree persistence configuration settings\nnext: resume onchain sync from persisted tree db\n\nIntroduce Peer Management {E:2023-peer-mgmt}\n\nachieved: Basic peer management to ensure standard in/out ratio for relay peers.\nnext: add service slots to peer manager\n\n\nEco Dev §\nAug 2023 {E:2023-eco-growth}\n\nachieved: production of swags and marketing collaterals for web3conf completed\nnext: web3conf talk and side event production. various calls with commshub for preparing marketing collaterals.\n\n\nDocs §\nAdvanced docs for js-waku {E:2023-eco-growth}\n\nnext: create guide on @waku/react and debugging js-waku web apps\n\nDocs general improvement/incorporating feedback (2023) {E:2023-eco-growth}\n\nachieved: rewrote the docs in UK English\nnext: update docs terms, announce js-waku docs\n\nFoundation of js-waku docs {E:2023-eco-growth}\nachieved: added guide on js-waku bootstrapping\n\nResearch §\n1.1 Network requirements and task breakdown {E:2023-1mil-users}\n\nachieved: Setup project management tools; determined number of shards to 8; some conversations on RLN memberships\nnext: Breakdown and assign tasks under each milestone for the 1 million users/public Waku Network epic.\n\n"},"waku/updates/2023-08-14":{"title":"2023-08-14 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-08-14 Waku weekly §\n\nEpics §\nWaku Network Can Support 10K Users {E:2023-10k-users}\nAll software has been delivered. Pending items are:\n\nRunning stress testing on PostgreSQL to confirm performance gain https://github.com/waku-org/nwaku/issues/1894\nSetting up a staging fleet for Status to try static sharding\nRunning simulations for Store protocol: Will confirm with Vac/DST on dates/commitment and probably move this to 1mil epic\n\n\nEco Dev §\nAug 2023 {E:2023-eco-growth}\n\nachieved: web3conf talk, swags, 2 side events, twitter promotions, requested for marketing collateral to commshub\nnext: complete waku metrics, coordinate events with Lou, ethsafari planning, muchangmai planning\nblocker: was blocked on infra for hosting nextjs app for waku metrics but migrating to SSR and hosting on vercel\n\n\nDocs §\nAdvanced docs for js-waku\n\nnext: document notes/recommendations for NodeJS, begin docs on js-waku encryption\n\n\nnwaku §\nRelease Process Improvements {E:2023-qa}\n\nachieved: minor CI fixes and improvements\nnext: document how to run PR built images in waku-simulator, adding Linux arm64 binaries and images\n\nPostgreSQL {E:2023-10k-users}\n\nachieved: Learned that the insertion rate is constrained by the relay protocol. i.e. the maximum insert rate is limited by relay so I couldn’t push the “insert” operation to a limit from a Postgres point of view. For example, if 25 clients publish messages concurrently, and each client publishes 300 msgs, all the messages are correctly stored. If repeating the same operation but with 50 clients, then many messages are lost because the relay protocol doesn’t process all of them.\nnext: Carry on with stress testing. Analyze the performance differences between Postgres and SQLite regarding the read operations.\n\nAutosharding v1 {E:2023-1mil-users}\n\nachieved: many feedback/update cycles for FILTER, LIGHTPUSH, STORE & RFC\nnext: updating ENR for live subscriptions\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added.\nnext: Extend Rest Api interface for new v2 filter. Get v2 filter service supported from node. Add more tests.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: upgrade libp2p & chainsafe deps to libp2p 0.46.3 while removing deprecated libp2p standalone interface packages (new breaking change libp2p w/ other deps), add tsdoc for referenced types, setting up/fixing prettier/eslint conflict\n\nDeveloper Experience (2023) {E:2023-eco-growth}\n\nachieved: non blocking pipeline step (https://github.com/waku-org/js-waku/issues/1411)\n\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: close the “fallback mechanism for peer rejections”, refactor peer-exchange compliance test\nnext: peer-exchange to be included with default discovery, action peer-exchange browser feedback\n\n\ngo-waku §\nMaintenance {E:2023-qa}\n\nachieved: improved keep alive logic for identifying if machine is waking up; added vacuum feature to sqlite and postgresql; made migrations optional; refactored db and migration code, extracted code to generate node key to its own separate subcommand\n\nC-Bindings Improvement: Callbacks and Duplications {E:2023-many-platforms}\n\nachieved: PR for updating the RFC to use callbacks, and refactored the encoding functions\n\nImprove Test Coverage {E:2023-qa}\n\nachieved: Fixed issues reported by the data race detector tool.\nnext: identify areas where test coverage needs improvement.\n\nRLN: Post-Testnet3 Improvements {E:2023-rln}\n\nachieved: exposed merkle tree configuration, removed embedded resources from go-zerokit-rln, fixed nwaku / go-waku rlnKeystore compatibility, added merkle tree persistence and modified zerokit to print to stderr any error obtained while executing functions via FFI.\nnext: interop with nwaku\n\nIntroduce Peer Management {E:2023-peer-mgmt}\n\nachieved: add service slots to peer manager.\nnext: implement relay connectivity loop, integrate gossipsub scoring for peer disconnections\n\n"},"waku/updates/2023-08-21":{"title":"2023-08-21 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-08-21 Waku weekly §\n\nEco Dev §\nAug 2023 {E:2023-eco-growth}\n\nachieved: +20% increase on twitter followers and had a discussion with digital comms team regarding improving Waku’s metrics on social handles. Migration of all ecodev elements from github to notion has also been initiated.\nnext: publish the metrics dashboard after call with Vaclav and publish draft for advocates program. Also coordinate with Lou regarding ETHRome hackathon.\nblocker: none\n\n\nDocs §\nAdvanced docs for js-waku\n\nachieved: added guide for js-waku debugging and running in NodeJS - PR111\nnext: js-waku encryption guides\n\n\nResearch §\n1.1 Network requirements and task breakdown {E:2023-1mil-users}\n\nachieved: Breakdown and assign tasks under each milestone for the 1 million users/public Waku Network epic.\nnext: Refine/discuss task breakdown. Start working on Waku Network RFC.\n\n\nnwaku §\nSharded peer management and discovery {E:2023-peer-mgmt}\n\nachieved: discv5 ENR update & filter predicate run-time updating\nnext: PRs feedback updates\n\nAutosharding v1 {E:2023-1mil-users}\nachieved: Complete! FILTER, LIGHTPUSH and RFC merged.\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added. V2 implementation done wait for PR review\nnext: Testing and add even more tests for failure cases.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: breaking change for @noble/secp256k1 PR in progress, redo trailing commas PR\n\nDeveloper Experience (2023) {E:2023-eco-growth}\n\nachieved: set default fallback fro NodeRequirements\n\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: peer-exchange included by default (PR opened)\nnext: tasks breakdown and followup from dogfooding feedback\n\n\ngo-waku §\nRLN enabled by default {E:2023-rln}\n\nachieved: removed registration capability from the wakunode and created a separate subcommand to do the registration\nnext: run rln-relay on all configured pubsub topics and content topics\n\nMaintenance {E:2023-qa}\n\nachieved: refactored wakuv2 metrics to make each protocol responsible for registering and defining its own metrics\n\nRLN: Post-Testnet3 Improvements {E:2023-rln}\nachieved: interop with nwaku.\n\nIntroduce Peer Management {E:2023-peer-mgmt}\n\nachieved: implement relay connectivity loop, log reachability status reported with help of AutoNAT service, local testing using waku simulator and bug fixes\nnext: work towards dogfooding new peer mgmt with Status\n\n"},"waku/updates/2023-08-28":{"title":"2023-08-28 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-08-28 Waku weekly §\n\nEpics §\nStatus MVP: Status Core Contributors use Status Mobile {E:2023-light-protocols}\nLight push and filter protocols are available in Status Mobile and Desktop. Some light dogfooding has started.\n\nResearch §\n1.1 Network requirements and task breakdown {E:2023-1mil-users}\n\nachieved: Further task refinement and assigning ownership. Visibility and traceability via GH issues.\nnext: Start working on Waku Network RFC.\n\n\nnwaku §\nsetting up static sharding fleet for Status {E:2023-10k-users}\n\nachieved: final infra definition, including generated keys and shards, specified in infra-status issue\nnext: ensure fleet gets deployed as specified\n\nRelease Process Improvements {E:2023-qa}\n\nachieved: added a CI job to notify on unexpected config option or DB schema changes\nnext: document how to run PR built images in waku-simulator, adding Linux arm64 binaries and images\n\nPostgreSQL {E:2023-10k-users}\n\nachieved: new docker compose in test-waku-query that allows to quickly compare insert and query performance between SQLite and Postgres.\nnext: Carry on with stress testing & follow-up of the Postgres addition to wakuv2.shards by the infra team.\n\nnwaku c-bindings {E:2023-many-platforms}\n\nachieved: Started applying thread-safe recommendations, making the Waku Node instance to be created within the Waku Thread itself.\nnext: Carry on with the thread-safety recommendations: avoid using Channel to communicate main thread and the Waku Thread.\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added. V2 implementation done wait for PR review\nnext: Finish rebase to master, manual adapt of autoshard feature into Filter v2.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: store protocol refactor for readability\n\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: break down dogfooding into tasks for peer-exchange\n\nCover Several Environments As Part of Testing {E:2023-qa}\n\nachieved: created front-end app to be run in a pipeline\nnext: complete app and run in the pipeline, figure out next steps to run Firefox\n\n\ngo-waku §\nRLN enabled by default {E:2023-rln}\n\nachieved: run rln-relay on all configured pubsub topics and content topics, added metrics, made RLN database aware of chainID and contract address, refactored keystore.\nnext: test keystore interop with nwaku, integrate waku rln registry, and restore valid roots from DB\n\nAuto-sharding v1 {E:2023-1mil-users}\n\nachieved: Implemented core logic for autosharding\nnext: API changes for autosharding\n\nImprove Test Coverage {E:2023-qa}\n\nachieved: Improved test coverage in utils.\n\nIntroduce Peer Management {E:2023-peer-mgmt}\n\nachieved: Raised PR in status-go to use this version in order to dogfood. Local testing with status desktop\nnext: Dogfood changes with Status desktop and mobile using Waku CC’s\n\n"},"waku/updates/2023-09-04":{"title":"2023-09-04 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-09-04 Waku weekly §\n\nEpics §\n1.1 Network requirements and task breakdown {E:2023-1mil-users}\n\nachieved: Started working on Waku Network RFC. Visibility and traceability in GH improvements.\nnext: Continue working on Waku Network RFC.\n\n\nnwaku §\nsetting up static sharding fleet for Status {E:2023-10k-users}\n\nachieved: negotiation with infra to improve fleet definition, clarify postgresql deployment\nnext: ensure fleet gets deployed as specified\n\nRelease Process Improvements {E:2023-qa}\n\nachieved: minor fixes in GH action workflows, building experimental (i.e. RLN enabled) image per-PR to simlify RLN testing/simulations\nnext: document how to run PR built images in waku-simulator, adding Linux arm64 binaries and images\n\nPostgreSQL {E:2023-10k-users}\n\nachieved: Download and start configuring jmeter to have a variable number of clients sending concurrent Store requests.\nnext: Carry on with stress testing & follow-up of the Postgres addition to wakuv2.shards by the infra team.\n\nnwaku c-bindings {E:2023-many-platforms}\n\nachieved: Merged PR that made the Waku Node to be created within the Waku Thread. Submitted a PR that aims to make a safer the communication between the main thread and the Waku Thread.\nnext: Merge the PR to enhance communication between threads and start extracting the thread context outside the library (comment: https://github.com/waku-org/nwaku/pull/1865#discussion_r1282722954).\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added. V2 implementation done wait for PR review\nnext: Complete Filter v2 PR foundings fixes.\nblocking: PR review found a design flow, need a little redesign.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: @chainsafe/libp2p-gossipsub is updated\n\nDeveloper Experience (2023) {E:2023-eco-growth}\n\nachieved: pre-emptive stream creations for light protocols, using lowest latency peers for light protocols (WIP)\nnext: merging lowest latency peer PR\n\nWaku Relay scalability in the Browser\n\nachieved: complete PoC of Waku Relay over WebRTC using circuit relay\nnext: pause this to prioritize Waku Network milestone\n\nCover Several Environments As Part of Testing {E:2023-qa}\n\nachieved: finishing testing against chrome and react;\nnext: investigate other adding browsers;\n\n\ngo-waku §\nRLN enabled by default {E:2023-rln}\n\nachieved: test keystore interop with nwaku, integrate waku rln registry, and restore valid roots from DB\nnext: ordered validator execution, bandwidth validation, upgrade zerokit\n\nMaintenance {E:2023-qa}\n\nachieved: allow mixing named and static shards, logs successful message pushes, concurrency fixes for filterv2\n\nAuto-sharding v1 {E:2023-1mil-users}\n\nachieved: Implemented new config for autosharding and ENR updates with shard info\nnext: update various protocols to autoshard\n\n"},"waku/updates/2023-09-11":{"title":"2023-09-11 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-09-11 Waku weekly §\nResearch §\n1.1 Network requirements and task breakdown {E:1.1 Network requirements and task breakdown}\n\nachieved: Opened first raw version of Waku Network RFC for review.\nnext: Address any feedback on the Waku Network RFC and complete under-defined sections.\n\n\nDocs §\nReview Usage and Metrics 2023 Q3 {E:Define network and community metrics}\n\nachieved: published the language/SDK poll on Discord\nnext: publish the poll on socials for more visibility and responses\n\nDocs general improvement/incorporating feedback (2023)\n\nnext: refactor the layout of the docs to match the new designs\n\n\nnwaku §\nfeat(rest): Add /health endpoint to rest api {E:REST API service node}\n\nachieved: Feature /health endpoint added. PR merged: https://github.com/waku-org/nwaku/pull/2011\n\nfeat: Autosharding API for (relay) subscriptions {E:1.2: Autosharding for autoscaling}\n\nachieved: Refactored and simplified the core logic\nnext: More PR feedback\n\nRelease Process Improvements {E:Automated release processes}\n\nachieved: execute js-waku tests from nwaku workflows against PRs, nightly and release candidates\nnext: adding Linux arm64 binaries and images\n\nPostgreSQL {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}\n\nachieved:\n\nCreated a jmeter test plan to stress Store queries through REST Store. As a conclusion, the node with Store Postgres showed worse performance than the one with SQLite.\nhttps://github.com/waku-org/test-waku-query/pull/5\nAdded reconnection feature. If the connection with Postgres is lost, the nwaku node tries to reconnect again. https://github.com/waku-org/nwaku/pull/1997\nThe wakuv2.shards fleet had been de-prioritized in favor of the status.shards one.\nhttps://github.com/status-im/infra-nim-waku/issues/74#issuecomment-1710514544\n\n\nnext: Optimize database so that the Store requests behave better with Postgres.\n\nchore: do not advertise MAs with port 0 {bug}\n\nnext: analyze and fix issue\n\nfeat: HTTP REST API: Filter support v2 {E:REST API service node}\n\nachieved: PR tracking is https://github.com/waku-org/nwaku/pull/1890\nReview is done, various fixes upon applied\nnext: Last, agreed interface change to be done to complete.\n\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\nnext: analyze and fix issue\n\nbug: 0.0.0.0 included in listenAddrs of identify message {bug}\n\nachieved: fixed bug, updated tests according to new fixes and raised PR\n\nnwaku c-bindings (NodeJS + Python) {E:NodeJS Library}\n\nachieved: improved the thread safeness communication.\nhttps://github.com/waku-org/nwaku/pull/1978\nnext: Once the above PR is merged, avoid the use of global variables, to enhance the thread-safeness ( see https://github.com/waku-org/nwaku/pull/1865#discussion_r1282722954 )\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:REST API service node}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added. V2 implementation done wait for PR review, /health rest api added to check (currently) RLN readiness\nnext: Last round of Filter v2 PR review with finalized re-worked push handler part.\nblocking: /health endpoint come in and Filter v2 work was down prio till.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: updated typescript + plugins to major versions, waiting to merge for release\n\nDeveloper Experience (2023) {E:2023-eco-growth}\n\nachieved:\n\ninvestigation of go-waku interop test that is failing - ongoing, fixing next release\nprotocols now use lowest latency peer instead of a random peer\n\n\nnext: root cause go-waku interop test failure, release next tag on master merge\n\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: Peer Exchange is now merged included in defaultBootstrap\nnext: followup on browser investigation and confirm if the EPIC can be safely closed\n\nCover Several Environments As Part of Testing {test}, {E:2023-qa}\n\nachieved: browser testing is redone and opening for review\nnext: integrate with release process - rather quick follow up, revisit current epic\n\n\ngo-waku §\nRLN enabled by default {E:3.2: Basic DoS protection in production}\n\nachieved:\n\nordered validator execution, upgrade zerokit, append rln proofs when posting msgs in rest/rpc, clean up nullifier table, automatically use key from keystore if only a single credential is available, validate credential using onchain query\nrln membership registration logic refactoring and fixing bugs. Added test for membershipFetcher. Added code for mock_blockchain and mock_client to test membershipFetcher.\n\n\nnext: bandwidth validation, rln isReady verif in /health endpoint, subcommand to list credentials\n\nMaintenance {E:2023-qa}\n\nachieved:\n\nfix panic observed in peer-manager, update filter protocol as per rfc.\nadd tls/ws to address factory and log ENRs only after they have been setup\nrefactoring and some bug fixes in peermanager and read rfcs and docs\n\n\nnext: increase test coverage and read more code.\n\nImprove Test Coverage {test}\n\nachieved: build examples as part of CI to capture compile errors\n\n"},"waku/updates/2023-09-18":{"title":"2023-09-18 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-09-18 Waku weekly\n\nEpics §\n1.1 Network requirements and task breakdown {E:1.1 Network requirements and task breakdown}\n\nachieved: Further specifications added for RLN. Merged and published first version of RFC\nnext: Define first launchable (sub)network for Devconnect.\n\n\nDocs §\nAdvanced docs for js-waku\n\nachieved: added guide for local development with nwaku\n\nNode operator doc - cloud and advanced options\n\nachieved: added guide on advanced nwaku and WebSocket configurations\nnext: add guide for enabling node monitoring\n\n\nResearch §\nRLN Key Benchmarks {E:3.2: Basic DoS protection in production}\n\nachieved: benchmark rln, see issue with report.\n\n\nnwaku §\nfeat: HTTP REST API: lightpush {E:REST API service node}\n\nachieved:\nnext: LightPush REST endpoint will be implemented fully and put on PR review\nblocking:\n\nbug: wrong user_version in sqlite database that blocks the run of a Waku node {bug}\n\nachieved: bug fix that prevented a Store nwaku to start if the SQLite db was created with versions [0.14.0 - 0.18.0]\n\nfeat: Autosharding API for (relay) subscriptions {E:1.2: Autosharding for autoscaling}\n\nachieved: many PR fixes,\nblocker: explicit subscriptions in js-waku tests\n\nchore(rln-relay): Requirements to consider RLN ready (non experimental) {E:3.1: DoS requirements and design}\n\nachieved: waku rln is not an experimental feature anymore, and is part of nwaku code base. from now on experimental features are hidden behind a flag and not in different build\n\nchore: do not advertise multiaddr with port 0 {bug}\n\nachieved: tested two different solutions: updating the port with an addressMapper, and not allowing the user to use port 0. Analyzed and discussed technical implications of both solutions. Initially followed decision to proceed with 2nd solution for now, with intention of implementing the first solution in the future.\n\nOpened a draft PR and updated tests for the solution of not allowing the user to choose port 0.\n\n\nnext: after further feedback received today, we have to complete the discussion of how to move forward and either review and proceed with current PR, or plan and implement solution that updates all the data structures consistently across the node\n\nfeat: HTTP REST API: Filter support v2 {E:REST API service node}\n\nachieved: Filter v1 & v2 REST API endpoints merged to master\nnext: LightPush REST endpoint\n\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\nachieved: implemented solution that does DNS IP resolution during node bringup when no external IP is found but a DNS address is provided.\n\nValidated and tested “happy paths” of the solution, raised draft PR and got feedback about the solution\n\n\nnext: discuss and define the system’s behavior on errors, implement error handling and adding tests for this feature.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: added logs, investigated issues reported\nnext: approach reported issues, add preventative measures\n\nCover Several Environments As Part of Testing {test}, {E:2023-qa}\n\nachieved: got reviews on playwrights tests\nnext: maybe add bounty, check Karma testing\n\n\ngo-waku §\nfeat: discovery & peer management for static shards {E:1.4: Sharded peer management and discovery}\n\nachieved: Update WakuPeerStore to store pubSubTopics for a peer.\nnext: Sharded Peer Management considering static sharding for Status communities.\n\nRLN enabled by default {E:3.2: Basic DoS protection in production}\n\nachieved: isReady verif in /health endpoint, make RLN available in service nodes and library usage by default, update docs and docker image, use zerokit 0.3.4, allow running service node with no RLN credentials\nnext: bandwidth validation, subcommand to list credentials\n\nMaintenance {E:2023-qa}\n\nachieved: CommonService for embedding lifecycle operation in lightpush,discv5,filter,peerConnector etc.\nnext: after discussion with richard prem, use create 2 different types of commonService. Change nameServer flag functionality in go-waku to nwaku. And work on newly created tasks.\n\nImprove Test Coverage {test}\n\nachieved: replace golint by revive, and add make lint-full target to run linting with many more rules enabled\n\n"},"waku/updates/2023-09-25":{"title":"2023-09-25 Waku weekly","links":[],"tags":["waku-updates"],"content":"nwaku §\nfeat: RLN support for Nwaku-Compose {E:3.2: Basic DoS protection in production}\n\nachieved: added RLN flags run_node.sh (including the optional ones), added RLN related environment variables to docker-compose.yml, added RLN metrics’ visualizations to Grafana and updated the README to account for the new changes. Improved implementation based on feedback.\nnext: test the use of optional parameters, get feedback for new version, and merge as soon as all the comments get addressed\n\nchore: bump vendor dependencies for 0.21.0 {dependencies}\n\nachieved: Bumped all dependencies and prepared to 0.21.0. We will start doing this regularly after each release.\n\nfeat: HTTP REST API: lightpush {E:REST API service node}\n\nachieved: Lightpush REST API endpoint merged to master\nnext: Admin REST endpoint, extended health endpoint, Full swagger doc of nwaku rest API interface\n\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\nachieved: peer manager can filter peer by shard, filter discv5 bootstrap nodes by shard, external APIs moved out of node folder\nnext: refactor APIs handlers to discover peers if none is found in peer manager with the required capability\n\nfeat: Autosharding API for (relay) subscriptions {E:1.2: Autosharding for autoscaling}\n\nachieved: fixed js-waku nwaku interop test\nblocker: js-waku PR not merged\n\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\nachieved: added error handling and tests, received new feedback and addressed the comments\nnext: get the new version reviewed and merge if approved\n\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\nachieved: implemented solution that does DNS IP resolution during node bringup when no external IP is found but a DNS address is provided.\nValidated and tested “happy paths” of the solution, raised draft PR and got feedback about the solution\nnext: discuss and define the system’s behavior on errors, implement error handling and adding tests for this feature.\n\nnwaku c-bindings (NodeJS + Python) {E:NodeJS Library}\n\nachieved: Use of ‘ThreadSignalPtr’ instead of loop to handle req/resp.\nhttps://github.com/waku-org/nwaku/pull/2045\nnext: Avoid the use of global variables, to enhance the thread-safeness ( see https://github.com/waku-org/nwaku/pull/1865#discussion_r1282722954 )\n\n\njs-waku §\nPeer Exchange is supported and used by default {E:2.1: Production testing of existing protocols}\n\nachieved: The Peer Exchange Epic is now completed & closed\n\nCover Several Environments As Part of Testing {test}, {E:Comprehensive dev testing}\n\nachieved: improved karma testing, added testing in browser\n\n\ngo-waku §\nfeat: discovery & peer management for static shards {E:1.4: Sharded peer management and discovery}\n\nachieved: handle dynamic topic sub/unsub and update peerMetadata.\nnext: relay peer mgmt for static/auto sharding\n\nfeat: Autosharding API for req-resp protocols {E:1.2: Autosharding for autoscaling}\n\nachieved: Completed Filter API and lightClient changes for autosharding\n\nAdd postgresql to the unit tests {test}\n\nachieved: Add test for store query creation functionality, and change store test to use postgres. Add tests for postgres module.\n\n"},"waku/updates/2023-10-02":{"title":"2023-10-03 Waku Weekly","links":[],"tags":["waku-updates"],"content":"waku-rust-bindings §\nfeat: filterv2 support {E:RLN non-native SDKs}\n\n\nachieved: added support for unsubscribe, ping and unsubscribe_all filterv2 functions of go-waku c-bindings\n\n\nnext: add support to subscribe\n\n\n\nnwaku §\nfeat: Implement /admin Rest Api endpoint\n\n\nachieved:\n\n\nnext: /admin rest endpoint feature is on PR review will be merged next week. Restructure openapi descriptions and producing swagger ui like live document of all rest interfaces.\n\n\nblocking: There are two build issues. libwaku cannot build on Fedora (RedHat) distros. Second, Abhi reported a build issue with wakunode2 - nim compiler crash under some circumstances.\n\n\nfeat: RLN support for Nwaku-Compose {E:3.2: Basic DoS protection in production}\n\n\nachieved: finished addressing feedback\n\n\nnext: task is blocked until there’s an easier method for users to register RLN credentials\n\n\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\n\nachieved: newly refactored STORE REST API handler that trigger discv5 peer search when needed.\n\n\nnext: refactor other APIs\n\n\nPostgreSQL {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}\n\n\nachieved:\n\n\nBetter dburl parse that accepts host names with dashes and dots.\n\n\nProperly set the compilation flag -d:postgres so Docker images are compiled with support to Postgres (with libpq5 dependency.)\n\n\nDuring the stress testing, I discovered that the max throughput seems not to be directly related to Postgres. If I make the code to ignore Postgres and return immediately a mocked response, then the throughput is even lower.\n\n\nnext: Carry on with “select” performance analysis and analyze it directly from a Store client, rather than having REST <-> Store_Client <-> Store_Server. By ignoring the REST layer we will have a better insight into the actual Store protocol, as @jm-clius recommended to me some time ago.\n\n\nchore: add retention policy with GB or MB limitation {enhancement}, {E:PostgreSQL}\nAdded the new retention policy based on DB size.\nUsers can provide the size such as <size_number><case_insenstive_gb_or_mb> ex. 30gb (which is also the default)\n--store-message-retention-policy=size:25GB\n--store-message-retention-policy=size:25gb\n--store-message-retention-policy=size:250MB\n--store-message-retention-policy=size:250mb\nTest case also added.\nOutdated messages/rows are deleted to suffice the size limit, with 20% size reduction upon overflowing.\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\n\nachieved: addressed feedback and merged\n\n\nchore: improve test coverage on NetConfig generation\n\n\nachieved: developed the new NetConfig test suite, raised PR, received and implemented feedback and merged.\n\n\nnwaku c-bindings (NodeJS + Python) {E:NodeJS Library}\n\n\nachieved:\n\n\nAdded a simple cpp example to the main code. https://github.com/waku-org/nwaku/pull/2079.\n\n\nSubmitted a PR where we start showing the doability of a Rust integration with the libwaku.\n\n\nThis PR is currently introducing the thread-safety enhancement of avoiding using global variables. Ideally, this should be in a separate PR. https://github.com/waku-org/nwaku/pull/2089.\nNotice that it was important to invest time in the Rust example so that we can carry on with the “callback” technique to exchange information between the host code (any) and the foreign code (Nim.)\n\n\nnext: Separate the PR mentioned above and submit another one which only avoids using global variables but doesn’t add the wip-Rust integration.\n\n\n\njs-waku §\nStatic Sharding {E:Static sharding}\n\n\nachieved: allowing for multiple pubsub topics to be configured & refactoring protocols to support\n\n\nnext: enabling peer management to only dial relevant shards\n\n\n\ngo-waku §\nrefactor: add user_data to c-bindings {E:RLN non-native SDKs}\n\n\nachieved: updated all the functions to include an additional void* user_data parameter\n\n\nfeat: discovery & peer management for static shards {E:1.4: Sharded peer management and discovery}\n\n\nachieved: basic relay peer mgmt for static/auto sharding\n\n\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\n\nachieved: Peer selection updated to be based on pubsubTopic or contentTopic\n\n\nnext: Update lightClient API to consider new peerSelection options\n\n\nfeat: Autosharding API for req-resp protocols {E:1.2: Autosharding for autoscaling}\n\n\nachieved: Updated lightpush API for autosharding\n\n\n\nEcoDev §\nOctober 2023\n\nETHSafari bound and was mostly travelling last week\n"},"waku/updates/2023-10-09":{"title":"2023-10-09 Waku Weekly","links":[],"tags":["waku-updates"],"content":"\nnwaku §\nfeat: Implement /admin Rest Api endpoint {E:REST API service node}\n\nachieved: /admin Rest API endpoint implemented\nnext: Restructure openapi descriptions and producing swagger ui like live document of all rest interfaces. Restructure Rest API schema types.\n\nchore: notify user if docker-compose fails {enhancement}, {E:3.2: Basic DoS protection in production}\n\nachieved: discussed the issue with colleagues, implemented the solution and closed the issue\n\nfeat: allowing users to choose port 0 for dynamically allocated ports {enhancement}\n\nachieved: analyzed code and found the different data structures affected by the dynamic port allocation. Considered the implications of different approaches to solve the issue, discussed and translated the different options into code.\nStarted the implementation of the chosen solution, with part of the solution already working.\nnext: complete the first working version of the solution, improve its design/architecture, and test.\n\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\nachieved: Filter, Store, Light push REST APIs discovery handler (a rework of the previous solution)\n\nsetting up static sharding fleet for Status {E:Static sharding}\n\nachieved: fleet has been deployed, PostgreSQL setup has been tested.\nnext: Do some basic dogfooding with Status Desktop.\n\nPostgreSQL {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}\n\nachieved: Applied performance comparison between SQLite and Postgres but in this case, making direct requests from a go-waku unittest that @richard-ramos had prepared.\nAfter directly comparing the Store protocol, noticed that the bottle neck is within the database itself. i.e. the SQLite database performs better than Postgres, given that we have a very simple schema and simple queries, without joins. Adding indexes to the Postgres database didn’t help very much. For example, given the same query, SQLite takes 1ms whereas Postgres takes 6ms.\nnext:\n\nWrap up the Store testing environment and install it into our sandbox machine, metal-01.he-eu-hel1.wakudev.misc.statusim.net, so that anyone can proceed from this point (two databases with the same dataset of ~2 million rows .) in case someone is keen on analyzing performance or debug in a more realistic testing scenery. This will include concurrent queries from multiple nodes, where PostgreSQL is expected to perform better.\nStart extracting the database creation and indexes creation to outside the code base.\n\n\n\nchore: add retention policy with GB or MB limitation {enhancement}, {E:PostgreSQL}\nIn review: the database bug to delete limited messages/rows\nUpcoming/working: updated retention policy + test + missing tes on timestamp based retention policy\nUndergoing: MUID concept on message level\nfeat: provide a way to define advertised addresses {enhancement}\n\nachieved: went over the code and found the root cause of the issue and a preliminary solution\nnext: finish discussing the approach to the solution and implement it\n\n\njs-waku §\nStatic Sharding {E:Static sharding}\n\nachieved: PR open for allowing peer management for multiple pubsub topics/shard\nnext: getting reviews & releasing\n\nPeer Management: Connection and Disconnection {track:restricted-run}, {E:2.1: Production testing of existing protocols}\n\nachieved: investigated & closed #1412\nnext: look into addressing deliberate vs accidental disconnections\n\n\ngo-waku §\n\nTeam attended EthRome\n"},"waku/updates/2023-10-16":{"title":"2023-10-16 Waku weekly","links":[],"tags":["waku-updates"],"content":"nwaku §\nchore: Reorganize RestApi specs for live documentation {E:REST API service node}\n\nachieved: Http RestAPI interface is in parity with json-rpc with even more features supported on it.\nnext: Openapi specification is reorganized and online doc generated out of it. Currently under PR review.\nFollow up spec reorganization with rest api type reorganization. RFC changes to enhance lighpust failure response.\n\nfeat: allowing users to choose port 0 for dynamically allocated ports {enhancement}\n\nachieved: had over code review sessions and got feedback. Implemented improvements, attempted new approaches, fixed bugs. Most of the solution is already implemented and working.\nnext: fix failed tests, add test cases and raise PR\n\nfeat: experimental incentivize store protocol {E:Basic service incentivization}\n\nachieved: wrote the first draft of incentivization outline\nnext: discuss open question, continue structuring the document\n\nsetting up static sharding fleet for Status {E:Static sharding}\n\nachieved: setup a separate shard for community points of contact, and another one for 1:1/group messages\nnext: investigate/fix discv5 not working when static sharding is being used.\n\nPostgreSQL {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}\n\nachieved:\n\nTesting environment prepared in metal-01.he-eu-hel1.wakudev.misc.statusim.net. There are two databases (Postgres and SQLite) with 5 million of random messages.\nEnhanced Grafana dashboard so that we can compare timings performance throughout an histogram.\n\n\nnext: Carry on with the investigation to enhance the Postgres performance.\n\nfeat: provide a way to define advertised addresses {enhancement}\n\nachieved: implemented solution and raised PR\nnext: get feedback, implement suggested improvements and close\n\nnwaku c-bindings (NodeJS + Python) {E:NodeJS Library}\n\nachieved:\n\nSeparate PR to avoid global variables: https://github.com/waku-org/nwaku/pull/2118\nStarted to document the tasks tackled so far: https://www.notion.so/NWaku-cbindings-FFI-7a9ae6240cfc4caba7c7ff0bf3429a70\n\n\nnext: Start creating a separate NodeJs and Python repositories, where we will create nodejs-waku and py-waku, respectively.\n\n\njs-waku §\nPeer Management: Connection and Disconnection {E:2.1: Production testing of existing protocols}\n\nachieved: reached a conclusion tackling deliberate vs accidental disconnections, PRs opened to handle Filter subscriptions on disconnection/reconnections, iterative fixes on addressing multiple dial attempts for same peer, fixes around keep alive pings\nnext: getting reviews & merging these PRs which should enable us to close this epic 🥳\n\n\ngo-waku §\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\nachieved: refactor and migrate peer selection to peer manager and update lightclient API to use new options\nnext: on-demand discovery if peers are not available for the shard\n\nAdd postgresql to the unit tests {test}\n\nachieved: Completed. Fixed only sqlite being used for creating queries.\n"},"waku/updates/2023-10-23":{"title":"2023-10-23 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-10-23 Waku weekly §\nWaku Network Can Support 10K Users §\n\nachieved:\n\nVac/DST team has done further runs with up to 600 nodes in the network as part of wrapping up a blog post report.\nStaging fleet for Status with static sharding and PostgreSQL deployed and being tested by go-waku team using local changes in Status Desktop.\n\n\nnext:\n\nDogfooding of Status Desktop with Status staging fleet. Will aim to create a small internal Waku community.\nContinue integration of static sharding in status-go.\n\n\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nPostgreSQL implementation has not yet been proven more performant than SQLite. Further improvements and testing in progress.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: hardcoded bootnodes ENRs in addition to DNS Discovery URLs as a way to overcome nameserver issues. Use a static shard instead of the default pubsub topic. Update tool to crawl and discover nodes via discv5.\nnext: fix if necessary strange behavior with discv5 when ENRs in DNS discovery URL do not contain shards. Document steps for dogfooding.\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved: See 10k milestone update for PostgreSQL status.\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under\nvac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\n\n\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nCritical path work for autosharding done in nwaku, in progress on go-waku\nParameters for the Waku Network Gen 0 have been captured in an RFC and use as a basis for simulations and theoretical analysis, removing uncertainty on this milestone around message rates, performance and expected bandwidth usage.\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one joining at end of Oct) so delivery in this client is likely to lag behind other clients.\n\n\n\n3.2: Basic DoS protection in production §\n[js-waku] Task: Manage RLN membership(s) and keys\n\nachieved: completed flow up items and main stream of work;\n\n[js-waku-examples] feat: re-create rln-js\n\nachieved: experimented with different frameworks, almost complete rewriting the example;\n\n[research] Message propagation times with waku-rln\n\nachieved: Ran simulations with 1000 nwaku nodes with rln enabled, with the goal of measuring message propagation delays under different conditions.\nnext: Some issues with the current simulations, need to investigate shadow tool to simulate CPU “time passing”. Some results are not valid.\n\n2.1: Production testing of existing protocols §\n[js-waku] chore: improve logging when fails to connect to a node\n\nachieved: setup a Logger for more verbose and modular error readbility\n\n[js-waku] Peer Management: Connection and Disconnection\n\nachieved: The Connection and Disconnection Peer Management epic has been closed\n\n[waku-rust-bindings] feat: filterv2 support\n\nachieved: added support to waku_filter_subscribe\nnext: write unit tests for filterv2 and publish new version\n\nQuality Assurance processes are in place - 2024-03-31 §\nThis work is tracked with vac:dst:software-testingwaku\nSupport Many Platforms - 2024-04-30 §\nShip RLN as part of non-native SDKs §\n[go-waku] refactor: add user_data to c-bindings\n\nachieved: exposed filterv2 subscription details (useful for rust bindings)\n\nREST API service node §\n[nwaku] chore: reorganize rest-api types\n\nachieved: Enhancements on Rest request error handling.\nnext: Finalize api spec and doc after PR review. Work in progress: rest api type reorganization. RFC changes to enhance light-push failure response.\nblocking: Fixing found issues during release.\n\n[go-waku] feat: lightpush REST API\n\nachieved: Add lightpush rest api and test. Rest Filter v2 in progress.\n\nOther Work §\nEnhancements §\n[nwaku] feat: allowing users to choose port 0 for dynamically allocated ports\n\nachieved: fixed failed tests, added a test case to cover the changes, small refactor and raised PR\nnext: get PR reviewed and implement feedback\n\n[nwaku] feat: provide a way to define advertised addresses\n\nachieved: merged PR with initial fix. Implemented and raised PR for the --ext-multiaddr-only CLI flag\nnext: get PR reviewed, implement feedback and merge\n\nBugs §\n[nwaku] bug: WSS enabled node stops accepting websocket connections after some time\n\nachieved: discovered and debuged WSS issue, discovered and debugged REST API causing SIGSEGV, oversaw release v0.21.0\nnext: help with release v0.21.1, investigate existing bandwidth management work\n\nEcosystem Development - Docs §\n\nachieved:\n\ngot familiar with what The Graph is doing with Waku, @waku/sdk update in @waku/react\nPreparation to Polygon Enugu\nPeer management disconnection docs\n\n\nnext:\n\nWork on metrics dashboard\nRecord some explainer videos\nDocs redesign\nOutline for encryption docs\n\n\n"},"waku/updates/2023-10-30":{"title":"2023-10-30 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-10-30 Waku weekly §\nWaku Network Can Support 10K Users §\n\nIntegration of static sharding in go-waku is continuing (see updates below).\nTesting of PostgreSQL enabled some performance improvement in the implementation that are being implemented.\nInternal instructions have been distributed to dogfood static sharding with the Waku team (Waku Discord private channel).\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: unsuccesfully tried to avoid introducing a breaking change in status-go. We need to decide whether to go ahead and merge that PR\nblocker: discv5 filters out outdated ENR entries from DNS Discovery URL in shard fleet - https://github.com/waku-org/nwaku/issues/2162\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nSee 10k milestone update for PostgreSQL status.\nFirst version of the 10k-tool by DST is ready and is being tested with simulation running a small nim-libp2p/gossipsub binary.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under\nvac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\n\n\n\nPostgreSQL in service node: Further optimisations §\n[nwaku] PostgreSQL\n\nachieved:\n\nTime processing enhancement when performing SELECT operations. There was an overhead caused by looping too many times over the returned rows, in order to convert the row types. By applying a “rowCallback” approach we can reduce by 30ms the time spent on the query under analysis.\n\n\nnext:\n\nThe queries used in the comparison analysis still perform much better in SQLite (< ~5ms) than in Postgres (< ~15ms.) Therefore we need to push the investigation further to enhance that.\n\n\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nFurther simulation done, with a continued focus on message propagation time and possible improvements.\nProgress across all client son sharded peer management discovery\nFirst PRs merged towards basic distributed store services\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.\n\n\n\n3.2: Basic DoS protection in production §\n[nwaku] feat: add rln to waku simulator instance\n\nachieved: learnt about waku-simulator’s inner workings and got the background required to integrate RLN to it. Added service that generates traffic to the nodes via their REST APIs. Investigated and tested different ways of approaching the RLN integration.\nnext: get RLN to work and add Grafana dashboards with RLN data\n\n[js-waku-examples] feat: re-create rln-js\n\nachieved: addressed flaws in integration, completed rewriting;\n\n[research] Tuning GossipSub’s D parameter in Waku\n\nachieved: nwaku simulations showing the impact in message propagation delay when reducing gossipsub’s D value. Main goal is to reduce bandwidth consumption in exchange of worsen propagation delay.\nnext: asses if we want to move forward changing D.\n\n[research] Message propagation times with waku-rln\n\nachieved: Final simulation results with 1000 nwaku nodes with rln enabled, with the goal of measuring message propagation delays under different conditions (amount of nodes and message size).\nnext: NA\n\n1.4: Sharded peer management and discovery §\n[nwaku] feat: Service peer selection on specific shards\n\nachieved: REST APIs discovery handlers PR merged\n\n[nwaku] feat: Peer management with shard as a dimension\n\nachieved: Waku Metadata shard subscriptions, Sharded relay peer management, draft sharded peer store pruning\nnext: finalize sharded peer store pruning & run simulations\n\n[go-waku] feat: Deprecate Named Sharding and Update Lightpush Client API\n\nachieved: Create PR for review for removing of Named Pubsubtopic.\n\n[go-waku] feat: Service peer selection on specific shards\n\nachieved: draft PR #834 opened for on-demand peer discovery\nnext: use on-demand peer discovery for service and relay peer selection\n\n2.3: Basic distributed Store services §\n[nwaku] feat: add new message_hash column to the archive protocol\n\nachieved: On SQLite’s schema transition (i.e. this PR) to messageHash feature complete PR posted (awaiting reviews), Gained insight into the connection and interplay between the store and archive components, and how they may be leveraged into making a sync protocol. Small stuff - bug fix on the jsWaku which was this PR dependent (that too was time-consuming since my first time interacting with JS code of waku), PR on vacuum on time-based retention policy, thought through the nitty gritty details of node based roles and incentives.\nnext:\n\nThe sync protocol formulation totally based on the messages sync without any external factors into POV\nReview PostgreSQL PRs by Ivan to gain more knowledge on the storage/archive feature.\n\n\n\n2.1: Production testing of existing protocols §\n[nwaku] PostgreSQL\n\nachieved:\n\nTime processing enhancement when performing SELECT operations. There was an overhead caused by looping too many times over the returned rows, in order to convert the row types. By applying a “rowCallback” approach we can reduce by 30ms the time spent on the query under analysis.\n\n\nnext:\n\nThe queries used in the comparison analysis still perform much better in SQLite (< ~5ms) than in Postgres (< ~15ms.) Therefore we need to push the investigation further to enhance that.\n\n\n\n[waku-rust-bindings] feat: filterv2 support\n\nachieved: fix issues found during testing\nnext: publish new version\n\nQuality Assurance processes are in place - 2024-03-31 §\nSupport Many Platforms - 2024-04-30 §\nPresentation Readiness §\n[js-waku] feat: better support for development\n\nachieved: experimented with Next.js app;\nnext: looking for ways to mitigate errors in console or catch others;\n\nShip RLN as part of non-native SDKs §\n[go-waku] refactor: add user_data to c-bindings\n\nachieved: fixed issues found during tests with waku-rust-bindings\n\nREST API service node §\n[go-waku] feat: admin REST API\n\nachieved: Implemented Admin REST API and updated the spec.\n\nEcosystem Development §\n\n\nachieved:\n\nnew tictactoe example with @waku/react\nProgress on Devconnect planning\nOrganising dev ex calls\nShipping resources for hackathon\nReviewed Graphcast proposal for using relay\n\n\n\nnext:\n\nipfs/waku example for file transfer\nWaku tutorial videos\n@waku/react hacker pain-point feedback report\nMetrics dashboard\nETHLisbon\n\n\n"},"waku/updates/2023-11-06":{"title":"2023-11-06 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-11-06 Waku weekly §\nWaku Network Can Support 10K Users §\n\nachieved:\n\nfurther PostgreSQL optimisations nearing conclusion\nimplemented bridge to allow Status Community to move to static sharding with backwards compatibility towards default pubsub topic\nsolution for shared bootstrap nodes being filtered out in discv5 as more static shards are activated\nensured no unknown blockers from Waku’s side to start dogfooding in conversation with Status Communities\n\n\nnext:\n\ncontinue integration of static sharding in status-go.\ndeploy bridge for backwards compatibility\ndogfooding of Status Desktop with Status staging fleet. Will aim to create a small internal Waku community\n\n\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\nlack of confidence in simulation results: results so far exhibits various artifacts and anomalies seemingly related to tooling limitations. It is therefore difficult to draw certain conclusions re Waku scalability.\nlack of clarity in terms of Status fleet ownership, monitoring and maintenance, which is an integral part of the solution.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: fix in status-go to use correct unprotected pubsub topic for community point of contacts, added pubsub topic bridge feature to go-waku, stop filtering out bootnodes on discovery, minimize noise on logs when selecting peers and not having peers available.\nnext: deploy bridge between default pubsub topic and shard 32\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nSee 10k milestone update for PostgreSQL status.\nFirst version of the 10k-tool by DST is ready and is being tested with simulation running a small nim-libp2p/gossipsub binary.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under\nvac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\nlack of real world feedback/dogfooding: the complete static sharding solution involves significant changes to the Waku protocol and tech stack. Although each element is unit tested, dogfooding may hit corner cases in the integrated solution that cannot be foreseen/recreated in lab conditions.\n\n\n\nPostgreSQL in service node: Further optimisations §\n[nwaku] PostgreSQL\n\nachieved: Optimize select/Store queries by adding prepared statements. PR\nnext: Wrap up the Postgres optimizations. Summarize the performance comparison in a report.\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nStarting internal dogfooding of Waku Network: We have launched the proto-network and it is already possible to run a node in said network.\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.\nUncertainty as to how RLN membership mechanism would hinder application adoption, if memberships need to be distributed or obtained by registration, if staking is necessary to prevent abuse, etc.\n\n\n\n3.2: Basic DoS protection in production §\n[nwaku] feat: add rln to waku simulator instance\n\nachieved: integrated RLN, added Grafana dashboards, tested, merged and deployed\n\n1.4: Sharded peer management and discovery §\n[go-waku] feat: Service peer selection on specific shards\n\nachieved: on-demand peer discovery for service peer selection and new relay shard subscriptions\n\n2.3: Basic distributed Store services §\n[nwaku] feat: add new message_hash column to the archive protocol\n\nachieved: PR to support SQLite code to support messageHash attribute without interrupting the existing cursor-related functionality, id field stays for now. Skelton for sync in progress.\nnext:\n\nfinalize the SQLite messageHash attribute and add a research page about it.\nstart a research page about the sync mechanism for nWaku, doing request/reply a PoC on the same.\n\n\n\nQuality Assurance processes are in place - 2024-03-31 §\nSupport Many Platforms - 2024-04-30 §\nPresentation Readiness §\n[js-waku] feat: better support for development\n\nachieved: by going through basic flow identified errors that can or cannot be ignored;\nnext: working on improving log errors, aiming to complete in couple of days;\n\nOther Work §\nEnhancements §\n[js-waku-examples] feat: make light-js example a proper debugging tool\n\nachieved: added peer dropdown, list of connected peers, and button for querying past messages using store\nnext: will take on my first issue in js-waku\n\nBugs §\n[js-rln] bug: proof is not verified\n\nachieved: as per suggestion investigated if the roots are correct, seems found a fix;\n\nDocumentation §\n[docs.waku.org] Advanced docs for js-waku\n\nachieved: added createSubscription() docs in #128\nnext: tackle @waku/sdk deprecated namespace #131, create filter management docs\n\n[docs.waku.org] Node operator doc - cloud and advanced options\n\nachieved: updated nwaku config options in #128, added nwaku published MA option in #130\n\nChores §\n[nwaku] chore: bump vendor dependencies for 0.22.0\n\nachieved: updated dependencies, resolved conflicts, tested and raised PR\nnext: get PR reviewed, implement feedback and merge\n\nEcosystem Development §\n\n\nachieved:\n\nMultiple leads from ETHLisbon.\nSync call with The Graph.\njs-waku prioritizing.\nCreated Hackathon project with Waku at ETHLisbon.\nAwesome-waku updates.\n\n\n\nnext:\n\nReview RLN docs readiness for launch at DevConnect.\nWeb3privacy event preparation.\nWaku network soft-launch organisation.\nCreating tutorial videos.\nETHStaker gathering for gaining some awareness about node operator onboarding.\n\n\n"},"waku/updates/2023-11-13":{"title":"2023-11-13 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Network Can Support 10K Users §\n\nachieved:\n\nfinal PostgreSQL optimisations completed. Benchmarks published: https://www.notion.so/Postgres-e33d8e64fa204c4b9dcb1514baf9c582\nadded “debug nodes” with trace-level message logging to each Status fleet to allow for easier e2e message traceability\nconfirmed no unknown blockers from Waku’s side to continue dogfooding in conversation with Status Communities\n\n\nnext:\n\ncontinue integration of static sharding in status-go.\ndogfooding of Status Desktop with Status staging fleet. Will aim to create a small internal Waku community\n\n\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\nlack of confidence in simulation results: results so far exhibits various artifacts and anomalies seemingly related to tooling limitations. It is therefore difficult to draw certain conclusions re Waku scalability.\nlack of clarity in terms of Status fleet ownership, monitoring and maintenance, which is an integral part of the solution.\n\n\n\nTargeted dogfooding for Status Communities §\n\n\nachieved: deployed bridge between default pubsub topic and shard 32, added UseShardAsDefaultTopic node config option to indicate whether the client should use a shard or the default waku topic. Merged open status-go PRs related to sharding. Initial connection to peers + dns-discovery no longer blocks the login. Updated open status-desktop PR for dogfooding to take into account status-go latest sharding related changes.\n\n\nnext: get https://github.com/status-im/status-desktop/pull/12344 merged.\n\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nBasic Postgresql optimizations completed and benchmarks published. See 10k milestone.\nFirst version of the 10k-tool by DST is ready and is being tested with simulation running a small nim-libp2p/gossipsub binary.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under vac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\nlack of real world feedback/dogfooding: the complete static sharding solution involves significant changes to the Waku protocol and tech stack. Although each element is unit tested, dogfooding may hit corner cases in the integrated solution that cannot be foreseen/recreated in lab conditions.\n\n\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nStarted internal dogfooding of proto-network and started to work on documentation.\nProgressed on capability and sharding discovery.\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.\nUncertainty as to how RLN membership mechanism would hinder application adoption, if memberships need to be distributed or obtained by registration, if staking is necessary to prevent abuse, etc.\n\n\n\n3.2: Basic DoS protection in production §\n[go-waku] bug: handle errors generated in gm.rootTracker.UpdateLatestRoot(pair.Key.(uint64))\n\nachieved: task complete\n\n1.5: Launch and dogfood integrated public Waku Network MVP §\n\nachieved:\n\nLaunched team-internal CC dogfooding with nwaku nodes and RLN Sepolia contract\nIntroduced landing page and tutorials to join the network and publish using nwaku-compose\n\n\nnext:\n\nSoft launch of the network at Devconnect Istanbul\nExtend dogfooding to other clients (js-waku, go-waku)\n\n\n\n1.4: Sharded peer management and discovery §\n[nwaku] feat: Peer management with shard as a dimension\n\nachieved: discv5 filter peer by capability, misc. improvement w.r.t sharding and tests, sharded peer management improvement\nnext: run more simulations\n\n[go-waku] feat(discv5): filter peer by capability\n\nachieved: added capacility in discv5 to filter out peers that do not have waku2 ENR field\n\n1.2: Autosharding for autoscaling §\n[go-waku] feat: Changes to Store protocol APIs for Autosharding\n\nachieved: API updates for autosharding\nachieved: added functions for validating content topic, determining shard index and pubsub topic for autosharding\nnext: configure js-waku node to use either static or auto sharding\nblocker: need my PRs approved/merged. Also best to merge in other open PRs, especially https://github.com/waku-org/js-waku/pull/1697\n\nOther Work §\nEnhancements §\n[nwaku] chore: allow text/plain contentType for rest request’s body types\n\nnext: Allow text/plain contentType on RestApi is on PR, libwaku Fedora build issue\n\n[nwaku] chore: decouple listen and announced addresses\n\nachieved: implemented, tested and raised PR\nnext: get PR reviewed, implement feedback and merge\n\n[waku-rust-bindings] Peer discovery & management \n\nachieved: Worked mainly on rust-waku-bindings issues for go-waku.\nnext: Handle epic 2.2\n\n[go-waku] chore: # chore: remove --store-message-db-vacuum\n\nachieved: removed VACUUM functionality from go-waku, since it’s an operation that must be done by infra instead of being part of go-waku\n\nDocumentation §\n[docs.waku.org] Encryption documentation\n\nnext: begin work on encryption docs\n\n[docs.waku.org] Advanced docs for js-waku\n\nachieved: filter management docs\nnext: deprecated namespace docs #131\n\nChores §\n[nwaku] chore: bump vendor dependencies for 0.22.0\n\nachieved: finished and merged\n\nEcosystem Development §\n\nachieved: SpiffWorkflow x Waku sync\nnext: metrics, web3privacy meetup, DCxPrague talk\n"},"waku/updates/2023-11-20":{"title":"2023-11-20 Waku Weekly","links":[],"tags":["waku-updates"],"content":"2023-11-20 Waku weekly §\nWaku Network Can Support 10K Users §\n\nachieved:\n\nclosed last PostgreSQL issue for Store scalability\nconfirmed no unknown blockers from Waku’s side to continue dogfooding in conversation with Status Communities\nstarted team-internal dogfooding of a test community using static sharding\nstarted fleet ownership handover process: published guidelines/list of responsibilities - https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741\n\n\nnext:\n\ncontinue dogfooding of Status Desktop with Status staging fleet with test community\ntraining session to conclude fleet ownership handover: https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741\n\n\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\nlack of confidence in simulation results: results so far exhibits various artifacts and anomalies seemingly related to tooling limitations. It is therefore difficult to draw certain conclusions re Waku scalability.\nlack of clarity in terms of Status fleet ownership, monitoring and maintenance, which is an integral part of the solution.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: logout / login freeze, fix request on correct pubsub topic, and add missing shard information on community invite\nnext: dogfooding\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nClosed last Postgresql issue for basic Store scalability. See 10k milestone.\nAssisted DST in setting up initial tests with the ~1K tool. Currently still fine-tuning parameters, ensuring results are consistent, etc. for smaller configurations.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under\nvac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\nlack of real world feedback/dogfooding: the complete static sharding solution involves significant changes to the Waku protocol and tech stack. Although each element is unit tested, dogfooding may hit corner cases in the integrated solution that cannot be foreseen/recreated in lab conditions.\n\n\n\nWaku Network Gen 0 - 2023-12-01 §\n1.4: Sharded peer management and discovery §\n[nwaku] chore: improve cluster id, shards, topics flow\n\nachieved: Various tests updates and fixes.\nnext: Figure out why CI passes locally only.\n\n1.2: Autosharding for autoscaling §\n[nwaku] chore: allow fetching cached messages by content or pubsub topic\n\nachieved: failed refactor of message cache\nnext: a better and simpler message cache\n\n[js-waku] feat: Autosharding API for req-resp protocols\n\nachieved: derive pubsub topic from content topic in encoders/decoders when autosharding is specified\nnext: node config should specify static sharding or autosharding. implement autosharded topics in all req-resp protocols\n\nSupport Many Platforms - 2024-04-30 §\nPresentation Readiness §\n[js-waku] feat: node connection state\n\nachieved: modified ConnectionManager to track connection state. exposed through read function and new event\nnext: resolve any remaining feedback\n\nOther Work §\nEnhancements §\n[nwaku] chore(REST): adding to /admin/v1/peers response lightpush and filter v2 peer info\n\nachieved: implemented, tested and raised PR\nnext: get PR reviewed, implement feedback and merge\n\n[nwaku] chore: allow text/plain contentType for rest request’s body types\n\nachieved: Better support for js-waku using RestApi: Allow text/plain contentType\nnext: Bandwidth management preparation\n\n[nwaku] chore: decouple listen and announced addresses\n\nachieved: got the PR reviewed, implemented feedback and merged\n\nEcosystem Development §\n\nachieved: two talks last week. Logos + Waku at Web3Privacy meetup and RLN at DCxPrague\nnext: afk for a week\n"}} \ No newline at end of file +{"acid/index":{"title":"Comms Roadmap Overview","links":["acid/milestones-overview","tags/acid-updates"],"tags":["overview"],"content":"Welcome to the Comms Roadmap Overview\n\nMilestones\nweekly updates\n"},"acid/milestones-overview":{"title":"Comms Milestones Overview","links":[],"tags":["milestones"],"content":"\nComms Roadmap\nComms Projects\nComms planner deadlines\n"},"acid/updates/2023-08-02":{"title":"2023-08-02 Acid weekly","links":[],"tags":["acid-updates"],"content":"Leads roundup - acid §\nAl / Comms\n\nStatus app relaunch comms campaign plan in the works. Approx. date for launch 31.08.\nLogos comms + growth plan post launch is next up TBD.\nWill be waiting for specs for data room, raise etc.\nHires: split the role for content studio to be more realistic in getting top level talent.\n\nMatt / Copy\n\nInitiative updating old documentation like CC guide to reflect broader scope of BUs\nBrand guidelines/ modes of presentation are in process\nWikipedia entry on network states and virtual states is live on\n\nEddy / Digital Comms\n\nLogos Discord will be completed by EOD.\nCodex Discord will be done tomorrow.\nLPE rollout plan, currently working on it, will be ready EOW\nPodcast rollout needs some\nOverarching BU plan will be ready in next couple of weeks as things on top have taken priority.\n\nAmir / Studio\n\nStarted execution of LPE for new requirements, broken down in smaller deliveries. Looking to have it working and live by EOM.\nHires: still looking for 3 positions with main focus on developer side.\n\nJonny / Podcast\n\nPodcast timelines are being set. In production right now. Nick delivered graphics for HiO but we need a full pack.\nFirst HiO episode is in the works. Will be ready in 2 weeks to fit in the rollout of the LPE.\n\nLouisa / Events\n\nGlobal strategy paper for wider comms plan.\nTemplate for processes and executions when preparing events.\nDecision made with Carl to move Network State event to November in satellite of other events. Looking into ETH Lisbon / Staking Summit etc.\nSeoul Q4 hackathon is already in the works. Needs bounty planning.\n"},"acid/updates/2023-08-09":{"title":"2023-08-09 Acid weekly","links":[],"tags":["acid-updates"],"content":"Top level priorities: §\nLogos Growth Plan\nStatus Relaunch\nLaunch of LPE\nPodcasts (Target: Every week one podcast out)\nHiring: TD studio and DC studio roles\nMovement Building: §\n\nLogos collective comms plan skeleton ready - will be applied for all BUs as next step\nGoal is to have plan + overview to set realistic KPIs and expectations\nDiscord Server update on various views\nStatus relaunch comms plan is ready for input from John et al.\nReach out to BUs for needs and deliverables\n\nTD Studio §\nFull focus on LPE:\n\nOn track, target of end of august\nreview of options, more diverse landscape of content\nEpisodes page proposals\nPlayers in progress\nrefactoring from prev code base\nstructure of content ready in GDrive\n\nCopy §\n\nContent around LPE\nContent for podcast launches\nStatus launch - content requirements to receive\nOrganization of doc sites review\nTBD what type of content and how the generation workflows will look like\n\nPodcast §\n\nGood state in editing and producing the shows\nFirst interview edited end to end with XMTP is ready. 2 weeks with social assets and all included.\nLSP is looking at having 2 months of content ready to launch with the sessions that have been recorded.\n3 recorded for HIO, motion graphics in progress\nFirst E2E podcast ready in 2 weeks for LPE\nLSP is looking at having 2 months of content ready to launch with the sessions that have been recorded.\n\nDC Studio §\n\nBrand guidelines for HiO are ready and set. Thanks Shmeda!\nLogos State branding assets are being developed\nPresentation templates update\n\nEvents §\n\nNetwork State event probably in Istanbul in November re: Devconnect will confirm shortly.\nProgram elements and speakers are top priority\nHackathon in Seoul in Q1 2024 - late Febuary probably\nJarrad will be speaking at HCPP and EthRome\nGlobal event strategy written and in review\nLou presented social media and event KPIs on Paris event\n\nCRM & Marketing tool §\n\nGet feedback from stakeholders and users\nPM implementation to be planned (+- 3 month time TBD) with working group\nLPE KPI: Collecting email addresses of relevant people\nCareful on how we manage and use data, important for BizDev\nCareful on which segments of the project to manage using the CRM as it can be very off brand\n"},"acid/updates/2023-08-29":{"title":"2023-08-29 Comms weekly","links":[],"tags":["acid-updates"],"content":"Leads roundup - acid §\nAl - Comms §\n\nLPE & Podcast are almost there. Content needs to be polished and reviewed by Carl and Jarrad. Might have an impact on the deadline but we start testing phase tomorrow.\nPlan for marketing and promotion of the podcast needs a bit more work. Teasers for Snowden will be released. Next episode drops next week.\nStatus app comms campaign. We are aligned with John and Status team. Needs pre-launch work for content and pending some items and confirmations from John.\nDigital designer will be joining us soon for Content team. We are still looking for a Motion designer.\nTownhall: Dmitry and Santiago will be talking re: Codex + Logos culture.\n\nAmir - Tech and Design §\n\nLPE is ready. Content is being populated. Soft launch is 30/08. Then stress test, debug, etc.\nNotion page is up and running for listing errors, bugs and feedback. Amir will move to GitHub https://www.notion.so/f9fef49cc74c46b19ceb9c14a2003062?v=3eb563f28fc448bd836d16da1272d620&pvs=4\nWiki: codebase will be ready in a day or two, then once infra team deploys we have kick off meeting for structure, content etc. Then design team can redesign based on what we need. Timeframe: end of September\n\nMatt - Copy §\n\nContent from the LPE is getting there, pending review as mentioned above.\nCleaning up the documentation sites etc.\nStatus comms campaign is coming so articles in planning will be drafted and\n\nChristian - Podcast §\n\nPodcast release plan is being solidified and reviewed https://docs.google.com/document/d/1ppSb_Fkdw3iirwzlEgTvYpkq3n00ds4Xz5KE3mgqA-E/edit?usp=sharing\nReview process is set up and open for feedback.\n\nNick - Content §\n\nDecks for townhall are coming and will be ready for next week.\nImages for LPE content is being vetted. We are looking to establish a style for the first article to set the tone for the following. This is holding it back a bit but once it is set we can move it from there.\n\nLouisa - Events §\n\nBy the end of next week we will launch global event strategy post-review. Includes templates and structures for the future.\nNetwork State Event needs to lock down the potential event speakers, how to communicate with them and basically get a review. Nimbus and Waku and Codex will be there. We need to fix the program and agree on it. Venues shortlisted by the end of the week.\n8 agencies have been briefed as event organisers. Needs to be locked and set by end of week.\nETH Rome, Logos and Waku are sponsoring and Jarrad is talking. Paralelni Polis is happening late September. Working on the details to hit production deadlines.\nBeginning work on hacakthon in Seoul end of February 2024.\n\nMovement Building - Santiago §\n\nComms plans LPE, Status and Logos Community plans are on good track. Carl reviewed and asked for 90 day plans plus timelines.\nLogos community structure is being developed to guide people through an engagement/leadership ladder that serves our purpose. First community coming in will be our testing phase pre-growth.\nLPE launch plan is being reviewed and has a budget verbally approved to push via paid ads. Focus mostly on Snowden on episode as a roundabout way to support awareness for Logos.\nBU Plans, pretty much done, will send them to Al asap for review.\n"},"acid/updates/2023-09-21":{"title":"2023-09-18 Acid Update","links":[],"tags":["acid-updates"],"content":"Overview/Priorities §\n\nAl departure\n\nShort term - We need to stabilise, Al brought a lot of value, we may have to step up a little bit, will meet with Carl and Jarrad weekly.\nLong term - positive changes internally, open culture, open feedback, etc.\nTownhalls - Christian will be point of contact. With Santiago to support. The idea is plan 3-6 months in advance.\nComms strategy - Adjusting it to be more strategic and concise. with focus on Brand Awareness & BU Needs, measuring Impact & clear timeline.\nVirtual office - Available for anyone to join Santiago and Ned to discuss, ask questions, hangout.\nTo team leads: please implement feedback mechanisms that are safe for people. Open up first about shortcomings and promote healthy criticism and exchange. Copy the After Action Review model if necessary for each project delivery and a regular one at your discretion. We want to be better together and trust each other. It is a marker of a successful organisation.\n\n\n\nAmir - Tech & Design §\n\nImprovements on LPE. RSS feed, Discord bot integration, X threads can be previewed\nIntegration of Odoo for email client is with infra.\nLogos System Design (LSD) is being optimised.\n\nMatt / Sterlin - Copy §\n\nPlethora of words to the LPE. Focus there. Make sure the content looks and feels good. Sterlin feels writing looks good in relation with other similar projects.\nMatt and Sterlin are working on the Status blog posts for the upcoming launch.\nAmelia is working on the BU updates.\nRick is the social media master, making really good progress on setting up a solid base and communication with the BUs in regards to their needs.\n\nNick - Digital Content Studio §\n\nNew meeting with Jarrad to get his involvement in the day to day things, he has clarity re: guests, shifting content and style. Objective is to have conversations that inform our thinking about network states, governance, etc. Cater content for Jarrad to build his skill as a speaker and host.\nProduction value is an important improvement point.\nLooking for more people to join as motion designer for video help.\nSwag for ETH Rome needs feedback but is on it’s way and on time.\nPodcast: we have a solid buffer of interviews for HiO and Logos that allows us to have time for strategic changes.\nPodcast: New stream/recording subscription needs to be approved by someone else to move forward.\n\nSantiago - Movement Building §\n\nComms strategies - overall, as a master guideline, we should be creating a movement around network states and not a network state, as a key player and a thought leader. From people developing privacy tech, charter cities, etc. To invest all our resources to creating spaces (physical x digital) for the different parties.\nJarrad: We want authentic organic interaction and conversations like a learning community.\nNick feedback : To approach which conversations/guests are more appropriately placed in which formats, because production time need to be mindful (podcast, twitter space, etc.)\nLPE launch awaits Comms strategy realignment.\n\nLouisa - Events §\n\nHolding back on global guidelines and event strategy once comms strategy is in place.\nJarrad is speaking at POW and HCCP. Decks coming ASAP.\nETH Rome: investing in bounties, smaller meetups are coming. We need booth, merch, swag design this week. Railgun collab with Waku.\nIstanbul: Just some alignment needed re: names and others. Vac, Nimbus and Waku will be there, think about how to overlay design work.\n"},"acid/updates/2023-10-03":{"title":"2023-10-10 Comms weekly","links":[],"tags":["acid-updates"],"content":"Overview/Priorities §\n\nComments from the BUs about blockers and miscommunications - Reevaluation of our comms strategy: BUs are responsible for DevRel, BD, and technical content. We’re responsible for QC of outgoing content (wordsmiths, video editing, and packaging) and non-technical content. This will be communicated with them and consolidated along with the strategy asap.\nNew Mantra: Brand awareness and Learning Communities, which are both measurable by proxy. This means we focus more on performance and growth KPIs and reporting these clearly to C/J.\nWith clear success metrics in place + costs and resources used we can finally focus on optimise our efforts and use it as a way to guide conversations about prioritising requests. This includes things like revisiting the creation of swag for each event etc.\nNew champions model for each BU. https://miro.com/app/board/uXjVPOFj6t8=/. We have an account manager/ implement, test it and iterate as soon as possible\n\nAmir - Tech & Design §\n\nLogos System Design new version (design) is done. Development continue with Joao. Will move on to documentation.\nLPE project is done. Optimising the scoring system for the search pending a lot of content. V1 is officially done. Renamed to Network State Press\nIhor working on sketches and directing of Institute of Free Tech. Will share soon.\nBDP - brand design portal, we designed and managed the dev before but now on hold. For now focus on Brand Guidelines in Docusauraus for BUs.\n\nNick - Digital Content Studio §\n\nPresentations, swag work with Veronika & Video for events.\nJonny has presented a few options for the podcast\n\nChristian - Podcast §\n\nOpen to doing Twitter spaces, in another category to keep it more streamlined and controlled. He wants interactive discussions, open quesitons, brainstorming etc.\nCurrently QC of Snowden\nNo new interviews, just doing checks of Ameen, Baylina and Assange. Will have it ready\nJarrad will present the townhall\n\nMatt - Copy §\n\nStatus articles - Sterlin and Matt.\nBU Docs sites - Amelia. - good to go.\nMode of presentation guidelines (part of brand guidelines) for BUs - by Matt.\nDevelp site for Nimbus - Rick\nIFT landing page - Rick\nCollectively, series of articles about beginner’s guide to Network States.\n\nSantiago - Movement Building §\n\nFocusing on brand awareness and growth - we will set up reporting structures for Carl and Jarrad that are numbers based in relation to cost effectiveness.\nOdoo Email tool is with infra - configuration needed of the external SMTP server.\nFinding a PR moments for the raise.\nNext week and a half will be focused on updating the Logos server to have a proper onboarding strategy to optimise for a learning community experience. Will meet with Eddy and Jen to do this. Jen is currently updated all the all the Discord servers.\n\nLouisa - Events §\n\nPOW and HCCP done - challenge not enough brand awareness\nMetrics and dashboards to get a clear impact on KPIs related to events.\n\nJ&F - Project Management §\n\nAssessment for workspace, work/information flow and dashboard optimization intra and inter teams and projects.\nOrganize around BUs and content pipelines\nTools assessment\n"},"acid/updates/2023-10-17":{"title":"2023-10-25 Comms weekly","links":[],"tags":["acid-updates"],"content":"ACID ROUND UP - OCT. 17\nOverview/Priorities\n\nWorkflows / Champions model: Reporting structure necessary.\nReporting to C+J: ClickUp dashboards.\nBrand Guidelines: In process of improvements.\nIstanbul NSF event cancelled. Will find more opportunities in first half of 2024.\n\nTech & Design\n\nLSD finetuning.\nNomos team requested executable code inside documentation website.\nDocumentation for Docusaurus site. Every BU can deploy their own documentation\nIntegrating the Logos job listings on IFT website - working with JB and Flo.\nNo integrated requirement checklist for what the roadmap should be for all the org. It is not clear if this is one project or several. Different reporting structures per BU makes this complex. Focus on task / “bounty” list\nFinish up guidelines pages\n\nDigital Content Studio\n\nAna (new visual designer) joined last week. Helping on branding designs.\nPodcast templates for cutout animations are good to go. Match options for outputs.\nTwitter Spaces has an overlap with podcast pipeline. Jarrad also wants a easy going convo type setup for his own thinking and this is a bit. Needs to sync with MF.\nMatt and Nick sign off on LPE Article Headers/Social images\n\nPodcast\n\nQuality control got version of Jordi Baylina episode with new graph. Will be ready soon.\nSnowden episode needs a change in the graph at the beginning and needs date change when we know it will launch\n\nCopy\n\nDoc sites are all live except for Waku - pending some small changes.\nNimbus websites might be getting close to launch.\nCarl asked for a beginner series for the network state concept, including a call to action that makes it easy for them to get to the beginner friendly content.\nIFT copy is in Carl’s hands and we are waiting for review.\n3 tech one pagers for Matt and the fundraising team are done.\n\nMovement Building\n\nTwitter Spaces idea for each BU is being discussed internally. Ideas to use https://docs.google.com/document/d/1yOPPsZqKzf6__zuCsFYRsDDkk-lYX—vjRoz6e7OYK4/edit\nWorking on events stuff and postponing Network State Forum event for next year\nWe are running and testing ads on promoting our Twitter Spaces and have pivoted to growing our brand following online to lead into a big event. Potentially hackathon around the all hands meeting etc.\nPR company: onboarding is happening, they are asking good questions there\nStatus: Launch the community campaign. John wants to launch Nov 1.\nPaid Twitter Ads: Carl asked to run test ad. 2k for Logos space tweet. so far, 800k impressions. 125 followers gained so far. We will use this for benchmarking.\nNSP: held up as Jarrad is reviewing content and Carl is pending.\nWaku: feedback from Rome, mentioned that people come to them what is Waku/Status/Logos and how does everything fit. They don’t have a clear answer. We are fixing this.\nTalking to Lou re: events, we can approach Waku marketing as short term campaigns initially November-December. Will propose an awareness campaign to see what can be done with existing resources.\n\nEvents\n\nDifferent scenarios for Istanbul. Looking at whether we co-sponsor EthGlobal Istanbul.\nWaku will be doing EthGlobal India. EthGlobal Istanbul too expensive (40k) for Waku alone so we might co-sponsor.\nSpeaking to EthDenver for next year + an Africa strategy for Waku.\nSet up and manage events and KPIs and reporting in Click Up via forms that external people to the comms team can fill in.\nWe need a proper lead time for activation campaigns to maximise participation, social awareness etc. This is in planning.\nVideo footage from EthCC Paris event still unedited. If there are requests, we can edit it for that purpose.\nWriting a brief for event managers\n\nProject Management\n\nWorkflows reviews and optimizations based on strategy, goals and champions model\nPM and reporting set-up in ClickUp\n"},"acid/updates/2023-10-24":{"title":"2023-10-25 Comms weekly","links":[],"tags":["acid-updates"],"content":"Overview/Priorities\n\nWe are on the right track re: reporting, champions model and outputs. Full update here: https://doc.clickup.com/9009185920/p/h/8cfuh40-13894/965f96f62ea5053\n\nTech & Design\n\nIFT website desktop version almost ready\nLogos Brand Guidelines are being updated\nDocusauraus updates - workshop for BUs to enable them to do content updates\nJobs will be added to every BU website and IFT\n\nDigital Content Studio\n\nContent guidelines in the works, summarising everything and putting it all together to make it functional.\nSwag and presentations are coming in according to plan - nothing of note.\nJonny working on proposal for NPS UX/structure in Figma based on conversation with nick and Amir yesterday\n\nPodcast\n\nPulling together detailed rollout doc with assets and exact copy for Al to send to Snowden and Assange for approvals and coordination.\nGet Stella out - audio quality is much better than Snowden’s so it’s good to go.\n\nCopy\n\nIFT is ready and getting published by EOW.\nNo news for copy re: NSP. Soft launch projected for this week for NSP.\nBeginner friendly piece by Rick for NSP is in production.\nEvent promotion for Logos EthGlobal Pragma presence.\nSocial buffer for Logos is set and ready. In depth threads re: philosophy and connection with each part of the tech stack.\n\nMovement Building\n\nLogos Discord structure: https://docs.google.com/document/d/1N0vgj7GIHllJ9YI912WdMetSEELMBzuWbRKl8NXjXCA/edit#heading=h.ebfdikfy2j9v\nLogos Forum gets traffic due to paid ads, please pay attention and move discussions there as much as is natural.\nFeedback from Jarrad: we need to focus on creating shareable cultural artifacts. For example, transcribing Twitter spaces into forums. Lazar suggested using the radical _anarchy salon content too.\nSoft launch of NSP will happen this end of week. Next week we go with main launch.\nTwitter paid ads were running on space. Report is complete and ready to be shared.\nGrowth strategy with Logos paid ads and Network state paid ads will be completed soon and shared with all.\nLegal: long story short is they will ask to have the least possible changes to the privacy policy but changes we asked for should be ready to be implemented.\n\nEvents\n\nWaku will be the main brand at ETHGlobal Istanbul to avoid confusion and to optimise\nLogos will be present at Pragma - we maximise brand awareness and want to test\nWider event marketing campaign needs to be clear. Distinct posts, tracking impact.\nDashboard on ClickUp for KPIs is in the works. Focus on optimising event attendance vs cost and resources.\n2024 is in the works. Africa events outline for Waku, ETH Denver already contacted.\n\nProject Management\n\nSetting up workspace, PM and reporting in click up with teams and get audit with Clickup experts. Onboarding next week.\n"},"codex/milestones-overview":{"title":"Codex Milestones Overview","links":[],"tags":["milestones-overview"],"content":"Milestones §\n\nZenhub Tracker\nMiro Tracker\n"},"codex/monthly-reports/2023-oct":{"title":"2023 October Codex Monthly Report","links":["codex/updates/2023-10-23"],"tags":["monthly-report","codex"],"content":"Executive Summary §\nIn the first half of the month, the team had an Offsite which focused on concretizing solutions around the MVP and planning out the required work to deliver the MVP by the end of the year.\nAll work after the offsite this month has been focused on the tasked out work that was planned during the offsite.\nThe Ethereum Foundation collaboration on Data Availability Sampling is coming to an end, all of the work associated with it was summed up here.\nKey Updates §\nPersonnel §\nA new job role was put up for a Technical Business Development Lead for Codex. This work will be dedicated to establishing and maintaining relationships with business partners interacting with the Codex Network. As the MVP and testnet get closer to launch, it is expected that these core relationships will need to be forged and cultivated.\n\nlots of upskilling and training new CCs (all people on client < 4 months old).\n\nMilestones §\nThere was only one weekly update this month so it can be referenced for milestone updates, the link is down below.\nThe Ethereum Foundation collaboration on Data Availability Sampling is coming to an end, all of the work associated with it was summed up here. A subsequent report will be created that looks at the pros and cons of the engagement to inform both other Logos projects and future similar Codex engagements.\n\nfat trimmed that wasn’t required for MVP (maybe get a list of these things).\n\nPerceived Changes in Project Risk §\nThe project maintains its track to deliver the Codex MVP by the end of the year. The offsite that took place mapped out the specific work to be done, and who is tasked to do it within the team.\nmore confident that it will be delivered on time based on scope of work and current team makeup and planning from off-site\nthere is no expected delay to delivering the MVP and testnet by the end of the year. and debugging infra for monitoring failures with testnet.\nFuture Plans §\nInsight §\nThe Codex roadmap has yet to be ported over to this website, but now that the offsite is complete and the roadmap is more concrete, that transition should happen quickly within the next month.\nThis should allow us to ramp up the automated monitoring and create development activity dashboards. It is hoped that we have a development dashboard established by next month and a section within the monthly report that describes quantitative measurements of project development.\nProject §\nall focus is on current MVP and associated testnet\ncurrent MVP is minimum marketplace integrated with client and proving scheme. Proving scheme needs coding out and plugged into client. Need client itself to reflect recent changes in merkelization and block transfer.\nget testnet up and running, internal (logos/status) dogfooding for this year’s MVP, then to build monitoring and participation metrics over next year to prep for mainnet launch.\nSources and Useful Links §\nWeekly Reports\n\n2023-10-23\n"},"codex/monthly-reports/2023-sept":{"title":"2023 September Codex Monthly Report","links":["codex/updates/2023-09-15","content/codex/updates/2023-09-29"],"tags":["monthly-report","codex"],"content":"Executive Summary §\nSeptember updates for the Codex project were main focused on the ongoing research and analysis of the proofing schemes and their impact on the overall architecture and network economy.\nKey Updates §\nPersonnel §\nA new Business Development (BD) job description was posted and candidates are currently being interviewed. This role is expected to help facilitate strategy around the much needed partnerships for Codex and liaise with the other BD related resources we have within Logos to ensure efficient communications.\nMilestones §\nThe Codex team is broken up into 5 sections, and the weekly reports give details on how each of them have performed. Currently the Milestone definitions are not in line with this reporting process and will be worked on in the subsequent month. The teams are broken up into the following sections:\n\nClient\nInfra\nMarketplace\nResearch\nDAS\n\nBelow is summary of key updates to these sections over the month of September 2023\nClient §\nThe client continues to push towards Milestone 1.3: Codex v1.0 - Katana, which is slotted to be completed by the end of the year. Significant work has been done on merkelization which is required in order to integrate the proving system, and can be followed in this working branch.\nThe Block Exchange protocol got some attention and refinement. Notes on the associated thoughts can be found in these two writeups:\n\nBlock Discovery Problem\nCodex Swarm Overlays\n\nIn an effort to focus on the critical development path, this work is paused in lieu of attention on the distributed systems testing work.\nProgress was made on the ability for Codex to manage asynchronous and threaded disk IO. In the process of doing this work, a bug within Nim’s SharedPtr was discovered and fixed.\nInfra §\nA Grafana and Kibana instance were deployed in order to facilitate the various testing being done.\nMarketplace §\nIn order to alleviate a concurrency issue with Data Availabilities in the contract, a Reservation System has been proposed and worked on. This removes the previous constraint that current downloads was limited by the number of Availabilities.\nResearch §\nThe Codex Whitepaper v0.1 was drafted and scheduled for release in October 2023. It is currently under review and improving based on feedback.\nThere has been a large discussion this month around Erasure Coding (EC) for sampling. An analysiswas performed which looked at the various effects Erasure Coding schemes have on the sampling process and associated data guarantees. A quote of the conclusion on parameter choices is below:\n\n\n \n Quote \n \n \n\nwe cannot have a small slot size, because that would mean too many proofs by a node (≈ 1 Tb seems to be a minimum)\nwe cannot have a too small block size, because the Merkle tree of the commitments will take too much space (say a minimum of 1024 bytes)\nwe cannot have a too big “checked sample” size, because we cannot do proofs for large amount of data (say a maximum of 65536 bytes)\nwe cannot have too much sampling checks per slot, because we cannot do proofs for many samples (depends on the block size and SNARK tech)\nwe probably want as big N, K parameters as possible, but actual implementations have limit\n\n\nA short review of the Interleaving Schemes for Multidimensional Cluster Errors was performed here and some general notes on Erasure Coding as it pertains to Codex was written up here. Much of these thoughts is being captured in the Erasure Coding Proofing document here. The conclusion section (at time of writing) is copied here for convenience:\n\n\n \n Quote \n \n \nIt is likely that with the current state of the art in SNARK design and erasure coding implementations we can only support slot sizes up to 4GB. There are two design directions that allow an increase of slot size. One is to extend or implement an erasure coding implementation to use a larger field size. The other is to use existing erasure coding implementation in a multi-dimensional setting.\nTwo concrete options are:\n\nErasure code with a field size that allows for 2^28 shards. Check 20 shards per proof. For 1TB this leads to shards of 4KB. This means the SNARK needs to hash 80KB plus the Merkle paths for a storage proof. Requires custom implementation of Reed-Solomon, and requires at least 1 GB of memory while performing erasure coding.\nErasure code with a field size of 2^16 in two dimensions. Check 160 shards per proof. For 1TB this leads to a shards of 256 bytes. This means that the SNARK needs to hash 40KB plus the Merkle paths for a storage proof. We can use the leopard library for erasure coding and keep memory requirements for erasure coding to a negligable level.\n\n\nIt appears as though the team is preferring to go with the multi-dimensional approach to EC.\nDAS §\nWork continues on the DAS research in coordination with the Ethereum Foundation (EF). As a result of SBC, a blog post was written by the EF that discussed a forward thinking proposal for PeerDAS - a simpler DAS approach using battle-tested p2p components which the team has contributed to (referenced inside). Conversations of relevancy continue.\nA Codex Blog post was published discussing two by-products of the DAS research: the characterization of big block diffusion latency on the existing Ethereum Mainnet and the existence of big organic blocks on Ethereum Mainnet and its implications. The conclusion is quoted below:\n\n\n \n Quote \n \n \nWe have discovered a large number of big blocks (>250 KB) that occur organically every day in the Ethereum Mainnet. We have measured the propagation time of those blocks in three different world regions and compared their latency based on geographical location as well as block size. We have analysed how these propagation differences are reflected in the five CL clients separately, as they have different ways of reporting blocks. The empirical results measured in Ethereum Mainnet and presented in this work give us the first clear idea of how block propagation times might look when EIP-4844 is deployed, and 1 MB blocks become the standard and not the exception.\nIn the future, we plan to continue with these block propagation measurements and monitor the behaviour of big blocks in the Ethereum network. Additionally, we want to help different CL clients harmonise their event recording and publication systems in order to be able to compare CL clients between them.\n\nDiscussions with Felix Lange began around some fixes for Discv5.\nOther §\nA Codex YouTube channel has been setup and many tutorial videos and conference talks were uploaded. Go like and subscribe!\nPerceived Changes in Project Risk §\nIn an effort to meet the MVP launch by the end of the year, significant resources have been diverted to engineering efforts. Jessie has taken on more responsibility in the administration and project management duties while Dmitriy has started to focus more on the research and engineering needs\nThe ongoing research around the Data Availability Proof system still has potential to have drastic changes to the overall architecture of the system and associated resource costs of the various participants within the Codex Network. It is unclear how “locked in” parts of the system are that are included in the MVP launch.\nFuture Plans §\nInsight §\nBecause of the mismatch of weekly updates with Milestone definitions, it is difficult to assess the impact of any given update. Next month should have all milestone definitions within this site and a reporting structure that is more intuitively associated with it. It has been noted that the current structure makes it difficult to track cross-team work which the changes next month hope to fix.\nA Logos Collaborations section will be included next month to highlight differences in alignment with the Logos Collective as well as cross project collaboration updates.\nThe reporting process has missed a lot of work around the network simulation and modeling of Codex, which we expect to be corrected by next month by previously mentioned actions.\nDepending on the uptake and viability of the Waku reporting process to other projects, then a myriad of quantitative measures will be included in the next monthly report.\nProject §\nNEED INPUT HERE\nSources and Useful Links §\n\nZenhub tracker - mapping of milestones -> epics -> issues\nMay 2023 - Codex Project Status Report - list of risks and details on the milestones\n\nWeekly Reports\n\n2023-09-15\n2023-09-29\n"},"codex/overview":{"title":"Codex Roadmap Overview","links":["codex/monthly-reports/2023-sept","codex/milestones-overview","tags/codex-updates"],"tags":["overview"],"content":"Welcome to the Codex Roadmap Overview\n\n2023 September Report\nMilestones\nweekly updates\n"},"codex/updates/2023-07-21":{"title":"2023-07-21 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex update 07/12/2023 to 07/21/2023 §\nOverall we continue working in various directions, distributed testing, marketplace, p2p client, research, etc…\nOur main milestone is to have a fully functional testnet with the marketplace and durability guarantees deployed by end of year. A lot of grunt work is being done to make that possible. Progress is steady, but there are lots of stabilization and testing & infra related work going on.\nWe’re also onboarding several new members to the team (4 to be precise), this will ultimately accelerate our progress, but it requires some upfront investment from some of the more experienced team members.\nDevOps/Infrastructure: §\n\nAdopted nim-codex Docker builds for Dist Tests.\nOrdered Dedicated node on Hetzner.\nConfigured Hetzner StorageBox for local backup on Dedicated server.\nConfigured new Logs shipper and Grafana in Dist-Tests cluster.\nCreated Geth and Prometheus Docker images for Dist-Tests.\nCreated a separate codex-contracts-eth Docker image for Dist-Tests.\nSet up Ingress Controller in Dist-Tests cluster.\n\nTesting: §\n\nSet up deployer to gather metrics.\nDebugging and identifying potential deadlock in the Codex client.\nAdded metrics, built image, and ran tests.\nUpdated dist-test log for Kibana compatibility.\nRan dist-tests on a new master image.\nDebugging continuous tests.\n\nDevelopment: §\n\nWorked on codex-dht nimble updates and fixing key format issue.\nUpdated CI and split Windows CI tests to run on two CI machines.\nContinued updating dependencies in codex-dht.\nFixed decoding large manifests (PR #479).\nExplored the existing implementation of NAT Traversal techniques in nim-libp2p.\n\nResearch §\n\nExploring additional directions for remote verification techniques and the interplay of different encoding approaches and cryptographic primitives\n\nhttps://eprint.iacr.org/2021/1500.pdf\nhttps://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html\nhttps://eprint.iacr.org/2021/1544.pdf\n\n\nOnboarding Balázs as our ZK researcher/engineer\nContinued research in DAS related topics\n\nRunning simulation on newly setup infrastructure\n\n\nDevised a new direction to reduce metadata overhead and enable remote verification https://github.com/codex-storage/codex-research/blob/master/design/metadata-overhead.md\nLooked into NAT Traversal (issue #166).\n\nCross-functional (Combination of DevOps/Testing/Development): §\n\nFixed discovery related issues.\nPlanned Codex Demo update for the Logos event and prepared environment for the demo.\nDescribed requirements for Dist Tests logs format.\nConfigured new Logs shipper and Grafana in Dist-Tests cluster.\nDist Tests logs adoption requirements - Updated log format for Kibana compatibility.\nHetzner Dedicated server was configured.\nSet up Hetzner StorageBox for local backup on Dedicated server.\nConfigured new Logs shipper in Dist-Tests cluster.\nSetup Grafana in Dist-Tests cluster.\nCreated a separate codex-contracts-eth Docker image for Dist-Tests.\nSetup Ingress Controller in Dist-Tests cluster.\n\n\nConversations §\n\nzk_id — 07/24/2023 11:59 AM\n\n\nWe’ve explored VDI for rollups ourselves in the last week, curious to know your thoughts\n\n\ndryajov — 07/25/2023 1:28 PM\n\n\nIt depends on what you mean, from a high level (A)VID is probably the closest thing to DAS in academic research, in fact DAS is probably either a subset or a superset of VID, so it’s definitely worth digging into. But I’m not sure what exactly you’re interested in, in the context of rollups…\n\n\n\nzk_id — 07/25/2023 3:28 PM\nThe part of the rollups seems to be the base for choosing proofs that scale linearly with the amount of nodes (which makes it impractical for large numbers of nodes). The protocol is very simple, and would only need to instead provide constant proofs with the Kate commitments (at the cost of large computational resources is my understanding). This was at least the rationale that I get from reading the paper and the conversation with Bunz, one of the founders of the Espresso shared sequencer (which is where I found the first reference to this paper). I guess my main open question is why would you do the sampling if you can do VID in the context of blockchains as well. With the proofs of dispersal on-chain, you wouldn’t need to do that for the agreement of the dispersal. You still would need the sampling for the light clients though, of course.\n\n\ndryajov — 07/25/2023 8:31 PM\n\nI guess my main open question is why would you do the sampling if you can do VID in the context of blockchains as well. With the proofs of dispersal on-chain, you wouldn’t need to do that for the agreement of the dispersal.\n\nYeah, great question. What follows is strictly IMO, as I haven’t seen this formally contrasted anywhere, so my reasoning can be wrong in subtle ways.\n\n(A)VID - dispersing and storing data in a verifiable manner\nSampling - verifying already dispersed data\n\ntl;dr Sampling allows light nodes to protect against dishonest majority attacks. In other words, a light node cannot be tricked to follow an incorrect chain by a dishonest validator majority that withholds data. More details are here - https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html ------------- First, DAS implies (A)VID, as there is an initial phase where data is distributed to some subset of nodes. Moreover, these nodes, usually the validators, attest that they received the data and that it is correct. If a majority of validators accepts, then the block is considered correct, otherwise it is rejected. This is the verifiable dispersal part. But what if the majority of validators are dishonest? Can you prevent them from tricking the rest of the network from following the chain?\nDankrad Feist\nData availability checks\nPrimer on data availability checks\n\n\n[8:31 PM]\nDealing with dishonest majorities §\nThis is easy if all the data is downloaded by all nodes all the time, but we’re trying to avoid just that. But lets assume, for the sake of the argument, that there are full nodes in the network that download all the data and are able to construct fraud proofs for missing data, can this mitigate the problem? It turns out that it can’t, because proving data (un)availability isn’t a directly attributable fault - in other words, you can observe/detect it but there is no way you can prove it to the rest of the network reliably. More details here https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding So, if there isn’t much that can be done by detecting that a block isn’t available, what good is it for? Well nodes can still avoid following the unavailable chain and thus be tricked by a dishonest majority. However, simply attesting that data has been publishing is not enough to prevent a dishonest majority from attacking the network. (edited)\n\n\ndryajov — 07/25/2023 9:06 PM\nTo complement, the relevant quote from https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding, is:\n\nHere, fraud proofs are not a solution, because not publishing data is not a uniquely attributable fault - in any scheme where a node (“fisherman”) has the ability to “raise the alarm” about some piece of data not being available, if the publisher then publishes the remaining data, all nodes who were not paying attention to that specific piece of data at that exact time cannot determine whether it was the publisher that was maliciously withholding data or whether it was the fisherman that was maliciously making a false alarm.\n\nThe relevant quote from from https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html, is:\n\nThere is one gap in the solution of using fraud proofs to protect light clients from incorrect state transitions: What if a consensus supermajority has signed a block header, but will not publish some of the data (in particular, it could be fraudulent transactions that they will publish later to trick someone into accepting printed/stolen money)? Honest full nodes, obviously, will not follow this chain, as they can’t download the data. But light clients will not know that the data is not available since they don’t try to download the data, only the header. So we are in a situation where the honest full nodes know that something fishy is going on, but they have no means of alerting the light clients, as they are missing the piece of data that might be needed to create a fraud proof.\n\nBoth articles are a bit old, but the intuitions still hold.\n\n\nJuly 26, 2023\n\n\nzk_id — 07/26/2023 10:42 AM\nThanks a ton @dryajov ! We are on the same page. TBH it took me a while to get to this point, as it’s not an intuitive problem at first. The relationship between the VID and the DAS, and what each is for is crucial for us, btw. Your writing here and your references give us the confidence that we understand the problem and are equipped to evaluate the different solutions. Deeply appreciate that you took the time to write this, and is very valuable.\n\n\n[10:45 AM]\nThe dishonest majority is critical scenario for Nomos (essential part of the whole sovereignty narrative), and generally not considered by most blockchain designs\n\n\nzk_id\nThanks a ton @dryajov ! We are on the same page. TBH it took me a while to get to this point, as it’s not an intuitive problem at first. The relationship between the VID and the DAS, and what each is for is crucial for us, btw. Your writing here and your references give us the confidence that we understand the problem and are equipped to evaluate the different solutions. Deeply appreciate that you took the time to write this, and is very valuable.\ndryajov — 07/26/2023 4:42 PM §\nGreat! Glad to help anytime\n\n\nzk_id\nThe dishonest majority is critical scenario for Nomos (essential part of the whole sovereignty narrative), and generally not considered by most blockchain designs\ndryajov — 07/26/2023 4:43 PM\nYes, I’d argue it is crucial in a network with distributed validation, where all nodes are either fully light or partially light nodes.\n\n\n[4:46 PM]\nBtw, there is probably more we can share/compare notes on in this problem space, we’re looking at similar things, perhaps from a slightly different perspective in Codex’s case, but the work done on DAS with the EF directly is probably very relevant for you as well\n\n\nJuly 27, 2023\n\n\nzk_id — 07/27/2023 3:05 AM\nI would love to. Do you have those notes somewhere?\n\n\nzk_id — 07/27/2023 4:01 AM\nall the links you have, anything, would be useful\n\n\nzk_id\nI would love to. Do you have those notes somewhere?\ndryajov — 07/27/2023 4:50 PM\nA bit scattered all over the place, mainly from @Leobago and @cskiraly @cskiraly has a draft paper somewhere\n\n\nJuly 28, 2023\n\n\nzk_id — 07/28/2023 5:47 AM\nWould love to see anything that is possible\n\n\n[5:47 AM]\nOur setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us\n\n\nzk_id\nOur setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us\ndryajov — 07/28/2023 4:07 PM\nYes, we’re also working in this direction as this is crucial for us as well. There should be some result coming soon(tm), now that @bkomuves is helping us with this part.\n\n\nzk_id\nOur setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us\nbkomuves — 07/28/2023 4:44 PM\nmy current view (it’s changing pretty often :) is that there is tension between:\n\ncommitment cost\nproof cost\nand verification cost\n\nthe holy grail which is the best for all of them doesn’t seem to exist. Hence, you have to make tradeoffs, and it depends on your specific use case what you should optimize for, or what balance you aim for. we plan to find some points in this 3 dimensional space which are hopefully close to the optimal surface, and in parallel to that figure out what balance to aim for, and then choose a solution based on that (and also based on what’s possible, there are external restrictions)\n\n\nJuly 29, 2023\n\n\nbkomuves\nmy current view (it’s changing pretty often :) is that there is tension between: \n\ncommitment cost\nproof cost\nand verification cost\n\n the holy grail which is the best for all of them doesn’t seem to exist. Hence, you have to make tradeoffs, and it depends on your specific use case what you should optimize for, or what balance you aim for. we plan to find some points in this 3 dimensional space which are hopefully close to the optimal surface, and in parallel to that figure out what balance to aim for, and then choose a solution based on that (and also based on what’s possible, there are external restrictions)\nzk_id — 07/29/2023 4:23 AM\nI agree. That’s also my understanding (although surely much more superficial).\n\n\n[4:24 AM]\nThere is also the dimension of computation vs size cost\n\n\n[4:25 AM]\nie the VID scheme (of the paper that kickstarted this conversation) has all the properties we need, but it scales n^2 in message complexity which makes it lose the properties we are looking for after 1k nodes. We need to scale confortably to 10k nodes.\n\n\n[4:29 AM]\nSo we are at the moment most likely to use KZG commitments with a 2d RS polynomial. Basically just copy Ethereum. Reason is:\n\nOur rollups/EZ leader will generate this, and those are beefier machines than the Base Layer. The base layer nodes just need to verify and sign the EC fragments and return them to complete the VID protocol (and then run consensus on the aggregated signed proofs).\nIf we ever decide to change the design for the VID dispersal to be done by Base Layer leaders (in a multileader fashion), it can be distributed (rows/columns can be reconstructed and proven separately). I don’t think we will pursue this, but we will have to if this scheme doesn’t scale with the first option.\n\n\n\nAugust 1, 2023\n\n\ndryajov\nA bit scattered all over the place, mainly from @Leobago and @cskiraly @cskiraly has a draft paper somewhere\nLeobago — 08/01/2023 1:13 PM\nNote much public write-ups yet. You can find some content here:\n\n\nhttps://blog.codex.storage/data-availability-sampling/\n\n\nhttps://github.com/codex-storage/das-research\n\n\n\n\nWe also have a few Jupiter notebooks but they are not public yet. As soon as that content is out we can let you know \nCodex Storage Blog\nData Availability Sampling\nThe Codex team is busy building a new web3 decentralized storage platform with the latest advances in erasure coding and verification systems. Part of the challenge of deploying decentralized storage infrastructure is to guarantee that the data that has been stored and is available for retrieval from the beginning until\nGitHub\nGitHub - codex-storage/das-research: This repository hosts all the …\nThis repository hosts all the research on DAS for the collaboration between Codex and the EF. - GitHub - codex-storage/das-research: This repository hosts all the research on DAS for the collabora…\n\n\n\n\nzk_id\nSo we are at the moment most likely to use KZG commitments with a 2d RS polynomial. Basically just copy Ethereum. Reason is: \n\nOur rollups/EZ leader will generate this, and those are beefier machines than the Base Layer. The base layer nodes just need to verify and sign the EC fragments and return them to complete the VID protocol (and then run consensus on the aggregated signed proofs).\nIf we ever decide to change the design for the VID dispersal to be done by Base Layer leaders (in a multileader fashion), it can be distributed (rows/columns can be reconstructed and proven separately). I don’t think we will pursue this, but we will have to if this scheme doesn’t scale with the first option.\n\ndryajov — 08/01/2023 1:55 PM\nThis might interest you as well - https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a\nMedium\nCombining KZG and erasure coding\nThe Hitchhiker’s Guide to Subspace  — Episode II\n\n\n\n\n[1:56 PM]\nThis is a great analysis of the current state of the art in structure of data + commitment and the interplay. I would also recoment reading the first article of the series which it also links to\n\n\nzk_id — 08/01/2023 3:04 PM\nThanks @dryajov @Leobago ! Much appreciated!\n\n\n[3:05 PM]\nVery glad that we can discuss these things with you. Maybe I have some specific questions once I finish reading a huge pile of pending docs that I’m tackling starting today…\n\n\nzk_id — 08/01/2023 6:34 PM\n@Leobago @dryajov I was playing with the DAS simulator. It seems the results are a bunch of XML. Is there a way so I visualize the results?\n\n\nzk_id\n@Leobago @dryajov I was playing with the DAS simulator. It seems the results are a bunch of XML. Is there a way so I visualize the results?\nLeobago — 08/01/2023 6:36 PM\nYes, checkout the visual branch and make sure to enable plotting in the config file, it should produce a bunch of figures \n\n\n[6:37 PM]\nYou might find also some bugs here and there on that branch \n\n\nzk_id — 08/01/2023 7:44 PM\nThanks!\n\n"},"codex/updates/2023-08-01":{"title":"2023-08-01 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex update Aug 1st §\nClient §\nMilestone: Merkelizing block data §\n\nInitial design writeup https://github.com/codex-storage/codex-research/blob/master/design/metadata-overhead.md\n\nWork break down and review for Ben and Tomasz (epic coming up)\nThis is required to integrate the proving system\n\n\n\nMilestone: Block discovery and retrieval §\n\nSome initial work break down and milestones here - https://docs.google.com/document/d/1hnYWLvFDgqIYN8Vf9Nf5MZw04L2Lxc9VxaCXmp9Jb3Y/edit\n\nInitial analysis of block discovery - https://rpubs.com/giuliano_mega/1067876\nInitial block discovery simulator - https://gmega.shinyapps.io/block-discovery-sim/\n\n\n\nMilestone: Distributed Client Testing §\n\nLots of work around log collection/analysis and monitoring\n\nDetails here https://github.com/codex-storage/cs-codex-dist-tests/pull/41\n\n\n\nMarketplace §\nMilestone: L2 §\n\nTaiko L2 integration\n\nThis is a first try of running against an L2\nMostly done, waiting on related fixes to land before merge - https://github.com/codex-storage/nim-codex/pull/483\n\n\n\nMilestone: Reservations and slot management §\n\nLots of work around slot reservation and queuing https://github.com/codex-storage/nim-codex/pull/455\n\nRemote auditing §\nMilestone: Implement Poseidon2 §\n\nFirst pass at an implementation by Balazs\n\nprivate repo, but can give access if anyone is interested\n\n\n\nMilestone: Refine proving system §\n\nLost of thinking around storage proofs and proving systems\n\nprivate repo, but can give access if anyone is interested\n\n\n\nDAS §\nMilestone: DHT simulations §\n\nImplementing a DHT in Python for the DAS simulator.\nImplemented logical error-rates and delays to interactions between DHT clients.\n"},"codex/updates/2023-08-11":{"title":"2023-08-11 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex update August 11 §\n\nClient §\nMilestone: Merkelizing block data §\n\nInitial Merkle Tree implementation - https://github.com/codex-storage/nim-codex/pull/504\nWork on persisting/serializing Merkle Tree is underway, PR upcoming\n\nMilestone: Block discovery and retrieval §\n\nContinued analysis of block discovery and retrieval - https://hackmd.io/_KOAm8kNQamMx-lkQvw-Iw?both=#fn5\n\nReviewing papers on peers sampling and related topics\n\nWormhole Peer Sampling paper\nSmoothcache\n\n\n\n\nStarting work on simulations based on the above work\n\nMilestone: Distributed Client Testing §\n\nContinuing working on log collection/analysis and monitoring\n\nDetails here https://github.com/codex-storage/cs-codex-dist-tests/pull/41\nMore related issues/PRs:\n\nhttps://github.com/codex-storage/infra-codex/pull/20\nhttps://github.com/codex-storage/infra-codex/pull/20\n\n\n\n\nTesting and debugging Condex in continuous testing environment\n\nDebugging continuous tests cs-codex-dist-tests/pull/44\npod labeling cs-codex-dist-tests/issues/39\n\n\n\n\nInfra §\nMilestone: Kubernetes Configuration and Management §\n\nMove Dist-Tests cluster to OVH and define naming conventions\nConfigure Ingress Controller for Kibana/Grafana\nCreate documentation for Kubernetes management\nConfigure Dist/Continuous-Tests Pods logs shipping\n\nMilestone: Continuous Testing and Labeling §\n\nWatch the Continuous tests demo\nImplement and configure Dist-Tests labeling\nSet up logs shipping based on labels\nImprove Docker workflows and add ‘latest’ tag\n\nMilestone: CI/CD and Synchronization §\n\nSet up synchronization by codex-storage\nConfigure Codex Storage and Demo CI/CD environments\n\n\nMarketplace §\nMilestone: L2 §\n\nTaiko L2 integration\n\nDone but merge is blocked by a few issues - https://github.com/codex-storage/nim-codex/pull/483\n\n\n\nMilestone: Marketplace Sales §\n\nLots of cleanup and refactoring\n\nFinished refactoring state machine PR link\nAdded support for loading node’s slots during Sale’s module start link\n\n\n\n\nDAS §\nMilestone: DHT simulations §\n\nImplementing a DHT in Python for the DAS simulator - https://github.com/cortze/py-dht.\n\nNOTE: Several people are/where out during the last few weeks, so some milestones are paused until they are back"},"codex/updates/2023-08-31":{"title":"2023-08-31 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex Update August 21-31 §\nClient §\nMilestone: Block Merkelization §\n\nStoring and retrieving data using merkle trees\nCoders for merkle trees\nRefine merkle tree construction\n\nMilestone: Block Exchange protocol refinements and simulations §\n\nTracker simulation implementation\nBlock exchange protocol thoughts\n\nhttps://hackmd.io/ydT3AiliS8q2vdixBUXvCQ\n\n\nFollow swarmsim repo for updates\n\nMilestone: Async Disc Access & Threading support §\n\nTests on sharing thread data with refc\nerrorVariable and thread safety\n\nFix error binding in without statement on multiple threads\n\n\nWIP: Prototype proxy IO threadpool\n\nMilestone: Client stability and debugging §\n\nMajor effort to stabilize the Codex client through continuous automated testing\n\nStart discovery after announce address is updated\nStart discovery after announce address is updated\nRetrieve empty blocks\n\n\n\nInfra §\nMilestone: Monitoring and Metrics §\n\nInstall Node exporter and Prometheus in Dist-Tests cluster\nGrafana Dashboard updates\nAutomated metrics scraping\n"},"codex/updates/2023-09-15":{"title":"2023-09-15 Codex weekly","links":[],"tags":["codex-updates"],"content":"Client §\nMilestone: Block Merkelization §\n\nContinuing work on merkelization\n\nStoring and retrieving data using merkle trees\nCoders for merkle trees\nRefine merkle tree construction\n\n\n\nMilestone: Block Exchange protocol refinements and simulations §\n\nTracker simulation implementation\nBlock exchange protocol thoughts\n\nhttps://rpubs.com/giuliano_mega/1067876\nhttps://rpubs.com/giuliano_mega/1082104\n\n\nFollow swarmsim repo for updates\n\nMilestone: Async Disc Access & Threading support §\n\nWork on IO threads support\n\nhttps://github.com/codex-storage/nim-datastore/pulls\nSome early integration here - https://github.com/codex-storage/nim-codex/pull/552\n\nBased mostly on https://github.com/codex-storage/nim-codex/pull/545 and prev work by @elcritch\n\n\n\n\n\nMilestone: Client stability and debugging §\n\nMajor effort to stabilize the Codex client through continuous automated testing\n\nInfra §\nMilestone: Monitoring and Metrics §\n\nInstall Node exporter and Prometheus in Dist-Tests cluster\nGrafana Dashboard updates - waiting for public DNS to be setup\nAutomated metrics scraping - waiting for public DNS to be setup\n\nMarketplace §\nMilestone: Availabilities and Reservations §\n\nWork ongoing in\n\nhttps://github.com/codex-storage/nim-ethers\nhttps://github.com/codex-storage/codex-contracts-eth\nhttps://github.com/codex-storage/nim-codex\n\n\nSome recent PRs\n\nhttps://github.com/codex-storage/nim-ethers/pull/54\nhttps://github.com/codex-storage/nim-codex/pull/535\n\n\n\nResearch §\nMilestone: Publications §\n\nWhite paper - https://docs.google.com/document/d/1LCy23m90IHf32aUVhRT4r4772w1BfVcSLaJ0z9VTw9A/edit#heading=h.qs3bayckj5u4\nVarious publications incoming from Csaba\n\nDAS §\nMilestone: DAS Design §\n\nOngoing discussions around - https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541\n\nMilestone: Measurments and simulations §\n\nWork continues on simulating various aspects of the DHT in https://github.com/cortze/py-dht\nCsaba discussed/suggested fixes for Discv5 with Felix Lange\n"},"codex/updates/2023-09-29":{"title":"2023-09-29 Codex weekly","links":[],"tags":["codex-updates"],"content":"Client §\nMilestone: Block Merkelization §\n\nMerkelization current working branch\n\nhttps://github.com/codex-storage/nim-codex/tree/sending-blocks-with-proofs-over-the-network\n\n\n\nMilestone: Block Exchange protocol refinements and simulations §\n\nNot much done on it this past couple of weeks, progress can be tracked here when it resumes\n\nhttps://github.com/codex-storage/swarmsim\n\n\n\nMilestone: Async Disc Access & Threading support §\n\nWork on IO threads support\n\nAll related PRs are here https://github.com/codex-storage/nim-datastore/pulls\n\nWe now have a clear idea of how to implement and integrate it - https://github.com/codex-storage/nim-codex/pull/552\n\n\nfound a leak in Nim’s SharedPtr https://github.com/nim-lang/threading/issues/45 and fix https://github.com/nim-lang/threading/pull/46\n\n\n\nMilestone: Client stability and debugging §\n\nMajor effort to stabilize the Codex client through continuous automated testing\n\nMost team members are working on this on and off, testing is ongoing\n\n\n\nInfra §\n\nInstalled cert-manager in Dist-Tests cluster\nImplemented External OAUTH Authentication for Grafana/Kibana (need to adjust internal authentication)\nExposed Grafana and Kibana\nLosing the logs during Continuous Tests run\n\nResearch §\nMilestone: Publications §\n\nWhite paper ongoing - https://docs.google.com/document/d/1LCy23m90IHf32aUVhRT4r4772w1BfVcSLaJ0z9VTw9A/edit#heading=h.qs3bayckj5u4\n\nMilestone: Sampling for storage proofs §\n\nLarge discussion around erasure coding for sampling\n\nhttps://github.com/codex-storage/zk-research-artifacts/blob/master/sampling/sampling.pdf\nhttps://hackmd.io/DxJzAuTZROulBhPWqScmCg?view\nhttps://github.com/codex-storage/codex-research/pull/184\nhttps://hackmd.io/kxSF8wjPS3arDFcqFJrNDw\n\n\n\nDAS §\nMilestone: DAS Design §\n\nOngoing discussions around - https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541\nspace-DAS (don’t have link), a proposal to use spacefilling curves for sample placement\n\nMilestone: Measurements and simulations §\n\nWork continues on simulating various aspects of the DHT in https://github.com/cortze/py-dht\n"},"codex/updates/2023-10-23":{"title":"2023-10-25 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Oct 2 - 23 §\n\nWe had a teamwide offsite in Crete from October 6th to the 12th, during which we were able to discuss and come up with concrete solutions around several important pieces of the project aspects such as the proving system and the contract start interactions, as well as plan out outstanding work for our upcoming testnet launch at the end of the year. The meeting was very productive and it helped align the team around the current and future outstanding work in order to hit our big end of year milestone.\n\nClient §\nMilestone: Block Merkelization §\n\nMerkelization concrete PR in review\n\nhttps://github.com/codex-storage/nim-codex/pull/566\n\n\n\nMilestone: Block Exchange protocol refinements and simulations §\n\nSome results were presented during the offsite\n\nhttps://rpubs.com/giuliano_mega/codex-swarms\n\n\n\nMilestone: Async Disc Access & Threading support §\n\nWork on IO threads support (not much progress due to offsite, will be picked up asap)\n\nAll related PRs are here https://github.com/codex-storage/nim-datastore/pulls\n\nWe now how a clear idea of how to implement and integrated it - https://github.com/codex-storage/nim-codex/pull/552\n\n\n\n\n\nMilestone: Sampling and Storage Proofs §\n\nWork on storage proofs is ongoing under https://github.com/codex-storage/zk-research-artifacts/tree/master/storage_proofs\n\nA circom implementation is being worked on in https://github.com/codex-storage/zk-research-artifacts/tree/master/storage_proofs/MVP/circuit\nReference/testing implementation to consume the circuits is done here https://github.com/codex-storage/zk-research-artifacts/tree/master/storage_proofs/MVP/reference\n\n\nAnalysis of the sampling strategies are available here https://github.com/codex-storage/zk-research-artifacts/tree/master/sampling\n\nMilestone: Client stability and debugging §\n\nMajor effort to stabilize the Codex client through continuous automated testing\n\nWork on better log analysis is being done here https://github.com/gmega/logtools\nRunning several load tests with ˜100 nodes using the dist testing framework https://github.com/codex-storage/cs-codex-dist-tests\n\n\n\nInfra §\n\nInvestigating and fixing issues related to Elasticsearch logshipping\n\nInstall Loki in Dist-Tests cluster\nFix Vector errors related to the Kubernetes logs shipping\nConfigure Vector to ship Dist/Continuous-Tests logs to Loki\n\n\n\nResearch §\nMilestone: Publications §\n\nWhite paper ongoing - https://docs.google.com/document/d/1LCy23m90IHf32aUVhRT4r4772w1BfVcSLaJ0z9VTw9A/edit#heading=h.qs3bayckj5u4\n\nDAS §\nMilestone DAS §\n\nOur current engagement with the EF is coming to an end a summary of the work done has been collected here\n\nhttps://hackmd.io/TYqF-wj2SIWwpS2F_PhWzg\n\n\n"},"codex/updates/2023-11-03":{"title":"2023-11-03 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Oct 24th - Nov 3rd §\n\nThe team is working towards deploying a beta testnet by the end of the year, and most work is centered around finishing all the required functionality for that.\n\nClient §\nEpic: Block Merkelization §\n\nMerkelization concrete PR in review\n\nhttps://github.com/codex-storage/nim-codex/pull/566\n\nUnifying the flows\nMaking treeCid to be the same as treeRoot\nStoring proofs in key/value storage\n\n\n\n\n\nEpic: Wiring the Proving System §\n\nWork on storage proofs is ongoing in https://github.com/codex-storage/codex-storage-proofs-circuits\nWork on Poseidon2 is being done in - https://github.com/codex-storage/nim-poseidon2\n\nEpic: Improve Client Stability §\n\nExplored using CI flow for cloud-based benchmark harness, settled on Packer for image scripts Packer scripts - private repo\nSimple logging filtering/merging tool: logtools\nMicrobenchmark of Sql backend in two separate VMs\nRan remaining benchmarks, summary at Benchmark Summary\nExploring behavior of nim-datastore and sqlite\nContinued working on a “quick-and-dirty” test setup, managed to get it working\nQuick PoC for a codex net deployed with Terraform on VMs: Terraform main.tf\nAsync Profiling\n\nMarketplace §\nEpic: End-to-end Testing §\n\nFurther work on multinode integration testing\n\nprevent stuck transactions by async locking nonce sequencing (+ estimate gas)\nOn transaction failure, fetch revert reason with replayed transaction \nSupport logging to file\n[fix] Ensure AsyncLock is released in case of exception \n\n\nfeat: ensure block expiry\n\nInfra §\n\nCreated Testnet Kubernetes cluster 56\nDeployed Testnet cluster basic components 57\nConfigured DNS name for Testnet cluster 76\nCreated Service Accounts in Testnet cluster 77\nChecked CORS issue on Codex Demo 79\nConfigured TCP/UDP port forwarding for Testnet deployment 80\n"},"codex/updates/2023-11-10":{"title":"2023-11-10 Codex weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Nov 6th - Nov 10th §\n\nThe team is working towards deploying a beta testnet by the end of the year, and most work is centered around finishing all the required functionality for that.\n\nClient §\nEpic: Block Merkelization §\n\nMerkelization concrete PR in review - mostly ready for merging\n\nhttps://github.com/codex-storage/nim-codex/pull/566\n\n\nWorking on nim-datasotre to support atomic updates\n\nhttps://github.com/codex-storage/nim-datastore/pull/58\n\n\n\nEpic: Wiring the Proving System §\n\nMerged conversion from field elements into bytes in nim-poseidon2\n\nhttps://github.com/codex-storage/nim-poseidon2/pull/6\n\n\nAdded streaming API for Balazs’s sponge in nim-poseidon2\n\nhttps://github.com/codex-storage/nim-poseidon2/pull/9\n\n\nFixed merkle root construction for odd number of elements in nim-poseidon2\n\nhttps://github.com/codex-storage/nim-poseidon2/pull/8\n\n\n2D erasure coding WIP\n\nhttps://github.com/codex-storage/nim-codex/pull/608\n\n\n\nEpic: Improve Client Stability §\n\nAsync profiling (it might actualy work)\n\nhttps://github.com/codex-storage/nim-codex/pull/600\nPrometheus metrics collector completed with tests\n\n\n\nMarketplace §\nEpic: End-to-end Testing §\n\nAddressed access issues within the marketplacesuite template, pinpointing a problem with a provider declared in ethertest and overcoming the challenge through deep template layer analysis.\nDiscussions about improving the repostore maintenance module, specifically the method for returning bytes to Availabilities.\nOptimizing multinode integration tests, streamlining the process to enhance efficiency and performance.\nIntegration test for the proving loop in the sales state module that was previously causing hang-ups, ensuring smoother operation.\nProgressed towards a cleaner integration test structure with the creation of a draft PR, setting the stage for more structured testing and deployment.\n\nInfra §\n\nConfigure TCP/UDP port forwarding for Testnet deployment 80\nOrganize Grafana Dashboards 82\nConfigure Continuous Tests automation 69\nRun Continuous Tests and check metrics\nOrganize Grafana Dashboards\nConfigure Continuous Tests automation enhancement\nUpdate Vector config\nConfigure TCP/UDP port forwarding for Testnet deployment\n"},"index":{"title":"","links":["terms-of-use","tags/monthly-report","waku/","codex/overview","nomos/","vac/","acid/","insight/","innovation_lab/"],"tags":[],"content":"This site attempts to inform the previous, current, and future work required to fulfill the requirements of the projects under the Logos Collective, a complete tech stack that provides infrastructure for the self-sovereign network state. To learn more about the motivation, please visit the Logos Collective Site.\nThis site is an ongoing work in progress. The links within are an attempt to capture a lot of moving targets. This means that the information here may or may not be the bleeding edge of what is true with respect to the development within the Logos Collective projects. Your use of this Website is subject to the following terms of use which we ask you to read carefully prior to your use of the Website.\nNavigation §\n\nMonthly Project Reports\n\nProjects §\n\nWaku\nCodex\nNomos\n\nServices §\n\nVac\nComms (Acid Info)\nInsight\n\nSkunk works §\n\nInnovation Lab\n"},"innovation_lab/index":{"title":"Innovation Lab Roadmap Overview","links":["innovation_lab/milestones-overview","tags/ilab-updates"],"tags":["overview"],"content":"Welcome to the Innovation lab Roadmap Overview\n\nMilestones\nweekly updates\n"},"innovation_lab/milestones-overview":{"title":"Innovation Lab Milestones Overview","links":[],"tags":["milestones"],"content":"iLab Milestones can be found on the Notion Page"},"innovation_lab/updates/2023-07-12":{"title":"2023-07-12 Innovation Lab Weekly","links":[],"tags":["ilab-updates"],"content":"Logos Lab 12th of July\nCurrently working on the Waku Objects prototype, which is a modular system for transactional chat objects.\nMilestone: deliver the first transactional Waku Object called Payggy (attached some design screenshots).\nIt is now possible to make transactions on the blockchain and the objects send notifications over the messaging layer (e.g. Waku) to the other participants. What is left is the proper transaction status management and some polishing.\nThere is also work being done on supporting external objects, this enables creating the objects with any web technology. This work will guide the separation of the interfaces between the app and the objects and lead us to release it as an SDK.\nNext milestone: group chat support\nThe design is already done for the group chat functionality. There is ongoing design work for a new Waku Object that would showcase what can be done in a group chat context.\nDeployed version of the main branch:\nhttps://waku-objects-playground.vercel.app/\nLink to Payggy design files:\nhttps://scene.zeplin.io/project/64ae9e965652632169060c7d\nMain development repo:\nhttps://github.com/logos-innovation-lab/waku-objects-playground\nContact:\nYou can find us at https://discord.com/channels/973324189794697286/1118949151225413872 or join our discord at https://discord.gg/UtVHf2EU\n\nConversation §\n\n\npetty — 07/15/2023 5:49 AM\nthe waku-objects repo is empty. Where is the code storing that part vs the playground that is using them?\n\n\npetty\nthe waku-objects repo is empty. Where is the code storing that part vs the playground that is using them?\n\n\nattila🍀 — 07/15/2023 6:18 AM\nat the moment most of the code is in the waku-objects-playground repo later we may split it to several repos here is the link: https://github.com/logos-innovation-lab/waku-objects-playground\n\n"},"innovation_lab/updates/2023-08-02":{"title":"2023-08-02 Innovation Lab weekly","links":[],"tags":["ilab-updates"],"content":"Logos Lab 2nd of August\nCurrently working on the Waku Objects prototype, which is a modular system for transactional chat objects.\nThe last few weeks were a bit slower than usual because there were vacations, one team member got married, there was EthCC and a team offsite.\nStill, a lot of progress were made and the team released the first version of a color system in the form of an npm package, which lets the users to choose any color they like to customize their app. It is based on grayscale design and uses luminance, hence the name of the library. Try it in the Playground app or check the links below.\nMilestone: group chat support\nThere is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation.\nNext milestone: Splitter Waku Object supporting group chats and smart contracts\nThis will be the first Waku Object that is meaningful in a group chat context. Also this will demonstrate how to use smart contracts and multiparty transactions.\nDeployed version of the main branch:\nhttps://waku-objects-playground.vercel.app/\nMain development repo:\nhttps://github.com/logos-innovation-lab/waku-objects-playground\nGrayscale design:\nhttps://grayscale.design/\nLuminance package on npm:\nhttps://www.npmjs.com/package/@waku-objects/luminance\nContact:\nYou can find us at https://discord.com/channels/973324189794697286/1118949151225413872 or join our discord at https://discord.gg/ZMU4yyWG\n\nConversation §\n\n\nfryorcraken — Yesterday at 10:58 PM\n\nThere is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation.\n\nWhile status-js does implement chat features, I do not know how nice the API is. Waku is actively hiring a chat sdk lead and golang eng. We will probably also hire a JS engineer (not yet confirmed) to provide nice libraries to enable such use case (1:1 chat, group chat, community chat).\n\n\nAugust 3, 2023\n\n\nfryorcraken\n\n > There is a draft PR for group chat support for private groups and it is expected to be finished this week. At the end we decided to roll our own toy group chat protocol implementation because we did not find anything ready to use. It would have been great if we could have just used an existing implementation. While status-js does implement chat features, I do not know how nice the API is. Waku is actively hiring a chat sdk lead and golang eng. We will probably also hire a JS engineer (not yet confirmed) to provide nice libraries to enable such use case (1:1 chat, group chat, community chat).\n\n\n\nattila🍀 — Today at 4:21 AM\nThis is great news and I think it will help with adoption. I did not find a JS API for status (maybe I was looking at the wrong places), the closest was the status-js-api project but that still uses whisper and the repo recommends to use js-waku instead https://github.com/status-im/status-js-api Also I also found the 56/STATUS-COMMUNITIES spec: https://rfc.vac.dev/spec/56/ It seems to be quite a complete solution for community management with all the bells and whistles. However our use case is a private group chat for your existing contacts, so it seems to be a bit overkill for that.\n\n\nfryorcraken — Today at 5:32 AM\nThe repo is status-im/status-web\n\n\n[5:33 AM]\nSpec is https://rfc.vac.dev/spec/55/\n\n\nfryorcraken\nThe repo is status-im/status-web\n\n\nattila🍀 — Today at 6:05 AM\nAs constructive feedback I can tell you that it is not trivial to find it and use it in other projects It is presented as a React component without documentation and by looking at the code it seems to provide you the whole chat UI of the desktop app, which is not necessarily what you need if you want to embed it in your app It seems to be using this package: https://www.npmjs.com/package/@status-im/js Which also does not have documentation I assume that package is built from this: https://github.com/status-im/status-web/tree/main/packages/status-js This looks promising, but again there is no documentation. Of course you can use the code to figure out things, but at least I would be interested in what are the requirements and high level architecture (does it require an ethereum RPC endpoint, where does it store data, etc.) so that I can evaluate if this is the right approach for me. So maybe a lesson here is to put effort in the documentation and the presentation as well and if you have the budget then have someone on the team whose main responsibility is that (like a devrel or dev evangelist role)\n\n"},"innovation_lab/updates/2023-08-11":{"title":"2023-08-17 weekly","links":[],"tags":["team-updates"],"content":"Logos Lab 11th of August §\nCurrently working on the Waku Objects prototype, which is a modular system for transactional chat objects.\nWe merged the group chat but it surfaced plenty of issues that were not a problem with 1on1 chats, both with our Waku integration and from product perspective as well. Spent the bigger part of the week with fixing these. We also registered a new domain, wakuplay.im where the latest version is deployed. It uses the Gnosis chain for transactions and currently the xDai and Gno tokens are supported, but it is easy to add other ERC-20 tokens now.\nNext milestone: Splitter Waku Object supporting group chats and smart contracts\nThis will be the first Waku Object that is meaningful in a group chat context. Also this will demonstrate how to use smart contracts and multiparty transactions. The design is ready and the implementaton has started.\nNext milestone: Basic Waku Objects website\nWork started toward having a structure for a website and the content is shaping up nicely. The implementation has been started on it as well.\nDeployed version of the main branch:\nhttps://www.wakuplay.im/\nMain development repo:\nhttps://github.com/logos-innovation-lab/waku-objects-playground\nContact:\nYou can find us at https://discord.com/channels/973324189794697286/1118949151225413872 or join our discord at https://discord.gg/eaYVgSUG"},"insight/business-analysis/index":{"title":"Insight Business Analysis Overview","links":[],"tags":[],"content":"insight:business-analysis: §\n\ndatalake-repo-ingestion §\nreal-opt-keycard §"},"insight/dao/index":{"title":"Insight DAO Overview","links":[],"tags":[],"content":"insight:dao: §\n\nspiff-process-growth §\nspiff-bounty-experiment §"},"insight/index":{"title":"Insight Team Overview","links":["insight/monthly-reports/2023-oct","insight/dao/","insight/project-reporting/","insight/business-analysis/"],"tags":[],"content":"Description §\nThe insight team acts as a glue within the Logos Collective. They serve development projects by helping to track development activity and aiding in resource allocation. They serve the broader service units within the organization by helping them understand who’s doing what, how much effort is going into each chunk of work, how much it costs, and future projections of milestone delivery.\nThis page tracks the various work that they engage in throughout the org. As this is a service unit and not a project, it does not strictly work off a milestone based approach and has consistent service work to the various groups within the Logos Collective.\nMonthly Reports §\n\n2023 October\n\nCurrent work §\ndao: details §\nproject-reporting: details §\nbusiness-analysis: details §"},"insight/monthly-reports/2023-oct":{"title":"2023 October Insights Monthly Report","links":[],"tags":[],"content":"Executive Summary §\nKey Updates §\nPersonnel §\nA senior and junior software engineer have been brought on to support the ongoing development of SpiffWorkflow.\n\nMichael is a senior python developer with years of experience. He also contributed to SpiffWorkflow in the past by giving it an external security review before it was launched. He will be leading the internal development and mentoring the junior dev.\nKayvon joined as a junior dev to contribute to the ongoing development and web3-ification of SpifWorkflow.\n\nMonthly Highlights §\nSpiffWorkflow §\nThe project has received two new in-house developers so that ongoing maintenance and development can continue. The entire Kanban board is currently held in Notion but may move to somewhere more public in the near future.\nA new release happened that brought about a bunch of bug fixes and improvements, namely (copy/paste from Sasha’s Discord post):\n\nUI/UX changes across the site have been made to make it cleaner and easier to navigate\nNo more copying and sending process instance ID and sending it to someone. There is now a shareable link on each process instance that produces a short link to share.\nA new way to quickly understand where the process is upto. Rather than just seeing in-progress, you will now see things like “Pending Approval - Insights” or “Request Approved” etc. You will see this on the home page and all tables across the platform, under the column name: Last milestone\nHow many times have you wanted to look at the data previously entered into forms? You can now do this with the addition of a new section called My completed tasks, which can be found on the Process Instance Detailed page. This is one of the most requested features!\nWe now support the ability of parallel processing for tasks. Things like calling 3 different APIs can be done in parallel now, significantly speeding up all processes.\nSpiff now allows external systems to call it using APIs. I.e. on some trigger, external systems calls Spiff to start a process or complete a task for an existing process. This will be extremely powerful when integrating with of our systems.\nREADME files about a process are now embedded in Spiff. When you head to the process model page, you will see the About tab, which has a readme.md file with everything you need to know about a process.\nMarkdown support added across the platform\nAdded a tooltip component to the checkboxes in forms to enhance the user experience. Now, when you submit a travel request and are unsure about the Per Diem, simply hover over the checkbox and the help text will appear.\nAuto-approvals for processes. In order to reduce approval time, when someone holds both the role of Budget Owner and is part of the SME group, double-approval is not required. For example, if an Infra Lead provides approval as a Budget Owner for software and licenses, the Infra team review step will be automatically completed (approved). You can find the list of Budget Owners here.\nAdded Event categories to the Request Goods/Services process. The list of purchase categories can be found here\nFixed bugs and errors\nImplemented admin functionality to improve the support team’s ability to assist users when needed\nWe can now invite any external user to complete one/multiple steps in a process, without that user being created within Keycloak/Spiff. This allows us to do things like ask a vendor being onboarded to complete a form or perform a step in process, by simply sending them an email with all instructions. The access is time based password protected.\nIf you come across a missing City in the Travel request drop-down, simply inform the support team. They can add it for you, allowing you to proceed with your request.\n\nKudos to the team for such an awesome amount of work.\nA technical roadmap has begun to be developed which outlines the process of “DAOification” of the organization. The initial focus is on understanding the time-cost of the project and required resources.\nContract Extension Negotiations with Sartography §\n\nSummarizations provided by Eric in legal:\nJust to summarise where we’re at with Sartography as of the latest agreement, Sartography has indicated that they will develop additional SpiffWorkflow components called “SpiffWorkflow Extensions”. The negotiations with Sartography revolve around the issue ownership and licensing of the IP for these SpiffWorkflow Extensions as developed for Status. The points are as follows:\n\n(i) Commercial license instead of an open source license: Originally all Spiffworkflow software would either be open source or be delivered to Status for its ownership. Sartography are insisting on deviating from this approach for the Extensions and intend to apply a commercial license to it. This is an unacceptable position. If they develop IP with Status’ money, then it must align with the original approach.\n(ii) Waiver of fee for commercial license: Sartography have indicated that they are willing to “waive” the fee for any commercial license for the Extensions (referring this as a “gift” to Status). The terms of the commercial license will still need to be negotiated and are unknown to us right now. The waiver of a fee for a commercial license which we don’t have any view on may not be worth much if it turns out to be very restrictive.\n\n\n\nAn image of what Sartography aims to do, important to note this is not funded by Status:\n\nFor the avoidance of doubt, all “original” Spiffworkflow Software still aligns with our original agreed approach i.e. Sartography is obliged to keep it open source and any thing it delivers to Status will belong to Status who is obliged to make it open source.\nPath Forward - Still needs to be finalized by legal; however, Sartography is building an ability to commercialize features that they are developing outside of development with Status. They will extend a commercial license to us and waive all fees associated if Status uses any of those features. All feature they’ve expressed they are building are not features Status would leverage. For example, datastores for personal data and data stores for financial data.\nReal Options Analysis §\nFrederico lead the way on developing a framework (and explainer) for performing Real Options Analysis on Keycard. Keycard was chosen based on its smaller project size and traditional evaluation methodology as a project (the easiest one to start with) with the goal in mind of generalizing the framework for all projects within Logos and Status. The current analysis and framework can be found in Notion for now. Once finalized and reviewed, it may be released for public consumption.\nThis framework is expected to allow us to identify performance and evaluation trends for projects within their respective ecosystems, thus adding valuable insight to the decisions we as an org can make to steer them in the direction of success. More info on this can be seen in Jarrad’s previous townhall (Org internal link - sorry - picture below for public) where he discussed it.\n\nRevamping Accounting with Finance §\nWork continues with the Finance team to revamp the budgeting process for projects and services. The dashboard (mentioned below) being developed has helped track and monitor how money is being spent and allocated across the org.\nProject Dashboards §\nA lot of work has been done to create various dashboards for cohorts across the org. The project dashboards are mainly created from the development activity we can glean from Github thus is heavily dependent upon the team’s reporting and Github tagging process at the moment.\nCurrently, the following dashboards are being worked on and iterated with their respective teams to ensure they’re providing appropriate and correct information (ask Lalo if access if you feel you should have it and don’t):\n\nProject Reporting (Waku)\nProject Reporting (Status)\nBudget Reporting\nMilestone Table\nProcess Performance for Spiff\nWaiting for Twitter API v2 access to be purchased to complete the social engagement dashboard.\n\nThe Waku team gave a presentation on their adapted project reporting process to the PMs across the org and work has been started to adapt projects to something similar to allow for more automation and dashboard creation.\nThe Waku team has reported usefulness in their dashboard already despite it being incomplete (no weighting of work done yet, only tagging issues to epics and epics to milestones).\nFuture Plans §\nNext month, the insights team plans to focus on increasing the coverage of project roadmaps within this website as well as the backend development activity automation coverage for projects.\nThe more we cover projects development activity, the better dashboards we can make to serve them.\nNEED MORE HERE"},"insight/project-reporting/index":{"title":"Insight Project Reporting Overview","links":[],"tags":[],"content":"insight:project-reporting: §\n\nmilestone-publishing: §\n\ncodex\nnomos\nwaku\nvac\n\nmonthly-reports §\nllm-dev-activity §"},"nomos/base-layer-spec/data-availability/index":{"title":"Nomos Data Availability Details","links":[],"tags":[],"content":"nomos:data-availability: §\n\nDescription §\nNomos Data Availability design:\n\nOur Base Layer doesn’t have execution. Only the (global) Coordination Layer has a minimal set of operations.\nOur rollups are quasi-sovereign, meaning that they do not prove their state to the Base Layer, but they have to prove asset deposit/withdrawals, as well as implement the mechanism to pay for using the Base Layer DA+consensus. Note that full sovereignty means no bridging and implementing a client of the DA for the payments.\nWe also have a form of PBS, but enshrined in the L2s. The Base Layer only performs consensus on data that has been dispersed by the Builder. The Proposer is a node in the Base Layer, and the Builder is a node of the Execution Zone.\n\nResearch §\n\nData Availability Specification: https://www.notion.so/Data-Availability-Specification-wip-c3961b681eba4ccdab2be9181e4207b4\n\nEngineering §\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n - Initial data availability implementation: In progress, 2023-09-01, 2023-11-30\n"},"nomos/base-layer-spec/index":{"title":"Nomos Milestone: Full Base Layer Specification","links":["nomos/base-layer-spec/network-privacy/","nomos/base-layer-spec/priv-pos/","content/nomos/base-layer-spec/data-availability/","vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation","vac/tke/g/nomos/economic-analysis"],"tags":[],"content":"nomos:base-layer-spec: §\n\nDescription §\nThe initial milestone of the Nomos project is a full specification of the Base Layer. This entails detailed explanations of the working parts of the architecture and how they lay the groundwork for future layers to be built on top. The working parts are:\n\nA private P2P network\nData availability\nA private Proof-of-State model leveraging a scalable, lightweight consensus algorithm\n\nThis work can be tracked via the following epics.\nKey Epics §\nnetwork-privacy: details §\n\ndue:\nprogress:\nshort description: Creation of a privacy preserving network underlay\n\nprivate-pos: details §\n\nnext deliverable: Sept 29, 2023\nprogress: 99%\nshort description: Creation of a Proof-of-Stake model that preserves the privacy of the stakers within the network\n\ndata-availability: details §\n\ndue:\nprogress:\nshort description: Definition of how Nomos makes data available to network participants, and its reference implementation for the Base Layer.\n\nDependent Upon: §\nvac:dr:carnot-aggregation-spec §\n\ncarnot-2-3rds-vote-aggregation\n\nvac:tke:stake-rewards §\n\neconomic-analysis\n"},"nomos/base-layer-spec/network-privacy/index":{"title":"Nomos Network Privacy Details","links":[],"tags":[],"content":"nomos:network-privacy: §\n\nCurrent Focus §\nMixnet 1.0 - a technology/system that helps keep information sent over the internet private and secure. It does so by mixing up data from different sources before sending it to its destination. In Nomos chain:\n\nMixnet nodes opt-in by publishing their IP and providing stake.\nThe mixnet topology of layers is public and defined on-chain (by some deterministic algorithm using the random-beacon for example).\nAfter certain number of epochs (to be determined), a new set of nodes is chosen and a new topology of Mixnet layers is defined. Nodes need to renew their stake and their keys (for security).\n\nFor more information, check https://www.notion.so/Private-Routing-Mixnet-Network-Privacy-Component-1-613f53cf11a245098c50af6b191d31d2\nResearch §\nCurrent Tasks §\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Viability analysis of the Embedded Mixnet: In progress, 2023-09-18, 2023-10-06\n\nEngineering §\nCurrent Tasks §\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 7day\n dateFormat YYYY-MM-DD \n section Status\n Mixnet 1.0 Stabilization: In progress, 2023-09-18, 2023-09-30\n"},"nomos/base-layer-spec/priv-pos/index":{"title":"Nomos Private Proof of Stake Details","links":[],"tags":[],"content":"Description §\nIn PoS systems, preserving stake privacy is vital to avoid exposing users’ wealth. Different approaches to achieve this include leveraging confidential assets, such as or coin mixing protocols applied to staking.\nCurrent Status §\nResearch phase: writing Private Proof of Stake Specifications:\nDue Date: 2023-09-29\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n PPoS Specifications: In progress, 2023-06-25, 2023-09-29\n"},"nomos/base-layer-testnet/index":{"title":"Nomos Milestone: Base Layer Testnet Implementation","links":["nomos/base-layer-testnet/testnet/","vac/dst/wakurtosis/nomos/ci-integration"],"tags":[],"content":"nomos:base-layer-testnet: §\n\nDescription §\nKey Epics §\ntestnet: index §\n\ndue: October 27th\nprogress: 66% (unstable testnet)\nshort description: deployment of the initial testnet for the Nomos network\n\nDependent Upon: §\nvac:dst:node-cicd §\n\nci-integration\n"},"nomos/base-layer-testnet/testnet/index":{"title":"Nomos Testnet Details","links":[],"tags":[],"content":"nomos:testnet: §\n\nDescription §\nWe aim for having an unstable testnet (asap) with no guarantees on breaking changes:\n\nData can be wiped out at every new rollout\nAccounts may disappear at some point\nThere are no incentives initially (ie no token as it requires data permanence)\nA good first functionality target would be to implement something like Bitcoin’s ordinals (NFTs), since they are just signed data.\n\nMore information: https://www.notion.so/Testnet-55049d959a6145fd9c542c5b3999c65a\nResearch §\nEngineering §\nCurrent Focus §\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Node for Testnet: In progress, 2023-08-28, 2023-10-27\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Client for Testnet: In progress, 2023-09-11, 2023-10-27\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 7day\n dateFormat YYYY-MM-DD \n section Status\n DevOps for Testnet: In progress, 2023-09-11, 2023-09-30\n"},"nomos/consensus-def/index":{"title":"Nomos Milestone: Scalable Consensus Definition","links":[],"tags":[],"content":"nomos:consensus-def: §\n\nDescription §\nThis tracks the work of the initial discovery effort that lays the groundwork for all other work, consensus. A survey of options was undertaken, explored and documented. The product of all the work is Carnot.\nMain whitepaper:\nPseudocode specification of Carnot: https://github.com/logos-co/nomos-specs/blob/master/carnot/spec.md\nStatus: Delivered"},"nomos/index":{"title":"Nomos Roadmap Overview","links":["nomos/monthly-reports/2023-oct","nomos/monthly-reports/2023-sept","nomos/base-layer-spec/","nomos/base-layer-testnet/","nomos/consensus-def/"],"tags":["nomos","roadmap","overview"],"content":"Nomos Overview §\nThe Nomos project is an attempt to make a scalable, modular, and private L1. To learn more about the project, please visit the website\nNomos is currently in its initial phase as a project within Logos, namely the research and architecture design phase.\nLatest Monthly Reports §\n\n2023 October\n2023 September\n\nCurrent Key Milestones §\nbase-layer-spec: details §\n\ndue: 2024 Q1\nstatus: in progress\ndescription: Full specification of the Nomos Base Layer along with accompanying research and justification.\n\nbase-layer-testnet: details §\n\ndue: 2024 Q3\nstatus: in progress\ndescription:\n\ncoord-layer-spec: §\n\ndue: 2024 Q4\nstatus: pending\ndescription:\n\ncoord-layer-testnet: §\n\ndue: 2025 Q1\nstatus: pending\ndescription:\n\n\nDelivered Milestones §\nconsensus-def: details §\n\ndue: 2023 Q3\nstatus: complete\ndescription: Research and specification of an underlying consensus algorithm to be used as foundation for Nomos.\n\n\nUseful Links §\n\nMilestones Overview Notion Page: where the team updates their milestones before being transferred here.\n"},"nomos/monthly-reports/2023-sept":{"title":"2023 September Nomos Monthly Report","links":["vac/acz/","","vac/zkvm/","vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation","nomos/updates/2023-09-04","nomos/updates/2023-09-11","nomos/updates/2023-09-19","nomos/updates/2023-09-26"],"tags":["monthly-report","nomos"],"content":"Executive Summary §\nThe Nomos team continues to stay focused on research related to the fine-grained details of the Base Layer specification and implementation. The addition of a Project Manager is expected to not only expedite the research by allowing the lead to dive deeper into the issues involved but also make that work and progress more transparent.\nMehmet joins the team next month to fulfill a long needed dedicated role in research privacy and zero-knowledge technology as it pertains to the Nomos requirements.\nThe whitepapers plan to be polished and published by early next month which not only details the current specifications but also known problems that need to be solved.\nKey Updates §\nPersonnel §\n\nFilip has joined as a Project Manager (last month) to assist in various activities. His position is to sit in between the Insights team and the Nomos project to facilitate development tracking and resource allocation. It is anticipated that his involvement will speed up development as current resources are then freed to focus on research and development. Until demands within Nomos require full-time engagement from him, he will also be assisting with Vac Program Management.\nAfter a lot of candidate interviews, Mehmet was offered a position and accepted to focus on the privacy and cryptography research needs within the project. His background in cryptography and security auditing of popular zero-knowledge platforms is expected to be very useful in aiding to architect Nomos. Mehmet’s starting date is Oct 2\n\nAnother candidate for this role that was considered, Ramses, has joined the Vac team and will initially be aiding in this work and growing the relationship with their Applied Crypto and Zero-Knowledge team. Ramses started in\n\n\nAn offer has been extended to a candidate for the open role of Applied Network Researcher. He passed all interview rounds but unfortunately passed on the final offer for another opportunity.\nThe roles of Applied Network Researcher and Distributed Systems Researcher are still open and candidates are being interviewed.\n\nMilestones §\nNomos’ roadmap is currently composed of five main sections, each of which is broken up into Research and Development. Obviously, Development lags behind the Research section. These five areas are as follows:\n\nWhitepapers\nNetwork Privacy and Mixnet\nTestnet\nPrivate PoS\nData Availability\n\nThe Milestone definitions and timelines are not yet ported to this site, and as such, are private to Logos. They are planned to be publicized on this site by the end of the this month, potentially bleeding into the beginning of October. For those with Notion access, you can view the Milestone definitions here.\nThe following sections will outline key activity across these milestones. If more information and detail is desired, links can be found under the associated heading among the Sources and Useful Links Weekly updates section.\nWhitepapers §\nThe current Whitepaper drafts are almost ready for publication. They require only “beautification” and a listing of detailed “current unsolved problems” that need to be explored later in the total project. This will be done following the current prioritization of mixnet specification.\nThis milestone will be completed next month.\nNetwork Privacy and Mixnet §\nThe specification of the mixnet is currently underway and expected to wrap up soon (next month??). This initial specification is modeled after the current State of the Art in the mixnet industry. This is chosen to be critical path based on all the depending architectural decisions that stem from decisions of the networking layer.\nReview and analysis of current mixnet literature continues. Throughout this review, a modeling framework was developed in order to help evaluate future (v2) speculative mixnet architectures as compared to the current one. This theoretical framework has already been able to reproduce known results within the industry, such as deriving that the probability of an anonymity failure:\n\ndecreases when increasing the number of layers\nincreases when increasing the number of nodes within a single layer.\n\nFramework and analysis details can be found in the overleaf document.\nWhile research explores subtleties in the mixnet specification, development has tackled the foundations of its implementation on top of libp2p within the nomos-node repository. They’ve logically setup how it connects to the rest of the pieces of the node, setup testing frameworks and node monitoring hooks, and generally got it provisioned for the upcoming testnet.\nTestnet §\nA PoC/Draft Testnet was created and merged via Docker-Compose, then general exploration was done to identify what to measure and how to do it within the nomos-node software.\nSimulations of the branch overlay with 1 committee was conducted. Initial results discovered a bug in reproducibility that was fixed. Additional simulations resulted in discovery of inter-module errors with the leader selection. This is currently being explored along with integration of mixnet developments.\nPrivate PoS §\nResearch was conducted in a variety of areas around a Private Proof of Stake spec relevant to the architecture of Nomos. All details can be found in the Whitepaper descriptions.\nThe initial design was created based on Zcash designs with section details around how “stake” is considered for the Base Layer of Nomos, how “restaking” could work, and various consensus modifications around Carnot. An introduction of “shadows” was done which presents the ideas around the initial voting process. The logic of these “shadows” is currently being fleshed out so that they’re more intuitive to understand. One result is that they’re now called “Validators” in an effort to keep naming conventions reasonable across the industry.\nMuch attention was spent on a discovered issue with vote propagation within this construction. This issue is around the implications of vote withholding and how they change as you move up the overlay. The solution being to propagate a map of seen votes upstream alongside the vote, thus increasing transparency of participation.\nThe concept of “Hastiness” has been introduced to describe the leader’s ability to decide whether or not to include votes from the root committee if the threshold is reached before they’ve had the opportunity to conclude. More research is underway to detail the implications of this decisions with respect to payout, latency, and security.\nMost notably, an extension (or more constrained parameterization) of Carnot was initiated and is underway (expected by end of Oct) as a consequence of needing to mitigate a signature aggregation issue. This extension requires 2/3 votes to be collected before a decisions is made.\nData Availability §\nResearch continues on the various available Data Availability schemes and their trade-offs which resulted in the ability to make some decisions on the Nomos specification and identified a more specific personnel requirement for specialized cryptographic expertise. This research demand will now be filled by the new addition to the team and progress is expected to accelerate.\nAn analysis of the impact of node decay in Data Availability was performed and presented in a Logos Research Seminar. This research resulted in a draft specification of private DA. This then lead to the first draft of a complete privacy solution for the networking layer for consensus and DA.\nThe architecture of Data Availability services was fleshed out within nomos-node software. Data dissemination implementation was completed and the mempool for certificates is currently in progress.\nPerceived Changes in Project Risk §\nPrivacy remains at the forefront of this project’s desired requirements. As such, it is important to define what types of privacy the project can offer and then detail exactly how various technology provides it. This is a “ground up” process that starts at the lowest layers and propagates up through the stack. Due to the continued exploration and designing of the Base Layer, it remains to be seen how the currently designs will impact upper layers, namely “Execution Zones.” The on-going development of the zkVM incubation project within Vac raises the risk of incompatibility between the two as both projects are optimizing for their respective domains in parallel and without much communication.\nFuture Plans §\nInsight §\nIt is expected that the entire Nomos roadmap will be specified within this site and the weekly reporting process will be in line with the Milestones defined therein.\nA Logos Collaborations section will be included next month to highlight differences in alignment with the Logos Collective as well as cross project collaboration updates.\nDepending on the uptake and viability of the Waku reporting process to other projects, then a myriad of quantitative measures will be included in the next monthly report.\nProject §\nNext month focuses on finalizing and publishing:\n\nthe first version of the Whitepapers\n\nemphasis that specification details will focus on the Base Layer implementation, leaving unknowns and explicit detail of above layers to be explored as open problems.\n\n\na Nomos Testnet Client and Node implementation\na viability analysis of an embedded mixnet\na specification and pseudocode for the extended 2/3-vote aggregation Carnot consensus algorithm (Vac dependency: carnot-2-3rds-vote-aggregation)\n\nSources and Useful Links §\nWeekly updates referenced\n\n2023-09-04\n2023-09-11\n2023-09-19\n2023-09-26\n"},"nomos/monthly-reports/index":{"title":"Nomos Monthly Reports","links":[],"tags":[],"content":"Here are the monthly reports that are generated for Nomos."},"nomos/updates/2023-07-24":{"title":"2023-07-24 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Research\n\nMilestone 1: Understanding Data Availability (DA) Problem\nHigh-level exploration and discussion on data availability problems in a collaborative offsite meeting in Paris.\nExplored the necessity and key challenges associated with DA.\nIn-depth study of Verifiable Information Dispersal (VID) as it relates to data availability.\nBlocker: The experimental tests for our specific EC scheme are pending, which is blocking progress to make final decision on KZG + commitments for our architecture.\nMilestone 2: Privacy for Proof of Stake (PoS)\nAnalyzed the capabilities and limitations of mixnets, specifically within the context of timing attacks in private PoS.\nInvested time in understanding timing attacks and how Nym mixnet caters to these challenges.\nReviewed the Crypsinous paper to understand its privacy vulnerabilities, notably the issue with probabilistic leader election and the vulnerability of anonymous broadcast channels to timing attacks.\n\nDevelopment\n\nMilestone 1: Mixnet and Networking\nInitiated integration of libp2p to be used as the full node’s backend, planning to complete in the next phase.\nBegun planning for the next steps for mixnet integration, with a focus on understanding the components of the Nym mixnet, its problem-solving mechanisms, and the potential for integrating some of its components into our codebase.\nMilestone 2: Simulation Application\nCompleted pseudocode for Carnot Simulator, created a test pseudocode, and provided a detailed description of the simulation. The relevant resources can be found at the following links:\n\nCarnot Simulator pseudocode (https://github.com/logos-co/nomos-specs/blob/Carnot-Simulation/carnot/carnot_simulation_psuedocode.py)\nTest pseudocode (https://github.com/logos-co/nomos-specs/blob/Carnot-Simulation/carnot/test_carnot_simulation.py)\nDescription of the simulation (https://www.notion.so/Carnot-Simulation-c025dbab6b374c139004aae45831cf78)\n\n\nImplemented simulation network fixes and warding improvements, and increased the run duration of integration tests. The corresponding pull requests can be accessed here:\n\nSimulation network fix (https://github.com/logos-co/nomos-node/pull/262)\nVote tally fix (https://github.com/logos-co/nomos-node/pull/268)\nIncreased run duration of integration tests (https://github.com/logos-co/nomos-node/pull/263)\nWarding improvements (https://github.com/logos-co/nomos-node/pull/269)\n\n\n"},"nomos/updates/2023-07-31":{"title":"2023-07-31 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos 31st July\n[Network implementation and Mixnet]:\nResearch\n\nInitial analysis on the mixnet Proof of Concept (PoC) was performed, assessing components like Sphinx for packets and delay-forwarder.\nConsidered the use of a new NetworkInterface in the simulation to mimic the mixnet, but currently, no significant benefits from doing so have been identified.\nDevelopment\nFixes were made on the Overlay interface.\nNear completion of the libp2p integration with all tests passing so far, a PR is expected to be opened soon.\nLink to libp2p PRs: https://github.com/logos-co/nomos-node/pull/278, https://github.com/logos-co/nomos-node/pull/279, https://github.com/logos-co/nomos-node/pull/280, https://github.com/logos-co/nomos-node/pull/281\nStarted working on the foundation of the libp2p-mixnet transport.\n\n[Private PoS]:\nResearch\n\nDiscussions were held on the Privacy PoS (PPoS) proposal, aligning a general direction of team members.\nReviews on the PPoS proposal were done.\nA proposal to merge the PPoS proposal with the efficient one was made, in order to have both privacy and efficiency.\nDiscussions on merging Efficient PoS (EPoS) with PPoS are in progress.\n\n[Carnot]:\nResearch\n\nAnalyzing Bribery attack scenarios, which seem to make Carnot more vulnerable than expected.\n\nDevelopment\n\nImproved simulation application to meet test scale requirements (https://github.com/logos-co/nomos-node/pull/274).\nCreated a strategy to solve the large message sending issue in the simulation application.\n\n[Data Availability Sampling (or VID)]:\nResearch\n\nConducted an analysis of stored data “degradation” problem for data availability, modeling fractions of nodes which leave the system at regular time intervals\nContinued literature reading on Verifiable Information Dispersal (VID) for DA problem, as well as encoding/commitment schemes.\n"},"nomos/updates/2023-08-07":{"title":"2023-08-07 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos weekly report §\nNetwork implementation and Mixnet: §\nResearch §\n\nResearched the Nym mixnet architecture in depth in order to design our prototype architecture.\n(Link: https://github.com/logos-co/nomos-node/issues/273#issuecomment-1661386628)\nDiscussions about how to manage the mixnet topology.\n(Link: https://github.com/logos-co/nomos-node/issues/273#issuecomment-1665101243)\n\nDevelopment §\n\nImplemented a prototype for building a Sphinx packet, mixing packets at the first hop of gossipsub with 3 mixnodes (+ encryption + delay), raw TCP connections between mixnodes, and the static entire mixnode topology.\n(Link: https://github.com/logos-co/nomos-node/pull/288)\nAdded support for libp2p in tests.\n(Link: https://github.com/logos-co/nomos-node/pull/287)\nAdded support for libp2p in nomos node.\n(Link: https://github.com/logos-co/nomos-node/pull/285)\n\nPrivate PoS: §\nResearch §\n\nWorked on PPoS design and addressed potential metadata leakage due to staking and rewarding.\nFocus on potential bribery attacks and privacy reasoning, but not much progress yet.\nStopped work on Accountability mechanism and PPoS efficiency due to prioritizing bribery attacks.\n\nCarnot: §\nResearch §\n\nAddressed two solutions for the bribery attack. Proposals pending.\nWork on accountability against attacks in Carnot including Slashing mechanism for attackers is paused at the moment.\nModeled data decimation using a specific set of parameters and derived equations related to it.\nProposed solutions to address bribery attacks without compromising the protocol’s scalability.\n\nData Availability Sampling (VID): §\nResearch §\n\nAnalyzed data decimation in data availability problem.\n(Link: https://www.overleaf.com/read/gzqvbbmfnxyp)\nDA benchmarks and analysis for data commitments and encoding. This confirms that (for now), we are on the right path.\nExplored the idea of node sharding: https://arxiv.org/abs/1907.03331 (taken from Celestia), but discarded it because it doesn’t fit our architecture.\n\nTesting and Node development: §\n\nFixes and enhancements made to nomos-node.\n(Link: https://github.com/logos-co/nomos-node/pull/282)\n(Link: https://github.com/logos-co/nomos-node/pull/289)\n(Link: https://github.com/logos-co/nomos-node/pull/293)\n(Link: https://github.com/logos-co/nomos-node/pull/295)\nRan simulations with 10K nodes.\nUpdated integration tests in CI to use waku or libp2p network.\n(Link: https://github.com/logos-co/nomos-node/pull/290)\nFix for the node throughput during simulations.\n(Link: https://github.com/logos-co/nomos-node/pull/295)\n"},"nomos/updates/2023-08-14":{"title":"2023-08-17 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos weekly report 14th August §\n\nNetwork Privacy and Mixnet §\nResearch §\n\nMixnet architecture discussions. Potential agreement on architecture not very different from PoC\nMixnet preliminary design [https://www.notion.so/Mixnet-Architecture-613f53cf11a245098c50af6b191d31d2]\n\nDevelopment §\n\nMixnet PoC implementation starting [https://github.com/logos-co/nomos-node/pull/302]\nImplementation of mixnode: a core module for implementing a mixnode binary\nImplementation of mixnet-client: a client library for mixnet users, such as nomos-node\n\nPrivate PoS §\n\nNo progress this week.\n\n\nData Availability §\nResearch §\n\nContinued analysis of node decay in data availability problem\nImproved upper bound on the probability of the event that data is no longer available given by the (K,N) erasure ECC scheme [https://www.overleaf.com/read/gzqvbbmfnxyp]\n\nDevelopment §\n\nLibrary survey: Library used for the benchmarks is not yet ready for requirements, looking for alternatives\nRS & KZG benchmarking for our use case https://www.notion.so/2D-Reed-Solomon-Encoding-KZG-Commitments-benchmarking-b8340382ecc741c4a16b8a0c4a114450\nStudy documentation on Danksharding and set of questions for Leonardo [https://www.notion.so/2D-Reed-Solomon-Encoding-KZG-Commitments-benchmarking-b8340382ecc741c4a16b8a0c4a114450]\n\n\nTesting, CI and Simulation App §\nDevelopment §\n\nSim fixes/improvements [https://github.com/logos-co/nomos-node/pull/299], [https://github.com/logos-co/nomos-node/pull/298], [https://github.com/logos-co/nomos-node/pull/295]\nSimulation app and instructions shared [https://github.com/logos-co/nomos-node/pull/300], [https://github.com/logos-co/nomos-node/pull/291], [https://github.com/logos-co/nomos-node/pull/294]\nCI: Updated and merged [https://github.com/logos-co/nomos-node/pull/290]\nParallel node init for improved simulation run times [https://github.com/logos-co/nomos-node/pull/300]\nImplemented branch overlay for simulating 100K+ nodes [https://github.com/logos-co/nomos-node/pull/291]\nSequential builds for nomos node features updated in CI [https://github.com/logos-co/nomos-node/pull/290]\n"},"nomos/updates/2023-08-21":{"title":"2023-08-21 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos weekly report 21st Oct §\n(delayed as I was on holidays and then took me some time to clarify some things with the team)\nNetwork Privacy and Mixnet §\n\nImproved the mixnet implementation based on latest discussion. https://github.com/logos-co/nomos-node/pull/307\nBase implementation of Mixnet PoC: https://github.com/logos-co/nomos-node/pull/302\nRefactor to encapsulate message body creation&write&read: https://github.com/logos-co/nomos-node/pull/308\nNew issues related to mixnet: https://github.com/logos-co/nomos-node/issues?q=is%3Aopen+is%3Aissue+label%3Amixnet\n\nPrivate PoS §\n\nUpdated draft addressing comments related to shielded and transparent transaction types.\nDefined an opportunistic voting problem.\nContinuing analysis on zCash transaction’s construction.\nThis is currently the project that is going slowest and needs more attention going forward. It’s also the most complex and with the most unknowns.\n\nSimulations app §\n\nGraceful shutdown of simulations.\nCreated a new repository for simulations configurations and test results: https://github.com/logos-co/nomos-simulations\nUpdates and discussed test runs: https://github.com/logos-co/nomos-simulations/pull/3\nChanges to support CSV format output of simulation data: https://github.com/logos-co/nomos-node/pull/304 and https://github.com/logos-co/nomos-node/pull/306\nMinor issue on integration tests fixed: https://github.com/logos-co/nomos-node/pull/315\n\nData Availability Sampling §\n\nStudied RS+KZG in context of our DA architecture.\nRS: basic encoding/decoding lib. Created a basic wrapper around reed-solomon-encoding library to work with arbitrary bytearrays with the simples API possible. Created basic tests and docs as well.\nKZG: basic commitment + proof creation, also proof verification lib. Same here, created a simplistic API that abstract from the confusing types in the underlaying used library.\nCreated a simplistic API for RS: https://github.com/logos-co/nomos-node/pull/303\nCreated a simplistic API for KZG: https://github.com/logos-co/nomos-node/pull/309\n"},"nomos/updates/2023-08-29":{"title":"2023-08-29 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Nomos weekly report §\nMilestone 1: Network Privacy and Mixnet §\nResearch §\n\nA Mixnet PoC was conducted to gauge end-to-end latency, revealing a slight latency increase when utilizing mixnet. Several potential optimization areas have been identified.\n\nDevelopment §\n\nVarious enhancements for the Mixnet have been developed, including the addition of delays for Sphinx packets, auto port for integration tests, and introducing a graceful shutdown for mixnode elements.\nThere’s an ongoing shift from channels to streams in mixnet message handling.\nRefactoring of Mixnet Node & Client: https://github.com/logos-co/nomos-node/pull/320\nMixnet PoC Architecture Documents: https://www.notion.so/Mixnet-and-Network-Privacy-Architecture-613f53cf11a245098c50af6b191d31d2\nMixnet Measurements Documentation: https://www.notion.so/Mixnet-Measurements-551ade11ae4d44ca9f3d947ea6950c67\nSphinx Packet Delay Support: https://github.com/logos-co/nomos-node/pull/321\nAuto Port for Tests: https://github.com/logos-co/nomos-node/pull/327\nMixnet Criterion Measurement: https://github.com/logos-co/nomos-node/pull/328\nGraceful Shutdown for Mixnet: https://github.com/logos-co/nomos-node/pull/330\n\n\nMilestone 2: Private PoS §\nResearch §\n\nDiscussions were held about token-engineering and staking in private settings, resulting in documentation that delves into the validation and delegation aspects of PPoS. Current considerations involve the integration of the ZeroCash/zCash construction into the staking model.\n\n\nMilestone 3: Data Availability Sampling (RS, KZG) §\nResearch §\n\nLimitations discovered during RS and KZG implementation, notably with RS library scalability issues and bls12_381 curve finite field challenges. Found KZG libraries are primarily designed for Ethereum, which constrains the blob size.\nBenchmarks for KZG implementation were carried out, and simulation runs were conducted for different configurations.\nNode decay in relation to data availability was analyzed, leading to the derivation of an equation for understanding node averages in the network.\n\nDevelopment §\n\nKZG Library: https://github.com/logos-co/nomos-node/pull/325\nKZG Base Layer initial approach: https://github.com/logos-co/nomos-node/pull/309\nDetailed KZG Operation Benchmarks: https://github.com/logos-co/nomos-node/tree/da-kzg-benches\nNode Decay Analysis & Results: https://www.overleaf.com/read/gzqvbbmfnxyp\n"},"nomos/updates/2023-09-04":{"title":"2023-09-04 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"nomos: §\n\nnetwork privacy and mixnet: §\nresearch §\n\nNo specific research tasks reported this week related to this milestone.\n\ndevelopment §\n\nMade mixnet tests stable: https://github.com/logos-co/nomos-node/pull/334\nFinished the delay implementation: https://github.com/logos-co/nomos-node/pull/362\nMigrated the mixnode binary to Overwatch for better integration: https://github.com/logos-co/nomos-node/pull/339\nAdded a retry mechanism to the libp2p backend for transient errors: https://github.com/logos-co/nomos-node/pull/332\nFixed network tests failing with mixnet: https://github.com/logos-co/nomos-node/pull/338\nFix panic for RandomDelayIter: https://github.com/logos-co/nomos-node/pull/335\nConnection cache for mixnet: https://github.com/logos-co/nomos-node/pull/343\nImplemented mempool network adapters for libp2p: https://github.com/logos-co/nomos-node/pull/344\nImplemented the libp2p version of the addtx endpoint: https://github.com/logos-co/nomos-node/pull/345\n\n\ntestnet: §\ndevelopment: §\n\nPOC/Draft for testnet using Docker Compose: https://github.com/logos-co/nomos-node/pull/364\nDNS Multiaddr parsing and peer id configuration: https://github.com/logos-co/nomos-node/pull/346, https://github.com/logos-co/nomos-node/pull/361\n\n\nprivate PoS: §\nresearch: §\n\nIntroduced the Base Design section, focusing on the ZCash design’s constructions, building an understanding of the data structures and algorithms, and presenting relevant algorithms with comprehensive descriptions.\nDeveloped the Staking Extension section, leveraging Base Design constructions to introduce staking mechanics, defining the “Stake” algorithm that transforms shielded coins into voting “staking coins”, and the “Reward” algorithm that distributes rewards and restakes coins back into the pool.\nCreated the Consensus Modifications section, detailing modifications to the Carnot Consensus algorithm based on the Staking Extension, introducing mapping of staking coins to validator “shadows”, presenting the initial voting construction, introducing a vote aggregation mechanism, and elaborating on vote dissemination and aggregation through a tree overlay.\n\n\ndata availability: §\nresearch: §\n\nStudied more options for DA verification schemes: https://www.notion.so/Data-Availability-Specification-WIP-c3961b681eba4ccdab2be9181e4207b4\nReached some conclusions that allow us to make progress in implementing the architecture. Blocker: we need specialized cryptographic expertise to make further progress on this. I will personally keep working on it later on, but privacy matters are more important now as they have a higher impact on the architecture.\nAnalysis of node decay in the data availability problem is complete: https://www.overleaf.com/read/gzqvbbmfnxyp\n\ndevelopment: §\n\nIncluded BL blobs in the block: https://github.com/logos-co/nomos-node/pull/368\n"},"nomos/updates/2023-09-11":{"title":"2023-09-11 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"nomos: §\n\nnetwork privacy and mixnet: §\nresearch: §\n\nRevised mathematical methods, such as the Poisson point process, etc., used in analysis of mixnets.\nExplored literature related to mixnets where approaches from differential privacy are used. The latter could lead to a more general privacy guarantee which is relevant to not only current but also future attacks on privacy.\n\ndevelopment: §\n\nFixed a bug in the connection pool implementation https://github.com/logos-co/nomos-node/pull/373\nFixed Cargo.toml for nomos-network https://github.com/logos-co/nomos-node/pull/380\nAdded defaults to libp2p settings https://github.com/logos-co/nomos-node/pull/388\nFixed request handling in mixnode: https://github.com/logos-co/nomos-node/pull/372\nAdded benchmark code (in localhost): https://github.com/logos-co/nomos-node/pull/375\nAfter trying to find existing solutions to routing strategies (routing first, privacy later), and not finding a proper solution, moved to thinking about a naive approach: https://www.notion.so/WIP-Proposal-Routing-7b034dcac64940eda25ee415806d0ec8\nFound using sync Mutex will lead to a block. https://github.com/logos-co/nomos-node/pull/370\nFinish implementing the first version of retry for mixnode and mixclient https://github.com/logos-co/nomos-node/pull/386\n\n\ntestnet: §\ndevelopment: §\n\nNode config via environment variables: https://github.com/logos-co/nomos-node/pull/382\nObservability and node configuration in testnet work in progress: https://github.com/logos-co/nomos-node/pull/364 (Same draft PR as last week WIP).\nResolving more GH Actions related issues:\n\nhttps://github.com/logos-co/nomos-node/pull/385\nhttps://github.com/logos-co/nomos-node/pull/389\n\n\n\n\nprivate PoS: §\nresearch: §\n\nFound an issue in vote propagation of the PPoS construction: When a vote is propagated upstream to the higher committee there is a chance that a malicious shadow in committee decides not to broadcast their vote to the committee members and send it only upstream. Then this “unseen” vote will block the possibility of reconstructing the most common committee_vote, and at the same time prove that other shadows have voted. The solution for that is to propagate a map of seen votes upstream alongside the vote, this enables the higher committee to select only the votes that are most commonly seen for building the committee_vote thus making that kind of malicious behavior detectable.\nImproving the PPoS description: working on selecting proper naming conventions, as currently there are voters, shadows, coins which are confusing. That is done in pair with revising the logic.\n\n\ndata availability: §\nresearch: §\n\nA draft for private DA can be found here: https://www.notion.so/Data-Availability-Specification-c3961b681eba4ccdab2be9181e4207b4?d=d4e8d1bcd6224682ba74737100106e48#0c70202794214cbab626e51f7f1f7c24\n\ndevelopment: §\n\nBlobs in block: https://github.com/logos-co/nomos-node/pull/368\nDA service architecture: https://github.com/logos-co/nomos-node/pull/376\nDa service backend implementation: https://github.com/logos-co/nomos-node/pull/381\n"},"nomos/updates/2023-09-19":{"title":"2023-09-19 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"nomos: §\n\nnetwork privacy and mixnet: §\nresearch: §\n\nReview of the “Untraceable electronic mail, return addresses, and digital pseudonyms” paper. Review of the “The Loopix anonymity system” paper.\nNotes provided in the overleaf document https://www.overleaf.com/read/rybwvjftfrrg\n\ndevelopment: §\n\nPolishing mixnet to make it ready for the testnet:\nHelping preparing mixnet deployments: https://github.com/logos-co/nomos-node/pull/408\nReviewed mixnet connection management\nRefactor the libp2p network backend: https://github.com/logos-co/nomos-node/tree/libp2p-refactor-yjlee and based on that prepare to measure the quality of unobservability - https://github.com/logos-co/nomos-node/issues/391\nBlock building: https://github.com/logos-co/nomos-node/pull/401\nFountain codes: https://github.com/logos-co/nomos-node/pull/407\nGot the mixnet retry PR merged: https://github.com/logos-co/nomos-node/pull/386\nFinish the concrete error implementation for mixnet and ready for merge: https://github.com/logos-co/nomos-node/pull/405\nWIP: fan-in message passing model for mixnode: https://github.com/logos-co/nomos-node/tree/mixnet-fan-in\n\n\ntestnet: §\ndevelopment: §\n\nTestnet preparation: https://github.com/logos-co/nomos-node/pull/410\nTestnet POC with libp2p merged: https://github.com/logos-co/nomos-node/pull/364\nThe POC for testnet using etcd and docker compose was reviewed and merged. The mixnet functionality will be added on top of this.\nSimulation branch overlay with 1 committee fix: https://github.com/logos-co/nomos-node/pull/402\nA bug where branch overlay results different from tree overlay with one committee blocked research team to use simulations results. Fixed it.\nImprovements in CI:\n\nhttps://github.com/logos-co/nomos-node/pull/409\nhttps://github.com/logos-co/nomos-node/pull/411\nhttps://github.com/logos-co/nomos-node/pull/412\n\n\nMinor improvements to remove annoying red x’s from our CI\n\n\nprivate PoS: §\nresearch: §\n\nShadows logic: Looking at how to describe the logic of the shadow in the most clear way: It will be divided into a set of modules, each module taking care of processing a separate communication channel.\nAll channels have their logic described in adequate modules and with references to self-descripting functions. However, some of them (like how exactly to aggregate votes) must yet to be defined.\nHastiness issues: In short, the leader, in order to limit the cost of vote aggregation can decide to not to include votes from top committees (and root in particular). This is an acceptable strategy and will lead to a correctly formed aggregation proof. The proof will include a global threshold of votes from lower committees but not from the top committees (and root committee in particular). The impact of this leader’s hastiness does not break the security of the protocol as a threshold of votes is correctly gathered. However, it may limit rewards from the top committees (and root in particular), as the votes from those committees may not be needed to reach the threshold. More on that under the issues section of the PPoS doc.\n\n\ndata availability: §\nresearch: §\n\nFirst stab at privacy solution for the network layer for consensus and DA: https://www.notion.so/Practical-Private-Addressing-Network-Privacy-Component-2-2b9b4923124a4fdb81dba5d2bba1d289?d=99166164267a46589c5715175e1b3657#5e27d2010d30468f9d8f0d0928b9c639\nInit survey of SoA in network privacy alternative solutions\n\ndevelopment: §\n\nDA nomos core kickstart, added different pieces that were missing for abstractions: https://github.com/logos-co/nomos-node/pull/390\nAdded attestation trait\nAdded certificate trait\nAdded DaProtocol trait that abstracts encoding/decoding, and put the pieces together for blob+attestation+certificate handling.\nRefactored (moved and restructured) da modules\nRefactor and improve common traits - https://github.com/logos-co/nomos-node/pull/395\nImplement a simple da protocol with full replication - https://github.com/logos-co/nomos-node/pull/400\nImplement a command to disseminate blobs through the network - https://github.com/logos-co/nomos-node/pull/396\nAdded da-service to nomos node - https://github.com/logos-co/nomos-node/pull/404\nHousekeeping:\n\nhttps://github.com/logos-co/nomos-node/pull/403\nhttps://github.com/logos-co/nomos-node/pull/388\nhttps://github.com/logos-co/nomos-node/pull/399\n\n\n"},"nomos/updates/2023-09-26":{"title":"2023-09-26 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"nomos: §\n\nnetwork privacy and mixnet: §\nresearch: §\n\nWith the assumption that nodes of a mixnet are selected without replacement, we performed analysis with Byzantine node presence (for specific widths and lengths). This gives the probability that there is at least one path where all nodes are Byzantine (“anonymity” failure)\nEvaluation in the “Loopix” paper used the mixnet with n1=2 and L=5\nConclusion: probability of anonymity failure decreases when increasing length and increases with increasing width\nNotes provided in the overleaf document https://www.overleaf.com/read/rybwvjftfrrg\nDiscussions on how to model the network privacy for analysis; viability of the embedded mixnet design\nNotes (WIP): https://www.notion.so/Network-Privacy-2dabf0aa878744e299b2ebb97120876f\n\ndevelopment: §\n\nMaking integration tests work with FlatOverlay and RandomBeacon:\n\nhttps://github.com/logos-co/nomos-node/pull/425\nhttps://github.com/logos-co/nomos-node/pull/426\n\n\nSome integration tests are randomly failed. Debugging them: https://github.com/logos-co/nomos-node/pull/437\nRefactoring libp2p network layer: https://github.com/logos-co/nomos-node/pull/417\nAdd missing error handlings in mixnet: https://github.com/logos-co/nomos-node/pull/436 (+ more coming soon)\nTrying to enable gathering metrics for libp2p (but needs to be discussed about how this can be used with our existing metrics service): https://github.com/logos-co/nomos-node/pull/431\nNew mixnet message handle PR: https://github.com/logos-co/nomos-node/pull/435\nQC checks: https://github.com/logos-co/nomos-node/pull/430\n\n\ntestnet: §\ndevelopment: §\n\nTreeOverlay in Nomos node:\n\nhttps://github.com/logos-co/nomos-node/pull/415\nhttps://github.com/logos-co/nomos-node/pull/423\n\n\nAfter adding tree overlay to Nomos node, integration tests started failing. Main reason was that the leader didn’t spawn in time and nodes failed to send their votes. This mainly affected the happy path test. Work will be merged once the issues are fixed.\nTestnet with mixnode: WIP\nWork on the mixnet node in testnet continues. Ongoing inter-team discussions in regards to how we should monitor and extract info from the network. The PR for libp2p metrics might be the way to go.\nCI chores: https://github.com/logos-co/nomos-node/pull/432\n\n\nprivate PoS: §\nresearch: §\n\nAdd missing function descriptions and finalize structure definitions.\nDefined/redefined structures used in all algorithms that required a rewrite.\nUpdated the terminology and made the Shadows name obsolete, and now they are called Validators (for synchronization with other PoS designs).\nThe validators logic was redesigned, improved and updated accordingly.\nThe same was with the ledger/transactions part, and now they form a complete logic.\nReadability: the specification part was updated. The rest of the document is out of sync and needs to be revised as the focus was put on the specification.\nCritical analysis: an issue was identified and described (under the issues section) that touches on a problem where insufficient number of votes are aggregated and the need for an additional voting round before commencing an overlay tree reconstruction. This can be mitigated with an additional votes collection from late voters (before the tree timeout) or increased level of votes that are collected during initial voting collection.\nReview of the Delegation and Validation rewards document by Frederico.\n\n\ndata availability: §\ndevelopment: §\n\nDissemination ready\n\nhttps://github.com/logos-co/nomos-node/pull/416\nhttps://github.com/logos-co/nomos-node/pull/400\nhttps://github.com/logos-co/nomos-node/pull/404\n\n\nMempool for certificates in progress\n"},"nomos/updates/2023-10-09":{"title":"2023-10-09 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet: §\nresearch: §\n\nDerived asymptotic expressions for anonymity and communication failure probabilities, when taking into account certain values for population size and network size. Used simulations and analytic framework to study failure probabilities in mixnets of different sizes. Assuming delays between sending and receiving messages are independent random variables from the exponential distribution, derived probability distribution of latency. Main result: one cannot have both low probability of communication and low probability of anonymity failures. The probability of anonymity failure is decreasing with the number of layers but at the expense of increasing the latency.\nFinalize research of network-level privacy solutions. Learned important information on: Framework for formalizing privacy, Nym and tokenomics of a Mixnet, Sphinx, and Loopix. Notes found at: https://www.notion.so/Network-Privacy-2dabf0aa878744e299b2ebb97120876f (summaries still WIP).\n\ndevelopment: §\n\nLock Overwatch to a specific revision in nomos: https://github.com/logos-co/nomos-node/pull/455.\nImplement and pipe services lifecycle handling in Overwatch: https://github.com/logos-co/Overwatch/pull/27.\nBash is being replaced with python due to adding mixnet to docker. At the moment, small issues with node spawning order are being resolved (for tree overlay). ETA on finishing: beginning of this week.\nAdd API to return mempool item status: https://github.com/logos-co/nomos-node/pull/449.\nMake libp2p gossipsub settings configurable: https://github.com/logos-co/nomos-node/pull/454.\nAvoid temporary gossipsub errors when bootstrapping tests: https://github.com/logos-co/nomos-node/pull/442.\n\ntestnet: §\ndevelopment: §\n\nSkeleton for nomos API service - https://github.com/logos-co/nomos-node/pull/451.\nSupport generics for overwatch derive - https://github.com/logos-co/Overwatch/pull/26.\nFix clippy warnings for rust 1.73 - https://github.com/logos-co/nomos-node/pull/452.\nRemove waku mentions from codebase - https://github.com/logos-co/nomos-node/pull/446.\nImproved integration tests.\nHandle corner cases in the unhappy path: https://github.com/logos-co/nomos-node/pull/438.\nAdd canonical ID to attestations and certificates: https://github.com/logos-co/nomos-node/pull/448.\nAdd functionalities to nomos-cli: https://github.com/logos-co/nomos-node/pull/450.\n\nprivate PoS: §\nresearch: §\n\nExploring multi-staking PPoS design for Carnot.\nIdea: a slightly modified version of PoS, unknown how much funds a single validator has and validators are grouped by the amount of stake they have. This property gives validators group-based k-anonymity, where they are indistinguishable (on the stake level). This also enables us to assign the same voting power per each group of validators, which then can be reflected on the overlay structure.\nConsidering a couple of additional stake hiding/obfuscating techniques without making the initial design too complex. We incentivize/penalize validators based not on the voting power they represent but on the stake. We can have a system that diverges from an equality between voting power and stake, to a system that approximates the voting power based on the stake but the rewarding/penalization directly follows the stake.\n\ndata availability: §\ndevelopment: §\n\nDA nomos API based on the new skeleton: https://github.com/logos-co/nomos-node/pull/456.\nAdd API to return DA blobs: https://github.com/logos-co/nomos-node/pull/453.\n"},"nomos/updates/2023-10-17":{"title":"2023-10-17 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet: §\nresearch: §\n\nFinalized the write up and summaries of the privacy network research - https://www.notion.so/Network-Privacy-2dabf0aa878744e299b2ebb97120876f (Pinned those notes that are the most important, to serve as a guidance for anyone who wants to have a quicker overview of the topic)\n\n\ntestnet: §\ndevelopment: §\n\nImproved integration tests: https://github.com/logos-co/nomos-node/pull/458\nPreparing for demo\nLifecycle handling: https://github.com/logos-co/nomos-node/pull/457\nA note on current testnet implementation. Realized that even with python code the configuration of mixnet and libp2p nodes are getting too complicated, nodes are still missing features and the glue code is not a solution in the long run. Will have more discussions.\n\n\nprivate PoS: §\nresearch: §\n\nInitial proposal for multi-staking PPoS design for Carnot: https://www.notion.so/Sketch-Approximated-PoS-with-k-anonymity-towards-multi-staking-for-Carnot-BFT-e066eb4f80114ddc862a8665aea952b6?pvs=4\n\n\ndata availability: §\nresearch: §\n\nSona polynomial commitment scheme was examined and found to be applicable to data availability. Comparisons and notes can be viewed here:https://www.notion.so/Polynomial-Commitment-Schemes-59bf8f6fe39840babe819c5c0a9628fc\nIf we continue with KZG, the method to be followed for “trusted setup” was investigated. Some methods can be found here: https://www.notion.so/Trusted-Setup-19a29ee752f14e96895328a0bd7a9634\nAdded notes on using prime field: https://www.notion.so/Notes-c4a680142a954953a2c0ea0e4b6fdcf1\n\n\nEurorust Event: §\nHere are some notes by Daniel about the event the Engineering Team attended to last weekend:\n\nFrom the ecosystem speeches we can say they are constantly making efforts on making the language mature. impl Trait in traits are coming later this year, will impact our codebase (will need some refactors). It doesn’t look like a big change but it kind of is. We use a lot of abstractions (futures + streams mostly) that force use to box everything (dynamic dispatch), that now will be statically dispatched.\nOverall keynotes and speeches were not really good. More exploratory than anything. Some of them showed tech that was mostly not relevant to us.\nGathering the team had some impact. We had some bonding on related topics that all of us enjoy. And we had some conversations that otherwise would not probably took place.\nIMO probably not worth to repeat this kind of events unless we participate in a more active way (preparing a speech ourselves and apply which I think we are totally capable of. We have a few things we could show up - Simulation app or Overwatch for example).\n"},"nomos/updates/2023-10-23":{"title":"2023-10-25 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet: §\nresearch: §\n\nSet up a calculation for the probability of anonymity (communication) failure in the mix network of a large size, sampled from a large population of nodes, such that mix network size is comparable with the node population size. The latter is the most challenging regime to analyse but potentially can give us much more accurate estimates of probabilities. Previously we have analysed regimes when mix network size is much smaller than network size and when all nodes in the network are also used in the mix network.\nNotes on “Anonymity Trilemma: Strong Anonymity, Low Bandwidth Overhead, Low Latency - Choose Two” paper provided in the overleaf document. https://www.overleaf.com/read/rybwvjftfrrg ; The latter derives necessary conditions for anonymous communication in terms of latency, amount of noise messages and some measure of anonymity.\n\ndevelopment: §\n\nMixnet development specifications: went through the Loopix paper again - writing the draft specs: https://www.notion.so/WIP-Mixnet-Development-Specifications-807b624444a54a4b88afa1cc80e100c2 (covering the current Loopix-based implementation + Future work: cover traffic, multicasting (TBD), incentivization (TBD))\n\ntestnet: §\ndevelopment: §\n\nSave block contents to storage - https://github.com/logos-co/nomos-node/pull/464\nRefactoring for future content - https://github.com/logos-co/nomos-node/pull/461\nServices state watchers - added a first version so overwatch can await for other services signal that they are ready to work. First version using relay did not work (among other things, too complicated). Second version uses an aditional handle per service, it is morestraight forward. It may add more intricated relationship among services, and they cannot be handled/caught on runtime. Testing only for now.\nFailing services status PR: https://github.com/logos-co/Overwatch/pull/29\nWorking services status PR: https://github.com/logos-co/Overwatch/pull/30\nUpdate lifecycle handling: https://github.com/logos-co/nomos-node/pull/457\nGenerics metrics API: https://github.com/logos-co/nomos-node/pull/466\nHuman readable ser/deser for array based types: https://github.com/logos-co/nomos-node/pull/468\nUpdate libp2p breaking changes: https://github.com/logos-co/nomos-node/pull/470\nFinished mixnodes in docker testnet: https://github.com/logos-co/nomos-node/pull/467 - The testnet in docker compose is now merged and has a README. There are still room for improvement, like spawning some nodes sequentially (like in https://github.com/logos-co/nomos-node/pull/425), but this will be solved in added in a new PRs or solved by other node improvements.\nImprovements for node config: https://github.com/logos-co/nomos-node/pull/460, https://github.com/logos-co/nomos-node/pull/471 - These changes were required for spawning nodes in testnet, will be useful for our endusers too\n\nprivate PoS: §\n::research §\n\nSingle-staking - reviewed and updated the design up to the construction section.\nMulti-staking - all comments have been addressed, but new are coming.\nRight now we are investigating a scenario where we are limiting the amount of validators in the Single-Staking case by diverging from the requirement of having multiples of validators by removing the economical incentives. In other words, we are considering to allow registering validators that have at least a threshold of stake (that is or is not capped) and a single (unitary) voting power. This way we are limiting the economical need for having multiple validators hosted by a single node, and at the same time limiting the network overhead of the single-staking design.\nThe “Delegation and Validation Rewards” document (WIP): https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4\nIncorporating notes in the architecture whitepapers. These readings are not as deeply technical as papers, but more about understanding the directions currently explored at the edge of blockchain architectures (namely rollups, modular architectures and intent-centric architectures).\nWorking on the problem of PPoS, one of the most critical points of focus right now, to have at least an understanding of the available options\n\nnomos::data availability §\n::research §\n\nHyrax, Dory and Dark schemes were studied, comparisons here: https://www.notion.so/Polynomial-Commitment-Schemes-59bf8f6fe39840babe819c5c0a9628fc ; It was concluded that schemes with verifier time above logarithmic are not a good option for data availability.\nFRI is a structure that should be used not for now, (at this stage especially, due to large proof size - higher than KZG), but can be used for quantum resistance in the future. Here are some sources that say this can be used in later stages (the reasons are the same as ours). - https://scroll.io/blog/kzg#user-content-fn-6 and https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Why-use-the-hash-of-the-KZG-instead-of-the-KZG-directly\n\n::development §\nnomos::miscellaneous §\n\nDavid Rusu has joined - warm welcome to him!\n"},"nomos/updates/2023-10-30":{"title":"2023-10-30 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet: §\nresearch: §\n\nAnalysis of failure probability in random partitions of networks constructed from nodes with prescribed voting “weights” - derived equations for the probability of anonymity (communication) failure in the mix network of a large size, n, sampled from a large population of nodes of the size, N, such that n is comparable with N (https://www.overleaf.com/read/rybwvjftfrrg). Analysis of these equations is currently in progress.\nSet up a model of random partitions of networks where each node has a weight (https://www.overleaf.com/read/kkmsngmcgbkj#c4de95). Derivation of probability distributions for this model is currently in progress.\nWe have agreed to put more effort into designing a fully weighted multi-staking privacy PoS design. The goal is to map the space of possible solutions (at least the subset of solutions that have been worked on and thought about lately) and their impact on the privacy, security and efficiency of the network.\n\ndevelopment: §\n\nMixnet specifications: Goals + Basic specs (implemented already) + Cover traffic - https://www.notion.so/WIP-Mixnet-Development-Specifications-807b624444a54a4b88afa1cc80e100c2\nMaking Nomos & Mixnode stable for Testnet - Investigated/resolved CI failures: https://github.com/logos-co/nomos-node/pull/49\n\ntestnet: §\ndevelopment: §\n\nTest nomos demo this week!\nSimulation overlay topology info: https://github.com/logos-co/nomos-node/pull/478 and https://github.com/logos-co/nomos-node/pull/479 - to understand better how the network topology looks inside a simulation with a large number of nodes, a way to visualise the network was added\nSimulation optional network capacity: https://github.com/logos-co/nomos-node/pull/483 - after discussing potential issues for getting baseline simulation results for networks with large number of nodes, the option to disable network capacity simulation was added. Advised the DST team to drastically increase the timeout number, so that the baseline will have all the nodes participating (happy path)\nTestnet consensus layer setup: https://github.com/logos-co/nomos-node/pull/482\nCI summary for long running integration tests: https://github.com/logos-co/nomos-node/pull/484\nDiscussion about metrics service and prometheus - current http metrics service is fine, but its design is more fitting for the UIs rather than metrics collectors like prometheus. Explored this idea with libp2p (https://github.com/logos-co/nomos-node/pull/431), it seems like a good idea to have a node-wide service like node-http-api for prometheus metrics.\nFix overwatch lifecycle refactor issue: https://github.com/logos-co/Overwatch/pull/31\nSighandler service: https://github.com/logos-co/nomos-node/pull/480\nImplement da-blob API: https://github.com/logos-co/nomos-node/pull/487\nImplement storage API: https://github.com/logos-co/nomos-node/pull/488\nImplement add cert and add tx APIs: https://github.com/logos-co/nomos-node/pull/489\nIntegrate the new HTTP backend to nomos-node: https://github.com/logos-co/nomos-node/pull/490\nAdd http API to revive block contents from storage: https://github.com/logos-co/nomos-node/pull/473\nAdd API to revive DA blobs: https://github.com/logos-co/nomos-node/pull/477\nAllow deprecated type in Swarm: https://github.com/logos-co/nomos-node/pull/486\n\nprivate PoS: §\nresearch: §\n\nRewards for validators/delegators - the live document “Delegation and Validation Rewards”: https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4\nRead up on Zarcanum (PPoS chain), not much to get inspired from them - https://www.notion.so/Private-Proof-of-Stake-182722d1bdef4894af1d56fece334eae#b8cc6b67f7334b41930bd091458dff2b\nWeighted-BRB - https://www.notion.so/Weighted-Byzantine-Reliable-Broadcast-in-front-of-PoS-consensus-d160a930522942ac98ebf42dc7c515bd\n\ndata availability: §\nresearch: §\n\nSurvey of polynomial commitment schemes - https://www.notion.so/Mehmet-5e698a9bba5d489aa058d3a695cda12f - work in progress, but-RS+KZG seems to be the more reasonable option for data availability at the first stage.\n"},"nomos/updates/2023-11-06":{"title":"2023-11-06 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\ndevelopment §\n\n\nEnriched cover traffic specs: Notion link \n\n\nAdded a fallback for the case where mixnet fails: Notion link \n\n\nNomos integration test stabilization\n\n\nTune timeouts (by heavy debugging):\n\nhttps://github.com/logos-co/nomos-node/pull/492\nhttps://github.com/logos-co/nomos-node/pull/494 \n\n\n\nPrevent Duplicate error from libp2p gossipsub broadcasting: https://github.com/logos-co/nomos-node/pull/498 \n\n\nFix port conflict: https://github.com/logos-co/nomos-node/pull/504 \n\n\nStore CI artifacts:\n\nhttps://github.com/logos-co/nomos-node/pull/508 \nhttps://github.com/logos-co/nomos-node/pull/510 \n\n\n\nMixnet implementation improvement\n\n\nMixclient reconnect: https://github.com/logos-co/nomos-node/pull/501 \n\n\ntestnet §\ndevelopment §\n\nServices APIs:\n\nhttps://github.com/logos-co/nomos-node/pull/476 \nhttps://github.com/logos-co/nomos-node/pull/487 \nhttps://github.com/logos-co/nomos-node/pull/488 \nhttps://github.com/logos-co/nomos-node/pull/489 \n\n\nMempool aware of included blocks: https://github.com/logos-co/nomos-node/pull/485\nVoter attestation: https://github.com/logos-co/nomos-node/pull/498 \nCommunity PRs - typos:\n\nhttps://github.com/logos-co/nomos-node/pull/503 \nhttps://github.com/logos-co/nomos-node/pull/481 \n\n\nHttp API integration (Made the CI all green for the integrating PRs): https://github.com/logos-co/nomos-node/pull/490 \nChat demo: https://github.com/logos-co/nomos-node/pull/495 \nNomos node types (extract common types from nomos-node crate): https://github.com/logos-co/nomos-node/pull/496 \nNomos update for demo call: Notion link \nStatic testnet configuration: https://github.com/logos-co/nomos-node/pull/499 \nIn order to reliably expose all services when deployed, static configuration was added.\nPublic deployment of temporal nomos testnet: ⁠general⁠\nTo work out all missing pieces a temporal VPS was chosen for testnet deployment. The deployment was tested with nomos-cli app\nPreparing for testnet deployment on nomos infrastructure: https://github.com/status-im/infra-misc/issues/189 \nTo have testnet properly deployed and available at nomos.tech domain, we need to deploy it on - New API: https://github.com/logos-co/nomos-node/pull/509 \nImplement a basic version concrete error for Overwatch: https://github.com/logos-co/Overwatch/pull/32 \nRemove included  blocks from mempool: https://github.com/logos-co/nomos-node/pull/485\nDA utilities: https://github.com/logos-co/nomos-node/pull/493  \nRework consensus API: https://github.com/logos-co/nomos-node/pull/502 \nInclude block ID during serialization of carnotinfo:\nhttps://github.com/logos-co/nomos-node/pull/505  \nOpened a new issue: https://github.com/logos-co/nomos-node/issues/506 \n\nprivate PoS §\nresearch §\n\nMulti-staking - prepared a discussion doc drafting a couple of ideas such as: how we can hide stake/voting power using homomorphic encryption and the consequences of that approach. The bottom line is that with Carnot and its tree structure we cannot follow the generic Proof of Stake approach and hide the voting power at the same time. We need to modify the Proof of Stake to follow the number of votes rather than the voting power during the vote aggregation phase. This modification bears consequences that need to be studied carefully, as the probability of a failure or liveness issues might be higher: Notion link \nRich Nodes Attack on Weighted Carnot worked out an attack that any private weighted-Carnot protocol will need to overcome: Notion link \nPrivate Weighted Voting w/ Ring Signatures a solution to the above attack that relies on ring signatures to break the connection between a vote and voter: Notion link \nFrom discussions on the above docs, started accumulating a summary of which behaviors to reward or penalize: List of Rewarded and Penalized Actions: Notion link \nDerived a probability distribution for the weights of committees for a scenario  when weights of nodes, modeled as random variables, are sampled in every voting round.\nA derivation of a probability distribution for a scenario when weights of nodes are only sampled once (currently in progress).\nWrote a simulation code which would  allow us  to compare failure probabilities in the above  two scenarios with the (unweighted) original Carnot version.\nDetails for probability distribution for the weights of committees for a scenario when weights of nodes, modeled as random variables, are sampled in every voting round, are provided in https://www.overleaf.com/read/kkmsngmcgbkj#c4de95 \nRewards for validators/delegators: the live document Notion link \nResearch notes on rewards for validators/delegators: Notion link \nList of Rewarded or Penalized Actions: Notion link \n\ndata availability §\nresearch §\n\nFinished the survey on the polynomial commitment schemes: Notion link  \nPCS related libraries were examined. The structures and benchmarks used were reviewed. Resources related to this were added to the research notes above. \nThis work in particular is a nice compilation:https://xn—2-umb.com/23/pc-bench/ \nStudied on EC+Commitment data structures. 1D or 1.5D structure may be more suitable for data availability within the scope of the Nomos project: Notion link \n\ndevelopment §\nmiscellaneous §\n\nNomos team will be at the offsite next week.\n"},"nomos/updates/2023-11-13":{"title":"2023-11-06 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nAnalysis of failure probability in random partitions of networks constructed from nodes with prescribed voting “weights”:\nConsidered a scenario when weights and Byzantine labels of nodes are sampled once, i.e. fixed, and then assigned to committees randomly.\nA derivation of a probability distribution for the random process is currently in progress\nConsidered designing a gradient descent algorithm which, given weights and Byzantine labels of nodes, tries to find assignments to committees with the smallest number of failures.\nAnalysis and implementation of the above algorithm is currently in progress. -reviewed literature on analysis of Loopix mixnets and implemented code for a simulation which computes fraction of de-anonymized messages.\nThe details on all of the above are provided in https://www.overleaf.com/read/kkmsngmcgbkj#c4de95\nWalked through core parts of Nym implementation again to get details of what are written in papers.\nClarified sphinx packet creation process (+ encryption): https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2#d0bbc9d1f63e43faaa30bb4c888102bd]\nClarified delay calculation in Poisson distribution (inspired to Nym impl): https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#3ae7e03fcbad461ab8d6b57e5c0e88fe\nClarified loop cover traffic creation & interval in Poisson (inspired to Nym impl): https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#14f53c5d6c844c828689f0412d5e2195\nSuggesting skipping two other types of cover traffic (at least, for now)\nDrop cover by nomos-node: https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#76993c1312ea464a88557987a2f37b60\nLoop cover by mix-node: https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#f07a473a4b5d4f338ff024a145f6b525\n\ndevelopment §\n\nNomos integration test stabilization: https://github.com/logos-co/nomos-node/pull/533\nMixnet implementation improvement\nFixed the concurrent packet handling in Mixnode: https://github.com/logos-co/nomos-node/pull/530\n\ntestnet §\ndevelopment §\n\nPublic deployment of Nomos testnet on nomos.tech infra: ⁠general, https://github.com/status-im/infra-misc/issues/189, https://github.com/logos-co/nomos-node/pull/513, https://github.com/logos-co/nomos-node/pull/520, https://github.com/logos-co/nomos-node/pull/524\nThe hardware and automation done and already running a master branch of our docker compose testnet. New tasks will be created for improving metrics, logging and stability, but this is a big milestone as we are now in control of this environment.\nPrometheus with new http api: https://github.com/logos-co/nomos-node/pull/522, https://github.com/logos-co/nomos-node/issues/523\nA proposal for metrics collection using prometheus, this will enable us to see what’s happening in the node network easier.\nSimulations finalization times debugging: The issue when views are advanced faster than they should in simulations remains, the ability to remove all network constraints didn’t resolve the issue. I still don’t know the main reason for it, hopefully this week we’ll have a breakthrough in this regard.\nFixed an issue with nomos-cli api https://github.com/logos-co/nomos-node/pull/525\nAdd options to provide custom writer for log https://github.com/logos-co/nomos-node/pull/518\nDisable logs https://github.com/logos-co/nomos-node/pull/517\nRemove process::exit(1) from library code https://github.com/logos-co/nomos-node/pull/516\nLimit carnot/blocks response size https://github.com/logos-co/nomos-node/pull/515\nDo not use 0x prefix in serialization https://github.com/logos-co/nomos-node/pull/514\nIdentified https://github.com/logos-co/nomos-node/issues/526\n\nprivate PoS §\nresearch §\n\n“Delegation and Validation Rewards” doc update: https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4\nMulti-staking: The discussion doc was discussed and we have decided that the complexities mentioned in the document are currently out of the scope.\nPrivate Leader Election: During the week it become more apparent that the private voting design is not a priority and we have decided to design a (general also multi-staking compatible) private leader election mechanism that is based on the single-staking design. The output is documented here: https://www.notion.so/Private-Leader-Election-for-Carnot-PoS-e720168ff3c44d098ec6a4aa586188da?pvs=4\nExplore interesting lines for PPoS:\n\n\n\n[Automatic Persistant Validator Identifier from Public Staking Transactions](https://www.notion.so/Public-Stake-Value-w-o-a-Persistent-Identifier-62a3237b97d44b87924ba3fff74f0362?pvs=4 “Automatic Persistant Validator Identifier from Public Staking Transactions)\n\n\nSingle Staking w/ Network Tricks\nFailed attempt: Hashed and Salted Stakes\nIs Network Privacy enough for PPoS\n\n\n\ndata availability §\nresearch §\n\n\n\ndevelopment §\nmiscellaneous §\n\nNomos team will be at the offsite this and next week (ends of 2023-11-23).\n"},"nomos/updates/index":{"title":"Nomos Weekly Updates","links":[],"tags":[],"content":"These are all the Nomos weekly updates that are reported to Logos Insight team."},"tags/component":{"title":"Components","links":["creating-components"],"tags":[],"content":"Want to create your own custom component? Check out the advanced guide on creating components for more information."},"tags/vac-updates":{"title":"Vac updates","links":[],"tags":[],"content":"Here are all files that are tagged with #vac-updates"},"terms-of-use":{"title":"Website Terms of Use","links":[],"tags":[],"content":"These terms and conditions (“Website Terms of Use”) are entered into by you and us, and they govern your access and use of the Website, including any content and functionality contained in the Website. \nIt is your responsibility to read the Website Terms of Use carefully before your use of the Website and your use of the Website means you have agreed to be bound and comply with these Website Terms of Use. \nIf you do not agree with these Website Terms of Use, you must not access or use the Website. \nDisclaimers §\nThe Website is provided by us on an ‘as is’ basis and you use the Website at your own sole discretion and risk.\nWe disclaim all warranties of any kind, express or implied, including without limitation the warranties of merchantability, fitness for a particular purpose, and non-infringement of intellectual property or other violation of rights. We do not warrant or make any representations concerning the completeness, accuracy, legality, utility, reliability, suitability or availability of the use of the Website, the content on this Website or otherwise relating to the Website, such content or on any sites linked to this site.These disclaimers will apply to the maximum extent permitted by applicable law. \nWe make no claims that the Website or any of its content is accessible, legally compliant or appropriate in your jurisdiction. Your access or use of the Website is at your own sole discretion and you are solely responsible for complying with any applicable local laws. \nThe content herein or as accessible through this Website is intended to be made available for informational purposes only and should not be considered as creating any expectations or forming the basis of any contract, commitment or binding obligation with us. No information herein shall be considered to contain or be relied upon as a promise, representation, warranty or guarantee, whether express or implied and whether as to the past, present or the future in relation to the projects and matters described herein.\nThe information contained herein does not constitute financial, legal, tax, or other advice and should not be treated as such. \nNothing in this Website should be construed by you as an offer to buy or sell, or soliciting any offer to buy or sell any tokens or any security. \nForward looking statements §\nThe Website may (or as made accessible through this Website) also contain forward-looking statements that are based on current expectations, estimates, forecasts, assumptions and projections about the technology, industry and markets in general.\nThe forward looking statements, which may include statements about the roadmap, project descriptions, technical details, functionalities, features, the development and use of tokens by projects, and any other statements related to such matters are subject to a high degree of risk and uncertainty. The forward looking statements are subject to change and are based on, among other things, market conditions, technical developments, and regulatory environment. The actual development and results, including the order and the timeline, might vary from what is presented. The information contained on this Website is a summary and does not purport to be accurate, reliable or complete and we bear no responsibility for the accuracy, reliability or completeness of information contained herein. Because of the high degree of risk and uncertainty described above, you should not place undue reliance on any matters described in this website or as accessible through this Website.\nWhile we aim to update our website regularly, all information, including the timeline and the specifics of each stage, is subject to change and may be amended or supplemented at any time, without notice and at our sole discretion.\nIntellectual property rights §\nThe Website and its contents are made available under free and open source licences. This means that anyone can use, share, and modify such content, as long as they follow the terms of the applicable licence. \nThird party website links §\nTo the extent the Website provides any links to a third party website, then their terms and conditions, including privacy policies, govern your use of those third party websites. We have no control over such third party websites and will not be liable for your use of or activities on any third party websites accessed through the Website. If you access such third party websites through the Website, it is at your own risk and you are solely responsible for your activities on such third party websites. \nThe Website may embed videos from Youtube, a service provided by Google LLC, using Youtube’s privacy-enhanced mode. When you interact with such videos, Youtube may place cookies on your personal device. The cookies do not directly identify individual users and YouTube will not store information to personalise your experience unless you are logged in to a Google account. We do not have any control over these cookies set by Youtube and it is recommended that you review YouTube’s embedding videos information page. \nLimitation of liability §\nWe will not be held liable to you under any contract, negligence, strict liability, or other legal or equitable theory for any lost profits, cost of procurement for substitute services, or any special, incidental, or consequential damages related to, arising from, or in any way connected with these Website Terms of Use, the Website, the content on the Website, or your use of the Website, even if we have been advised of the possibility of such damages. In any event, our aggregate liability for such claims is limited to EUR 100 (one hundred Euros). This limitation of liability will apply to the maximum extent permitted by applicable law.\nIndemnity  §\nYou shall indemnify us and hold us harmless from and against any and all claims, damages and expenses, including attorneys’ fees, arising from or related to your use of the Website, the content on the Website, including without limitation your violation of these Website Terms of Use. \nModifications §\nWe may modify or replace any part of this Website Terms of Use at any time and without notice. You are responsible for checking the Website periodically for any changes. The new Website Terms of Use will be effective immediately upon its posting on the Website.\nGoverning law §\nSwiss law governs these Website Terms of Use and any disputes between you and us, whether in court or arbitration, without regard to conflict of laws provisions.\nDisputes §\nIn these terms, “dispute” has the broadest meaning enforceable by law and includes any claim you make against or controversy you may have in relation to these Website Terms of Use, the Website, the content on the Website, or your use of the Website \nWe prefer arbitration over litigation as we believe it meets our principle of resolving disputes in the most effective and cost effective manner. You are bound by the following arbitration clause, which waives your right to litigation and to be heard by a judge. Please note that court review of an arbitration award is limited. You also waive all your rights to a jury trial (if any) in any and all jurisdictions. \nIf a (potential) dispute arises, you must first use your reasonable efforts to resolve it amicably with us. If these efforts do not result in a resolution of such dispute, you shall then send us a written notice of dispute setting out (i) the nature of the dispute, and the claim you are making; and (ii) the remedy you are seeking. \nIf we and you are unable to further resolve this dispute within sixty (60) calendar days of us receiving this notice of dispute, then any such dispute will be referred to and finally resolved by you and us through an arbitration administered by the Swiss Chambers’ Arbitration Institution in accordance with the Swiss Rules of International Arbitration for the time being in force, which rules are deemed to be incorporated herein by reference. The arbitral decision may be enforced in any court. The arbitration will be held in Zug, Switzerland, and may be conducted via video conference virtual/online methods if possible. The tribunal will consist of one arbitrator, and all proceedings as well as communications between the parties will be kept confidential. The language of the arbitration will be in English. Payment of all relevant fees in respect of the arbitration, including filing, administration and arbitrator fees will be in accordance with the Swiss Rules of International Arbitration. \nRegardless of any applicable statute of limitations, you must bring any claims within one year after the claim arose or the time when you should have reasonably known about the claim. You also waive the right to participate in a class action lawsuit or a classwide arbitration against us. \nAbout these Website Terms of Use §\nThese Website Terms of Use cover the entire agreement between you and us regarding the Website and supersede all prior and contemporaneous understandings, agreements, representations and warranties, both written and oral, with respect to the Website. \nThe captions and headings identifying sections and subsections of these Website Terms of Use are for reference only and do not define, modify, expand, limit, or affect the interpretation of any provisions of these Website Terms of Use. \nIf any part of these Website Terms of Use is held invalid or unenforceable, that part will be severable from these Website Terms of Use, and the remaining portions will remain in full force and effect. If we fail to enforce any of these Website Terms of Use, that does not mean that we have waived our right to enforce them."},"vac/acz/index":{"title":"Applied Cryptography and Zero-knowledge Service Unit","links":["vac/acz/rlnp2p/waku/production-readiness","vac/acz/rlnp2p/waku/rln-membership-management","vac/acz/rlnp2p/waku/rln-relay-enhancements","vac/acz/rlnp2p/waku/rln-relay-enhancements_02","vac/acz/rlnp2p/waku/rln-relay-erc20","vac/acz/rlnp2p/waku/rlnv2-relay-integration","vac/acz/rlnp2p/waku/rln-multi-epoch-constraints","vac/acz/rlnp2p/vac/rln-doc-and-outreach","vac/acz/zerokit/vac/zerokit-v0-4","vac/acz/zerokit/vac/zerokit-v0-5","vac/acz/zerokit/vac/maintenance","vac/acz/secure-channels/waku/ethereum-chat"],"tags":["acz","vac"],"content":"vac:acz: §\n\nrlnp2p:waku: §\n\n production-readiness\n rln-membership-management\n rln-relay-enhancements\nrln-relay-enhancements_02\nrln-relay-erc20\nrlnv2-relay-integration\nrln-multi-epoch-constraints\n\nrlnp2p:vac: §\n\nrln-doc-and-outreach\n\nzerokit:vac: §\n\n zerokit-v0.4\nzerokit-v0.5\nmaintenance\n\nsecure-channels:waku: §\n\nethereum-chat\n"},"vac/acz/rlnp2p/vac/rln-doc-and-outreach":{"title":"RLN Doc and Outreach","links":[],"tags":[],"content":"vac:acz:rlnp2p:vac:rln-doc-and-outreach §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n RLN doc and outreach: done, 2023-01-20, 2023-07-31\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\n\nWaku doc: How can a user setup Waku + RLN?\n\neven though Waku RLN does not support slashing yet, we can see RLN as that provides an additional datapoint regarding message validity\n\n\ndoc explaining how the components of RLN (zerokit, contract, and a project using it, e.g. Waku, work together)\n\nthis can be in notion at first\n\n\nrlog post based on the two points above\ntalk @ progcrypto and logos event in Istanbul (co-located with devconnect)\n\nJustification §\nDeliverables §"},"vac/acz/rlnp2p/waku/production-readiness":{"title":"RLNP2P Waku Pruduction Readiness Details","links":[],"tags":[],"content":"vac:acz:rlnp2p::waku:production-readiness §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tProduction Readiness :done, 2023-01-20, 2023-07-31\n\n\ndue: 2023/07/31\nstatus: 100%\n\nDescription §\nmembership management is out of scope for this milestone\nDeliverables §\nTBD"},"vac/acz/rlnp2p/waku/rln-membership-management":{"title":"Waku RLN Membership Management Details","links":["waku/"],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-membership-management §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN Membership Management :done, 2023-01-20, 2023-09-30\n\n\ndue: 2023/09/30\nstatus: 100%\n\nDescription §\nEnhancing the first simple CC membership list\nRisks §\n\ndepends on input from Waku\n\nInfo §\n2023/09/04 - 2023/09/11 §\n\nadded documentation for rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1993\n\n2023/08/28 - 2023/09/04 §\n\nfixed makefile target for rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1960\nlog the membership index out upon registration in the rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1963\n\n2023/08/21 - 2023/08/28 §\n\nDemo of rln_keystore_generator: https://github.com/waku-org/nwaku/pull/1956\nWrote a tool rln_keystore_generator\n\nhttps://github.com/waku-org/nwaku/pull/1925\nhttps://github.com/waku-org/nwaku/pull/1928\nhttps://github.com/waku-org/nwaku/pull/1931\n\n\n"},"vac/acz/rlnp2p/waku/rln-multi-epoch-constraints":{"title":"Multi Epoch Constraints","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:multi-epoch-constraints §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Multi epoch constraints: 2023-09-15, 2023-11-15\n\n\nstatus: 0%\nCC: Ramses\n\nDescription §\nCurrently, RLN v1 allows for a fixed message rate of 1/msg per epoch while RLN v2 allows for n msgs/epoch.\nThe goal of this milestone is designing the key derivation and related cryptographic components for allowing several n msgs/epoch constraints.\nFor example: 24 msg / day && 1 msg/10 seconds.\n\nthe nullifier defined in the RLN RFC has to be adapted accordingly.\n\nJustification §\nDeliverables §"},"vac/acz/rlnp2p/waku/rln-relay-enhancements":{"title":"Waku RLN-RELAY Enhancements Details","links":[],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-relay-enhancements §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN-RELAY enhancements :, 2023-06-01, 2023-09-30\n\n\ndue: 2023/09/30\nstatus: 100%\n\nDescription §\n\nsimple membership management setup (fixed CC list)\ninstruction on how to register to the membership set / setup up (for Waku CCs)\n\nGoal §\nRun RLN relay on the Waku production fleet. Waku CCs can use it\nInfo §\n2023/09/04 - 2023/09/11 §\n\nif only one key exists in the keystore, use it - https://github.com/waku-org/nwaku/pull/1984\nfix log levels for some logs - https://github.com/waku-org/nwaku/pull/1986\nupdated documentation for rln-relay - https://github.com/waku-org/nwaku/pull/1993\nclean nullifier table every MaxEpochGap - https://github.com/waku-org/nwaku/pull/1994\ncreated rln_db_inspector tool, allows inspection into merkle tree structure - https://github.com/waku-org/nwaku/pull/1999, https://github.com/waku-org/nwaku/pull/2012\nfixed missing memberships between history sync and new memberships sync with @alrevuelta - https://github.com/waku-org/nwaku/pull/2015\nremove rln from waku’s experimental features - https://github.com/waku-org/nwaku/pull/2001\nfix metric calculation for registered members - https://github.com/waku-org/nwaku/pull/2018\nuups proxy for waku-rln-registry - https://github.com/waku-org/waku-rln-contract/pull/9\n\n2023/08/28 - 2023/09/04 §\n\nrln was enabled by default in the Makefile - fixed - https://github.com/waku-org/nwaku/pull/1964\nordered pubsub validator execution - https://github.com/waku-org/nwaku/pull/1966\nfixed deserialization of valid merkle roots - https://github.com/waku-org/nwaku/pull/1973\nconfirm that the fetched credential from the keystore is registered to the membership set - https://github.com/waku-org/nwaku/pull/1980\nfixed makefile target for zerokit’s librln.a - https://github.com/waku-org/nwaku/pull/1981\nconverted zero-based indexing to 1-based indexing on vacp2p/rln-contract - https://github.com/vacp2p/rln-contract/pull/28\ndownstreamed zero-based indexing to waku-org/waku-rln-contract - https://github.com/waku-org/waku-rln-contract/pull/8 -\ndeployed new version of the registry contract on sepolia - 0xc04937d502E0ae671cedFC2A0BCD6692055520f3\n\n2023/08/21 - 2023/08/28 §\n\ntree metadata should include chainId and contractAddress - https://github.com/waku-org/nwaku/pull/1932\nset flush_interval appropriately -https://github.com/waku-org/nwaku/pull/1933\nintegrate new WakuRlnRegistry contract - https://github.com/waku-org/nwaku/pull/1943\nbump zerokit to v0.3.2\nhttps://github.com/waku-org/nwaku/pull/1951\ntree metadata should include window of roots - https://github.com/waku-org/nwaku/pull/1953\nsync tree state from contract deployed block number - https://github.com/waku-org/nwaku/pull/1955\noptimization to waku_keystore - https://github.com/waku-org/nwaku/pull/1956\nfixed a forceProgression bug in the WakuRlnRegistry contract - https://github.com/waku-org/waku-rln-contract/pull/6\n\n2023/08/14 - 2023/08/21 §\n\nrpc handler for waku rln relay - https://github.com/waku-org/nwaku/pull/1852\nfixed ganache’s change in method to manage subprocesses, fixed timeouts related to it - https://github.com/waku-org/nwaku/pull/1913\nshould error out on rln-relay mount failure - https://github.com/waku-org/nwaku/pull/1904\nfixed invalid start index being used in rln-relay - https://github.com/waku-org/nwaku/pull/1915\nconstrain the values that can be used as idCommitments in the rln-contract - https://github.com/vacp2p/rln-contract/pull/26\nassist with waku-simulator testing\nremove registration capabilities from nwaku, it should be done out of band - https://github.com/waku-org/nwaku/pull/1916\nadd deployedBlockNumber to the rln-contract for ease of fetching events from the client - https://github.com/vacp2p/rln-contract/pull/27\n\n2023/08/07 - 2023/08/14 §\n\nCreated tracking issue to manage status of this milestone - https://github.com/waku-org/nwaku/issues/1906\n\n2023/07/31 - 2023/08/07 §\n\nWaku RLN contract registry\nMark duplicated messages as spam\nUse waku-org/waku-rln-contract as a submodule in nwaku\n\nDeliverables §\n\nhttps://github.com/waku-org/nwaku/issues/1906\n"},"vac/acz/rlnp2p/waku/rln-relay-enhancements_02":{"title":"Waku RLN-RELAY Enhancements 02","links":["vac/acz/rlnp2p/waku/rln-relay-enhancements"],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-relay-enhancements §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN-RELAY enhancements :, 2023-09-01, 2023-11-31\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\n\ncontinuation of rln-relay-enhancements\ncomprises further enhancements of RLN relay, requested by the Waku team\n\nJustification §\nRisks §\nDeliverables §"},"vac/acz/rlnp2p/waku/rln-relay-erc20":{"title":"RLN relay ERC20","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:rln-relay-erc20 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Production Readiness: , ,\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\n\nfuture work\n\nJustification §\nDeliverables §"},"vac/acz/rlnp2p/waku/rlnv2-relay-integration":{"title":"RLN v2 Waku Relay Integration","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:rlnv2-relay-integration §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n RLN v2 relay integration: 2023-11-01, 2024-02-29\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\n\nalso involves\n\nTKE\nimplemenations in various Waku versions\n\n\n\nJustification §\nDeliverables §"},"vac/acz/secure-channels/waku/ethereum-chat":{"title":"Ethereum Chat","links":[],"tags":[],"content":"vac:acz:secure-channels:waku:ethereum-chat §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Ethereum Chat: 2023-09-12, 2023-11-30\n\n\nstatus: 0%\nCC: Ramses\n\nDescription §\nThe goal of this milestone is having\n\n\nusing the noise framework\n\n\nEthereum Wallet address used to derive authentication key for noise\n\n\nDesign an Ethereum address-based 1:1 chat\n\nshould be transport agnostic\ntoy eth chat: https://rfc.vac.dev/spec/20/\n\nthis milestone requires forward secrecy (see limitations section of the toy eth chat RFC)\n\n\nconsider using https://eips.ethereum.org/EIPS/eip-5564\n\n\n\nNaive Groupchat functionality (using n 1:1 chat channels)\n\n\ninvolve metamask here (metamask im team)\n\n\na follow up milestone will cover running Ethereum chat on top of Waku\n\n\nfollow up goal: develop this into an EIP\n\n\nJustification §\nDeliverables §\n\nspecification (RFC) of a secure Ethereum-based chat protocol\n"},"vac/acz/zerokit/vac/maintenance":{"title":"maintenance","links":[],"tags":[],"content":""},"vac/acz/zerokit/vac/zerokit-v0-4":{"title":"Zerokit v0.4 Release Details","links":[],"tags":[],"content":"vac:acz:zerokit::vac:zerokit-v0.4 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection zerokit\n\t\tv0.4 Release :done, 2023-01-20, 2023-09-07\n\n\ndue: 2023/09/07\nstatus: 100%\n\nDescription §\n\nRelease Planning - Github Issue #197\n\nDeliverables §\n\nhttps://github.com/vacp2p/zerokit/releases/tag/v0.4.0\n\nInfo §\n2023/08/14 - 2023/08/21 §\n\nsubstitute id_commitments for rate_commitments and update tests in rln-v2 - https://github.com/vacp2p/zerokit/pull/205\nrln-v2 working branch - https://github.com/vacp2p/zerokit/pull/204\n\n2023/08/07 - 2023/08/14 §\n\nSerde api’s updated - https://github.com/vacp2p/zerokit/pull/202\n\n2023/07/31 - 2023/08/07 §\n\nzerokit v0.4.0 release planning - https://github.com/vacp2p/zerokit/issues/197\n"},"vac/acz/zerokit/vac/zerokit-v0-5":{"title":"Zerokit v0.5 Release","links":[],"tags":[],"content":"vac:acz:zerokit::vac:zerokit-v0.5 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n\tdateFormat YYYY-MM-DD\n\tsection zerokit\n\t\tv0.5 Release: 2023-10-01, 2024-02-29\n\n\nstatus: 5%\nCC: Aaryamann\n\nDescription §\n\n\nRelease Planning issue:\n\n\nmain focus: RLN performance improvements\n\nexplore using kzg proofs\n\n\n\nDeliverables §\nInfo §\n\nWe have a benchmarking suite done\n"},"vac/dr/consensus/nomos/blockchain-security-in-crypto-economic-models":{"title":"Blockchain Security in Crypto-economic Models","links":[],"tags":[],"content":"vac:dr:consensus:vac:blockchain-security-in-crypto-economic-models §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Blockchain Security in Crypto-economic Models: 2023-11-01, 2024-02-29\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nThis research will provide a comprehensive security analysis of Carnot under the Crypto Economic Model.\nThis is a new security model for distributed consensus algorithms in which economic attacks on the protocol will be considered.\nJustification §\nThe combination of PoS and distributed consensus, necessitates a new comprehensive security model for blockchain ecosystem.\nRisks §\nThis is a new research direction.\nDeliverables §\n\nconference paper\n"},"vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation":{"title":"Carnot 2/3 Vote aggregation","links":["roadmap/vac/dst/dr-support/vac/carnot-2-3rds-executable-spec"],"tags":[],"content":"vac:dr:nomos:nomos:carnot-vote-2-3rds-vote-aggregation §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot 2/3 Vote Aggregation: 2023-08-01, 2023-10-15\n\n\nstatus: 20%\nCC: Moh\n\nDescription §\nThis research will use the Carnot flexible design to make it collect more than 2/3rd of cryptographic proof of votes cast for a block.\n\n\nwrite a research log post\n\n\ndesciption of the solution\n\n\nsupport by the DST team: carnot-2rds-executable-spec\n\n\nRisks §\nMight slightly increase the protocol overhead. But we make sure this overhead is minimal.\nJustification §\nDeliverables §\n\n Presentation slides (logos research)\nPseudocode (potentially paper in a future milestone)\nnotion doc describing the solution\nresearch log post\npython code, support by the DST team carnot-2rds-executable-spec\nRFC on rfc.vac.dev containing executable spec\n\nNote: Need to be discussed: The Pseudocode can be completed earlier so that devs can began implementation, whereas the paper can be completed later."},"vac/dr/consensus/nomos/carnot-bribary-article":{"title":"Carnot Bribary Article","links":[],"tags":[],"content":"vac:dr:consensus:nomos:carnot-bribary-article §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot Bribary Article: 2023-08-01, 2023-08-31\n\n\nstatus: ?%\nCC:\n\nDescription §\nThe article describes how multi-dimensional bribery attacks cannot be addressed at the consensus layer alone.\nA proper game theoretical, economic analysis also needs to be done. The solution to this problem will also touch on several aspects\nincluding the economy, distributed systems, and cryptography.\nThis Milestone also comprises a presentation:\nThis presentation slide describes how multi-dimensional bribery attacks cannot\nbe addressed at the consensus layer alone. By combining PoS with the\ndistributed consensus a new dimension is introduced into the ecosystem. Now the\nsecurity of the protocol should also be considered against economic attacks.\nThe presentation provides an example based on the Crypto Economic security\nmodel of how any PoS consensus protocol can fail against a bribing attack. The\npresentation emphasizes that a proper game theoretical, and economic analysis\nalso needs to be done. It also suggests a solution for addressing bribing\nattacks in Carnot consensus.\nRisks §\nThis problem has not been properly addressed for PoS protocols.\nJustification §\nDeliverables §\n\n\nA report on how bribery attacks can be addressed in PoS. This will ultimately give a new research direction.\n\n\npresentation slides\n\n\ncurrent status\n\n"},"vac/dr/consensus/nomos/carnot-paper":{"title":"Carnot Paper","links":[],"tags":[],"content":"vac:dr:consensus:nomos:carnot-paper §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot Paper: done, 2023-01-20, 2023-09-30\n\n\nstatus: 100%\nCC: Moh\n\nDescription §\nFirst version of a scientific carnot paper.\nPublish on arxiv.\nJustification §\nDeliverables §\n\nhttps://arxiv.org/pdf/2308.16016.pdf\n"},"vac/dr/consensus/nomos/carnot-paper_02":{"title":"Carnot Paper 02","links":[],"tags":[],"content":"vac:dr:consensus:nomos:carnot-paper_02 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot Paper: 2023-09-01, 2024\n\n\nstatus: 10%\nCC: Moh\n\nDescription §\n\n\ncomplete experimental results\n\n\npublish the paper at a scientific conference or journal\n\n\npresent the paper at the conference\n\n\nthe goal is to submit before end of 2023\n\n\nRisks §\n\nWe need to find a fitting conference and the respective deadlines might not align.\nreview process takes a long time\n\n(No fixed deadline because of these risks.)\nJustification §\nDeliverables §"},"vac/dr/consensus/nomos/detecting-reporting-attacks-carnot":{"title":"Detecting Reporting Attacks Carnot","links":[],"tags":[],"content":"vac:dr:consensus:nomos:detecting-reporting-attacks-carnot §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Detecting Reporting Attacks Carnot: 1970-01-01, 1970-01-02\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nThis research work will describe the mechanism of how various attacks can be detected, reported, and slashed in the consensus.\nJustification §\nDeliverables §\n\nalgorithm\npseudocode\nspec\nrlog post\n"},"vac/dr/consensus/nomos/inter-chain-protocol":{"title":"Inter Chain Protocol","links":[],"tags":[],"content":"vac:dr:consensus:nomos:inter-chain-protocol §\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nExploring the interplay between the main chain and execution zones or chains is a pivotal aspect of our research.\nOur inquiry delves into how these zones are initiated from the main chain, ensuring their security and data availability.\nAdditionally, we address the optimization of interaction among independent chains, facilitating efficient cross-chain communication and collaboration.\nJustification §\nDeliverables §\n\nAlgorithm\nspec\n"},"vac/dr/consensus/nomos/multi-leader-and-multi-overlay-carnot":{"title":"Multi-Leader and Multi-Overlay Carnot","links":[],"tags":[],"content":"vac:dr:consensus:nomos:multi-leader-and-multi-overlay-carnot §\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nIn pursuit of heightened resilience and performance optimization, our research extends to multi-leader and multi-overlay Carnot configurations.\nThis direction seeks to bolster the protocol’s resistance against Denial of Service (DoS) and bribery attacks.\nBy introducing multiple leadership nodes and overlay structures, we envision a protocol that thrives in adversarial environments while maintaining exceptional performance standards.\nAs we navigate this deep research trajectory, our collective efforts contribute to the advancement of blockchain technology, ushering in a new era of consensus, privacy, and scalability.\nHas to adhere to Nomos architecture (specific specifications)\n\nNomos Whitepaper\nhas to adhere to privacy requirements\n\nJustification §\nDeliverables §\n\nAlgorithm\nspec\n"},"vac/dr/consensus/nomos/stake-privacy-timing-attacks":{"title":"Network Privacy Stack - Stakeholder Privacy","links":[],"tags":[],"content":"vac:dr:consesus:nomos:stake-privacy-timing-attacks §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Stake Privacy - Timing Attacks:\n\n\nstatus: 0%\nCC: Moh\n\nDescription §\nThis milestone comprises component 3 of the Nomos network privacy stack\nin the context of consensus privacy:\nThe main goal of this work is finding in-protocol (carnot) mechanisms to solve the problem of timing attacks.\nUpper layer protections of the network from the sender: Simplest solution to prevent attacks to private PoS: minimum age of transaction for inclusion.\nCertain types of timing attacks and network observation to identify high stake participants are already being worked on at the network level.\nHowever, this problem should be considered at the PoS/consesus layer as well.\nmore info §\n\npaper: On the Anonymity Guarantees of Anonymous Proof-of-Stake Protocols\n\nFrom the abstract:\n[...] focus on anonymizing the\nmessages of the blockchain protocol, but suggest that potential identity leaks from the networklayer can be removed as well by employing anonymous broadcast channels.\nIn this work we show that this intuition is flawed.\n\nGenerally, our endeavor in stake privacy research centers on preserving the confidentiality of validator stakes.\nBy leveraging cryptographic techniques and innovative approaches, we aim to enhance the privacy and security of staking operations within the Carnot ecosystem.\nOlder docs:\n\nHash-based Node Id encryption Hash-based-Node-Id-encryption-7bfb11941a6840c49bfe065f535877c9?pvs=24\nCarnot PoS Discussion notion.so/Carnot-PoS-Discussion-f2ef371102f6433da81fb1b1b9213c2b?pvs=24\n\nPotential future solutions (outside the scope of this mile stone) comprise: proof of mixing + modifications to the base mixnet design. This seems like a difficult path, for long-term research if feasible.\nJustification §\nThis is and important step towards achieving the Nomos privacy requirements.\nDeliverables §\n\nspecification\n"},"vac/dr/g/nomos/reviews":{"title":"Reviews","links":[],"tags":[],"content":"vac:dr:g:nomos:reviews §\n\n\nstatus: ongoing\nCC: team\n\nDescription §\nJustification §\nDeliverables §"},"vac/dr/gsub-scaling/vac/gossipsub-improvements-paper":{"title":"Gossipsub Improvements Paper","links":[],"tags":[],"content":"vac:dr:gsub-scaling:vac:gossipsub-improvements-paper §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Gossipsub Improvements paper: 2023-06-01, 2023-10-31\n\n\nstatus: 70%\nCC: Farooq\n\nDescription §\nbackground + first results + potential improvements\n\n\ncomprehensive current/related work study on gossipsub scaling (including relevant work outside of gossipsub, in the broader area of unstructured P2P networks in general)\ncomplete technical report on gossip scaling / gossipsub improvements (containing, but not limited to, our previous research)\nresearch log post (vac.dev) based on the techreport\ntalk @ Logos research call\nscientific paper ready for publication\n\nJustification §\nDeliverables §"},"vac/dr/gsub-scaling/vac/gossipsub-simulation":{"title":"Gossipsub Simulation","links":[],"tags":[],"content":"vac:dr:gsub-scaling:vac:gossipsub-simulation §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Gossipsub Simulation: 2023-06-31, 2023-09-30\n\n\nstatus: 20%\nCC: Farooq\n\nDescription §\n\nsimple gossipsub node (in nim) for DST/Wakurtosis simulations\nPoC shadow simulation\n\nJustification §\nDeliverables §"},"vac/dr/gsub-scaling/vac/unstructured-p2p-improvements-survey":{"title":"Unstructured P2P Improvements Survey","links":[],"tags":[],"content":"vac:dr:gsub-scaling:vac:unstructured-p2p-improvements-survey §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Unstructured P2P Improvements Survey: 2023-08-15, 2023-12-31\n\n\nstatus: 20%\nCC: Farooq\n\nDescription §\n\nsurvey techreport\nsurvey scientific paper if there is enough to justify a paper\n\nJustification §\nDeliverables §"},"vac/dr/index":{"title":"Deep Research Service Unit","links":["vac/dr/valpriv/vac/tor-push-poc","vac/dr/valpriv/vac/tor-push-rel-work","vac/dr/valpriv/vac/tor-push-paper","vac/dr/valpriv/vac/tor-push-rln","vac/dr/valpriv/vac/priv-validator-network","vac/dr/valpriv/vac/mix-net-solution","vac/dr/valpriv/nomos/validator-privacy","vac/dr/gsub-scaling/vac/gossipsub-simulation","vac/dr/gsub-scaling/vac/gossipsub-improvements-paper","vac/dr/gsub-scaling/vac/unstructured-p2p-improvements-survey","vac/dr/consensus/nomos/carnot-paper","vac/dr/consensus/nomos/carnot-paper_02","vac/dr/consensus/nomos/carnot-bribary-article","vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation","vac/dr/consensus/nomos/blockchain-security-in-crypto-economic-models","vac/dr/consensus/nomos/detecting-reporting-attacks-carnot","vac/dr/consensus/nomos/stake-privacy-timing-attacks","vac/dr/consensus/nomos/inter-chain-protocol","vac/dr/consensus/nomos/multi-leader-and-multi-overlay-carnot","vac/dr/zk/codex/storage-proofs-open-problems-review","vac/dr/g/nomos/reviews"],"tags":["dr","vac"],"content":"vac:dr:valpriv:vac: §\n\ntor-push-poc\ntor-push-rel-work\ntor-push-paper\ntor-push-rln\npriv-validator-network\nmix-net-solution\n\nvac:dr:valpriv:nomos: §\n\nvalidator-privacy\n\nvac:dr:gsub-scaling:vac: §\n\ngossipsub-simulation\ngossipsub-improvements-paper\nunstructured-p2p-improvements-survey\n\nvac:dr:consensus:nomos: §\n\n carnot-paper\ncarnot-paper_02\ncarnot-bribary-article\ncarnot-2-3rds-vote-aggregation\nblockchain-security-in-crypto-economic-models\ndetecting-reporting-attacks-carnot\nstake-privacy-timing-attacks\ninter-chain-protocol\nmulti-leader-and-multi-overlay-carnot\n\nvac:dr:zk:codex: §\n\nstorage-proofs-open-problems-review\n\nvac:dr::nomos: §\n\nreviews\n"},"vac/dr/valpriv/nomos/validator-privacy":{"title":"validator-privacy","links":[],"tags":[],"content":""},"vac/dr/valpriv/vac/mix-net-solution":{"title":"mix-net-solution","links":[],"tags":[],"content":""},"vac/dr/valpriv/vac/priv-validator-network":{"title":"priv-validator-network","links":[],"tags":[],"content":""},"vac/dr/valpriv/vac/tor-push-paper":{"title":"Tor Push Paper","links":[],"tags":[],"content":"vac:dr:valpriv:vac:tor-push-paper §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Tor Push Paper: 2023-08-01, 2023-11-30\n\n\nstatus: 30%\nCC: Umar\n\nDescription §\nComprises:\n\nthorough anonymity/sec analysis of Tor push for Validator privacy\nthorough latency analysis of Tor push\npaper (for workshop) on introducing and analysing Tor-push\n\nJustification §\nDeliverables §"},"vac/dr/valpriv/vac/tor-push-poc":{"title":"Tor Push PoC","links":["vac/dr/valpriv/vac/tor-push-paper"],"tags":[],"content":"vac:rc:valpriv:vac:tor-push-poc §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Tor Push PoC: 2023-06-01, 2023-09-15\n\n\nstatus: 80%\nCC: Umar\n\nDescription §\n\n first PoC of Tor push in Nimbus (testnet Goerli) https://github.com/vacp2p/nimbus-eth2-experimental/issues/1\n\nfirst latency measurements (comprehensive analysis in next milestone)\n\n\nresearch log post on Tor push / Nimbus PoC incl first latency measurements\nadd epoch support as described in the RFC\nupdate/adjust Tor push spec\ntalk @ Logos research call\nrefine PoC (should fully cover the RFC)\nthorough latency measurements fortor-push-paper\n\nInfo §\n\nThe epochs\n\nJustification §\nDeliverables §\n\n[WIP] https://github.com/vacp2p/nimbus-eth2-experimental/pull/3\n"},"vac/dr/valpriv/vac/tor-push-rel-work":{"title":"Tor Push Related Work","links":[],"tags":[],"content":"vac:dr:valpriv:vac:tor-push-rel-work §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Tor Push Related Work: done, 2023-06-01, 2023-09-15\n\n\nstatus: 100%\nCC: Umar\n\nDescription §\nBackground and motivation here.\n\ncomprehensive current/related work study on Validator Privacy\n\nfocus on network layer but also including: network vs consesus layer privacy (SSLE), as well as combinations\n\n\n\nJustification §\nDeliverables §"},"vac/dr/valpriv/vac/tor-push-rln":{"title":"tor-push-rln","links":[],"tags":[],"content":""},"vac/dr/zk/codex/storage-proofs-open-problems-review":{"title":"Storage Proofs: Open Problems Review","links":[],"tags":[],"content":"vac:dr:zk:codex:open-problems-review §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Open Problems Review: 2023-09-20, 2023-11-30\n\n\nstatus: 0%\nCC: Marvin\n\nDescription §\n\nhttps://github.com/codex-storage/zk-research-artifacts/blob/master/storage_proofs/storage_proof_musings.md\n\nJustification §\nDeliverables §"},"vac/dst/analysis-gsub-model/status/control-messages":{"title":"Control Messages","links":[],"tags":[],"content":"vac:dst:analysis-gsub-model:status:control-messages §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Control Messages: 2023-07-01, 2023-09-15\n\n\nstatus: 85%\nCC: Ganesh\n\nDescription §\nJustification §\nInfo §\n\ndelayed because of extending Nomos analysis milestone\n\nDeliverables §"},"vac/dst/analysis-gsub-model/vac/refactoring":{"title":"Refactoring","links":[],"tags":[],"content":"vac:dst:analysis-gsub-model:vac:refactoring §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Refactoring: 2023-08-01, 2023-09-30\n\n\nstatus: 40%\nCC: Ganesh\n\nDescription §\nJustification §\nDeliverables §"},"vac/dst/analysis-shadow/vac/shadow-basic-simulation":{"title":"Basic Shadow Simulation","links":[],"tags":[],"content":"vac:dst:analysis-shadow:vac:basic-shadow-simulation §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Basic Shadow Simulation: 2023-08-01, 2023-08-31\n\n\nstatus: 90%\nCC: Jordi\n\nDescription §\n\nsimple 10k shadow sim of the gossipsub node as a PoC.\n\nJustification §\nDeliverables §"},"vac/dst/analysis-shadow/vac/shadow-gossipsub-analysis":{"title":"Shadow Gossipsub Analysis","links":[],"tags":[],"content":"vac:dst:analysis-shadow:vac:shadow-gossipsub-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Shadow Gossipsub Analysis: 2023-09-01, 2023-10-31\n\n\nstatus: 0%\nCC: Jordi\n\nDescription §\n\ndevelop a gossipsub node with allows to set desired message rates and other properties\ntry to get to a higher node number (50k?)\nresearch log post\n\nJustification §\nDeliverables §"},"vac/dst/analysis-shadow/waku/shadow-waku-relay-analysis":{"title":"Shadow Waku Relay Analysis","links":[],"tags":[],"content":"vac:dst:analysis-shadow:waku:shadow-waku-relay-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Shadow Waku Relay Analysis: done, 2023-10-01, 2023-11-30\n\n\nstatus: 0%\nCC: Jordi\n\nDescription §\nJustification §\nDeliverables §"},"vac/dst/analysis/nomos/nomos-simulation-analysis":{"title":"Simulation Analysis","links":[],"tags":[],"content":"vac:dst:analysis:nomos:simulation-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Simulation Analysis: 2023-08-01, 2023-09-15\n\n\nstatus: 70%\nCC: Ganesh\n\nDescription §\nJustification §\nInfo §\nExtended:\n\n\ninclude signature aggregation into analysis\n\n\nwrite analysis section in Carnot paper\n\n\nnomos node\n\n\nnomos simulations\n\n\nDeliverables §"},"vac/dst/dr-support/vac/carnot-executable-spec":{"title":"Carnot 2-3rds Vote Aggregation Python Implementation","links":["vac/dr/consensus/nomos/carnot-2-3rds-vote-aggregation"],"tags":[],"content":"vac:dst:dr-support:vac:carnot-2-3rds-python-impl §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Carnot 2/3rds Python Impl: 2023-09-15, 2023-10-31\n\n\nstatus: 0%\nCC: Ganesh\n\nDescription §\n\nsupport the DR team with writing the python code for a executable specification of the Carnot 2/3rds vote aggregation\n\nsee DR milestone: carnot-2-3rds-vote-aggregation\n\n\n\nJustification §\nDeliverables §"},"vac/dst/eng-10ktool/vac/bandwidth-test":{"title":"Bandwidth Test","links":[],"tags":[],"content":"vac:dst:eng-10ktool:vac:bandwidth §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Bandwidth Test: 2023-08-01, 2023-10-31\n\n\nstatus: 80%\nCC: Alberto\n\nDescription §\nA first version of tool that allows running >10k gossipsub / waku relay nodes.\nThe tool should measure bandwidth usage per node and bundle the simulation data for analaysis.\nJustification §\nDeliverables §\n\nhttps://github.com/vacp2p/cs-codex-dist-tests\n"},"vac/dst/eng-10ktool/vac/qos":{"title":"QoS","links":[],"tags":[],"content":"vac:dst:eng-10ktool:vac:qos §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n QoS 10ktool: 2023-11-01, 2023-12-31\n\n\nstatus: 0%\nCC: Alberto\n\nDescription §\nAdd QoS parameter support to the 10k tool.\nJustification §\nDeliverables §"},"vac/dst/eng-10ktool/waku/waku-protocols":{"title":"Waku Protocols","links":[],"tags":[],"content":"vac:dst:eng-10ktool:waku:waku-protocols §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Waku Protocols: 2023-11-01, 2023-12-31\n\n\nstatus: 0%\nCC: Alberto\n\nDescription §\nSo far, we tested gossip / relay, as well as discv5.\nThis milestone comprises running further Waku protocols, namely:\n\nfilter\nlightpush\nstore\npeer exchange\n\nJustification §\nDeliverables §"},"vac/dst/eng/vac/bundle-simulation-data":{"title":"Bundle Simulation Data","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:production-readiness §\n\n\nstatus: ongoing\nCC:\n\nDescription §\nThe Vac DST engineering team runs simulations, bundles the resulting data, and delivers.\nJustification §\nDeliverables §"},"vac/dst/index":{"title":"Distributed Systems Testing Service Unit","links":["vac/dst/wakurtosis/waku/techreport","vac/dst/wakurtosis/waku/techreport_02","vac/dst/wakurtosis/waku/techreport_03","vac/dst/wakurtosis/waku/features","vac/dst/wakurtosis/waku/gossipsub-topology-analysis","vac/dst/wakurtosis/nomos/ci-integration","vac/dst/wakurtosis/vac/rlog","vac/dst/wakurtosis/vac/retrospective-rlog","vac/dst/wakurtosis/vac/maintenance","vac/dst/analysis/nomos/nomos-simulation-analysis","vac/dst/analysis-gsub-model/vac/refactoring","vac/dst/analysis-gsub-model/status/control-messages","vac/dst/analysis-shadow/vac/shadow-basic-simulation","vac/dst/analysis-shadow/vac/shadow-gossipsub-analysis","vac/dst/analysis-shadow/waku/shadow-waku-relay-analysis","roadmap/vac/dst/dr-support/vac/carnot-2-3rds-executable-spec","vac/dst/eng/vac/bundle-simulation-data","vac/dst/eng-10ktool/vac/bandwidth-test","vac/dst/eng-10ktool/vac/qos","vac/dst/eng-10ktool/waku/waku-protocols","vac/dst/software-testing/waku/test-plans","vac/dst/software-testing/waku/test-automation-js-waku","vac/dst/software-testing/waku/test-automation-nwaku","vac/dst/software-testing/waku/test-automation-go-waku","vac/dst/software-testing/waku/interop-testing"],"tags":["dst","vac"],"content":"vac:dst: §\n\nwakurtosis:waku: §\n\n techreport\n techreport_02\ntechreport_03\n wakurtosis:features\ngossipsub-topology-analysis\n\nwakurtosis:nomos: §\n\n ci-integration\n\nwakurtosis:vac: §\n\nrlog\nretrospective-rlog\n maintenance\n\nanalysis:nomos §\n\nsimulation-analysis\n\nanalysis-gsub-model:vac §\n\nrefactoring\n\nanalysis-gsub-model:status: §\n\ncontrol-messages\n\nanalysis-shadow:vac: §\n\nshadow-basic-simulation\nshadow-gossipsub-analysis\n\nanalysis-shadow:waku: §\n\nshadow-waku-relay-analysis\n\ndr-support: §\n\ncarnot-2-3rds-executable-spec\n\neng:vac: §\n\nbundle-simulation-data\n\neng-10ktool: §\n\nbandwidth-test\nQoS\nwaku-protocols\n\nsoftware-testing:waku: §\n\ntest-plans\ntest-automation-js-waku\ntest-automation-nwaku\ntest-automation-go-waku\ninterop-testing\n"},"vac/dst/software-testing/waku/interop-testing":{"title":"Interop Testing","links":[],"tags":[],"content":"vac:dst:software-testing:waku:interop-testing §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Interop Testing: 2023-09-01, 2024-02-29\n\n\nstatus: 0%\nCC: Florin, Alex, Roman\n\nDescription §\n\nfilter nwaku service node + js waku client node (t, Florin)\nnwaku <> go-waku interop (t, Alex)\n\nJustification §\nDeliverables §"},"vac/dst/software-testing/waku/test-automation-go-waku":{"title":"Test Automation go-waku","links":[],"tags":[],"content":"vac:dst:software-testing:waku:test-automation-go-waku §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Test Automation go-waku: 2023-10-01, 2024-02-29\n\n\nstatus: 0%\nCC: Roman\n\nDescription §\n\nfilter (t) ← first group of tests added in PR to JS waku\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\n\nJustification §\nDeliverables §"},"vac/dst/software-testing/waku/test-automation-js-waku":{"title":"Test Automation js-waku","links":[],"tags":[],"content":"vac:dst:software-testing:waku:test-automation-js-waku §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Test Automation js-waku: 2023-09-15, 2024-02-29\n\n\nstatus: 10%\nCC: Florin\n\nDescription §\n\nfilter (t) ← first group of tests added in PR to JS waku\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\nInteroperability (t)\n\nAdditional requirements:\nIt should be possible to choose the nwaku version the js waku test use (done via github actions inputs)\nJustification §\nDeliverables §"},"vac/dst/software-testing/waku/test-automation-nwaku":{"title":"Test Automation nwaku","links":[],"tags":[],"content":"vac:dst:software-testing:waku:test-automation-nwaku §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Test Automation nwaku: 2023-09-15, 2024-02-29\n\n\nstatus: 0%\nCC: Alex\n\nDescription §\nJustification §\nDeliverables §"},"vac/dst/software-testing/waku/test-plans":{"title":"Test Plans","links":[],"tags":[],"content":"vac:dst:software-testing:waku:test-plans §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Test Plans: 2023-09-01, 2024-02-29\n\n\nstatus: 15%\nCC: Florin\n\nDescription §\nunit + integration test\n(contains actually understanding the protocols, critically engage with the protocols)\n(instruct the engineer)\n\nfilter (t)\nlightpush (t)\nstore (t)\nrelay ()\npeer exchange\ndiscv5\npeer & connection management\ninteroperability (t, starting)\nsimulation plans\n\nJustification §\nDeliverables §\n\ntest plans\n"},"vac/dst/wakurtosis/nomos/ci-integration":{"title":"CI Integration","links":[],"tags":[],"content":"vac:dst:wakurtosis:nomos:ci-integration §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n CI Integration: done, 2023-07-01, 2023-07-31\n\n\nstatus: 100%\nCC: Alberto\n\nDescription §\nAdd Nomos integration to wakurtosis so Nomos can be also used in it.\nJustification §\nNomos is under constant developmet.\nWith this integration, each time a change is done, a continuous integration test is done, making sure the consensus protocol works properly with a few nodes.\nInfo §\nWe stopped working on a follow up milestone since we deprecated Wakurtosis in favour of our new 10ktool.\nDeliverables §\n\nfirst version of Nomos CI integration (https://github.com/vacp2p/wakurtosis/pull/141)\n"},"vac/dst/wakurtosis/vac/maintenance":{"title":"Wakurtosis Maintenance","links":[],"tags":[],"content":"vac:dst:wakurtosis:vac:maintenance §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Wakurtosis Maintenance: done, 2023-01-01, 2023-08-31\n\n\nstatus: 100%\nCC: Alberto\n\nDescription §\nKeep up to date the tool if there are crashing changes in the services that are being used in it (Waku, Nomos…)\nJustification §\nServices being used are in constant change, thus it can lead wakurtosis to break.\nInfo §\n\nWakurtosis is deprecated. We do not actively maintain it anymore.\n\nDeliverables §"},"vac/dst/wakurtosis/vac/retrospective-rlog":{"title":"Rlog: Wakurtosis Retrospective","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:retrospective-rlog §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Wakurtosis Retrospective: 2023-08-01, 2023-09-30\n\n\nstatus: 50%\nCC: Jordi\n\nDescription §\nResearch log discussing what would we have needed from Wakurtosis to make it work for us beyond our smaller solution.\nWhy did we decide to drop Kurtosis and work towards a Kubernetes-based solution now.\nJustification §\nInfo §\n\nAlberto’s Opinion\n\nDeliverables §"},"vac/dst/wakurtosis/vac/rlog":{"title":"Wakurtosis Rlog","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:rlog §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Rlog Wakurtosis: 2023-06-01, 2023-08-31\n\n\nstatus: 90%\nCC: Jordi\n\nDescription §\nResearch log post based on the Wakurtosis tech reports and addendum.\nJustification §\nInfo §\n\ndelayed because of holidays / other prios\n\nDeliverables §"},"vac/dst/wakurtosis/waku/features":{"title":"Wakurtosis Features","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:wakurtosis-features §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Wakurtosis Features: done, 2023-04-01, 2023-07-31\n\n\nstatus: 100%\nCC: Alberto\n\nDescription §\n\nFeatures requested by Waku for the simulations done in wakurtosis (e.g. discv5 support).\n\nJustification §\n\nDiscv5 is an important protocol to test. Also, we should be able to work with offline data once the simulation is finished.\n\nDeliverables §"},"vac/dst/wakurtosis/waku/gossipsub-topology-analysis":{"title":"Gossipsub Topology Analysis","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:gossipsub-topology-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Gossipsub Topology Analysis: 2023-07-01, 2023-10-15\n\n\nstatus: 60%\nCC: Ganesh\n\nDescription §\nAnalysis of the topology of a gossipsub topic mesh.\nComprises:\n\nresearch log post\nshadow integration\nLogos research call talk; also get input during the discussion regarding which areas we should go deeper into, and what would help Logos projects the most.\n\nInfo §\nExtended deadline because:\n\nadded research log post to the milestone goals + more analysis goals (e.g stability/dynamics)\nadded analysing simple gossipsub node (in addition to Waku relay)\n\nRelevant data has to be collected on the gossipsub-layer which increased the complexity of this milestone\n\n\nshadow integration\nmore focus on nomos simulation analysis + extended analysis\n\nNote: This analysis module will be usable outside of Wakurtosis, too.\nThis is the reason we continue on this milestone, even though Wakurtosis is deprecated now.\nJustification §\nDeliverables §"},"vac/dst/wakurtosis/waku/techreport":{"title":"Techreport","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:techreport §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Techreport: done, 2023-06-01, 2023-07-31\n\n\nstatus: 100%\nCC: Jordi\n\nDescription §\nJustification §\nDeliverables §\n\ntechreport\n"},"vac/dst/wakurtosis/waku/techreport_02":{"title":"Techreport_02","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:techreport_02 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Techreport_02: done, 2023-08-01, 2023-08-31\n\n\nstatus: 100%\nCC: Jordi\n\nDescription §\nRun extra batches of simulations of the non-Discv5 case with average degree K=13, and K=50.\nJustification §\nTo be able to better compare non-Discv5 and Discv5 Waku behaviours, the Waku team asked us to run new simulation batches with maximum fanout.\nCurrent simulation batches are hard to compare due to the dynamic nature of network generated by the Discv5 protocol.\nDeliverables §\n\ntechreport addendum\n"},"vac/dst/wakurtosis/waku/techreport_03":{"title":"Techreport_03","links":[],"tags":[],"content":"vac:dst:wakurtosis:waku:techreport_03 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Techreport_02: done, 2023-09-01, 2023-09-30\n\n\nstatus: 70%\nCC: Jordi\n\nDescription §\nAdd runs with 0msg/s to isolate the effect of discv5.\nJustification §\nDeliverables §\n\ntechreport addendum\n"},"vac/index":{"title":"Vac Roadmap","links":["vac/p2p/","vac/tke/","vac/dst/","vac/acz/","vac/sc/","vac/dr/","vac/rfc/","vac/nes/","tags/vac-updates"],"tags":[],"content":"vac §\nStructure §\nvac:<unit>:<tag>:<for_project>:<title>_<counter>\n\nvac indicates it is a vac milestone\nunit indicates the vac unit p2p, dst, tke, acz, sc, zkvm, dr, rfc\ntag tags a specific area / project / epic within the respective vac unit, e.g. nimlibp2p, or zerokit\nfor_project indicates which Logos project the milestone is mainly for nomos, waku, codex, nimbus, status; or vac (meaning it is internal / helping all projects as a base layer)\ntitle the title of the milestone\ncounter an optional counter; 01 is implicit; marked with a 02 onward indicates extensions of previous milestones\n\nVac Unit Roadmaps §\nR&D Service Units §\n\np2p: Peer-to-peer\ntke: Token Engineering\ndst: Distributed Systems Testing\nacz: Applied Cryptography and Zero-knowledge\nsc: Smart Contracts\n\nVac Core §\n\ndr: Deep Research\nrfc: RFC Process and Maintenance\n\nIncubator Projects §\n\nnes: Nescience\n\nWeekly Updates §\n\nweekly updates\n"},"vac/nes/index":{"title":"Nescience Incubation Project","links":["vac/nes/state-separation/vac/state-separation-doc","vac/nes/proofsystems/vac/research-existing-proofsystems","vac/nes/proofsystems/vac/benchmarks"],"tags":["zkvm","vac"],"content":"vac:nes:state-separation §\n\nstate-separation-doc\n\nvac:nes:proofsystems §\n\nresearch-existing-proofsystems\nbenchmarks\n"},"vac/nes/proofsystems/vac/benchmarks":{"title":"Benchmarks","links":[],"tags":[],"content":"vac:zkvm:proofsystems:vac:benchmarks §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Benchmarks: 2023-03-01, 2023-11-30\n\n\nstatus: 70%\nCC: team\n\nDescription §\nComprises:\n\nresearch log post\nmake benchmark repo public + README (explaining how to execute benchmarks)\nbenchmarks (recursive) for all current proof-systems (unless there is a good reason not to include one)\nscientific paper\n\nDeliverables §"},"vac/nes/proofsystems/vac/research-existing-proofsystems":{"title":"Research Existing Proofsystems","links":[],"tags":[],"content":"vac:zkvm:proofsystems:vac:research-existing-proofsystems §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Research Existing Proofsystems: 2023-01-01, 2023-11-30\n\n\nstatus: 70%\nCC: team\n\nDescription §\nDeliverables §"},"vac/nes/state-separation/vac/state-separation-doc":{"title":"State Separation Doc","links":[],"tags":[],"content":"vac:zkvm:state-separation:vac:state-separation-doc §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n State Separation: 2023-09-20, 2023-10-31\n\n\nstatus: 50%\nCC: Moudy\n\nDescription §\nDocument explaining and providing reason for Nescience state separation.\nJustification §\nDeliverables §"},"vac/p2p/index":{"title":"P2P Service Unit","links":["vac/p2p/nimlibp2p/vac/gossipsub-improvements-eip-4844","vac/p2p/nimlibp2p/vac/webrtc-transport","vac/p2p/nimlibp2p/vac/gossipsub-ddos-mitigation","vac/p2p/nimlibp2p/vac/gossipsub-stagger-send","vac/p2p/nimlibp2p/vac/maintenance","vac/p2p/nimchronos/vac/maintenance"],"tags":["p2p","vac"],"content":"vac:p2p: §\n\nnimlibp2p:vac: §\nThe P2P Service unit develops nim-libp2p.\nnim-libp2p roadmap on github: https://github.com/status-im/nim-libp2p/issues/777\n\n gossipsub-improvements-eip-4844\nwebrtc-transport\ngossipsub-ddos-mitigation\ngossipsub-stagger-send\nmaintenance\n\nnimchronos:vac: §\n\nmaintenance\n"},"vac/p2p/nimchronos/vac/maintenance":{"title":"Libchronos Maintenance","links":[],"tags":[],"content":"vac:p2p:nimchronos:vac:maintenance §\n\n\nstatus: ongoing\nCC: p2p team\n\nDescription §\n\nrepo: https://github.com/status-im/nim-chronos\n"},"vac/p2p/nimlibp2p/vac/gossipsub-ddos-mitigation":{"title":"Gossipsub DDoS Mitigation","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:gossipsub-ddos-mitigation §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n Gossipsub DDoS mitigation: 2023-07-01, 2023-10-31\n\n\nstatus: 30%\nCC: Diego\n\nDescription §\nDeliverables §"},"vac/p2p/nimlibp2p/vac/gossipsub-improvements-eip-4844":{"title":"Gossipsub Improvements EIP 4844","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:gossipsub-improvements-eip-4844 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n Gossipsub Improvements EIP 4844: done, 2023-03-01, 2023-07-31\n\n\nstatus: 100%\nCC: Tanguy\n\nDescription §\nDeliverables §"},"vac/p2p/nimlibp2p/vac/gossipsub-stagger-send":{"title":"Gossipsub Stagger Send","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:gossipsub-stagger-send §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n Gossipsub Stagger Send: 2023-06-01, 2023-10-31\n\n\nstatus: 20%\nCC: Tanguy\n\nDescription §\n\nspecification\nfirst implementation (not deployable yet, deploy version will be in a separate milestone after syncing with other implementations)\n\nDeliverables §"},"vac/p2p/nimlibp2p/vac/maintenance":{"title":"Libp2p Maintenance","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:maintenance §\n\n\nstatus: ongoing\nCC: p2p team\n\nDescription §\n\nrepo: https://github.com/status-im/nim-libp2p\n"},"vac/p2p/nimlibp2p/vac/webrtc-transport":{"title":"WebRTC Transport","links":[],"tags":[],"content":"vac:p2p:nimlibp2p:vac:webrtc-transport §\n\n%%{\n init: {\n 'theme': 'base',\n 'themeVariables': {\n 'primaryColor': '#BB2528',\n 'primaryTextColor': '#fff',\n 'primaryBorderColor': '#7C0000',\n 'lineColor': '#F8B229',\n 'secondaryColor': '#006100',\n 'tertiaryColor': '#fff',\n }\n }\n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n WebRTC Transport: 2023-04-01, 2023-07-31\n\n\nstatus: 70%\nCC: Diego\n\nDescription §\nDeliverables §"},"vac/rfc/index":{"title":"RFC Specifications Service Unit","links":["vac/rfc/rfc/status/port-status-specs","vac/rfc/rfc/nomos/carnot-specification","vac/rfc/rfc/nomos/carnot-threat-model-informational","vac/rfc/rfc/nomos/carnot-vote-2-3rds-vote-aggregation-specification","vac/rfc/rfc/nomos/inter-chain-protocol-specification","vac/rfc/rfc/nomos/multi-leader-and-multi-overlay-carnot-specification","vac/rfc/rfc/waku/waku-keystore"],"tags":["rfc","vac"],"content":"vac:rfc: §\n\nrfc:status: §\n\nport-status-specs\n\nrfc:nomos: §\n\ncarnot-specification\ncarnot-threat-model-informational\ncarnot-vote-2-3rds-vote-aggregation-specification\ninter-chain-protocol-specification\nmulti-leader-and-multi-overlay-carnot-specification\n\nrfc:waku: §\n\nwaku-keystore\n"},"vac/rfc/rfc/nomos/carnot-specification":{"title":"carnot-specification","links":[],"tags":[],"content":""},"vac/rfc/rfc/nomos/carnot-threat-model-informational":{"title":"carnot-threat-model-informational","links":[],"tags":[],"content":""},"vac/rfc/rfc/nomos/carnot-vote-2-3rds-vote-aggregation-specification":{"title":"carnot-vote-2-3rds-vote-aggregation-specification","links":["vac/rfc/rfc/nomos/carnot-vote-2-3rds-vote-aggregation-specification"],"tags":[],"content":"\npart of the DR roadmap: carnot-vote-2-3rds-vote-aggregation-specification\n"},"vac/rfc/rfc/nomos/inter-chain-protocol-specification":{"title":"inter-chain-protocol-specification","links":[],"tags":[],"content":""},"vac/rfc/rfc/nomos/multi-leader-and-multi-overlay-carnot-specification":{"title":"multi-leader-and-multi-overlay-carnot-specification","links":[],"tags":[],"content":""},"vac/rfc/rfc/status/port-status-specs":{"title":"Port Status Specs","links":[],"tags":[],"content":"vac:rfc:rfc:status:port-status-specs §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Port Status Spec: 2023-08-01, 2023-11-31\n\n\nstatus: 85%\nCC: Jimmy\n\nDescription §\nThis milestone comprises the first version of each of the specifications. Iterations on spec parlance and further enhancements will be covered in future milestones.\nThe goal we want to aim for is to take down and completely get rid of https://specs.status.im/ and its accompanying repo https://github.com/status-im/specs , so that all Status protocol specs are in the https://github.com/vacp2p/rfc repo\nTasks:\n\ndetermine which specs from https://specs.status.im/ are still relevant as protocol specs, and which old specs are no longer relevant and can be discarded\nout of the still relevant protocol specs that haven’t yet been moved over to the Vac RFC repo, update these specs as needed and move them into the Vac RFC repo\nonce done, take down https://specs.status.im/ and archive the https://github.com/vacp2p/rfc repo\n\nThe new Status website will have a ‘Specs’ section inside the ‘Developers’ part of the website, and this Specs section will pull in and render all specs from https://rfc.vac.dev/ with “STATUS-” in their title.\nNote that feature specs should NOT be added to the Vac RFC repo, only protocol specs should go here.\nRFCs to be moved / updates:\n\n(todo add RFCs we already ported)\n 6/PAYLOADS (needs significant update)\n 2/ACCOUNT\n 16/Keycard (discuss with keycard team)\n16/Push-Notifications (raw, needs update)\n10/waku-usage (outdated, check if we need that, update to Waku 2 if makes sense)\n\nout of scope? §\n\n14/Dapp browser API usage (this is not part of chat SDK, is this still a RFC? API doc would be more fitting here.)\n13/3RD-PARTY (investigate, most likely out-of-scope as it is not a protocol spec)\n8/EIPS (clarify if we have to port this → this should not be an RFC, needs constant updates, link EIPS in RFCs where needed)\n\nstable - deprecated §\n(just copy these; confirm this is OK)\n\n4/whisper-mailserver\n11/Waku-Mailserver\n\nJustification §\nDeliverables §\n\nhttps://rfc.vac.dev/spec/53/\nhttps://rfc.vac.dev/spec/54/\nhttps://rfc.vac.dev/spec/55/\nhttps://rfc.vac.dev/spec/56/\nhttps://rfc.vac.dev/spec/61/\nhttps://rfc.vac.dev/spec/63/\n"},"vac/rfc/rfc/waku/waku-keystore":{"title":"Waku Keystore","links":[],"tags":[],"content":"vac:rfc:rfc:waku:waku-keystore §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Waku Keystore RFC: 2023-11-01, 2023-11-31\n\n\nstatus: 0%\nCC: Jimmy\n\nDescription §\nWaku keystore offers a secure way to store RLN credentials,\nwhich consist of the user’s identityCredential,\nthe identityIndex (the index of their commitment in the tree),\nand the membershipContract (the contract to which this credential is registered).\nWe follow EIP-2335 closely, with some changes that are more evident from the code.\n\nnwaku implementation of keystore - https://github.com/waku-org/nwaku/tree/master/waku/waku_keystore\ngo-waku implementation of keystore - https://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/rln/keystore/keystore.go\njs-waku implementation of keystore - https://github.com/waku-org/js-rln/tree/master/src/keystore\nSample keystore - https://github.com/waku-org/js-rln/blob/891ee3474aa97e8fe5ac1b35b7ed7387f395a537/src/keystore/keystore.spec.ts#L16-L95\n\nThe RFC should describe the credential encryption format, the supported kdf’s, as well as a sample keystore.\nJustification §\nDeliverables §\n\nRFC\n"},"vac/sc/g/codex/review-codex-contracts":{"title":"Review Codex Contracts","links":[],"tags":[],"content":"vac:sc::codex:review-codex-contracts §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Review Codex Contracts: 2023-09-15, 2023-10-31\n\n\nstatus: 0%\nCC: r4bbit\n\nDescription §\nReview the codex smartcontract and give feedback: https://github.com/codex-storage/codex-contracts-eth\nMore info: https://github.com/codex-storage/nim-codex/blob/master/codex/contracts/Readme.md\nJustification §\nDeliverables §"},"vac/sc/g/status/community-contracts-ERC20":{"title":"Community Contracts ERC20","links":[],"tags":[],"content":"vac:sc:rlnp2p:status:community-contracts-erc20 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n Community Contracts ERC20: 2023-08-01, 2023-11-31\n\n\nstatus: 100%\nCC: Andrea\n\nDescription §\n\nhttps://github.com/status-im/communities-contracts/issues/13\n\nInfo §\nThis milestone comprises what the SC has to deliver towards the completion of Status No3 prio:\n3) work on the Status Community ownership tokenisation smart contracts is the third priority\nJustification §\nDeliverables §"},"vac/sc/g/status/community-contracts-ERC721":{"title":"Community Contracts ERC721","links":[],"tags":[],"content":"vac:sc::status:community-contracts-erc721 §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Community Contracts ERC721: done, 2023-01-20, 2023-08-31\n\n\nstatus: 100%\nCC: Andrea\n\nDescription §\nJustification §\nDeliverables §"},"vac/sc/g/status/community-contracts-deployer":{"title":"Community Contracts Deployer","links":[],"tags":[],"content":"vac:sc::status:community-contracts-deployer §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Community Contracts Deployer: 2023-09-01, 2023-09-30\n\n\nstatus: 100%\nCC: r4bbit\n\nDescription §\nJustification §\nDeliverables §\n\n\nhttps://github.com/status-im/communities-contracts/commit/e7d799b761e87166ecee4efaaede0b7a6cc367ad\n\n\nhttps://goerli-optimism.etherscan.io/address/0xfFa8A255D905c909379859eA45B959D090DDC2d4\n\n\nTest-net addresses:\nCommunityTokenDeployer 0xfFa8A255D905c909379859eA45B959D090DDC2d4\nCommunityOwnerTokenRegistry 0x99F0Eeb7E9F1Da6CA9DDf77dD7810B665FD85750\nCommunityOwnerTokenFactory 0x76d0E484e7c3398922636960Ab33bDe6E9936D81\nCommunityMasterTokenFactory 0x420BE6568c6E09782CEAE1575495Cd6C1c7EA04D\n"},"vac/sc/g/status/community-contracts-maintenance":{"title":"Community Contracts Maintenance","links":[],"tags":[],"content":"vac:sc::status:community-contracts-maintenance §\n\n\nstatus: ongoing\nCC: Andrea\n\nDescription §\nJustification §\nDeliverables §"},"vac/sc/g/status/community-contracts-token-import":{"title":"Token Import","links":[],"tags":[],"content":":sc:g:status:token-import §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Production Readiness:\n\n\nstatus: 5%\nCC: Andrea\n\nDescription §\nNote: This milestones needs further details, which will be agreed apon with Status in an upcoming meeting.\nPreliminary description:\nDesign and implement a contract that offers a token import functionality to communities.\nIt should allow:\n\ndeploying a token vault for a given token\ndepositing tokens to specific token vaults\nspecific community members (token masters) can alter (e.g. airdrop) tokens in the store\ntokens in the vault can be air dropped\n\nA token vault is basically a community wallet that a community’s token masters can airdrop from.\nJustification §\nDeliverables §\n\ndesign description\nsmart contract\n"},"vac/sc/g/status/community-curation-contracts":{"title":"Community Curation dapp Contracts","links":["vac/sc/g/status/snt-optimism-bridge"],"tags":[],"content":"vac:sc::status:community-curation-dapp-contracts §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Production Readiness: 2023-09-15, 2023-10-21\n\n\nstatus: 95%\nCC: Ricardo\n\nDescription §\nDepends on finishing SNT-optimism-bridge\nThe milestone has to be completed (can be a mitigation / preliminary fix):\n\nhttps://github.com/status-im/community-dapp/issues/64\nhttps://github.com/status-im/community-dapp/issues/65\n\nInfo §\nThis milestone comprises what the SC has to deliver towards the completion of Status No2 prio:\n2) if any further work needs to be done on the Community Directory Curation dApp for the initial launch this is second priority\nJustification §\nDeliverables §"},"vac/sc/g/status/governance-contract-mvp":{"title":"Governance Contract MVP","links":[],"tags":[],"content":"vac:sc::status:governance-contract-mvp §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Governance Contract MVP: 2023-08-01, 2023-09-30\n\n\nstatus: 20%\nCC: Ricardo\n\nDescription §\n\nvoting within communities\nreplace the current community-dapp voting contracts https://github.com/status-im/community-dapp/tree/master/packages/contracts/contracts\ntesting is out of scope for that milestone\n\nJustification §\nDeliverables §"},"vac/sc/g/status/mimime-token-enhancement":{"title":"MimiMe Token Enhancements","links":[],"tags":[],"content":"vac:sc::status:minime-token-enhancement §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD\n section Status\n SNT Optimism Bridge:\n\n\nstatus: 20%\nCC: Ricardo\n\nDescription §\nThis is future work. Not pressing atm.\n\nhttps://github.com/vacp2p/minime/issues/6\n\nlow hanging fruit regarding gas savings\nwill setup a follow up milestone for further improvements\n\n\n\nJustification §\nDeliverables §"},"vac/sc/g/status/mimime-token-maintenance":{"title":"MimiMe Token Maintenance","links":[],"tags":[],"content":"vac:sc::status:minime-token-maintenance §\n\n\nstatus: ongoing\nCC: Ricardo\n\nDescription §\nJustification §\nDeliverables §"},"vac/sc/g/status/snt-optimism-bridge":{"title":"SNT Optimism Bridge","links":["vac/sc/g/status/mimime-token-enhancement"],"tags":[],"content":"vac:sc::status:snt-optimism-bridge §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n SNT Optimism Bridge: 2023-09-01, 2023-09-30\n\n\nstatus: 100%\nCC: Ricardo\n\nDescription §\nThis milestone comprises issues that have to be completed to bridge SNT to Optimism.\nThese issues are part of enhancing the MimiMe token.\n\nhttps://github.com/vacp2p/minime/issues/19\nhttps://github.com/vacp2p/minime/issues/17\nhttps://github.com/vacp2p/minime/issues/7\nhttps://github.com/vacp2p/minime/issues/5\nhttps://github.com/vacp2p/minime/issues/31\n\nFollowing enhancments to the MimiMe token (future work) are tracked in:\nmimime-token-enhancement\nThis milestone also contains:\n\na listing of issues identified in the 1st Certora audit, which we addressed\na listing of issues that are now out of scope because we forked the MimiMe repo, and removed parts we do not need\nCertora checking\n\nInfo §\nThis milestone comprises what the SC has to deliver towards the completion of Status No1 prio:\nthe SNT contract for deployment on Optimism is top priority\nNote: This milestone includes deployment on Goerli and “manual” testing.\nIntegration tests for this milestone is out of scope for this milestone.\nIf integration tests are desired, we would track and address this in a future milestone.\nJustification §\nDeliverables §"},"vac/sc/g/status/staking-contract-maintenance":{"title":"Status Staking Contract Maintenance Details","links":[],"tags":[],"content":"%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tStaking contract maintenance :, 2023-01-20, 2023-08-31\n\n\ndue date: 2023/08/31\nstatus: 100%\n\nDescription §\nStatus staking contract MVP maintenance\nDeliverable §\nTBD"},"vac/sc/g/status/staking-contract-mvp":{"title":"Status Staking Contract MVP","links":[],"tags":[],"content":"vac:sc::status:staking-contract-mvp §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tStaking Contract :, 2023-01-20, 2023-08-31\n\n\ndue date:\nstatus: 100%\n\nDescription §\nMVP for the Status staking contract\nDeliverable §\nTBD"},"vac/sc/g/status/staking-contract":{"title":"Status Staking Contract","links":["vac/sc/g/status/staking-contract"],"tags":[],"content":"vac:sc::status:staking-contract §\nG\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Status Staking Contract: 2023-09-01, 2023-10-31\n\n\nstatus: 10%\nCC: Ricardo\n\nDescription §\nThis milestone comprises a set of improvements on and extensions to the current state of the staking contract staking-contract.\nDetails can be found here: https://www.notion.so/Implementing-SNT-Staking-Contract-Issues-Differences-2de74e7c19124e78b1c9490300a84422\nThis document is the basis for the following issues:\n\nhttps://github.com/logos-co/staking/issues/9\nhttps://github.com/logos-co/staking/issues/10\nhttps://github.com/logos-co/staking/issues/11\nhttps://github.com/logos-co/staking/issues/12\nhttps://github.com/logos-co/staking/issues/13\nhttps://github.com/logos-co/staking/issues/14\nhttps://github.com/logos-co/staking/issues/15\nhttps://github.com/logos-co/staking/issues/16\nhttps://github.com/logos-co/staking/issues/17\nhttps://github.com/logos-co/staking/issues/18\n\nThe milestone is achieved when these issues have been resolved.\nJustification §\nDeliverables §"},"vac/sc/g/vac/rln-contract-support":{"title":"Vac RLN Contract Support Details","links":[],"tags":[],"content":"%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Vac\n\t\tRLN Contract Support :, 2023-01-20, 2023-09-15\n\n\ndue date: 2023/09/15\nstatus: 10%\n\nDescription §\nKick-off task for the Vac SC Unit"},"vac/sc/g/vac/secureum-upskilling":{"title":"Secureum Upskilling","links":[],"tags":[],"content":"vac:sc::vac:secureum-upskilling §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n tickInterval 1month\n dateFormat YYYY-MM-DD \n section Status\n Secureum Upskilling: 2023-08-15, 2023-10-15\n\n\nstatus: 70%\nCC: team\n\nDescription §\nJustification §\nDeliverables §"},"vac/sc/index":{"title":"Smart Contracts Service Unit","links":["vac/sc/g/status/community-contracts-ERC721","vac/sc/g/status/community-contracts-ERC20","vac/sc/g/status/community-contracts-deployer","vac/sc/g/status/community-contracts-token-import","vac/sc/g/status/community-contracts-maintenance","vac/sc/g/status/community-curation-contracts","vac/sc/g/status/snt-optimism-bridge","vac/sc/g/status/mimime-token-enhancement","vac/sc/g/status/mimime-token-maintenance","vac/sc/g/status/governance-contract-mvp","vac/sc/g/status/staking-contract-mvp","vac/sc/g/status/staking-contract","vac/sc/g/status/staking-contract-maintenance","vac/sc/g/codex/review-codex-contracts","vac/sc/g/vac/secureum-upskilling","vac/sc/g/vac/rln-contract-support"],"tags":["sc","vac"],"content":"vac:sc:: §\n\nstatus: §\n\n community-contracts-ERC721\n community-contracts-ERC20\n community-contracts-deployer\ncommunity-contracts-token-import\ncommunity-contracts-maintenance\ncommunity-curation-contracts\n SNT-optimism-bridge\nmimime-token-enhancement\nmimime-token-maintenance\ngovernance-contract-mvp\n staking-contract-mvp\nstaking-contract\nstaking-contract-maintenance\n\ncodex: §\n\nreview-codex-contracts\n\nvac: §\n\nsecureum-upskilling\nrln-contract-support\n"},"vac/tke/g/codex/economic-analysis":{"title":"Codex Economic Analysis","links":[],"tags":[],"content":"vac:tke::codex:economic-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD\n\tsection Codex\n\t\tEconomic Analysis :, 2023-01-20, 2023-08-30\n\n\nstatus: 50%\nCC: Matty\n\nDescription §\nCodex economic analysis, Codex token utility, Codex collateral management\nJustification §\nPer Dimitry and Jesse, required by Codex team for completing implementation of system and planning launch"},"vac/tke/g/nomos/economic-analysis":{"title":"Nomos Economic Analysis","links":[],"tags":[],"content":"vac:tke::nomos:economic-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Nomos\n\t\tEconomic Analysis :, 2023-05-01, 2023-10-31\n\n\nstatus: 30%\nCC: Frederico\n\nDescription §\nNomos economic analysis, Nomos token utility, requirements and constraints\nJustification §\nRequired for ensuring economic security and censorship resistance of Nomos chain"},"vac/tke/g/status/snt-governance-proposal":{"title":"SNT Governance Proposal","links":[],"tags":[],"content":"vac:tke::status:SNT-governance-proposal §\n\ndue: TDB\nstatus: TDB\nCC: Matty\nDescription §\n\ntook precedence over SNT litepaper\nfirst draft being prepared for next review with John on 2023/09/12\n\nJustification §\n\nPer John’s request, high importance for involving community for relaunch of Status app and refresh of SNT token\n"},"vac/tke/g/status/snt-litepaper":{"title":"SNT Litepaper","links":[],"tags":[],"content":"vac:tke::status:SNT-litepaper §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tSNT Litepaper: 2023-01-20, 2023-08-30\n\n\nstatus: 70% - delayed: governance proposal taking precedence\nCC: Matty\n\nDescription §\n\ndelayed, other milestones took precedence\nPer confirmation with John on 2023/08/22 litepaper is not a pressing need, much lower priority than governance proposal\n\nJustification §\n\nhelpful to support relaunch of Status app and describe SNT’s new staking features\n"},"vac/tke/g/status/snt-staking":{"title":"SNT Staking","links":["vac/sc/"],"tags":[],"content":"vac:tke::status:SNT-staking §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tSNT Staking :, 2023-01-20, 2023-08-30\n\n\nstatus: 82%\nCC: Frederico (Python), Martin\ncollab: smart contracts team\n\nDescription: §\nRisks §\n\nimplementation of the smart contract is being handed off to smart contract team\n"},"vac/tke/g/waku/economic-analysis":{"title":"Waku Economic Analysis","links":[],"tags":[],"content":"vac:tke::waku:economic-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Waku\n\t\tEconomic Analysis :, 2023-06-01, 2023-11-30\n\n\nstatus: 10%\nCC: Martin\n\nDescription §\nWaku economic analysis"},"vac/tke/index":{"title":"Token Engineering Service Unit","links":["vac/tke/g/status/snt-litepaper","vac/tke/g/status/snt-governance-proposal","vac/tke/g/status/snt-staking","vac/tke/g/codex/economic-analysis","vac/tke/g/nomos/economic-analysis","vac/tke/g/waku/economic-analysis"],"tags":["p2p","vac"],"content":"vac:tke:: §\n\nstatus: §\n\nsnt-lightpaper\nSNT-governance-proposal\nSNT-staking\n\ncodex: §\n\neconomic-analysis\n\nnomos: §\n\neconomic-analysis\n\nwaku: §\n\neconomic-analysis\n"},"vac/updates/2023-07-10":{"title":"2023-07-10 Vac Weekly","links":[],"tags":["vac-updates"],"content":"\nvc::Deep Research\n\nrefined deep research roadmaps https://github.com/vacp2p/research/issues/190, https://github.com/vacp2p/research/issues/192\nworking on comprehensive current/related work study on Validator Privacy\nworking on PoC of Tor push in Nimbus\nworking towards comprehensive current/related work study on gossipsub scaling\n\n\nvsu::P2P\n\nPrepared Paris talks\nImplemented perf protocol to compare the performances with other libp2ps https://github.com/status-im/nim-libp2p/pull/925\n\n\nvsu::Tokenomics\n\nFixing bugs on the SNT staking contract;\nDefinition of the first formal verification tests for the SNT staking contract;\nSlides for the Paris off-site\n\n\nvsu::Distributed Systems Testing\n\nReplicated message rate issue (still on it)\nFirst mockup of offline data\nNomos consensus test working\n\n\nvip::zkVM\n\nhiring\nonboarding new researcher\npresentation on ECC during Logos Research Call (incl. preparation)\nmore research on nova, considering additional options\nIdentified 3 research questions to be taken into consideration for the ZKVM and the publication\nResearched Poseidon implementation for Nova, Nova-Scotia, Circom\n\n\nvip::RLNP2P\n\nfinished rln contract for waku product - https://github.com/waku-org/rln-contract\nfixed homebrew issue that prevented zerokit from building - https://github.com/vacp2p/zerokit/commit/8a365f0c9e5c4a744f70c5dd4904ce8d8f926c34\nrln-relay: verify proofs based upon bandwidth usage - https://github.com/waku-org/nwaku/commit/3fe4522a7e9e48a3196c10973975d924269d872a\nRLN contract audit cont’ https://hackmd.io/@blockdev/B195lgIth\n\n\n"},"vac/updates/2023-07-17":{"title":"2023-07-17 Vac weekly","links":[],"tags":["vac-updates"],"content":"Last week\n\nvc\n\nVac day in Paris (13th)\n\n\nvc::Deep Research\n\nworking on comprehensive current/related work study on Validator Privacy\nworking on PoC of Tor push in Nimbus: setting up goerli nim-eth2 node\nworking towards comprehensive current/related work study on gossipsub scaling\n\n\nvsu::P2P\n\nParis offsite Paris (all CCs)\n\n\nvsu::Tokenomics\n\nBugs found and solved in the SNT staking contract\nattend events in Paris\n\n\nvsu::Distributed Systems Testing\n\nEvents in Paris\nQoS on all four infras\nContinue work on theoretical gossipsub analysis (varying regular graph sizes)\nPeer extraction using WLS (almost finished)\nDiscv5 testing\nWakurtosis CI improvements\nProvide offline data\n\n\nvip::zkVM\n\nonboarding new researcher\nPrepared and presented ZKVM work during VAC offsite\nDeep research on Nova vs Stark in terms of performance and related open questions\nresearching Sangria\nWorked on NEscience document (https://www.notion.so/Nescience-WIP-0645c738eb7a40869d5650ae1d5a4f4e)\nzerokit:\n\nworked on PR for arc-circom\n\n\n\n\nvip::RLNP2P\n\noffsite Paris\n\n\n\nThis week\n\nvc\nvc::Deep Research\n\nworking on comprehensive current/related work study on Validator Privacy\nworking on PoC of Tor push in Nimbus\nworking towards comprehensive current/related work study on gossipsub scaling\n\n\nvsu::P2P\n\nEthCC & Logos event Paris (all CCs)\n\n\nvsu::Tokenomics\n\nAttend EthCC and side events in Paris\nIntegrate staking contracts with radCAD model\nWork on a new approach for Codex collateral problem\n\n\nvsu::Distributed Systems Testing\n\nEvents in Paris\nFinish peer extraction, plot the peer connections; script/runs for the analysis, and add data to the Tech Report\nRestructure the Analysis script and start modelling Status control messages\nSplit Wakurtosis analysis module into separate repository (delayed)\nDeliver simulation results (incl fixing discv5 error with new Kurtosis version)\nSecond iteration Nomos CI\n\n\nvip::zkVM\n\nContinue researching on Nova open questions and Sangria\nDraft the benchmark document (by the end of the week)\nresearch hardware for benchmarks\nresearch Halo2 cont’\nzerokit:\n\nmerge a PR for deployment of arc-circom\ndeal with arc-circom master fail\n\n\n\n\nvip::RLNP2P\n\noffsite paris\n\n\nblockers\n\nvip::zkVM:zerokit: ark-circom deployment to crates io; contact to ark-circom team\n\n\n"},"vac/updates/2023-07-24":{"title":"2023-08-03 Vac weekly","links":[],"tags":["vac-updates"],"content":"NOTE: This is a first experimental version moving towards the new reporting structure:\nLast week\n\nvc\nvc::Deep Research\n\nmilestone (15%, 2023/11/30) paper on gossipsub improvements ready for submission\n\nrelated work section\n\n\nmilestone (15%, 2023/08/31) Nimbus Tor-push PoC\n\nbasic torpush encode/decode ( https://github.com/vacp2p/nim-libp2p-experimental/pull/1 )\n\n\nmilestone (15%, 2023/11/30) paper on Tor push validator privacy\n\n(focus on Tor-push PoC)\n\n\n\n\nvsu::P2P\n\nadmin/misc\n\nEthCC (all CCs)\n\n\n\n\nvsu::Tokenomics\n\nadmin/misc\n\nAttended EthCC and side events in Paris\n\n\nmilestone (30%, 2023/09/30) Codex economic analysis, Codex token utility, Codex collateral management\n\nKicked off a new approach for Codex collateral problem\n\n\nmilestone (50%, 2023/08/30) SNT staking smart contract\n\nIntegrated SNT staking contracts with Python\n\n\nmilestone (50%, 2023/07/14) SNT litepaper\n\n(delayed)\n\n\nmilestone(30%, 2023/09/29) Nomos Token: requirements and constraints\n\n\nvsu::Distributed Systems Testing\n\nmilestone (95%, 2023/07/31) Wakurtosis Waku Report\n\nAdd timout to injection async call in WLS to avoid further issues (PR #139 https://github.com/vacp2p/wakurtosis/pull/139)\nPlotting & analyse 100 msg/s off line Prometehus data\n\n\nmilestone (90%, 2023/07/31) Nomos CI testing\n\nfixed errors in Nomos consensus simulation\n\n\nmilestone (30%, …) gossipsub model analysis\n\nadd config options to script, allowing to load configs that can be directly compared to Wakurtosis results\nadded support for small world networks\n\n\nadmin/misc\n\nInterviews & reports for SE and STA positions\nEthCC (1 CC)\n\n\n\n\nvip::zkVM\n\nmilestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria…)\n\n(write ups will be available here: https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451)\nSolved the open questions on Nova adn completed the document (will update the page)\nReviewed Nescience and working on a document\nReviewed partly the write up on FHE\nwriteup for Nova and Sangria; research on super nova\nreading a new paper revisiting Nova (https://eprint.iacr.org/2023/969)\n\n\nmilestone (50%, 2023/08/31) new fair benchmarks + recursive implementations\nzkvm\n\nResearching Nova to understand the folding technique for ZKVM adaptation\n\n\nzerokit\n\nRostyslav became circom-compat maintainer\n\n\n\n\nvip::RLNP2P\n\nmilestone (100%, 2023/07/31) rln-relay testnet 3 completed and retro\n\ncompleted\n\n\nmilestone (95%, 2023/07/31) RLN-Relay Waku production readiness\nadmin/misc\n\nEthCC + offsite\n\n\n\n\n\nThis week\n\nvc\nvc::Deep Research\n\nmilestone (15%, 2023/11/30) paper on gossipsub improvements ready for submission\n\nworking on contributions section, based on https://hackmd.io/X1DoBHtYTtuGqYg0qK4zJw\n\n\nmilestone (15%, 2023/08/31) Nimbus Tor-push PoC\n\nworking on establishing a connection via nim-libp2p tor-transport\nsetting up goerli test node (cont’)\n\n\nmilestone (15%, 2023/11/30) paper on Tor push validator privacy\n\ncontinue working on paper\n\n\n\n\nvsu::P2P\n\nmilestone (…)\n\nImplement ChokeMessage for GossipSub\nContinue “limited flood publishing” (https://github.com/status-im/nim-libp2p/pull/911)\n\n\n\n\nvsu::Tokenomics\n\nadmin/misc:\n\n(3 CC days off)\nCatch up with EthCC talks that we couldn’t attend (schedule conflicts)\n\n\nmilestone (50%, 2023/07/14) SNT litepaper\n\nStart building the SNT agent-based simulation\n\n\n\n\nvsu::Distributed Systems Testing\n\nmilestone (100%, 2023/07/31) Wakurtosis Waku Report\n\nfinalize simulations\nfinalize report\n\n\nmilestone (100%, 2023/07/31) Nomos CI testing\n\nfinalize milestone\n\n\nmilestone (30%, …) gossipsub model analysis\n\nIncorporate Status control messages\n\n\nadmin/misc\n\nInterviews & reports for SE and STA positions\nEthCC (1 CC)\n\n\n\n\nvip::zkVM\n\nmilestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria…)\n\nRefine the Nescience WIP and FHE documents\nresearch HyperNova\n\n\nmilestone (50%, 2023/08/31) new fair benchmarks + recursive implementations\n\nContinue exploring Nova and other ZKPs and start technical writing on Nova benchmarks\n\n\nzkvm\nzerokit\n\ncircom: reach an agreement with other maintainers on master branch situation\n\n\n\n\nvip::RLNP2P\n\nmaintenance\n\ninvestigate why docker builds of nwaku are failing [zerokit dependency related]\ndocumentation on how to use rln for projects interested (https://discord.com/channels/864066763682218004/1131734908474236968/1131735766163267695)(https://ci.infra.status.im/job/nim-waku/job/manual/45/console)\n\n\nmilestone (95%, 2023/07/31) RLN-Relay Waku production readiness\n\nrevert rln bandwidth reduction based on offsite discussion, move to different validator\n\n\n\n\nblockers\n"},"vac/updates/2023-07-31":{"title":"2023-07-31 Vac weekly","links":[],"tags":["vac-updates"],"content":"\nvc::Deep Research\n\nmilestone (20%, 2023/11/30) paper on gossipsub improvements ready for submission\n\nproposed solution section\n\n\nmilestone (15%, 2023/08/31) Nimbus Tor-push PoC\n\nestablishing torswitch and testing code\n\n\nmilestone (15%, 2023/11/30) paper on Tor push validator privacy\naddressed feedback on current version of paper\n\n\nvsu::P2P\n\nnim-libp2p: (100%, 2023/07/31) GossipSub optimizations for ETH’s EIP-4844\n\nMerged IDontWant (https://github.com/status-im/nim-libp2p/pull/934) & Limit flood publishing (https://github.com/status-im/nim-libp2p/pull/911) 𝕏\nThis wraps up the “mandatory” optimizations for 4844. We will continue working on stagger sending and other optimizations\n\n\nnim-libp2p: (70%, 2023/07/31) WebRTC transport\n\n\nvsu::Tokenomics\n\nadmin/misc\n\n2 CCs off for the week\n\n\nmilestone (30%, 2023/09/30) Codex economic analysis, Codex token utility, Codex collateral management\nmilestone (50%, 2023/08/30) SNT staking smart contract\nmilestone (50%, 2023/07/14) SNT litepaper\nmilestone (30%, 2023/09/29) Nomos Token: requirements and constraints\n\n\nvsu::Distributed Systems Testing\n\nadmin/misc\n\nAnalysis module extracted from wakurtosis repo (https://github.com/vacp2p/wakurtosis/pull/142, https://github.com/vacp2p/DST-Analysis)\nhiring\n\n\nmilestone (99%, 2023/07/31) Wakurtosis Waku Report\n\nRe-run simulations\nmerge Discv5 PR (https://github.com/vacp2p/wakurtosis/pull/129).\nfinalize Wakurtosis Tech Report v2\n\n\nmilestone (100%, 2023/07/31) Nomos CI testing\n\ndelivered first version of Nomos CI integration (https://github.com/vacp2p/wakurtosis/pull/141)\n\n\nmilestone (30%, 2023/08/31 gossipsub model: Status control messages\n\nWaku model is updated to model topics/content-topics\n\n\n\n\nvip::zkVM\n\nmilestone(50%, 2023/08/31) background/research on existing proof systems (nova, sangria…)\n\nachievment :: nova questions answered (see document in Project: https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451)\nNescience WIP done (to be delivered next week, priority)\nFHE review (lower prio)\n\n\nmilestone (50%, 2023/08/31) new fair benchmarks + recursive implementations\n\nWorking on discoveries about other benchmarks done on plonky2, starky, and halo2\n\n\nzkvm\nzerokit\n\nfixed ark-circom master\nachievment :: publish ark-circom https://crates.io/crates/ark-circom\nachievment :: publish zerokit_utils https://crates.io/crates/zerokit_utils\nachievment :: publish rln https://crates.io/crates/rln (𝕏 jointly with RLNP2P)\n\n\n\n\nvip::RLNP2P\n\nmilestone (100%, 2023/07/31) RLN-Relay Waku production readiness\n\nUpdated rln-contract to be more modular - and downstreamed to waku fork of rln-contract - https://github.com/vacp2p/rln-contract and http://github.com/waku-org/waku-rln-contract\nDeployed to sepolia\nFixed rln enabled docker image building in nwaku - https://github.com/waku-org/nwaku/pull/1853\n\n\nzerokit:\n\nachievement :: zerokit v0.3.0 release done - https://github.com/vacp2p/zerokit/releases/tag/v0.3.0 (𝕏 jointly with zkVM)\n\n\n\n\n"},"vac/updates/2023-08-07":{"title":"2023-08-07 Vac weekly","links":[],"tags":["vac-updates"],"content":"More info on Vac Milestones, including due date and progress (currently working on this, some milestones do not have the new format yet, first version planned for this week):\nhttps://www.notion.so/Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac week 32 August 7th\n\nvsu::P2P\n\nvac:p2p:nim-libp2p:vac:maintenance\n\nImprove gossipsub DDoS resistance https://github.com/status-im/nim-libp2p/pull/920\n\n\nvac:p2p:nim-chronos:vac:maintenance\n\nRemove hard-coded ports from test https://github.com/status-im/nim-chronos/pull/429\nInvestigate flaky test using REUSE_PORT\n\n\n\n\nvsu::Tokenomics\n\n(…)\n\n\nvsu::Distributed Systems Testing\n\nvac:dst:wakurtosis:waku:techreport\n\ndelivered: Wakurtosis Tech Report v2 (https://docs.google.com/document/d/1U3bzlbk_Z3ZxN9tPAnORfYdPRWyskMuShXbdxCj4xOM/edit?usp=sharing)\n\n\nvac:dst:wakurtosis:vac:rlog\n\nworking on research log post on Waku Wakurtosis simulations\n\n\nvac:dst:gsub-model:status:control-messages\n\ndelivered: the analytical model can now handle Status messages; status analysis now has a separate cli and config; handles top 5 message types (by expected bandwidth consumption)\n\n\nvac:dst:gsub-model:vac:refactoring\n\nRefactoring and bug fixes\nintroduced and tested 2 new analytical models\n\n\nvac:dst:wakurtosis:waku:topology-analysis\n\ndelivered: extracted into separate module, independent of wls message\n\n\nvac:dst:wakurtosis:nomos:ci-integration_02\n\nplanning\n\n\nvac:dst:10ksim:vac:10ksim-bandwidth-test\n\nplanning; check usage of new codex simulator tool (https://github.com/codex-storage/cs-codex-dist-tests)\n\n\n\n\nvip::zkVM\n\nvac:zkvm::vac:research-existing-proof-systems\n\n90% Nescience WIP done – to be reviewed carefully since no other follow up documents were giiven to me\n50% FHE review - needs to be refined and summarized\nfinished SuperNova writeup ( https://www.notion.so/SuperNova-research-document-8deab397f8fe413fa3a1ef3aa5669f37 )\nresearched starky\n80% Halo2 notes ( https://www.notion.so/halo2-fb8d7d0b857f43af9eb9f01c44e76fb9 )\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nMore discoveries on benchmarks done on ZK-snarks and ZK-starks but all are high level\nViewed some circuits on Nova and Poseidon\nRead through Halo2 code (and Poseidon code) from Axiom\n\n\n\n\nvip::RLNP2P\n\nvac:acz:rlnp2p:waku:production-readiness\n\nWaku rln contract registry - https://github.com/waku-org/waku-rln-contract/pull/3\nmark duplicated messages as spam - https://github.com/waku-org/nwaku/pull/1867\nuse waku-org/waku-rln-contract as a submodule in nwaku - https://github.com/waku-org/nwaku/pull/1884\n\n\nvac:acz:zerokit:vac:maintenance\n\nFixed atomic_operation ffi edge case error - https://github.com/vacp2p/zerokit/pull/195\ndocs cleanup - https://github.com/vacp2p/zerokit/pull/196\nfixed version tags - https://github.com/vacp2p/zerokit/pull/194\nreleased zerokit v0.3.1 - https://github.com/vacp2p/zerokit/pull/198\nmarked all functions as virtual in rln-contract for inheritors - https://github.com/vacp2p/rln-contract/commit/a092b934a6293203abbd4b9e3412db23ff59877e\nmake nwaku use zerokit v0.3.1 - https://github.com/waku-org/nwaku/pull/1886\nrlnp2p implementers draft - https://hackmd.io/@rymnc/rln-impl-w-waku\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nzerokit v0.4.0 release planning - https://github.com/vacp2p/zerokit/issues/197\n\n\n\n\nvc::Deep Research\n\nvac:dr:valpriv:vac:tor-push-poc\n\nredesigned the torpush integration in nimbus https://github.com/vacp2p/nimbus-eth2-experimental/pull/2\n\n\nvac:dr:valpriv:vac:tor-push-relwork\n\nAddressed further comments in paper, improved intro, added source level variation approach\n\n\nvac:dr:gsub-scaling:vac:gossipsub-improvements-tech-report\n\ncont’ work on the document\n\n\n\n\n"},"vac/updates/2023-08-14":{"title":"2023-08-17 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac Milestones: https://www.notion.so/Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac week 33 August 14th §\n\nvsu::P2P §\nvac:p2p:nim-libp2p:vac:maintenance §\n\nImprove gossipsub DDoS resistance https://github.com/status-im/nim-libp2p/pull/920\ndelivered: Perf protocol https://github.com/status-im/nim-libp2p/pull/925\ndelivered: Test-plans for the perf protocol https://github.com/lchenut/test-plans/tree/perf-nim\nBandwidth estimate as a parameter (waiting for final review) https://github.com/status-im/nim-libp2p/pull/941\n\nvac:p2p:nim-chronos:vac:maintenance §\n\ndelivered: Remove hard-coded ports from test https://github.com/status-im/nim-chronos/pull/429\ndelivered: fixed flaky test using REUSE_PORT https://github.com/status-im/nim-chronos/pull/438\n\n\nvsu::Tokenomics §\n\nadmin/misc:\n\n(5 CC days off)\n\n\n\nvac:tke::codex:economic-analysis §\n\nFilecoin economic structure and Codex token requirements\n\nvac:tke::status:SNT-staking §\n\ntests with the contracts\n\nvac:tke::nomos:economic-analysis §\n\nresume discussions with Nomos team\n\n\nvsu::Distributed Systems Testing (DST) §\nvac:dst:wakurtosis:waku:techreport §\n\n1st Draft of Wakurtosis Research Blog (https://github.com/vacp2p/vac.dev/pull/123)\nData Process / Analysis of Non-Discv5 K13 Simulations (Wakurtosis Tech Report v2.5)\n\nvac:dst:shadow:vac:basic-shadow-simulation §\n\nBasic Shadow Simulation of a gossipsub node (Setup, 5nodes)\n\nvac:dst:10ksim:vac:10ksim-bandwidth-test §\n\nTry and plan on how to refactor/generalize testing tool from Codex.\nLearn more about Kubernetes\n\nvac:dst:wakurtosis:nomos:ci-integration_02 §\n\nEnable subnetworks\nPlan how to use wakurtosis with fixed version\n\nvac:dst:eng:vac:bundle-simulation-data §\n\nRun requested simulations\n\n\nvsu:Smart Contracts (SC) §\nvac:sc::vac:secureum-upskilling §\n\nLearned about\n\ncold vs warm storage reads and their gas implications\nUTXO vs account models\nDELEGATECALL vs CALLCODE opcodes, CREATE vs CREATE2 opcodes; Yul Assembly\nUnstructured proxies https://eips.ethereum.org/EIPS/eip-1967\nC3 Linearization https://forum.openzeppelin.com/t/solidity-diamond-inheritance/2694) (Diamond inheritance and resolution)\n\n\nUniswap deep dive\nFinished Secureum slot 2 and 3\n\nvac:sc::vac:maintainance/misc §\n\nIntroduced Vac’s own foundry-template for smart contract projects\n\nGoal is to have the same project structure across projects\nGithub repository: https://github.com/vacp2p/foundry-template\n\n\n\n\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:zerokit:vac:maintenance\n\nPR reviews https://github.com/vacp2p/zerokit/pull/200, https://github.com/vacp2p/zerokit/pull/201\n\n\n\n\nvip::zkVM §\nvac:zkvm::vac:research-existing-proof-systems §\n\ndelivered Nescience WIP doc\ndelivered FHE review\ndelivered Nova vs Sangria done - Some discussions during the meeting\nstarted HyperNova writeup\nstarted writing a trimmed version of FHE writeup\nresearched CCS (for HyperNova)\nResearch Protogalaxy https://eprint.iacr.org/2023/1106 and Protostar https://eprint.iacr.org/2023/620.\n\nvac:zkvm::vac:proof-system-benchmarks §\n\nMore work on benchmarks is ongoing\nPutting down a document that explains the differences\n\n\nvc::Deep Research §\nvac:dr:valpriv:vac:tor-push-poc §\n\nrevised the code for PR\n\nvac:dr:valpriv:vac:tor-push-relwork §\n\nadded section for mixnet, non-Tor/non-onion routing-based anonymity network\n\nvac:dr:gsub-scaling:vac:gossipsub-simulation §\n\nUsed shadow simulator to run first GossibSub simulation\n\nvac:dr:gsub-scaling:vac:gossipsub-improvements-tech-report §\n\nFinalized 1st draft of the GossipSub scaling article\n"},"vac/updates/2023-08-21":{"title":"2023-08-21 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac Milestones: https://www.notion.so/Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac Github Repos: https://www.notion.so/Vac-Repositories-75f7feb3861048f897f0fe95ead08b06\nVac week 34 August 21th §\nvsu::P2P §\n\nvac:p2p:nim-libp2p:vac:maintenance\n\nTest-plans for the perf protocol (99%: need to find why the executable doesn’t work) https://github.com/libp2p/test-plans/pull/262\nWebRTC: Merge all protocols (60%: slowed down by some complications and bad planning with Mbed-TLS) https://github.com/status-im/nim-webrtc/pull/3\nWebRTC: DataChannel (25%)\n\n\n\nvsu::Tokenomics §\n\nadmin/misc:\n\n(3 CC days off)\n\n\nvac:tke::codex:economic-analysis\n\nCall w/ Codex on token incentives, business analysis of Filecoin\n\n\nvac:tke::status:SNT-staking\n\nBug fixes for tests for the contracts\n\n\nvac:tke::nomos:economic-analysis\n\nNarrowed focus to: 1) quantifying bribery attacks, 2) assessing how to min risks and max privacy of delegated staking\n\n\nvac:tke::waku:economic-analysis\n\nCaught up w/ Waku team on RLN, adopting a proactive effort to pitch them solutions\n\n\n\nvsu::Distributed Systems Testing (DST) §\n\nvac:dst:wakurtosis:vac:rlog\n\nPushed second draft and figures (https://github.com/vacp2p/vac.dev/tree/DST-Wakurtosis)\n\n\nvac:dst:shadow:vac:basic-shadow-simulation\n\nRun 10K simulation of basic gossipsub node\n\n\nvac:dst:gsub-model:status:control-messages\n\nGot access to status superset\n\n\nvac:dst:analysis:nomos:nomos-simulation-analysis\n\nBasic CLI done, json to csv, can handle 10k nodes\n\n\nvac:dst:wakurtosis:waku:topology-analysis\n\nCollection + analysis: now supports all waku protocols, along with relay\nCannot get gossip-sub peerage from waku or prometheus (working on getting info from gossipsub layer)\n\n\nvac:dst:wakurtosis:waku:techreport_02\n\nMerged 4 pending PRs; master now supports regular graphs\n\n\nvac:dst:eng:vac:bundle-simulation-data\n\nRun 1 and 10 rate simulations. 100 still being run\n\n\nvac:dst:10ksim:vac:10ksim-bandwidth-test\n\nWorking on split the structure of codex tool; Working on diagrams also\n\n\n\nvsu:Smart Contracts (SC) §\n\nvac:sc::status:community-contracts-ERC721\n\ndelivered (will need maintenance and adding features as requested in the future)\n\n\nvac:sc::status:community-contracts-ERC20\n\nstarted working on ERC20 contracts\n\n\nvac:sc::vac:secureum-upskilling\n\nSecureum: Finished Epoch 0, Slot 4 and 5\nDeep dive on First Depositor/Inflation attacks\nLearned about Minimal Proxy Contract pattern\nMore Uniswap V2 protocol reading\n\n\nvac:sc::vac:maintainance/misc\n\nWorked on moving community dapp contracts to new foundry-template\n\n\n\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:rlnp2p:waku:rln-relay-enhancments\n\nrpc handler for waku rln relay - https://github.com/waku-org/nwaku/pull/1852\nfixed ganache’s change in method to manage subprocesses, fixed timeouts related to it - https://github.com/waku-org/nwaku/pull/1913\nshould error out on rln-relay mount failure - https://github.com/waku-org/nwaku/pull/1904\nfixed invalid start index being used in rln-relay - https://github.com/waku-org/nwaku/pull/1915\nconstrain the values that can be used as idCommitments in the rln-contract - https://github.com/vacp2p/rln-contract/pull/26\nassist with waku-simulator testing\nremove registration capabilities from nwaku, it should be done out of band - https://github.com/waku-org/nwaku/pull/1916\nadd deployedBlockNumber to the rln-contract for ease of fetching events from the client - https://github.com/vacp2p/rln-contract/pull/27\n\n\nvac:acz:zerokit:vac:maintenance\n\nexposed seq_atomic_operation ffi api to allow users to make use of the current index without making multiple ffi calls - https://github.com/vacp2p/zerokit/pull/206\nuse pmtree instead of vacp2p_pmtree now that changes have been upstreamed - https://github.com/vacp2p/zerokit/pull/203\nPrepared a PR to fix a stopgap introduces by PR 201 https://github.com/vacp2p/zerokit/pull/207\nPR review https://github.com/vacp2p/zerokit/pull/202, https://github.com/vacp2p/zerokit/pull/206\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nsubstitute id_commitments for rate_commitments and update tests in rln-v2 - https://github.com/vacp2p/zerokit/pull/205\nrln-v2 working branch - https://github.com/vacp2p/zerokit/pull/204\nmisc research while ooo:\nstealth commitment scheme inspired by erc-5564 - https://github.com/rymnc/erc-5564-bn254, associated circuit - https://github.com/rymnc/circom-rln-erc5564 (very heavy on the constraints)\n\n\n\nvip::zkVM §\n\nvac:zkvm::vac:research-existing-proof-systems\n\nUpdated the Nova questions document (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451 -> Projects -> Nova_Research_Answers.pdf)\nResearched ProtoStar and Nova aleternatives\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nDrafted the Nova Benchamarks document (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451 -> Projects -> Benchmarks.pdf)\nResearched hash functions\nResearched benchmarks\n\n\n\nvc::Deep Research §\n\nvac:dr:valpriv:vac:tor-push-poc\n\nReimplemented torpush without any gossip sharing\nAdded discovering peers for torpush in every epoch/10 minutes\ntorswitch directly pushes messages to separately identified peers\n\n\nvac:dr:valpriv:vac:tor-push-relwork\n\nadded quantified measures related to privacy in the paper section\n\n\nvac:dr:gsub-scaling:vac:gossipsub-improvements-tech-report\n\nExplored different unstructured p2p application architectuture\nStudied literature on better bandwidth utilization in unstructured p2p networks.\n\n\nvac:dr:gsub-scaling:vac:gossipsub-simulation\n\nWorked on GossibSup simulation in shadow simulator. Tried understanding different libp2p functions\nCreated short awk scripts for analyzing results.\n\n\nvac:dr:consensus:nomos:carnot-bribery-article\n\nContinue work on the article on bribery attacks, PoS and Carnot\nCompleted presentation about the bribery attacks and Carnot\n\n\nvac:dr:consensus:nomos:carnot-paper\n\nDiscussed Carnot tests and results with Nomos team. Some adjustment to the parameters needed to be made to accurate results.\n\n\n"},"vac/updates/2023-08-28":{"title":"2023-08-28 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac week 35 §\n\nVac Milestones: https://www.notion.so/Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac Github Repos: https://www.notion.so/Vac-Repositories-75f7feb3861048f897f0fe95ead08b06\n\nvsu::P2P §\n\nvac:p2p:nim-libp2p:vac:maintenance\n\nBecaming a Validator in the Nimbus Consensus client (95%)\nIWANT replies can be bigger than the pubsub message limit (100%, on review) https://github.com/status-im/nim-libp2p/issues/887\nImprove gossipsub DDoS resistance (98%) https://github.com/status-im/nim-libp2p/pull/920\n\n\n\nvsu::Tokenomics §\n\nadmin/misc:\nvac:tke::codex:economic-analysis\n\nTimeline of Filecoin vs competitors, IPFS vs Filecoin usage, Filip: miners perspective\n\n\nvac:tke::status:SNT-staking\n\nFurther debugging, verify Multiplier Points calculation (especially gas fee optimization, how GMX implements)\n\n\nvac:tke::nomos:economic-analysis\n\nBook seperate calls w/ Moh and Marcin to discuss helping them w/ their relative points of focus\n\n\nvac:tke::waku:economic-analysis\n\nCall w/ Aaryamann on RLN, condense our thoughts to a “proposal” for Waku\n\n\n\nvsu::Distributed Systems Testing (DST) §\n\nvac:dst:analysis:nomos:nomos-simulation-analysis\n\nAnalysis done, scales to million nodes\nExploratory sets of runs done\nDecided on the parameter set for the final runs\n\n\nvac:dst:software-testing:waku:test-plans\n\nget familiar with specs for some of the Waku protocols\n\n\nvac:dst:software-testing:waku:test-automation-js-waku\n\nSetup local env\nInvestigated how the existing tests are running and how the code is structured\n\n\nadmin/misc:\n\n2 CCs ooo\n\n\n\nvsu:Smart Contracts (SC) §\n\nvac:sc::vac:secureum-upskilling\n\nFinished Secureum Slot 6\nRead a bit into Upgradable contract patterns\n\n\nvac:sc::status:community-contracts-maintenance\n\nMoved communities-contracts repo to our Foundry template https://github.com/status-im/communities-contracts/pull/1\nAlso implemented additional tests\n\n\nvac:sc::vac:maintainance/misc\n\nFinished up moving community-dapp/contracts to foundry template\n\n\nvac:sc::status:community-contracts-deployer\n\nBrainstormed and discussed desired deployer contract with desktop team; Discussion: https://github.com/status-im/status-desktop/issues/11954#issuecomment-1694591812\nupdating ERC2470 https://eips.ethereum.org/EIPS/eip-2470\n\n\nvac:sc::status:snt-staking-contract-maintenance\n\ndiscussing issue with order of processAccount giving advantages on first callers\n\n\n\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:rlnp2p:waku:membership-management\n\nWrote a tool rln_keystore_generator : https://github.com/waku-org/nwaku/pull/1925, https://github.com/waku-org/nwaku/pull/1928, https://github.com/waku-org/nwaku/pull/1931\n\n\nvac:acz:rlnp2p:waku:rln-relay-enhancments\n\ntree metadata should include chainId and contractAddress - https://github.com/waku-org/nwaku/pull/1932\nset flush_interval appropriately -https://github.com/waku-org/nwaku/pull/1933\nintegrate new WakuRlnRegistry contract - https://github.com/waku-org/nwaku/pull/1943\nbump zerokit to v0.3.2 https://github.com/waku-org/nwaku/pull/1951\ntree metadata should include window of roots - https://github.com/waku-org/nwaku/pull/1953\nsync tree state from contract deployed block number - https://github.com/waku-org/nwaku/pull/1955\noptimization to waku_keystore - https://github.com/waku-org/nwaku/pull/1956\nfixed a forceProgression bug in the WakuRlnRegistry contract - https://github.com/waku-org/waku-rln-contract/pull/6\n\n\nvac:acz:zerokit:vac:maintenance\n\nprevent tree db from being recreated if it exists - https://github.com/vacp2p/zerokit/pull/209\nreleased zerokit v0.3.2 - https://github.com/vacp2p/zerokit/releases/tag/v0.3.2\nmerged PR to fix a stopgap introduced by PR 201 https://github.com/vacp2p/zerokit/pull/207\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nPrepared a PR to deal with message_id range check https://github.com/vacp2p/zerokit/pull/210\nResearched needed changes to rln-cli\n\n\n\nvip::zkVM §\n\nvac:zkvm::vac:research-existing-proof-systems\n\n40% update of the blog is done, working on finding smoother ways to explain findings and alternatives (focusing on a blog structure rather than a document)\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nAdded a summary table for different performances\n\n\nvac:zkvm::vac:research-existing-proof-systems\n\nFinished Plonky2 research document https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#01301b98f3af4157b932112ed998cff2\nWrite notes on Protostar\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nminor fixes plonky2 PR https://github.com/vacp2p/zk-explorations/pull/5\nREADME’s to make zk-explorations repo public https://github.com/vacp2p/zk-explorations/pull/4\nmerged and closed needed PRs for zk-explorations repo\nwork on Halo2 benchmark\n\n\n\nvc::Deep Research §\n\nvac:dr:valpriv:vac:tor-push-poc\n\ndev: fixed bugs related to initialization, changed to building async tor connections, adding direct peers, triaging/debugging issues https://github.com/vacp2p/nimbus-eth2-experimental/pull/2/commits/431a76014b3f584573329993b167fe1118eca6b3\ntest: readied setup o beacon node(s) with validator keys, test attestation transmission over tor. Planning for measuring delays\n\n\nvac:dr:valpriv:vac:tor-push-relwork\n\nsolution section refined with several updates including adding a figure for the Tor-push method.\ndedicated section on “Theoretical Analysis”\nfour different possible scenarios for the attacker to break the anonymity of the Tor network\n\n\nvac:dr:gsub-scaling:vac:gossipsub-improvements-tech-report\n\nLiterature study related to scalability, overlay design, efficient message propagation in unstructured p2p networks\nStarted writing a survey report on efficient broadcast in large scale p2p networks.\n\n\nvac:dr:gsub-scaling:vac:gossipsub-simulation\n\nExecuted different gossipsub simulations in shadow simulator\ncan now collect different metrics like packet delivery ratio, data overhead, control overhead, network bandwidth utilization, average latency & standard deviations\n\n\nvac:dr:consensus:nomos:carnot-bribery-article\nContinue work on the article on bribery attacks, PoS and Carnot. Different examples including one based on game theory were presented to show that bribery attacks are economic attacks and cannot be addressed alone in the consensus layer. Economy based solutions have to be considered at the PoS layer.\nvac:dr:consensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nBegin work on Carnot variant that aggregates the majority of votes.\nDesigning the algorithm.\n\n\nvac:dr:consensus:nomos:carnot-paper\n\nAnalyzing and discussing Carnot tests. There were variance in the latency results. We think it is due to the geographical distribution of nodes. Hence, Gusto was asked to use a single geographic zone to acheive a smooth curve while verifying that the variance is due to the latency cause by geographical distribution of nodes.\n\n\n\nvc::RFC §\n\nvac:rfc:rfc:status:port-status-specs\n\nUpdated RFC spec for Community History Archive protocol according to PR feedback\n\nhttps://github.com/vacp2p/rfc/pull/610\nThis has been reviewed more and those additional comments need to be addressed as well\n\n\n\n\nStarted porting /spec/6/PAYLOADS to Vac\n"},"vac/updates/2023-09-04":{"title":"2023-09-04 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2023/09/04 §\n\nVac Milestones\nVac Github Repos\n\nvac:p2p: §\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nOpened upstream discussion about gossipsub peer exchange (which is a DDoS vector) https://github.com/libp2p/specs/issues/570\n\n\nnimlibp2p:vac:webrtc-transport\n\nHitting roadblocks on DTLS\n\n\n\nvac:tke:: §\n\ncodex:economic-analysis\n\nPresenting Filecoin findings to Codex team\nLitepaper: assumptions on collateral\n\n\nstatus:SNT-staking\n\nHighlighted multiple design requirements not met by SC implementation for SC team notion doc\nOpen questions w/ John, epoch duration\nStaking governance proposal for when John returns Sep 12\n\n\nnomos:economic-analysis\n\nDelegated staking specifications w/Marcin, update for privacy constraints\nBribery attacks analysis, Moh asked to followup early/mid Sep\n\n\nwaku:economic-analysis\n\nFormalized RLN thoughts shared w/ Aaryamann, will push for additional feedback once Martin returns\n\n\n\nvac:dst: §\n\nanalysis:nomos:nomos-simulation-analysis\n\nTook over data generation on Tuesday\nFound a bug in simulations, working around it\nThe comparison runs are now fully automated\ngot the first full set of comparison plots: everything appears to be explainable for a fixed probability\nTree runs now scale to 15k nodes\n\n\nwakurtosis:vac:retrospective-rlog\n\nGather info and wrote summary of why we decided to stop using Kurtosis.\n\n\n10ksim:vac:10ksim-bandwidth-test\n\nCode diagrams + structurization\nChats with Ben (Codex)\n\n\nwakurtosis:nomos:ci-integration_02\n\n(hold for now, since we drop Kurtosis; will continue in November once we have the new 10k simulator tool)\n\n\nsoftware-testing:waku:test-plans\n\nAdded test plans for filter, lightpush and store: https://www.notion.so/Test-Plans-09c8c7b7f6784c459fb774792665e37c\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nMade it possible to choose the nwaku version in the js waku github actions workflow by using workflow_dispatch inputs. PR Link\n\n\n\nvac:sc:: §\n\nvac:secureum-upskilling\n\nNo progress; busy with CommunityTokenDeployer contract\n\n\nstatus:community-contracts-maintenance\n\nGas optimizations in token contracts\n\nCustom errors vs require string messages PR\nUsage of immutable properties PR\n\n\n\n\nstatus:community-contracts-deployer\n\nImplemented CommunityTokenDeployer\n\nIncludes tests and docs\nPull requests\nRan into a contract size issue; Context comment\n\n\nAdded docs for commuity token deployer contract\n\nPull Request\n\n\n\n\nstatus:governance-contract-mvp\n\nERC2470 ressurection\n\nUpdated to latest solidity\nImplemented error checking for “already deployed” (saves gas in case of user error)\nImplemented error checking for “successful deploy” (forces gas estimation to successful deploy scenario)\nIn progress upgrade on solidity compiler new outputs (from 0.5.11=>0.8.x)\n\n\nResearch on delegation vs staking contract\n\n\n\nvac:acz: §\n\nrlnp2p:waku:membership-management\n\nfixed makefile target for rln-keystore-generator - https://github.com/waku-org/nwaku/pull/1960\nlog the membership index out upon registration in the rln-keystore-generator - https://github.com/waku-org/nwaku/pull/1963\n\n\nrlnp2p:waku:rln-relay-enhancments\n\nrln was enabled by default in the Makefile - fixed - https://github.com/waku-org/nwaku/pull/1964\nordered pubsub validator execution - https://github.com/waku-org/nwaku/pull/1966\nfixed deserialization of valid merkle roots - https://github.com/waku-org/nwaku/pull/1973\nconfirm that the fetched credential from the keystore is registered to the membership set - https://github.com/waku-org/nwaku/pull/1980\nfixed makefile target for zerokit’s librln.a - https://github.com/waku-org/nwaku/pull/1981\nconverted zero-based indexing to 1-based indexing on vacp2p/rln-contract - https://github.com/vacp2p/rln-contract/pull/28\ndownstreamed zero-based indexing to waku-org/waku-rln-contract - https://github.com/waku-org/waku-rln-contract/pull/8 -\ndeployed new version of the registry contract on sepolia - 0xc04937d502E0ae671cedFC2A0BCD6692055520f3\n\n\nzerokit:vac:zerokit-v0.4\n\nMerged a PR to deal with message_id range check https://github.com/vacp2p/zerokit/pull/210\nresearched tree_size issue for the 0.4 release\nresearched idCommitment/rateCommitment issue for the 0.4 release\n\n\n\nvac:zkvm: §\n\nproofsystems:vac:research-existing-proof-systems\n\n[blog post] (https://vac.dev/rlog/Nescience-A-zkVM-leveraging-hiding-properties)\nResearched ways to achieve Goal2 and Goal3 for Nescience.\nIntegrated different techniques for Goal4 and Goal5 for Nescience.\nprepared Nova-implementation writeup (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#cce2cc365a384126b2a5041900bd3ce9)\nContinued Lasso research (https://a16zcrypto.com/posts/article/introducing-lasso-and-jolt/)\nNotes for Protogalaxy; 100%\nNotes for Protostar\n\n\nproofsystems:vac:proof-system-benchmarks\n\nAdded an introductory section for Benchmark in zk-explorations repo: https://github.com/vacp2p/zk-explorations/pull/10\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nCompleted literature study. Covered article related to overlay design (single tier, multi-tier, hybrid overlays)\npeer selection methodologies, rumor/gossiping protocols, push/pull based publishing approaches, message encoding, probablistic forwarding, overlay optimization, and peer heterogeneity/capacity based roles (super nodes and similar roles)\nStill need to review 1-2 D-regular graph based approaches. Only selected articles are added in zotero (under vacp2p)\n\n\nvalpriv:vac:tor-push-poc\n\nDebugged various appraoches(tcp, gossip, tor). Triaged why attestations not working\n\n\nvalpriv:vac:tor-push-relwork\n\ncompleted related work all\n\n\nconsensus:nomos:carnot-paper\n\nPublishing the Carnot paper (Done) https://arxiv.org/pdf/2308.16016.pdf\nBegin work on writing up Carnot’s specification in RFC format\n\n\nconsensus:nomos:carnot-bribery-article\n\nFinishing (describing research directions and their pros and cons, polishing the article) and publishing the article (Done) https://www.notion.so/WIP-Bribery-Attacks-in-Consensus-Protocols-Challenges-and-Solutions-e4e108c17dba421abe83de49076c8f25\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nCompleting the initial design and work on presentation slides. The plan will be to present the initial design on September 6 research call\n\n\n\nvac:rfc:rfc: §\n\nstatus:port-status-specs\n\nStarted porting 6/PAYLOAD to vac RFCs\n\nWork-in-progress PR is pending here\nThis RFC specifically needs a lot of work as it misses a lot of the current payload types\n\n\nUpdated 61/STATUS-community-history-archives according to feedback comments and landed it\n\nMerged PR is here\n\n\nstarted porting 16/keycard-usage to Vac (looking into status-go)\n\n\n"},"vac/updates/2023-09-11":{"title":"2023-09-11 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnim-libp2p:vac:maintenance:\n\nIWANT splitting now ready for review\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nTraffic scoring now ready for review\nPursuing upstream discussions about gossipsub Peer Exchange\n\n\nnim-chronos:vac:maintenance:\n\nContinued https://github.com/status-im/nim-chronos/pull/418\n\n\n\nvac:tke: §\n\nvac:tke::status:SNT-staking\n\nWrite first draft of staking governance proposal\nstandby to hear SC team questions\n\n\nvac:tke::nomos:economic-analysis\n\nAnalysis of rewards for delegation vs validation\n\n\n\nvac:dst: §\n\nwakurtosis:vac:rlog\n\nAddress PR feedback (https://github.com/vacp2p/vac.dev/pull/123)\n\n\nwakurtosis:waku:techreport_03\n\nbatch of simulation data with 0 msg/s rate.\n\n\nwakurtosis:vac:retrospective-rlog\n\nStarted draft/planning of document\n\n\neng-10ktool:vac:bandwidth-test\n\nWorking on adding an intermediate layer between services (Codex) and framework.\n\n\nwakurtosis:waku:techreport_02\nsoftware-testing:waku:test-plans\n\nMinor tweaks/updates on the filter test plan\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nCreated draft PR with ~60 new tests + refactoring for Filter protocol (https://github.com/waku-org/js-waku/pull/1552)\nWorked with Vaclav to run js-waku tests automatically in the nwaku CI.\n\nTests will run against the nwaku node built for the PR that triggers the CI + jswaku from master (nwaku PR: https://github.com/waku-org/nwaku/pull/2006) (js-waku PR: https://github.com/waku-org/js-waku/pull/1541)\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nGet acquainted with codebase, tests, rfcs, and nim.\nstart implementing first set of tests (Filter/SUBSCRIBER_PING).\n\n\nvac:dst:analysis:nomos:nomos-simulation-analysis\n\nDone first set of runs for different probabilities; a run takes 2+ days\nThe tree simulation now scales to 30k nodes!\nBranch runs are now fully automated\n\n\nvac:dst:wakurtosis:waku:topology-analysis\n\ntried json RPC under shadow (worked as expected); the RPC appears a bit faster compared to wakurtosis\nWaku network collection PR done : https://github.com/vacp2p/wakurtosis/pull/143\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\nif only one key exists in the keystore, use it - https://github.com/waku-org/nwaku/pull/1984\nfix log levels for some logs - https://github.com/waku-org/nwaku/pull/1986\nupdated documentation for rln-relay - https://github.com/waku-org/nwaku/pull/1993\nclean nullifier table every MaxEpochGap - https://github.com/waku-org/nwaku/pull/1994\ncreated rln_db_inspector tool, allows inspection into merkle tree structure - https://github.com/waku-org/nwaku/pull/1999, https://github.com/waku-org/nwaku/pull/2012\nfixed missing memberships between history sync and new memberships sync with @alrevuelta - https://github.com/waku-org/nwaku/pull/2015\nremove rln from waku’s experimental features - https://github.com/waku-org/nwaku/pull/2001\nfix metric calculation for registered members - https://github.com/waku-org/nwaku/pull/2018\nuups proxy for waku-rln-registry - https://github.com/waku-org/waku-rln-contract/pull/9\n\n\nzerokit:vac:zerokit-v0.4\n\nfetched artifacts from trusted setup completion, generated verfication keys and circuit’s wasm files\nfor some reason, the proof verification always results in false, needs further investigation. working branch - https://github.com/vacp2p/zerokit/pull/211\nCreated and merged a PR to fix test failings https://github.com/vacp2p/zerokit/pull/212\nReaserched test failures with new artifacts\n\n\n\nvac:sc: §\n\nstatus:snt-staking-contract-maintenance\n\nPrepared a pull request that migrates the code base to our foundry template: Pull Request #6\n\n\nstatus:community-contracts-deployer\n\nRefactored CommunityTokenDeployer contract to make use of token factory contracts: Pull Request #2\nUpdated documentation and visuals according to code changes: Pull Request #4\n\n\nvac:maintainance/misc\n\nAdded support for codecoverage analysis in our foundry template: PR: https://github.com/vacp2p/foundry-template/pull/6\nAdded basic deployment config to our template: PR: https://github.com/vacp2p/foundry-template/pull/5\nAdded slither support: PR: https://github.com/vacp2p/foundry-template/pull/4\nadded a new resource to the Smart Contract notion section about gas optimizations\n\n\n\nvac:zkvm: §\n\nproofsystems:vac:research-existing-proof-systems\n\nAddressed some questions regarding Nescience.\nWorked on compressing informations in Nescience for a future publication.\nContinued research on Jolt\nContinued writing a paper on Lasso (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#025f586e7e4c46818a0e0a1ab9a79c20)\nAttended webinars for Open Talk: Zero Knowledge (recorded talks)\nUpdate Halo2 notes\n\n\nproofsystems:vac:benchmarks\n\nPublished a complete section on Github regarding Benchmarks (https://github.com/vacp2p/zk-explorations/blob/main/benchmarks.md).\nwork on Halo2 benchmark implementation\nNova Circom: done, Nova-Scotia: there is a part left\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nCompleted the tor based gossipsub instance broadcas; the first working POC. Overcame, triaged several issues https://github.com/vacp2p/nimbus-eth2-experimental/issues/1\n\nfirst running tor-push nimbus validator\n\n\n\n\nvalpriv:vac:tor-push-paper\n\nchanges to introduction, solution section, removed not in scope papers\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on adding staggered sending suppoort in Gossipsub (still working on it)\nFormalized and improved simulation scripts for GossipSub behavior against large messages.\n\n\nconsensus:nomos:carnot-paper\n\nWork on writing up Carnot’s specification in RFC format (https://github.com/logos-co/nomos-specs/blob/RFC/carnot/spec.md)\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWork on presentation slides for Sep. 6 research call. (slides can be found at: https://www.notion.so/Roadmap-Deep-Research-DR-561a864c890549c3861bf52ab979d7ab?pvs=4#d1d3033792b443f39e47955721f9db52)\nBegin to write down the high level protocol.(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n\nvc::rfc: §\n\nstatus:port-status-specs\n\nKicked off discussion with “stakeholders” about 6/PAYLOAD spec and how it should be ported/maintained\nstarted porting parts of 6/PAYLOAD\nPorted 16/keycard-usage to 63/status-keycard-usage - https://github.com/vacp2p/rfc/pull/615\n\n\n"},"vac/updates/2023-09-18":{"title":"2023-09-18 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnim-libp2p:vac:maintenance:\n\nFixed gossipsub Direct Peers\nContinued cross-libp2p perf implementation\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nOpen eth specs issue about disabling gossipsub Peer Exchange\n\n\nnimlibp2p:vac:webrtc-transport\n\nFixed the blocking DTLS issue, continuing vertical implementation\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nReview litepaper feedback w/ Codex and identify steps to finalize Codex tokenomics\n\n\nvac:tke::status:SNT-staking\n\nReview staking governance proposal w/John in Status call\n\n\nvac:tke::nomos:economic-analysis\n\nAnalysis of rewards for delegation vs validation\nResearching ETH 2.0 emission decision rationales\n\n\n\nvac:dst: §\n\nwakurtosis:waku:techreport_03 & wakurtosis:vac:rlog\n\nAnalysis of the non-load simulations (0msgs to isolate discv5 effects)\nRecaculated efficiencies taking into account message counts instead of expectation\nGenerated new efficiency plots; Re-written discussion to account for the latter\n\n\neng-10ktool:vac:bandwidth-test\n\nCreated new repo for Python tool (https://github.com/vacp2p/10ksim)\nKubernetes configuration and documentation (https://github.com/vacp2p/10ksim/issues/1)\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAddressed comments and merged the Filter protocol tests PR (https://github.com/waku-org/js-waku/pull/1552)\nCreated new PR with ~40 new lightpush tests (https://github.com/waku-org/js-waku/pull/1571)\nExtract the testing parts of js-waku CI into reusable workflows that can be easily called cross-repo (https://github.com/waku-org/js-waku/pull/1566)\nImproved the retry-on-fail mechanism of the js-waku tests (https://github.com/waku-org/js-waku/pull/1573)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nFinished implementing waku filter ping tests; PR\nImplemented waku filter subscribe tests; Found first two wrong/unclear behaviours due to tests; PR 1; PR 2\nChecking existing tests and removing legacy/duplicated.\nBegan implementing waku filter client error tests\n\n\n\nvac:acz: §\n\nzerokit:vac:zerokit-v0.4\n\nPrepared a PR to fix test_recover_id_secret test due to incorrect serialization https://github.com/vacp2p/zerokit/pull/217\nFixed serialization in other tests\n\n\nsecure-channels:waku:ethereum-chat\n\nGetting familiar with some of the protocols, namely: X3DH, Double Ratchet, XEdDSA and Noise.\nStart defining the requirements of the secure chat protocol.\n\n\nrlnp2p:waku:rln-relay-enhancments\n\nupdated submodule, fixed metric - https://github.com/waku-org/nwaku/pull/2024\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nupdated nwaku pre-requisites docs for rln - https://github.com/waku-org/docs.waku.org/pull/115\n\n\nzerokit:vac:maintenance\n\nexposed leaves_set api to count the number of insertions into the tree - https://github.com/vacp2p/zerokit/pull/213\noptimized the batch insert to reduce insertion times - https://github.com/vacp2p/zerokit/pull/215\n\n\nzerokit:vac:zerokit-v0.4\n\nstill continuing to investigate proof verification failures. headway made, the root that the proof has is != the tree root produced by zerokit.\n\n\n\nvac:sc:: §\n\nstatus:SNT-optimism-bridge\n\nWorkin on porting legacy MiniMe token to our foundry template\n\nAlso update its code and tests; Ultimately this becomes a dependency of other projects (staking, governance etc)\n\n\nUpdated to solidity 0.8.19\nFixed linting 1 , 2\nUpgraded error-strings to error-codes\nStarted fixing auditor errors: variables->immutables, uint128 castings, check-effects-interactions\nother minor improvements (erc20, separate contracts)\n\n\nvac:misc:\n\nVisited blockchain week in Berlin\n\n\n\nvac:zkvm: §\n\nproofsystems:vac:research-existing-proof-systems\n\nWorked on the motivation of Goal 1: Why separate state is more beneficial (Document next week)\nStarted a somehow scientific article format for Nescience\nFinished a writeup on Lasso https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#e563de6778b04479a7936e2c5664c9ec\nStarted writing a writeup on Jolt\nUpdate Logos slides for presentation on 9/20. (link pending)\nBegin research recproof\n\n\nproofsystems:vac:benchmarks\n\nFinished Nova benchmark that uses Nova-Scotia https://github.com/vacp2p/zk-explorations/pull/13\nStarted working on Nova benchmark that uses bellman (original/default way to do things in Nova)\nWorked on Halo2 benchmarks\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nExtraced latency of attestations sent from gossip_sub debug level logs\nCollected around 150 or more latencies of attestations, both for normal and tor switch\nValidated tor-circuit formation on validator machine\n\n\nvalpriv:vac:tor-push-paper\n\nRevised the structure of paper, added mathematical definition\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nThe first draft of survey is ready for review\n\n\ngossipsub-improvements-paper\n\nIncorporated changes to the first draft of the improvement paper. Still a work in process.\n-consensus:nomos:carnot-vote-2-3rds-vote-aggregation\nWriting the psuedocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdded discussion and committee merging algorithm to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\ncontinued discussion of the PAYLOAD RFC; continue working on updating the RFC\n\n\n"},"vac/updates/2023-09-25":{"title":"2023-09-25 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nMerged GossipSub Traffic Scoring https://github.com/status-im/nim-libp2p/pull/920\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nContinued simulations\n\n\nnim-libp2p:vac:maintenance\n\nTried to integrate HP in nwaku, but rendezvous isn’t integrated yet\n\n\nnimlibp2p:vac:webrtc-transport\n\nContinued vertical integration of protocols\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nMeeting with Codex on Tuesday, get in sync on timeline and steps for final delivery\n\n\nvac:tke::status:SNT-staking\n\nReview goverance process itself, governance proposal template, staking gov proposal w/ John\n\n\nvac:tke::nomos:economic-analysis\n\nAnalysis of rewards for delegation vs validation\nAlvaro shared further docs to review on Private Addressing incentives and two-tiered staking\n\n\nvac:tke::waku:economic-analysis\n\nReading WAKU papers and onboarding Sergei, establishing recurring cadence\n\n\n\nvac:dst: §\n\nwakurtosis:waku:techreport_03\n\nDelivered (pending discussion with Waku team)\n\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nRun 20K simulation (resources test)\n\n\neng-10ktool:vac:bandwidth-test\n\nCheck with Slava K8s configuration, to run nodes in master aswell (K3s)\nCode first multi-node deployment\nDockerized DST node\n\n\nsoftware-testing:waku:test-plans\n\nStarted working at the Relay test plan\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAddressed all comments from last week PRs and merged them\nFixed the nwaku CI part that invokes js-waku: https://github.com/waku-org/nwaku/pull/2061\nBumped nwaku version in js-waku CI: https://github.com/waku-org/js-waku/pull/1591\nHelped investigating nwaku issues caught by the js-waku tests\nInvestigated some flaky tests and tried to fix them: https://github.com/waku-org/js-waku/pull/1592\nStarted working on adding new tests for the static sharding functionality for js-waku\nAdded a bug report found during testing and a feature request for test reporting\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nImplement service to service waku filter tests: PR\nImplement coverage for nwaku: PR\nRebase all test branches from master, fixing numerous git mishaps.\nUpdate PRs with comments.\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\nfixed a segfault issue - https://github.com/waku-org/nwaku/pull/2047\n\n\nzerokit:vac:zerokit-v0.4\n\nstill investigating the proof verification failures using the new artifacts. can confirm that the inputs for proof generation are valid, and are verified by using snarkjs.\n\n\nRemoved private message_id from compute_id_secret agruments\n\nFix RLNProofValues\n\n\nsecure-channels:waku:ethereum-chat\n\nWiP Notion doc on the specifications of the protocol\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-deployer\n\nMerged all pending PRs. This milestone is now done\nDeployed a version of token deployer contracts to optimism goerli\n\n\nstatus:community-curation-contracts\n\nDiscussed and started implementing necessary changes for beta release\n\nFoundry deployment script\nbatch processing of votes in finalization phase\n\n\n\n\nstatus:SNT-optimism-bridge\n\nSync call with Certora on audit report and next audit planning\ncreated tests for onTransfer reentrancy case https://github.com/vacp2p/minime/pull/29\n\nfixed reentrancy https://github.com/vacp2p/minime/pull/24\n\n\nrised coverage from 54.62% to 67.23% https://github.com/vacp2p/minime/pull/33\nAlter Minime to allow being extended to specialized tokens (such as OptimismMintableERC20) https://github.com/vacp2p/minime/pull/32\ncreate script for detailed gas-report https://github.com/vacp2p/minime/pull/25\nlocally optimized gas usage\n\n\n\nvac:zkvm: §\n\n\nproofsystems:vac:research-existing-proof-systems\n\nWritten a document for State Separation motivation for Nescience\nReadings to justify Goal 3\nConsidered some scientific paper format for Nescience\nWorked on Jolt writeup draft (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#fae64ac478004b749f7b211a9542f2d2)\nStarted research on Poseidon paper (https://eprint.iacr.org/2019/458.pdf) and is implementations\nLogos research call presentation.\nNotes on Recproof (WIP) and zkTree (same document).\nNotes on Poseidon2 (WIP)\n\n\n\nproofsystems:vac:benchmarks\n\nAdded an explanation for Plonky2 circuit [To add to GitHub]\nStarted reading Nova circuit to provide an explanation of what the circuit is doing\nfinish up Nova bellman benchmark https://github.com/vacp2p/zk-explorations/pull/14\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nInvestigated the issue with failing attestation, Fixed the exclusion of connected peer\nDebugged the latency script evaluation/ Recalculated stats.\n\n\nvalpriv:vac:tor-push-paper\n\nUpdated the structure of the paper and added tentative contributions to the paper.\nAdded sections on latency and security analysis in the results section along with the potential limitations of the proposed method.\n\n\ngossipsub-improvements-paper\n\nResearch log post for GossipSub improvements is ready for review\nIncorporated changes to the Introduction, and Related work. Results part is still a work in process.\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the pseudocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdding discussion to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n:nomos:review\n\nReviewing https://www.notion.so/Data-Availability-Specification-c3961b681eba4ccdab2be9181e4207b4#3df2088e8a9b4c048310e51ff8e577a8\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nporting 2/ACCOUNTS to vac rfcs (RFC 65); in review process\n63/STATUS-Keycard-Usage merged https://rfc.vac.dev/spec/63/\n\n\n"},"vac/updates/2023-10-02":{"title":"2023-10-02 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnim-chronos:vac:maintenance\n\nOpened alternative fix for closure completion issue\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nContinued simulations\n\n\nnimlibp2p:vac:webrtc-transport\n\nContinued vertical integration of protocols\n\n\nnim-libp2p:vac:maintenance\n\nMerged gossipsub IWANT fix\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nCodex pushed meeting back again, reviewing this week to get in sync on timeline and steps for final delivery\n\n\nvac:tke::status:SNT-staking\n\nJohn has reviewed goverance process itself, governance proposal template, staking gov proposal, finalize details with him this week\nComplete anonymous user matching proposal draft\nStill some differences between design and implementation in SC, Martin working on these items in order to hand off\n- Rewards should not be claim order dependent\n- Restaking mechanism, same vault vs create new vault\n- Rewards can be claimed retroactively vs GMX style model of needing to claim in real-time\n\n\nvac:tke::nomos:economic-analysis\n\nFrederico in regular communication with Alvaro, continuing on Private Addressing research\n\n\nvac:tke::waku:economic-analysis\n\nMartin follow up with Sergei on collaboration ideas and feedback on WAKU so far\n\n\n\nvac:dst: §\n\nwakurtosis:vac:retrospective-rlog\n\nDelivered for first round of reviews (https://github.com/vacp2p/vac.dev/pull/131)\n\n\nwakurtosis:vac:rlog\n\nTaken care of review comments, still issues with results (injection loss)\n\n\neng-10ktool:vac:bandwidth-test\n\nChanged dst-node code to fit a K8s environment\nPut dst-node in dockerhub\nRun as many nodes as possible on two machines with plain Kubernetes\n\n\nsoftware-testing:waku:test-plans\n\nFinished the Relay test plan: https://www.notion.so/Relay-c91b6df8d96a4527b5d2d599bf8dd54e\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAdded new tests for static sharding feature (phase 1) to cover filter, lighPush, store and relay protocol. Also changed existing methods and tests to support multiple pubSubTopics. Awaiting review: https://github.com/waku-org/js-waku/pull/1624\nStarted refactoring and adding new tests for store protocol. Draft PR: https://github.com/waku-org/js-waku/pull/1627\nHelped investigating a change in nwaku that caused issues in the js-waku lightPush tests\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nMerge coverage https://github.com/waku-org/nwaku/pull/2067\nUpdate open Filter PRs\nImplement waku filter tests (Unsubscribe, payloads, security and privacy)\n\nUnsubscribe PR\nUnsubscribe All, Payloads, and Privacy and Security PR\nNode Privacy and Security PR\n\n\nImplement returning error on “unsubscribing from non-subscribed server” (Change inside Unsubscribe PR)\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nRan Go’s coverage report to see about unit tests\nBuilt and played with Waku v2 Filter example, docker image locally\nWrote Dockerfile and test container image build workflow\ngo-waku’s test docker registry @quay.io is in preparation with jakubgs\n\n\n\nvac:acz: §\n\nzerokit:vac:zerokit-v0.4\n\nunblocked rln-v2 proof verification, pending rln-wasm bug fix\n\n\nsecure-channels:waku:ethereum-chat\n\nCompleted a first version of the WiP including an extension to group chats.\nCompleted a first approach to using Noise nomenclature for X3DH and the DH ratchet in the double ratchet.\nStudied how to approach Signal’s PQXDH in terms of Noise.\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-deployer\n\nCode clean up https://github.com/status-im/communities-contracts/pull/17\nCustom token events https://github.com/status-im/communities-contracts/pull/18\n\n\nstatus:community-curation-contracts\n\nFinish moving to foundry template https://github.com/status-im/community-dapp/pull/69\nAdd foundry deployment script https://github.com/status-im/community-dapp/pull/70\nIntroduce evaluation limit and use minime token https://github.com/status-im/community-dapp/pull/72\nSmaller additional PRs\n\nRemove safeMath/save gas https://github.com/status-im/community-dapp/pull/71\nUse OZs Ownable https://github.com/status-im/community-dapp/pull/73\nProduction parameters https://github.com/status-im/community-dapp/pull/74\n\n\n\n\nstatus:SNT-optimism-bridge\n\nMove repository to foundry template\nAdd modern minime as dependency https://github.com/logos-co/optimism-bridge-snt/pull/9\n\n\nstatus:community-contracts-ERC20\n\nAdded Owners and Master tokens to Community ERC20 contract\n\n\nstatus:SNT-optimism-bridge\n\nreport for certora\nimplement ERC2612\nimprove code and gas cost\ncoverage to almost 100%\nimprove abstraction of MiniMeBase\nwork on SNTPlaceHolder issues\n\nadd claimTokens\nremove safemath\n\n\n\n\n\nvac:zkvm: §\n\nproofsystems:vac:research-existing-proof-systems\n\nWritten a document for Proof Creation and Verification (Goal 3 for Nescience) - WIP 70%\nStarted a first draft for research article for Nescience\nStarted readings on bulding secure zkVMs\nResearched on Poseidon paper (https://eprint.iacr.org/2019/458.pdf) and is implementations\nFinished Jolt writeup (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#43de765557544ec59efa038a2d39c98b)\n\n\nproofsystems:vac:benchmarks\n\nadded ducumentation to plonky2 code (https://github.com/vacp2p/zk-explorations/pull/15)\nWork on Halo2-benchmark\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nReducing attestation miss rate, separating peerpool/conn table for torswitch\n\n\nvalpriv:vac:tor-push-paper\n\npaper updated\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nIncorporated suggested changes GossipSub improvements research log post (https://github.com/vacp2p/vac.dev/pull/130). Currently doing proofreads, and readjusting citations.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nPull request created for GossipSub shadow simulation.\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the psuedocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdding discussion to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n:nomos:review\n\nReviewing https://www.notion.so/Data-Availability-Specification-c3961b681eba4ccdab2be9181e4207b4#3df2088e8a9b4c048310e51ff8e577a8\n\n\nzk:codex:storage-proofs-open-problems-review\n\nsync with Codex on the issues\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nclean up 65/status-accounts spec, draft of test vectors which were omitted\nContinue and finish porting a version of the PAYLOADS spec https://github.com/vacp2p/rfc/pull/612\n\n\n"},"vac/updates/2023-10-09":{"title":"2023-10-09 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nContinued vertical integration of protocols\nStarted DataChannel implementation (last protocol in the stack)\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation:\n\nMerged last part of the ddos mitigation. End of this milestone, next step is to enable in nimbus\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nCodex meeting confirmed for Tuesday, reviewing this week to get in sync on timeline and steps for final delivery (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nDiscuss anonymous user matching proposal with John (@Matty)\nComplete all edits of all 3 proposals based on John’s feedback (@Matty)\nImprovements to smart contract implementation (claim order dependency), and refactoring, actively working with SC team (@Martin)\nFinance (Matt Nemer and Adam) asked for refresh of the economic model/projections this month (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nFrederico remains in regular communication with Alvaro and Marcin, continuing on Private Addressing research (@Frederico)\n\n\n\nvac:dst: §\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nBandwidth analysis with ‘plot-shadow’ (https://github.com/shadow/shadow/blob/main/src/tools/plot-shadow.py)\nTemporal graph extraction / analysis of gossipsub node\n\n\nwakurtosis:vac:rlog\n\nRunning new batch of simulations\n\n\nanalysis:nomos:simulation-analysis\n\nwork on additional set of analysis and ways to resolve the tree/branch discrepancy; analysis/data collection is priority\nAdding “realistic” network delays to the simulations is an immense memory hog and DST machine crashed repatedly for days together;\n\nspecial thanks for Jakub for promptly resetting the machine, but it still took days to figure usable parameters\n\n\nTook all week and weekend to get just one run for 10k nodes\n\n\nwakurtosis:waku:gossipsub-topology-analysis\n\nThe CollectNet PR (https://github.com/vacp2p/wakurtosis/pull/143)\n\n\neng-10ktool:vac:bandwidth-test\n\nK8s configurations https://github.com/vacp2p/10ksim/issues/1\nPOD limites per node (point 4)\n\nAvailable IPs per node (point 4)\nParallelize StatefulSets (point 5)\nSet second machine as Schedulable\n\n\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nFinished adding new tests for store protocol.\n\nIncreased coverage from 9 tests to ~60.\nDiscovered several issues/discrepancies that I’ve raised with the Waku teams.\n\n\nAdded small fix for some flaky tests\nUpdated docker hub org from where the tests fetch nwaku/gowaku images\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nBegin Relay subscribe tests\n\nMessage id (https://github.com/waku-org/nwaku/pull/2101)\nSubscribe WIP (No PR yet)\n\n\nInvestigate possible missbehaviours, diving into libp2p code.\nOpen relay subscription bug issue: https://github.com/waku-org/nwaku/issues/2114\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nGo-waku’s test docker registry @quay.io is working well\nDockerfile and test container image build workflow tested & merged https://github.com/waku-org/go-waku/pull/792\nWrote first test and found first bug - fixed by devs already https://github.com/waku-org/go-waku/commit/d900a6c81457cdb9bd264867d61064fc923a4d30 https://github.com/waku-org/go-waku/pull/794\n\n\n\nvac:acz: §\n\nzerokit:vac:zerokit-v0.4\n\nMerged PR https://github.com/vacp2p/zerokit/pull/217\nFixed ffi tests\ncompleted release, milestone complete - https://github.com/vacp2p/zerokit/releases/tag/v0.4.1\n\n\nrlnp2p:waku:multi-epoch-constraint\n\nStart working on a more concise solution for the problem\n\n\nsecure-channels:waku:ethereum-chat\n\nIncrease the level of detail in the description of the WiP towards the creation of an RFC\n\n\n\nvac:sc:: §\n\nstatus:SNT-optimism-bridge\n\nUpdate bridge repo to latest vacp2p/minime dependency\nImplemented foundry deploy script\nCustom errors over string messages\nToken controller rename\n\n\nstatus:community-contracts-ERC20\n\nHelped with adding owner/token-master access control\n\n\nstatus:community-curation-contracts\n\nDeployed contracts on goerli\n\n\nstatus:community-contracts-maintenance\n\nLanded custom minting events\nupdate the erc20 contract to have owner/master tokens\nadded CommunityOwnable contract with base auth\nFix and update failing tests and deploy erc20 implementation to testnet\nPR: https://github.com/status-im/communities-contracts/pull/19\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nResearching techniques for state separation\nStarted a new document about how to implement state separation\n\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished the document about [Proof Creation and Verification] (Goal 3 for Nescience) - To share soon\nStill doing some research on how to make Nescience compact for an article\nSeveral readings on bulding secure zkVMs\nPrepared a draft on Starky (https://www.notion.so/zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#4e5bc7f510c042609139bffd5534e69b)\n\n\nproofsystems:vac:benchmarks\n\nAdded an explanation for Nova-Scotia circuit\nPrepared poseidon-starky circuit generation part\nBegin code review for Nova benchmark\nContinue working on Halo2 benchmark\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nSeparating tor context from normal and implemented new PR\nFor over 4 days, monitored attestation success with near zero attestation drop rate, effectiveness varies\nwith opt incl distance, but automatically recovers to 86% on average\n\n\nvalpriv:vac:tor-push-paper\n\nmore updates to the paper\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\npushed the recommended changes for GossipSub improvement blogpost for approval\nstudied different proximity estimation, bandwidth estimation techniques for GossipSub improvements\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nUpgraded my system to execute relatively larger networks. Executed relatively larger simulations (upto 9000 nodes) to analyze the impact of D on message spread and the number of messages.\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the psuedocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdding discussion to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\nzk:codex:storage-proofs-open-problems-review\n\nGetting up to speed on Codex documents: Balazs’ sampling\nshared minor math error in Discord, Codex’s EC requirements, Preventing data loss, Block placement, Compact Proofs of Retrievability, Codex storage proofs rationale\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nmerged rfc 65\nreviewed waku-usage rfc, unclear if the old rfc can be ported as it is no longer relevant\nPAYLOADs almost done, addressing review comments\n\n\n"},"vac/updates/2023-10-16":{"title":"2023-10-16 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nStarted to implement DataChannel in WebRTC: https://github.com/status-im/nim-webrtc/pull/4\nStarted to implement the WebRTC transport in libp2p: https://github.com/status-im/nim-libp2p/pull/\nrework of UDP / Stun / Dtls / Sctp https://github.com/status-im/nim-webrtc/pull/\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nhttps://github.com/libp2p/jvm-libp2p/pull/336\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nMet w/ Codex and reviewed the marketplace workflows, identified many updates for litepaper (@Matty)\nWill update litepaper incorporating feedback, and update Codex modeling, reconnect after their offsite\n\n\nvac:tke::status:SNT-staking\n\nUpdate notion docs with links to all latest governance proposals\nAssigning issues in Github to SC team, and submit pull reqs, primarily on dependency the claims, and how restaking works (@Martin)\nContinuing revamp of economic model/projections, review early approach w/John (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nFrederico remains in regular communication with Alvaro and Marcin, continuing on Private Addressing research (@Frederico)\nReviewing similar challenges ETH is also considering, changes to economic model for adding native delegation\n\n\nvac:tke::waku:economic-analysis\n\nHad a call with Aaryamann and Sergei last week, they had followup questions on fleshing out pros/cons of various design approaches to RLN stake (@Martin)\n\n\n\nvac:dst: §\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nFixed timestamp bug\nUpdated traffic injection to continuous operation\nCreated IPFS mesh slices of arbitrary time length\n\n\nanalysis:nomos:simulation-analysis\n\nFinally zero’d in on the tree/branch bug. The pre and post-analysis are fine, the bug is in the Carnot sim.\nThe view installation time distribution with network delays is now done\n\n\ndr-support:vac:carnot-2-3rds-python-impl\n\ninvestigate Carnot sim code\n\n\neng-10ktool:vac:bandwidth-test\n\nFinish exporting metrics (delayed)\nMake sure new CIDR configuration supports 10k PODs\n\n\nwakurtosis:vac:rlog\n\nfinish simulations\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nNew tests:\n\nRelay[WIP]\n\n\nImprovements:\n\nSpeed up execution from 12m to 3.5m for 250 tests through parallelization(Significant refactoring needed to achieve this)\nFollow up fix to only allow paralellization in CI env\n\n\nFixes:\n\nUpdated tests after gowaku store fixes\nUpdated tests after remote peer rejected error\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nRelay and message id tests\n\nPR\n\n\nMerge filter subscribe PRs; Pending unsubscribe, missing one review.\nHeavily investigate issues shown on tests\n\nMax 1MB message size, no graceful handle.\nAfter stopping and restarting a relay node, can’t reconnect it with connectRelay.\nCan’t stop a relay node and send a message: Inconsistent with filter push behaviour.\nPublishing multiple messages in a row triggers the same SEGFAULT as when refreshing a subscription.\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote five tests - were added to the branch https://github.com/waku-org/go-waku/tree/chore(filterV2)-test-updates\nReported issue “Messages won’t get through with multiple pubsub topics” https://github.com/waku-org/go-waku/issues/804\nTracking coverage as notes so far -> will change to tabular form. Notion has API, we could possibly update docs during test execution? https://www.notion.so/Filter-Test-Coverage-42fc15b503ec4621980a7757d85089db?pvs=4\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\nworked on the rln rlog - https://github.com/vacp2p/vac.dev/pull/132\n\n\nmisc\n\nexplored next iteration of rln, which includes message sizes within the proof\n\n\nrlnp2p:waku:multi-epoch-constraint\n\nKeep working on a solution for the problem. (https://www.notion.so/WiP-Multi-epoch-Constraints-a5b648b98c46461187563d6c1e094468)\n\n\nsecure-channels:waku:ethereum-chat\n\nKeep improving the level of detail in the description of the WiP towards the creation of an RFC. (https://www.notion.so/WiP-Secure-Ethereum-Chat-f69ff155456c4fdeb719aba96fd7a8ab)\n\n\n\nvac:sc:: §\n\nstatus:snt-staking-contract-maintenance\n\nAdded additional tests\n\nhttps://github.com/logos-co/staking/pull/27\nhttps://github.com/logos-co/staking/pull/36\n\n\nUse custom errors over error strings\n\nhttps://github.com/logos-co/staking/pull/28\nhttps://github.com/logos-co/staking/pull/29\nhttps://github.com/logos-co/staking/pull/30\nhttps://github.com/logos-co/staking/pull/35\n\n\nSome cleanup\n\nhttps://github.com/logos-co/staking/pull/26\nhttps://github.com/logos-co/staking/pull/25\n\n\nIntroduced VaultFactory\n\nhttps://github.com/logos-co/staking/pull/38\n\n\n\n\nstatus:community-contracts-maintenance\n\nDeployed community token deployer contracts to Sepolia\n\nhttps://github.com/status-im/communities-contracts/pull/20\n\n\n\n\ncodex:review-codex-contracts\n\nDid a first quick review of the code, notes can be found here\n\nhttps://www.notion.so/Codex-Marketplace-Contracts-337a2e38fa574a2d8ffb589f4f599\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nFinished and shared a new document about state separation techniques\nKeep researching and adding updates\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStill working on Proof Creation and Verification (Goal 3 for Nescience), specifically trying to identify novel techniques\nConsidering article for Nescience\nContinuous readings on bulding secure zkVMs\ndiscussion on Sona proof system (from Lasso paper) and alternatives (Hyrax, KZG, FRI)\nReserched the connection between plonky2 and starky\n\n\nproofsystems:vac:benchmarks\n\nStarting a draft for an article (overleaf)\nworking on Halo2 benchmark\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nGetting fleet nimbus node measurements.\nFor PR, over 11 days, monitored attestation success with near zero attestation drop rate, effectiveness 89%\nInvestigating why opt. incl distance degrades occassionally\n\n\nvalpriv:vac:tor-push-paper\n\nAdded changes in https://www.overleaf.com/project/6499e467346d9f56b2971ca\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nDigged deeper into the gossipsub implementation in nim-lib-p2p.\nModified handling of large messages in the existing implementation. Modified message relaying behavior\n\nWe relay the large messages to only d_low peers and other peer are sent an IDONTWANT message.\nUnreceived large messages are requested using IWANT message.\nWe save approximately 40% bandwidth, on cost of approximately 2 RTTs to the opverall message latency\n\n\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the psuedocode (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\nAdding discussion to the high level protocol document(https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd)\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nreviewed waku usage of status, draft of rfc\n\n\n"},"vac/updates/2023-10-23":{"title":"2023-10-23 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nadmin\n\nrestructure\n\n\nnimlibp2p:vac:maintenance\n\nFind a fix for https://github.com/waku-org/nwaku/issues/2140\nPR: Test: Remove workflow for Nim Devel from "Daily" https://github.com/status-im/nim-libp2p/pull/968\n\nnim devel test will still be run daily, but in a separate CI workflow\n\n\n\n\nnimlibp2p:vac:webrtc-transport\n\nSuccessfully compile the full stack and start debugging.\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nhttps://github.com/status-im/nim-libp2p/pull/965\n\n\nnimlibp2p:vac:maintenance\n\nAdd arm64 support when running HP tests locally\nhttps://github.com/libp2p/test-plans/pull/311 and https://github.com/libp2p/rust-libp2p/pull/4687. (This is a blocker for: Add Hole Punching to libp2p test-plans - https://github.com/status-im/nim-libp2p/issues)\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nUpdating Codex “growth model” and migrating litepaper to notion w/ Codex feedback (@Matty)\nProviding fundraise (Matt Nemer) w/ high level summary of financials and token design (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nHelping John with final preparation for website launch, setting up Snapshot space (@Martin)\nOngoing w/ SC team for staking contract implementation (@Martin)\nDiscussed “growth model” (economic projections) w/ John, Chandler, and finance, aligning w/ Chandlers model (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nFinished drafting high level proposals on Private Addressing research, reviewing w/ Marcin (@Frederico)\nReturning to native delegated staking research, based on recent developments in ETH and Lido (@Fredico)\n\n\nvac:tke::waku:economic-analysis\n\nJoining Waku Reseach Sync calls going forward to stay up to date on progress w/ Sergei (@Martin)\nReviewing Sergei’s notes so far on waku-org/research, and completing followup requests from Aaryaman and Sergei\n\n\n\nvac:dst: §\n\nwakurtosis:vac:rlog\n\nPushed changes with new results (https://github.com/vacp2p/vac.dev/commit/c67ea09ac17a6049529983ef325ae4d9c6c24e2d)\n\n\nanalysis-shadow:waku:shadow-waku-relay-analysis\n\nInvestigating best approach for large scale (new wakunode2 with traffic vs external RPC calls)\n\n\neng-10ktool:vac:bandwidth-test\n\nFix problem in multicloud-cluster:\n\nhttps://github.com/status-im/infra-misc/issues/184\nhttps://github.com/k3s-io/k3s/discussions/8657\n\n\nCheck Prometheus metrics\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nNew tests:\n\nRelay - awaiting review\n\n\nImprovements:\n\nTest report dashboard. PR and deployment - awaiting review\n\n\nIssues found:\n\nNwaku regression around store cursor\nJS-waku possible issue around duplicate messages\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nIssues\n\nResubscription SEGFAULT\n\nReinvestigated and found it was a test case error, a futures issue.\nClosed Ticket\n\n\nPublishing multiple messages in a row triggers the same SEGFAULT as when refreshing a subscription.\n\nSame as above\n\n\nMax message sizes don’t match RFC\n\nReinvesitgated because some sizes weren’t correct.\nOpened Ticket\n\n\nAfter stopping and restarting a relay node, it can’t reconnect with connectRelay.\n\nReinvestigated because a comment by Aaryamann.\nOpened Ticket\n\n\n\n\nBegan implementing Store tests.\nGot a working GDB for NIM with VSCode integration. Not great, but it’s something.\nCleaned up Filter and Relay tests, and added missing payload size tests.\n\n[PR](https://github.com/waku-org/nwaku/pull/2138\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote five tests - were added to the branch https://github.com/waku-org/go-waku/tree/chore(filterV2)-test-updates\nReported issue “Subscription with empty contentTopic should fail” https://github.com/waku-org/go-waku/issues/810\nRetested issues #804 and #810 - learned a lot from Prem Prathi\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\ncontinued work on rlog, improvements\nprogcrypto sync with pse, presentation work - https://hackmd.io/wS2MAfSvSK-tnxzcriah9A\n\n\nadmin/misc\n\nsupporting DST, working on waku relay segfault, resolved\n\n\nsecure-channels:waku:ethereum-chat\n\nInclude some considerations on the extension to group chat revolving around asynchronous ratcheting trees.\nStart writing the raw version of the RFC.\nhttps://www.notion.so/WiP-Secure-Ethereum-Chat-f69ff155456c4fdeb719aba96fd7a\n\n\nzerokit:vac:maintenance\n\nprepared refactoring PR (https://github.com/vacp2p/zerokit/pull/219)\n\n\n\nvac:sc:: §\n\nstatus:community-curation-contracts\n\nAdjusted deploy script to mint mock SNT token on local node (this was needed for testing purposes)\n\nPR: https://github.com/status-im/community-dapp/pull/80\n\n\nFixed deployment script to ensure directory contracts are set in voting contracts\n\nhttps://github.com/status-im/community-dapp/pull/81\n\n\nFixed deployment that ensures Multicall2 is available on local nodes as well as references for production networks\n\nPR: https://github.com/status-im/community-dapp/pull/82\n\n\n\n\nvac:sc::status:snt-staking-contract_02\n\nImplement missing checks for staking lockup period\n\nPR: https://github.com/logos-co/staking/pull/39\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nResearching techniques for state separation and how to integrate different models.\nResearched and posted a document on Verkle tree.\nBegan research on ring signatures (DualRing and DualDory) (doc pending)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nPublished a new document about Proof Creation and Verification\n\n\nproofsystems:vac:benchmarks\n\nStarted a draft for an article (overleaf)\napplied feedback for the Nova-Scotia PR\nWrote the halo2 aggregation circuit (issues with testing, need more CPU power, will use DST server)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nScaled up execution of TEN multiple simultanesous torpush-validators with near zero attestation misses\nGathering measurements from other fleet nodes (blocked at)\n\n\nvalpriv:vac:tor-push-paper\n\nAdded more graphs, completed abstract, comparisons in the paper.\nStill reviewing new paper to incorporate https://www.research.ed.ac.uk/en/publications/on-the-anonymity-guarantees-of-anonymous-proof-of-stake-protocols\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nModified large message handling mechanism (outlined below) for GossipSub.\n\nNow we send large message to randomly selected (dlow-1) peers.\nRemaining peers get idontwant message\n\n\nMissed out nodes use iwant message to pull the missing large message\nApproximately 20-25% overall message reduction achieved and 1/2 RTT latency increased for approximately 5% nodes\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nStarted following discussions for current gossipsub improvement direcetions\n\n\nWriting the pseudocode and addressed comments from Nomos team (https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/carnot-vote-aggregation.py).\n\nResponded to questions raised in the high level protocol document (https://www.notion.so/High-Level-Algorithm-6535ac0363df4629ad2c40dff4bc62cd) by the nomos team.\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nwaku usage rfc - https://github.com/vacp2p/rfc/pull/627\n\n\n"},"vac/updates/2023-10-30":{"title":"2023-10-30 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDebug a various problems and trying to make the E2E works.\n\n\nnimlibp2p:vac:gossipsub-ddos-mitigation\n\nhttps://github.com/status-im/nim-libp2p/pull/965\n\n\nnimlibp2p:vac:maintenance\n\nAdd arm64 support when running HP tests locally https://github.com/libp2p/test-plans/pull/311 and https://github.com/libp2p/rust-libp2p/pull/4687\nAdd Hole Punching to libp2p test-plans https://github.com/status-im/nim-libp2p/issues/966\nIsolated failing tests from “Daily workflow”; Full matrix is passing now, but a lot of work on failing tests ahead\n\nhttps://github.com/status-im/nim-libp2p/issues/972\nhttps://github.com/status-im/nim-libp2p/actions/runs/6663282955\n\n\nfixed code duplicity: https://github.com/status-im/nim-libp2p/pull/968\nFurther problems identified:\n\nDeprecated compiler options and code usages\nNo support for macos-arm64\nOutdated go-libp2p-daemon\n\n\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nFinish the Codex growth model and updated litepaper (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nFollowing up with recent code changes SC has made (@Martin)\nCoordinating setup of Snapshot space w/ Corey who is the owner (@Martin)\n\n\nvac:tke::nomos:economic-analysis\n\nResearching rewards for validators and delegators, evaluating new private PoS (0 or 1 stake weight design) w/ Marcin (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nMartin participating in Waku calls, follows ups on “ENS” type approach to Waku stake (@Martin)\n\n\n\nvac:dst: §\n\nwakurtosis:vac:rlog\n\nReview changes of last commits\nBuilt NWaku image to run new 600 nodes with no load simulations (https://ci.infra.status.im/job/nim-waku/job/docker-manual/69/)\n\n\nanalysis-shadow:waku:shadow-waku-relay-analysis\n\nWorked in basic simulation with 10K Waku nodes (Pub/Sub Node)\n\n\nanalysis:nomos:simulation-analysis\n\nThe analysis is stable/automated, the machine runs are stable/automated, but the simulation bug(s) still effect results. (The nomos team is working on it)\nsimulation runs cont’\n\n\neng-10ktool:vac:bandwidth-test:\n\nPush as many gossipsub nodes as deliver and deliver metrics, either by\n\nMultiple gossipsub nodes per POD\nPushing further number of PODs per node\n\n\nClean up how to run it in a single bash script\n\n\nadmin/misc\n\nRun simulations for zkvm team\n\n\nsoftware-testing:waku:test-plans\n\nAdded Interop tests section to all existing test plans. Ex: for filter\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAddressed and merged all open PRs\nFixed CI logs\nHelped reproduce, investigate and retest store cursor regression\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nStarted building the framework for nwaku <-> gowaku interop testing\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nStore tests\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 2 tests - were added to the branch chore(filterV2)-test-updates\nRefactored first batch of tests and closed related PR https://github.com/waku-org/go-waku/pull/811\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\nfinished progcrypto presentation - https://docs.google.com/presentation/d/1ZkiFVJ3jBalFwAzQVaYbWU9BiRb22-2k5xGIRd2jXvU/edit?usp=sharing\n\n\nadmin/misc:\n\nstart implementation plan on reinforced concrete hash function for zkhack\n\n\nsecure-channels:waku:ethereum-chat\n\nwork on RFC cont’\n\n\nzerokit:vac:maintenance\n\nfixed linting (https://github.com/vacp2p/zerokit/pull/219), merged PR\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nSet up multisig for our team\n\nhttps://www.notion.so/Smart-Contract-Dev-Multisig-Wallet-bdf448b8e1424e13a463e1268b2ec294\n\n\nCreated a bunch of screencasts\n\nhttps://www.notion.so/f24bc8154bfd4757989216dde0f50af0?v=eb8f6f301de94f4889ee6179d16eaf47\n\n\n\n\ncodex:review-codex-contracts\n\nHad a call with the codex team to discuss their marketplace system\n\nRecording: https://drive.google.com/file/d/16QfFpgucYjIvfq0CYVGuIjJ3p5fR5rD5/view\n\n\n\n\nstatus:SNT-optimism-bridge\n\nDeployed SNT on Optimism\n\nhttps://optimistic.etherscan.io/address/0x650AF3C15AF43dcB218406d30784416D64Cfb6B2\n\n\nSent a PR to add SNT to optimism’s superchain token list (and bridge)\n\nhttps://github.com/ethereum-optimism/ethereum-optimism.github.io/pull/559\n\n\n\n\nstatus:community-curation-contracts\n\nFixed a bug with how active voting rooms are being determined\n\nPR: https://github.com/status-im/community-dapp/pull/89\n\n\nAdd ownership capabilities to Directory contract\n\nhttps://github.com/status-im/community-dapp/pull/90\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nResearched techniques for harmonizing UTXO and based-account model for state separation. (Goal 1)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nResearched techniques for proof creation and verification for Nova. (Goal 3)\nReadings on zkVM and how to build from scratch\nUpdated Zotero with some papers and blog posts\nPreparing for Zk hack\nlook into KiloNova\ndrafting document comparing theoretical complexities of proof schemes we’ve examined (part of Nescience’s Goal 3).\n\n\nproofsystems:vac:benchmarks\n\nUpdated Nova Cricuit document\nMerged the Nova-Scotia PR\nGenerated srs for 28 and 27\nReduced the number of columns in the halo2 circut\nContinued testing of aggregation circuit\nCode Review for Nova-Bellman\nFinish Code Review for Poseidon-Starky\nProvide rough calculations for Halo2 SRS generations in discord.\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nShare the internal release of tor-push validators with team for buddy testing/aspre-alpha.\ncompared attestation misses of normal and torpush validators\n\n\nvalpriv:vac:tor-push-paper\n\nFixed abstract, intro, identified needed improvements for stats.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nAdded staggered message sending in GossipSub implementation.\nCarried out performance evaluations for staggered sending, reduced sending https://github.com/status-im/nim-libp2p/pull/969\n\n\nconsensus:nomos:carnot-vote-2-3rds-vote-aggregation\n\nWriting the unit tests and addressed comments from Nomos team(https://github.com/logos-co/nomos-specs/blob/Carnot-vote-aggregation/carnot/test_carnot_vote_aggregation.py).\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nadded discovery usage to status-wakuv2-usage rfc - https://github.com/vacp2p/rfc/pull/627\n\n\n"},"vac/updates/2023-11-06":{"title":"2023-11-06 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\ncont. fixed segfault.\n\n\nnimlibp2p:vac:maintenance\n\nRevert https://github.com/status-im/nim-libp2p/issues/868\nfor Nimbus. A new libp2p branch was create for that https://github.com/status-im/nim-libp2p/tree/b2eac7e-and-revert-c6aa085 - https://github.com/status-im/nimbus-eth2/pull/5549\nnew Issue #975: CI workflow is failing frequently, https://github.com/status-im/nim-libp2p/issues/975, https://github.com/status-im/nim-libp2p/tree/fix/ci-workflow-stability\nin progress: PR #968: fix: move workflows for Nim Devel and legacy i386 from “Daily”\n\nnew workflows “Daily - Devel” and “Daily - Legacy Platforms” https://github.com/status-im/nim-libp2p/pull/968\nIssue #972: Daily workflow could fail randomly with [OSError] https://github.com/status-im/nim-libp2p/issues/972\n\n\n\n\n\nvac:tke: §\n\nadmin/misc: (7 CC conference days)\nvac:tke::status:SNT-staking\n\nFinalizing the setup & shape of Snapshot space (@Martin)\n\n\nvac:tke::nomos:economic-analysis\n\nResearching properties of rewards functions (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nPreparing an overview of possible revenue models (@Martin)\nMonitoring Sergei’s research (@Martin)\n\n\n\nvac:dst: §\n\nwakurtosis:vac:retrospective-rlog\n\nReviewed comments; soon to publish\n\n\nwakurtosis:vac:rlog\n\nAnalysis of new Wakurtosis simulations regarding the 600 nodes anomaly\nAnalysis of K8 simulations regarding the 600 nodes anomaly\n\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nworked on Topology slices\n(added more RAM to the server)\n\n\nanalysis-shadow:waku:shadow-waku-relay-analysis\n\nRun 600 nodes NWaku Shadow simulations with and without load\n\n\nanalysis:nomos:simulation-analysis\n\nThe network delay/bandwidth tuning, readjusting the probabilities, none of them helped. The bug(s) cannot be side-steped in any meaningful way.\nNew issue: for > 10 views, the disk usage blows up. 1.7 TERABYTES; and the output is just text files! This was quite unexpected; we now have yet another scalability issue with the nomos sim.\nspent couple of days on the Rust code and worked on adjustments. None of them helped with the bug.\n\n\nanalysis-gsub-model:vac:refactoring\n\nTuned/cleanedup to the control messages code\n\n\neng-10ktool:vac:bandwidth-test:\n\nMachines are no longer blocked\nAdded Kubernetes network policies to void having machines blocked.\n600 node simulations with Kubernetes to try to replicate 0 rate anomaly\nStarted an aproximation of waku-simulator with Kurtosis\nMeeting with Slava to investigate prometheus dropping container labeling information\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nHelped Danish with implementing the testing part of a Static Sharding PR\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nFirst PR:\n\nstart/stop waku docker nodes and connect them in a network\nsend RPC or REST API calls and validate that messages are reaching the peers\nsetup ci runs (on pr, on demand and nightly) via github actions\nallure reports via github pages that contain test and docker log attachments for failing tests\nautomated linting and code formatting\n2 basic tests for now but will extend after the initial set of reviews\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nMoved most of the PRs, missing one.\nImplement some store tests.\nFound (and fixed) issue with default values encoding/decoding for HistoryQuery.\nbug: assert false SEGFAULT.\n\nIt only triggers on some files, and imports don’t seem to be related.\n\n\nbug: Stopped filter node can receive messages\n\nIt’s actually expected behaviour.\nIssue\n\n\nbug: Filter doesn’t receive messages after subscribing and restarting\n\nIssue\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 4 tests related to filter unsubscribe and closed the PR https://github.com/waku-org/go-waku/pull/855\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\nMake changes as per review on rlog\n\n\nadmin/misc\n\nStudy the research paper on the Reinforced Concrete hash function.\nImplemented Reinforced concrete in huff - https://github.com/rymnc/reinforced-concrete-huff\n\ntl;dr: lesser gas consumed than poseidon (2 inputs)\n\n\nRC hash writeup on vacp2p/research - https://github.com/vacp2p/research/pull/196\n\n\nsecure-channels:waku:ethereum-chat\n\nKeep working on the comments from the team and finish the raw RFC.\nhttps://github.com/vacp2p/rfc/pull/626\n\n\n\nvac:sc:: §\n\nstatus:community-curation-contracts\n\nAdjusted import remappings\n\nhttps://github.com/status-im/community-dapp/pull/95\n\n\nAdded Goerli OP deployment config\n\nhttps://github.com/status-im/community-dapp/pull/96\n\n\nDeployed contracts on Goerli OP\nVerified contracts on OP Mainnet\n\n\nvac:maintainance/misc\n\nDeployed OP SNT on Goerli OP\nCreated a few screen casts on deployment\n\nhttps://www.notion.so/f24bc8154bfd4757989216dde0f50af0?v=eb8f6f301de94f4889ee6179d16eaf47\n\n\nImplemented SNT V2 which will be used to make SNT available on Sepolia\n\nhttps://github.com/status-im/status-network-token-v2/pull/1\n\n\n\n\ncodex:review-codex-contracts\n\nfinished watching the call recording\nreviewed the code again based on the knoledge from call\nsent PRs based on our review\nhttps://github.com/codex-storage/codex-contracts-eth/pull/73\nhttps://github.com/codex-storage/codex-contracts-eth/pull/74\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nKeep researching techniques for harmonizing UTXO and based-account model for state separation -> Model to model adapter (Goal 1)\nPrivacy-enhancing: Prepare document comparing Dory and IPA polynomial commitment schemes.\nResearch ring signatures that use Dory and IPA.\n\n\nproofsystems:vac:research-existing-proof-systems\n\nResearching techniques for proof creation and verification for Nova. (Goal 3)\nMore readings on zkVM and how to build from scratch\nPreparing for Zk hack\nDone slides for ProgCrypto\nPreparing a summary of a zk-Benchmark paper\n\n\nproofsystems:vac:benchmarks\n\nReviewed Starky implementation\nReviewed Nova implementation\nMerged the Nova-Bellman PR (https://github.com/vacp2p/zk-explorations/pull/14)\nMerged the posiedon-starky PR (https://github.com/vacp2p/zk-explorations/pull/16)\nReduced the number of columns in the halo2 circut\nSuccessfully ran shplonk implementation of poseidon halo2 circuit\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nInvestigated, drove measurements from other fleet nodes for latency\nGot testbed results with 10 validators, comparing and adding\n\n\nvalpriv:vac:tor-push-paper\n\nAdding scaled up execution results, revise discussion\nrevised presentation\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nCompleted small-scale simulations for large message handling\nCreated an updated PR for shadow simulation scripts https://github.com/vacp2p/dst-gossipsub-test-node/pull/3\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nCompiled things, revisited documents, and worked on presentation for logos research call on GossipSub Improvements\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nAdded the pull request for 71/STATUS-Push-Notification-Server https://github.com/vacp2p/rfc/pull/629/files (still WiP)\n\n\n"},"vac/updates/2023-11-13":{"title":"2023-11-13 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nDive into the Yamux/Relayv2 problem - https://github.com/status-im/nim-libp2p/pull/979\n\n\nnimlibp2p:vac:maintenance\n\nAdd Hole Punching to libp2p test-plans https://github.com/status-im/nim-libp2p/issues/966 and https://github.com/libp2p/test-plans/pull/322\nYamux doesn’t work in a Relayv2 connection https://github.com/status-im/nim-libp2p/pull/\nSingle-board computer (SBC) support https://github.com/status-im/nim-libp2p/issues/978\nARM64/aarch64 support https://github.com/status-im/nim-libp2p/issues/980\nTest Plans repo fork updated and resources to run tests requested https://github.com/status-im/libp2p-test-plans\nImplementing Nimble lock file functionality https://github.com/status-im/nim-libp2p/issues/975 https://github.com/status-im/nim-libp2p/tree/fix/ci-workflow-stability\nfix: move workflows for Nim Devel and legacy i386 from “Daily” -> workflows renamed to “Nim Devel” and “Legacy Platforms” https://github.com/status-im/nim-libp2p/pull/968\nDaily workflow could fail randomly with [OSError] https://github.com/status-im/nim-libp2p/issues/972\n\n\nnimlibp2p:vac:webrtc-transport\n\nFix read/write on the DTLS\nRetrieve the remote certificate\nStart creating a way to log packets behind the DTLS encryption into pcap file in order to make it readable with wireshark\nWebRTC is done. WebRTC for libp2p isn’t:\n\nchrome://webrtc-internals/ show no errors, neither wireshark.\nBut libp2p spec requires a weird handshake that I haven’t finished yet\n\n\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nMeeting with Codex on token allocation (@Matty)\nReview Codex modeling and litepaper with Codex (all)\nOne-pager draft requested by Matt Nemer for fundraising purposes (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nManaging snaphot for Status go-live this week (@Martin)\nReviewing and updating Cyprien’s governance proposal draft (all)\nStatus growth modeling followup discussion (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nContinuing research of PoS economics and token distributions (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nMonitoring Sergei’s research (@Martin)\nWaku growth monitoring (@Martin)\n\n\n\nvac:dst: §\n\nwakurtosis:waku:gossipsub-topology-analysis\n\nGenerated shadow simulation topology slices\n\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nRun 35K nodes simulation in shadow with low traffic\nImplemented constant traffic in the node\n\n\nanalysis:nomos:simulation-analysis\n\nsync with Moh and Nomos\nNomos sim team now has eveything to reproduce and fix the bug: exact configs and access to full runs\nSuggested improvements to the data output that will reduce both the memory and disk overload of nomos simulation by orders of magnitude. Moh and Gusto agree that this will work.\nWrapped up the nomos analysis for now: waiting for the sims team to finish fixing the bugs\n\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\nWrote an analysis script that can read graphs generated by Shadow runs\n\n\nanalysis-gsub-model:status:control-messages\n\nstarted write up on old and new Waku-models\n\n\neng-10ktool:vac:bandwidth-test:\n\nAdd publishing waku messages with Kubernetes\nTried to fix Prometheus labeling\nKeep investigating 0 rate anomaly with Kubernetes\nMeet with Florin to talk about tool repositories\nRan 4.5k waku nodes with no traffic\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nMerged 1st PR\nDraft 2nd PR:\n\nadd more tests (17 ATOW)\nframework improvements and adjustments as the number of tests increase\n\n\ngowaku issues found:\n\nfailures with relay get-messages API\nresponse message contains extra redundant fields compared with what is published\nREST API HTTP 500 Internal Server Error when publishing messages\nDocker DEBUG logs floaded in certain conditions\n\n\nnwaku issue found : container crashes when a message is published with malformed timestamp\nrest-api-specs issue found: missing fields in the REST API schema\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nUpdated last PR, missing reviewer responses.\nInvestigating assert false: Ivan took charge of that task; found it doesn’t happen anymore (will write notes on the issue to resume investigation later)\nPicking up pace with store tests.\nInvestigate a PEER_DIAL_FAILURE error in store; Happens when archive isn’t mounted (unexpected); Not yet reported.\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 2 tests related to filter unsubscribe all https://github.com/waku-org/go-waku/pull/875\nWrote string generator functions for tests with variable data https://github.com/waku-org/go-waku/pull/879\n\n\n\nvac:acz: §\n\nadmin/misc\n\n@ devconnect, participated in zk-hack, submitted https://devfolio.co/projects/reinforced-concrete-implementations-e82e, won a bounty from polygon\nupdated rln to use RC, significantly lower constraints, we can potentially bring down proof generation ti\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nvac blog post: https://vac.dev/rlog/rln-anonymous-dos-prevention/\n\n\nsecure-channels:waku:ethereum-chat\n\nImproving the raw RFC by writing it in terms of Noise, including: X3DH. XEdDSA. Double Ratchet. ADKG. https://github.com/vacp2p/rfc/tree/ethsecpm_improvements\n\n\nrlnp2p:waku:multi-epoch-constraints\n\nKeep working on the multi-constrained epoch project.\n\n\nzerokit:vac:maintenance\n\nmerged PR 220\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nRecorded new screen casts\nStarted working on presentation for Research Call\nmostly working in the Discover bug\ncontacted dapp deployer\nstarted a postmortem that I’m updating\njust exported a full list of dapps and contact\n\n\nstatus:governance-contract-mvp\n\nreseach and development; proposal types\nimplemented delegation\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nStill researching techniques for harmonizing UTXO and based-account model for state separation (delays due to Istanbul trip)\nResearch for privacy enhancing (from state separation document): ring signatures (Dory, IPA) assuming Nova.\nFor Flexibility Operation: researching Verkle trees implementation in other blockchains.\nDrafting document for privacy enhancing.\n\n\nproofsystems:vac:research-existing-proof-systems\n\nResearching techniques for proof creation and verification for Nova. (Goal 3)\nPreparing for Zk hack\nPreparing for ProgCrypto\n\n\nproofsystems:vac:benchmarks\n\nWrote a GWC implementation of poseidon circuit for halo2\nSuccessfully ran GWC implementation of poseidon halo2 circuit\nResearched GPU halo2 enhancement for our own possible use (https://github.com/kroma-network/tachyon/tree/main/vendors/halo2)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nGot separate measurements for aggregate vs attestation, Pushed all duties’ broadcasts on tor.\nManaged to get libp2p logs from other nimbus fleet machine. Large files, need to process them\n\n\nvalpriv:vac:tor-push-paper\n\nReady to share the paper. Finishing adding new results\nUpdating presentations, simplifying the slides.\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nrevisited documents, and worked on presentation for logos research call on GossipSub Improvements.\nBased on the feedback from the logos research call, revisited nim-libp2p documentation, codebase etc.\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nStarted revisiting the GossipSub improvement paper to reflect current work and finalize writeup (Still work in progress. will need 1-2 more days to reflect in overleaf document).\nRequested the DST team for initial simulation. I intend to use the outcomes to finalize test patterns.\npublished Vac blog post: https://vac.dev/rlog/GossipSub%20Improvements/\n\n\nzk:codex:storage-proofs-open-problems-review\n\nReview Groth16 notes for Codex\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nRemoved mailserver from 71/STATUS-PUSH-NOTIFICATION RFC https://github.com/vacp2p/rfc/pull/629\nAdded references to 71/STATUS-PUSH-NOTIFICATION RFC https://github.com/vacp2p/rfc/pull/629\nDid first read of 10/WAKU-USAGE looking for improvements\n\n\nwaku:waku-keystore\n\nCreated outline\nCreated draft pull request - https://github.com/vacp2p/rfc/pull/631\n\n\n"},"vac/updates/2023-11-20":{"title":"2023-11-20 Vac weekly","links":[],"tags":["vac-updates"],"content":"Publicly Engaging Highlights §\n\npresentations @ Progcrypto https://progcrypto.org/ on\n\nRLN\nValidator Privacy\nNescience\n\n\n\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nAdd Hole Punching to libp2p test-plans - https://github.com/status-im/nim-libp2p/issues/966 and https://github.com/libp2p/test-plans/pull/322\nfix: remove unittest2 range - https://github.com/status-im/nim-libp2p/pull/986\nfix: doc workflow - https://github.com/status-im/nim-libp2p/pull/985\nfix(dcutr): make the dcutr client inbound and the server outbound - https://github.com/status-im/nim-libp2p/pull/983\nfix(interop-tests): don’t hardcode x86_64 for native - https://github.com/libp2p/rust-libp2p/pull/4862\nconflicting dependency resolution - https://github.com/nim-lang/nimble/issues/116\nimplementing Yamux update window: https://github.com/status-im/nim-libp2p/pull/987\nResearch VM hosting providers - to execute perf tests https://docs.google.com/spreadsheets/d/1VL6QpDdBgYC1Ld0Nr-cpNv9bRht3nQkBQUF1pNerBDs/edit?usp=sharing\nworking on several CI issues\n\nTesting Nimble lock file - deps download consistent across platforms; https://github.com/status-im/nim-libp2p/issues/975\nfix: move workflows for Nim Devel and legacy i386 from “Daily” -> workflows renamed to “Nim Devel” and “Legacy Platforms” https://github.com/status-im/nim-libp2p/pull/968\nDaily workflow could fail randomly with [OSError] https://github.com/status-im/nim-libp2p/issues/972\n\n\n\n\nnimlibp2p:vac:webrtc-transport\n\nLog decyphered packet\n\nFailing to directly write a pcap file (it’s far more complicated than it looks)\nFailing to use the SSLKEYLOGFILE interaction between browser & wireshark\nStart writing a self-made logger to understand where it fails\n\n\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nFinish litepaper edits from Frederico and Martin review\nPing Codex on litepaper, followup discussion (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nConfirm with Agata on responses to the governance forum posts (@Matty)\nMeet w/ John to plan out next steps post-website launch\n\n\nvac:tke::nomos:economic-analysis\n\nContinuing research of PoS economics and token distributions, participating in Nomos offsite discussions (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nDevConnect and Waku offsite (@Martin)\nResearching EigenTrust use for Waku reputation system (@Matty)\n\n\n\nvac:dst: §\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\ncont’ with various simulation runs; does not scale to larger message sizes because of RAM limit (a burst of nine 500KB msgs, 500 nodes was too much for 256GB RAM)\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nAddressed review comments and merged 2nd PR to reach 27 tests for relay publish\n\nDraft 3rd PR:\nmake framework support dynamic number of nodes\n\nadd multi-node tests (that work on any number of nodes)\n\n\n\n\nMultiple issues found:\n\ngowaku:\n\n2 regressions (container sometimes crashes + log spam) on lastest master\nREST API error handling discrepancies\n\n\nnwaku:\n\nREST API request fails if request contains meta or rate_limit_proof fields\n\n\nrest-api-specs: missing fields in the REST API schema\n\n\n\n\nsoftware-testing:waku:test-automation-js-waku\n\nAdd summary with link to report to the js-waku CI test job\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nPR Train Merged\n\nPR 2085\nPR 2095\nPR 2096\nPR 2101\nPR 2138\n\n\nFix compilation and tests failing after PR train\n\nPR 2222\nPR 2224\n\n\nImplementing store tests\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 7 tests related to filter push - valid data https://github.com/waku-org/go-waku/pull/904\nTest fixes to extend message timeout https://github.com/waku-org/go-waku/pull/911\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\npresented RLN @ Progcrypto\n\n\nsecure-channels:waku:ethereum-chat\n\nWorked towards moving the algorithms involved in the Ethereum chat to Noise terms. In particular: XEdDSA and DR.\nStart working on ADKG. https://www.notion.so/WiP-ADKG-e83e24612abc41a7bf292e96660ab833\n\n\nzerokit:vac:maintenance\n\nfixed nightly zerokit build failure\nmerged PR 223 (https://github.com/vacp2p/zerokit/pull/223)\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nReview Certora PR for OP SNT repository\n\n\nstatus:community-contracts-maintenance\n\nRedeployed contracts to Goerli for updated version https://github.com/status-im/communities-contracts/pull/23\nDeployed contracts to Arbitrum Goerli and Arbitrum Sepolia\nVerified contracts on Sepolia\n\n\nstatus:token-import\n\nstarted working on the Vault contract\n\n\n\nvac:nescience: §\n\nproofsystems:vac:benchmarks\n\npresent Nescience @ progcrypto\nPrepared a PR for a GWC implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/17\nPrepared a PR for a SHPLONK implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/18\n\n\nstate-separation:vac:state-separation-doc\n\nResearch mimblewimble (part of enhanced privacy)\nResearch verkle trees specific to kzg and ipa (part of flexibility in operations, and joint with Codex’s future needs)\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted the GossipSub improvements paper, with the exception of the results and discussion part. Reflected the feedback and current works as well.\n\n\nvalpriv:vac:tor-push-poc\n\ntalk @progcrypto\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nUpdated 71/STATUS-PUSH-NOTIFICATION RFC https://github.com/vacp2p/rfc/pull/629\n\n\nwaku:waku-keystore\n\nUpdated draft - https://github.com/vacp2p/rfc/pull/631\n\n\n"},"waku/index":{"title":"Waku Roadmap","links":["waku/monthly-reports/2023-sept","waku/milestones-overview","tags/waku-updates","waku/reports"],"tags":["waku-roadmap","overview"],"content":"Welcome to the Waku Roadmap Overview\nWaku is a family of robust, censorship-resistant communication protocols designed to enable privacy-focused messaging for Web3 apps. To learn more please visit the website and docs.\n\n2023 September Report\nMilestones\nWeekly updates\nReports\n"},"waku/milestone-waku-10-users":{"title":"Milestone: Waku Network supports 10k Users","links":[],"tags":[],"content":"%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Scaling\n\t\t10k Users :done, 2023-01-20, 2023-07-31\n\nCompletion Deliverable §\nTBD\nEpics §\n\nGithub Issue Tracker\n"},"waku/milestones-overview":{"title":"Waku Milestones Overview","links":[],"tags":[],"content":"Milestone: Waku Network can Support 1 Million Users §\nLink: https://github.com/waku-org/pm/milestone/4\nDue by: 2023-11-30\nEpic: Cater for professional operators (Status Communities)\n\n\nLink: https://github.com/waku-org/pm/issues/92\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1929\n\n\nhttps://github.com/fryorcraken/milestone-update/\n\n\nEpic: Simulation with 10k nodes\n\n\nLink: https://github.com/waku-org/pm/issues/85\n\n\nIssues in Epic:\n\n\nhttps://github.com/vacp2p/research/issues/191\n\n\nEpic: PostgreSQL in service node: Further optimisations\n\n\nLink: https://github.com/waku-org/pm/issues/84\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1894\n\n\nhttps://github.com/waku-org/nwaku/issues/1893\n\n\nhttps://github.com/waku-org/nwaku/issues/1888\n\n\nhttps://github.com/waku-org/nwaku/issues/1885\n\n\nhttps://github.com/waku-org/nwaku/issues/1842\n\n\nhttps://github.com/waku-org/nwaku/issues/1841\n\n\nhttps://github.com/waku-org/nwaku/issues/1840\n\n\nhttps://github.com/waku-org/nwaku/issues/1604\n\n\nMilestone: Waku Network Gen 0 §\nLink: https://github.com/waku-org/pm/milestone/1\nDue by: 2023-12-01\nEpic: 3.4: Production and memberships on mainnet\n\n\nLink: https://github.com/waku-org/pm/issues/87\n\n\nNo issues in Epic description.\n\n\nEpic: 3.4: Further memberships\n\n\nLink: https://github.com/waku-org/pm/issues/72\n\n\nNo issues in Epic description.\n\n\nEpic: 3.3: Membership for Status Communities\n\n\nLink: https://github.com/waku-org/pm/issues/71\n\n\nNo issues in Epic description.\n\n\nEpic: 3.2: Basic DoS protection in production\n\n\nLink: https://github.com/waku-org/pm/issues/70\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/go-waku/issues/732\n\n\nhttps://github.com/waku-org/go-waku/issues/731\n\n\nhttps://github.com/waku-org/go-waku/issues/655\n\n\nEpic: 1.5: Launch and dogfood integrated public Waku Network MVP\n\n\nLink: https://github.com/waku-org/pm/issues/68\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/research/issues/1\n\n\nEpic: 1.4: Sharded peer management and discovery\n\n\nLink: https://github.com/waku-org/pm/issues/67\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1941\n\n\nhttps://github.com/waku-org/nwaku/issues/1940\n\n\nhttps://github.com/waku-org/js-waku/issues/1505\n\n\nhttps://github.com/waku-org/js-waku/issues/1504\n\n\nhttps://github.com/waku-org/go-waku/issues/727\n\n\nhttps://github.com/waku-org/go-waku/issues/680\n\n\nhttps://github.com/waku-org/go-waku/issues/679\n\n\nhttps://github.com/waku-org/go-waku/issues/678\n\n\nEpic: 1.3: Node bandwidth management mechanism\n\n\nLink: https://github.com/waku-org/pm/issues/66\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1947\n\n\nhttps://github.com/waku-org/nwaku/issues/1946\n\n\nhttps://github.com/waku-org/nwaku/issues/1945\n\n\nhttps://github.com/waku-org/nwaku/issues/1938\n\n\nhttps://github.com/waku-org/js-waku/issues/1503\n\n\nhttps://github.com/waku-org/go-waku/issues/677\n\n\nEpic: 1.2: Autosharding for autoscaling\n\n\nLink: https://github.com/waku-org/pm/issues/65\n\n\nNo issues in Epic description.\n\n\nEpic: 2.3: Basic distributed Store services\n\n\nLink: https://github.com/waku-org/pm/issues/64\n\n\nNo issues in Epic description.\n\n\nEpic: 2.2: Sharded capability discovery for light protocols\n\n\nLink: https://github.com/waku-org/pm/issues/63\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/js-waku/issues/1506\n\n\nEpic: 2.1: Production testing of existing protocols\n\n\nLink: https://github.com/waku-org/pm/issues/49\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1950\n\n\nhttps://github.com/waku-org/nwaku/issues/1948\n\n\nhttps://github.com/waku-org/nwaku/issues/1888\n\n\nhttps://github.com/waku-org/js-waku/issues/1463\n\n\nhttps://github.com/waku-org/js-waku/issues/914\n\n\nEpic: Dogfood RLN in production\n\n\nLink: https://github.com/waku-org/pm/issues/51\n\n\nNo issues in Epic description.\n\n\nEpic: Open membership mechanism\n\n\nLink: https://github.com/waku-org/pm/issues/52\n\n\nNo issues in Epic description.\n\n\nEpic: RLN validation in production\n\n\nLink: https://github.com/waku-org/pm/issues/55\n\n\nNo issues in Epic description.\n\n\nEpic: Autosharding - dogfooding\n\n\nLink: https://github.com/waku-org/pm/issues/58\n\n\nNo issues in Epic description.\n\n\nMilestone: Quality Assurance processes are in place §\n-Link: https://github.com/waku-org/pm/milestone/3\nDue by: 2024-03-31\nEpic: Comprehensive Dev Testing\n\n\nLink: https://github.com/waku-org/pm/issues/90\n\n\nIssues in Epic:\n\n\nhttps://github.com/fryorcraken/milestone-update/\n\n\nhttps://github.com/waku-org/js-waku/issues/1589\n\n\nhttps://github.com/waku-org/js-waku/issues/1435\n\n\nhttps://github.com/waku-org/js-waku/issues/337\n\n\nhttps://github.com/waku-org/js-waku/issues/1595\n\n\nhttps://github.com/waku-org/js-waku/issues/1597\n\n\nEpic: Automated Release processes\n\n\nLink: https://github.com/waku-org/pm/issues/86\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1889\n\n\nhttps://github.com/waku-org/js-waku/issues/1543\n\n\nhttps://github.com/waku-org/waku-rust-bindings/issues/67\n\n\nEpic: End-to-end testing\n\n\nLink: https://github.com/waku-org/pm/issues/34\n\n\nIssues in Epic:\n\n\nhttps://notes.status.im/s/iylE6wdli#\n\n\nhttps://github.com/waku-org/go-waku/issues/608\n\n\nMilestone: Support Many Platforms §\nLink: https://github.com/waku-org/pm/milestone/2\nDue by: 2024-04-30\nEpic: Ship RLN as part of non-native SDKs\n\n\nLink: https://github.com/waku-org/pm/issues/88\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/go-zerokit-rln/issues/5\n\n\nhttps://github.com/waku-org/go-waku/issues/732\n\n\nhttps://github.com/waku-org/nwaku/issues/2033\n\n\nhttps://github.com/fryorcraken/milestone-update/\n\n\nEpic: REST API service node\n\n\nLink: https://github.com/waku-org/pm/issues/82\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1988\n\n\nhttps://github.com/waku-org/nwaku/issues/1985\n\n\nhttps://github.com/waku-org/nwaku/issues/1910\n\n\nhttps://github.com/waku-org/nwaku/issues/1909\n\n\nhttps://github.com/waku-org/nwaku/issues/1872\n\n\nhttps://github.com/waku-org/nwaku/issues/1652\n\n\nhttps://github.com/waku-org/nwaku/issues/1214\n\n\nhttps://github.com/waku-org/nwaku/issues/1076\n\n\nhttps://github.com/waku-org/nwaku/issues/938\n\n\nhttps://github.com/waku-org/go-waku/issues/264\n\n\nEpic: NodeJS Library\n\n\nLink: https://github.com/waku-org/pm/issues/81\n\n\nIssues in Epic:\n\n\nhttps://github.com/waku-org/nwaku/issues/1332\n\n"},"waku/monthly-reports/2023-sept":{"title":"2023 September Monthly Waku Report","links":["vac/dst/","vac/dst/wakurtosis/vac/retrospective-rlog","waku/updates/2023-09-04","waku/updates/2023-09-11","waku/updates/2023-09-18","waku/updates/2023-09-25"],"tags":["monthly-report","waku"],"content":"Executive Summary §\nThe month of September saw an agreement and solidification of the Waku roadmap which defines the process of launching the Waku Network as an independent piece of infrastructure the broader ecosystem can rely upon. Along with this, a revamp of the process in which work is labeled and tracked was performed which has an automated part and is generally more in line with the requests from the Insights team.\nWork continues in the scaling and productionization efforts across the clients. Work previously done to enables PostgreSQL engine for WAKU-STORE in nwaku is being locally stress tested, further stress test using dev fleet is expected to be finalized next month. A Waku static sharding strategy is being integrated into Status to accommodate the first growth milestones of the re-release and adaptive sharding research and implementation is close behind.\nLocal simulation of RLN-RELAY has enabled the discovery of minor bugs which are fixed in the latest release of zerokit and nwaku and the study of the affect of RLN on performance.\nKurtosis as a platform was found to be insufficient for modeling a Waku network at the scale we wish, and the Vac team is pursuing an alternative strategy and writing up learnings from the boundaries were able to push.\nQuality Assurance practices are scheduled throughout the next year to keep all client implementations up to a threshold of continuous quality.\nThe process to add native integration APIs to nwaku is underway such that the default native library moves from go-waku to nwaku.\nKey Updates §\nPersonnel §\n\naddition of\n\nAaron as Project Manager\nSergei as Researcher\nGabriel as nwaku Engineer\n\n\nSeveral Jobs Descriptions have been reviewed this month to be opened shortly:\n\nGrowth Lead/Marketing strategist to drive Waku’s growth and liaise with Comms Hubs\nBusiness Development Lead, to further develop partnership with ecosystem projects\nSolution Engineer, to provide technical support to projects integrating Waku\n\n\nA core contributor to lead the Waku Chat SDK team has been secured, with start date in November.\n\nMilestones §\nA lot of work has been put into coalescing and finalizing the development tracking process that is in line with the Insight Reporting requirements, and Aaron’s addition to the team this month as pushed it over the edge to completion. Much of this has gone into automating the weekly reporting process via GitHub labels and comments on issues.\nFor tracking Waku maintains these Milestones in the waku-org/pm repo. Within each milestone description, you’ll find the corresponding Epics. Every Epic is distinctly labeled, and this label is affixed to each issue associated with that particular Epic. The labels are managed by the labels.yaml file located in the waku-org/pm repo.\nGiven the expansive nature of Waku and its various repositories working towards the milestones, the labels established in the labels.yaml file are replicated across each respective waku-org repo. This structure allows for seamless navigation, starting from top-level milestones down to the most granular issues.\nWaku is broken out into the following four Milestones, with Epics associated with them:\n\nWaku Network Gen0\nWaku Network Can Support 1MM Users\nQuality Assurace Processes in Place\nSupport Many Platforms\n\nMore details on the structure and progress of all Waku work can be tracked in their PM repository, specifically the milestone page. The following sections are highlighted updates on what happened this month.\nWaku Network Gen0 §\nThe Waku Network RFC was created and published on Vac as RAW which details the ideas and architecture of the Waku Network. The next version of RLN was also published on Vac as RAW.\nA benchmark of RLN was conducted and the results were discussed in a Logos Research Call presentation (See waku-org/research#23 for details). The tl;dr is copied here for convenience:\n\n\n \n TLDR: \n \n \n\nProof generation is constant-ish. 0.15 second for each proof\nProof verification is constant-ish, 0.012 seconds. In a network with 10k nodes and D=6 this would add an overhead delay of 0.06 seconds.\nGossipsub scoring drops connections from spammer peers, which acts as the punishment (instead of slashing). Validated in the simulation.\nRLN doesn’t have any impact on memory consumption.\n\n\nBased on these two specification publications and other associated work, efforts have begun to launch the first dev-testnet in time for the DevConnect event in November 2023.\nAll launch critical work for autosharding has been done in terms of RFC and nwaku.\nWaku Network Can Support 1MM Users §\nSignificant work was completed on the PostgreSQL integration and setup within nwaku, which supports the data retention and retrieval of Waku archival nodes. The implementation is currently being stress-tested to ensure production performance metrics are met.\nThe efforts in simulating a Waku Network of 10k users within a single shard continues and is tracked within Vac DST Roadmap. The performance of Wakurtosis (Kurtosis backend) was found to be insufficient for our requirements for scaling simulations. The creation of a Kubernetes orchestration tool, written in Python, has begun construction. This tool is heavily architected to mimic what Codex has created. It was chosen to reproduce this tooling in Python in order to increase usability and ease of maintenance/contribution as C# is a less known language within the org. The reasoning for this development can be tracked in retrospective-rlog.\nThe effort to understand a “professional Waku node operator” has begun and initial notes can be tracked within this minutes doc.\nA “static sharding” fleet was setup to test sharding and PostgreSQL by Waku team.\nSetup of a similar fleet dedicated to Status Communities is in progress (the first fleet may be used in the interim).\nQuality Assurance Processes in Place §\nThis milestone was created to ensure preparedness for the upcoming production client needs (specifically Waku Network Gen0 and Status Communities). A list of required processes in place was constructed and tasked out so that all implementations of Waku go through a standardized production release cycle.\nThis work is coordinating with the new Vac DST additions focused on testing rubrics for Logos Projects. This milestone is expected to be completed by Q1 2024.\nWork has started to use the js-waku CI as an integration test suite for nwaku and go-waku. This test suite can now easily be run for either client as part of their release process.\nSupport Many Platforms §\nThis is a large milestone created last month that tracks Waku’s “integration landscape” and attempting to ensure any developer seamlessly is able to integrate Waku.\nIt has started to list the work required for completion but more detail is needed to be fleshed out on prioritization and estimated resource needs. Currently, it is slotted for completion by April 2024.\nMuch of the work this month was fleshing out the available REST APIs of nwaku.\nA poll was created to query what language priority we should have was gone. They’ll be published on socials next month to boost engagement and feedback. This poll will assist with priorities for this milestone.\nPerceived Changes in Project Risk §\n\nWaku doing most integration of Waku into status-go consumes a lot of Go-related developer resources.\n\na list of needed work is tracked here\n\n\nThere effort to convert nwaku to the main native integration client requires a large effort in the implementations of C-bindings in Nim and has some unknowns associated with it. Furthermore this additional effort and uncertainty doesn’t directly contribute to the current critical path of development.\nThe first main application of the milestone reorganization within the project has made the milestones associated with it clear, thus allowing the Waku Network MVP target setup to be tracked well\n\nFuture Improvement Plans §\nInsight §\nThe insight team plans to further evaluate the value the reporting process implemented by Waku as it pertains to use within the other projects under Logos. It is expected that next month it will be finalized and ready for review by other teams to see if they’d like to adopt it.\nOne side effect of the automated reporting process is that the associate issue labels are already compatible with our data lake ingestion that was initiated by the Status project. This will allow us to create more useful dashboards and monitoring that take into account accurate development activity.\nProject §\nAs the milestones continue to be fleshed out and detailed, the ability to show progress over time will improve.\nSources and Useful Links §\nWeekly Reports\n\n2023-09-04\n2023-09-11\n2023-09-18\n2023-09-25\n"},"waku/reports":{"title":"Waku Reporting","links":[],"tags":["wakureporting"],"content":"Meetings and Weekly Updates §\nHigh level reporting overview §\n\nDaily standups are posted in the team discord.\nWeekly progress reports are submitted as comments on open issues in any public waku-org github repository. A script compiles the relevant comments and prepares for publication.\n\nWeekly updates pertaining to progress made toward active Epics and Milestones can be found here.\n\n\nMonday all-team PM meetings are held three times to accommodate all time zones.\nWaku client-team PM meetings are held throughout the week depending on the general timezone and schedules of the team.\nWeekly highlights are derived from the weekly dev updates and compiled for publication by the Comms team via the “Waku Wednesday” series on X.\n\n"},"waku/updates/2023-07-24":{"title":"2023-07-24 Waku weekly","links":[],"tags":["waku-updates"],"content":"Disclaimer: First attempt playing with the format. Incomplete as not everyone is back and we are still adjusting the milestones.\n\nDocs §\nMilestone: Foundation for Waku docs (done) §\nachieved: §\n\noverall layout\nconcept docs\ncommunity/showcase pages\n\nMilestone: Foundation for node operator docs (done) §\nachieved: §\n\nnodes overview page\nguide for running nwaku (binaries, source, docker)\npeer discovery config guide\nreference docs for config methods and options\n\nMilestone: Foundation for js-waku docs §\nachieved: §\n\njs-waku overview + installation guide\nlightpush + filter guide\nstore guide\n@waku/create-app guide\n\nnext: §\n\nimprove @waku/react guide\n\nblocker: §\n\npolyfills issue with js-waku\n\nMilestone: Docs general improvement/incorporating feedback (continuous) §\nMilestone: Running nwaku in the cloud §\nMilestone: Add Waku guide to learnweb3.io §\nMilestone: Encryption docs for js-waku §\nMilestone: Advanced node operator doc (postgres, WSS, monitoring, common config) §\nMilestone: Foundation for go-waku docs §\nMilestone: Foundation for rust-waku-bindings docs §\nMilestone: Waku architecture docs §\nMilestone: Waku detailed roadmap and milestones §\nMilestone: Explain RLN §\n\nEco Dev (WIP) §\nMilestone: EthCC Logos side event organisation (done) §\nMilestone: Community Growth §\nachieved: §\n\nWrote several bounties, improved template; setup onboarding flow in Discord.\n\nnext: §\n\nReview template, publish on GitHub\n\nMilestone: Business Development (continuous) §\nachieved: §\n\nDiscussions with various leads in EthCC\n\nnext: §\n\nBooking calls with said leads\n\nMilestone: Setting Up Content Strategy for Waku §\nachieved: §\n\nDiscussions with Comms Hubs re Waku Blog\nexpressed needs and intent around future blog post and needed amplification\ndiscuss strategies to onboard/involve non-dev and potential CTAs.\n\nMilestone: Web3Conf (dates) §\nMilestone: DeCompute conf §\n\nResearch (WIP) §\nMilestone: Autosharding v1 §\nachieved: §\n\nrendezvous hashing\nweighting function\nupdated LIGHTPUSH to handle autosharding\n\nnext: §\n\nupdate FILTER & STORE for autosharding\n\n\nnwaku (WIP) §\nMilestone: Postgres integration. §\nachieved: §\n\nnwaku can store messages in a Postgres database\nwe started to perform stress tests\n\nnext: §\n\nAnalyse why some messages are not stored during stress tests happened in both sqlite and Postgres, so maybe the issue isn’t directly related to store.\n\nMilestone: nwaku as a library (C-bindings) §\nachieved: §\n\nThe integration is in progress through N-API framework\n\nnext: §\n\nMake the nodejs to properly work by running the nwaku node in a separate thread.\n\n\ngo-waku (WIP) §\n\njs-waku (WIP) §\nMilestone: Peer management §\n_achieved: §\n\nspec test for connection manager\n\nMilestone: Peer Exchange §\nMilestone: Static Sharding §\nnext: §\n\nstart implementation of static sharding in js-waku\n\nMilestone: Developer Experience §\nachieved: §\n\njs-lip2p upgrade to remove usage of polyfills (draft PR)\n\nnext: §\n\nmerge and release js-libp2p upgrade\n\nMilestone: Waku Relay in the Browser §\n"},"waku/updates/2023-07-31":{"title":"2023-07-31 Waku weekly","links":[],"tags":["waku-updates"],"content":"Docs §\nMilestone: Docs general improvement/incorporating feedback (continuous) §\nnext: §\n\nrewrite docs in British English\n\nMilestone: Running nwaku in the cloud §\nnext: §\n\npublish guides for Digital Ocean, Oracle, Fly.io\n\n\nEco Dev (WIP) §\n\nResearch §\nMilestone: Detailed network requirements and task breakdown §\nachieved: §\n\ngathering rough network requirements\n\nnext: §\n\ndetailed task breakdown per milestone and effort allocation\n\nMilestone: Autosharding v1 §\nachieved: §\n\nupdate FILTER & STORE for autosharding\n\nnext: §\n\nRFC review & updates\ncode review & updates\n\n\nnwaku §\nMilestone: nwaku release process automation §\nnext: §\n\nsetup automation to test/simulate current master to prevent/limit regressions\nexpand target architectures and platforms for release artifacts (e.g. arm64, Win…)\n\nMilestone: HTTP Rest API for protocols §\nnext: §\n\nFilter API added\ntests to complete.\n\n\ngo-waku §\nMilestone: Increase Maintability Score. Refer to CodeClimate report §\nnext: §\n\ndefine scope on which issues reported by CodeClimate should be fixed. Initially it should be limited to reduce code complexity and duplication.\n\nMilestone: RLN updates, refer issue. §\nachieved:\n\nexpose set_tree, key_gen, seeded_key_gen, extended_seeded_keygen, recover_id_secret, set_leaf, init_tree_with_leaves, set_metadata, get_metadata and get_leaf\ncreated an example on how to use RLN with go-waku\nservice node can pass in index to keystore credentials and can verify proofs based on bandwidth usage\n\nnext: §\n\nmerkle tree batch operations (in progress)\nusage of persisted merkle tree db\n\nMilestone: Improve test coverage for functional tests of all protocols. Refer to [CodeClimate report] §\nnext: §\n\ndefine scope on which code sections should be covered by tests\n\nMilestone: C-Bindings §\nnext: §\n\nupdate API to match nwaku’s (by using callbacks instead of strings that require freeing)\n\n\njs-waku §\nMilestone: Peer management §\nachieved: §\n\nextend ConnectionManager with EventEmitter and dispatch peers tagged with their discovery + make it public on the Waku interface\n\nnext: §\n\nfallback improvement for peer connect rejection\n\nMilestone: Peer Exchange §\nnext: §\n\nrobusting support around peer-exchange for examples\n\nMilestone: Static Sharding §\nachieved: §\n\nWIP implementation of static sharding in js-waku\n\nnext: §\n\ninvestigation around gauging connection loss;\n\nMilestone: Developer Experience §\nachieved: §\n\nimprove & update @waku/react\nmerge and release js-libp2p upgrade\n\nnext: §\n\nupdate examples to latest release + make sure no old/unused packages there\n\nMilestone: Maintenance §\nachieved: §\n\nupdate to libp2p@0.46.0\n\nnext: §\n\nsuit of optional tests in pipeline\n\n"},"waku/updates/2023-08-06":{"title":"2023-08-06 Waku weekly","links":[],"tags":["waku-updates"],"content":"Milestones for current works are created and used. Next steps are:\n\nRefine scope of research work for rest of the year and create matching milestones for research and waku clients\nReview work not coming from research and setting dates\nNote that format matches the Notion page but can be changed easily as it’s scripted\n\nnwaku §\nRelease Process Improvements {E:2023-qa}\n\nachieved: fixed a bug in release CI workflow, enhanced the CI workflow to build and push a docker image on each PR to make simulations per PR more feasible\nnext: document how to run PR built images in waku-simulator, adding Linux arm64 binaries and images\nblocker:\n\nPostgreSQL {E:2023-10k-users}\n\nachieved: Docker compose with nwaku + postgres + prometheus + grafana + postgres_exporter https://github.com/alrevuelta/nwaku-compose/pull/3\nnext: Carry on with stress testing\n\nAutosharding v1 {E:2023-1mil-users}\n\nachieved: feedback/update cycles for FILTER & LIGHTPUSH\nnext: New fleet, updating ENR from live subscriptions and merging\nblocker: Architecturally it seams difficult to send the info to Discv5 from JSONRPC for the Waku app.\n\nMove Waku v1 and Waku-Bridge to new repos {E:2023-qa}\n\nachieved: Removed v1 and wakubridge code from nwaku repo\nnext: Remove references to v2 from nwaku directory structure and documents\n\nnwaku c-bindings {E:2023-many-platforms}\n\nachieved:\n\nMoved the Waku execution into a secondary working thread. Essential for NodeJs.\nAdapted the NodeJs example to use the libwaku with the working-thread approach. The example had been receiving relay messages during a weekend. The memory was stable without crashing.\n\n\nnext: start applying the thread-safety recommendations https://github.com/waku-org/nwaku/issues/1878\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added.\nnext: Extend Rest Api interface for new v2 filter. Get v2 filter service supported from node.\n\n\njs-waku §\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: robustness around peer-exchange, and highlight discovery vs connections for PX on the web-chat example\nnext: saving successfully connected PX peers to local storage for easier connections on reload\n\nWaku Relay scalability in the Browser {NO EPIC}\n\nachieved: draft of direct browser-browser RTC example https://github.com/waku-org/js-waku-examples/pull/260\nnext: improve the example (connection re-usage), work on contentTopic based RTC example\n\n\ngo-waku §\nC-Bindings Improvement: Callbacks and Duplications {E:2023-many-platforms}\n\nachieved: updated c-bindings to use callbacks\nnext: refactor v1 encoding functions and update RFC\n\nImprove Test Coverage {E:2023-qa}\n\nachieved: Enabled -race flag and ran all unit tests to identify data races.\nnext: Fix issues reported by the data race detector tool\n\nRLN: Post-Testnet3 Improvements {E:2023-rln}\n\nachieved: use zerokit batch insert/delete for members, exposed function to retrieve data from merkle tree, modified zerokit and go-zerokit-rln to pass merkle tree persistence configuration settings\nnext: resume onchain sync from persisted tree db\n\nIntroduce Peer Management {E:2023-peer-mgmt}\n\nachieved: Basic peer management to ensure standard in/out ratio for relay peers.\nnext: add service slots to peer manager\n\n\nEco Dev §\nAug 2023 {E:2023-eco-growth}\n\nachieved: production of swags and marketing collaterals for web3conf completed\nnext: web3conf talk and side event production. various calls with commshub for preparing marketing collaterals.\n\n\nDocs §\nAdvanced docs for js-waku {E:2023-eco-growth}\n\nnext: create guide on @waku/react and debugging js-waku web apps\n\nDocs general improvement/incorporating feedback (2023) {E:2023-eco-growth}\n\nachieved: rewrote the docs in UK English\nnext: update docs terms, announce js-waku docs\n\nFoundation of js-waku docs {E:2023-eco-growth}\nachieved: added guide on js-waku bootstrapping\n\nResearch §\n1.1 Network requirements and task breakdown {E:2023-1mil-users}\n\nachieved: Setup project management tools; determined number of shards to 8; some conversations on RLN memberships\nnext: Breakdown and assign tasks under each milestone for the 1 million users/public Waku Network epic.\n\n"},"waku/updates/2023-08-14":{"title":"2023-08-14 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-08-14 Waku weekly §\n\nEpics §\nWaku Network Can Support 10K Users {E:2023-10k-users}\nAll software has been delivered. Pending items are:\n\nRunning stress testing on PostgreSQL to confirm performance gain https://github.com/waku-org/nwaku/issues/1894\nSetting up a staging fleet for Status to try static sharding\nRunning simulations for Store protocol: Will confirm with Vac/DST on dates/commitment and probably move this to 1mil epic\n\n\nEco Dev §\nAug 2023 {E:2023-eco-growth}\n\nachieved: web3conf talk, swags, 2 side events, twitter promotions, requested for marketing collateral to commshub\nnext: complete waku metrics, coordinate events with Lou, ethsafari planning, muchangmai planning\nblocker: was blocked on infra for hosting nextjs app for waku metrics but migrating to SSR and hosting on vercel\n\n\nDocs §\nAdvanced docs for js-waku\n\nnext: document notes/recommendations for NodeJS, begin docs on js-waku encryption\n\n\nnwaku §\nRelease Process Improvements {E:2023-qa}\n\nachieved: minor CI fixes and improvements\nnext: document how to run PR built images in waku-simulator, adding Linux arm64 binaries and images\n\nPostgreSQL {E:2023-10k-users}\n\nachieved: Learned that the insertion rate is constrained by the relay protocol. i.e. the maximum insert rate is limited by relay so I couldn’t push the “insert” operation to a limit from a Postgres point of view. For example, if 25 clients publish messages concurrently, and each client publishes 300 msgs, all the messages are correctly stored. If repeating the same operation but with 50 clients, then many messages are lost because the relay protocol doesn’t process all of them.\nnext: Carry on with stress testing. Analyze the performance differences between Postgres and SQLite regarding the read operations.\n\nAutosharding v1 {E:2023-1mil-users}\n\nachieved: many feedback/update cycles for FILTER, LIGHTPUSH, STORE & RFC\nnext: updating ENR for live subscriptions\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added.\nnext: Extend Rest Api interface for new v2 filter. Get v2 filter service supported from node. Add more tests.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: upgrade libp2p & chainsafe deps to libp2p 0.46.3 while removing deprecated libp2p standalone interface packages (new breaking change libp2p w/ other deps), add tsdoc for referenced types, setting up/fixing prettier/eslint conflict\n\nDeveloper Experience (2023) {E:2023-eco-growth}\n\nachieved: non blocking pipeline step (https://github.com/waku-org/js-waku/issues/1411)\n\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: close the “fallback mechanism for peer rejections”, refactor peer-exchange compliance test\nnext: peer-exchange to be included with default discovery, action peer-exchange browser feedback\n\n\ngo-waku §\nMaintenance {E:2023-qa}\n\nachieved: improved keep alive logic for identifying if machine is waking up; added vacuum feature to sqlite and postgresql; made migrations optional; refactored db and migration code, extracted code to generate node key to its own separate subcommand\n\nC-Bindings Improvement: Callbacks and Duplications {E:2023-many-platforms}\n\nachieved: PR for updating the RFC to use callbacks, and refactored the encoding functions\n\nImprove Test Coverage {E:2023-qa}\n\nachieved: Fixed issues reported by the data race detector tool.\nnext: identify areas where test coverage needs improvement.\n\nRLN: Post-Testnet3 Improvements {E:2023-rln}\n\nachieved: exposed merkle tree configuration, removed embedded resources from go-zerokit-rln, fixed nwaku / go-waku rlnKeystore compatibility, added merkle tree persistence and modified zerokit to print to stderr any error obtained while executing functions via FFI.\nnext: interop with nwaku\n\nIntroduce Peer Management {E:2023-peer-mgmt}\n\nachieved: add service slots to peer manager.\nnext: implement relay connectivity loop, integrate gossipsub scoring for peer disconnections\n\n"},"waku/updates/2023-08-21":{"title":"2023-08-21 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-08-21 Waku weekly §\n\nEco Dev §\nAug 2023 {E:2023-eco-growth}\n\nachieved: +20% increase on twitter followers and had a discussion with digital comms team regarding improving Waku’s metrics on social handles. Migration of all ecodev elements from github to notion has also been initiated.\nnext: publish the metrics dashboard after call with Vaclav and publish draft for advocates program. Also coordinate with Lou regarding ETHRome hackathon.\nblocker: none\n\n\nDocs §\nAdvanced docs for js-waku\n\nachieved: added guide for js-waku debugging and running in NodeJS - PR111\nnext: js-waku encryption guides\n\n\nResearch §\n1.1 Network requirements and task breakdown {E:2023-1mil-users}\n\nachieved: Breakdown and assign tasks under each milestone for the 1 million users/public Waku Network epic.\nnext: Refine/discuss task breakdown. Start working on Waku Network RFC.\n\n\nnwaku §\nSharded peer management and discovery {E:2023-peer-mgmt}\n\nachieved: discv5 ENR update & filter predicate run-time updating\nnext: PRs feedback updates\n\nAutosharding v1 {E:2023-1mil-users}\nachieved: Complete! FILTER, LIGHTPUSH and RFC merged.\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added. V2 implementation done wait for PR review\nnext: Testing and add even more tests for failure cases.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: breaking change for @noble/secp256k1 PR in progress, redo trailing commas PR\n\nDeveloper Experience (2023) {E:2023-eco-growth}\n\nachieved: set default fallback fro NodeRequirements\n\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: peer-exchange included by default (PR opened)\nnext: tasks breakdown and followup from dogfooding feedback\n\n\ngo-waku §\nRLN enabled by default {E:2023-rln}\n\nachieved: removed registration capability from the wakunode and created a separate subcommand to do the registration\nnext: run rln-relay on all configured pubsub topics and content topics\n\nMaintenance {E:2023-qa}\n\nachieved: refactored wakuv2 metrics to make each protocol responsible for registering and defining its own metrics\n\nRLN: Post-Testnet3 Improvements {E:2023-rln}\nachieved: interop with nwaku.\n\nIntroduce Peer Management {E:2023-peer-mgmt}\n\nachieved: implement relay connectivity loop, log reachability status reported with help of AutoNAT service, local testing using waku simulator and bug fixes\nnext: work towards dogfooding new peer mgmt with Status\n\n"},"waku/updates/2023-08-28":{"title":"2023-08-28 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-08-28 Waku weekly §\n\nEpics §\nStatus MVP: Status Core Contributors use Status Mobile {E:2023-light-protocols}\nLight push and filter protocols are available in Status Mobile and Desktop. Some light dogfooding has started.\n\nResearch §\n1.1 Network requirements and task breakdown {E:2023-1mil-users}\n\nachieved: Further task refinement and assigning ownership. Visibility and traceability via GH issues.\nnext: Start working on Waku Network RFC.\n\n\nnwaku §\nsetting up static sharding fleet for Status {E:2023-10k-users}\n\nachieved: final infra definition, including generated keys and shards, specified in infra-status issue\nnext: ensure fleet gets deployed as specified\n\nRelease Process Improvements {E:2023-qa}\n\nachieved: added a CI job to notify on unexpected config option or DB schema changes\nnext: document how to run PR built images in waku-simulator, adding Linux arm64 binaries and images\n\nPostgreSQL {E:2023-10k-users}\n\nachieved: new docker compose in test-waku-query that allows to quickly compare insert and query performance between SQLite and Postgres.\nnext: Carry on with stress testing & follow-up of the Postgres addition to wakuv2.shards by the infra team.\n\nnwaku c-bindings {E:2023-many-platforms}\n\nachieved: Started applying thread-safe recommendations, making the Waku Node instance to be created within the Waku Thread itself.\nnext: Carry on with the thread-safety recommendations: avoid using Channel to communicate main thread and the Waku Thread.\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added. V2 implementation done wait for PR review\nnext: Finish rebase to master, manual adapt of autoshard feature into Filter v2.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: store protocol refactor for readability\n\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: break down dogfooding into tasks for peer-exchange\n\nCover Several Environments As Part of Testing {E:2023-qa}\n\nachieved: created front-end app to be run in a pipeline\nnext: complete app and run in the pipeline, figure out next steps to run Firefox\n\n\ngo-waku §\nRLN enabled by default {E:2023-rln}\n\nachieved: run rln-relay on all configured pubsub topics and content topics, added metrics, made RLN database aware of chainID and contract address, refactored keystore.\nnext: test keystore interop with nwaku, integrate waku rln registry, and restore valid roots from DB\n\nAuto-sharding v1 {E:2023-1mil-users}\n\nachieved: Implemented core logic for autosharding\nnext: API changes for autosharding\n\nImprove Test Coverage {E:2023-qa}\n\nachieved: Improved test coverage in utils.\n\nIntroduce Peer Management {E:2023-peer-mgmt}\n\nachieved: Raised PR in status-go to use this version in order to dogfood. Local testing with status desktop\nnext: Dogfood changes with Status desktop and mobile using Waku CC’s\n\n"},"waku/updates/2023-09-04":{"title":"2023-09-04 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-09-04 Waku weekly §\n\nEpics §\n1.1 Network requirements and task breakdown {E:2023-1mil-users}\n\nachieved: Started working on Waku Network RFC. Visibility and traceability in GH improvements.\nnext: Continue working on Waku Network RFC.\n\n\nnwaku §\nsetting up static sharding fleet for Status {E:2023-10k-users}\n\nachieved: negotiation with infra to improve fleet definition, clarify postgresql deployment\nnext: ensure fleet gets deployed as specified\n\nRelease Process Improvements {E:2023-qa}\n\nachieved: minor fixes in GH action workflows, building experimental (i.e. RLN enabled) image per-PR to simlify RLN testing/simulations\nnext: document how to run PR built images in waku-simulator, adding Linux arm64 binaries and images\n\nPostgreSQL {E:2023-10k-users}\n\nachieved: Download and start configuring jmeter to have a variable number of clients sending concurrent Store requests.\nnext: Carry on with stress testing & follow-up of the Postgres addition to wakuv2.shards by the infra team.\n\nnwaku c-bindings {E:2023-many-platforms}\n\nachieved: Merged PR that made the Waku Node to be created within the Waku Thread. Submitted a PR that aims to make a safer the communication between the main thread and the Waku Thread.\nnext: Merge the PR to enhance communication between threads and start extracting the thread context outside the library (comment: https://github.com/waku-org/nwaku/pull/1865#discussion_r1282722954).\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:2023-many-platforms}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added. V2 implementation done wait for PR review\nnext: Complete Filter v2 PR foundings fixes.\nblocking: PR review found a design flow, need a little redesign.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: @chainsafe/libp2p-gossipsub is updated\n\nDeveloper Experience (2023) {E:2023-eco-growth}\n\nachieved: pre-emptive stream creations for light protocols, using lowest latency peers for light protocols (WIP)\nnext: merging lowest latency peer PR\n\nWaku Relay scalability in the Browser\n\nachieved: complete PoC of Waku Relay over WebRTC using circuit relay\nnext: pause this to prioritize Waku Network milestone\n\nCover Several Environments As Part of Testing {E:2023-qa}\n\nachieved: finishing testing against chrome and react;\nnext: investigate other adding browsers;\n\n\ngo-waku §\nRLN enabled by default {E:2023-rln}\n\nachieved: test keystore interop with nwaku, integrate waku rln registry, and restore valid roots from DB\nnext: ordered validator execution, bandwidth validation, upgrade zerokit\n\nMaintenance {E:2023-qa}\n\nachieved: allow mixing named and static shards, logs successful message pushes, concurrency fixes for filterv2\n\nAuto-sharding v1 {E:2023-1mil-users}\n\nachieved: Implemented new config for autosharding and ENR updates with shard info\nnext: update various protocols to autoshard\n\n"},"waku/updates/2023-09-11":{"title":"2023-09-11 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-09-11 Waku weekly §\nResearch §\n1.1 Network requirements and task breakdown {E:1.1 Network requirements and task breakdown}\n\nachieved: Opened first raw version of Waku Network RFC for review.\nnext: Address any feedback on the Waku Network RFC and complete under-defined sections.\n\n\nDocs §\nReview Usage and Metrics 2023 Q3 {E:Define network and community metrics}\n\nachieved: published the language/SDK poll on Discord\nnext: publish the poll on socials for more visibility and responses\n\nDocs general improvement/incorporating feedback (2023)\n\nnext: refactor the layout of the docs to match the new designs\n\n\nnwaku §\nfeat(rest): Add /health endpoint to rest api {E:REST API service node}\n\nachieved: Feature /health endpoint added. PR merged: https://github.com/waku-org/nwaku/pull/2011\n\nfeat: Autosharding API for (relay) subscriptions {E:1.2: Autosharding for autoscaling}\n\nachieved: Refactored and simplified the core logic\nnext: More PR feedback\n\nRelease Process Improvements {E:Automated release processes}\n\nachieved: execute js-waku tests from nwaku workflows against PRs, nightly and release candidates\nnext: adding Linux arm64 binaries and images\n\nPostgreSQL {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}\n\nachieved:\n\nCreated a jmeter test plan to stress Store queries through REST Store. As a conclusion, the node with Store Postgres showed worse performance than the one with SQLite.\nhttps://github.com/waku-org/test-waku-query/pull/5\nAdded reconnection feature. If the connection with Postgres is lost, the nwaku node tries to reconnect again. https://github.com/waku-org/nwaku/pull/1997\nThe wakuv2.shards fleet had been de-prioritized in favor of the status.shards one.\nhttps://github.com/status-im/infra-nim-waku/issues/74#issuecomment-1710514544\n\n\nnext: Optimize database so that the Store requests behave better with Postgres.\n\nchore: do not advertise MAs with port 0 {bug}\n\nnext: analyze and fix issue\n\nfeat: HTTP REST API: Filter support v2 {E:REST API service node}\n\nachieved: PR tracking is https://github.com/waku-org/nwaku/pull/1890\nReview is done, various fixes upon applied\nnext: Last, agreed interface change to be done to complete.\n\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\nnext: analyze and fix issue\n\nbug: 0.0.0.0 included in listenAddrs of identify message {bug}\n\nachieved: fixed bug, updated tests according to new fixes and raised PR\n\nnwaku c-bindings (NodeJS + Python) {E:NodeJS Library}\n\nachieved: improved the thread safeness communication.\nhttps://github.com/waku-org/nwaku/pull/1978\nnext: Once the above PR is merged, avoid the use of global variables, to enhance the thread-safeness ( see https://github.com/waku-org/nwaku/pull/1865#discussion_r1282722954 )\n\nHTTP REST API: Store, Filter, Lightpush, Admin and Private APIs {E:REST API service node}\n\nachieved: Legacy Filter - v1 - interface Rest Api support added. V2 implementation done wait for PR review, /health rest api added to check (currently) RLN readiness\nnext: Last round of Filter v2 PR review with finalized re-worked push handler part.\nblocking: /health endpoint come in and Filter v2 work was down prio till.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: updated typescript + plugins to major versions, waiting to merge for release\n\nDeveloper Experience (2023) {E:2023-eco-growth}\n\nachieved:\n\ninvestigation of go-waku interop test that is failing - ongoing, fixing next release\nprotocols now use lowest latency peer instead of a random peer\n\n\nnext: root cause go-waku interop test failure, release next tag on master merge\n\nPeer Exchange is supported and used by default {E:2023-light-protocols}\n\nachieved: Peer Exchange is now merged included in defaultBootstrap\nnext: followup on browser investigation and confirm if the EPIC can be safely closed\n\nCover Several Environments As Part of Testing {test}, {E:2023-qa}\n\nachieved: browser testing is redone and opening for review\nnext: integrate with release process - rather quick follow up, revisit current epic\n\n\ngo-waku §\nRLN enabled by default {E:3.2: Basic DoS protection in production}\n\nachieved:\n\nordered validator execution, upgrade zerokit, append rln proofs when posting msgs in rest/rpc, clean up nullifier table, automatically use key from keystore if only a single credential is available, validate credential using onchain query\nrln membership registration logic refactoring and fixing bugs. Added test for membershipFetcher. Added code for mock_blockchain and mock_client to test membershipFetcher.\n\n\nnext: bandwidth validation, rln isReady verif in /health endpoint, subcommand to list credentials\n\nMaintenance {E:2023-qa}\n\nachieved:\n\nfix panic observed in peer-manager, update filter protocol as per rfc.\nadd tls/ws to address factory and log ENRs only after they have been setup\nrefactoring and some bug fixes in peermanager and read rfcs and docs\n\n\nnext: increase test coverage and read more code.\n\nImprove Test Coverage {test}\n\nachieved: build examples as part of CI to capture compile errors\n\n"},"waku/updates/2023-09-18":{"title":"2023-09-18 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-09-18 Waku weekly\n\nEpics §\n1.1 Network requirements and task breakdown {E:1.1 Network requirements and task breakdown}\n\nachieved: Further specifications added for RLN. Merged and published first version of RFC\nnext: Define first launchable (sub)network for Devconnect.\n\n\nDocs §\nAdvanced docs for js-waku\n\nachieved: added guide for local development with nwaku\n\nNode operator doc - cloud and advanced options\n\nachieved: added guide on advanced nwaku and WebSocket configurations\nnext: add guide for enabling node monitoring\n\n\nResearch §\nRLN Key Benchmarks {E:3.2: Basic DoS protection in production}\n\nachieved: benchmark rln, see issue with report.\n\n\nnwaku §\nfeat: HTTP REST API: lightpush {E:REST API service node}\n\nachieved:\nnext: LightPush REST endpoint will be implemented fully and put on PR review\nblocking:\n\nbug: wrong user_version in sqlite database that blocks the run of a Waku node {bug}\n\nachieved: bug fix that prevented a Store nwaku to start if the SQLite db was created with versions [0.14.0 - 0.18.0]\n\nfeat: Autosharding API for (relay) subscriptions {E:1.2: Autosharding for autoscaling}\n\nachieved: many PR fixes,\nblocker: explicit subscriptions in js-waku tests\n\nchore(rln-relay): Requirements to consider RLN ready (non experimental) {E:3.1: DoS requirements and design}\n\nachieved: waku rln is not an experimental feature anymore, and is part of nwaku code base. from now on experimental features are hidden behind a flag and not in different build\n\nchore: do not advertise multiaddr with port 0 {bug}\n\nachieved: tested two different solutions: updating the port with an addressMapper, and not allowing the user to use port 0. Analyzed and discussed technical implications of both solutions. Initially followed decision to proceed with 2nd solution for now, with intention of implementing the first solution in the future.\n\nOpened a draft PR and updated tests for the solution of not allowing the user to choose port 0.\n\n\nnext: after further feedback received today, we have to complete the discussion of how to move forward and either review and proceed with current PR, or plan and implement solution that updates all the data structures consistently across the node\n\nfeat: HTTP REST API: Filter support v2 {E:REST API service node}\n\nachieved: Filter v1 & v2 REST API endpoints merged to master\nnext: LightPush REST endpoint\n\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\nachieved: implemented solution that does DNS IP resolution during node bringup when no external IP is found but a DNS address is provided.\n\nValidated and tested “happy paths” of the solution, raised draft PR and got feedback about the solution\n\n\nnext: discuss and define the system’s behavior on errors, implement error handling and adding tests for this feature.\n\n\njs-waku §\nMaintenance {E:2023-qa}\n\nachieved: added logs, investigated issues reported\nnext: approach reported issues, add preventative measures\n\nCover Several Environments As Part of Testing {test}, {E:2023-qa}\n\nachieved: got reviews on playwrights tests\nnext: maybe add bounty, check Karma testing\n\n\ngo-waku §\nfeat: discovery & peer management for static shards {E:1.4: Sharded peer management and discovery}\n\nachieved: Update WakuPeerStore to store pubSubTopics for a peer.\nnext: Sharded Peer Management considering static sharding for Status communities.\n\nRLN enabled by default {E:3.2: Basic DoS protection in production}\n\nachieved: isReady verif in /health endpoint, make RLN available in service nodes and library usage by default, update docs and docker image, use zerokit 0.3.4, allow running service node with no RLN credentials\nnext: bandwidth validation, subcommand to list credentials\n\nMaintenance {E:2023-qa}\n\nachieved: CommonService for embedding lifecycle operation in lightpush,discv5,filter,peerConnector etc.\nnext: after discussion with richard prem, use create 2 different types of commonService. Change nameServer flag functionality in go-waku to nwaku. And work on newly created tasks.\n\nImprove Test Coverage {test}\n\nachieved: replace golint by revive, and add make lint-full target to run linting with many more rules enabled\n\n"},"waku/updates/2023-09-25":{"title":"2023-09-25 Waku weekly","links":[],"tags":["waku-updates"],"content":"nwaku §\nfeat: RLN support for Nwaku-Compose {E:3.2: Basic DoS protection in production}\n\nachieved: added RLN flags run_node.sh (including the optional ones), added RLN related environment variables to docker-compose.yml, added RLN metrics’ visualizations to Grafana and updated the README to account for the new changes. Improved implementation based on feedback.\nnext: test the use of optional parameters, get feedback for new version, and merge as soon as all the comments get addressed\n\nchore: bump vendor dependencies for 0.21.0 {dependencies}\n\nachieved: Bumped all dependencies and prepared to 0.21.0. We will start doing this regularly after each release.\n\nfeat: HTTP REST API: lightpush {E:REST API service node}\n\nachieved: Lightpush REST API endpoint merged to master\nnext: Admin REST endpoint, extended health endpoint, Full swagger doc of nwaku rest API interface\n\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\nachieved: peer manager can filter peer by shard, filter discv5 bootstrap nodes by shard, external APIs moved out of node folder\nnext: refactor APIs handlers to discover peers if none is found in peer manager with the required capability\n\nfeat: Autosharding API for (relay) subscriptions {E:1.2: Autosharding for autoscaling}\n\nachieved: fixed js-waku nwaku interop test\nblocker: js-waku PR not merged\n\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\nachieved: added error handling and tests, received new feedback and addressed the comments\nnext: get the new version reviewed and merge if approved\n\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\nachieved: implemented solution that does DNS IP resolution during node bringup when no external IP is found but a DNS address is provided.\nValidated and tested “happy paths” of the solution, raised draft PR and got feedback about the solution\nnext: discuss and define the system’s behavior on errors, implement error handling and adding tests for this feature.\n\nnwaku c-bindings (NodeJS + Python) {E:NodeJS Library}\n\nachieved: Use of ‘ThreadSignalPtr’ instead of loop to handle req/resp.\nhttps://github.com/waku-org/nwaku/pull/2045\nnext: Avoid the use of global variables, to enhance the thread-safeness ( see https://github.com/waku-org/nwaku/pull/1865#discussion_r1282722954 )\n\n\njs-waku §\nPeer Exchange is supported and used by default {E:2.1: Production testing of existing protocols}\n\nachieved: The Peer Exchange Epic is now completed & closed\n\nCover Several Environments As Part of Testing {test}, {E:Comprehensive dev testing}\n\nachieved: improved karma testing, added testing in browser\n\n\ngo-waku §\nfeat: discovery & peer management for static shards {E:1.4: Sharded peer management and discovery}\n\nachieved: handle dynamic topic sub/unsub and update peerMetadata.\nnext: relay peer mgmt for static/auto sharding\n\nfeat: Autosharding API for req-resp protocols {E:1.2: Autosharding for autoscaling}\n\nachieved: Completed Filter API and lightClient changes for autosharding\n\nAdd postgresql to the unit tests {test}\n\nachieved: Add test for store query creation functionality, and change store test to use postgres. Add tests for postgres module.\n\n"},"waku/updates/2023-10-02":{"title":"2023-10-03 Waku Weekly","links":[],"tags":["waku-updates"],"content":"waku-rust-bindings §\nfeat: filterv2 support {E:RLN non-native SDKs}\n\n\nachieved: added support for unsubscribe, ping and unsubscribe_all filterv2 functions of go-waku c-bindings\n\n\nnext: add support to subscribe\n\n\n\nnwaku §\nfeat: Implement /admin Rest Api endpoint\n\n\nachieved:\n\n\nnext: /admin rest endpoint feature is on PR review will be merged next week. Restructure openapi descriptions and producing swagger ui like live document of all rest interfaces.\n\n\nblocking: There are two build issues. libwaku cannot build on Fedora (RedHat) distros. Second, Abhi reported a build issue with wakunode2 - nim compiler crash under some circumstances.\n\n\nfeat: RLN support for Nwaku-Compose {E:3.2: Basic DoS protection in production}\n\n\nachieved: finished addressing feedback\n\n\nnext: task is blocked until there’s an easier method for users to register RLN credentials\n\n\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\n\nachieved: newly refactored STORE REST API handler that trigger discv5 peer search when needed.\n\n\nnext: refactor other APIs\n\n\nPostgreSQL {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}\n\n\nachieved:\n\n\nBetter dburl parse that accepts host names with dashes and dots.\n\n\nProperly set the compilation flag -d:postgres so Docker images are compiled with support to Postgres (with libpq5 dependency.)\n\n\nDuring the stress testing, I discovered that the max throughput seems not to be directly related to Postgres. If I make the code to ignore Postgres and return immediately a mocked response, then the throughput is even lower.\n\n\nnext: Carry on with “select” performance analysis and analyze it directly from a Store client, rather than having REST <-> Store_Client <-> Store_Server. By ignoring the REST layer we will have a better insight into the actual Store protocol, as @jm-clius recommended to me some time ago.\n\n\nchore: add retention policy with GB or MB limitation {enhancement}, {E:PostgreSQL}\nAdded the new retention policy based on DB size.\nUsers can provide the size such as <size_number><case_insenstive_gb_or_mb> ex. 30gb (which is also the default)\n--store-message-retention-policy=size:25GB\n--store-message-retention-policy=size:25gb\n--store-message-retention-policy=size:250MB\n--store-message-retention-policy=size:250mb\nTest case also added.\nOutdated messages/rows are deleted to suffice the size limit, with 20% size reduction upon overflowing.\nchore: update resolved enr ip when using dns4-domain-name flag {enhancement}\n\n\nachieved: addressed feedback and merged\n\n\nchore: improve test coverage on NetConfig generation\n\n\nachieved: developed the new NetConfig test suite, raised PR, received and implemented feedback and merged.\n\n\nnwaku c-bindings (NodeJS + Python) {E:NodeJS Library}\n\n\nachieved:\n\n\nAdded a simple cpp example to the main code. https://github.com/waku-org/nwaku/pull/2079.\n\n\nSubmitted a PR where we start showing the doability of a Rust integration with the libwaku.\n\n\nThis PR is currently introducing the thread-safety enhancement of avoiding using global variables. Ideally, this should be in a separate PR. https://github.com/waku-org/nwaku/pull/2089.\nNotice that it was important to invest time in the Rust example so that we can carry on with the “callback” technique to exchange information between the host code (any) and the foreign code (Nim.)\n\n\nnext: Separate the PR mentioned above and submit another one which only avoids using global variables but doesn’t add the wip-Rust integration.\n\n\n\njs-waku §\nStatic Sharding {E:Static sharding}\n\n\nachieved: allowing for multiple pubsub topics to be configured & refactoring protocols to support\n\n\nnext: enabling peer management to only dial relevant shards\n\n\n\ngo-waku §\nrefactor: add user_data to c-bindings {E:RLN non-native SDKs}\n\n\nachieved: updated all the functions to include an additional void* user_data parameter\n\n\nfeat: discovery & peer management for static shards {E:1.4: Sharded peer management and discovery}\n\n\nachieved: basic relay peer mgmt for static/auto sharding\n\n\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\n\nachieved: Peer selection updated to be based on pubsubTopic or contentTopic\n\n\nnext: Update lightClient API to consider new peerSelection options\n\n\nfeat: Autosharding API for req-resp protocols {E:1.2: Autosharding for autoscaling}\n\n\nachieved: Updated lightpush API for autosharding\n\n\n\nEcoDev §\nOctober 2023\n\nETHSafari bound and was mostly travelling last week\n"},"waku/updates/2023-10-09":{"title":"2023-10-09 Waku Weekly","links":[],"tags":["waku-updates"],"content":"\nnwaku §\nfeat: Implement /admin Rest Api endpoint {E:REST API service node}\n\nachieved: /admin Rest API endpoint implemented\nnext: Restructure openapi descriptions and producing swagger ui like live document of all rest interfaces. Restructure Rest API schema types.\n\nchore: notify user if docker-compose fails {enhancement}, {E:3.2: Basic DoS protection in production}\n\nachieved: discussed the issue with colleagues, implemented the solution and closed the issue\n\nfeat: allowing users to choose port 0 for dynamically allocated ports {enhancement}\n\nachieved: analyzed code and found the different data structures affected by the dynamic port allocation. Considered the implications of different approaches to solve the issue, discussed and translated the different options into code.\nStarted the implementation of the chosen solution, with part of the solution already working.\nnext: complete the first working version of the solution, improve its design/architecture, and test.\n\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\nachieved: Filter, Store, Light push REST APIs discovery handler (a rework of the previous solution)\n\nsetting up static sharding fleet for Status {E:Static sharding}\n\nachieved: fleet has been deployed, PostgreSQL setup has been tested.\nnext: Do some basic dogfooding with Status Desktop.\n\nPostgreSQL {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}\n\nachieved: Applied performance comparison between SQLite and Postgres but in this case, making direct requests from a go-waku unittest that @richard-ramos had prepared.\nAfter directly comparing the Store protocol, noticed that the bottle neck is within the database itself. i.e. the SQLite database performs better than Postgres, given that we have a very simple schema and simple queries, without joins. Adding indexes to the Postgres database didn’t help very much. For example, given the same query, SQLite takes 1ms whereas Postgres takes 6ms.\nnext:\n\nWrap up the Store testing environment and install it into our sandbox machine, metal-01.he-eu-hel1.wakudev.misc.statusim.net, so that anyone can proceed from this point (two databases with the same dataset of ~2 million rows .) in case someone is keen on analyzing performance or debug in a more realistic testing scenery. This will include concurrent queries from multiple nodes, where PostgreSQL is expected to perform better.\nStart extracting the database creation and indexes creation to outside the code base.\n\n\n\nchore: add retention policy with GB or MB limitation {enhancement}, {E:PostgreSQL}\nIn review: the database bug to delete limited messages/rows\nUpcoming/working: updated retention policy + test + missing tes on timestamp based retention policy\nUndergoing: MUID concept on message level\nfeat: provide a way to define advertised addresses {enhancement}\n\nachieved: went over the code and found the root cause of the issue and a preliminary solution\nnext: finish discussing the approach to the solution and implement it\n\n\njs-waku §\nStatic Sharding {E:Static sharding}\n\nachieved: PR open for allowing peer management for multiple pubsub topics/shard\nnext: getting reviews & releasing\n\nPeer Management: Connection and Disconnection {track:restricted-run}, {E:2.1: Production testing of existing protocols}\n\nachieved: investigated & closed #1412\nnext: look into addressing deliberate vs accidental disconnections\n\n\ngo-waku §\n\nTeam attended EthRome\n"},"waku/updates/2023-10-16":{"title":"2023-10-16 Waku weekly","links":[],"tags":["waku-updates"],"content":"nwaku §\nchore: Reorganize RestApi specs for live documentation {E:REST API service node}\n\nachieved: Http RestAPI interface is in parity with json-rpc with even more features supported on it.\nnext: Openapi specification is reorganized and online doc generated out of it. Currently under PR review.\nFollow up spec reorganization with rest api type reorganization. RFC changes to enhance lighpust failure response.\n\nfeat: allowing users to choose port 0 for dynamically allocated ports {enhancement}\n\nachieved: had over code review sessions and got feedback. Implemented improvements, attempted new approaches, fixed bugs. Most of the solution is already implemented and working.\nnext: fix failed tests, add test cases and raise PR\n\nfeat: experimental incentivize store protocol {E:Basic service incentivization}\n\nachieved: wrote the first draft of incentivization outline\nnext: discuss open question, continue structuring the document\n\nsetting up static sharding fleet for Status {E:Static sharding}\n\nachieved: setup a separate shard for community points of contact, and another one for 1:1/group messages\nnext: investigate/fix discv5 not working when static sharding is being used.\n\nPostgreSQL {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}\n\nachieved:\n\nTesting environment prepared in metal-01.he-eu-hel1.wakudev.misc.statusim.net. There are two databases (Postgres and SQLite) with 5 million of random messages.\nEnhanced Grafana dashboard so that we can compare timings performance throughout an histogram.\n\n\nnext: Carry on with the investigation to enhance the Postgres performance.\n\nfeat: provide a way to define advertised addresses {enhancement}\n\nachieved: implemented solution and raised PR\nnext: get feedback, implement suggested improvements and close\n\nnwaku c-bindings (NodeJS + Python) {E:NodeJS Library}\n\nachieved:\n\nSeparate PR to avoid global variables: https://github.com/waku-org/nwaku/pull/2118\nStarted to document the tasks tackled so far: https://www.notion.so/NWaku-cbindings-FFI-7a9ae6240cfc4caba7c7ff0bf3429a70\n\n\nnext: Start creating a separate NodeJs and Python repositories, where we will create nodejs-waku and py-waku, respectively.\n\n\njs-waku §\nPeer Management: Connection and Disconnection {E:2.1: Production testing of existing protocols}\n\nachieved: reached a conclusion tackling deliberate vs accidental disconnections, PRs opened to handle Filter subscriptions on disconnection/reconnections, iterative fixes on addressing multiple dial attempts for same peer, fixes around keep alive pings\nnext: getting reviews & merging these PRs which should enable us to close this epic 🥳\n\n\ngo-waku §\nfeat: Service peer selection on specific shards {E:1.4: Sharded peer management and discovery}\n\nachieved: refactor and migrate peer selection to peer manager and update lightclient API to use new options\nnext: on-demand discovery if peers are not available for the shard\n\nAdd postgresql to the unit tests {test}\n\nachieved: Completed. Fixed only sqlite being used for creating queries.\n"},"waku/updates/2023-10-23":{"title":"2023-10-23 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-10-23 Waku weekly §\nWaku Network Can Support 10K Users §\n\nachieved:\n\nVac/DST team has done further runs with up to 600 nodes in the network as part of wrapping up a blog post report.\nStaging fleet for Status with static sharding and PostgreSQL deployed and being tested by go-waku team using local changes in Status Desktop.\n\n\nnext:\n\nDogfooding of Status Desktop with Status staging fleet. Will aim to create a small internal Waku community.\nContinue integration of static sharding in status-go.\n\n\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nPostgreSQL implementation has not yet been proven more performant than SQLite. Further improvements and testing in progress.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: hardcoded bootnodes ENRs in addition to DNS Discovery URLs as a way to overcome nameserver issues. Use a static shard instead of the default pubsub topic. Update tool to crawl and discover nodes via discv5.\nnext: fix if necessary strange behavior with discv5 when ENRs in DNS discovery URL do not contain shards. Document steps for dogfooding.\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved: See 10k milestone update for PostgreSQL status.\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under\nvac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\n\n\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nCritical path work for autosharding done in nwaku, in progress on go-waku\nParameters for the Waku Network Gen 0 have been captured in an RFC and use as a basis for simulations and theoretical analysis, removing uncertainty on this milestone around message rates, performance and expected bandwidth usage.\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one joining at end of Oct) so delivery in this client is likely to lag behind other clients.\n\n\n\n3.2: Basic DoS protection in production §\n[js-waku] Task: Manage RLN membership(s) and keys\n\nachieved: completed flow up items and main stream of work;\n\n[js-waku-examples] feat: re-create rln-js\n\nachieved: experimented with different frameworks, almost complete rewriting the example;\n\n[research] Message propagation times with waku-rln\n\nachieved: Ran simulations with 1000 nwaku nodes with rln enabled, with the goal of measuring message propagation delays under different conditions.\nnext: Some issues with the current simulations, need to investigate shadow tool to simulate CPU “time passing”. Some results are not valid.\n\n2.1: Production testing of existing protocols §\n[js-waku] chore: improve logging when fails to connect to a node\n\nachieved: setup a Logger for more verbose and modular error readbility\n\n[js-waku] Peer Management: Connection and Disconnection\n\nachieved: The Connection and Disconnection Peer Management epic has been closed\n\n[waku-rust-bindings] feat: filterv2 support\n\nachieved: added support to waku_filter_subscribe\nnext: write unit tests for filterv2 and publish new version\n\nQuality Assurance processes are in place - 2024-03-31 §\nThis work is tracked with vac:dst:software-testingwaku\nSupport Many Platforms - 2024-04-30 §\nShip RLN as part of non-native SDKs §\n[go-waku] refactor: add user_data to c-bindings\n\nachieved: exposed filterv2 subscription details (useful for rust bindings)\n\nREST API service node §\n[nwaku] chore: reorganize rest-api types\n\nachieved: Enhancements on Rest request error handling.\nnext: Finalize api spec and doc after PR review. Work in progress: rest api type reorganization. RFC changes to enhance light-push failure response.\nblocking: Fixing found issues during release.\n\n[go-waku] feat: lightpush REST API\n\nachieved: Add lightpush rest api and test. Rest Filter v2 in progress.\n\nOther Work §\nEnhancements §\n[nwaku] feat: allowing users to choose port 0 for dynamically allocated ports\n\nachieved: fixed failed tests, added a test case to cover the changes, small refactor and raised PR\nnext: get PR reviewed and implement feedback\n\n[nwaku] feat: provide a way to define advertised addresses\n\nachieved: merged PR with initial fix. Implemented and raised PR for the --ext-multiaddr-only CLI flag\nnext: get PR reviewed, implement feedback and merge\n\nBugs §\n[nwaku] bug: WSS enabled node stops accepting websocket connections after some time\n\nachieved: discovered and debuged WSS issue, discovered and debugged REST API causing SIGSEGV, oversaw release v0.21.0\nnext: help with release v0.21.1, investigate existing bandwidth management work\n\nEcosystem Development - Docs §\n\nachieved:\n\ngot familiar with what The Graph is doing with Waku, @waku/sdk update in @waku/react\nPreparation to Polygon Enugu\nPeer management disconnection docs\n\n\nnext:\n\nWork on metrics dashboard\nRecord some explainer videos\nDocs redesign\nOutline for encryption docs\n\n\n"},"waku/updates/2023-10-30":{"title":"2023-10-30 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-10-30 Waku weekly §\nWaku Network Can Support 10K Users §\n\nIntegration of static sharding in go-waku is continuing (see updates below).\nTesting of PostgreSQL enabled some performance improvement in the implementation that are being implemented.\nInternal instructions have been distributed to dogfood static sharding with the Waku team (Waku Discord private channel).\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: unsuccesfully tried to avoid introducing a breaking change in status-go. We need to decide whether to go ahead and merge that PR\nblocker: discv5 filters out outdated ENR entries from DNS Discovery URL in shard fleet - https://github.com/waku-org/nwaku/issues/2162\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nSee 10k milestone update for PostgreSQL status.\nFirst version of the 10k-tool by DST is ready and is being tested with simulation running a small nim-libp2p/gossipsub binary.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under\nvac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\n\n\n\nPostgreSQL in service node: Further optimisations §\n[nwaku] PostgreSQL\n\nachieved:\n\nTime processing enhancement when performing SELECT operations. There was an overhead caused by looping too many times over the returned rows, in order to convert the row types. By applying a “rowCallback” approach we can reduce by 30ms the time spent on the query under analysis.\n\n\nnext:\n\nThe queries used in the comparison analysis still perform much better in SQLite (< ~5ms) than in Postgres (< ~15ms.) Therefore we need to push the investigation further to enhance that.\n\n\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nFurther simulation done, with a continued focus on message propagation time and possible improvements.\nProgress across all client son sharded peer management discovery\nFirst PRs merged towards basic distributed store services\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.\n\n\n\n3.2: Basic DoS protection in production §\n[nwaku] feat: add rln to waku simulator instance\n\nachieved: learnt about waku-simulator’s inner workings and got the background required to integrate RLN to it. Added service that generates traffic to the nodes via their REST APIs. Investigated and tested different ways of approaching the RLN integration.\nnext: get RLN to work and add Grafana dashboards with RLN data\n\n[js-waku-examples] feat: re-create rln-js\n\nachieved: addressed flaws in integration, completed rewriting;\n\n[research] Tuning GossipSub’s D parameter in Waku\n\nachieved: nwaku simulations showing the impact in message propagation delay when reducing gossipsub’s D value. Main goal is to reduce bandwidth consumption in exchange of worsen propagation delay.\nnext: asses if we want to move forward changing D.\n\n[research] Message propagation times with waku-rln\n\nachieved: Final simulation results with 1000 nwaku nodes with rln enabled, with the goal of measuring message propagation delays under different conditions (amount of nodes and message size).\nnext: NA\n\n1.4: Sharded peer management and discovery §\n[nwaku] feat: Service peer selection on specific shards\n\nachieved: REST APIs discovery handlers PR merged\n\n[nwaku] feat: Peer management with shard as a dimension\n\nachieved: Waku Metadata shard subscriptions, Sharded relay peer management, draft sharded peer store pruning\nnext: finalize sharded peer store pruning & run simulations\n\n[go-waku] feat: Deprecate Named Sharding and Update Lightpush Client API\n\nachieved: Create PR for review for removing of Named Pubsubtopic.\n\n[go-waku] feat: Service peer selection on specific shards\n\nachieved: draft PR #834 opened for on-demand peer discovery\nnext: use on-demand peer discovery for service and relay peer selection\n\n2.3: Basic distributed Store services §\n[nwaku] feat: add new message_hash column to the archive protocol\n\nachieved: On SQLite’s schema transition (i.e. this PR) to messageHash feature complete PR posted (awaiting reviews), Gained insight into the connection and interplay between the store and archive components, and how they may be leveraged into making a sync protocol. Small stuff - bug fix on the jsWaku which was this PR dependent (that too was time-consuming since my first time interacting with JS code of waku), PR on vacuum on time-based retention policy, thought through the nitty gritty details of node based roles and incentives.\nnext:\n\nThe sync protocol formulation totally based on the messages sync without any external factors into POV\nReview PostgreSQL PRs by Ivan to gain more knowledge on the storage/archive feature.\n\n\n\n2.1: Production testing of existing protocols §\n[nwaku] PostgreSQL\n\nachieved:\n\nTime processing enhancement when performing SELECT operations. There was an overhead caused by looping too many times over the returned rows, in order to convert the row types. By applying a “rowCallback” approach we can reduce by 30ms the time spent on the query under analysis.\n\n\nnext:\n\nThe queries used in the comparison analysis still perform much better in SQLite (< ~5ms) than in Postgres (< ~15ms.) Therefore we need to push the investigation further to enhance that.\n\n\n\n[waku-rust-bindings] feat: filterv2 support\n\nachieved: fix issues found during testing\nnext: publish new version\n\nQuality Assurance processes are in place - 2024-03-31 §\nSupport Many Platforms - 2024-04-30 §\nPresentation Readiness §\n[js-waku] feat: better support for development\n\nachieved: experimented with Next.js app;\nnext: looking for ways to mitigate errors in console or catch others;\n\nShip RLN as part of non-native SDKs §\n[go-waku] refactor: add user_data to c-bindings\n\nachieved: fixed issues found during tests with waku-rust-bindings\n\nREST API service node §\n[go-waku] feat: admin REST API\n\nachieved: Implemented Admin REST API and updated the spec.\n\nEcosystem Development §\n\n\nachieved:\n\nnew tictactoe example with @waku/react\nProgress on Devconnect planning\nOrganising dev ex calls\nShipping resources for hackathon\nReviewed Graphcast proposal for using relay\n\n\n\nnext:\n\nipfs/waku example for file transfer\nWaku tutorial videos\n@waku/react hacker pain-point feedback report\nMetrics dashboard\nETHLisbon\n\n\n"},"waku/updates/2023-11-06":{"title":"2023-11-06 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-11-06 Waku weekly §\nWaku Network Can Support 10K Users §\n\nachieved:\n\nfurther PostgreSQL optimisations nearing conclusion\nimplemented bridge to allow Status Community to move to static sharding with backwards compatibility towards default pubsub topic\nsolution for shared bootstrap nodes being filtered out in discv5 as more static shards are activated\nensured no unknown blockers from Waku’s side to start dogfooding in conversation with Status Communities\n\n\nnext:\n\ncontinue integration of static sharding in status-go.\ndeploy bridge for backwards compatibility\ndogfooding of Status Desktop with Status staging fleet. Will aim to create a small internal Waku community\n\n\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\nlack of confidence in simulation results: results so far exhibits various artifacts and anomalies seemingly related to tooling limitations. It is therefore difficult to draw certain conclusions re Waku scalability.\nlack of clarity in terms of Status fleet ownership, monitoring and maintenance, which is an integral part of the solution.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: fix in status-go to use correct unprotected pubsub topic for community point of contacts, added pubsub topic bridge feature to go-waku, stop filtering out bootnodes on discovery, minimize noise on logs when selecting peers and not having peers available.\nnext: deploy bridge between default pubsub topic and shard 32\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nSee 10k milestone update for PostgreSQL status.\nFirst version of the 10k-tool by DST is ready and is being tested with simulation running a small nim-libp2p/gossipsub binary.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under\nvac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\nlack of real world feedback/dogfooding: the complete static sharding solution involves significant changes to the Waku protocol and tech stack. Although each element is unit tested, dogfooding may hit corner cases in the integrated solution that cannot be foreseen/recreated in lab conditions.\n\n\n\nPostgreSQL in service node: Further optimisations §\n[nwaku] PostgreSQL\n\nachieved: Optimize select/Store queries by adding prepared statements. PR\nnext: Wrap up the Postgres optimizations. Summarize the performance comparison in a report.\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nStarting internal dogfooding of Waku Network: We have launched the proto-network and it is already possible to run a node in said network.\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.\nUncertainty as to how RLN membership mechanism would hinder application adoption, if memberships need to be distributed or obtained by registration, if staking is necessary to prevent abuse, etc.\n\n\n\n3.2: Basic DoS protection in production §\n[nwaku] feat: add rln to waku simulator instance\n\nachieved: integrated RLN, added Grafana dashboards, tested, merged and deployed\n\n1.4: Sharded peer management and discovery §\n[go-waku] feat: Service peer selection on specific shards\n\nachieved: on-demand peer discovery for service peer selection and new relay shard subscriptions\n\n2.3: Basic distributed Store services §\n[nwaku] feat: add new message_hash column to the archive protocol\n\nachieved: PR to support SQLite code to support messageHash attribute without interrupting the existing cursor-related functionality, id field stays for now. Skelton for sync in progress.\nnext:\n\nfinalize the SQLite messageHash attribute and add a research page about it.\nstart a research page about the sync mechanism for nWaku, doing request/reply a PoC on the same.\n\n\n\nQuality Assurance processes are in place - 2024-03-31 §\nSupport Many Platforms - 2024-04-30 §\nPresentation Readiness §\n[js-waku] feat: better support for development\n\nachieved: by going through basic flow identified errors that can or cannot be ignored;\nnext: working on improving log errors, aiming to complete in couple of days;\n\nOther Work §\nEnhancements §\n[js-waku-examples] feat: make light-js example a proper debugging tool\n\nachieved: added peer dropdown, list of connected peers, and button for querying past messages using store\nnext: will take on my first issue in js-waku\n\nBugs §\n[js-rln] bug: proof is not verified\n\nachieved: as per suggestion investigated if the roots are correct, seems found a fix;\n\nDocumentation §\n[docs.waku.org] Advanced docs for js-waku\n\nachieved: added createSubscription() docs in #128\nnext: tackle @waku/sdk deprecated namespace #131, create filter management docs\n\n[docs.waku.org] Node operator doc - cloud and advanced options\n\nachieved: updated nwaku config options in #128, added nwaku published MA option in #130\n\nChores §\n[nwaku] chore: bump vendor dependencies for 0.22.0\n\nachieved: updated dependencies, resolved conflicts, tested and raised PR\nnext: get PR reviewed, implement feedback and merge\n\nEcosystem Development §\n\n\nachieved:\n\nMultiple leads from ETHLisbon.\nSync call with The Graph.\njs-waku prioritizing.\nCreated Hackathon project with Waku at ETHLisbon.\nAwesome-waku updates.\n\n\n\nnext:\n\nReview RLN docs readiness for launch at DevConnect.\nWeb3privacy event preparation.\nWaku network soft-launch organisation.\nCreating tutorial videos.\nETHStaker gathering for gaining some awareness about node operator onboarding.\n\n\n"},"waku/updates/2023-11-13":{"title":"2023-11-13 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Network Can Support 10K Users §\n\nachieved:\n\nfinal PostgreSQL optimisations completed. Benchmarks published: https://www.notion.so/Postgres-e33d8e64fa204c4b9dcb1514baf9c582\nadded “debug nodes” with trace-level message logging to each Status fleet to allow for easier e2e message traceability\nconfirmed no unknown blockers from Waku’s side to continue dogfooding in conversation with Status Communities\n\n\nnext:\n\ncontinue integration of static sharding in status-go.\ndogfooding of Status Desktop with Status staging fleet. Will aim to create a small internal Waku community\n\n\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\nlack of confidence in simulation results: results so far exhibits various artifacts and anomalies seemingly related to tooling limitations. It is therefore difficult to draw certain conclusions re Waku scalability.\nlack of clarity in terms of Status fleet ownership, monitoring and maintenance, which is an integral part of the solution.\n\n\n\nTargeted dogfooding for Status Communities §\n\n\nachieved: deployed bridge between default pubsub topic and shard 32, added UseShardAsDefaultTopic node config option to indicate whether the client should use a shard or the default waku topic. Merged open status-go PRs related to sharding. Initial connection to peers + dns-discovery no longer blocks the login. Updated open status-desktop PR for dogfooding to take into account status-go latest sharding related changes.\n\n\nnext: get https://github.com/status-im/status-desktop/pull/12344 merged.\n\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nBasic Postgresql optimizations completed and benchmarks published. See 10k milestone.\nFirst version of the 10k-tool by DST is ready and is being tested with simulation running a small nim-libp2p/gossipsub binary.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under vac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\nlack of real world feedback/dogfooding: the complete static sharding solution involves significant changes to the Waku protocol and tech stack. Although each element is unit tested, dogfooding may hit corner cases in the integrated solution that cannot be foreseen/recreated in lab conditions.\n\n\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nStarted internal dogfooding of proto-network and started to work on documentation.\nProgressed on capability and sharding discovery.\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.\nUncertainty as to how RLN membership mechanism would hinder application adoption, if memberships need to be distributed or obtained by registration, if staking is necessary to prevent abuse, etc.\n\n\n\n3.2: Basic DoS protection in production §\n[go-waku] bug: handle errors generated in gm.rootTracker.UpdateLatestRoot(pair.Key.(uint64))\n\nachieved: task complete\n\n1.5: Launch and dogfood integrated public Waku Network MVP §\n\nachieved:\n\nLaunched team-internal CC dogfooding with nwaku nodes and RLN Sepolia contract\nIntroduced landing page and tutorials to join the network and publish using nwaku-compose\n\n\nnext:\n\nSoft launch of the network at Devconnect Istanbul\nExtend dogfooding to other clients (js-waku, go-waku)\n\n\n\n1.4: Sharded peer management and discovery §\n[nwaku] feat: Peer management with shard as a dimension\n\nachieved: discv5 filter peer by capability, misc. improvement w.r.t sharding and tests, sharded peer management improvement\nnext: run more simulations\n\n[go-waku] feat(discv5): filter peer by capability\n\nachieved: added capacility in discv5 to filter out peers that do not have waku2 ENR field\n\n1.2: Autosharding for autoscaling §\n[go-waku] feat: Changes to Store protocol APIs for Autosharding\n\nachieved: API updates for autosharding\nachieved: added functions for validating content topic, determining shard index and pubsub topic for autosharding\nnext: configure js-waku node to use either static or auto sharding\nblocker: need my PRs approved/merged. Also best to merge in other open PRs, especially https://github.com/waku-org/js-waku/pull/1697\n\nOther Work §\nEnhancements §\n[nwaku] chore: allow text/plain contentType for rest request’s body types\n\nnext: Allow text/plain contentType on RestApi is on PR, libwaku Fedora build issue\n\n[nwaku] chore: decouple listen and announced addresses\n\nachieved: implemented, tested and raised PR\nnext: get PR reviewed, implement feedback and merge\n\n[waku-rust-bindings] Peer discovery & management \n\nachieved: Worked mainly on rust-waku-bindings issues for go-waku.\nnext: Handle epic 2.2\n\n[go-waku] chore: # chore: remove --store-message-db-vacuum\n\nachieved: removed VACUUM functionality from go-waku, since it’s an operation that must be done by infra instead of being part of go-waku\n\nDocumentation §\n[docs.waku.org] Encryption documentation\n\nnext: begin work on encryption docs\n\n[docs.waku.org] Advanced docs for js-waku\n\nachieved: filter management docs\nnext: deprecated namespace docs #131\n\nChores §\n[nwaku] chore: bump vendor dependencies for 0.22.0\n\nachieved: finished and merged\n\nEcosystem Development §\n\nachieved: SpiffWorkflow x Waku sync\nnext: metrics, web3privacy meetup, DCxPrague talk\n"},"waku/updates/2023-11-20":{"title":"2023-11-20 Waku Weekly","links":[],"tags":["waku-updates"],"content":"2023-11-20 Waku weekly §\nWaku Network Can Support 10K Users §\n\nachieved:\n\nclosed last PostgreSQL issue for Store scalability\nconfirmed no unknown blockers from Waku’s side to continue dogfooding in conversation with Status Communities\nstarted team-internal dogfooding of a test community using static sharding\nstarted fleet ownership handover process: published guidelines/list of responsibilities - https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741\n\n\nnext:\n\ncontinue dogfooding of Status Desktop with Status staging fleet with test community\ntraining session to conclude fleet ownership handover: https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741\n\n\nrisks:\n\nDependency on Vac/DST to conclude ~1k nodes simulations.\nImplementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev (1, 2, 3). See status-go#4057 for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.\nlack of confidence in simulation results: results so far exhibits various artifacts and anomalies seemingly related to tooling limitations. It is therefore difficult to draw certain conclusions re Waku scalability.\nlack of clarity in terms of Status fleet ownership, monitoring and maintenance, which is an integral part of the solution.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: logout / login freeze, fix request on correct pubsub topic, and add missing shard information on community invite\nnext: dogfooding\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nClosed last Postgresql issue for basic Store scalability. See 10k milestone.\nAssisted DST in setting up initial tests with the ~1K tool. Currently still fine-tuning parameters, ensuring results are consistent, etc. for smaller configurations.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under\nvac:dst:eng-10ktool.\nWakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.\nLarge scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.\nlack of real world feedback/dogfooding: the complete static sharding solution involves significant changes to the Waku protocol and tech stack. Although each element is unit tested, dogfooding may hit corner cases in the integrated solution that cannot be foreseen/recreated in lab conditions.\n\n\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nInternal dogfooding of proto-network continues.\nSignificant progress of autosharding in js-waku: autosharding function implemented, work to integrate in protocols started.\n\n\nrisks:\n\nUsage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.\nWe are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.\njs-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.\nUncertainty as to how RLN membership mechanism would hinder application adoption, if memberships need to be distributed or obtained by registration, if staking is necessary to prevent abuse, etc.\n\n\n\n1.4: Sharded peer management and discovery §\n[nwaku] chore: improve cluster id, shards, topics flow\n\nachieved: Various tests updates and fixes.\nnext: Figure out why CI passes locally only.\n\n1.2: Autosharding for autoscaling §\n[nwaku] chore: allow fetching cached messages by content or pubsub topic\n\nachieved: failed refactor of message cache\nnext: a better and simpler message cache\n\n[js-waku] feat: Autosharding API for req-resp protocols\n\nachieved: derive pubsub topic from content topic in encoders/decoders when autosharding is specified\nnext: node config should specify static sharding or autosharding. implement autosharded topics in all req-resp protocols\n\nSupport Many Platforms - 2024-04-30 §\nPresentation Readiness §\n[js-waku] feat: node connection state\n\nachieved: modified ConnectionManager to track connection state. exposed through read function and new event\nnext: resolve any remaining feedback\n\nOther Work §\nEnhancements §\n[nwaku] chore(REST): adding to /admin/v1/peers response lightpush and filter v2 peer info\n\nachieved: implemented, tested and raised PR\nnext: get PR reviewed, implement feedback and merge\n\n[nwaku] chore: allow text/plain contentType for rest request’s body types\n\nachieved: Better support for js-waku using RestApi: Allow text/plain contentType\nnext: Bandwidth management preparation\n\n[nwaku] chore: decouple listen and announced addresses\n\nachieved: got the PR reviewed, implemented feedback and merged\n\nEcosystem Development §\n\nachieved: two talks last week. Logos + Waku at Web3Privacy meetup and RLN at DCxPrague\nnext: afk for a week\n"}} \ No newline at end of file diff --git a/waku/updates/2023-11-20.html b/waku/updates/2023-11-20.html index 307c04e2f..79b14dda1 100644 --- a/waku/updates/2023-11-20.html +++ b/waku/updates/2023-11-20.html @@ -1,5 +1,5 @@ -2023-11-20 Waku Weekly

Logos Collective Project Roadmaps

Search

SearchSearch

2023-11-20 Waku Weekly

Nov 21, 2023, 3 min read

2023-11-20 Waku weekly

+2023-11-20 Waku Weekly

Logos Collective Project Roadmaps

Search

SearchSearch

2023-11-20 Waku Weekly

Nov 21, 2023, 4 min read

2023-11-20 Waku weekly

Waku Network Can Support 10K Users

  • achieved: @@ -49,6 +49,22 @@

Waku Network Gen 0 - 2023-12-01

+
    +
  • achieved: +
      +
    • Internal dogfooding of proto-network continues.
      • +
    • Significant progress of autosharding in js-waku: autosharding function implemented, work to integrate in protocols started.
      • +
    +
    • +
  • risks: +
      +
    • Usage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.
      • +
    • We are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.
      • +
    • js-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.
      • +
    • Uncertainty as to how RLN membership mechanism would hinder application adoption, if memberships need to be distributed or obtained by registration, if staking is necessary to prevent abuse, etc.
      • +
    +
    • +

1.4: Sharded peer management and discovery

[nwaku] chore: improve cluster id, shards, topics flow