diff --git a/sitemap.xml b/sitemap.xml index 9e276c28a..68cb7bc8c 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1302,7 +1302,7 @@ 2024-08-12T23:42:40.905Z https://roadmap.logos.co/waku/updates/2024-08-12 - 2024-08-13T05:10:15.316Z + 2024-08-16T02:59:53.508Z https://roadmap.logos.co/what-is-a-milestone 2024-08-09T17:35:13.062Z diff --git a/static/contentIndex.json b/static/contentIndex.json index 1acf47d35..4af0349e3 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"},"codex/updates/2024-01-22":{"title":"2024-01-22 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Dec 15th - Jan 22th §\n\nThe Codex team is currently wrapping up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\n\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient §\nEpic: Wiring the Proving System §\n\nCompleted:\n\nWire Sampler to SlotBuilder\nExports fromBytes from the library\nConvert from 32 bytes\n\n\nOngoing:\n\nDataset expiry\nUpdate DataSampler to match updated SlotBuilder\nInvestigate: way to run codex tests through valgrind or similar tool\nIntegrate DataSampler in Marketplace callbacks\n\n\n\nEpic: Improve Client Stability §\n\nCompleted:\n\nUpdate to Chronos V4\nAdd exception handling for Chronos V4\nCompiler PR to Chronos V4 bugs\n\n\nOngoing:\n\nCodex CI improvements\nTrack down segfault issue after rebase of Chronos V4 PR\n\n\n\nMarketplace §\nEpic: End-to-end Testing §\n\nCompleted:\n\nAdd working testnet starter\nUpdates to Codex frontend include:\n\nAdd node storage information\nUpload page updates periodically\nChange error messages to appear below input area instead of an alert\n\n\nFinish the Github Workflow to compile, build and setup the circuit with included generated proof for testing\nInitial work on integration of the verifier into smart-contract suite, with passing storage proof tests\nRebase nim-ethers to the latest version, 0.7.1\nRebase create logging proxy had symbol resolution errors, created PR for nim-poseidon2 to resolve and complete rebase\nRebase multinode integration test refactor, had to remove upraises annotations from some callbacks in the tests\nRefactor add MarketError, refactoring ethers error handling, reviewing verifier integration in codex-contracts-eth\nComplete Github Workflow for testing, worked on integration of verifier into smart-contract suit.\nReleased 0.10.13 with improvements, released asynctest 0.5.0,\n\n\nOngoing:\n\nContinue work on Solidity verifier\n\n\n\nInfra §\n\nCompleted:\n\nResolve issues on docs.codex.storage\nAdd documentation about DNS names and convention\nCheck download speed for codex-storage-proofs-circuits\nSwitch from AWS Windows instance to Hetzner\n\n\nOngoing:\n\nDeploy a site to store circuit ceremony files\nDeploy Codex Storage nodes in Testnet cluster\n\n\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\n\nCompleted:\n\nDebug Groth16 implementation, discovered local bug in [constantine], made a CLI interface (+other improvements) for the Groth16 prover\nResearch and solve puzzles for ZK hack IV kickoff\nPlay with binary field used in the new Binius proof system\nCatchup with recent research (https://zkmesh.substack.com/p/zkmesh-dec-2023-recap)\nExplore Nova-Scotia, discussed hash padding\nUpdate Merkle tree proposal document\nExplore Ascon hash as a possible replacement for SHA256\n\n\nOngoing:\n\nPoC Ascon hash implementation in circom (not competitive with other hashes, at least not in circom)\nThink about how to implement SHA256 proofs\nMore learning about lookups and folding\nStart working out the details of an idea about how to do efficient proofs of computations on bits (eg. range checks, classical hash functions)\n\n\n"},"codex/updates/2024-01-29":{"title":"2024-01-29 Codex Weekly","links":[""],"tags":["codex-updates"],"content":"Codex Update Jan 22nd - Jan 29th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\n\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient §\nEpic: Nim Improvements §\n\nCompleted:\n\nFiled Atlas issue to restore handling forked repos\nFiled Atlas issue for handling “vendoring” style setups\n\n\nOngoing:\n\nReview Atlas graph updates and contribute\n\n\n\nEpic: Wiring the Proving System §\n\nCompleted:\nOngoing:\n\nDataset expiry\nUpdate DataSampler to match updated SlotBuilder\nInvestigate: way to run codex tests through valgrind or similar tool\nIntegrate DataSampler in Marketplace callbacks\n\n\n\nEpic: Improve Client Stability §\n\nCompleted:\nOngoing:\n\nContibue rebasing of unmerged Chronos V4 PR and build improvements PR + fixes to initial idea on builds\nContinue work on asynctest branch\nBug-fixing to track down the “file sizes differ” bug\nOther bugs to be fixed\n\n\n\nMarketplace §\nEpic: End-to-end Testing §\n\nCompleted:\n\nFix tests and replcae GPL licensed ZK verifier w/ MIT version that take JSON output from Circom in contract\nAdd formatting check to CI in codex-contracts-eth repo\nRebase Marketplace integration test refactor with erasure coding changes\n\n\n\nOngoing:\n\nPersistent Availabilities\n\nDesign Plan\n\n\nAdd duration to Codex frontend\nAdded a calendar for the expiry of creating ROSC’s\nWork to add ceremony files to Codex\n\nCeremony file distribution\nAdd Ceremony file hash to Marketplace’s Contract configuration\nAdd support to retrieve Ceremony file hash from Contract’s configuration\nAdd support for Ceremony file hash download from S3\n\n\nContinue work on updating nim-ethers to support JSON-RPC breaking changes and pulling out utils/json to its own library\n\n\n\nInfra §\n\nCompleted:\n\nDeploy a site to store circuit ceremony files\nAutomate Codex ceremony files upload to Cloudflare R2 using GitHub Actions\n\n\nOngoing:\n\nCreate Codex Helm chart\nDeploy Codex Storage nodes in Testnet cluster\n\n\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\n\nCompleted:\n\nImplement G2 curves (so most building blocks are now in place in my algebra backend to be able to experiment\nReview work from Hashcloak collaboration for zk backend benchmarking test suite\n\n\nOngoing:\n\nNew proof system design proposal\n\n\n"},"codex/updates/2024-02-05":{"title":"2024-02-05 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Jan 29nd - Feb 5th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient §\nEpic: Nim Improvements §\nCompleted:\n\nFiled issue for adding Atlas / non-Nimble support for packages\nStart working on Atlas command changes\n\nOngoing:\n\nCreate a repo as a place to start implementing some core async-threading tools for Chronos like worker pool & disk io on top of the ThreadSignalPtr primitive\n\nplans to support refc & orc\n\n\n\nEpic: Wiring the Proving System §\nCompleted:\n\nWrapped ark-circom in a C FFI via:\n\nnim-circom-compat and\ncircom-compat-ffi\n\n\n\nOngoing:\n\nIntegration of codex-storage-proofs-circuits with a PR in nim-codex\n\nEpic: Improve Client Stability §\nCompleted:\n\nUpdated profiler branch for debugging\nPorted the profiler to Chronos V4\nWrote separate test runner for two client test to try to figure out the origin of a file size bug which magically disappeared\n\nOngoing:\n\nFinish work to take down draft flag from PR Expiry per dataset\nWrite tests for PR Safe block deletion (with ref count)\nLook into the CI/docker packaging/local build tooling for Waku and Nimbus as part of build improvements PR\nChronos V4 branch\nPinned versions for Chronos and json-rpc\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nRebased multinode integration test refactor which had two failing tests due to the erasure coding changes\nRebased Marketplace integration test suite\nAdded support for Result types using formatIt for logging proxy\nFinished the verifier contract\nDeployed a dummy verifier on local networks for testing\nFinished updates to nim-ethers, all tests passing, including in Nim v2\nFixed an issue in the nim-ethers json-rpc update\n\nDerived Signers could not access the derived getAddress and sendTransaction when their async raises were updated with SignerError\n\n\n\nOngoing:\n\nContinue work on updating nim-ethers to support json-rpc breaking changes\nContinue work on supporting json-rpc breaking changes and pulling out utils/json to its own lib\nIntegrate contract changes into nim-codex\nLook into removing waitFor in integration tests\nReview and clean up nim-ethers changes\n\nTry to figure out a cleaner way to handle exceptions instead of catching all CatchableErrors\n\n\nStart tweaking the nim-json api to normalize both serialize and deserialize pragmas, with modes: OptOut, OptIn, and Strict\nWIP on adding PATCH call for Availabilities\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nFrobenius endomorphism & pairing implementation\nReview the Solidity Groth16 verifier\n\nOngoing:\n\nDAS simulator improvements to cover more diffusion models\nStart DAS sample query mechanism design\nProof recursion ideation\n"},"codex/updates/2024-02-12":{"title":"2024-02-12 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Feb 6th - Feb 12th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nEpic: Nim Improvements §\nCompleted:\n\nAdd Nim-matrix workflow to run on merge queue\nChanges to build improvements proposal so default version for the compiler is now represented as special version repo_version which can be accessed locally and in CI\n\nOngoing:\n\nNim memory profiler\n\nEpic: Wiring the Proving System §\nCompleted:\n\nIntegrated zk verifier into nim-codex\n\nOngoing:\n\nStarted reviewing the Circom circuit\n\nEpic: Improve Client Stability §\nCompleted:\n\nTwo PRs for testing framework (one PR #93, and one PR #94)\n\nOngoing:\n\nRun Continuous-Test outside of the cluster to reproduce ‘file size issue’\n\nEpic: Infra §\nCompleted:\nOngoing:\n\nCreate Codex Helm chart\nDeploy Codex Storage nodes in Testnet cluster #115\nTracking down the timeout issues in Codex\nUpdates to logtools\n\nNow understand what deploy IDs and test runs are (4 min video here);\n\n\nWorked on the block flow tracker\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nFixed decoding issue in nim-ethers\nWorkaround for that same decoding issue\n\nCan’t use the fix from nim-ethers yet, Codex is still on old version of chronos\n\n\nPublished nim-serde\n\nFinalized nim-serde api: now has two main pragmas, serialize and deserialize, that can be applied at the object-level or field-level:\nEach can set key (valid at field-level), ignore (valid at field-level), and mode (valid at object-level)\n\nmode can be one of:\n\nOptOut\nOptIn\nStrict\n\n\n\n\nMany more tests for the nim-serde lib — serialize OptIn, OptOut, Strict and deserialize OptIn, OptOut, Strict\nAdded a comprehensive README to nim-serde\nAdded CI to serde, with branch protection rules on master\nAdded support for deserializing seq[byte]\n\n\nUpdated nim-ethers json-rpc and chronos upgrade PR to use nim-serde instead of the json util. Created the PR https://github.com/codex-storage/nim-ethers/pull/64\n\nOngoing:\n\nWIP on finishing the Availabilities API endpoints tweaks\nTried to integrate nim-serde in nim-codex, but running into symbol clashes with parseJson, so changed parseJson to JsonNode.parse, still needs to be integrated into nim-codex\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\nOngoing:\n\nMore work on the algebra backend (pairings, APIs)\nWork towards an independent Groth16 prover (so that we can debug the Nim one) - an initial version of that seems to work now\n"},"codex/updates/2024-02-19":{"title":"2024-02-19 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Feb 13th - Feb 19th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient §\nEpic: Nim Improvements §\nCompleted:\n\nInitial PR up for Apatheia async-threading\nOngoing:\nStarted implementing an async-threading API\n\nEpic: Wiring the Proving System §\nCompleted:\nOngoing:\n\nCode review of the circom circuit\nProgress on prover integration\nDetermine why different amounts of data were being downloaded for different slot indices (and failing to release reservations due to be larger than the slotSize)\nGetting integration tests PR #662 into shape for merging\n\nIntegration tests were generally not using the right ec params (num nodes, dataset size, tolerance)\nAfter EC params were corrected, some of the tests were not working due to the recent async clock.now update\n\nCreated a revert PR for the async clock.now PR\n\n\n\n\n\nEpic: Improve Client Stability §\nCompleted:\nOngoing:\n\nStarted work on delegating expensive computations to a separate thread\nReviewing changes made to Apatheia\nStarted integrating apaethia into nim-codex\nRebasing two large PRs against latest master:\n\nSafe block deletion (with ref count)\nExpiry per dataset\n\n\n\nTesting §\nCompleted:\nOngoing:\n\nContinue work to track down the timeout issues in Codex\n\nDid a bunch of updates to logtools, which now understand what deploy IDs and test runs are (4 min video here);\n\n\nWorked on the block flow tracker in tandem with the logtools\n\nNot cancelling pending WantHave’s and under the right conditions this makes the peer implode\n\n\nMade some changes and opened PRs for test framework (one normal, and one tiny PR);\nMade changes to the build improvements proposal, so that the default version for the compiler is now represented as special version repo_version which can be accessed locally and in CI\n\nFor now this is hidden in this commit; started treating those PRs as low priority\n\n\nIsolated the Codex issue to a working hypothesis of failed cancel messages\n\nSmaller-scale test validation of above issue\nLearned how to actually slow down traffic on a given port\n\nIn the end that was not the issue, the issue being instead that peers need to create libp2p connections so they pop into each other’s PeerCtxStore\n\n\n\n\nPut together failing test for the cancellation issue\n\nGoes into testblockexc.nim\nNeed to provide a fix\n\n\n\nInfrastructure §\nCompleted:\n\nAdjust workflows for changelog generation #5\nFix Docker entrypoint NAT helper variables #706\n\nOngoing:\n\nCreate Codex Helm chart #58\nDeploy Codex Storage nodes in Testnet cluster #115\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nUpdated nim-ethers pull request to integrate serde\nRebased integration test refactor\nNim-serde changelog workflow in CI\nFinished moving nim-codex json util to serde\n\nOngoing:\n\nSee Epic: Wiring the Proving System\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nFirst working version of the Haskell Groth16 prover\n\nWork towards an independent Groth16 prover (so that we can debug the Nim one) - an initial version of that seems to work now\n\n\nReviewed improvements to the circuit\n\nOngoing:\n\nMore work on the algebra backend (pairings, APIs)\nStarted writing down some musings about aggregation (WIP)\nFound the bug in the Circom zkey usage preventing valid proof verification\n"},"codex/updates/2024-02-26":{"title":"2024-02-26 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Feb 20th - Feb 26th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nCompleted:\nOngoing:\n\nCodex team members heading to attend ETH Denver\n\nEpic: Nim Improvements §\nCompleted:\nOngoing:\nEpic: Wiring the Proving System §\nCompleted:\nOngoing:\nEpic: Improve Client Stability §\nCompleted:\nOngoing:\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nFinished PR for availabilities update endpoints\n\nRan into very weird bug in one of these:\n\nChronos server implementation, Presto or Nim’s HTTPClient\nCould not debug and decided to rather move from HTTP 204 response to 200 one\n\n\nCreated reproduction repo\nLogged the issue in Presto repo\n\n\nDebugged non-working Dist. testing contracts\n\nOngoing:\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nhelped with figuring out the Ethereum elliptic curve conventions\ngave an elliptic curve talk at the local university; slides for the interested\nfound the second bug in the Nim Groth16 prover (in Constantine again)\n\nOngoing:\n\nstarted thinking about the small / dynamic data problem\n"},"codex/updates/2024-03-04":{"title":"2024-03-04 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Feb 27th - Mar 4th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nCompleted:\n\nCodex team members attended ETH Denver\nOngoing:\n\nEpic: Nim Improvements §\nCompleted:\nOngoing:\n\nStarted a PR to fix Atlas after SAT integration\nFinishing basic fixes PR in Atlas\nextracted the profiler into its own library\n\nretained only the instrumentation modifications in our Chronos V4 branch\nafter we merge V4 into Codex (blocked by a bunch of issues), start a discussion with the Chronos folks to try to get the instrumentation part in\n\n\n\nEpic: Wiring the Proving System §\nCompleted:\nOngoing:\n\nCeremony file setup\n\nEpic: Improve Client Stability §\nCompleted:\nOngoing:\n\ntracked a Codex bug during a V4 merge which turned out to be a compiler bug\n\nwith consequences to Chronos\nbug resolution handled by Nim compiler team after being flagged as “showstopper”\n\n\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nAdd IsSyncing to nim-ethers\nAdd sync check to codex startup\nIn-flight flag for outgoing blocks\n\nDiscord role rewards based on on-chain state and events\n\nPartially tested, requires fixed marketplace-dist-test\n\n\n\n\nUpdated and merged: fix for block-retransmit issue\nDebug isSync (nim-ethers update) and update to testnet-starter\n\nOngoing:\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nNim Groth16 prover finally appears to work correctly (though with the current workaround it also became significantly slower)\nMulti-threading support in the Nim Groth16 prover\n\nOngoing:\n\nThinking about using FRI commitment for storage proofs\n\nHash based, includes RS, outsourceable, easy to prove large/r data sets\n\n\nThinking about using KZG as updateable commitment\n\nWith efficient proofs for small/updateable data sets\n\n\nDebugging the multithreading bug in the prover\nchecking out new research\nSpeed up the “binary circuit” proposal by a factor of ~2x\nThinking about a (supposedly fast) dedicated SHA256 proof protocol, and how to implement it\n"},"codex/updates/2024-03-11":{"title":"2024-03-11 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 5th - Mar 11th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nEpic: Multithreading §\nCompleted:\n\nMarked PR as ready - scheduling erasure encoding and decoding on a thread pool\n\nOngoing:\n\nStarted work on scheduling prover computation on a thread pool\n\nEpic: Wiring the Proving System §\nCompleted:\nOngoing:\n\nMarked PR as ready - scheduling erasure encoding and decoding on a thread pool\nStarted work on scheduling prover computation on a thread pool\n\nEpic: Improve Client Stability §\nCompleted\n\nReasoning on why the profiler works the way it does\nClosed bug: fixes double lookups when block does not exist\n\nOngoing:\n\nSome triaging of bugs in the Codex repo, still some way to go\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\nOngoing:\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nEthResearch post on sampling techniques (https://ethresear.ch/t/lossydas-lossy-incremental-and-diagonal-sampling-for-data-availability/18963)\nLogos X space with Leo and Danny\nMinor refactor the proof circuit PR\n\nOngoing:\n\nDAS simulator (https://github.com/codex-storage/das-research) paper prep (calls + work)\nShadow based P2P emulator for DAS (https://github.com/cskiraly/dst-gossipsub-test-node/tree/FullDAS)\nLooked into how circom handles custom gates (tldr: it’s easy to abuse for our own purposes, but snarkjs doesn’t implement anything)\nStarted working on prototyping stuff for the new proof system\n"},"codex/updates/2024-03-18":{"title":"2024-03-18 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 12th - Mar 18th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nClient §\nCompleted\n\nMarked PR as ready - scheduling erasure encoding and decoding on a thread pool https://github.com/codex-storage/nim-codex/pull/716\nPut together reasoning on why the profiler works the way it does;\nClosed a bug re: double lookups when block does not exist;\n\nOngoing\n\nStarted a PR to fix Atlas after SAT integration\nFinishing basic fixes PR in Atlas https://github.com/nim-lang/atlas/pull/120\nStarted work on scheduling prover computation on a thread pool\nFixing comments and rebasing large PRs:\nhttps://github.com/codex-storage/nim-codex/pull/631\nhttps://github.com/codex-storage/nim-codex/pull/678\nWork on Frontend\n\nImplemented dropdown list for expiry input\nStarted working on caching node information for displayed information\n\n\nSome triaging of bugs in the Codex repo, still some way to go;\n\nInfrastructure §\nCompleted\n\n✅ Install VictoriaMetrics in Testnet cluster #130\n✅ Adjust number of nodes in Testnet cluster #136\n✅ Redeploy Testnet cluster components #138\n✅ Install ELK in Testnet cluster #135\n\nOngoing\n\n�️ Install Oauth2 proxy in Testnet cluster #141\n�️ Deploy Testnet cluster components #57\n\nMarketplace §\nCompleted\n\nDiscussions about ceremony files retrival\nPR Reviews:\n\nhttps://github.com/codex-storage/codex-storage-proofs-circuits/pull/7\nhttps://github.com/codex-storage/codex-contracts-eth/pull/83\nhttps://github.com/codex-storage/nim-codex/pull/730\n\n\n\nOngoing\n\nWIP on merging https://github.com/codex-storage/nim-codex/pull/692\nWIP on persistant availabilities\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nEthResearch post on sampling techniques (https://ethresear.ch/t/lossydas-lossy-incremental-and-diagonal-sampling-for-data-availability/18963)\nDAS simulator (https://github.com/codex-storage/das-research) paper prep (calls + work)\nShadow based P2P emulator for DAS (https://github.com/cskiraly/dst-gossipsub-test-node/tree/FullDAS)\nLooked into how circom handles custom gates (tldr: it’s easy to abuse for our own purposes, but snarkjs doesn’t implement anything)\nMinor refactor the proof circuit PR\n\nOngoing\n\nStarted working on prototyping for the new proof system\n"},"codex/updates/2024-03-25":{"title":"2024-03-25 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 19th - Mar 25th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nClient §\nCompleted\n\nVarious fixes for prover-verifier integration\n\nhttps://github.com/codex-storage/nim-codex/pull/702\n\n\nSplit prover-verifier integration into several PRs and merged them into master\n\nhttps://github.com/codex-storage/nim-codex/pull/702#issuecomment-1986256598\\\n\n\n\nOngoing\n\nSyncing up with testnet owners to help think through our use cases and whether or not we have gaps in our QA/testing plan;\nPut together a small tutorial on deploying contracts on a local Geth network with some code.\n\nTesting §\nCompleted\n\nFixed proof generation is dist-test environment\nFixed crash in dist-test env related to blockchain inspection\nBring up-to-date continuous tests (enable transient-node and marketplace test scenarios)\nOngoing\nWhy do proofs with EC params 1-0 fail?\nNode response to fill-slot call is unreliable in geth env\nWrap up discord-reward bot\n\nInfrastructure §\nCompleted\n\n✅ Install Oauth2 proxy in Testnet cluster #141\n✅ Deploy Testnet cluster components #57\n✅ Install Vector in Testnet cluster #144\n✅ Configure monitoring in Testnet cluster #147\n✅ Send Codex and Geth Bootstrap nodes logs and metrics to the Testnet cluster #148\n\nOngoing\n\n�️ Configure Grafana dashboards for Testnet resources #154\n�️ Add Release workflow for Codex #749\n\nMarketplace §\nCompleted\n\nnim-ethers\n\nSupport Solidity’s custom errors\n\nhttps://github.com/codex-storage/nim-ethers/pull/69\n\n\nUpdate dependencies\n\nhttps://github.com/codex-storage/nim-ethers/pull/70\n\n\nFix flaky test\n\nhttps://github.com/codex-storage/nim-ethers/pull/71\n\n\nMerged fix for Solidity getters\n\nhttps://github.com/codex-storage/nim-ethers/pull/63\n\n\n\n\ncodex-contracts-eth:\n\nFinished verifier refactor:\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/83\n\n\n\n\ncodex-storage-proofs-circuits:\n\nMerged code review PR:\n\nhttps://github.com/codex-storage/codex-storage-proofs-circuits/pull/5\n\n\n\n\nquestionable:\n\nWorked out a way to handle generic Results in without statements:\n\nhttps://github.com/codex-storage/questionable/pull/59\n\n\n\n\n\nOngoing\n\nSee previous week\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nwrote an initial draft notes about Plonk; github (WIP)\n\nOngoing\n\nworking towards implementing a Plonkish prover with custom accelerator gadgets, so that we can test proof system ideas\nrealized that proof system idea has a botleneck; may still speed up Poseidon hashing, but the new botleneck is much worse for binary circuits like SHA256. To make the latter practical needs new ideas.\n"},"codex/updates/2024-04-01":{"title":"2024-04-01 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 26th - Apr 1st §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nClient §\nCompleted\n\nCreated task for NAT traversal and gathered various info for it https://github.com/codex-storage/nim-codex/issues/753\nFinished work on scheduling erasure coding on a thread pool https://github.com/codex-storage/nim-codex/pull/716\n\nOngoing\n\nWorking on scheduling prover computation on a thread pool, draft PR in progress\nAddressing comments for large PRs\nhttps://github.com/codex-storage/nim-codex/pull/631\nhttps://github.com/codex-storage/nim-codex/pull/678\n\nTesting §\nCompleted\n\nDocumented issue for running Codex integration tests on certain macOS configurations https://github.com/codex-storage/codex-contracts-eth/issues/95\n\nInfrastructure §\nCompleted\n\nNone\n\nOngoing\n\n� Install Fluent Bit to get Testnet Kubernetes events\n� Adjust Vector config\n� Deploy ethereum web wallet for Testnet\n� Run Public RPC node on Testnet\n� Add more Codex Storage nodes\n� Use multi-stage builds for Rewarder #101\n� codex-testnet-starter updates\n�️ Configure Grafana dashboards for Testnet resources #154\n�️ Add Release workflow for Codex #749\n\nNim Tooling §\nCompleted\n\nAdd recursion limit for SAT (packaging) https://github.com/nim-lang/sat/pull/3\nDisable stacktrace on SAT solver to avoid stackoverflows in debug builds https://github.com/nim-lang/sat/pull/5#event-12262613353\nWrote up draft for Nimble Caching RFC https://hackmd.io/@elcritch/rJ4VrExJR\n\nMarketplace §\nCompleted\n\nRevisit design of https://github.com/codex-storage/nim-codex/issues/467\nReview https://github.com/codex-storage/nim-codex/pull/692\nReview https://github.com/codex-storage/nim-codex/pull/678, many reviews and ongoing discussion\nReview https://github.com/codex-storage/nim-codex/pull/730\nChore to remove no longer used compilation flag: https://github.com/codex-storage/nim-codex/pull/741\nTried to understand why an integration was indeterminately failing in CI and locally, thought was very difficult to reproduce\nMerged https://github.com/codex-storage/nim-codex/pull/704, which had the integration test failure. Re-running the failed test in CI was enough to get it to merge, but indicates there is an issue with this test\nRebased and merged MarketError PR: https://github.com/codex-storage/nim-codex/pull/670\nUpdated pausing slot queue design PR: https://github.com/codex-storage/codex-research/pull/188/\nRe-reviewed feat[marketplace]: add slot queue pausing PR #752 in Codex and started review of Expiry per dataset PR #678\nAdded protection branch rule for nim-ethers in Codex\nReviewed PRs #757, #752, #760, #69, and #70 in Codex\nReviewed comments for the Availability Patch PR and Pausing Queue PR in Codex\n\nOngoing\n\nDiscussed with team plans to improve integration tests: what they should cover, parallelism, and whether or not some could be replaced with unit tests. Also discussed some open issues and PR comments.\nContinued work on implementation of slot queue pausing. Most implementation in, need to add tests: https://github.com/codex-storage/nim-codex/tree/feat/marketplace/slot-queue-improvements\nWorked on updating a macro for Optionalize to add the serialize pragma annotation on the type. Tried to get the macro to read existing serialize annotations on the type and fields first but was taking too long, so moved on\nDiscussions about release branches, proof circuit assets, and versioning\nDiscussed Optionalize() macro and serialize pragma\nDiscussed the parallelism of integration tests\nProgress on Persistent Availabilities implementation\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nNone\n\nOngoing\n\nTrying to understand what can be salvaged from my binary circuit idea (by implementing and measuring stuff)\nWorking on the Plonk notes\n"},"codex/updates/2024-04-08":{"title":"2024-04-08 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Apr 2nd - Apr 8th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q2 public testnet release. An internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nThe Codex team is currently attending the week long Logos all hands off-site, attending ZK Summit and having their team specific off-site the following week.\n\nLogos and Codex Off-site Links (2024/04/01 - 2024/04/15) §\nThe following are links containing artifacts from both off-sites:\n\nCodex Athens Presentation\nCodex Athens Presentation Video Recording\nCodex Workshop Presentation\nCodex Athens Off-site Artifacts\n"},"codex/updates/2024-04-15":{"title":"2024-04-15 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Apr 9th - Apr 16th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q2 public testnet release. An internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nThe Codex team is currently attending the week long Logos all hands off-site, attending ZK Summit and having their team specific off-site the following week.\n\nLogos and Codex Off-site Links (2024/04/01 - 2024/04/15) §\nThe following are links containing artifacts from both off-sites:\n\nCodex Athens Presentation\nCodex Athens Presentation Video Recording\nCodex Workshop Presentation\nCodex Athens Off-site Artifacts\n"},"codex/updates/2024-04-22":{"title":"2024-04-22 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 16th - Mar 22nd §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\n\nmost members OOO\n\nMarketplace §\n\nmost members OOO\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nstarted looking into the Goldilocks field and Plonky2 (unfortunately, there appears to be NO documentation at all…)\nwrote a draft document about our proof research needs\n"},"codex/updates/2024-04-29":{"title":"2024-04-29 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 22nd - Mar 29th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\n\nMembers OOO\n\nMarketplace §\nCompleted\n\nWork on duration for expiry\nnim-codex PR https://github.com/codex-storage/nim-codex/pull/793\ncontracts PR https://github.com/codex-storage/codex-contracts-eth/pull/99\n\nOngoing\n\nwhitepaper review\nTokenomics discussions\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nNone\n\nOngoing\n\nWhitepaper review (90% done)\nCoordinating Vac cooperation\nTried to look a little bit into set accumulator schemes\n"},"codex/updates/2024-05-06":{"title":"2024-05-06 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update April 30th - May 6th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nNone\n\nOngoing\n\nSplitting two big PRs into a series of smaller ones\n\nExpiry per dataset\nSafe block deletion (with ref count)\n\n\nReviewing various PRs in the client\n\nMarketplace §\nCompleted\n\nTokenomics meeting to discuss existing questions, as well as the new slot reservations proposal\nDiscussion about the slot reservations proposal, in which we came up with a simplified version, opting to allow for emergent behaviors before adding to complexity\nDiscussion about fill reward curve\nDiscussion about the new slot reservations proposal\nReviews :\n\nhttps://github.com/codex-storage/nim-codex/pull/793\nhttps://github.com/codex-storage/codex-contracts-eth/pull/99\n\n\n\nOngoing\n\nWriting out new proposal for slot reservations as well as capturing the original bloem method idea\nTokenomics & Marketplace proposal discussions\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nDiscussion with marketplace team about slot fill reward and address window expansion curves\n\nOngoing\n\nStudying various FFT/NTT algorithms\nLooking at new research\nLooking a bit into the recent “Foreign Arithmetic” (SigmaBus) paper. Unfortunately it seems to be much less useful for us than originally thought.\n"},"codex/updates/2024-05-13":{"title":"2024-05-13 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update May 7th - May 13th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nOrganized new Kanban board to sort through new and existing Epics and Issues associated with ongoing work to test & fix bugs in the core client towards stability - two large items of focus for the coming two months is:\n\nEthCC Workshop Client work\nFirst release of Codex for the testnets\n\n\nFixed upload/addition of blocks but did not fix it in the advertising loop yet\nFinished evaluation of LevelDB vs SQLite\n\nOngoing\n\nSplitting two big PRs into a series of smaller ones\n\nExpiry per dataset\nSafe block deletion (with ref count)\n\n\n\nMarketplace §\nCompleted\n\nNew proposal for slot reservations and capturing the original bloem method idea; developed simplified version of slot reservations opting to allow for emergent behaviors before adding to complexity\nCompleted PR Reviews and merged:\n\nFeat: expiry specified with number of seconds\nFeat: expiry specified as duration\n\nFollow up fix with adding confirmation: https://github.com/codex-storage/nim-codex/pull/802\n\n\n\n\nUpdated Marketplace sections of Codex Whitepaper\n\nOngoing\n\nTokenomics meeting to discuss existing questions as well as the new slot reservations proposal\nDiscussion with Research team about fill reward curve\nApplication Properties for Codex contract\n\nLearning about Properties and how to write them in Certora system\n\n\nNew UI team sync\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nWrote down current thinking about tracking sets of proofs (WIP)\nNotes on Tracking proofs in Codex\n\nOngoing\n\nLearning about different FFT / NNT algorithms\nContinued work on Plonk notes\nCurrent focus is mainly on recursive proofs in the elliptic curve setting\n"},"codex/updates/2024-05-20":{"title":"2024-05-20 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update May 14th - May 20th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nPackaged self-contained LevelDB Nim project so no dependencies on system packages lifted from existing wrapper and then wrapped it in a datastore implementation\n\nPreliminary tests shows increased performance is as expected\n\n\nResolved issue with dependency bump and broken dependency chain and now stuck with serialization issue - bug was related to resolving to wrong deserializer and work on nim-serde and nim-RPC\n\nOngoing\n\nStarted work on LevelDB migration; Discord bot, reward system and chain inspection broken\nResolving failing integration tests re: expiry of the request in storage\nWorking on issue related to inability to see amount of tokens sent in block explorer\nDeploying faucet web app for testnet tokens (ETH & TST)\nWorking on Codex release workflow\nTrying to use DST’s k8s cluster and have not been able to use it yet\nMigrate dist test cluster from Digital Ocean to Hetzner and deploy different mointoring tools (e.g., Victoria Metrics) - parametrics logs replacing elastic search with similar API and CLI scrollingto be added to UI later on\n\nMarketplace §\nCompleted\n\nHelped with some work related to LevelDB integration\nAdded custom errors PR in nim-ethers that required attention\n\nOngoing\n\nWriting documentation around some of the Solidity code ahead of audit\nCoordinating audit with SC team (Vac) and looping in Security; still deciding on 2nd security audit company\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nSync w/ Client team about circom-compat\nStudying bulletproofs with the goal to try to use them in proof recursion, on the “wrong” curve - see writeup here\nUpdated thinking about proof recursion\nWrote a high-level overview explaining all the moving parts of a ZK proofs (different files and steps and their meaning)\n\nOngoing\n\nProposal for tracking proofs (more precisely, the multiset commitments in there) has a scaling problem, and started thinking about an alternative motivated by Plookup\nLooking more into Winograd-type FFT\n"},"codex/updates/2024-05-27":{"title":"2024-05-27 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update May 21th - May 27th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nN/A\n\nOngoing\n\nContinued work on LevelDB migration; failing unit test uncovered bug on race condition in one of the state machines in the Marketplace module and switch to LevelDB reveleaed it and changing timing of DB reproduced it; reproduced it in SQLite by putting a sleep statement and nothing wrong in LevelDB\n\nMarketplace picked this bug up\n\n\nDocker build problems; Rust build failed and Circom devices no longer building - rolled back Codex to previous Docker image and it doesn’t build anymore so not something changed on our end\nWorking on debugging Rust FFI threading\n\nMarketplace §\nCompleted\n\nContract deployment and security writeup\nMore adjustments to the slot queue PR, and merge\nRe-review of ethers custom errors PR\nMerge fix for forcing scope of deserialization\nRelease new version of nim-serde to unblock chronos v4\nBump serde version and merge\nMerged Remove overloaded UInt256.fromJson\nCleanup integration tests review\nAddressed Slot Reservations PR comments with some rewrites\n\nOngoing\n\n“Application Properties” writeup for Certora issues tracked here and ongoing discussion of issues here\nReviewing RFC spec for Marketplace\nBuilding frontend for the EthCC Demo that shows past and real time contract events, and downloads CIDs and displays as images\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nInitial Dynamic data proposal WIP\n\nOngoing\n\nUnderstanding aggregator node hybrid-system dynamics\n"},"codex/updates/2024-06-03":{"title":"2024-06-03 Codex Weekly","links":["(https:/discord.com/channels/895609329053474826/1230457525854539819/1245555994465931294)"],"tags":["codex-updates"],"content":"Codex Update May 28th - June 3rd §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nAdded custom Docker file for release workflow\n\nOngoing\n\nEthCC planning meeting with Marketplace\nContinued bug hunting and fixing towards stability of client\nPlanning around EthCC Codex demo logistics; Dockerized Codex in VMs, cloud VPN, and physical MikroTik router setup\nNaming conventions of testnet deployments\nNAT Traversal issues; AutoNAT issues not working as expected - formal writeup to come describing issues and potential solutions\nChallenges with DHT and peer discovery\nFast-track reviews of ‘rework async iter’, ‘safe block deletion’ and ‘expiry per dataset’ PRs\nExplore scalability issues with LevelDB and large node tests\n\nMarketplace §\nCompleted\n\nMarketplace discussion meeting (release branches/versions, conditional deployments, pointer calculation, contract gas estimates, upgradability legal implications)\n\nAdd freezing functionality for emergency use cases\nCall with Legal for POV of Contract’s security and upgradability\nCall with SC team (Vac) about Legal POV for Contract’s security and upgradability\n\n\nMarketplace team meeting with Legal about contract freezing/upgradability\nReview of Bug/sales race PR\nSales module concurrency issue - reworking fix after feedback\n\nOngoing\n\nMore progress on EthCC Demo frontend\nGas reporting plugin attempt to run against Codex integration tests\nInvestigate deploying unchanged contracts using hardhat-deploy and newer hardhat Ignition (created issue for upgrade)\nFrontend dev application reviews\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nL2 Deployment\n\nOngoing\n\nProxy re-encryption call with ACZ (Vac)\nInterviewing ZK engineer candidates\nEncryption options WIP\nSet commitment proposal with details WIP\n"},"codex/updates/2024-06-10":{"title":"2024-06-10 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update June 4th - June 10th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nSetup similar VPN from home to cloud VPN for router OS similar to MikroTik router and APs; purchased hardware to test - ordered physical SIM adapter for router\n\nOngoing\n\nWorkshop preparation\nOngoing scalability work; intially had to fix the Docker build and got updated build with LevelDB, odd stuff happening in cluster but 4.5GiB exchange for upload/download succeeded\nNAT Planning and roll out\n\nMarketplace §\nCompleted\n\nTBD\n\nOngoing\n\nWorkshop preparation\nCertora setup & integration\n\nWIP in the Certora’s Application Properties work\n\n\nPersistent Availabilities\nSlot Reservations\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nOngoing work on details of the dynamic data proposal (the proof parts)\nHelped Nomos with a small FFT issue\n\nOngoing\n\nLooking at new research\nWorking on Winograd-type NTT\nWorking on proof recursion\nLooking into more FFT/NTT algorithms (ECFFT, prime order FFT, etc; we need non-power-of-two sizes for foreign field arithmetic)\nReliability and Proof Frequency (WIP)\n"},"codex/updates/2024-06-17":{"title":"2024-06-17 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update June 11th - June 17th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nL2 assumptions, planning and deployment options\nNAT Traversal in Codex\n\nOngoing\n\nWorkshop preparations\nDeveloping single binary pipeline for releases\nSome splitting of PRs further into datastore and rework\nNeed this Safe block deletion (with ref count) PR approved\n\nMarketplace §\nCompleted\n\nMerged fix: createReservation lock\nL2 overview and Marketplace support/compatibility check\n\nOngoing\n\nWorkshop preparations\nLooking into more research about contract upgradability and industry practices\nReviews of Marketplace spec\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nFiguring out usable NTT options on the Grumpkin curve; WIP notes\n\nOngoing\n\nPrototyping with intent of a full implementation soon\n"},"codex/updates/2024-06-24":{"title":"2024-06-24 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update June 18th - June 24th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nMerged safe block deletion PR\n\nOngoing\n\nWorkshop preparations\n\nSlides presentation and complete demo run-through\n\n\nManifest initialization bug\nCrash fixing; second release failing because of CPU load - possible prover blocking I/O and need better threading (to use async profiler to resolve this)\nWork on scheduler\nWorking on bug fix for EC issues\n\nProblem with verifiable manifest (was not enabled for Athens demo) & tree roots issue\nCrashes resulting in SIGSEGV error\n\n\n\nMarketplace §\nCompleted\n\nHired full-stack dev to work on Codex App and some Client/Marketplace tasks\n\nOngoing\n\nWorkshop preparations\n\nFrontend session cookies issue - CORS requests problems; sticky sessions are problem for replicated services because reqeusts can be sent to different sessions, problem is how to persist RPC session w/ 3 RPC nodes and if you want to send all requests to same RPC node is problematic\n\n\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nPlausible deniability writeup from ACZ (Vac)\n\nOngoing\n\nDynamic data proposal WIP\n"},"codex/updates/2024-07-01":{"title":"2024-07-01 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update June 25th - July 1st §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nRelease pipeline for Linux setup (x64 & ARM for Ubuntu and MacOS)\n\nOngoing\n\nWorkshop preparations\n\nSlides presentation and complete demo run-through\n\n\nGeneral bug hunting and fixing towards baseline stability and BitTorrent-like performance\n\nMarketplace §\nCompleted\n\nWorkshop preparations\n\nOngoing\n\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nGathered all ZK related documents here\nWriteup on OTP-like encryption to prevent outsourcing attacks\n\nOngoing\n\nOngoing research into the details of folding\nInterviewing more ZK engineer candidates\n\nCreating take-home programming exercise\n\n\nThinking about how to describe Plonkish circuits\nLooking at new ZK research\n"},"codex/updates/2024-07-08":{"title":"2024-07-08 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update July 2nd - July 8th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nWorkshop preparations\n\nSlides presentation and complete demo run-through\n\n\nRelease pipeline for Windows (x64 & ARM) setup\n\nOngoing\n\nGeneral bug hunting and fixing towards baseline stability and BitTorrent-like performance\nWriteup of Merkle Trees and Proof Tree\nEC in Codex\n\nMarketplace §\nCompleted\n\nWorkshop preparations\n\nOngoing\n\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nN/A\n\nOngoing\n\nN/A\n"},"index":{"title":"","links":["terms-of-use","what-is-a-milestone","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.\nEvery year (starting this year), each project defines its plans in a number a milestones, which are then reflected and tracked here-in. You an read more about the contents of a given milestone and the various justifications for that content in What is a Milestone.\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":[],"tags":["nomos","roadmap","overview"],"content":"Nomos Overview §\nThe Nomos project building a blockchain for Network States. To learn more about the project, please visit the website\nNomos is currently in its research phase, and actively building a Testnet."},"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/2023-11-27":{"title":"2023-11-27 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Offsite §\n\nSummary of the offsite (daily): https://docs.google.com/document/d/1qJ_hP2FA7P3kB5TNi-tkFaWGmqlP8tZd9RC1dAlU5kw \nCarnot in a Privacy Setting under Mixnet Assumption: https://docs.google.com/document/d/1fICGvSkTCgvk879uaapzFzy6Qbzz6VkXX0lL_iJ8GJo\nPPoS + Carnot discussion - why Carnot will not be used for the base layer, exploring combinations of different approaches as well as a potential solution for fully private base layer\nMixnet: numerical experiments were conducted - more details here: https://docs.google.com/spreadsheets/d/1MaSBbfUGmJniILPvcQLxtyXqjBExUUEB6C2-YWNP6uI/edit#gid=0 \nData Availability: exploring cryptography, deciding on base layer structure, looking into super commitments, proving schemes.\nConclusions and next steps as a team for the implementation of the Nomos 1.0 Base Layer.\nFilmed presentation: Preliminary Privacy Analysis https://drive.google.com/file/d/1mrNWdJMX_WneUFNmHJn316uLrPXkBbMH/view?usp=sharing \nFilmed presentation: Last day summary PPoS - https://drive.google.com/file/d/1DlDi3bWglIRR3nJ6owjLemQSy9YiRSZY/view?usp=sharing \n\nPrivate PoS Tokenomics §\nResearch §\n\nValidator rewards function - https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4 \nSimulation results: https://github.com/logos-co/token-economics/blob/nomos-linear-reward-function/Nomos/multi_staking_rewards/linear_reward.ipynb**\n"},"nomos/updates/2023-12-04":{"title":"2023-12-04 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nProgress on the Mixnet implementation specification, with particular emphasis on integration on the rest of the system.\nDiscussing and analyzing possible strategies for cover traffic specially tailored to the consensus algorithm.\n\ndevelopment §\ntestnet §\ndevelopment §\n\nMerged Prometheus metrics service\n\nprivate PoS §\nresearch §\n\nWe consider leader election in PoS observed over some period of time by an adversary who wants to learn its stake with high “accuracy” and high “confidence”.\nFor the probability of stake greater than some threshold derived rigorous lower and upper bounds on this probability.\nFor the same probability considered an asymptotic long-time regime and developed a mathematical framework for this regime. \nVerification of above results by simulations is in progress. \nThe above will be a part of the  framework which will be used to get a more accurate estimate of the number of layers which are required to reduce anonymity failures in the mixnet. More details provided here\nAnalyzed how stake splitting affected leader rates in Crypsinous: Stake Splitting in Praos\n\ndata availability §\nresearch §\n\nDesigned a new super-commitment structure and explained it here. After some discussions, we agreed that  prover cannot temper the column entries by adding and subtracting some values but he can reorder the column entries. The proof does not guarantee column ordering. Solution methods for this were discussed, but since the focus was on a different structure design, this development was postponed for now.\nThought of a different design and explained it here. The main idea of the design is to take a commitment of commitments. As a result of the investigations, the structure is thought to be working. Cryptographic proof will be worked on.\nThe newly designed structures were compared with these existing schemes. It is thought that our current design will provide the whole advantages of Avail.\n\ndevelopment §\n\nContinuing DA mock implementation - splitting it into reviewable parts\n1D benchmarking\n\nmiscellaneous §\n\nThe Whitepaper now contains a whole new section on Light Nodes.\nCarnot’s role in Nomos has been updated.\nExplanations about privacy have been expanded and adapted to include the notion of resiliency.\nAdded other sections, like Multiple Base Layers and others related to Light Nodes.\nAdded new diagrams\n"},"nomos/updates/2023-12-11":{"title":"2023-12-11 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nCrypsinous over Mixnet contains the summarization of investigation into how Crypsinous will work in combination with the Mixnet\nIn the development section below, we will go into further into details in terms of how this researched affected the specification.\nThe discussions are still open and the specification is still prone to change.\n\ndevelopment §\n\nUpdated the Mixnet Specification according to the new research and analysis in the Crypsinous over Mixnet document. The gist of the document update is that every node emits real/cover packets with a rate in a Poisson distribution.\n\nA slot leader publishes 3 block proposals and several drop cover packets within a slot (a slot is published every 20s)\nAt that time, all of the other nodes emit only drop cover packets (“decoys”) within a slot.\nThe target mean packet delay is 2s.\nBased on this:\n\nDefined a packet emission mechanism\nRefined a packet delay calculation\nDefined a cover traffic strategy\n\n\n\n\n\ntestnet §\ndevelopment §\n\nNo updates\n\nprivate PoS §\nresearch §\n\nResearching on a potential problem of wealth concentration in the token engineering model that was reported by DarkFi since it contradicts the results we have calculated in the Validation Rewards\nPerformed additional research in terms of feasibility of learning total stake: the problem here is that we cannot compute relative stake based on what is the Crypsinous paper.\n\nTherefore we came up with Dynamic Lottery Function Difficulty adjustment\n\n\nRefined rigorous lower and upper bounds on the probability of stake greater than some threshold, i.e. “confidence”. The details can be seen in Notes on mathematical and statistical aspects of proof of stake consensus mechanisms\n\nThe upper bound was only available for prob. 0.9 and higher and a new version also allows for lower prob.\nThe latter is needed for a more accurate estimation of the number of layers in the mixnet.\nThe asymptotic result for the same probability also can be used only for higher values and extending this result for lower values is currently in progress\n\n\n\ndata availability §\nresearch §\n\nWriting of the new protocol specification complete - it is still open for discussion - comments and proposals with valid reasoning can still adjust the specification - anyone can comment.\nFor the historical records, the trail of thoughts, scenarios and improvements can be seen here.\nThe new specification was also looked at by the Nescience team - it has no cryptographical weaknesses.\nImplementation expected to start at the beginning of January.\nIn the future, we will evaluate additional Data Availability structures (based on internal literature) to see how they compare to what we have.\nthe DA node read/write API implementation is in progress - we have reviewed and reevaluated the initial plan to implement DA data dissemination and retrieval flows and created an action plan based on that.\n\ndevelopment §\n\nWe have performed simulations to confirm there will be no “flatness” issues with Carnot implementation.\nWe are currently in the process of finalizing the Carnot paper - the simulations action plan will also be shown there.\nFound additional proofs that simulations and rust Carnot implementation acts as expected in varying committee overlays - more info on Discord.\n"},"nomos/updates/2023-12-18":{"title":"2023-12-18 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nContinuing the research on the effects of wealth concentration within Ouroboros Crypsinous - more precisely fixing some of the code and running simulations. The results and reports will continue to be provided in the Notion doc.\nAlso, doing additional research into the Darkfi’s Crypsinous implementation (and why they are striving away from it)\nMixnet specification is done, currently in review - once additional comments have been added, will provide new updates\nThere have been some slight improvements in the Crypsinous over Mixnet document - not too major\nCompiled a high-level overview of the Ouroboros family\nStudying byzantine gossip and swarm consensus as part of the effort of solving the tagging attack problem (as alternatives to random subsampling and reliable broadcast) - some of the ideas involve the use of gradecast over byzantine gossip, but providing more details in the following week.\n\ndevelopment §\n\nSolved [an issue](https://github.com/logos-co/nomos-node/pull/544](https://github.com/logos-co/nomos-node/pull/544 ”https://github.com/logos-co/nomos-node/pull/544) that was causing problems with simulations (Carnot 10k nodes - Tree implementation returned different results when searching for child committee and then using child committee to find its parent)\nBy fixing the above and the depth calculation in the analysis script, the simulations stall has been fixed totally, and we are meeting in the deadlines in terms of releasing the Carnot papers - no additional showstoppers\n\ntestnet §\ndevelopment §\n\nNo updates\n\nprivate PoS §\nresearch §\n\nNormalize stake for lottery - we have a proof of convergence to expected fixed point and stability conditions for that fixed point: Analysis Summary\nWe’ve run simulations of the process and they confirm the stability conditions and convergence derived analytically (above)\nThere is still work to be done in terms of slots observation to understand a good measurement of leader rate as well as some additional confirmation of the analysis\nAnalysis of stake de-anonymization (details are [here](https://www.overleaf.com/read/xvgmfchdhgzh#acd15d](https://www.overleaf.com/read/xvgmfchdhgzh#acd15d ”https://www.overleaf.com/read/xvgmfchdhgzh#acd15d) and here): and here)\nUsed the lower bound (LB), asymptotic estimate (AE) and upper bound (UB) on the probability of stake greater than some threshold (“confidence”), within a given “accuracy”, to estimate the number of layers in the mixnet.\nThe UB (on the number of layers) is loose. The AE (for the number of layers) is close to the LB (on the number of layers), suggesting that LB is closer to true values (AE is in very good agreement with simulations). However, AE is only available for “confidence” higher than 0.6 and some “accuracies”\nFor the currently used lottery function, derived the maximum likelihood estimator of relative stake. The latter can be used by an adversary to infer the relative stake of a node\nAnalysis of fraction of compromised paths is currently in progress and more details will be provided in the following weeks\n\ndata availability §\nresearch §\n\nContinuing on the process of comparing different DA structures - the comparison can be found [here](https://www.notion.so/Comparison-of-DA-Structures-WIP-47350a408cbd4d8db545527b7a598ccf](https://www.notion.so/Comparison-of-DA-Structures-WIP-47350a408cbd4d8db545527b7a598ccf ”https://www.notion.so/Comparison-of-DA-Structures-WIP-47350a408cbd4d8db545527b7a598ccf) . Right now we are comparing Merkle Tree, RS+KZG and Merkle Tree+Snarks - based on the literature at the bottom of the aforementioned document.\nThe parameters we are currently comparing are proof size, prover time, verifier time and commitment size, but in terms of theoretical examples, not actual benchmarks.\n\ndevelopment §\n\nThe new read/write DA API is still in progress - there are conversations ongoing which can be seen in the draft PR\n\nmiscellaneous §\n\nThe architecture whitepaper is awaiting feedback and expected to be finalized in the first week of 2024 - the paper can be found on Discord\n"},"nomos/updates/2023-12-25":{"title":"2023-12-25 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nUsed bounds and asymptotic analysis to create a new version of the table (see this for reference) which estimates the number of layers needed in the mixnet protecting the network layer. The latter assumes a very simple lottery function where the probability of winning is equal to the relative stake.\n\ndevelopment §\n\nNo updates\n\ntestnet §\ndevelopment §\n\nWe are experiencing an issue with the file system on metal-01.he-eu-hel1.nomos.misc entering a read-only state. This is preventing any write operations on the system, impacting normal operations and services.\nNomos node stability investigation - found a main reason for tesnet failing after some time, consensus engine has some asserts that are not met during the run. I’m trying to replicate the same behaviour in integration tests.\n\nprivate PoS §\nresearch §\n\nA consensus reference page has been written detailing the path and the history of decisions made as a context to the other documents we have provided. It is important to mention that this is a living document that might be updated further in the future.\nUpdated the ongoing document of DarkFi Crypsinous implementation with new details.\nSummarized the findings and ideas from different papers around byzantine gossip and consensus. There are some ideas that might be useful to us in the future.\nFor the Crypsinous lottery function analyzed the maximum likelihood (ML) statistical inference framework. The latter can be used by an adversary for inference of stakes of nodes to infer relative stake. Formally the ML framework suggests that observations of election statistics of all nodes are required in order to infer relative stake of a single node. However, for long time observations there is a possibility that statistics for a single node are sufficient to infer its relative stake. The analysis of this scenario, which uses a “naive” estimator of relative stake, is currently in progress.\nNormalize stake for leader lottery: Summary with plots and equations can be found here.\nWe have a new analytical tool for analyzing the average of our process for learning stake, it lets us study how the process converges without the slow simulation runs and makes analytical work much simpler.\nWe found that our process for learning D will underestimate true total stake by up to 3% (depends on our choice of constants), we have some analytical bounds on the underestimate and confirmed them with simulation.\n\ndata availability §\nresearch §\n\nFinished the comparison article of DA structures (Merkle Tree, RS+KZG and Merkle Tree+Snarks) and reach the conclusion that the structure we designed is flexible. We can easily switch to the Merkle tree + Plonky2 structure in the future.\nSome additional research notes in terms of DA comparison can be found here.\nSkimming through NOTRY: Deniable messaging with retroactive avowal to check if there is anything interesting to us\n\ndevelopment §\n\nNo updates\n\nmiscellaneous §\n\nArchitecture whitepaper will be reviewed internally by the team in the following weeks.\n"},"nomos/updates/2024-01-08":{"title":"2024-01-08 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nThe Mixnet specification doc has been updated with new details after a discussion was help in terms of establishing connections in advance - Whenever a Mixnet topology is reconstructed, each mix node in the layer l establishes connections optimistically with all mix nodes in the layer L+1 , in order to reduce the latency of individual packet delivery - more details in the relevant comments in the linked Notion doc.\n\ndevelopment §\n\nNo updates\n\ntestnet §\ndevelopment §\n\nIncreased the storage limit in addition setting up firewall rules for the Nomos http ports - they are set in the same range for containers and host - more details here.\nOpened TCP ports 18080-18083 for HTTP - more details here. Also opened some additional ports\nAdded missing configuration and fixed conflicting rules for ports: Limit number of committed blocks in info requests - more info here; Receive blocks blobs in parallel - more info here; Set and get blocks tip without filtering - more info here.\nOptimized consensus related methods, the changes allow node to run without problems on a testnet: CI - more work in progress (in terms of DA specification)\n\nprivate PoS §\nresearch §\n\nAfter trying 6 attempts, we had a breakthrough in understanding variance of our learning process around the fixed point: this latest method shows very good agreement with simulation across the full parameter space that we tested - This sets up to answer some of the burning questions we have had for a while (How big should T be, how small should delta be, how fast does this converge).\nWe came up with a good measure of “centrality of stake”, this has allowed us to do much more informative simulations across the parameters that matter: More detailed update with plots in Notion: 2024-01-08 Progress\nAnalysis of total stake inference problem: the analytical framework, derived for the algorithm which uses Crypsinous lottery function stochastic process to estimate the total stake, was used to construct the simplest possible theory which describes expectation and variance of the total stake statistical estimator.\nSeveral approaches were tried, including mapping to the physical thermal relaxation process, but explained simulations but only for a limited scope of parameters.\nThe latest approach, which uses large stake expansion, leads to simple theory with a small number of parameters which explains simulations quite well. More details here.\nLarge numbers of validators issue has been documented - something that Carnot doesn’t solve implicitly - more details here.\n\ndata availability §\nresearch §\n\nWe have made a new design - the 2D Data Availability Structure based on a problem whether the execution zones perform the RS-encoding process correctly; it has been solved accordingly but it is costly due to the size of the data - more studies to come.\nThe protocols we have examined and also designed so far were compared on relevant data. Detailed information can be viewed here. Additionally, the total data size can be accessed by entering the data size and number of nodes here\n\ndevelopment §\n\nNo updates\n\nmiscellaneous §\n\nArchitecture whitepaper is being reviewedg.\nShared sequencing - compiled notes on some of the implications, architectural designs, discussions, inspirations and more, in an article here.\nNotes on the MTR Declaration of Decentralization provided [here](https://www.notion.so/Filip-8b260c1bfddd43cc9cd1211478be53e8 here- It is in an interesting proof of value approach (mix of PoS on main chain with a sidechain Relay/CER for the PoW, merged every sidechain’s 30 blocks), that they are utilizing, but I think that it has too many holes to fulfill - risks and attack vectors. Even though the ecosystem has been live for a couple of years, it never reached the heights they apparently planned. They focused too much on becoming “big” rather than building up from ground zero. However, the interesting design choice is their utilization of sidechains (more precisely their adaptors and connectors) in the attempt to connect to other ecosystems. The paper didn’t provide too many details about it though.\n"},"nomos/updates/2024-01-15":{"title":"2024-01-15 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nNo updates.\n\ndevelopment §\n\nRefined Mixnet specs: Decided to use libp2p even for direct QUIC connections for v1, so that we can use peer discovery and NAT traversal later on; Defined an initial approach to report on unresponsive mix nodes, though it should be improved later; Simplified the specification of using Sphinx packets, by abstracting the internal Sphinx spec ;Updated the calculation of lambda and mu by suggesting a refined approach of emission rates; Decided to start with only mixnode-defined delays.\nThree quarters of mixnet python specification code has been done; since it has been decided to move Sphinx out of the mixnet specs(see comments) - it will be moved to a new repo in order to be utilized properly; the basic structure and topology construction and Sphinx packet builder have also been added.\nResearch of QUIC and QUIC connections - what is available and what is the difference from the TCP connections\n\ntestnet §\ndevelopment §\n\nInitial node metrics PR has been merged - to reiterate, this will add metrics service + initial metrics for CL and DA mempools. We will continue the effort to collect data about other services in the coming weeks.\n\ncryptarchia §\nresearch §\n\nThe Private Proof of Stake milestone has been renamed to Cryptarchia in order to better reflect current work.\nUpdated the living document that showcases if the leader election function leads to wealth concentration - more precisely the stochastic fork choice rule - which seems to ignore the validator stake.\n[Analysis](https://www.overleaf.com/read/fzbrxvkwwscq#f2907c](https://www.overleaf.com/read/fzbrxvkwwscq#f2907c) of total stake inference problem: For the statistical estimator of the total stake D, the results of a large stake expansion were used to derive Gaussian approximation for the distribution of D. The latter was used to define “confidence” and “accuracy”. The large stake expansion was used to study other important properties, such as convergence rate of inference algorithm, and provides a relatively simple and compact set of relations between different parameters, such as number of nodes N, learning rate h, number of epochs T, stake mean and stake variance\nWe were able to answer most of the open questions (from previous weekly - remaining is analytical grounds for fast convergence) - How big should T be (# of slots in an epoch), How small should h be , How fast does this converge.\nWe have a general solution to the total stake inference problem - based on this document we have a good understanding of Accuracy, Convergence Rate and Stability.\nWriting of the Cryptarchia specification is well underway - you can check the latest version here.\nReviewed Ouroboros Praos, the focus was to understand the whole design and put a bit more attention at the design of the random beacon and some security assumptions. More on that in the notes.\n\ndevelopment §\n\nThe Cryptarchia development plan initially stated is still valid and has been updated. We will have the first milestone defined soon as well.\nRefactor consensus engine in preparation for adding a new consensus - PR.\n\ndata availability §\nresearch §\n\nThe DA Layer Comparison table has been finished and is currently in review and update phase. For the raw data, refer to this Google sheet\nBlock format specification has been added.\nDA API specification has been added.\n\ndevelopment §\n\nMerged a couple of small fixes for the nomos-chat app - more details here.\n\nmiscellaneous §\n\n3 interrelated topics that have the potential to create an interesting element of differentiation have been researched: turning Execution Zones into Plasma chains with ZK proofs (findings), solutions for instant deposit/withdrawal, solutions for ZK-bridging with the Base Layer (basically the CL layer, but as minimal as possible).\nPolygon Avail has been researched - findings.\nSimulations working principle (the Carnot paper Appendix) has been added.\nWhitepaper feedback review in progress.\nCarnot paper has been reviewed.\n"},"nomos/updates/2024-01-22":{"title":"2024-01-22 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nOne of the last pieces of the mixnet specification: “Defining topology update and entropy injection in a clear way” - we are close to a solution and will include new findings next week. To see the current proposal and differences being discussed (for example architecting the consensus and mixnet interaction) please check the GitHub PR. Code review is also in progress.\n\ndevelopment §\n\nTested libp2p stream protocol for the mixclient->mixnode and mixnode->mixnode communication. Concluded that’s very simple and appropriate for our case because it’s the fundamental protocol that is used for other libp2p protocols such as DHT. That’s basically not very different from the naive communication implementation over QUIC or TCP.\nCompleted several PRs (with code-review as well) Topology, Sphinx packet construction, Packet delays, Mix client Poisson emission.\nDesigned the updated Nomos Rust project structure for mixnet v1.\nAnalyzed the rust-libp2p QUIC transport in terms of configuration and implementation details.\n\ntestnet §\ndevelopment §\n\nRemoved the async-trait from the node as well as Overwatch.\nGrafana and related services addition to the testnet (new PR).\nPreparation for demo chat app bot, ability to send data from file, non-interactively (new PR).\nPrune Carnot old block PR has been completed and is currently in review.\nAdded a test for big blobs dissemination.\nLimited the number of in-flight requests performed by the chat app to avoid using too many descriptors - more details here.\n\ncryptarchia §\nresearch §\n\nUpdated the wealth concentration analysis with the new [chapter](https://www.notion.so/Does-Crypsinous-Leader-Election-Function-lead-to-wealth-concentration-in-PoS-b81f07a791b745438443f51f00ac258f?pvs=4#1df422f6cc204cb8b362f41cda260b8b about stake relativization algorithm. The section about known total stake is also in progress.\nStake relativization specification is complete.\nSet up an analytical framework which will be used to study the impact of using the (biased) total stake estimator on the leader election process. The central object of this framework is the joint probability distribution of two copies of the election process with the same (random) sampling noise, the same stake but different values of the total stake.\n\ndevelopment §\n\nNo updates, heavily in research.\n\ndata availability §\nresearch §\n\nDA API specification is written (likely to change due to active discussions).\nDA Layer Comparison article is almost finished - there are several comments still left to be resolved. Protocols were explained in more detail. Tables have been updated and to see the raw updated data on its own refer to this sheet.\n\ndevelopment §\n\nDA implementation plan is written (with active discussions it is likely to change).\n\nmiscellaneous §\n\nDevised a plan to take action for Nomos marketing and comms strategy: devised a couple of WIP docs (strategic one and mission one). We will start compiling our resources to help out the comms team with “ammo” for the Twitter and other social media.\nCarnot paper is currently being reviewed. Team feedback collected, several issues (for example of administrative and legal nature) were raised and will be addressed.\n"},"nomos/updates/2024-01-29":{"title":"2024-01-29 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nThe Mixnet specification is ready for review and can be frozen with the current version for v1 (until we find additional requirements during the implementation).\nDefined the mixnet topology update mechanism as a result of internal team discussions - conclusion: we should abstract a robustness layer that will handle mixnet configuration.\nRedefined mix destination: Instead of having an extra hop to the mix destination after L layers, we’re going to use the last mix layer as the mix destination (for message reconstruction).\nAlso, the problem of the common view of candidate nodes for mixnet participation was raised - how to ensure that the whole network will know which mixnodes are selected. As previously discussed, we confirmed that we need to have a dedicated staking action for registering candidate mixnet nodes on-chain - the sampling will be performed only from the list created by that staking action.\nThe PRs that entail the changes and piece them all together in the executable mixnet specification can be found here and here.\n\ndevelopment §\n\nAdded a couple of PRs in preparation for the mixnet rust development - crate structure, remove mixnet legacies 1, and remove mixnet legacies 2.\n\ntestnet §\ndevelopment §\n\nStarted the document on the design of Block Explorer 2. Also, added a PR regarding naive blocks query implementation from the storage layer (the PR is still open with an ongoing discussion).\nAdded a testnet basic bot to the chatapp non-interactive mode (PR). In more detail, we have previously added the ability to disseminate a file to the DA in the testnet, and we updated the chatapp with a similar functionality, which is used to have a bot that constantly pushes readable data to our DA in the testnet. This data (as opposed to file upload) will be readable by our testnet users and will be useful during the demos.\nContainer for the basic bot PR - performed some required changes to our testnet infrastructure.\n\ncryptarchia §\nresearch §\n\nUpdated the wealth concentration analysis chapter about stake relativization algorithm.\nStarted the Nomos Tokenomics Design Canvas that will be filled in with additional details in the future.\nWe have discussed an alternative path for the leader election function (stake relativization) in the. Refer to this comment for more details. This helped answer a high-priority question: Do we need to learn total stake?\nThe initial version of the Cryptarchia executable specification PR has been merged.\nAdded fork choice rule to the Cryptarchia executable specification.\nMerged implementation of slot leader election check to the Cryptarchia executable specification.\nAnalysis of Impacts of Approximate Total Stake - having considered two alternative election histories of a node (one when using the true stake and the other when using the approximate stake), the population study shows higher staked nodes are more impacted by errors in estimating total stake. Also, impact on the finality study shows high sensitivity to overestimates of stake. This was done by deriving the analytic expression for the Hamming distance between the two aforementioned histories which allows quantifying differences - for the detailed analytic work, refer to the Overleaf document.\n\ndevelopment §\n\nNo updates, heavily in research.\n\ndata availability §\nresearch §\n\nDA Layer Comparison article has been updated according to the latest review. In addition to that, we also provided details about the Ethereum Danksharding Protocol and its comparison to the Nomos DA protocol (according to our research).\nVID Certificate section in the DA API Specification has been added. In it, we explained the steps required to create VID Certificate and their order, described what data is sent to different participants (Nomos Zone, DA Node, Block Producer). We have reviewed it internally and added some new questions and comments - refer to the discussion for more details.\nBased on the definitions from the VID certificate, revised the Block DA Metadata structure with some minor updates, more precisely with the data that should be written in the block for DA.\n\ndevelopment §\n\nNo development updates.\n\nmiscellaneous §\n\nFinalized v0.5 of the darkpaper: updates according to feedback and new insights and strategy: rewritten several sections and eliminated a bunch of sections that were not satisfactory. Some changes of the darkpaper are conceptual, not just cosmetic, improving the strategical focus.\n"},"nomos/updates/2024-02-05":{"title":"2024-02-05 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nPolishing the mixnet specification regarding the topology algorithm and all parameters - we’ve had some concerns about it, so there are several ongoing discussions on Notion and GitHub in regards to answering them. For more details on the discussion, check this PR.\nWhile it has been postponed from v1, we will have to define the mix node identity soon for incentivization.\nAfter careful consideration and discussion, the topology update and public APIs PRs for core logic have been merged.\n\ndevelopment §\n\nAdded a utilities function of python mixnet to rust PR. Currently in review.\n\ntestnet §\ndevelopment §\n\nAdditional polishing (route separation) of the Naive blocks query implementation from the storage layer PR.\nAdded DA API for Explorer, while removing the unused API PR - currently in review.\nIntegrated the block explorer into the demo. Currently thinking about writing integration tests for it.\nTestnet fixes PR: the testnet ran on Linux with no issues; however, several fixes were needed for it to work on MacOS (about Grafana, Nomos chat bot params, and Nomos chat OpenSSL libs build version).\n\ncryptarchia §\nresearch §\n\nUpdated the wealth concentration analysis chapter about the stake relativization algorithm - specifically about the impact of the stake relativization.\nUpdated the Nomos Tokenomics Design Canvas with details about the “Validators” role. More roles to be entered in the coming weeks.\nAdded the fork choice rule PR as described in “Ouroboros Genesis: Composable Proof-of-Stake Blockchains with Dynamic Availability”. Tests will be added later.\n“Follower maintains ledger state as it follows the blockchain” PR. Leader coins are now spent when they become slot leaders. The next step is to have the leaderproof produce a new coin that the validator can then use to lead another slot.\nMerged the “Add header ID and message” PR.\nSummarized the mathematical analysis work in the Impact on Forks chapter and Reducing Forking chapter. More precisely, derived the probability of the “forking” event and the “empty slot” event when the approximate value of the total stake is used. Considered the large total stake and finite number of slots scenario to derive the typical number of forks and empty slots expected in the T number of slots. This framework was used to assess impacts of underestimation/overestimation of the total stake on the number of forks and empty slots. For the detailed mathematical analysis, check the Overleaf document.\n\ndevelopment §\n\nNo updates, heavily in research.\n\ndata availability §\nresearch §\n\nDA Document has been updated with new details based on the team review (specifically around adding more details about Ethereum Danksharding).\nMerged a mandatory PR containing a big chunk of primitives from the ETH specification that’s a dependency for building our DA specification. It will help us save a good amount of time during our implementation (and testing) of everything.\n\ndevelopment §\n\nStarted work on the DA Layer Implementation Details document. This is a an executable spec.\nThe sketch of the DA layer can be seen in this branch.\n\nmiscellaneous §\n\nThe website’s copywriting has been updated to reflect the changes from the Darkpaper.\nStarted publishing posts on X.\nWe have chosen several articles and will be publishing more detailed, scientific blog posts in the coming weeks. Once the specifications are complete, they will also be communicated via our social media.\nDarkpaper v0.5 published internally.\n"},"nomos/updates/2024-02-12":{"title":"2024-02-12 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nStarted the investigation of the mixnet participation problem. We have looked at Nym and how they constructed a mechanism for populating the mixnet. We extracted the design and described it in detail here. In short, they require the mixnet nodes to register on-chain; once there, they are randomly selected using weight as stake (plus delegated stake), and rewards are paid based on the mix node performance.\n\ndevelopment §\n\nNo development updates.\n\ntestnet §\ndevelopment §\n\nFixed the race for nomos log service PR.\nNomos-cli: Integrated the explorer into the nomos-cli in one PR with the integration tests coming in another one once it is unblocked (blocked due to the sled dependency).\n\ncryptarchia §\nresearch §\n\nNew details have been added to the Cryptarchia specification: the epoch transition, nonce specification, orphan proofs validation, leader lottery VRF details, leader coin evolution. With these additions, the Cryptarchia v1 is now ready internally.\nThe impact of approximate total stake (total stake underestimation/overestimation) document has been finalized and summarized. Awaiting internal review. For the mathematical analysis and results, please check the Overleaf document.\nWe have considered adversarial statistical inference of relative stake when the Ouroboros Crypsinous lottery function is used in the leader election process while assuming that only a fraction of election results are observed. For this scenario, we also derived a statistical estimator of relative stake. The analysis of the (naive) statistical estimator is currently in progress. The summary of this work is provided here while the detailed analysis can be found here.\nTokenomics Design Canvas has been updated with new objectives & requirements in addition to new sections.\nAdded a chapter about the “stake relativization algorithm” to the “Does Crypsinous’ Leader Election Function lead to wealth concentration in PoS?” document.\n\ndevelopment §\n\nNo updates, heavily in research.\n\ndata availability §\nresearch §\n\nThe DA Layer Comparison Table has been finalized, after several reviews and additional efforts.\nData Availability Specification has been updated according to recent comments.\nDA protocol details page has been created with the protocol diagrams included in the latest iteration.\nThe DA specification has been updated with new details. To see them and, in general, the progress of the DA specification, refer to this PR.\n\ndevelopment §\n\nDue to the focus on the DA Specification, protocol details, and the comparison table, no development updates.\n\nmiscellaneous §\n\nBlog coming this week and will be posted on the Nomos website (with the link on our X/Twitter).\n"},"nomos/updates/2024-02-19":{"title":"2024-02-19 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nBased on previous investigation, started a document about integrating the population strategy from Nym into the Cryptarchia setting. In it, while following an explicit staking assumption, it is assumed that a node that wants to be a mix node must register and stake on-chain. WIP with a lot of potential changes.\n\ndevelopment §\n\nImplementation WIP: defining structure for mixnode / mixclient.\nImplementation: concluded that the nymtech/sphinx crate can be used for our use case. For reference, previously we used a wrapper of sphinx developed in the nymtech/nym codebase - but now, we can use the nymtech/sphinx crate as it is.\nModified libp2p to use QUIC. Replaced TCP with QUIC in the nomos-libp2p crate, which will be used by the mixnet network backend: PR.\nFixed integration tests for QUIC. With the QUIC updates, some DA integration tests were failing - now they are working properly: PR.\n\ntestnet §\ndevelopment §\n\nCreated a document regarding embeddable databases with their analysis. In more detail, the document includes benchmark code, analysis of several rust-based DBs, a proposal for which DB we should use, and example code for our most important use cases.\n\ncryptarchia §\nresearch §\n\nUpdated the “Does Crypsinous’ Leader Election Function lead to wealth concentration in PoS?” document with new details about stake relativization - more precisely new simulations in regards to validators of certain ranges.\nStarted building out a NIZK (Non-interactive Zero-Knowledge) Glossary of terms that will be used for internal education as well as writing the specification.\nWIP: writing a how-to guide for reading/writing NIZK specifications. This will help us in the future when writing certain Nomos specifications.\nAnalysis of de-anonymization of relative stake: for adversarial inference of relative stake in the leader election process, considered statistical properties of (naive) maximum likelihood (ML) estimator of relative stake - in the naive ML approach, the relative stake of node i is obtained from the frequency of observed 1’s, representing vins in elections, and properties of lottery function. Also, analyzed statistical properties of the naive ML estimator of relative stake. The consequences of the aforementioned results for the mixnet are in progress and will be shared in the future. To see the math behind the analysis check the Overleaf document.\n\ndevelopment §\n\nNo tangible updates - but Cryptarchia rust implementation is in progress, more details in the coming weeks.\n\ndata availability §\nresearch §\n\nInitial DA API specification structure PR: defined mock zone, DA node and block producer to wrap DA spec and use it for encoding, dissemination and verification. Once the DA spec is near finalization, we will continue the mock implementation in python.\nDA Specification updated per reviews and comments. Likely more changes on the way (depending on review).\nStarted a document on studying VeriZEXE and Taiga designs. WIP, currently includes initial notes, likely to change.\n\ndevelopment §\n\nStarted implementing KZG core functionality of DA - more details in the upcoming weeks.\n\nmiscellaneous §\n\nFinalizing v0.6. of the darkpaper for internal release.\nFinalizing the first blog post for internal release.\n"},"nomos/updates/2024-02-26":{"title":"2024-02-26 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nAnalysis of the fraction of compromised paths in the mix network: developed an (asymptotic) analytical framework for the analysis of the fraction of compromised paths in the randomly generated mix network. Calculated the average and variance of the fraction of compromised paths. In the regime of a finite number of layers and very large width, the variance is vanishing, and the fraction of compromised paths becomes deterministic. Analysis of the large number of layers and large width regime is currently in progress.\nContinued the investigation of the mixnet population - analyzing the proof of mixing under the explicit staking assumption for Cryptarchia: Trying to reason the possibility to limit the number of active staking parties and uphold the same security properties as Nym has. In conclusion: without active participation of “users” (regular nodes) we cannot effectively measure the performance of the mixnet. On top of that, the engagement of the regular nodes must follow the same design as mixnet formation - it must be incentivized.\n\ndevelopment §\n\nImplemented the full spec of mixnet v1. Preparing to open a couple of small PRs by splitting a few of the bigger ones.\n\ntestnet §\ndevelopment §\n\nNo updates.\n\ncryptarchia §\nresearch §\n\nThe Tokenomics Design Canvas has been updated. Among other updates, it is important to mention that we added a new role to the canvas - Light nodes (Zone verifiers and replication providers).\nScraped cexplorer for the individual stake values held in Cardano’s: Notes.\nSimulations and plots to validate stake privacy analysis: Analysis.\nAnalysis of de-anonymization of relative stake: for adversarial inference of relative stake in the leader election process, considered statistical properties of maximum likelihood (ML) estimators of relative stake. A number of empty slots were included in the ML framework but lead to an inconsistent estimator of the relative stake - this result was confirmed in simulations. The ML framework was used to infer the relative stake in simulations using synthetic and real stake (Cardano) data. Simulations suggest that at least a 1/100 fraction of the network has to be observed at any time to infer the relative stake of the top 1% nodes with high probability within T=432000 time-slots. Summary and the detailed analysis.\n\ndevelopment §\n\nCryptarchia first PR - Cryptarchia engine - is ready for review - it’s mostly a translation from specs code apart from a few routines that were made more efficient. Additional things (e.g., orphan proofs) will be added in a future iteration.\n\ndata availability §\nresearch §\n\nStudied on the BLS threshold Signature. The detailed explanations of BLS-pairing and signature aggregation are finished - document.\nStudying Taiga designs (WIP) - This article discusses the architectural differences between the privacy-preserving execution environments Taiga, Zexe, and VeriZexe in the context of smart contract systems.\nStudied on the python implementation of KZG to understand the verification check problem. We solved the bug encountered previously - PR.\n\ndevelopment §\n\nDA API implementation for FullReplication protocol in progress: added Certificate Metadata definition and integration PR.\nResearch on SurrealDB - captured the notes as part of the greater DB research document.\nImplemented RocksDB storage service - PR. Based on this also opened the PR to start using RocksDB as the backend.\n\nmiscellaneous §\n\nv0.6 of Darkpaper is close to finalizing (internally). After the introduction is written, we will coordinate the public release.\nThe first blog (Is Network Anonymity Alone Sufficient for Proof of Stake Systems) is being finalized. We have one more round of comments to review and add the blog feature to the nomos.tech website. The next blog (regarding wealth concentration in PoS) is in progress.\n"},"nomos/updates/2024-03-04":{"title":"2024-03-04 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nStarted rewriting the “Populating mixnet” document, leading to the creation of a new document that combines both previous mixnet-related documents. Initial editing was done, a couple of minor sections have been added, and an additional section has been created that discusses a couple of cryptoeconomical problems requiring more investigation - WIP.\nMixnet Incentivization: started a new document that will contain the understanding of the mixnet incentivization problem.\nAnalysis of the fraction of compromised paths in the mix network: In the regime of a finite number of layers and very large width, the variance is vanishing, and the fraction of compromised paths, alpha, becomes deterministic. This, however, is no longer true when the number of layers and width of layers are both large. For this regime derived an analytic (asymptotic) expression for the probability that α belongs to some interval [alpha_0, alpha_1]. Verification of this analytic result by simulations is in progress, and the summary is here.\n\ndevelopment §\n\nMixnet network backend skeleton - PR.\nLibp2p stream read/write - PR.\nEmitting packets from mixclient using libp2p stream - PR.\nHandle outputs from mixnode using libp2p stream/gossipsub - PR.\nRefactor Poisson distribution implementation - PR.\nMix client Poisson emission - PR.\nMix node packet handling - PR.\nMix Packet / Fragment logic - PR.\nMove FisherYates to nomos-utils - PR.\nMixnet topology - PR.\nMix client/node unit tests PR.\nNote on the PRs above: tests will fail because the whole implementation has been split into small PRs. All tests will pass at the last PR that will be opened.\nTaking some time to refactor network adapter codes that are tightly coupled with only the libp2p network backend.\n\ntestnet §\ndevelopment §\n\nWIP: Integration for explorer - PR (marked as WIP since one of the unit tests is failing).\n\ncryptarchia §\nresearch §\n\nTokenomics design canvas has been updated with additional clarifications regarding the “Light node” role (both Zone verifiers and providers of replication).\nStake relativization has been updated as part of the Cryptarchia specification.\nStarted the Block rewards document to discuss and propose solutions to rewarding new block proposals.\n\ndevelopment §\n\nMerged all PRs for Cryptarchia here and here.\n\ndata availability §\nresearch §\n\nSeveral libraries were reviewed for the implementation of RS encoding. The usage of FFT in the implementation was examined. In the initial stage, details on how the implementation can be carried out were outlined here.\n\ndevelopment §\n\nKZG core functionality (working version) has been implemented - PR.\nStarted RS: implemented encoding.\nStarted RS: decoding implementation in progress.\nDA API Verified certificate selection from the mempool function - PR.\nDA API sign attestations in full replication - PR.\nDA API signer tests - PR.\n\ncoordination layer §\nresearch §\n\nThe examination of the Taiga design continues. Technical details and the cryptographic functions used are being researched. Verifiable encryption is under consideration, and existing libraries in the literature are being reviewed. Notes and questions related to the Taiga design are documented here (WIP).\nAs part of the same effort with the previous point, created two more documents here and here that envelop additional efforts on studying Taiga.\n\ndevelopment §\n\nNo updates at the moment, heavily in research.\n\nmiscellaneous §\n\n1 new blog post is in review regarding Wealth concentration in PoS systems. Currently in the first iteration.\n"},"nomos/updates/2024-03-11":{"title":"2024-03-11 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"cryptarchia §\nresearch §\n\nWe have updated the Cryptarchia specification with the update epoch stabilization schedule - PR.\nAnalysis of adversarial inference of relative stake: derived an equation that can be used to infer the Lagrange parameter in the maximum likelihood inference of relative stake - the details of the analysis.\n\ndevelopment §\n\nRemoved assumptions on Carnot being the consensus algorithm in the mempool: PR.\nSeparate ledger and consensus to prepare for integration: PR.\n\nmixnet (network privacy) §\nResearch §\n\nWork in Progress (WIP): The Mixnet Incentivization document has been initiated. Current open questions will be addressed, covering system design, mathematical analysis, and more.\nContinuing work on the mixnet with staking, incorporating modifications based on feedback. A section has been added concerning the hidden bonus of deanonymization. It’s a straightforward observation that random assignment of adversarial nodes can, in some cases, lead to a higher number of adversarial paths than naively expected. Also, a section about discussing the latency and anonymity relationship has been started. WIP document.\nAnalysis of the fraction of compromised paths in the mix network: using an asymptotic lower bound to estimate the probability that the fraction of compromised paths, α, belongs to the interval [α0​,α1​]. The analysis suggests that in the mixnet of size n=240 with L=3 layers sampled from N=800 nodes, where M=200 nodes are adversarial, α can be almost three times larger than the average (M/N)L which assumes a mixnet of infinite width. The parameters n=240, L=3, and N=800 are currently used in Nym’s mixnet. Here for ¼ of adversarial nodes, the fraction of compromised paths can be as high as 0.05. To compare, the average here is 0.02. Summary is provided here.\n\ndevelopment §\n\nAll PRs for Mixnet v1 implementation have been merged. We’ve taken some additional time to polish the code according to feedback.\nOne remaining PR we are working on is adding a compilation option to enable mixnet. We’re going to always enable mixnet in production, but we’ve discussed that it’s also good to remain in the libp2p-only compilation mode for development to unblock other dev topics until everything of mixnet becomes stable. Will be finished this early this week.\n\ndata availability §\nresearch §\n\nNo current updates.\n\ndevelopment §\n\nFinished RS core encode/decode: there was an issue with different FFT calls from different libraries that didn’t work and took a while to debug. They use floating numbers, and when rounding or using a big set of operations, precision leads to errors - PR.\nImplemented DA protocol encoder: PR.\nImplemented DA protocol verifier: PR.\nDA API mempool tests using a mock implementation PR - The previous PR defined an abstraction for verifying and filtering what to include in the generic mempool; this PR provides mock implementations for TX and Cert verification/filtering. WIP: DA API indexing for data blobs - adding an index to data blob in DA node when the certificate is observed in the block.\n\ncoordination layer §\nresearch §\n\nWe have begun a couple of study documents in terms of the Coordination Layer: What does it mean for an asset to be “inside” a Zone and Illustrated guide to “Mutator Sets and their Application to Scalable Privacy. With these documents, we want to solve questions and challenges before delving into the design.\nThe “Parallel Zero Knowledge Virtual Machine” paper has been reviewed, and a brief summary of GKR details has been shared.\n\ndevelopment §\n\nHeavily in research, no development updates.\n\ntestnet §\ndevelopment §\n\nExplorer works well now, can share the data directories with the node, and provide data through HTTP: PR.\n\nmiscellaneous §\n\nNomos has a new HackMD account - our team will be publishing various notes on it - mostly scientific in nature.\nBlog to be released this week. Stay tuned on our website.\n"},"nomos/updates/2024-03-18":{"title":"2024-03-18 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Cryptarchia §\nResearch §\n\nNo research updates at this moment.\n\nDevelopment §\n\nStake Relativization Specification - the spec implementation has revealed some bugs in our orphan proof handling logic. Those bugs are still being worked through in this PR.\nRefactored Cryptarchia implementation into ledger and consensus crates: PR.\nRefactored nomos header and block definition so that it’s now responsibility of the nomos-core crate: PR.\nAdded Cryptarchia consensus service: PR.\n\nMixnet (Network Privacy) §\nResearch §\n\nMixnet incentivization document has been further updated, more precisely the “Rewards” chapter that showcases the mathematic analysis and some of the parameters.\nFocused on researching the problem of mixing transactions by briefly investigating the economic perspective - emphasized on the fact that it can be a main source of the revenue for the mix network. Furthermore, we discussed the privacy perspective and potential negative impact on the privacy due to direct staking.\nStarted work on the Message Type Indistinguishability (WIP name) section, where we discuss the potential sizes of the messages, their impact on the throughput, mixnet capacity, and noted a rewarding thing leading to a negative on the privacy. Both this and the previous point can be found in this (WIP) document.\nAnalysis of the fraction of compromised paths in the mix network: optimized code which computes the (asymptotic) lower bound on the probability that the fraction of compromised paths, alpha, belongs to the interval [alpha_0, alpha_1]. The code takes the mixnet size n, sampled from N nodes where M nodes assumed to be adversarial, some initial fraction of compromised paths alpha_0 and outputs minimal fraction of compromised paths alpha_1 such that prob. that fraction of compromised paths belongs to the interval [alpha_0, alpha_1] is 1. The code can be used to design a program which optimizes the number of layers L given some threshold, on the alpha_1, which can be tolerated. However, one has to test if the asymptotic lower bound is suitable for this and gives alpha_1 which is not too loose. Summary of numerical results and simulations is provided in this document. Summary of analysis is provided in this document and the detailed analysis can be found in the Overleaf document.\n\nDevelopment §\n\nIntegrated mixnet network service for consensus, DA, and mempool: PR.\nUpdated nomos-node integration tests for Mixnet: PR.\nRefactoring mixnet code: PR - and further PRs to be opened soon.\n\nData Availability §\nResearch §\n\nA case for dispersing the same VID Certificate multiple times was discussed during development, shorter version can be found in this document (VID Related Open Questions chapter).\nBLS threshold details have been added in the relevant document. It was concluded that there could be a significant overhead in communication when using DKG. Instead, an agreement was reached to apply a different solution using aggregate BLS. The relevant changes have been updated in the specification document. At this stage, we will proceed with this method. To find the best solution for this part, we might ask for support from the VAC team.\n\nDevelopment §\n\nInitial DA API spec structure revised and merged: PR.\nTests using DA Protocol specs have been developed. Currently, there are 2 types of tests, which are showcased in the first PR and the second PR.\nFinalizing DA verifier protocol specification: PR.\nFinalizing DA encoding protocol specification: PR.\nFinalizing DA dispersal protocol specification. Full flow with tests included, using Encoders and Verifiers: PR. Also, they have gone through reviews and we started discussions in several PRs - #1, #2, #3\nAdded attesters bitfield to DA certificate. Missing compressed bitfield so we can use BLS aggregation of signatures as a threshold scheme: PR.\nAdded certificate verification specification.\n\nCoordination Layer §\nResearch §\n\nSynchronous Composability with Partial Transactions document with a proposed design.\nProgressed with the discussion on Atomic Asset Transfer w/ Taiga in this document.\nThe Taiga circuit structures have been reviewed again. Relevant comments have been added to the document.\n\nDevelopment §\n\nNo development updates.\n\nTestnet §\nDevelopment §\n\nNo updates at this moment.\n\nMiscellaneous §\n\nBlog is now live - feel free to take a look at the first article here. More to come soon!\n"},"nomos/updates/2024-03-25":{"title":"2024-03-25 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Cryptarchia §\nResearch §\n\nNo research updates at this moment.\n\nDevelopment §\n\nFixed a bug in the Cryptarchia spec regarding try_create_fork to find parent block.\nStake Relativization Executable Specification is done: PR. Also, implementing stake relativization revealed some bugs in our Cryptarchia spec which took some time to debug and write tests for. Also, the stake relativization spec has been updated with learnings from the implementation (changes were mostly around time management since we need the inferred total stake to be stable by the time we enter the next epoch).\nRegarding block rewards, our proposal would be to postpone this work for when we will have the CL available, as it’s likely best done through a ‘special’ transaction (probably in a block body rather than in the header).\nAs discussed, at this moment, we will not support multiple consensus protocols in node.\n\nMixnet (Network Privacy) §\nResearch §\n\nMixnet incentivization document has been updated with additional problem statements: we are exploring how to make delegations private.\nAnalysis of the fraction of compromised paths in the mix network: The asymptotic lower bound (asympt. l.b.) on the probability that the fraction of compromised paths, \\alpha, belongs to the interval [\\alpha_0, \\alpha_1] was used to obtain an upper bound on the maximum fraction of compromised paths, \\alpha_max, in the mixnet of size n sampled from N nodes, where M nodes are adversarial.\nComparing the asympt. l.b. and simulations shows that the latter provides a very loose upper bound on \\alpha_max when the size of mixnet n is fixed and the number of layers L is increasing. However, the asympt. l.b. provides a better upper bound on \\alpha_max when the width of the mixnet n_1 is fixed and the number of layers L is increasing.\nDerived the probability distribution for the fraction of compromised paths \\alpha in the mixnet of size n=n_1 L, where n_1 is the number of nodes per layer and L is the number of layers, with m adversarial nodes when n_1 is very large. In this regime, the number of adversarial nodes in a layer is a random variable from the binomial distribution with parameters n_1 and m/n, such that on average n_1m/n nodes per layer are adversarial. Summary of numerical results and simulations is provided in this doc while Summary of analysis is provided here and the details of the analysis are in Overleaf.\nMixnet with staking design: Message Type Indistinguishability - extended the message type indistinguishability section of the staking design document, where we added a part about the impact of the pledged and delegated stake based rankings on the privacy. This part of the investigation, led to coining the Staking Security vs Privacy dilemma, where we describe a tension between staking security and privacy. In short, staking can increase chances for deanonymization. The details can be seen in this document.\n\nDevelopment §\n\nSome refactoring work on following PRs: #615, #616, #618.\nWIP: Testing if mix client/node emit packets according to the specified Poisson parameters.\nWIP: Testing if enough packets are mixed in each mix node.\nWIP: Working on making the aforementioned two as metrics (for monitoring).\n\nData Availability §\nResearch §\n\nNo research updates at this moment.\n\nDevelopment §\n\nFixed a new storage issue in windows build CI: PR.\nAdded a new block subscription to consensus service: PR.\nDA API testing: PR.\nAdded Certificate verification to specs: PR.\nFixed arbitrary data encoding in the Encoder specs: PR. There was an issue with this, we can only encode up to 31bytes per chunk using bls. Notice that bls uses 32bytes field elements, but some 32bytes elements would be higher than the bls_modulus, hence we need to use 31bytes.\nAdded duplicated blobs verification in verifier: Verifiers need to return the attestation in case a duplicated verification comes around, or skip it depending on different stages: PR.\nMoved current DA API implementation to draft: DA Protocol abstraction will change. Until we have an updated version, the DA API work is on hold.\n\nCoordination Layer §\nResearch §\n\nWe’ve been reading Taiga source code, and putting up minor contributions as we go through it: PR - taiga#262, taiga#260, taiga#259.\nReviewed Synchronous Composability with Partial Transactions. The relevant article has been reviewed, and comments have been added.\nDetails regarding the proof of equivalence have been explained and python code for random proof generation has been added to the following document.\nAs part of our research effort, compiled the notes on - Bitcoin L2s, New Architectures, Coordination Layer.\n\nDevelopment §\n\nNo development updates.\n\nTestnet §\nDevelopment §\n\nRemoved unused nomos services: old metrics service replaced with a Prometheus PR and old http API removed PR.\n\nMiscellaneous §\n\nA new blog post will be published this week: Tackling the Challenge of Wealth Concentration in PoS Blockchains with the simulations and scientific results.\nWe have exciting new ideas cooking about updating the Nomos documentation - stay tuned!\n"},"nomos/updates/2024-04-01":{"title":"2024-01-04 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Cryptarchia §\nResearch §\n\nUsed the probability that the naive estimator of relative stake is inside some interval which includes the true stake α, δ(α), to derive an algorithm that suggests how to divide the stake of a node in order to reduce the quality of statistical inference by an adversary. The interval [α(1−γ),α(1+γ)] is parameterized by the adversarial “accuracy” parameter γ. The probability δ(α) can be interpreted as adversarial “confidence” gained after Tq observations (on average), where T is the number of time-slots in one epoch and q is the fraction of observed slots (for example due to deanonymization failure of the mixnet), that the inferred stake is within the interval [α(1−γ),α(1+γ)]. Assuming q and γ, a node can use its stake α to compute the probability δ(α). The latter is a monotonically increasing function of α, and dividing α among a number of nodes reduces the adversarial “confidence,” thereby reducing the quality of adversarial inference. The details of the analysis can be found in the following document.\n\nDevelopment §\n\nCryptarchia fuzz tests: tried various fuzz testing strategies, but finally ended up with a simple but clear fuzz strategy, through which we can test Cryptarchia by simulating the environment where the block proposal delivery (p2p networking) is not synchronous and not predictable. The initial PR for the basic strategy has been opened. Also opened a small fix found by the fuzz test: PR.\n\nMixnet (Network Privacy) §\nResearch §\n\nDiscussed the Staking-Privacy dilemma and came to a conclusion that the Nym design needs to be fine-tuned to reduce the impact of the delegated stake on the probability of selection of a node. We also need to investigate a mysterious constant that “controls the loss of competitiveness experienced by a Sybil attacker when it partitions the stake into multiple pledges”.\nPrepared a recommendation for the first iteration of the mixnet staking. The main motivation was to present a simple staking design for mixnet that is inspired by Nym but is simplified and will be updated when our approach gets more mature.\n\nDevelopment §\n\nAdding metric APIs for Mixnet - still work in progress. A PR will be opened for a minimal but essential metric API this week. This should be enough for now because the entire mixnet architecture may change according to the mixnet staking design. The first metric is going to be the number of packets that are being mixed in each mix node, which can be considered as the quality of mixing. More details in the relevant document.\n\nData Availability §\nResearch §\n\nNomos DA specification has been rewritten - a document has been added on top of the original one to make certain mathematical and technical details more digestible.\n\nDevelopment §\n\nNomos DA verifier sketch: We have started putting all pieces in place for getting the DA protocol implemented and integrated in the node. This implies some cleaning and refactoring that have impact in the code base. We have a da-v1 branch where we will be incorporating everything until it is ready and stable to be added to master - PR.\nPublished a draft branch with the first working version of the Nomos DA protocol. This will make a lot of changes including removing of old attempts and experiments. Notice that this branch will hold a lot of changes but that most of them will be incrementally included (and reviewed).\nBranch added: KZG+RS core in rust, bytes_to_polynomial method - not working atm but we are debugging to see what is the issue (looks like roots of unity related).\nBranch added: DA indexer - work in progress, removed all previously proposed mocks and structures as da protocol changed substantially.\n\nCoordination Layer §\nResearch §\n\nTaiga: compiled a report on the current state as part of our research efforts.\nTaiga made the choice to use blake2s for VP commitments and Poseidon for resource commitments. The experiment looks at prover/verify time when blake2s is replaced with Poseidon, and we get a near doubling in performance. More details in our experiment. The details of the Blake2s with Poseidon implementation have been reviewed in this document. As part of examining the usage of Blake2s and Poseidon in the Taiga implementation, a summary providing general information about ZK-friendly hash functions has been prepared.\nThe survey on proof systems is underway: to summarize, Halo2 stands out in implementations for private transactions. Its use of Plonkish arithmetization and consideration of lookup arguments make Halo2 advantageous. As discussed earlier, we prefer not to use a trusted setup-related feature like KZG in the coordination layer. Consequently, proof protocols involving trusted setups, such as Groth16 and Plonk, are less favored. Generally, there are three common polynomial commitment schemes used in existing protocols: KZG, IPA, and FRI. A comparison of these schemes has been added to the report. Even if we don’t use Plonk, the use of Plonk-ish arithmetizations in Halo2 is significant for performance. In addition, Nova’s folding improvement is critical for performance, but it requires the use of R1CS instead of Plonkish. Sangria, a folding scheme using Plonkish methods, is a new design worth exploring. Finally, after outlining the general framework for the coordination layer, we believe that upgrading cryptographic sub-algorithms for performance will not be too challenging.\n\nDevelopment §\n\nNo development updates.\n\nTestnet §\nDevelopment §\n\nNo updates at the moment.\n\nMiscellaneous §\n\nNew blog will be published after reviews - Stake relativization.\nNomos team will be at All-hands next week.\n"},"nomos/updates/2024-04-08":{"title":"2024-01-08 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Note §\n\nThis is a weekly update from the part of the team that didn’t attend the All-Hands Event in Athens.\n\nMixnet (Network Privacy) §\nResearch §\n\nRegarding the current situation with the mixnet and staking, we have decided to focus on the simplest approach, that is only single-staking without stake delegation as suggested for the first iteration of the staking. Due to the simplicity of this approach, we can model it more precisely and learn more of its properties.\nWe have received a couple of comments regarding the mixnet from an external reviewer. The comments and our analysis can be seen in this document.\nReviewed an interesting critique of mixnets and suggestions on their improvements. One of them is the Poisson mixing design choice that is part of Nym and is claimed to be wrong. This led to a discussion on how to design a better mixing mechanism. We don’t know exactly what is broken in the Poisson mix; there are some claims and some proposals on how to solve the problem suggested in the presentation. We have asked for more paperwork supporting their claims and the authors of the presentation are working on it. In the meantime, a proposal has been prepared based on suggestions from the presentation.\nLooked at the Bittensor proposal (especially the idea of treating a node as a learning machine and combining it with a rewarding function), read through all of their papers. If we would like to use a similar approach then we must prove that the outcome of the mechanism cannot be biased - which might be very hard.\nOptimization of mixnets: written the initial specification and some functions for the algorithm which uses the (asymptotic) lower bound on the probability that the fraction of compromised paths belongs to some interval to compute the optimal number of layers. The details are provided in this document.\nAlso, tried to tighten the bound on this probability using the AM–GM and Markov’s inequalities, but trying this approach has not produced any improvements so far. The details are provided in this document.\n"},"nomos/updates/2024-04-15":{"title":"2024-01-15 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Note §\n\nThis is a weekly update from the part of the team that didn’t attend the All-Hands Event in Athens.\n\nMixnet (Network Privacy) §\nResearch §\n\nMixnet mixing problem: Based on the critique of the Loopix mixing design and proposed solutions, we have prepared an updated mixing design.\nWe are going to prepare a Mixnet empirical analysis tool, so that we can make sure that our Mixnet design meets a proper level of anonymity that we expect. This will probably be based on our executable specification, so that anyone in the team can run it easily whenever they want. Based on it, our reference implementation (Rust) will expose similar metrics, so that we can monitor its behavior in the testnet (probably in collaboration with Vac). This will be useful for finding the Poisson problem mentioned in the previous weekly, for example.\nNetwork bootstrapping/node registration: started thinking through the problem of network bootstrapping and the requirement of node registration. Looking for inspiration, details of the very early discussion can be found in this WIP document.\nOptimization of mixnets: derived an upper bound on the probability that the fraction of compromised paths, α, is greater than some threshold 1α1​. This new upper bound is non-asymptotic, i.e., for mixnets of any size n sampled from the population of N nodes, and much simpler to compute numerically than previously considered asymptotic bounds. Initial results of comparing this upper bound with simulations suggest that the bound is “practical”, i.e., can be much smaller than the trivial bound of 1, and can be used in optimization of mixnets. The summary of this work is provided in this document, and the detailed analysis can be found in the Overleaf document. Further simulations and work on the algorithm are currently in progress.\n"},"nomos/updates/2024-04-22":{"title":"2024-01-22 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Cryptarchia §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMixnet (Network Privacy) §\nResearch §\n\nDefined metrics to be collected for Mixnet (for other components as well, but mainly for Mixnet). This list should be sufficient for now.\nInvestigated which empirical analysis had been done by Loopix paper and another paper, in order to design Nomos empirical analysis soon. When compared to our previous work, it isn’t so different. The main goal would be measuring the probability of linking an output message from a source message correctly. Still remains to determine if this should be for executable spec, or for a real implementation.\nPlanning the first collaboration with DST. This would focus on the Mixnet properties, but only simple metrics as the first step. Before starting the collaboration, we need to check if this list is really reasonable to be offloaded to DST.\nIn consideration on how we can avoid node distinction and registration, and while reviewing the Hopr design an idea arose of changing the layered mix topology (Nym) to a circular one which enables users to extend their number of hops freely, and using gossip pub-sub protocol as an underlying messaging to achieve mixing over P2P. Therefore, we are able to have at the same time privacy (and scalability) optimal layered mix (with flexibility of adjusting the level of anonymity - path length) that does not require registering node long-lasting public identifiers (IPs) and works on top of a P2P network. All this led to a sketch of a new type of a mix, the “Whirl” Mix.\nNew Network Privacy proposal has been made, based on the updated and clear vision/roadmap of Nomos.\nOptimization of mixnets: considered a scenario when all N nodes, where at most M nodes are adversarial, are used to construct the mixnet with L layers. Proved that in this case the fraction of compromised paths 𝛼α is at most (𝑀/𝐿)𝐿(M/L)L which was also verified by simulations. The histogram of 𝛼α obtained in simulations only has a long left tail. Properties of the above mixnet are very different from properties of mixnets of size n sampled from N nodes. Here the fraction of compromised paths is always bounded by 1. This suggests that for small (or moderate) N using all nodes could be more desirable. The summary of this work is provided in Notion while the details of the analysis can be found in Overleaf.\n\nDevelopment §\n\nNo development updates.\n\nData Availability §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nMerged KZG+RS core (implementation of the KZG and RS core methods): PR.\nImplemented and merged DA V1 encoder: PR.\nImplemented and merged DA V1 verifier: PR.\nDA mempool specific functionality for cert to vid conversion: network payload and mempool item in DA mempool now can differ if payload can be converted into the mempool item, PR.\nDA Indexer (WIP): implementation of metadata indexer had to be postponed as it depended on the certificate, vid and metadata definitions added in mempool split PR and da-protocol-v1 branch.\n\nCoordination Layer §\nResearch §\n\nStudied on the proof aggregation methods and also on the Jolt protocol (previously reviewed) for the survey. Added the updates (WIP - the aim is to complete it by the end of this week). A brief explanation about Jolt: It is designed to reduce prover costs by using lookup arguments. The reason for reviewing it is that its implementation was released in the past weeks. This version uses the Hyrax polynomial commitment, which results in higher verifier complexity (which is not ideal for Nomos). However, they mentioned that future versions would support different commitment schemes. Our priority is minimizing verifier costs, but if Jolt can offer good results for both prover and verifier, it might be worth considering. Release post of Jolt on X.\n\nDevelopment §\n\nSplit generic mempool into CL and DA mempools - this was needed as making it completely generic would have been impossible at some point. They are now free to deviate in both typing and behavior without affecting the other. The refactor was done so they can share as many available resources as possible: PR.\n\nTestnet §\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nWIP: Nomos Roadmap and Milestone Execution Plan.\nWealth Concentration in PoS, part 1 - published and posted on X.\nIntroduction to Nomos Architecture - in final stages, will be shared by Wednesday or Thursday.\n"},"nomos/updates/2024-04-29":{"title":"2024-01-29 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nPlanning the Mixnet v2 PoC simulation (WIP): To simulate the behavior of the new design, we need to cover some design options (such as the way of broadcasting, etc.). We’ll create a simulator with these options to find the optimal design.\nResearched the existing Mixnet simulators: They provide Python simulators focusing only on global passive adversaries (GPA) by measuring the Shannon entropy as a metric for anonymity (the uncertainty of linking an output message with a certain input message). We can adopt this practice for GPA analysis. For active adversary analysis, we need to figure out how to simulate tagging attacks and n-1 attacks (if necessary). For tagging attacks, we can probably perform an indirect analysis by measuring how many nodes a block is disseminated in before it’s selected/proposed.\nSummarized the requirements for the Mixing gadget.\nOptimization of mixnets: For a scenario when n nodes, sampled from N nodes with at most M adversarial nodes, we designed an algorithm. Given the number of nodes per layer n_1, the fraction of compromised paths which can be tolerated αm​ax, and the probability that the fraction of compromised paths is greater than 𝛼𝑚𝑎𝑥αm​ax, δ, the algorithm outputs the number of layers L: Summary. The algorithm is implemented in Python, but the code needs further refinement.\nAnalysis of anonymity and communication failures in the mix gadget: Assuming that k nodes are sampled from N nodes, where at most M nodes are adversarial, we derived the probability that all k nodes are adversarial and the probability that at least one node is adversarial. The latter is the probability of communication failure, and the former is the probability of anonymity failure. The probability of anonymity failure decreases with k, and the probability of communication failure increases with k. We derived upper bounds on these probabilities. For large N, the probability of anonymity failure is bounded above by 2(𝑀/𝑁)𝑘/𝜋2(M/N)k/π​, and the probability of communication failure is bounded by 1−𝜋(1−𝑀/𝑁)𝑘/21−π​(1−M/N)k/2. Note that M in the latter corresponds not only to adversarial but also to “slow” nodes or nodes with bad connections. The summary of this work is in progress.\nWork on analysis of the new mix gadget design is currently in progress.\n\nDevelopment §\n\nNo development updates.\n\nData Availability §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nInitial DA protocol benchmarking uncovered 2 performance issues that will be addressed as soon as possible: WIP.\nAdd Cert verification to DA mempool: - Merged payload to item conversion in mempool PR. Added certificate verification in da mempool PR merged.\nDA Indexer service definition: Service that is responsible for DA API functionality, is able to track new blocks and assign metadata to previously attested chunks PR. Note that the service is defined, but other services like storage are not yet integrated. These missing pieces will be the focus of upcoming weeks.\n\nPPoS/Consensus §\nResearch §\n\nWealth concentration document is in the process of reorganization with new studies being according to 8 parameters (see table 1 in the doc - we’re able to use way more realistic numbers as well, because software evolved), 3 classes of stakers (lower, mid, higher - we still lack a precise definition of them); and 3 fork-choice rules (lowest, highest, stochastic).\nThe first study assumes the relative stake is known and compares the 3 classes of stakers when the protocol enforces each of the 3 fork-choice rules under different parametrizations (sensitivity analysis).\nThe second study relaxes the assumption that the relative stake is known. We use and evaluate the impact of David and Alexander’s algorithm.\nThe third study relaxes the assumption that the protocol enforces the fork-choice rule. Each staker is allowed to use the rule of its choice.\nInvestigated the current state of the orphan proofs problem. After internal discussions, it was understood that this is a low priority for now, and we need to evaluate the real impact of this problem and how often it can happen first.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nCompleted the Proof Systems Survey: added updates on aggregation, folding schemes, and some protocols. Also, listed and grouped libraries with existing implementations. This week, there will be more detailed explanations about these libraries.\nCelestia ZK-Research Group messages have been summarized in a document with annotations and discussions around parts that might be important to us.\n\nDevelopment §\n\nNo development updates.\n\nTestnet + Insights §\nResearch §\n\nExtended the metrics and visualizations document by adding a planning block to match with yearly planning and resources.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nLatest discussions triggered the need for yearly planning modifications: Wrote a document explaining year expectations + resources planning.\nCreated an initial Vac QA collaboration document with cross-team interactions plan.\nMilestone Execution plan has been published.\nLogos - Nomos update added - this will be an introductory one with focus on progress of research and engineering in the future.\nNew Nomos blog to be published this week with another to be set to review.\n"},"nomos/updates/2024-05-06":{"title":"2024-05-06 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nTo specify adversary models, we analyzed and summarized two papers: 2013 P. Syverson & 2023 C. Diaz.\nBased on the above research, we defined the adversary model in the Mixnet v2: Proof of Concept, focusing on adversaries with partial visibility. Still, specific attack models must be defined so that we can simulate them. Currently, we are attempting things in reverse: imagining attacks that partially or completely break the protections that our design aims to provide. It’s still a work in progress in the same Notion page. Once this is complete, we can start implementing a simulation.\nBased on the previous week’s observations, we wrote a document containing a discussion on how to make the tagging attack less effective.\nAnalysis of anonymity and communication failures in the mix gadget (summary): Assuming that n nodes sample (with replacement) k nodes from the population with N nodes, where at most M nodes are adversarial, the fraction of k-subsets where all k nodes are adversarial, i.e., “anonymity failure” has occurred, is \\left(\\frac{M}{N}\\right)^k on average. The fraction of k-subsets where at least one node is adversarial, i.e., “communication failure” has occurred, is 1 - \\left(1 - \\frac{M}{N}\\right)^k on average. However, if n < N is finite, then deviation from these averages will be observed. For the fraction of k-subsets with anonymity failure, we derived an upper bound on the probability that the fraction of these k-subsets is greater than the average \\left(\\frac{M}{N}\\right)^k by the factor of 1+γ. The upper bound is decreasing with increasing n and γ. A similar upper bound is derived for the fraction of k-subsets with communication failure. Work on the analysis of these bounds and verification by simulation is currently in progress.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nDA Indexer implementation PR: Implemented AddIndex and GetRange functionality in Indexer service. When a list of VidCertificates is observed in a new Block, AddIndex is used to assign Metadata from VidCertificate to a blob that was attested. - When the user requests Range of Indexes for a given AppId, indexer collects available blobs for indexes and returns them in a list.\nDA Indexer + Mempool + Cryptarchia integration test: DA functionality relies on multiple services working together; a test to see if currently implemented parts are working was created.\nSome ideas and improvements were registered (low priority): Verified Certificate state and Investigate BlobDB storage.\n\nPPoS/Consensus §\nResearch §\n\nWealth concentration update: changes related to the introduction of the study structure, rearrangement based on new sections, and expanded explanations.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nDesigned a bridge withdrawal implementation. In designing, we found some bugs in CL, namely, anoma’s “single logic per resource” design is too limiting; it wasn’t possible to see how to implement a simple withdrawal in that design. The fix that was made was borrowed from Zexe, replacing the single note constraint with two types of constraints: birth and death constraints. There is a single birth constraint and arbitrarily many death constraints. Birth constraints govern how a note from a particular application can be produced. Death constraints are provided by the user and configure how a note can be spent; only one of the death constraints needs to be satisfied in order to spend a note.\nCreated the withdrawal CL test case.\nUpdated the Proof Systems survey according to comments. Explanations have been added to some of the sections. Additionally, existing zkp libraries have been reviewed to identify which proof methods are used.\nCoordination Layer Studies: a separate [section](A separate section for FRI has been added) for FRI has been added.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-05-13":{"title":"2024-05-13 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nClarified the adversary model further (WIP); we’ll develop it more by simulation. Attacks to be simulated are listed here, and are based on the adversary model in the same document. The related studies were referred to, including Waku’s documentation about adversarial models (provided by the Waku team).\nAnalysis of anonymity and communication failures in the mix gadget: Assuming that n nodes sample (with replacement) k nodes from the population with N nodes, where at most M nodes are adversarial, the average number of k-paths with anonymity and communication failures are, respectively, given by n \\left( \\frac{M}{N} \\right)^k and n \\left(1 - \\left(1 - \\frac{M}{N}\\right)^k\\right). Calculated an upper bound on the probability that the number of k-paths with these failures are greater than their respective averages by the factor 1+𝛾1+γ, where 𝛾>0γ>0. compared the above bounds with simulations showing that they are tight. Analysis of different cases of 𝑀/𝑁={½,⅓,¼,1/10}M/N={½,⅓,¼,1/10} suggests that, for reliability purposes, some combinations of n and k could be more advantageous than others. The summary of this work is provided here.\nStarted the investigation of the problem regarding mixing over a broadcasting channel, which is an interesting form of mixing in a sparse network. Using a broadcasting channel makes it impossible for an observer to learn who the recipient of the message is (assuming proper message relaying strategy). Making nodes indistinguishable requires a single cover traffic message per time slot, which is a step closer to ideal privacy. However, this has a great network overhead cost, which limits the scalability of the network significantly assuming a fixed bandwidth requirement per node. Also, made an observation about the impossibility of stake hiding, which is based on the fact that the network behavior of a node is reflected on the ledger and any disturbance of the node behavior must also be seen on the ledger. Document for reference.\n\nDevelopment §\n\nImplemented the simulation of “basic” mixnet behaviors (Modified Sphinx, Cover traffic, Broadcasting). They’re very naive but should be enough for running basic adversary simulations. The simulator is being implemented in the mixnet-v2-sim branch in the nomos-specs repository. Basic usage and development progress can be found in the README, though it’s still heavily WIP. Sphinx size: If the payload size is 330 bytes (32 bytes block hash + 288 bytes validator proof) and an incentive tx is 512 bytes (which may not be enough), and if the number of mix layers is 3, a Sphinx packet is 1937 bytes (subject to change).\n\nData Availability §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nDid benchmarks on DA, lib performance was way below expected and targets. Debugged issues, what was found is that the most problematic is proof generation. Discussed options for improvements: Parallelization (which is not really possible as is internally parallelized already) and amortized proof generation method. Ruse evaluation + Benchmarks can be found here.\n\nPPoS/Consensus §\nResearch §\n\nWealth concentration update: changes related to the introduction of the study structure, rearrangement based on new sections, and expanded/improved explanations.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nStudy on DA fast proof generation: research was conducted on fast proof generation in the DA domain. The Feist-Khovratovich technique was examined, and libraries implementing this method were investigated. The general structure of the method and the approach it attempts to implement are explained here.\nWrote a potential design for Mailboxes & Sovereign Transactions.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-05-20":{"title":"2024-05-20 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nSecurity of mixing over a broadcasting channel (document): We have been able to generalize the stake hiding impossibility observation, discuss a general countermeasure, and add a section on how to practically weaken this impossibility. We have extended the Global View section with more discussion regarding the overhead of broadcasting communication. A practical note regarding mixing failure and a sketch for a mechanism to recover from mixnet failure redundancy have been added. We have also started working on a partial view analysis.\n\nDevelopment §\n\nMixnet v2 Simulation: added adversary simulation. Currently, it includes only a passive adversary with a global view. More realistic adversaries will be added later (low priority for now). The current version of Mixnet v2 simulation can be found here. Please note that this document is WIP and not an experiment report, though it includes some plots. It shows what the simulation can do right now and what’s next. In progress: writing the first simulation result document to be shared internally so that we can plan ahead.\nWe internally agreed to start by simulating the simple behavior first and measuring the bandwidth usage, especially by broadcasting real messages without mixing. After that, we can turn on more complex behaviors (e.g., mixing & cover) and compare the results with the previous ones. This is because the simulation result with the whole set of behaviors may be too complex to analyze at the beginning when not everyone fully understands how the simulation works.\nWe found that the simulation speed is too slow with 100K nodes (not physical ones). The main reason is that the simulation is based on SimPy, which is single-threaded. However, the same poor performance was observed when another simulation framework in Python (Mesa) was tried. There may be some solutions (e.g., multiprocessing), but first, our aim is to produce the first meaningful simulation result with fewer nodes before improving it.\n\nData Availability §\nResearch §\n\nWe reviewed the FK20 algorithm again. Libraries for accelerating DA proof generation were reviewed. It appears there is some room for improvement, but it is not yet at the desired levels. Libraries: Rust-kzg, C-kzg, and Peerdas-kzg.\n\nDevelopment §\n\nDA Verifier service implementation: PR merged: the service for attesting the blobs.\nDA Verifier integration tests: Verifier service expects the DA protocol to implement a couple of traits for serialization, encoding, signing, etc. KZGRS backend is mostly implemented, but still needs some service-related utilities. This work is in the verifier-integration-tests branch.\nKZGRS performance review: as per the previous benchmarks on our KZGRS, we uncovered a few performance flaws. Those were addressed, but even then it did not reach our current targets. We have been checking and comparing with other implementations to see if we were doing anything wrong. We were not.\n\nPPoS/Consensus §\nResearch §\n\nExpanded/improved explanations of the results found in the Wealth Concentration in PoS document.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nStudies on binary field proof systems have been completed and documented. This week, we will also cover and take notes on Stwo (STARK prover) and check which parts we can use for the CL. These structures provide fast prover time. We need to discuss how much we need this on the CL side (because while providing fast prover time, it also increases proof size, which seems more important for us).\nThe Atomic Asset Transfer case has been started, but the text and diagrams lacked rigor. An implementation of the CL executable spec has begun, which can better sanity check the design. Details on Noir ZK language integration with Python: here.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nUpdated and improved the “Monitoring, instrumentation, and explorer” document - added a “milestones” section with the targets for the next iterations.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNew blog post has been released: Preventing Wealth Concentration in PoS Systems: The Role of Stake Relativisation.\n"},"nomos/updates/2024-05-27":{"title":"2024-05-27 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nSecurity of Mixing over Broadcasting Channel document has been updated with new details. We mapped the first few cases that we want to analyze through simulations; the Partial View section was added to the document. Analysis of partial view is much more complex than the Global View case, and the Global View does not seem to leak significant information. Thus, the observer in Partial View will need to play a probability game to learn something. However, there are routing attacks that can increase the field of view of the observer, so we should not neglect this case. We have also started working on the analysis of an alternative to broadcasting dissemination—peer to peer.\nAnalysis of random structures generated by the mix gadget, such as properties of hypergraphs, etc. was performed and summary can be found here.\n\nDevelopment §\n\nP2P Privacy Simulation: all simulation reports can be found in P2P Privacy: Simulation Results.\nPosted a report: P2P Privacy: Bandwidth Usage Patterns. Bandwidth was measured for both 1-to-all broadcasting and gossiping, with various parameters (mix layers & cover traffic) changed, so that we can gain insight into how bandwidth increases as parameters change. The document also shows how the simulation works. In short, we now have a framework to measure the performance of the protocol. The next simulation is evaluating anonymity with changing cover traffic patterns to find the optimal cover traffic strategy that guarantees a reasonable level of anonymity in the protocol.\nOne more (WIP) report can be found in (WIP) P2P Privacy: Anonymity. We are currently using the number of messages staying in each node over time as a metric to evaluate the level of anonymity. Although it may not be the best metric, it’s probably the most intuitive one for now.\n\nData Availability §\nResearch §\n\nThe details of the Semi-AVID protocol have been studied, the relevant implementation has been reviewed, and the document prepared.\nThe benchmark document for the results of NomosDA and Semi-AVID has been prepared. Values for Semi-AVID have been calculated and added to the table. We also computed the values for NomosDA. Based on feedback received, the table will be updated and recreated in regard to the latest values.\n\nDevelopment §\n\nKZGRS certificate implementation (PR merged), including: Certificate implementation required for verifier and indexer services, adding of DST tag to Nomos spec and the implementation (Nomos spec PR merged) and VID and Metadata for KZGRS DA protocol.\nAdded DA Verifier service improvements (PR merged).\n\nPPoS/Consensus §\nResearch §\n\nExpanded/improved explanations of the results in the “Does Crypsinous Leader Election Function Lead to Wealth Concentration in PoS” document. Also provided a single Jupyter notebook to replicate all computations.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nCL use case implementation in Python: made some progress towards a 1 input, 1 output test case for CL. PR #93, but it’s not yet working. Certain CL design bugs were found during implementation, which led to changing some parts of the specification.\nMinor crisis on prover key sizes preventing thin clients from generating a transaction. But the general opinion is that what we settled on should work for us (lazy prover key derivation).\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nNomos node insights document has been updated with new details.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-06-03":{"title":"2024-06-03 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nContinued with the analysis of random structures generated by the mix gadget and outlined two possible approaches to the analysis of mix gadget.\nExplained how the timing attack by a passive adversary can be simulated: Tracing back message flows. In short, we can simulate an adversary who traces back message flows to identify original message senders (i.e. block proposers) and repeats this multiple times to find senders selected more often. This is not the perfect way, but our opinion is that we can enhance this to simulate more powerful adversaries.\n\nDevelopment §\nData Availability §\nResearch §\n\nDA benchmarks: we are running benchmarks to compare vs SemiAvid - including: updating and running benchmarks according to needed and requested data and creating a calculator for nomos-da benchmark results. The results can be seen here and the DA calculator script can be seen here.\nTo continue on the point above, we have updated the main document and created separate sub-tables for NomosDA, Semi-AVID, and fk20. Benchmark results were entered into the tables for ANBC, RB, and CT, and general tables were created. Diagrams for the relevant tables were added to the document. Upon rechecking the results, it was observed that the values were consistent within themselves.\n\nDevelopment §\n\nNo updates this week\n\nPPoS/Consensus §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nPoC for CL specification: got the 1-to-1 transfer test running (and passing).\nThe python crypto library we’ve been using so far has been buggy and slow (as in > 1minute startup time and slow ecc math). Tests are very slow to run. Trying to swap it out for some other ecc library, issue is that a lot of the more obscure curves are not well supported in python.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nUpdate current testnet with missing configs for cryptarchia PR merged: After the introduction of Cryptarchia, Nomos testnet was missing some consensus configuration. Also, exposed required configuration as environment variable. We improved docker build times by defining common base image for Nomos node as well. Also included several minor fixes that were required to deploy on testnet.nomos.tech.\nAfter the review and report on the testnet state, refined the plan for this iteration.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-06-10":{"title":"2024-06-10 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nMixnet v2 Simulation: invested time to improve/simplify the passive adversary attacks before running simulations with various parameter sets. Also running the passive adversary simulation with various parameter sets to find the optimal parameters/designs (the result is not posted in Notion yet).\nIntroduced an attack that monitors nodes which emit messages at promised timing (i.e., block interval). The description can be found here. This attack is expected to be disrupted by adding cover traffic. The confirmation of this will come once we run the attack with different cover traffic parameters.\nOptimized the timing attack (tracing back message paths) and quantified its result, as posted here. The confirmation of this will come once we run this simulation with different parameters (number of layers and delays).\nFor the analysis of the mix gadget, we have followed the “conventional” mix model research path: considering the most general scenario when n nodes sample k paths from the set of all nodes in the network [N]. We assumed that each node samples ( r ) of such ( k ) paths. We have shown that a node in a ( k )-path is also participating in other ( r - 1 + c_i ) ( k )-paths. Here ( c_i ) is a random variable from the binomial distribution with parameters ( rn ) and ( \\frac{k}{N} ). For ( k \\ll N ) and ( N ) large, ( c_i ) is a random variable from the Poisson distribution with parameter ( \\frac{k r n}{N} ). On average, a node is participating in ( \\frac{k r n}{N} + r ) ( k )-paths. We calculated an upper bound on the probability that node connectivity deviates from this average by the amount of ϵ\\epsilonϵ. The summary can be found here.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nFinished the benchmark document and all results are documented here. We will continue with NomosDA.\nWe were having an issue with the roots of unity that didn’t allow us to use FFTs. After an org-internal talk, we solved the issue, and now it is working (the problem was that we were using the wrong generator that worked for everything except the FFTs).\nStarted implementing FFT in specs as it is highly needed for FK20.\n\nDevelopment §\n\nNo updates this week.\n\nPPoS/Consensus §\nResearch §\n\nImproved the results in the wealth concentration document.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nStarted to review the Plonky3 details (the notes can be found here). Generally, we can say it’s an improved version of Plonky2 in terms of prover time - meaning we can use it in situations where we need more efficient prover time. Initially, it was more appropriate to use Plonky2 because Plonky3 was still in development, but considering that Risc0 and Succinct have also started using it, we can consider using the Plonky3 protocol as well. In any case, it has advantages over Plonky2.\nOn the other hand, we haven’t found any disadvantages in Plonky3. We thought proof size might be an issue, but they mentioned that they could reduce the proof size using recursion. In this case, it seems logical to use it for inner proof, but the details need to be examined. Perhaps conducting a similar benchmark study for inner and outer proofs as we did for DA would be beneficial.\nAfter discussing the CL Architecture, the most recent design making use of message buffers is now described here: CL Architecture.\nAfter making the decision to rewrite the CL spec in Rust due to the lack of crypto libraries in Python, we decided to halt the spec work in favor of the CL architecture design work that was more pressing.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nFinished base insights structure document (after discussion) - for the time being though, since it’s probably going to be a living document.\n\nDevelopment §\n\n(WIP) Tested our GELF tracing subscriber and connected it to Graylog in the testnet: subscriber is implemented and sends logs to the provided Graylog endpoint. However, the Graylog instance is spawned in the testnet, but manual steps need to be taken during every redeployment, which is not acceptable.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-06-17":{"title":"2024-06-17 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nMixnet v2 Simulation: ran the passive adversary simulation and posted the result here. We can see that the accuracy of timing attack (by passive adversary) significantly decreases as the number of mix layers and cover traffic increase. Next, we need to analyze this result along with bandwidth usages to find the optimal parameters of cover traffic and mix layers.\nAnalysis of the mix gadget: For the analysis of random graphs, generated by random sampling of k-paths in the mix gadget, wrote an interpretation of the result of this analysis. Based on this, looked at a more optimal approach for anonymous communication family of random graphs - notes.\nUpdated the sparse network section of the Security of Mixing over Broadcasting Channel document, as well as the models and finished the global view section. In the document, we have discussed what can be observed without cover traffic in our scenario, the cover traffic design, and how the cover traffic impacts on the observer capabilities to link the traffic.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nStudied on the Henosis design and wrote notes on it. It’s a study related to combining heterogeneous proofs in proof aggregation - this may be used as an inspiration in Nomos. The [code](https://github.com/availproject/Henosis/tree/main ”https://github.com/availproject/Henosis/tree/main) is available on GitHub.\nFK20 running specification in python: added tests to double check that generated proofs are the same.\nFK20 implementation in python: implemented FFT methods and added FFT parallelization version.\n\nDevelopment §\n\nDA HTTP API and integration to the node is still in progress.\n\nPPoS/Consensus §\nResearch §\n\nImproved the results in the wealth concentration document.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nWe’ve restarted the CL executable specification in rust (PR). The following parts have been specified: notes, nullifiers, ptx input, ptx output, partial tx. Still remaining to be specified: tx bundle of ptx’s, birth/death constraints, integration with SP1 snarks.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nFinished the tracing subscriber and connected it to Graylog in the testnet: - PR merged.\nImplemented minor changes to the CI for the updated rust version: PR.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-07-01":{"title":"2024-07-01 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nStarted writing the new mixnet executable specs. Completed: Global transmission rate, Peering degree limit, Noise per connection, Gossip-based Sphinx routing. Still to do: Time mixing.\nWIP: Updating mixnet simulation according to the new specs. The plan is to finish the first working version by the end of this week. It’s taking more time than expected because of the attempt to have reusability between specs and simulation. Now the plan is clear.\nGathered the outcome of our discussions and design decisions from the offsite and compiled a document that outlines the design of our mixnet gadget. WIP: work on the queuing mechanism for the mixnet gadget, taking into account what corrupted nodes can learn.\nWith the assumption that the “Are continuous stop-and-go mixnets provably secure?” paper is state of the art, studied it in great depth to find out how anonymity guarantees are usually derived. For our case, the most useful definition from the aforementioned work is user unlinkability. However, it uses two senders and one receiver, but in our case, we have only one sender, i.e., the leader node, and one receiver node. The latter requires a new definition of sender unlinkability. The summary can be found here.\nAssuming that anonymity guarantees and statistical independence of nodes are related, considered an approach that studies various “correlation functions,” such as mutual information, Hamming distance, etc. This work will be carried on in this document.\nWIP: analysis of correlation functions.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nWIP: First iteration of the PoC can be found here. That PR already runs a libp2p inside a very basic DA node. It is important to mention that the very limited py-libp2p is not great software. The last official release is from 2020, and it had to be cloned from GitHub to make it work at all. Then, there was an issue with its internals: it’s highly opinionated. Tried to reuse existing py code from mixnet by using asyncio but py-libp2p would refuse to work with it due to the lib’s internal setup with trio. It is also important to mention that this is an exploration of the libraries; the team is yet to decide whether libp2p will be used at all.\n\nDevelopment §\n\nFinishing FK20 Rust implementation.\nIncluded FK20 in DA encoder (PR).\nAdded Rayon parallelization to DA encoder (PR).\nImplemented cache for Toeplitz part-1 and integrated it into the encoder (PR).\nAdded benchmarks and missing parallelization features (PR).\nDA subnetwork assignment algorithm: Implemented re-hashing algorithm and initial experiments. Tried to implement and improve a few variations of the algorithm, but none of them were better than the original. Ran a few experiments (results and ideas will be shared later on).\nWrapped up DA HTTP endpoints for KZGRS backend PR. Pushed changes related to DA HTTP endpoints. They are generic and should be reused with the updated KZGRS protocol and dispersal as a black box.\n\nPPoS/Consensus §\nResearch §\n\nWIP: produce and analyze more simulation results using the relativization algorithm, as stated in the wealth concentration document.\nThe protocols suggested by Ethereum for the proof of validator protocol have been reviewed. As stated in the article, the use of a Merkle tree could be slow for proof generation. Therefore, a zk-SNARK solution using a lookup table is considered to be more efficient. The related protocols are summarized step-by-step here. Additionally, the SemaCaulk design will also be examined. There is already Rust code available here, but it has not yet been audited. The related protocol will be examined in more detail and feedback will be provided.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nIntegrated the Proof of Equivalence document and validated the design. It seems that we now have a protocol that meets the requirements.\nThe StarkNet DA structure was reviewed again for Proof of Equivalence.\nWIP: continuing with the PoC, understanding whether Risc0 is a viable option (progress).\nIntegration of Risc0 zone PoC into CL note and partial tx model: we have the zone POC hooked into the CL UTXO model, but proof times are not where we want them. We are currently at 8 minutes to generate a proof, almost all of that is coming from the Pedersen commitment to the note value. All the work is being done in this PR.\nWIP: Trying to bring the death constraint proof time down to something manageable.\nEvaluation of SP1’s viability for CL: SP1’s outer proof takes 13 minutes to prove. The numbers were confirmed with SP1 devs. This is too slow for us to use. SP1 devs suggested they may support swapping out plonky3 for groth16; If they do that, we should re-evaluate.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nTestnet updates from the testnet branch now (deployments happen from the testnet branch) - Nomos PR, Infra PR. This is done to have more control over what runs in the testnet.\nEnabling/Disabling tracing using feature flags or config at runtime - PR. Added the ability to build the node without tracing, or toggle tracing via config if built with this feature.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-07-08":{"title":"2024-07-08 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nThe new mixnet executable spec is being updated in the PR #98 but has not been merged yet. The new spec will be reviewed for changes that need to be updated in the executable spec.\nUpdated mixnet simulation is in the branch of nomos-specs, a PR hasn’t been opened yet because additional team discussion is needed to check whether it meets our analysis requirements. A document has been prepared to explain what the simulation can do and how its result can be used. Based on this, we will discuss what needs to be done as the next experiment.\nUpdated mixnet gadget document with queuing designs: added a section about queuing mechanisms. There are two flavors, one is time bounded and another is time unbounded. Time unbounded is better from the privacy perspective as an adversary will not know any upper time limit during which a message is going to be propagated. Also presented two versions of the unbounded with discussion about the design properties and their impact on privacy.\nStarted working on the level 1 noise generation mechanism, it is sketched in the NomMix design already but requires more refinement. In short, the idea is to introduce another type of noise (cover traffic) that will be limited to some threshold (to protect the network from spam) and its generation will be incentivized to encourage nodes to send it.\nDiscussed how to proceed with simulations and analysis of the mixnet. One of the outcomes is a design of a new model that can be used to describe the network which is connection oriented (rather than node oriented) - more details in the point below.\nTo model communication in the network, considered two approaches: the “node-centred” and “connection-centred” . The former assumes that only the state of a node (such as sending, receiving, etc.) is observed and the latter assumes that also connection is observed. Also, considered Hamming distance as a measure of distance between systems with LEVEL 0 and LEVEL 0 + LEVEL 2 noises, i.e. the difference between a system which “communicates” and “doesn’t communicate”. This work is summarised in this document.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nWIP: (DA python PoC) Executor large number of persistent connections to remote host test - During the offsite, there were some concerns raised that the executor might not be able to keep a large number of open connections to remote hosts. A test using a python DA Node and Executor was performed, having the executor connecting to multiple instances of DA Nodes on a remote machine. Results need to be formally documented, but simple tests of pushing data over thousands of persistent TCP connections to a remote host succeeded on commodity hardware.\nWIP: (DA python PoC) PoC of Executor dispersal and sampling protocol for direct connections - A simple executor node is in progress - initially it was used for the connections feasibility test, now it’s developed further to work with the DA Node used in the subnet PoC.\nCreated the Runnable DA PoC Specification.\nUpdated the GitHub repo with current code (Status: Simple python DA nodes and simple python DA Executor implemented; executor can send packets) - WIP PR.\nTweaked the DA encoder benchmark to cross-check data & column sizes.\n\nDevelopment §\n\nNo updates this week.\n\nPPoS/Consensus §\nResearch §\n\nWIP: fixing a bug that was found in the wealth concentration code and producing and analyzing all simulation results again, based on the fix.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nCL PoC plan has been added to Notion.\nDid a few more prover optimizations in this PR.\nSummary of all the CL specs has been created.\nThe Caulk paper is being studied. The protocol is understood in general terms. The SemaCaulk definitions have been reviewed. A general description and protocol steps have been added for the related protocol here. Since KZG is used instead of a Merkle tree, proof calculations are faster. Creating a proof of set membership involves precomputation and quick proof generation. Precomputation can be done early and updated efficiently, while proof generation is fast and constant-time.\nResearch has been done on which other zkVMs could be tested for the CL. Also talked to external contributors to get a second opinion on the topic. Written the initial notes (not very detailed) about the related protocols here.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nPrepared Nomos Explorer architecture document.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-07-15":{"title":"2024-07-15 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nPR #98: Updated/refined the mixnet executable spec according to the newly written (WIP) spec. It’s being reviewed at the moment and is soon to be merged.\nPR #104: Modified the Sphinx encoding to support an arbitrary length of mix route and arbitrary maximum size of payload. Now we can let nodes select the length of mix nodes (not to exceed the max limit) and encapsulate a message larger than 1K (hardcoded in Loopix Sphinx) into a single Sphinx packet, while ensuring that all Sphinx packets have the same size.\nPR #105: Updated the simulation according to the newly written (WIP) spec. Also made it accept different randomness seeds for each module to make each of them deterministic independently. This is the first working version, which we can extend over and over.\nWorked on the level 1 messaging noise generation section, focused mostly on the motivational part at the moment. It’s noteworthy that the effectiveness of the mechanism is tightly coupled with the application of the queuing mechanism. Currently working on a better way of presenting the whole motivation. However, this does not block defining the noise generation mechanism, which is the next thing to do.\nLooked at ways to model the queuing mechanism (temporal mix). Our current approach is to treat it as a timed pool mix, which is well studied and provides us with analytical tools that we can use. However, later on, it was realized that it might not be the best model to use as we are deviating from a general mix to a task-specific mix which we might not be able to reflect using the timed pool mix. Nevertheless, it still looks like a good starting point that we can modify for our particular needs.\nReviewed mixnet gadget specification, and consequently decided on how to move forward with simulations and further implementation.\nStarted an analysis of the queuing system: in particular, considered the random process (outlined in this document) which governs the out-queue of a single connection. The latter is a variant of the pool mix and we have set up an analytical framework, based on previous studies such as the paper “Towards an Information Theoretic Metric for Anonymity,” which will allow us to study statistical properties of out-queues. The summary can be found in this document.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nPR #672: Added the verifier benchmarks. The data from benchmarks can be seen in this Notion document.\nWIP: Started the libp2p nomos DA subnetworks implementation document.\nPR #100, direct DA connection protocol: Defined the executor to DA node direct connection message types using protobuf. The code is targeting the da-poc branch in Nomos Spec to be used with subnets PoC.\nPR #99: Finalized the first version of the Runnable DA nodes PoC (ready for review).\n\nDevelopment §\n\nNo updates this week.\n\nPPoS/Consensus §\nResearch §\n\nAdded the Proof of Leadership specification to Notion. The first implementation in Circom, the one with sha256 (that didn’t take review into account) can’t be executed right now due to hardware requirements—however, this will be solved with the machine the team can now use. The implementation with the Anemoi hash function (that takes reviews into account => Taylor of order 2, more note inputs etc.) is not released yet.\nWIP: Finalizing studies 1 and 2 of the wealth concentration work. Results and report about wealth concentration can be found here but still not in a readable format.\nWIP: Continued implementing the Python code to analyze the selfish behavior when choosing the fork rule. This is created by adapting the Cryptarchia spec from the nomos-spec repository.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nHad a deep dive into Preconfirmations and Based Sequencing and created this document based on it.\nPR #102: Implemented the nullifier proof (as part of the implementation of the user side of the cross zone atomic transfer PoC).\nPR #103: Set up the infrastructure for using risc0 for CL proofs and integrating the nullifier proof from PR #102 with the CL. The nullifier proof takes about 5 seconds on a local MacBook (without Groth16 wrapping).\nWIP: Started a design of a trustless bridge for user-zone funds.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nPR #673: Added a base debug span, consensus, and da-verifier span for tracing logs.\nInvestigated minor CI issues and made a temporal fix for Nomos Node to build with libp2p and rustls (discussion in the relevant PR #673). For now, the rustls version is pinned, will be reverted after this issue is resolved.\n\nUser Tools §\nResearch §\n\nStarted the nomos-lib document (main document to abstract what we need for different binaries external to the nomos-node).\nStarted the nomos-cli document (first approach to interact with the nomos network).\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nListed future research projects, as Key Differentiators of Nomos vs other projects, document.\nUpdated the nomos-pm repository issues for the insights dashboard.\n"},"nomos/updates/2024-07-22":{"title":"2024-07-22 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nAll new mixnet-related PRs in the nomos-specs have been closed. New PRs will be opened once we’re ready to write the technical specs.\nSimulations are now being added in the nomos-simulations repository.\nPR #6: The initial mixnet simulation is ready to be reviewed. This PR has some missing pieces that will be added in the next PRs (to make the PR smaller and easily check if the simulation works correctly).\nPR #7: Now using gossiping for broadcasting after mix.\nPR #9: Added dissemination time measurement.\nUpdated the Noisy lottery section and worked out the details of the level 1 messaging noise generation mechanism, with a collection of algorithms that gradually build up the complexity.\nAs a result of the process of reducing complexity and clarifying the objectives of what we want to analyze and simulate, written a dictated subsection for simulation and analytics for the queuing mechanism.\nAnalysis of the queuing system in the Nomos Mixnet node: considered a queue of messages where a message is removed with probability q from the queue, i.e. the “coin-flipping”. The number of attempts to remove a message from the queue follows a Geometric distribution with parameter q. The latter was verified by simulation of random sampling. Based on this, it follows that a message is delayed in a node by at least RΔ, where Δ is some constant related to the implementation of the queue, with probability (1-q)^R. The summary can be seen here.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nPR #100: Direct DA connection protocol - added session control message type, simplified Dispersal and Sample error messages. This has been merged into the da-poc branch, it’s now in the nomos-poc repo.\nPR #5: DA feasibility test for a large number of UDP connections - investigated how a large number of connections would affect different network topologies.\nPR #6 (moved from nomos-specs): Finalized and merged the PoC PR. Based on this, the documentation has been updated accordingly.\n\nDevelopment §\n\nNo updates this week.\n\nPPoS/Consensus §\nResearch §\n\nThe first version of the Proof of Validator has been prepared in this document.\nWIP: Finalizing studies 1 and 2 of the wealth concentration work (wasn’t able to do it last week because the simulations took way longer than expected). Results and report about wealth concentration are here but still not in a readable format.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nFinalized the Proof of Leadership specification with error analysis.\nPR #3 added - for Proof of Leadership circuits (in circom).\nPR #106: Defined and implemented the input proof. The input proof verifies the statement that the ptx input has a valid nullifier, the balance commitment was computed correctly, and reveals a death commitment that was used to spend the note.\nPR #4: Balance commitments had a design bug that had broken input/output unlinkability, now resolved.\nPR #7: Transfer PoC. This introduced 2 more types of CL proofs: Output and Bundle proofs. Also built up the proof infra around this to allow constructing a fully proved transfer transaction that could be placed on chain.\nPR #2: Defined and implemented the first version of zone funds death constraints.\nExpanded the Preconfirmations and Based Sequencing document with new research.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-07-29":{"title":"2024-07-29 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nRan the initial simulation to compare queuing mechanisms, but found that it’s better to design a specifically targeted simulation (which focuses only on queuing mechanisms) instead of using the full-cycle simulation (which simulates the full features of the protocol).\nWe prepared the simulation strategy, and simplified the simulator according to the strategy (maximizing code reuse). The simulation results can be found in the Queuing Mechanism: Message Dissemination Time Experiments, though this report is not the final version. The result consists of the largest set of data (It took 48h+). More analysis needs to be done on the result data to make a decision on the queuing mechanism and recommended parameters. So far, we found that the Noisy Coin Flipping Queue shows the optimal dissemination time compared to other queuing mechanisms, but we don’t want to jump to conclusions. Other aspects besides dissemination time need to be tested.\nIn the process of enabling better progress with simulations and analytical work, wrote a methodology document that will guide our efforts in understanding the queueing mechanism’s impact on the network and its general properties.\nAnalysis of the queueing system in the Nomos Mixnet node: considered a message going through k nodes where the queuing system of each node delays the message. Assuming that a message is removed with probability q from the queue, the probability distribution of the total delay is the negative binomial. From this follows that the average total delay is \\frac{k}{q}​. Calculated the upper bound on the probability that the total delay is greater than the average \\frac{k}{q} by the factor 1 + \\epsilon. The upper bound suggests that the mentioned probability is a monotonic decreasing function of k, q, and \\epsilon. The aforementioned work is summarized in Notion.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nDraft version of DA technical specification added.\n\nDevelopment §\n\nPR #678 DA Protobufs: DA Prost integration merged - generates rust structures for protofiles as a build step.\nPR #681 DA Protobufs: DA Network message types merged - Dispersal, Replication, and Sampling protocols defined as protofiles and exposed as a module in nomos-da/network/messages.\nPR #679 CI Improvements - DA Indexer integration tests improvement merged - Integration test now better determines when to expect a specific blob_id in a block received via the network. This test will be used with the new DA dispersal protocol.\nResearching attacks on DAS; understanding better the interactions between DAS and consensus, MEV, and the properties of our current design - summary.\nPR #680 - started implementing DA network stack: sketched up crates, created basic structure for 3 subprotocols (dispersal, replication, sampling), implemented Replication subprotocol (non-working, we have a bug). Also added base contract for the DA networking layer on the nomos node. That way we can start integrating it into the DA services.\nPR #683 - added DA network adapter trait in mempool (first step in adapting the mempool to continuously sample and verify).\n\nPPoS/Consensus §\nResearch §\n\nPR #10 - 1st Proof of Validator PR in Circom with Merkle tree.\nExtended the Proof of Validator specification.\nContinuation on reporting on studies 1 and 2 of the wealth concentration work (also redoing certain figures and improving the way results are compared) - results and report are getting in shape.\nPR #9 - Proof of Leadership spec implementation in risc0.\nWorked on the Caulk library to understand the details of the Caulk Rust implementation. There was an error when the prover was run multiple times during the proof verification process. This error was fixed. Additionally, benchmarked the proof and verification performances for different elliptic curves. The results are added to the spec document.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nThe circuit design and details used in the Zcash spec were reviewed. Sprout and Sapling circuits are older designs. The Orchard circuit is the most current version, and its cryptographic structure is already the design we are using as a reference. Relevant notes were added to this document.\nPR #8 - Nomos native zone deposit tx.\nWIP: Nomos native zones bridge deposit.\nPR #11 - added death constraints to the transfer scenario; in this scenario, we don’t do any interesting account abstraction so the death constraints are proofs of no-ops. With this change, CL is “feature complete” for the purposes of the PoC.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nPR #682 CI Improvements - Protoc build deps for testnet and Jenkins CI merged.\nPR #684 Rust 1.80 (opened, not merged yet) - added an allow[dead_code] for Nonce in consensus for Clippy. Unused methods in da libp2p will be handled in separate PRs.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-08-05":{"title":"2024-08-05 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nNomos Mix simulations: message dissemination time by queue type - Session 1: Measured message dissemination time using 20~80 number of nodes, for each 5 queue types. Noisy Coin-flipping queue shows the lowest dissemination time when there are less number of real messages flown in the network, but shows the worst, if not. Random Sampling queue or Permuted Coin-flipping queue show around 2x longer dissemination time compared to the Non-mixing queue, but the performance degradation is relatively low, as the number of real messages increase. This is the initial interpretation of the result, which we can’t make a conclusion based on.\nNomos Mix simulations: message dissemination time by queue type - WIP: Session 2: This experiment is still running. This runs more nodes (100~10000) than the session 1, to see how each queue performs in the larger network. Also preparing next experiments: measuring how long messages stay in the queue.\nExtended the methodology document with more parameters for message dissemination experiments. Found one paper that measures properties of the Monero network which also include the node connectivity levels, an extract of it can be found here.\nDesigned another type of experiment, that is devoted to observing the quality of “temporal mixing” for a single node on a single path. The results of which will give us better understanding of the predictability of delaying of each of the queues and guide our decision during the selecting process.\nThe results for the first session of simulations give some intuition about the impact of each of the parameters on the dissemination time. However, it’s too early to conclude as the quality of mixing is another part of the equation and it’s our main focus now.\nStarted looking at the payment mechanism for the mixnet.\nAnalysis of the queueing system in the Nomos Mixnet node: considered the FIFO (First In First Out) attack where two sender nodes send messages through k mix nodes to the receiver node. The latter is controlled by an adversary which is also capable of observing other nodes. For a mix node where a message is removed from its out-queue with probability q, derived an expression for the probability of success of the FIFO attack. This probability can be computed numerically by creating a large population of random variables (wrote a code for the latter). Using this framework, showed that the probability of success of the FIFO attack is a monotonic decreasing function of the number of mix nodes k and is bounded from below by ½. Also showed that having different q parameters for sender and mix nodes can reduce the probability of success of the FIFO attack. Finally, showed that heterogeneous latencies of connections can increase the probability of success of the FIFO attack.\n\nDevelopment §\n\nPrepared the engineering PoC in Notion.\n\nData Availability §\nResearch §\n\nDA technical specification has been updated.\n\nDevelopment §\n\nPR #686: DA BlobInfo instead of Certificate - Removed Certificate and Attestation definitions, introduced DispersedBlobInfo trait and implementations. Also updated the DA mempool, integration tests and other components to use BlobInfo.\n(WIP) DA Mock network service for CLI app: still in progress preparing various components for the updated CLI App.\nPR #685 - finished implementing/fixing the DA network replication layer.\n(WIP) Started implementing the DA network dissemination layer - finished the validator behaviour and started the executor behaviour.\n\nPPoS/Consensus §\nResearch §\n\nFinalized the Proof of Validator specifications.\nPR #10 - 2nd Proof of Validator in Circom with Caulk.\nThe implementation for the Caulk usage scenario was prepared, and the results were added to the document.\nStarted analyzing the usage of the PoL as a PoV.\nFinalizing reports 1 and 2 of the wealth concentration work: the results are mostly in shape.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nPR #17: integrate the zone withdrawal logic with CL ptx/note structure.\nPR #13: users could create as many zero-valued outputs as they’d like without affecting the balance of a partial tx, the implications of this was not clear so we decided to ban zero-valued outputs for now until we understand what is going on.\nPR #14: boilerplate for the user atomic transfer ptx.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-08-12":{"title":"2024-08-12 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nImproved the simulation to avoid out-of-memory (OOM) issues—an unexpected bug. If we run heavy simulations with 90+ processes on the server, the total usage of system memory is very high, and OOM occurs after 10+ hours. We modified the handling of intermediate results to minimize memory usage.\nMeasuring the Message Dissemination Time by Queue Type (Session 2.1) - because the session 2.1 simulations are too slow, we are profiling the internal behaviour of the simulation to find if something is wrong. So far, everything looks fine. The amount of computations looks correct. But, there are still more things that we need to check at the moment.\nWorking on reducing the time complexity of the experiments from the parameters perspective and prepared reduced parameters for session 2, called 2.1. Afterwards, designed Session 3, and Session 4 for evaluating the behavior of a node with non-homogeneous peering degree. Finally, defined experiment 5 which should deprecate all previous experiments as it simulates most closely the behavior of the network. Relevant document.\nDesigned a responsive version (two flavors) of the queuing mechanism, that alters the probability of releasing the message from the queue when the same message is received from another queue by the node. This is a more elegant solution which should deprecate all others if performing well (delay and statistically wise). Relevant document.\nStarted drafting some high-level requirements for the pay-per-mix design. Heavy work in progress - relevant document.\nAnalysis of the queuing system in the Nomos Mixnet node: continued with the analysis of the FIFO (First In First Out) attack where two sender nodes, observed by an adversary, send messages through kkk mix nodes to the receiver node, corrupted by the adversary. Considered a scenario when a message is delayed by the sender node by 1qS\\frac{1}{q_S}qS​1​ (on average) and by the mix node by 1qM\\frac{1}{q_M}qM​1​ (on average). Here qSq_SqS​ and qMq_MqM​ are, respectively, probabilities of removing a message from the out-queue of sender and mix nodes. Computed the probability of success of the FIFO attack for different ratios ρ=qSqM\\rho = \\frac{q_S}{q_M}ρ=qM​qS​​. The probability of success of the FIFO attack approaches the lower bound 12\\frac{1}{2}21​, where the adversary doesn’t have any advantage over random guessing, with an increasing number of mix nodes kkk much faster for higher values of ρ\\rhoρ. However, even for higher values of ρ\\rhoρ the probability of success of the FIFO attack is increasing if the difference in latencies of connections, of two sender nodes to the first mix node, is greater than some threshold. This work is summarized in this document.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nUpdated the DA Technical Specification.\n\nDevelopment §\n\nPR #688 - Finished implementing/fixing the DA network dispersal layer: implemented executor behavior, implemented validator behavior and implemented interaction test for both behaviors.\n(WIP) PR #689 - Finished implementing/fixing the DA network sampling layer.\n(WIP) PR #690 - DA Mock network service for CLI app: all parts (services, adapters, etc.) are defined and interconnected, finishing up mock implementations. Progress is a bit slower than initially anticipated with the CLI App.\n\nPPoS/Consensus §\nResearch §\n\nConcluded that Caulk is not that interesting for improving proof of membership.\nFinalized the section about “Follow the Protocol” on the wealth concentration work.\nDropped the analysis of the PoV based on PoL analysis.\nPoV spec: The main motivation for implementing Caulk was its fast update process. We examined how many operations are required for Merkle-tree updates at specific depths and compared this with point addition and multiplication on the Caulk side. For Caulk, if the updates are to be made, this value is added linearly to the process, whereas this isn’t necessary for Merkle-tree. It was observed that at 2122^{12}212 notes, the values are almost equal, and even at 2202^{20}220 notes, the difference isn’t significant. For this reason, we agreed that itisn’t necessary to spend too much time on Caulk. Additionally, for Caulk, the proof of Pedersen equivalence would also disadvantage us in terms of proof size and constraints. The spec work for PoV has been completed. This is the latest version using a Merkle tree.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nPR #15 - Added strong zone notes validation by zone ID.\nPR #16 - Added metadata to zone notes to allow for correct funds/state note validation.\nPR #19 - Refactored zone auth.\nPR #20 and PR #22 - Added support for atomic transactions.\nCreated a table for notable zkVMs in the literature, currently filling in the details by reviewing the designs.\nAdded the necessary details and definitions for ZCash in the relevant document.\nPR #21 - Integrated the zone deposit scenario.\nPR #23 - User side of the atomic transfer transaction.\nPR #24 - Full atomic transfer transaction.\nWith the previous three PRs (in combination with previous work), we’ve got the full atomic transfer transaction working end-to-end! We still need to do some performance work to ensure executors can build a transaction within the 20s target block time (current proof time is ~400s).\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/Athens-Offsite-Notes":{"title":"Athens Offsite Notes","links":[],"tags":["nomos-updates","athens-all-hands"],"content":"Research §\nThe Nomos team has attended several meetings with different teams and internally. Most of these have been in terms of finding the right solutions for the Coordination layer, including but not limited to:\n\nProof aggregation techniques\nZK commitment schemes\nCL Inter-zone communication\nBridges\n\nBased on these discussions, we have compiled a preliminary version of the Coordination Layer Specification. There are still unknowns in this line of work, but we are of a unified mind that we are on the right track.\nEngineering §\nAt Nomos, there are some needs that could be covered by Vac. To be more precise: understanding on what Vac provides that could be helpful, understanding what is required for Vac to start on that support, a plan/pipeline for both teams to interact. Some of the proposals:\nDST:\n\nAt the moment, the most prominent project is the analysis of the Nomos mixnet.\nThis will serve as the first project interaction as it is also the highest priority.\nOngoing conversations on what is needed are already in place.\n\nQA:\n\nNomos node is in high need of a testing plan. But no real bandwidth for it.\nVac has specialized people with the experience and the workforce.\nCryptarchia and NomosDA would be the focus. But this is gonna be delayed until seen how the mixnet collaboration goes.\nAs part of this specifications will be reviewed by the Vac team so they can be improved. Eventually specifications will be forked and served as part of Vac too.\n\nComms §\n`Key Market Trends / Research §\nPrivacy Concerns:\n\nBuilding our case for privacy our protection and viability of the project. We need to define the terms of privacy and create that shield. Privacy is necessary for personal items to be possible, health, business, institutions. \n\nTechnical Narratives:\n\nLitenodes. Rules without a ruler\nData Availability Sampling\nRestaking\n\nDecentralisation \n\nWe can be more decentralised than any other blockchain ever. \n\n`Technical Milestones §\nProduct Development\n\n1st Milestone: Dark paper release, with a potential litepaper version.\n2nd Milestone: Testnet\n\n`Growth Plan  §\nTarget Audience: \n\nDegens: Refine for those who care and believers.\nInstitutions: Long term\nDevelopers/Contributors\nNode Operators: Long term.\n\nMovement Building (Community) - Educational Initiatives: \n\nRoles for incentivising culture, memes.\nAmbassador program\nDeveloper Outreach\n\nIncentive Programs \n\nLogos NFTs\nWhen we have zones we can get them to deploy during hackathons?\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/consulting/codex/proxy-re-encryption":{"title":"proxy-re-encryption","links":[],"tags":[],"content":"vac:acz:consulting:codex:proxy-re-encryption §\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 Proxy Re-Encryption: , 2024-05-27, 2024-09-30\n\n\nstatus: 50%\nCC: Ramses + 1\n\nDescription §\nTo embed and assist codex with their proxy re-encryption primitive.\nJustification §\nProxy re-encryption is necessary to provide plausible deniability to storage providers.\nDeliverables §\n\n A Document describing possible solutions: https://www.notion.so/Approaches-to-plausible-deniability-87c6fef92df946fcbc1327d51d936ce1?pvs=4\n Agreement and hardening of specification for the Codex team\n"},"vac/acz/consulting/nescience/zk-consulting":{"title":"Nescience ZK Consulting","links":[],"tags":[],"content":"vac:acz:consulting:nes:zk-consulting §\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 Nescience ZK Consulting: , 2024-01-01, 2024-12-31\n\n\nstatus: 30%\nCC: Ugur\n\nDescription §\nTo assist the Nescience team with their ZK needs.\nJustification §\nUgur has the expertise to assist Nescience with their zk research tracks.\nDeliverables §"},"vac/acz/consulting/nomos/init":{"title":"init","links":[],"tags":[],"content":"init cryptography consulting for nomos"},"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/waku/rlnv2-e2e","vac/acz/rlnp2p/vac/rln-doc-and-outreach","vac/acz/rlnp2p/vac/light-rln-verifiers","vac/acz/rlnp2p/vac/rln-light-clients","vac/acz/rlnp2p/status/rln-usage","vac/acz/zerokit/vac/zerokit-v0-4","vac/acz/zerokit/vac/zerokit-v0-5","vac/acz/zerokit/vac/maintenance","vac/acz/secure-channels/waku/mls-design","vac/acz/secure-channels/waku/mls-poc","vac/acz/secure-channels/waku/fd-design","vac/acz/secure-channels/waku/fd-poc","vac/acz/consulting/codex/proxy-re-encryption","vac/acz/consulting/nomos/init","vac/acz/consulting/nescience/zk-consulting","vac/acz/stealth-address-kit/maintenance","vac/acz/stealth-address-kit/research","vac/acz/validator-privacy/nimbus/productionize-tor-push"],"tags":["acz","vac"],"content":"vac:acz: §\n\nrlnp2p:waku: §\n\n production-readiness\n rln-membership-management\n rln-relay-enhancements\n rln-relay-enhancements_02\nrln-relay-erc20\n\n\n rlnv2-relay-integration\n\n\n rln-multi-epoch-constraints\n rlnv2-e2e\n\nrlnp2p:vac: §\n\n rln-doc-and-outreach\n light-rln-verifiers\n rln-light-clients\n\nrlnp2p:status: §\n\n rln-usage\n\nzerokit:vac: §\n\n zerokit-v0.4\n zerokit-v0.5\nmaintenance\n\nsecure-channels:waku: §\n\n mls-design\n mls-poc\n fd-design\n fd-poc\n\nconsulting:codex: §\n\n proxy-re-encryption\n\nconsulting:nomos: §\n\ninit\n\nconsulting:nes: §\n\n zk-consulting\n\nstealth-address-kit:vac: §\n\n maintenance\n research\n\nvalidator-privacy:nimbus: §\n\n productionize-tor-push\n"},"vac/acz/rlnp2p/status/rln-usage":{"title":"Status RLN Usage","links":[],"tags":[],"content":"vac:acz:rlnp2p:status:rln-usage §\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 Usage: , 2024-05-13, 2024-06-13\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\nTo describe an end-to-end user flow for a new user of the status app on how they can acquire an RLN membership.\nJustification §\nStatus will use RLN in the future, and we must first consult them on how to use it for seamless integration.\nDeliverables §\n\n Document describing end-to-end user flow\n"},"vac/acz/rlnp2p/vac/light-rln-verifiers":{"title":"Light RLN Verifiers","links":[],"tags":[],"content":"vac:acz:rlnp2p:vac:light-rln-verifiers §\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 Light RLN Verifiers: done, 2024-03-01, 2024-05-01\n\n\nstatus: 100%\nCC: Aaryamann\n\nDescription §\nMake use of cryptography techniques to improve trust assumptions and reduce off-chain complexity while verifying RLN proofs.\nJustification §\nA node attempting to verify RLN proofs takes nearly ~10 minutes to sync all the leaves. We should explore cost-effective solutions to make the root of the tree accessible onchain.\nDeliverables §\n\n PoC using tiered commitment trees: https://github.com/vacp2p/rln-contract/pull/37\n Deployed to sepolia and load tested: https://sepolia.etherscan.io/address/0xE7987c70B54Ff32f0D5CBbAA8c8Fc1cAf632b9A5\n Ethresearch post: https://ethresear.ch/t/tiered-commitment-trees-to-reduce-gas-costs-and-offchain-complexity/19484\n Vac forum post: https://forum.vac.dev/t/light-rln-verifiers-using-a-tiered-commitment-tree/290\n Vac blog post: https://vac.dev/rlog/rln-light-verifiers/\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-08-01, 2024-12-31\n\n\nstatus: 100%\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 §\n\n talk at progcrypto on RLN: https://www.youtube.com/watch?v=7xDxv8F70Jg&pp=ygUOcHJvZ2NyeXB0byBybG4%3D\n presented rln: zero to hero to nwaku+chatsdk team @ status all hands, explained all versions of rln and their trade-offs\n\n\n blog post/RFC on Light RLN verifiers: https://github.com/vacp2p/vac.dev/pull/136\n updated docs for rln-relay in nwaku-compose: https://github.com/waku-org/nwaku-compose/pull/52\n Present rln-v2 and v3 at logos research call: https://docs.google.com/presentation/d/1lcE5E3WKenueIULR_rhjtZU8Tdqv-7sPr6lpXPTaQSk/edit?usp=sharing\n RLN rlog on vac.dev: https://vac.dev/rlog/rln-anonymous-dos-prevention\n"},"vac/acz/rlnp2p/vac/rln-light-clients":{"title":"RLN Light Clients","links":[],"tags":[],"content":"vac:acz:rlnp2p:vac:rln-light-clients §\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 Light Clients: done, 2024-04-01, 2024-05-01\n\n\nstatus: 100%\nCC: Aaryamann\n\nDescription §\nMake use of zk-kit’s LazyIMTto have the merkle proof of a leaf accessible onchain, and the root as well, to allow for light rln provers and verifiers.\nJustification §\nA node attempting to verify RLN proofs takes nearly ~10 minutes to sync all the leaves. We should attempt to see if it is cheap enough to use the LazyIMT structure so that we can have the merkle proof accessible onchain.\nDeliverables §\n\n PoC (rln-v1): https://github.com/vacp2p/rln-contract/pull/31\n Deployed to cardona zkevm testnet: https://cardona-zkevm.polygonscan.com/address/0x16abffcab50e8d1ff5c22b118be5c56f801dce54\n PoC (rln-v2): https://github.com/vacp2p/rln-contract/pull/39\n Downstreamed to waku-rln-contract to estimate gas: https://github.com/vacp2p/rln-contract/pull/38\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nRLN VersionGas estimate for insertionrln-v190krln-v1 (lazyIMT)130krln-v2135krln-v2 (lazyIMT)210k"},"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 Status\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 Status\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: 90%\nCC:\n\nRamses\nAaryamann\n\n\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 §\nDynamic epoch sizes are required for users who have smaller messaging needs, to optimize for stake used.\nrln-v3 will allow that.\nDeliverables §\n\n design document: https://www.notion.so/rln-v3-PoC-b05af585f52f4b15a249184d4a627096\n PoC: https://github.com/vacp2p/gnark-rln/blob/9b05eddc89901a06d8f41b093ce8ce12fd0bb4e0/rln/rln.go\n blog post/ethresearch crosspost\n"},"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 Status\n\t\tRLN-RELAY enhancements :done, 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_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\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tRLN-RELAY enhancements 02:done, 2023-09-01, 2023-11-30\n\t\t\n\n\nstatus: 100%\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-e2e":{"title":"RLN v2 E2E integration","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:rlnv2-e2e §\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\tRLN v2 e2e Integration : , 2024-05-20, 2024-06-20\n\n\ndue: 2024-06-20\nstatus: 90%\n\nDescription §\n\n Come up with final gas estimation after the optimizations (RLN v2 + RLN in resource-restricted)\n Deliver end-to-end PoC working in The Waku Network showcasing the new features.\n Bug fixes found along testing\n New smart contract with both RLNv2 and RLN in resource-restricted clients changes.\n Deploy and consider using a L2 testnet.\n Deprecate tree sync in nwaku\n\nGoal §\nRun RLN relay v2 on TWN.\nDeliverables §\n\n https://github.com/waku-org/pm/issues/168\n https://github.com/waku-org/nwaku/issues/2758\n"},"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:done, 2023-11-01, 2024-02-29\n\n\nstatus: 100%\nCC: Aaryamann\n\nDescription §\n\nalso involves\n\nTKE\nimplemenations in various Waku versions\n\n\n\nJustification §\nrln-v2 brings multi message per epoch signaling which is favourable for all users of rln instead of abiding by one global rate limit.\nDeliverables §\n\n https://github.com/waku-org/nwaku/issues/2345\n"},"vac/acz/secure-channels/waku/fd-design":{"title":"Secure Channels - fully decentralized design","links":["vac/acz/secure-channels/waku/mls-design"],"tags":[],"content":"vac:acz:secure-channels:waku:fd-design §\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 FD Design: 2023-04-29, 2024-12-15\n\n\nstatus: 5%\nCC: Ramses, Ugur\n\nDescription §\n\nfollow up of mls-design\n\nWhile MLS, an established protocol, allows us to quicker release a secure key setup protocol with an Ethereum authenticator,\nMLS is federated in nature and makes reliability assumptions in regards to the underlying message dissemination layer.\nWe work towards mitigating this using on-chain components in the planned deliverables for the milestone linked above.\nHowever, we still desire a fully decentralized version that ideally does not require an on-chain component.\nThis Milestone tracks this effort.\nJustification §\nDeliverables §\n\nspecification (RFC)\n"},"vac/acz/secure-channels/waku/fd-poc":{"title":"Secure Channels - PoC of fully decentralized protocol","links":["vac/acz/secure-channels/waku/fd-design"],"tags":[],"content":"vac:acz:secure-channels:waku:fd-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 FD PoC: 2024-12-01, 2025-06-30\n\n\nstatus: 0%\nCC:\n\nDescription §\n\nPoC implementation of fd-design\n\nJustification §\nDeliverables §"},"vac/acz/secure-channels/waku/mls-design":{"title":"Secure Channels - MLS design","links":[],"tags":[],"content":"vac:acz:secure-channels:waku:mls-design §\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: done, 2023-09-12, 2024-05-31\n\n\nstatus: 100%\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\n https://github.com/vacp2p/rfc-index/blob/main/vac/raw/eth-secpm.md (specification)\n"},"vac/acz/secure-channels/waku/mls-poc":{"title":"Secure Channels - MLS PoC","links":["vac/acz/secure-channels/waku/mls-design"],"tags":[],"content":"vac:acz:secure-channels:waku:mls-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 MLS PoC: done, 2024-04-29, 2024-07-15\n\n\nstatus: 100%\nCC:\n\nEkaterina\nAaryamann\n\n\n\nDescription §\n\nproof of concept implementation of mls-design\nrepo: https://github.com/vacp2p/de-mls\nissues:\n\nhttps://github.com/vacp2p/de-mls/issues/1\nhttps://github.com/vacp2p/de-mls/issues/2\nhttps://github.com/vacp2p/de-mls/issues/3\n\n\n\nJustification §\nDeliverables §\n\nEngineers implementing the researchers advice on how to proceed with the PoC\n\n https://github.com/vacp2p/de-mls/issues/1\n https://github.com/vacp2p/de-mls/issues/2\n https://github.com/vacp2p/de-mls/issues/3\n https://github.com/vacp2p/de-mls/issues/4\n https://github.com/vacp2p/de-mls/issues/5\n https://github.com/vacp2p/de-mls/issues/6\n\n\n"},"vac/acz/stealth-address-kit/maintenance":{"title":"Stealth Address Kit Maintenance","links":[],"tags":[],"content":"vac:acz:stealth-address-kit: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 Stealth Address Kit Maintenance: , 2024-02-01, 2024-12-31\n\n\nstatus: 80%\nCC: Aaryamann\n\nDescription §\nContinue supporting and maintaining the stealth-address-kit repo.\nJustification §\nThis will be a viable privacy solution for status (private transfers) and waku (rln membership insertion)\nDeliverables §\n\n rename erc-5564-rs to stealth-address-kit\nThe following releases have been made -\n\n https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.3.1\n https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.2.0\n https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.1.0\n\n\n"},"vac/acz/stealth-address-kit/research":{"title":"Stealth Address Kit Research","links":[],"tags":[],"content":"vac:stealth-address-kit:research §\n\n\nnote: there is no gantt chart for this milestone\n\nDescription §\nFurther the research of the stealth address scheme and collaborate with EF researchers to do so.\nJustification §\nThis will be a viable privacy solution for status (private transfers) and waku (rln membership insertion)\nDeliverables §"},"vac/acz/validator-privacy/nimbus/productionize-tor-push":{"title":"Productionize Tor Push in Nimbus","links":[],"tags":[],"content":"vac:acz:validator-privacy:nimbus:productionize-tor-push §\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 Productionize tor push: , 2024-05-13, 2024-08-13\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\nTo make the tor push feature as accessible as running --tor-push:true while running a nimbus validator.\nJustification §\nImproved privacy guarantees for ethereum validators\nDeliverables §\n\n TBD\n"},"vac/acz/zerokit/vac/maintenance":{"title":"maintenance","links":[],"tags":[],"content":"ongoing: zerokit maintenance"},"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 Status\n\t\tv0.5 Release: done, 2023-10-01, 2024-06-01\n\n\nstatus: 100%\nCCs:\n\nEkaterina\nAaryamann\n\n\n\nDescription §\n\nRelease Planning issue: https://github.com/vacp2p/zerokit/issues/237\n\nDeliverables §\n\n https://github.com/vacp2p/zerokit/pull/239\n https://github.com/vacp2p/zerokit/pull/242\n https://github.com/vacp2p/zerokit/pull/243\n https://github.com/vacp2p/zerokit/pull/245\n https://github.com/vacp2p/zerokit/pull/246\n"},"vac/dr-ice/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-ice/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-ice/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-ice/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-ice/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-ice/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-ice/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-ice/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-ice/index":{"title":"Deep Research Service Unit - Icebox Milestones","links":["vac/dr-ice/valpriv/vac/tor-push-rln","vac/dr-ice/valpriv/vac/priv-validator-network","vac/dr-ice/valpriv/vac/mix-net-solution","vac/dr-ice/valpriv/nomos/validator-privacy","vac/dr-ice/consensus/nomos/carnot-paper_02","vac/dr-ice/consensus/nomos/carnot-bribary-article","vac/dr-ice/consensus/nomos/carnot-2-3rds-vote-aggregation","vac/dr-ice/consensus/nomos/blockchain-security-in-crypto-economic-models","vac/dr-ice/consensus/nomos/detecting-reporting-attacks-carnot","vac/dr-ice/consensus/nomos/stake-privacy-timing-attacks","vac/dr-ice/consensus/nomos/inter-chain-protocol","vac/dr-ice/consensus/nomos/multi-leader-and-multi-overlay-carnot"],"tags":["dr","vac"],"content":"vac:dr:valpriv:vac: §\n\ntor-push-rln\npriv-validator-network\nmix-net-solution\n\nvac:dr:valpriv:nomos: §\n\nvalidator-privacy\n\nvac:dr:consensus:nomos: §\n\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"},"vac/dr-ice/valpriv/nomos/validator-privacy":{"title":"validator-privacy","links":[],"tags":[],"content":""},"vac/dr-ice/valpriv/vac/mix-net-solution":{"title":"mix-net-solution","links":[],"tags":[],"content":""},"vac/dr-ice/valpriv/vac/priv-validator-network":{"title":"priv-validator-network","links":[],"tags":[],"content":""},"vac/dr-ice/valpriv/vac/tor-push-rln":{"title":"tor-push-rln","links":[],"tags":[],"content":""},"vac/dr/anon/vac/gossipsub-anonymity":{"title":"Gossipsub Anonymity Layer","links":[],"tags":[],"content":"vac:dr:anon:vac:gossipsub-anonymity §\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 Anonymity Layer: 2024-04-15, 2024-12-15\n\n\nstatus: 5%\nCC: Akshaya\n\nDescription §\nThis Milestone entails designing an anonymization layer for gossipsub, and by extension, IFT projects.\nThe primary objective of this anonymization layer is to serve as a cohesive anonymization solution for gossip-based projects,\nwith a specific focus on integrating it with the Logos projects Waku and Codex.\nCurrently, we’re uncertain whether the complete anonymization layer can be situated between gossipsub and the protocols of IFT projects.\nIt appears more plausible that we’ll establish a foundational element atop gossipsub,\nwith project-specific components integrated into the projects themselves,\nor introduce an intermediary layer between the general gossip anonymization protocol and the project protocols.\nThe Nomos team is crafting their own anonymization solution due to their unique requirements and their ability to leverage specific traffic patterns to enhance efficiency.\nNonetheless, the overarching objective for our anonymization network is to render our solution modular, enabling the inclusion of traffic pattern plugins that Nomos can define.\nOur initial exploration will revolve around extending our Tor push proposal.\nIn this approach, messages will traverse through an anonymization network before being disseminated via gossip protocols upon exiting the anonymization network.\nAdditionally, we aim to investigate the concept of embedding anonymization capabilities directly into gossipsub,\nrather than routing messages through a separate anonymization network before entering a standard gossipsub network operation.\nCurrently we view this anonymization solution as a P2P base layer, which the Vac P2P team will offer as part of libp2p.\nThis effort could potentially spawn an incubation project.\nThis effort would act as a basis for the Validator Privacy Network incubation project.\nJustification §\nCurrently, IFT projects do not provide enough anonymity guarantees.\nPrivacy protection, which entails anonymity, is part of the logos manifesto.\nDeliverables §\n\nreport comparing various approaches to realizing a gossipsub anonymization layer for IFT projects\n\nthis might entail identifying the need for in-project components (see description)\nhas to provide arguments why the proposed approach is expected to provide sufficient anonymity guarantees\n\n\ndocument describing benefits for each of Waku, Status, Codex, and Nimbus\nPaper on arxiv.com\n\nincluding security/privacy analysis\nshould offer improvements over Tor push.\nspam protection (integrate RLN)\nthe proposed solution MUST be practically applicable, efficient, and relevant (product-market fit)\n\n\ndraft specification of the base functionality (a usable subset of the functionality)\nPoC implementation of the base functionality\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/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/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/zk/codex/storage-proofs-open-problems-review","vac/dr/zk/codex/zk-consulting","vac/dr/g/nomos/reviews","vac/dr/anon/vac/gossipsub-anonymity"],"tags":["dr","vac"],"content":"vac:dr:valpriv:vac: §\n\n tor-push-poc\n tor-push-rel-work\ntor-push-paper\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\n\nvac:dr:zk:codex: §\n\n storage-proofs-open-problems-review\nzk-consulting\n\nvac:dr::nomos: §\n\nreviews\n\nvac:dr:anon:vac: §\n\ngossipsub-anonymity\n"},"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/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: 100%\nCC: Marvin\n\nDescription §\n\nhttps://github.com/codex-storage/zk-research-artifacts/blob/master/storage_proofs/storage_proof_musings.md\n\nJustification §\nDeliverables §\n\n sanity checks of existing documents\n"},"vac/dr/zk/codex/zk-consulting":{"title":"Codex Deep Research ZK consulting","links":[],"tags":[],"content":"vac:dr:zk:codex:zk-consulting §\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 zk-consulting: 2024-04-14, 2024-12-31\n\n\nstatus: 10%\nCC: Marvin\n\nDescription §\nThis Milestone comprises deep research ZK consulting for Codex:\nHere is a high level description of Codex ZK research problems: https://hackmd.io/1IZiFSiYSdyrbaKxKeUevg\n\nsummarizing existing research relevant for us (exactly which papers is kind of dynamically determined), in form of PDF notes and face-to-face explanations. We agreed with Marvin that this is probably the easiest way to get something going\nfinding a suitable set commitment scheme (for tracking which proofs are present / not present in an aggregated proof)\nfiguring out the details of recursion for elliptic-curve-and-pairing based schemes (while this is solved, more clarity on this is required)\n\nRegarding 3): Even if we end up using a non EC scheme for “large data”, KZG (and thus EC pairings) seems to be a much better choice for “small data”,\nso we will probably need this in any case (unless we can efficiently verify KZG proofs in a small field / FRI setting).\nSome of these tasks are explorative. Expected outputs are regular reports.\nA follow-up milestone for the next reporting period is expected.\nJustification §\nDeliverables §\n\nregular reports.\n"},"vac/dst-ice/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-ice/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-ice/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-ice/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-ice/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-ice/dr-support/vac/carnot-executable-spec":{"title":"Carnot 2-3rds Vote Aggregation Python Implementation","links":["vac/dr-ice/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-ice/index":{"title":"Distributed Systems Testing Service Unit - Milestone Icebox","links":["vac/dst-ice/wakurtosis/waku/gossipsub-topology-analysis","vac/dst-ice/wakurtosis/nomos/ci-integration","vac/dst-ice/wakurtosis/vac/rlog","vac/dst-ice/analysis/nomos/nomos-simulation-analysis","vac/dst-ice/analysis-gsub-model/vac/refactoring","vac/dst-ice/analysis-gsub-model/status/control-messages","vac/dst-ice/analysis-shadow/vac/shadow-basic-simulation","vac/dst-ice/analysis-shadow/vac/shadow-gossipsub-analysis","vac/dst-ice/analysis-shadow/waku/shadow-waku-relay-analysis","roadmap/vac/dst-ice/dr-support/vac/carnot-2-3rds-executable-spec"],"tags":["dst","vac"],"content":"vac:dst: §\n\nwakurtosis:waku: §\n\ngossipsub-topology-analysis\n\nwakurtosis:nomos: §\n\n ci-integration\n\nwakurtosis:vac: §\n\nrlog\n\nanalysis:nomos §\n\n simulation-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"},"vac/dst-ice/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: 100%\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-ice/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-ice/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-ice/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/deployment-and-analysis/codex/testnet":{"title":"Testnet","links":[],"tags":[],"content":"vac:dst:deployment-and-analysis:codex:testnet §\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 Testnet: 2024-05-01, 2024-12-31\n\n\nstatus: 15%\nCC: Wings\n\nDescription §\nAssist the Codex team with deploying and running a testnet for the Codex network.\n\nProvide a 256TB Storage Provider deployment, which should later build towards 1PiB\nProvide various support and analysis for how the testnet operates and help improve Codex\n\nJustification §\nDeliverables §\n\nMaterially assist Codex with rolling out testnet\nWorking SP storing real data\n"},"vac/dst/deployment-and-analysis/nomos/mixnet":{"title":"Mixnet","links":["tooling/vac/visualiser-tool"],"tags":[],"content":"vac:dst:deployment-and-analysis:nomos:mixnet §\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 Mixnet: 2024-05-01, 2024-12-31\n\n\nstatus: 10%\nCC: Wings\n\nDescription §\nAssist the Nomos team with deploying and running a mixnet at scale within VacLab.\n\nProvide analysis of the VacLab mixnet\nThrough Visualiser, provide visualisation tools and work with the Nomos team to implement privacy preserving metrics and measurements in Nomos to help understand the mixnet’s performance.\nWork with the Nomos team to deploy the visualisation tools for their own purposes.\n\nJustification §\nDeliverables §\n\nLab version of mixnet fully operational and rolled out\nWorking metrics via Visualiser Tool\n"},"vac/dst/deployment-and-analysis/vac/libp2p-version-testing":{"title":"Ongoing testing of specific monthly libp2p releases","links":[],"tags":[],"content":"vac:dst:deployment-and-analysis:vac:libp2p-version-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 LibP2P: 2024-05-15, 2024-12-31\n\n\nstatus: Ongoing\nCC: Wings\n\nDescription §\nThe Vac P2P team is transitioning nim-libp2p to a monthly release cycle.\nThis process involves selecting a commit hash to designate as the monthly version a week prior to release.\nDST will conduct stability tests on this version.\nThis also comprises analysing results as well as identifying and pinpointing bugs if any arise.\nSpecific issues might require several test runs and thorough analysis.\nOur aim is to increasingly automate this process.\nAdditional testing outside the scope of DST and this milestone comprises:\n\ntesting on a Nimbus test fleet\ntesting on a Waku test fleet\n\nJustification §\nDeliverables §\n\nMonthly report of libp2p testing outcomes\n"},"vac/dst/deployment-and-analysis/waku/10k":{"title":"10k Node Cluster","links":[],"tags":[],"content":"vac:dst:deployment-and-analysis:waku:10k §\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 10k: 2024-05-01, 2024-11-01\n\n\nstatus: 90%\nCC: Wings\n\nDescription §\nRun 10,000 Waku nodes actively passing messages in one network.\nGather bandwidth details, deliverability rate, retrieval times. Measure reliability, improve reliability and document deployment and analysis processes.\nGather QoS details such as latency, dropped packets, etc.\nJustification §\nDeliverables §\nDocumentation of both the deployment process and actual deployments.\nUseful analytics for the Waku team that can be used to improve the Waku software.\nResearch articles such as blog posts about the large scale clusters."},"vac/dst/deployment-and-analysis/waku/midscale":{"title":"Midscale","links":[],"tags":[],"content":"vac:dst:deployment-and-analysis:waku:midscale §\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 Midscale: 2024-05-01, 2024-11-01\n\n\nstatus: 20%\nCC: Wings\n\nDescription §\nRun deployments of between 1000 and 5000 Waku nodes actively passing messages in one network.\nTesting is to be done in this order of priority:\n\nMeasure relay bandwidth\nMeasure reliability of Waku message relaying\nMeasure usage of the DiscV5 protocol in the same scenario as (1).\nTest Store protocol at scale\nTest Waku relay+store reliability with nodes going offline/online\n\n\nIf nodes go online/offline, we should be able to retrieve missing messages from the store. This will also test Waku message relaying in a different way.\n\n\nFilter and lightpush tests\nMeasure (1) and (3) in heterogenous clusters involving different node implementations such as nwaku and go-waku\nMeasure (3) with Waku peer exchange protocol used for discovery by a subset of nodes.\nMeasure (1) with a mix of nodes using Resource-restricted device reliability protocol and peer exchange, meaning a small number of nwaku nodes serve store, light push and filter protocols and a high number of clients consume them. For example, 6-10 service nodes, 200 relay nodes and 1000 light nodes.\nThis should include connection and node churn impact on reliability for both relay and light clients.\n\nJustification §\nDeliverables §\nSimilar deliverables to 10k sim, but with focuses on smaller scale and more frequent deployments."},"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/tooling/vac/deployer-tool","vac/dst/tooling/vac/visualiser-tool","vac/dst/deployment-and-analysis/waku/10k","vac/dst/deployment-and-analysis/waku/midscale","vac/dst/deployment-and-analysis/nomos/mixnet","vac/dst/deployment-and-analysis/codex/testnet","vac/dst/deployment-and-analysis/vac/libp2p-version-testing","vac/dst/wakurtosis/waku/techreport","vac/dst/wakurtosis/waku/techreport_02","vac/dst/wakurtosis/waku/features","vac/dst/wakurtosis/nomos/ci-integration","vac/dst/wakurtosis/vac/retrospective-rlog","vac/dst/wakurtosis/vac/maintenance"],"tags":["dst","vac"],"content":"vac:dst: §\n\ntooling §\n\ndeployer-tool\nvisualiser-tool\n\ndeployment-and-analysis §\n\n10k\nmidscale\nmixnet\ntestnet\nlibp2p-version-testing\n\nwakurtosis:waku: §\n\n techreport\n techreport_02\n wakurtosis:features\n\nwakurtosis:nomos: §\n\n ci-integration\n\nwakurtosis:vac: §\n\nretrospective-rlog\n maintenance\n"},"vac/dst/tooling/vac/deployer-tool":{"title":"Deployer Tool","links":[],"tags":[],"content":"vac:dst:tooling:vac:deployer-tool §\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 Deployer Tool: 2024-05-01, 2024-11-01\n\n\nstatus: 80%\nCC: Alberto\n\nDescription §\nA first version of tool that allows deploying >10k gossipsub / waku relay nodes.\nThe tool should measure bandwidth usage per node and bundle the measurement data for analaysis.\nThe tool should be built in such a way that it can be used for other deployments as well.\nJustification §\nDeliverables §\n\nhttps://github.com/vacp2p/10ksim\n"},"vac/dst/tooling/vac/visualiser-tool":{"title":"Visualiser Tool","links":["vac/dst/tooling/vac/visualiser-tool.png"],"tags":[],"content":"vac:dst:tooling:vac:visualiser-tool §\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 Visualiser Tool: 2024-05-01, 2024-11-01\n\n\nstatus: 10%\nCC: Alberto\n\nDescription §\nA first version of tool that allows for visualising the message flow of a Waku network. It should be adaptable to other network types too (particularly Nomos, Codex)\nThis relies on a Grafana Loki deployment to store and query logs.\nJustification §\nDeliverables §\nA peer to peer network mapper that creates a visualisation something like this:\n\nThe tool should be able to visualise the message flow of a Waku network, by lighting up nodes in a graph as they receive messages, flashing a different colour for each message (or message type)."},"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/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/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/index":{"title":"Vac Roadmap","links":["vac/p2p/","vac/tke/","vac/dst/","vac/qa/","vac/acz/","vac/sc/","vac/nim/","vac/rfc/","vac/dr/","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\nqa: Quality Assurance\nacz: Applied Cryptography and Zero-knowledge\nsc: Smart Contracts\nnim: Nim\nrfc: RFC (Specifications)\n\nDeep Research §\n\ndr: Deep Research\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-architecture-01","vac/nes/state-separation/vac/state-separation-architecture-02","vac/nes/proofsystems/vac/research-existing-proofsystems","vac/nes/proofsystems/vac/benchmarks","vac/nes/zkvm/vac/vm-foundations","vac/nes/zkvm/vac/vm-ecosystem"],"tags":["zkvm","vac"],"content":"vac:nes:state-separation §\n\nstate-separation-architecture-01\nstate-separation-architecture-02\n\nvac:nes:proofsystems §\n\nresearch-existing-proofsystems\nbenchmarks\n\nvac:nes:zkvm §\n\nvm-foundations\nvm-ecosystem\n"},"vac/nes/proofsystems/vac/benchmarks":{"title":"Benchmarks","links":[],"tags":[],"content":"vac:nes: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, 2024-05-31\n\n\nstatus: 70%\nCC: team\n\nDescription §\nSince Nescience’s main goal is to be innovative in privacy technology (by building a virtual machine that prioritizes privacy,\nutilizing mainstream and specialized instruction sets optimized for Zero-Knowledge (ZK) applications),\na key focus is the evaluation of different proof systems especially new ones like the Nova-based proof system against alternatives to identify the best fit for our needs.\nThis milestone is important for advancing privacy-preserving technologies, setting a benchmark for the fair and effective comparison of ZKP systems.\nIt’s important for both our project’s infrastructure and the broader field. The diversity of ZKP system designs necessitates a standardized benchmarking approach to ensure fair comparison,\nrespecting each system’s unique features (which we are aiming to achieve and accomplish)\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\nWork Breakdown §\n\n\nBy conducting deep investigation of ZKP systems, we aim to demystify the complexities of cryptographic benchmarking and highlight our findings’ relevance to privacy technology advancement.\n\n\nBy rewriting circuits and using same techniques as recursive approach and Poseidon hash functions, we ensure that the comparison focuses on inherent system properties rather than external variables.\nThis approach will help normalize one of the key variables across systems, allowing for a more direct and fair comparison of their efficiency, scalability, and other critical metrics.\n\n\nDeliverables §\n\nResearch blog post\nPublic benchmark repo on Github (it includes and overall explanation, full circuits implementation and explanation, instructions to execute benchmarks, and testing results on diffferent machines)\nImplementation of recursive circuitsfor all current proof-systems (unless there is a good reason not to include one)\nscientific paper\n\nImpact: By selecting the most effective proof system, such as potentially Nova-based ones, based on superior performance,\nwe aim to strengthen our project’s foundation and contribute valuable insights to the privacy field and the scientific community.\nThis milestone can be useful to any team within the organization to help choose the correct proof system based on their needs\nand in general it help the scientific community to get useful insights to progress on different projects within the blockchain field."},"vac/nes/proofsystems/vac/research-existing-proofsystems":{"title":"Research Existing Proofsystems","links":[],"tags":[],"content":"vac:nes: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, 2024-12-31\n\n\nstatus: ongoing\nCC: team\n\nDescription §\nThis milestone demonstrates our commitment to a continuous and long-term effort aimed at the comprehensive analysis and study of various proof systems, both established and emerging.\nThe primary objective is to maintain cutting-edge relevance by staying alongside of the latest developments in proof systems, ensuring our projects are at the forefront of privacy technology.\nThis is important for sustaining our competitive edge and fostering innovation within our projects.\nThis milestone is foundational to our strategy, enabling us to swiftly adapt to new technologies and incorporate groundbreaking methods that enhance our privacy objectives.\nWork Breakdown §\nOur approach involves a systematic review of current and nascent proof systems, identifying those with the potential to advance our research and project goals.\nThis includes evaluating their applicability, efficiency, and the privacy enhancements they offer.\nBy doing so, we aim to uncover novel insights and techniques that can be integrated into our work, furthering our mission to deliver robust privacy solutions.\nDeliverables §\n\nBlog posts\nPotential benchmarks\n\nImpact: The ongoing research and analysis conducted under this milestone are expected to yield multiple benefits:\nidentification of promising proof systems that could revolutionize our approach to privacy, generation of innovative ideas for future development,\nand ensuring our projects remain relevant and impactful in the rapidly advancing field of blockchain and privacy technologies.\nThis milestone is valuable both internally and externally. Within our organization, it caters to the diverse needs of various teams that utilize proof systems for distinct purposes.\nSimilarly, it offers the scientific community access to essential insights across different systems without the need to delve into each one individually."},"vac/nes/state-separation/vac/state-separation-architecture-01":{"title":"State Separation Architecture 01","links":[],"tags":[],"content":"vac:nes:state-separation:vac:state-separation-architecture-01 §\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 Architecture 01: 2024-01-02, 2024-12-31\n\n\nstatus: 40%\nCC: Team\n\nDescription §\nThe main goal is to design and refine a sophisticated model of state separation within the Nescience project,\nwhich is aimed at distinctly segregating and managing public and private computational processes, including specialized operations such as shielded and deshielded activities.\nThis model is focused on improving privacy through the use of Zero-Knowledge Proofs (ZKPs) and overcoming obstacles related to the traceability\nand linkability of transactions by employing cutting-edge cryptographic methods and frameworks.\nThe goal is to create a nuanced architecture that adeptly balances public and private computational needs.\nIt will utilize an account-based system for public interactions and a UTXO (Unspent Transaction Output)-based method for private transactions,\neffectively combining the benefits of public state efficiency and transparency with the strong privacy safeguards of private states.\nThis effort aims to tackle critical issues in enhancing privacy, engaging deeply with a zero-knowledge virtual machine (zkVM), and achieving significant advances in privacy assurance.\nThe Nescience project elevates the concept of state separation to a new level, striking an unparalleled balance between privacy and scalability by enabling simultaneous public and private computations.\nUnlike existing initiatives, our model not only integrates these two states but also innovates within the private state to support trusted computing,\nachieving scalability without sacrificing privacy. We aim to redefine privacy-oriented technologies,\nwhich are often criticized for their sluggish performance, by introducing a fast, intuitive, and developer-friendly approach to state separation.\nFurthermore, we envision the public state serving as a vigilant monitoring layer, safeguarding privacy against any potential ZKP vulnerabilities or attacks,\nthereby assuring users of their data security.\nOur project distinguishes itself by offering a well-defined theoretical representation of state separation,\ncomplete with graphical analyses for a clearer comparison with other privacy-preserving solutions, thus addressing the lack of specificity and clarity in existing models.\nInteractions with the virtual machine (VM) are pivotal, involving two critical junctures.\nInitially, on the user (client) side, transactions that may contain multiple executions, including private, shielded, or deshielded types, are generated as ZK proofs.\nThese proofs, representing each execution, are then amalgamated into a single ZK proof for submission to the sequencer (VM).\nThe sequencer’s role is to aggregate transactions from users, verify the proofs, validate nullifiers for conflict detection,\nand then compile all verified proofs within an epoch to formulate a block.\nThis process also entails adjustments to the public state in response to the varied executions (public modifications, shielded, and deshielded executions).\nThe design criteria for the zkVM include the necessity for high recursion capabilities and sufficient efficiency to ensure usability in terms of memory and computational time on the user side.\nThis requirement is critical for compatibility with complex tasks like concealing certain information within zkVM operations,\naccommodating a significant volume of public and private inputs. The efficiency of verification, even in systems like Groth16 that offer theoretically constant-size verification times,\ncan be affected as the quantity of inputs grows, underscoring the need for a VM architecture that remains practical and responsive under varying loads.\nThis nuanced understanding underscores the project’s comprehensive approach to leveraging state separation for enhanced privacy and scalability,\nall while ensuring compatibility with an advanced zkVM framework.\nThe most significant impact of our state separation approach in the Nescience project lies in its innovative privacy features,\nwhich employ an account-based model for the public state and a UTXO-based model for the private state, allowing for individual or group-specific private states.\nThis method stands out by offering four distinct types of executions: public, private, shielded, and deshielded, each with unique characteristics to maintain privacy and scalability.\nPublic executions are transparent and swift, modifying accounts without the need for Zero-Knowledge Proofs (ZKPs).\nIn contrast, private, shielded, and deshielded executions, which involve transferring between public and private states or within private states,\nutilize ZKPs to protect sensitive information like addresses, transaction amounts, and smart contract invocations through kernel circuits.\nThese executions are further enriched by allowing transactions to comprise various execution types,\nensuring that sensitive data is processed on the user side with ZKPs to prevent exposure in the public state.\nFor example, transactions involving private tokens or smart contract interactions remain confidential, with minimal information reflected publicly.\nThis architecture addresses potential risks like linkability and double-spending through the innovative use of nullifiers and accumulators, enhancing privacy without sacrificing security.\nOur approach also introduces Private Directed Acyclic Graphs (PDAGs) as a tool for analyzing and enhancing privacy.\nAs an extension of Transaction Directed Acyclic Graphs (TDAGs), PDAGs are specifically designed to address and measure two critical aspects of privacy:\nunlinkability and untraceability. Unlinkability refers to the property that ensures individual transactions cannot be linked to each other,\nmaking it impossible to trace the flow of assets between transactions from an external observer’s perspective.\nThis feature is crucial for protecting user identities and preventing the exposure of transaction histories.\nUntraceability, on the other hand, ensures that it is infeasible to trace transactions back to their source or destination,\nproviding a further layer of privacy by obscuring the relationship between senders and receivers.\nThis means that, even if an entity were to observe the network, they would not be able to determine the parties involved in any given transaction.\nPDAGs incorporate these principles by structuring transaction records in a way that leverages the benefits of directed acyclic graphs (DAGs),\na type of data structure that allows for efficient data management and retrieval without the limitations of linear or hierarchical arrangements.\nIn the context of blockchain, DAGs enable faster transactions and greater scalability, while PDAGs extend these benefits with a focus on privacy.\nBy calculating unlinkability and untraceability metrics within a PDAG framework, it becomes possible to quantitatively assess the privacy level of a blockchain network.\nThis analytical approach allows for comparisons with other privacy-centric solutions, such as CoinJoin, Tornado Cash, and privacy-focused blockchains like Monero and Zcash.\nThrough PDAGs, developers can identify potential weaknesses in privacy measures and enhance the network’s resistance to analysis and tracking, ensuring a secure and private environment for users.\nBy incorporating decoy inputs in shielded and deshielded transactions, we further obscure the link between public and private states, significantly reducing the risk of privacy breaches.\nIn essence, the Nescience project’s state separation method not only advances privacy and scalability in blockchain technology\nbut also sets new standards in protecting user data through a sophisticated blend of theoretical models and practical implementations.\nThis approach not only addresses current privacy concerns but also lays the groundwork for future investigations into efficient and secure private state exchanges.\nTo provide a structured approach to the development of the advanced State Separation Architecture for the Nescience project,\nfocusing on privacy enhancement, we can break down the milestone into distinct sub-milestones, each with its own specific work breakdown and deliverables.\n\nJustification §\nWork Breakdown and Deliverables §\n\n\n\n Sub Milestone 1 (Q2 2024): Execution Types and Privacy Mechanism Design\n\nWork Breakdown: Define and design the distinct execution types (public, private, shielded, and deshielded) and their respective privacy mechanisms, integrating Zero-Knowledge Proofs (ZKPs) for enhanced privacy.\n\n\n\n Deliverables: Set of comprehensive deliverables, including an Execution Type Design Document that offers an in-depth analysis of the specifications and workflows for public, private, shielded, and deshielded executions in the Nescience state separation architecture -> Execution Types Document.\n\n\n\n\n\n\n Sub Milestone 2 (Q2 2024): Cryptographic Infrastructure and Nullification Strategy\n\nWork Breakdown: Develop the cryptographic infrastructure necessary for the state separation architecture, including nullifiers and accumulators, to prevent double-spending and ensure unlinkability of notes. First step would be identifying and selecting suitable cryptographic primitives for nullifiers and accumulators, then implementing the selected primitives in the architecture.\n\n\n\n Deliverables: A document providing a comprehensive guide on the implementation and integration of nullifiers and accumulators within the state separation model, detailing their specific roles and functions within the overall architecture -> Nullification Strategy Document.\n\n\n\n\n\n\n Sub Milestone 3 (Q3 2024): State Separation Document\n\nIntro: In this milestone, the first part (https://vac.dev/rlog/Nescience-A-zkVM-leveraging-hiding-properties) focuses on conducting detailed exploration of the multifaceted challenges,\npotential solutions, and alternatives that lay ahead building Nescience, a privacy-first blockchain project aiming to enable private transactions and provide a general-purpose execution environment\nfor classical applications. The second part aims to delve deeper into the selected strategic paths for developing a privacy-first blockchain, detailing the methodologies for addressing the identified challenges,\nthe decisions made to enhance privacy, and the expected outcomes.\nWork Breakdown: Document all the research findings, the development steps and the methodologies, explaining the utility and adoption process of each solution to reinforce privacy within the project and the shift in focus towards detailing the chosen paths for the project development, including the rationale behind these decisions and their alignment with privacy enhancements. Finally, Review future directions, potential areas of research, and ongoing development efforts to continue advancing privacy within the Nescience project\nDeliverables: Blog posts and/or scientific papers.\nImpact: By clearly articulating the exploration from identifying challenges to implementing solutions,\nPart Two of the State Separation Document aims to serve as a comprehensive guide and reference for enhancing privacy in blockchain technologies,\nmarking a significant milestone in the Nescience project’s development.\n\n\n\n Sub Milestone 4 (Q3 2024): Enhancing Transaction Privacy with Decoy Inputs\n\nWork Breakdown: Incorporate empty notes as decoy inputs for shielded and deshielded executions to enhance the untraceability and unlinkability of transactions. First we aim to design the mechanism for integrating decoy inputs into transactions to act as noise; then we develop a prototype that demonstrates the effectiveness of decoy inputs in enhancing transaction privacy.\nDeliverables: A prototype showcasing the implementation of decoy inputs, accompanied by evaluation results highlighting their impact on privacy enhancement.\n\n\n\n Sub Milestone 5 (Q4 2024): Nescience devnet deployment\n\nWork Breakdown: Deploy a Nescience Devnet by integrating simplified components into the zkVM and state separation architecture to achieve a fully functional Nescience environment. Add the necessary simplified components to the zkVM and state separation architecture such as P2P communication layer, Consensus layer, and Network layer. Focus on node deployment (Configure and start Nescience nodes on designated machines and ensure nodes operate independently, with a full structure that includes the consensus layer, network layer, etc.). Ideally, the Nescience Devnet should function autonomously, without reliance on external blockchain environments whereas existing components can be utilized ensuring that the system should be able to run on its own.\nDeliverables: A fully operational Nescience Devnet, capable of running nodes independently with integrated P2P communication, consensus, and network layers, all within the zkVM and state separation framework.\n\n\nRisks §\nWe currently have 2 open positions for hiring a 1) Zero Knowledge Research Engineer and a 2) Zero Knowledge Researcher.\nCurrently we are finding some difficulties in finding the best candidates for these positions and therefore we need to consume Vac resources (namely Ugur and Marvin) for a longer time to focus on Nescience projects."},"vac/nes/state-separation/vac/state-separation-architecture-02":{"title":"State Separation Architecture 02","links":[],"tags":[],"content":"vac:nes:state-separation:vac:state-separation-architecture-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 State Separation Architecture 02: 2025-01-02, 2025-12-31\n\n\nstatus: 0%\nCC: Team\n\nDescription §\ncontiunation of vac:nes:state-separation:vac:state-separation-architecture-02\nJustification §\nWork Breakdown and Deliverables §\n\n\nSub Milestone 1 (2025): TDAG & PDAG Integration for Privacy Enhancement\nWork Breakdown: Use Transaction Directed Acyclic Graphs (TDAGS) and Private Directed Acyclic Graphs (PDAGs) for a comparative analysis of the Nescience architecture’s privacy features. The main idea is to implement PDAGs to improve unlinkability and untraceability within the project, enhancing privacy features. This can be done by developing and integrating PDAG structure, oncluding data structures, algorithms and the integration mechanism with the existing system; by conducting thorough testing of the PDAG implementation to identify issues or areas of improvements; and by monitoring its performance and impact on privacy enhancement.\nDeliverables:\n\nReport on PDAG reearch and analysis.\nPDAG integration technical specifications and design documents.\nA functioning PDAG implementation with testing reports.\nDocumentation on PDAG privacy improvements and security analysis.\n\n\n\nSub Milestone 2 (2025): Kernel-based Architecture Implementation\nWork Breakdown: Develop a kernel-based framework for verifying private function executions accurately, using a recursive SNARKs approach to build and validate a call stack. This is to ensure robust proof of execution sacrificing computational resources (raising gas fees due to the intensive nature of generating SNARK proofs and handling recursive computations). We will focus on balancing the precision of recursive verification with its computational costs, aiming for a system that guarantees the integrity of private functions while managing resource use efficiently.\nDeliverables:\n\nA data structure to manage recursive function calls, ensuring efficiency and security.\nA system to securely accumulate and manage proof data for recursive calls, facilitating tamper-resistant proof handling.\nGeneration of intermediary SNARK proofs for each recursive call, with aggregation capabilities for comprehensive stack validation.\nEstablishment of a maximum recursion depth with enforcement mechanisms to prevent computational overflow.\nA fully integrated recursive verification system with extensive testing to ensure functionality, security, and performance under varied conditions.\n\n\n\nSub Milestone 3 (2025): Seamless Interaction Design\nWork Breakdown: Address the challenge of potential information leakage between private and public transactions by ensuring composability between contracts and secure integration of functions. Moreover, we would like to be able to create secure channels for contract composability and interaction layers that prevent private data exposure by implementing strategic safeguards against information leakage.\nDeliverables:\n\nIntermediary smart contracts for secure public-private interactions.\nConfidential sidechains and cross-chain protocols employement.\nFragmentation of data across shards for private interaction.\n\n\n\nSub Milestone 4 (2025 / 2026): zkVM deployment\nWork Breakdown: Our aim is to deploy our work in progress state separation architecture within a privacy-first zero knowledge virtual machine since it places an emphasis on privacy enhancements (which we need for our privacy-first zkVM).\nDeliverables: A functioning privacy-first zkVM that ensures that while private state data remains undisclosed, public state transitions can still be carried out and subsequently verified by third parties.\n\n\nSub Milestone 5 (2025 / 2026): State Separation Doc\nDescription: This open milestone is crucial for ensuring that our development aligns with the evolving needs and expectations of users and organization.\nWe aim not only to address the immediate challenges of developing a privacy-first blockchain but also to lay the groundwork for future innovations in blockchain privacy and security.\nNote: This is an ongoing and long term milestone with possible deliveries within the year 2024. The timing and nature of these deliveries are contingent upon our continuous findings\nand their subsequent impact on privacy for both the organization and the community.\nWork Breakdown:\n\nDocument all the research findings, the development steps and the methodologies.\nExplain the utility and adoption process of each solution to reinforce privacy within the project\nExplain the shift in focus towards detailing the chosen paths for the project development, including the rationale behind these decisions and their alignment with privacy enhancements.\nReview future directions, potential areas of research, and ongoing development efforts to continue advancing privacy within the Nescience project\n\nDeliverables\n\nBlog posts.\nScientific papers.\n\n\n"},"vac/nes/zkvm/vac/vm-ecosystem":{"title":"VM Ecosystem","links":[],"tags":[],"content":"vac:nes:zkvm:vac:vm-ecosystem §\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 VM ecosystem: 2025-01-01, 2025-12-31\n\n\nstatus: 0%\nCC: team\n\nDescription §\nWork Breakdown & Deliverables §\n\n\nSub Milestone 1 (2025): Deployment and Real-World Application Testing\nWork Breakdown: Deploy the privacy-centric zkVM in a controlled environment and test its real-world applicability and performance, focusing on privacy-preserving computations.\nDeliverables: An outline for deploying the zkVM in a test env, including infrastructure and security considerations, along with results of testings focusing on ptivacy preservation.\n\n\nSub Milestone 2 (2025): Community Engagement and Open-Source Contributions\nWork Breakdown: Engage with the cryptographic and privacy communities and teams within the organization to gather feedback, share insights, and contribute to the open-source ecosystem, fostering wider adoption and collaboration.\nDeliverables: Release of the developed cryptographic libraries and zkVM source code to the open-source community, accompanied by comprehensive documentation and guides for implementation and use.\n\n\nImpact: This plan underscores the goal for delivering a zkVM with strong focus on privacy enhancements. By identifying and integrating advanced cryptographic primitives, and considering the deployement within environments like Nexus VM or similar VMs, this milestone aims to make significant contributions to the field of privacy-preserving computation. Sub milestones may slightly change and some of them might be accomplished faster than others especially that during the previous period, we have focused on existing zkVMs and extensively studied the integration of cryptographic primitives to enhance pivacy."},"vac/nes/zkvm/vac/vm-foundations":{"title":"VM Foundations","links":[],"tags":[],"content":"vac:nes:zkvm:vac:vm-foundations §\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 VM Foundations: 2024-03-01, 2024-12-31\n\n\nstatus: 40%\nCC: team\n\nDescription §\nThe focus of this milestone is on the significant adaptation of a Zero-Knowledge Virtual Machine (zkVM) that places an emphasis on privacy enhancements. By modifying existing zkVM frameworks, the goal is to integrate advanced cryptographic primitives to create a highly secure, privacy-preserving computational environment. This includes exploring and implementing cutting-edge research in cryptographic techniques and ensuring these can be efficiently executed within our zkVM framework, with an example pathway through Nexus VM for specific Rust-based cryptographic implementations. The analysis includes RISC Zero, GKR-based VMs, and Layer 2 zkVMs, with a focus on their instruction set architectures, privacy capabilities, proof complexities, and specific innovations or limitations. This milestone will be divided in several sub-milestones in order to understand which paths to take and which path would better fit in order to get tangible output (see Work Breakdown and Deliverables)\n\nWork Breakdown & Deliverables §\n\n\n\n Sub Milestone 1: Privacy Cryptography Research and Selection\n\nWork Breakdown: Conduct exhaustive research into cryptographic primitives that enhance privacy, determining which are most applicable and promising for integration into a zkVM.\nDeliverables:\n\n\n\n A comprehensive review of current cryptographic techniques that enhance privacy, including signature schemes and MPC schemes, focusing on those with potential for zkVM integration -> 1. List of zkVMs and 2. In-depth Review.\n\n\n\n\n Analysis of selected cryptographic primitives for implementation in Rust, considering their compatibility with the zkVM environment, specifically within frameworks like Nexus VM -> List of Primitives and Privacy Requirements.\n\n\n\n\n\n\n Sub Milestone 2: Cryptographic Implementation and Testing (Related to Sub Milestone 1)\n\nWork Breakdown: Implement the selected cryptographic primitives in Rust (From Sub Milestone 1), ensuring they are optimized for privacy enhancement within the zkVM framework.\nDeliverables: Repo documenting the testing processes, performance evaluations, and optimizations applied to the cryptographic implementations to ensure privacy efficiency and scalability within the zkVM.\n\n\n\n Sub Milestone 3: zkVM Adaptation for Privacy\n\nWork Breakdown: Adapt an existing zkVM to integrate the implemented cryptographic primitives, prioritizing privacy preservation. For instance we can think about replacing Merkle trees with Verkle trees within existing VMs, or adding proof compression layer to replace logarithmic proof sizes with constant sized proofs. The possible prototype could potentially incorporate selected features and optimizations from the previous phases. This involves implementing privacy-preserving properties, selecting appropriate instruction sets, and integrating advancements such as Nova-based proof systems.\nDeliverables:\n\nPotential Privacy-Centric zkVM Prototype: A zkVM that integrates the Rust-based cryptographic libraries, showcasing enhanced privacy capabilities.\nDetailed documentation on performance metrics and comparative analysis with existing systems.\n\n\n\nImpact: This plan underscores the goal for delivering a zkVM with strong focus on privacy enhancements. By identifying and integrating advanced cryptographic primitives, and considering the deployement within environments like Nexus VM or similar VMs, this milestone aims to make significant contributions to the field of privacy-preserving computation. Sub milestones may slightly change and some of them might be accomplished faster than others especially that during the previous period, we have focused on existing zkVMs and extensively studied the integration of cryptographic primitives to enhance pivacy."},"vac/nim/core-libs/vac/chronos-maintainance":{"title":"chronos-maintainance","links":[],"tags":[],"content":""},"vac/nim/index":{"title":"Nim Unit","links":["vac/nim/tooling/vac/nim-suggest","vac/nim/tooling/vac/nimble","vac/nim/tooling/vac/compiler","vac/nim/tooling/vac/editor","vac/nim/tooling/vac/lsp","vac/nim/core-libs/vac/chronos-maintainance"],"tags":["nim","vac"],"content":"vac:nim: §\n\ntooling:vac: §\n\n nim-suggest\n nimble\n compiler\n editor\n lsp\n\ncore-libs:vac: §\n\n chronos-maintainance\n"},"vac/nim/tooling/vac/compiler":{"title":"compiler","links":[],"tags":[],"content":""},"vac/nim/tooling/vac/editor":{"title":"editor","links":[],"tags":[],"content":""},"vac/nim/tooling/vac/lsp":{"title":"lsp","links":[],"tags":[],"content":""},"vac/nim/tooling/vac/nim-suggest":{"title":"nim-suggest","links":[],"tags":[],"content":""},"vac/nim/tooling/vac/nimble":{"title":"nimble","links":[],"tags":[],"content":""},"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/qa/g/nomos/test-automation-cryptarchia":{"title":"Test Automation cryptarchia","links":[],"tags":[],"content":"vac:qa::nomos:test-automation-cryptarchia §\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 cryptarchia: 2024-05-01, 2024-08-31\n\n\nstatus: 0%\nCC: Florin, Alex, Roman\n\nDescription §\n\nCryptarchia test plan\nIntegration tests\nE2E tests\nPerformance tests\n\nJustification §\nDeliverables §"},"vac/qa/g/nomos/test-automation-data-availability":{"title":"Test Automation Data Availability","links":[],"tags":[],"content":"vac:qa::nomos:test-automation-data-availability §\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 Data Availability: 2024-07-29, 2024-10-31\n\n\nstatus: 0%\nCC: Florin, Roman\n\nDescription §\n\nTest plan\nUnit tests\nIntegration tests\nPerformance tests\n\nJustification §\nDeliverables §"},"vac/qa/g/vac/test-automation-nim-libp2p":{"title":"Test Automation nim-libp2p","links":[],"tags":[],"content":"vac:qa::vac:test-automation-nim-libp2p §\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 nim-libp2p: 2024-01-01, 2024-12-31\n\n\nstatus: 0%\nCC: Alex, Roman, Florin\n\nDescription §\nAdd tests and increase coverage for all the modules implemented in nim libp2p\nJustification §\nDeliverables §"},"vac/qa/g/vac/test-automation-nim-tooling":{"title":"Test Automation nim-tooling","links":[],"tags":[],"content":"vac:qa::vac:test-automation-nim-tooling §\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 nim-tooling: 2024-06-17, 2024-12-31\n\n\nstatus: 0%\nCC: Roman, Alex, Florin\n\nDescription §\n\nbuild process testing\ncontribution to Nim devel docker images\nNimble/Nim features testing\ncollect feedback from devs -> create issues\n\nJustification §\nDeliverables §"},"vac/qa/g/waku/interop-testing-02":{"title":"Interop Testing Part 2","links":[],"tags":[],"content":"vac:qa::waku:interop-testing-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 Interop Testing Part 2: 2024-07-01, 2024-12-31\n\n\nstatus: 0%\nCC: Florin, Roman\n\nDescription §\nAdd new coverage for the interop testing framework\n\npeer exchange\ndiscv5\npeer & connection management\nedge cases\nmore complex scenario\ncreate tests for known issues found by devs / node operators / integrators\n\nJustification §\nDeliverables §"},"vac/qa/g/waku/interop-testing":{"title":"Interop Testing","links":[],"tags":[],"content":"vac:qa::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-04-30\n\n\nstatus: 100%\nCC: Florin, Roman\n\nDescription §\nCreate an interop testing framework that can run Waku nodes and cover it’s\n\nfilter\nlightpush\nstore (incl. store v3)\nrelay\nnwaku <> go-waku interop\nci integrations\nnightly reports\n\nJustification §\nDeliverables §\n\nCreated scalable pytest framework\nReached ~ 320 tests\nCreated CI github actions workflows that:\n\nRuns nightly on latest nwaku and go-waku versions\nRuns tests between multiple nwaku nodes but with nwaku as service node and go-waku as client nodes in an interop way\nCan be run on demand against any nwaku / go-waku version\nPublishes nice reports with history and logs using github pages, check example\nNotifies waku discord channel about results of tests and pings developers if there are failures\n\n\nCoverage:\n\nfilter\nlightpush\nrelay\nstore\nsharding\n\n\nNwaku issues found:\n\n2719: store v3 response format issues\n2717: nwaku crashes for a store v3 request with invalid cursor format\n2716: passing a cursor that doesn’t correspond to any message in the store will return all messages\n2715: store v3 returns error “waku message hash parsing error: Incorrect base64 string” for some cursors\n2644: nwaku node fails to start without a shard flag\n2586: node doesn’t store messages if relay is disabled\n2582: contentTopic naming not consistent in the store response where is’s content_topic\n2567: lightpush fails with Failed to request a message push: dial_failure after the peer node restart\n2565: strange errors when light pushing messages with payload >= 300 kb\n2552: node ca be started on multiple clusters\n2550: node crashes with Message: AsyncEventQueue size exceeds limits when there are many flags to the docker start command\n2546: only receive messages if someone subscribes explicitly via REST API to a pubsubTopic\n2538: autosharding resolves content topics to wrong shard\n2512: some lightnodes are not receiving filter push in certain conditions\n2437: relay publish fails with 400 Bad Request when message contains an unknown field\n2436: relay publish fails with 400 Bad Request when message contains ephemeral field\n2388: relayed messages reach recently started peer with a big delay (~60 seconds)\n2380: Relayed messages are not stored when running nwaku with docker compose\n2372: failed to setup archive driver: Postgres has been configured but not been compiled. Check compiler definitions\n2371: multiple messages published in the same second via RLN RELAY are not dropped\n2320: Filter relay/v1/messages GET returns duplicate messages\n2319: Relay publish returns Failed to publish: timedout when a peer filter node is disconnected\n2315: updating a non existing subscriptions returns no error\n2299: Relay connection works no more\n2286: filter/v2/subscriptions response not in the expected format\n2255: pubsub topic not mandatory for filter/v2/subscriptions\n2214: relay publish fails with 400 Bad Request when message contains meta field\n2198: relay push with malformed timestamp crashes nwaku\n2147: store query cursor misbehaving for specific cursors\n2117: store response is empty when requests contains invalid cursor\n\n\nGo-Waku issues found:\n\n1110: store v3 - passing a cursor that doesn’t correspond to any message in the store will return all messages\n1109: store v3 returns error “illegal base64 data at input byte” for some cursors/hashes\n1108: pubsubTopic and contentTopics are required for store v3 requests\n1107: standardize store types by using camel case instead of snake case\n1106: store v3 local queries time out\n1087: failed to negotiate protocol: protocols not supported: [/vac/waku/store/2.0.0-beta4] when the peer node has store disabled\n1079: missing RequestId field error when lightpush has unexpected payload of content topic\n1078: lightpush on non subscribed pubsub topic hangs\n1076: strange errors when light pushing messages with payload >= 300 kb\n1074: all REST API calls return 200 with empty response\n1068: ephemeral field is ignored and not returned when retrieving messages even if the message contained this field\n1064: subscription not found if we start the node with the —pubsub-topic and we attempt to retrieve messages\n1061: dont harcode clusterid for autosharding\n1054: filter subscribe on a pubsubtopic from a different cluster id freezes\n1034: DELETE /relay/v1/subscriptions freezes in certain conditions\n988: invalid memory address or nil pointer dereference when trying to connect nodes\n972: filter/v2/subscriptions take a lot of time and even timeout sometimes\n971: Unsubscribing from one pubsubtopic seems to unsubscribe from all\n970: ping request failed with 503 when peer has no subscription\n969: PUT /filter/v2/subscriptions doesn’t exist\n968: 503 instead of 400 when a filter/v2/subscriptions bad request is sent\n967: filter/v2/subscriptions freezes when pubsubtopic is from the non-default (0) cluster\n960: Strange “not subscribed to pubsubTopic” errors for filter/v2/messages GET requests\n928: encoding/hex: odd length hex string for filter/v2/subscriptions POST requests\n923: discv5/discover.go messages flooding the docker DEBUG logs\n922: duplicate validator for topic error when trying to re-subscribe to previously unsubscribed topic\n914: REST relay publish returns HTTP 500 Internal Server Error instead of 4XX for invalid requests E:REST API service node\n\n\n"},"vac/qa/g/waku/maintenance-go-waku":{"title":"Maintenance go-waku","links":[],"tags":[],"content":"vac:qa::waku:maintenance-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 Maintenance go-waku: 2024-03-18, 2024-12-31\n\n\nstatus: 0%\nCC: Roman\n\nDescription §\nThis milestone comprises various (ad-hoc) tasks essential to maintaining and enhancing our project’s operational efficiency.\nIt is specifically designated for updates and fixes to tests that were introduced in previously closed milestones, ensuring that all our testing frameworks remain robust and up-to-date.\nIt also offers a space for small, ad-hoc developer requests, for instance, we can use this milestone when we are requested assistance with reproducing steps for a bug or to conduct an investigation into a specific failure.\nJustification §\nDeliverables §"},"vac/qa/g/waku/maintenance-js-waku":{"title":"Maintenance js-waku","links":[],"tags":[],"content":"vac:qa::waku:maintenance-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 Maintenance js-waku: 2024-03-18, 2024-12-31\n\n\nstatus: 0%\nCC: Florin\n\nDescription §\nThis milestone comprises various (ad-hoc) tasks essential to maintaining and enhancing our project’s operational efficiency.\nIt is specifically designated for updates and fixes to tests that were introduced in previously closed milestones, ensuring that all our testing frameworks remain robust and up-to-date.\nIt also offers a space for small, ad-hoc developer requests, for instance, we can use this milestone when we are requested assistance with reproducing steps for a bug or to conduct an investigation into a specific failure.\nJustification §\nDeliverables §"},"vac/qa/g/waku/maintenance-nwaku":{"title":"Maintenance nwaku","links":[],"tags":[],"content":"vac:qa::waku:maintenance-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 Maintenance nwaku: 2024-03-18, 2024-12-31\n\n\nstatus: 0%\nCC: Alex, Roman\n\nDescription §\nThis milestone comprises various (ad-hoc) tasks essential to maintaining and enhancing our project’s operational efficiency.\nIt is specifically designated for updates and fixes to tests that were introduced in previously closed milestones, ensuring that all our testing frameworks remain robust and up-to-date.\nIt also offers a space for small, ad-hoc developer requests, for instance, we can use this milestone when we are requested assistance with reproducing steps for a bug or to conduct an investigation into a specific failure.\nJustification §\nDeliverables §"},"vac/qa/g/waku/test-automation-go-waku":{"title":"Test Automation go-waku","links":[],"tags":[],"content":"vac:qa::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: 100%\nCC: Roman\n\nDescription §\n\nfilter (t)\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\n\nJustification §\nDeliverables §\n\n\nfilter:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_ping_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_proto_ident_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_push_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_subscribe_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_unsubscribe_test.go\n\n\n\nlightpush:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/lightpush/waku_lightpush_test.go\n\n\n\nstore:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/store/waku_store_client.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/store/waku_store_protocol_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/store/waku_store_query_test.go\n\n\n\nrelay:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/relay/waku_relay_test.go\n\n\n\npeer exchange:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/peer_exchange/waku_peer_exchange_test.go\n\n\n\npeer & connection management:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/peermanager/connection_gater_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/peermanager/service_slot_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/peermanager/topic_event_handler_test.go\n\n\n\ndiscv5\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/discv5/discover_test.go\n\n\n\nCI integration\n\nhttps://github.com/waku-org/waku-interop-tests/actions/workflows/test_common.yml\ngo_waku_daily which is now changed.\n\n\n"},"vac/qa/g/waku/test-automation-js-waku":{"title":"Test Automation js-waku","links":[],"tags":[],"content":"vac:qa::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: 100%\nCC: Florin\n\nDescription §\n\nfilter (t)\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\n\nAdditional requirements:\nIt should be possible to choose the nwaku version the js waku test use (done via github actions inputs)\nJustification §\nDeliverables §\n\nfilter\nlightpush\nstore\nrelay\npeer exchange\npeer & connection management\nCI integration\n"},"vac/qa/g/waku/test-automation-nwaku":{"title":"Test Automation nwaku","links":[],"tags":[],"content":"vac:qa::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: 100%\nCC: Alex\n\nDescription §\n\nfilter (t)\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\n\nJustification §\nDeliverables §\nFilter §\n- https://github.com/waku-org/nwaku/pull/2023\n- https://github.com/waku-org/nwaku/pull/2034\n- https://github.com/waku-org/nwaku/pull/2035\n- https://github.com/waku-org/nwaku/pull/2046\n- https://github.com/waku-org/nwaku/pull/2057\n- https://github.com/waku-org/nwaku/pull/2085\n- https://github.com/waku-org/nwaku/pull/2095\n- https://github.com/waku-org/nwaku/pull/2096\n\n* [tests/node/test_wakunode_filter.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_filter.nim)\n* [tests/waku_filter_v2/test_waku_client.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_filter_v2/test_waku_client.nim)\n\nLightpush §\n- https://github.com/waku-org/nwaku/pull/2269\n\n* [tests/node/test_wakunode_lightpush.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_lightpush.nim)\n* [tests/waku_lightpush/test_client.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_lightpush/test_client.nim)\n\nStore §\n- https://github.com/waku-org/nwaku/pull/2234\n- https://github.com/waku-org/nwaku/pull/2235\n- https://github.com/waku-org/nwaku/pull/2240\n\n* [tests/waku_store/test_client](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_store/test_client)\n* [tests/node/test_wakunode_store](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_store)\n\nRelay §\n- https://github.com/waku-org/nwaku/pull/2101\n- https://github.com/waku-org/nwaku/pull/2224\n\n* [tests/waku_relay/test_message_id.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_relay/test_message_id.nim)\n* [tests/waku_relay/test_protocol.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_relay/test_protocol.nim)\n\nPeer Exchange §\n- https://github.com/waku-org/nwaku/pull/2464\n\n* [tests/node/test_wakunode_peer_exchange.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_peer_exchange.nim)\n* [tests/test_relay_peer_exchange.nim (partial)](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/test_relay_peer_exchange.nim (partial))\n* [tests/waku_peer_exchange/test_protocol.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_peer_exchange/test_protocol.nim)\n* [tests/waku_peer_exchange/test_rpc_codec.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_peer_exchange/test_rpc_codec.nim)\n\nPeer & Connection Management §\n- https://github.com/waku-org/nwaku/pull/2321\n- https://github.com/waku-org/nwaku/pull/2566\n\n* [tests/node/peer_manager/peer_store/test_migrations.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/peer_manager/peer_store/test_migrations.nim)\n* [tests/node/peer_manager/peer_store/test_peer_storage.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/peer_manager/peer_store/test_peer_storage.nim)\n* [tests/node/peer_manager/peer_store/test_waku_peer_storage.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/peer_manager/peer_store/test_waku_peer_storage.nim)\n* [tests/node/test_wakunode_peer_manager.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_peer_manager.nim)\n\nDiscv5 §\n- https://github.com/waku-org/nwaku/pull/2487\n\n* [tests/waku_discv5/test_waku_discv5.nim (refactor and implementation)](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_discv5/test_waku_discv5.nim (refactor and implementation))\n* [tests/waku_enr/test_sharding.nim (refactor)](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_enr/test_sharding.nim (refactor))\n\nCI Integration §\n- None\n"},"vac/qa/g/waku/test-automation-rln":{"title":"Test Automation RLN","links":[],"tags":[],"content":"vac:qa::waku:test-automation-rln §\n\n%%{ \r\n init: { \r\n 'theme': 'base', \r\n 'themeVariables': { \r\n 'primaryColor': '#BB2528', \r\n 'primaryTextColor': '#fff', \r\n 'primaryBorderColor': '#7C0000', \r\n 'lineColor': '#F8B229', \r\n 'secondaryColor': '#006100', \r\n 'tertiaryColor': '#fff' \r\n } \r\n } \r\n}%%\r\ngantt\r\n tickInterval 1month\r\n dateFormat YYYY-MM-DD \r\n section Status\r\n Test Automation RLN: 2024-01-01, 2024-05-31\n\n\nstatus: 100%\nCC: Roman, Florin, Alex\n\nDescription §\n\nnwaku unit tests\njs-waku unit tests\ninterop off-chain tests\ninterop on-chain tests\n\nJustification §\nDeliverables §\nCode: §\n\nhttps://github.com/waku-org/waku-interop-tests/blob/master/tests/relay/test_rln.py\nhttps://github.com/waku-org/waku-interop-tests/blob/master/src/steps/rln.py\nhttps://github.com/waku-org/nwaku/pull/2356\nhttps://github.com/waku-org/nwaku/pull/2639\nhttps://github.com/waku-org/go-waku/pull/1003\nhttps://github.com/waku-org/go-waku/pull/1009\nhttps://github.com/waku-org/waku-simulator/pull/72\n\nIssues: §\n\nhttps://github.com/waku-org/nwaku/issues/2662\nhttps://github.com/waku-org/nwaku/issues/2837\nhttps://github.com/waku-org/nwaku/issues/2422\nhttps://github.com/waku-org/nwaku/issues/2602\nhttps://github.com/waku-org/nwaku/issues/2606\nhttps://github.com/waku-org/nwaku/issues/2901\nhttps://github.com/waku-org/nwaku/issues/2942\nhttps://github.com/waku-org/nwaku/issues/2822\nhttps://github.com/waku-org/nwaku/issues/2764\nhttps://github.com/waku-org/nwaku/issues/2763\nhttps://github.com/waku-org/nwaku/issues/2762\nhttps://github.com/waku-org/nwaku/issues/2743\nhttps://github.com/waku-org/nwaku/issues/2742\nhttps://github.com/waku-org/nwaku/issues/2822\nhttps://github.com/waku-org/nwaku/issues/2757\nhttps://github.com/waku-org/nwaku/issues/2946\nhttps://github.com/waku-org/nwaku/issues/2949\nhttps://github.com/waku-org/waku-simulator/issues/76\n"},"vac/qa/g/waku/test-automation-sharding":{"title":"Test Automation Sharding","links":[],"tags":[],"content":"vac:qa::waku:test-automation-sharding §\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 Sharding: 2024-01-01, 2024-04-30\n\n\nstatus: 100%\nCC: Roman, Florin, Alex\n\nDescription §\n\nnwaku unit tests\ngowaku unit tests\njs-waku unit tests\ninterop sharding tests\n\nJustification §\nDeliverables §\n\n\ngowaku:\n\nhttps://github.com/waku-org/go-waku/commit/a453c027b71cbf8d1b01d009e769d1b7d0faa8b5\n\n\n\ninterop:\n\nhttps://github.com/waku-org/waku-interop-tests/tree/master/tests/sharding\n\n\n\njs-waku:\n\nhttps://github.com/waku-org/js-waku/tree/master/packages/tests/tests/sharding\nhttps://github.com/waku-org/js-waku/blob/master/packages/utils/src/common/sharding.spec.ts\n\n\n\nnwaku:\n\nhttps://github.com/waku-org/nwaku/pull/2603\n\n\n"},"vac/qa/g/waku/test-automation-status-go-cli-2":{"title":"Status-go CLI Testing 2","links":[],"tags":[],"content":"vac:qa::waku:status-go-cli-testing-2 §\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 Status-go CLI Testing 2: 2024-08-19, 2024-12-31\n\n\nstatus: 0%\nCC: Florin\n\nDescription §\n\nReview the current test coverage of chat functionalities in status-go and proceed with further coverage. Start with community creation and usage in dedicated shards\nReview testing in status-go related to chat functionalities that rely on external systems (e.g., Waku fleet) and migrate them to an interoperable testing framework. Decouple CI tests from external/unreliable fleets\nTBD (discussions are still ongoing, Hanno will reach out to Status people to define the requirements)\n\nJustification §\nDeliverables §"},"vac/qa/g/waku/test-automation-status-go-cli":{"title":"Status-go CLI Testing","links":[],"tags":[],"content":"vac:qa::waku:status-go-cli-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 Status-go CLI Testing: 2024-06-01, 2024-09-02\n\n\nstatus: 100%\nCC: Florin\n\nDescription §\n\nTesting the reliability of message sending via the status-go CLI tool. See details\nTicket\nPotential tool to use\n\nJustification §\nDeliverables §\n\nCreated new framework that:\n\nbuilds and runs nodes using status cli tool\nprovides API to interact with different features\nruns tests for all requested features:\n\ncontact_request\ncreate_private_groups\nfetch_community\njoin_community\nleave_community\none_to_one_messages\nprivate_group_messages\n\n\nreuses communities to not clout the staging env\nruns each night on status master branch\ngenerates test report with history: https://status-im.github.io/status-cli-tests/122/\nfound multiple issues that are under investgation by Pablo\n\n\nAbility to simulate for all the above scenarios:\n\nLatency\nPacket loss\nLow bandwith\nHybernation\n\n\n\nPR list: §\n\nhttps://github.com/status-im/status-cli-tests/pull/1\nhttps://github.com/status-im/status-cli-tests/pull/2\nhttps://github.com/status-im/status-cli-tests/pull/3\nhttps://github.com/status-im/status-cli-tests/pull/4\nhttps://github.com/status-im/status-cli-tests/pull/5\nhttps://github.com/status-im/status-cli-tests/pull/6\n"},"vac/qa/g/waku/test-plan-rln":{"title":"Test Plan RLN","links":[],"tags":[],"content":"vac:qa::waku:test-plan-rln §\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 Plan RLN: 2023-02-01, 2024-02-29\n\n\nstatus: 100%\nCC: Florin\n\nDescription §\nTest plan for the Waku RLN relay.\nJustification §\nDeliverables §\n\nRLN Relay test plan\n"},"vac/qa/g/waku/test-plan-sharding":{"title":"Test Plan Sharding","links":[],"tags":[],"content":"vac:qa::waku:test-plan-sharding §\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 Plan RLN: 2023-12-01, 2024-02-29\n\n\nstatus: 100%\nCC: Florin\n\nDescription §\nTest plan for the Waku Sharding.\nJustification §\nDeliverables §\n\nSharding Test plan\n"},"vac/qa/g/waku/test-plans":{"title":"Test Plans","links":[],"tags":[],"content":"vac:qa::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: 100%\nCC: Florin\n\nDescription §\nunit + integration test\n(contains actually understanding the protocols, critically engage with the protocols)\n(instruct the engineer)\n\nfilter\nlightpush\nstore\nrelay\npeer exchange\ndiscv5\npeer & connection management\n\nJustification §\nDeliverables §\n\ntest plans\n"},"vac/qa/g/waku/ws-stress-testing":{"title":"WebSockets Stress Testing","links":[],"tags":[],"content":"vac:qa::waku:ws-stress-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 WebSockets Stress Testing: 2024-03-18, 2024-12-31\n\n\nstatus: 0%\nCC: Florin, Roman\n\nDescription §\n[WIP] : This milestone is designated as a specific request from the Waku Team, focusing on conducting a stress test to evaluate the robustness and reliability of the nim-websocket implementation versus HTTP.\n(more info will be added once the Waku 2024 milestones are finalized)\nJustification §\nDeliverables §"},"vac/qa/index":{"title":"QA Service Unit","links":["vac/qa/g/waku/test-plans","vac/qa/g/waku/test-plan-rln","vac/qa/g/waku/test-plan-sharding","vac/qa/g/waku/test-automation-js-waku","vac/qa/g/waku/test-automation-nwaku","vac/qa/g/waku/test-automation-rln","vac/qa/g/waku/test-automation-sharding","vac/qa/g/waku/test-automation-go-waku","vac/qa/g/waku/interop-testing","vac/qa/g/waku/interop-testing-02","vac/qa/g/waku/maintenance-js-waku","vac/qa/g/waku/maintenance-nwaku","vac/qa/g/waku/maintenance-go-waku","vac/qa/g/waku/ws-stress-testing","vac/qa/g/waku/test-automation-status-go-cli","vac/qa/g/waku/test-automation-status-go-cli-2","vac/qa/g/vac/test-automation-nim-libp2p","vac/qa/g/vac/test-automation-nim-tooling","vac/qa/g/nomos/test-automation-cryptarchia","vac/qa/g/nomos/test-automation-data-availability"],"tags":["dst","vac"],"content":"vac:qa:: §\n\nwaku: §\n\n test-plans\n test-plan-rln\n test-plan-sharding\n test-automation-js-waku\n test-automation-nwaku\n test-automation-rln\n test-automation-sharding\n test-automation-go-waku\n interop-testing\ninterop-testing-02\nmaintenance-js-waku\nmaintenance-nwaku\nmaintenance-go-nwaku\nws-stress-testing\n test-automation-status-go-cli\ntest-automation-status-go-cli-2\n\nvac: §\n\ntest-automation-nim-libp2p\ntest-automation-nim-tooling\n\nnomos: §\n\ntest-automation-cryptarchia\ntest-automation-data-availability\n"},"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-vote-2-3rds-vote-aggregation-specification","vac/rfc/rfc/nomos/specs-init","vac/rfc/rfc/waku/waku-keystore","vac/rfc/rfc/waku/core-rfc-updates","vac/rfc/rfc/vac/rfc-process-update","vac/rfc/rfc/vac/rfc-index","vac/rfc/rfc/nomos/carnot-threat-model-informational","vac/rfc/rfc/nomos/inter-chain-protocol-specification","vac/rfc/rfc/nomos/multi-leader-and-multi-overlay-carnot-specification"],"tags":["rfc","vac"],"content":"vac:rfc: §\n\nrfc:status: §\n\n port-status-specs\n\nrfc:nomos: §\n\n carnot-specification\n carnot-vote-2-3rds-vote-aggregation-specification\nspecs-init\n\nrfc:codex: §\n\nspecs-init\n\nrfc:waku: §\n\n waku-keystore\ncore-rfc-updates\n\nrfc:vac: §\n\n rfc-process-update\nrfc-index\n\nicebox §\n\ncarnot-threat-model-informational\ninter-chain-protocol-specification\nmulti-leader-and-multi-overlay-carnot-specification\n"},"vac/rfc/rfc/codex/specs-init":{"title":"specs-init","links":[],"tags":[],"content":"Init the effort of specifying Codex protocols.\nGo through existing docs and identify."},"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/nomos/specs-init":{"title":"specs-init","links":[],"tags":[],"content":"Init the effort of specifying Nomos protocols.\nGo through existing docs and identify."},"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/vac/rfc-index":{"title":"rfc-index","links":[],"tags":[],"content":"Build up and maintain rfc.vac.dev and https://github.com/vacp2p/rfc-index"},"vac/rfc/rfc/vac/rfc-process-update":{"title":"rfc-process-update","links":[],"tags":[],"content":"RFC process update"},"vac/rfc/rfc/waku/core-rfc-updates":{"title":"core-rfc-updates","links":[],"tags":[],"content":"Waku core RFC updates"},"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/contracts-formal-verification":{"title":"Contracts Formal Verification","links":[],"tags":[],"content":"vac:sc::codex:contracts-formal-verification §\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 Contracts Formal Verification: 2024-07-01, 2024-10-01\n\n\nstatus: 0%\nCC: r4bbit, gravityblast\n\nDescription §\nThis milestone entails the formal verification of the Codex marketplace smart contracts.\nThis should be done together with the Codex team as well as with Certora.\nIdeally, this will be done by regularly meeting with Certora and reviewing the rules that have been implemented by the Smart Contracts team.\nJustification §\nCodex is planning to launch a first version of their network by the end of 2024.\nTo ensure their marketplace system is secure they need to have their code audited and formally verified.\nDeliverables §\n\nApplication Properties for the marketplace smart contracts\nImplementation of properties in CVL rules\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: 100%\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/finance/access-control-safe-support":{"title":"Access Control Safe Support","links":[],"tags":[],"content":"vac:sc::finance:access-control-safe-support §\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 Contracts Formal Verification: 2024-06-01, 2024-12-31\n\n\nstatus: 0%\nCC: r4bbit\n\nDescription §\nThe finance team deploys various Safe multisig wallets for different finance strategies to generate yield.\nThese Safes follow a strict access control architecture by leveraging the Zodiac roles modifier module by Gnosis Guild.\nThe Smart Contracts team helps deploying these contracts as well as auditing any changes done to the deployment scripts.\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-batch-tx-ext":{"title":"Community Contracts CollectibleV1 Batch transaction Extension","links":[],"tags":[],"content":"vac:sc::status:community-contracts-batch-tx-ext §\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 CollectibleV1 Batch transaction Extension: 2024-02-19, 2024-03-21\n\n\nstatus: 100%\nCC: r4bbit\n\n**This milestone is updated on weekly basis. For a more up-to-date status head over to the milestone on GitHub.\nDescription §\nThis milestone extends the available token contracts that Status communities use to implement things like token gated permissions.\nAt the time of creating this milestone, two types of token contracts existed:\n\nCommunityERC20\nCollectibleV1\n\nThese are essentially ERC20 and ERC721 respectively, with some additional functionality, required by Status.\nIn this milestone, we’re adding support for batch transacting tokens of the BaseToken which CollectibleV1 is derived from.\nJustification §\nStatus Desktop needs to allow community owners to first deploy and mint a certain amount of their own token and then batch transact them to other accounts later on.\nRight now the only way to do this is to either use the contract’s mintTo() function, which mints to a list of accounts right away, or to perform multiple transactions for every token to be sent.\nDeliverables §\n\nBaseToken/CollectibleV1 batch transfer functions\nTests\nDocumentation\nApplication properties\nFormal verification\n"},"vac/sc/g/status/community-contracts-curation-dapp-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: 100%\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/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":"Community Contracts Token Import","links":[],"tags":[],"content":":sc:g:status:communty-contracts-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: 16%\nCC: Andrea\n\n**This milestone is updated on weekly basis. For a more up-to-date status head over to the milestone on GitHub.\nDescription §\nThis milestone is part of the effort to create “Community Vaults”.\nCommunity Vaults allow Status users to create communities that maintain their own token balances and later on allow for airdropping their tokens to other Status users or retail them.\nThis milestone focusses on the “token import”.\nThe naming is a bit misleading, but the basic idea is that users:\n\ncreate Status communities and deploy a “vault” contract\nthe vault contract acts as a wallet for the community\nany user can send ERC20 and ERC721 tokens to the vault\n\nJustification §\nDeliverables §\n\nCommunityVault smart contract implementation\nMigration/upgrade strategy for vaults\nAbility for users to deposit/import tokens to vault\nTests\nDocumentation\nFormal verification\n"},"vac/sc/g/status/community-contracts-vault-token-airdrop":{"title":"Community Vaults - Token Airdrop","links":[],"tags":[],"content":":sc:g:status:community-contracts-vault-token-airdrop §\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: Andrea\n\n**This milestone is updated on weekly basis. For a more up-to-date status head over to the milestone on GitHub.\nDescription §\nThis milestone focuses on the airdrop functionality of community vaults.\nThe general idea is that community owners and token masters can airdrop tokens that live in the community vault to other accounts and community members.\nPart of this milestone is to figure out which airdrop strategy makes most sense and then implementing it.\nJustification §\nDeliverables §\n\nAirdrop functionality in existing vault contracts\nDocumentation\nTests\nFormal verification\n"},"vac/sc/g/status/ens-usernames-maintenance":{"title":"ENS Usernames contracts maintenance","links":[],"tags":[],"content":"vac:sc::status:ens-usernames-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 Contracts Formal Verification: 2024-06-01, 2024-12-31\n\n\nstatus: 0%\nCC: Ricardo, r4bbit\n\nDescription §\nMaintaining and deploying the ens-usernames smart contracts, as well as ensuring their code is up to date.\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/minime-token-enhancement":{"title":"MiniMe 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: 100%\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/minime-token-maintenance":{"title":"MiniMe 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-v1":{"title":"Status Staking Contract V1","links":[],"tags":[],"content":"vac:sc::status:staking-contract-v1 §\n\nstatus: 52%\nCC: Ricardo\n\nDescription §\n**This milestone is updated on weekly basis. For a more up-to-date status head over to the milestone on GitHub.\nThis milestone focusses on the core functionality of the staking protocol.\nMeaning, any protocol characteristics and features that are needed for the protocol to function need to be properly implemented and tested.\nThis includes:\n\nStaking SNT and generating multiplier points\nCollecting and claiming rewards\nUnstaking funds\nMigration / upgrade to newer stake vaults\n\nThe milestone is considered done when the above is implemented, tested, documented and formally verified.\nJustification §\nDeliverables §\n\nSmart contracts implementation\nMigration strategy of vaults and stake managers\nTests\nDocumentation\nFormal verification\n"},"vac/sc/g/status/swap-aggregator":{"title":"Status Swap Aggregator","links":[],"tags":[],"content":"vac:sc::status:swap-aggregator §\n\nstatus: 0%\nCC: TBD\n\nDescription §\nThe exact details of this milestone are yet to be discussed. However, the general idea is to research if we could build a swap aggregator similar to MetaMask Swap and Rainbow Swap for Status.\nResearch has to be done in what existing system exist, how they work and how they capture revenue. Ideally we find a model that works for Status as well.\nJustification §\nBoth, MetaMask and Rainbow Wallet are making most of their revenue with their Swap protocols. With enough users, a small percentage of every trade could accumulate a significant amount of reoccuring revenue.\nDeliverables §\nTBD"},"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: 100%\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-contracts-curation-dapp-contracts","vac/sc/g/status/community-contracts-vault-token-airdrop","vac/sc/g/status/community-contracts-batch-tx-ext","vac/sc/g/status/snt-optimism-bridge","vac/sc/g/status/minime-token-enhancement","vac/sc/g/status/minime-token-maintenance","vac/sc/g/status/governance-contract-mvp","vac/sc/g/status/staking-contract-mvp","vac/sc/g/status/staking-contract-v1","vac/sc/g/status/staking-contract-maintenance","vac/sc/g/status/swap-aggregator","vac/sc/g/status/ens-usernames-maintenance","vac/sc/g/codex/review-codex-contracts","vac/sc/g/codex/contracts-formal-verification","vac/sc/g/vac/secureum-upskilling","vac/sc/g/vac/rln-contract-support","vac/sc/g/finance/access-control-safe-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\n community-contracts-curation-dapp-contracts\ncommunity-contracts-vault-token-airdrop\n community-contracts-batch-tx-ext\n SNT-optimism-bridge\n minime-token-enhancement\nminime-token-maintenance\ngovernance-contract-mvp\n staking-contract-mvp\nstaking-contract-v1\nstaking-contract-maintenance\nswap-aggregator\nens-usernames-maintenance\n\ncodex: §\n\n review-codex-contracts\ncontracts-formal-verification\n\nvac: §\n\n secureum-upskilling\nrln-contract-support\n\nfinance: §\n\naccess-control-safe-support\n"},"vac/tke/g/codex/bandwidth-incentives":{"title":"Codex Bandwidth Incentives","links":[],"tags":[],"content":"vac:tke::codex:bandwidth-incentives §\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\tBandwidth Incentives :, 2025-01-01, 2025-07-01\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nTBD\nJustification §\nAs part of Codex Technical Milestones #4 (“Bandwidth Incentives”).\nDeliverables §\n\nModeling and Simulations\nReport\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nReview of Bandwidth Provider role\nAnalysis of Bandwidth Provider costs, pricing, behavior and expectations\nEconomics and game theoretical analyses of the Bandwidth Providers\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/cdx-fees":{"title":"Codex Fee Mechanism","links":["vac/tke/g/codex/cdx","vac/tke/g/codex/cdx-insurance","vac/tke/g/codex/cdx-lender"],"tags":[],"content":"vac:tke::codex:cdx-fees §\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\tFees :, 2024-02-01, 2024-07-01\n\n\nstatus: 95%\nCC: Frederico\n\nDescription §\nUnderstand the mechanisms to implement protocol fees, e.g. burn-and-mint equilibrium model;\nJustification §\nUnderstand the security of the system. As part of the Codex Technical Milestone #5 (“Tokenomics”).\nDeliverables §\n\nSpecific parts of three chapters of the Codex Litepaper (Use Cases, Contract Lifecycle, and CDX Tokenomics) (the milestones cdx, cdx-insurance, and cdx-lender cover the remaining parts of these chapters).\nOne section of the Codex Whitepaper (CDX Tokenomics)\n\nTracking Metrics §\nCompletion of the respective sections in the Codex Litepaper and Whitepaper.\nWork breakdown §\nDefinition of value accrual, capture and incentive mechanisms of the Codex protocol.\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/cdx-insurance":{"title":"Codex Insurance Mechanism Analysis","links":["vac/tke/g/codex/cdx","vac/tke/g/codex/cdx-fees","vac/tke/g/codex/cdx-lender"],"tags":[],"content":"vac:tke::codex:cdx-insurance §\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\tInsurance Mechanism :, 2024-02-01, 2024-07-01\n\n\nstatus: 95%\nCC: Frederico, Juan\n\nDescription §\nMechanisms to make the system more stable\nJustification §\nUnderstand the roles that impact the performance and security of the protocol. As part of the Codex Technical Milestone #5 (“Tokenomics”).\nDeliverables §\n\nSpecific parts of three chapters of the Codex Litepaper (Use Cases, Contract Lifecycle, and CDX Tokenomics) (the milestones cdx, cdx-fees, and cdx-lender cover the remaining parts of these chapters).\nOne section of the Codex Whitepaper (CDX Tokenomics)\n\nTracking Metrics §\nCompletion of the respective sections in the Codex Litepaper and Whitepaper.\nWork breakdown §\n\nDefinition of insurance role.\nAnalysis of CDX impact on system security.\nComparison against protocols which don’t have any embeeded stabilization mechanism.\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/cdx-lender":{"title":"Codex Lender Analysis","links":["vac/tke/g/codex/cdx","vac/tke/g/codex/cdx-fees","vac/tke/g/codex/cdx-insurance"],"tags":[],"content":"vac:tke::codex:cdx-insurance §\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\tLender :, 2024-05-01, 2024-07-01\n\n\nstatus: 95%\nCC: Juan\n\nDescription §\nDesign and modeling of the lender role\nJustification §\nUnderstand the roles that impact the performance and security of the protocol. As part of the Codex Technical Milestone #5 (“Tokenomics”).\nDeliverables §\n\nSpecific parts of three chapters of the Codex Litepaper (Use Cases, Contract Lifecycle, and CDX Tokenomics) (the milestones cdx, cdx-fees, and cdx-insurance cover the remaining parts of these chapters).\nOne section of the Codex Whitepaper (CDX Tokenomics)\n\nTracking Metrics §\nCompletion of the respective sections in the Codex Litepaper and Whitepaper.\nWork breakdown §\n\nDefinition of insurance role.\nAnalysis of CDX impact on system security.\nComparison against protocols which don’t have any embeeded stabilization mechanism.\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/cdx":{"title":"Analysis of the Codex Token","links":["vac/tke/g/codex/cdx-fees","vac/tke/g/codex/cdx-insurance","vac/tke/g/codex/cdx-lender"],"tags":[],"content":"vac:tke::codex:cdx §\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\tCDX :, 2024-02-01, 2024-07-01\n\n\nstatus: 95%\nCC: Frederico\n\nDescription §\nCodex token as utility token for all participants (collateral and payment), impact on system security.\nJustification §\nDevelopment of Codex own utility token. As part of the Codex Technical Milestone #5 (“Tokenomics”).\nDeliverables §\n\nSpecific parts of three chapters of the Codex Litepaper (Use Cases, Contract Lifecycle, and CDX Tokenomics) (the milestones cdx-fees, cdx-insurance, and cdx-lender cover the remaining parts of these chapters).\nOne section of the Codex Whitepaper (CDX Tokenomics)\n\nTracking Metrics §\nCompletion of the respective sections in the Codex Litepaper and Whitepaper.\nWork breakdown §\n\nDefinition and analysis of Codex economy\nCDX as utility token for all participants (collateral and payment).\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/contract-defaults":{"title":"Codex Contract Default","links":["vac/tke/g/codex/contract-finalization","vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:contract-defaults §\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\tContract Defaults :, 2024-10-01, 2024-12-31\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDesign of the systemic slashing mechanism.\nJustification §\nAs part of Codex Technical Milestones #3 (“Marketplace Interactions”).\nDeliverables §\n\nModeling and Simulations of the slashing mechanisms\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-finalization, contract-initiation, contract-matching, proof-aggregators, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nReview consequences for SPs, Clients and PAs\nEconomic and game theoretical analysis of these consequences\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/contract-finalization":{"title":"Codex Contract Finalization","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:contract-finalization §\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\tContract Finalization :, 2024-10-01, 2025-01-01\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nSPs & Users obligations, data retrieval incentives, collateral retrieval, contract extension.\nJustification §\nAs part of the contract finalization process. As part of Codex Technical Milestones #3 (“Marketplace Interactions”).\nDeliverables §\n\nModeling and Simulations of the data retrieval process\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, proof-aggregators, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/contract-initiation":{"title":"Codex Contract Initiation","links":["vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:contract-initiation §\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\tContract Initiation :, 2024-10-01, 2024-12-31\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nMechanics of Codex contract initiation.\nJustification §\nAs part of Codex Technical Milestones #3 (“Marketplace Interactions”).\nDeliverables §\n\nModeling and Simulations of the Client behavior\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-matching, contract-defaults, contract-finalization, proof-aggregators, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nDefinition of default settings\nFacilitate the matching of pricing and collateral size\nAnalysis of client payment (full vs. partial upfront)\nAnalysis of potential gamifications and penalties\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/contract-matching":{"title":"Codex Contract Matching","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:contract-matching §\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\tContract Matching :, 2024-10-01, 2024-12-31\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine how slots are reserved and filled.\nJustification §\nAs part of the slot reservation mechanism. As part of Codex Technical Milestones #3 (“Marketplace Interactions”).\nDeliverables §\n\nModeling and Simulations of the slot reservation mechanism\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-defaults, contract-finalization, proof-aggregators, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nEconomics and game theoretical analysis of the Slot Reservation Mechanism\n\n### Perceived Risks\nTechnical and legal constraints."},"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, 2024-02-04\n\n\nstatus: 100%\nCC: Matty, Frederico, Martin\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/codex/proof-aggregators":{"title":"Codex Proof Aggregators","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:proof-aggregators §\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\tProof Aggregators :, 2024-07-01, 2024-10-01\n\n\nstatus: 10%\nCC: Frederico\n\nDescription §\nEconomics of the proof aggregator (incentives, costs, pricing).\nJustification §\nAs part of Codex Technical Milestones #1 (“Proof Aggregation”) and #2 (“Aggregator Network”).\nDeliverables §\n\nModeling and Simulations of the Proof Aggregator actor and process\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, contract-finalization, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nDefinition of the Proof Aggregator role\nAnalysis of PA costs and pricing\nDefinition of the Proof Aggregation economy\nAnalysis of the interactions between PAs\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/recovery-auction":{"title":"Codex Recovery Auction","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:recovery-auction §\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\tRecovery Auction :, 2024-10-01, 2024-12-31\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine details of the auction mechanisms for the slot recovery.\nJustification §\nAs part of Codex Technical Milestones #6 (“Data Repair”).\nDeliverables §\n\nModeling and Simulations of the auction mechanism\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, contract-finalization, proof-aggregators, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nDefine what triggers and ends the auction recovery mechanism\nDesign the Dutch Auction\nEvaluate impact on CDX price stability\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/slot-repair":{"title":"Codex Slot Repair","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:slot-repair §\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\tSlot Repair :, 2024-10-01, 2025-01-01\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDesign of the slot recovery mechanism.\nJustification §\nAs part of Codex Technical Milestones #6 (“Data Repair”).\nDeliverables §\n\nModeling and Simulations of the slot repair mechanism\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, contract-finalization, proof-aggregators, recovery-auction, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nEconomics and game theoretical analysis of the Slot Recovery Mechanism\nDefinition of the trigger of the Recovery Auction\nEnsure data availability.\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/tax-system":{"title":"Codex Tax System","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair"],"tags":[],"content":"vac:tke::codex:tax-system §\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\tTax System :, 2024-07-01, 2024-10-01\n\n\nstatus: 10%\nCC: Frederico\n\nDescription §\nJustification §\nAs part of Codex Technical Milestones #1 (“Proof Aggregation”) and #2 (“Aggregator Network”).\nDeliverables §\n\nModeling and Simulations of the CDX stability\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, contract-finalization, proof-aggregators, recovery-auction, and slot-repair cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nDefinition of a tax system\nAnalysis of the application of taxes\nAnalysis of CDX price stability\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/testnet-incentive":{"title":"Codex Testnet Incentives","links":[],"tags":[],"content":"vac:tke::codex:testnet-incentive §\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\tIncentivized Tesnet :, 2024-06-01, 2024-07-01\n\n\nstatus: 40%\nCC: Frederico, Martin, Juan\n\nDescription §\nDesign incentives for testnet.\nJustification §\nAs part of Codex Production Milestone #4 (Codex v1 Mainnet Launch).\nDeliverables §\nReport with analyses of incentives and expected consequences.\nTracking Metrics §\nDelivery of the report, and agreement with team and stakeholders.\nWork breakdown §\n\nDefinition of optimization goals\nDefinition of metrics\nAnalysis of incentives\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/finance/growth-models":{"title":"Financial Growth Models","links":[],"tags":[],"content":"vac:tke::finance:growth-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\tdateFormat YYYY-MM-DD\n\tsection Finance\n\t\tGrowth Models :, 2024-02-05, 2024-07-31\n\n\nstatus: 80%\nCC: Martin\n\nDescription §\nAd hoc assistance and consulting the use and further expansion of the growth model.\nJustification §"},"vac/tke/g/finance/real-option-models":{"title":"Finance Real Option Models","links":[],"tags":[],"content":"vac:tke::finance:real-option-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\tdateFormat YYYY-MM-DD\n\tsection Finance\n\t\tReal Option Models :, 2024-02-05, 2024-07-31\n\n\nstatus: 20%\nCC: Frederico\n\nDescription §\nDevelopment of pricing models based real option analysis.\nJustification §"},"vac/tke/g/nomos/cryptarchia-wealth-concentration-estimated-stake":{"title":"Cryptarchia Wealth Concentration Estimated Stake","links":[],"tags":[],"content":"vac:tke::nomos:cryptarchia-wealth-concentration-estimated-stake §\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 :, 2024-02-15, 2024-02-19\n\n\nstatus: 100%\nCC: Frederico\n\nDescription §\nUnderstand whether the algorithm that learns the total stake of the system affects wealth concentration. If so, under which conditions.\nJustification §\nNomos develops a private PoS system."},"vac/tke/g/nomos/cryptarchia-wealth-concentration-known-stake":{"title":"Cryptarchia Wealth Concentration Known Stake","links":[],"tags":[],"content":"vac:tke::nomos:cryptarchia-wealth-concentration-known-stake §\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 :, 2024-02-05, 2024-02-14\n\n\nstatus: 100%\nCC: Frederico\n\nDescription §\nUnderstand whether wealth concentration happens or not in traditional PoS. If so, under which conditions.\nJustification §\nNomos introduces a PoS system."},"vac/tke/g/nomos/delegation-research":{"title":"Nomos Delegation Research","links":[],"tags":[],"content":"vac:tke::nomos:delegation-research §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nUnderstand what other chains are doing with respect to delegation and restaking.\nJustification §\nAs part of Nomos PoS development."},"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, 2024-02-04\n\n\nstatus: 100%\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/nomos/enshrined-delegation":{"title":"Nomos Enshrined Delegation","links":[],"tags":[],"content":"vac:tke::nomos:enshrined-delegation §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine the best way is to incorporate delegation and restaking into Nomos.\nJustification §\nAs part of Nomos PoS development."},"vac/tke/g/nomos/mixnet-incentives":{"title":"Nomos Mixnet Incentives","links":[],"tags":[],"content":"vac:tke::nomos:mixnet-incentives §\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\tMixnet Incentives :, 2024-03-04, 2024-04-03\n\n\nstatus: 1%\nCC: Frederico\n\nDescription §\nSustainable mixnets need to be properly incentivized.\nJustification §\nAs part of Nomos privacy requirements."},"vac/tke/g/nomos/non-private-L2-consensus":{"title":"Nomos Non Private L2 Consensus","links":[],"tags":[],"content":"vac:tke::nomos:non-private-L2-consensus §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nThese will work likely with isolated pools. Since these are pools, would also be important to understand.\nJustification §\nAs part of Nomos development."},"vac/tke/g/nomos/penalizable-actions":{"title":"Nomos Penalizable Actions","links":[],"tags":[],"content":"vac:tke::nomos:penalizable-actions §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine actions that lead to a slash on Nomos.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/rewarded-actions":{"title":"Nomos Rewarded Actions","links":[],"tags":[],"content":"vac:tke::nomos:rewarded-actions §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine actions that lead to rewards on Nomos.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/selfish-behavior":{"title":"Nomos Validator Rewards","links":[],"tags":[],"content":"vac:tke::nomos:selfish-behavior §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nUnderstand what problems can emerge when validators modify the fork choice rule of the protocol to another one that best suits them.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/shared-liquidity":{"title":"Nomos Shared Liquidity","links":[],"tags":[],"content":"vac:tke::nomos:shared-liquidity §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nUnderstand the problem of L2 liquidity fragmentation in general.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/supply-policy":{"title":"Nomos Supply Policy","links":[],"tags":[],"content":"vac:tke::nomos:supply-policy §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine initial supply, distribution, allocations.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/tdc-objectives":{"title":"Nomos TDC Objectives","links":[],"tags":[],"content":"vac:tke::nomos:tdc-objectives §\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\tTDC Objectives :, 2024-02-05, 2024-03-13\n\n\nstatus: 70%\nCC: Frederico\n\nDescription §\nWrite the Objectives & Requirements section of the Token Design Canvas.\nJustification §"},"vac/tke/g/nomos/transaction-fee":{"title":"Nomos Transaction Fee","links":[],"tags":[],"content":"vac:tke::nomos:transaction-fee §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDesign block space pricing mechanism.\nJustification §\nAs part of Nomos PoS development."},"vac/tke/g/nomos/validator-rewards":{"title":"Nomos Validator Rewards","links":[],"tags":[],"content":"vac:tke::nomos:validator-rewards §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine how much tokens are distributed as rewards to block proposers.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/whitepaper":{"title":"Nomos Whitepaper","links":[],"tags":[],"content":"vac:tke::nomos:whitepaper §\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\tNomos Whitepaper :, 2024-02-05, 2024-02-29\n\n\nstatus: 100%\nCC: Frederico\n\nDescription §\nProvide feedback.\nJustification §"},"vac/tke/g/status/L2-deployment":{"title":"Status L2 deployment","links":[],"tags":[],"content":"vac:tke::status:L2-deployment §\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\tStatus L2 deployment: 2024-02-05, 2024-05-31\n\n\nstatus: 20%\nCC: Martin\n\nDescription §\nTBD\nJustification §"},"vac/tke/g/status/incentivized-communitities":{"title":"Incentivize Status Communitities","links":[],"tags":[],"content":"vac:tke::status:incentivized-communitities §\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nTBD\nJustification §\nTBD"},"vac/tke/g/status/snt-governance-proposal":{"title":"SNT Governance Proposal","links":[],"tags":[],"content":"vac:tke::status:SNT-governance-proposal §\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 Governance Proposal: 2023-09-01, 2024-06-30\n\n\nstatus: 50%\nCC: Martin\n\nDescription §\n\ntook precedence over SNT litepaper\nfirst draft being prepared for next review with John on 2023/09/12\norganizing snapshot voting\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, 2024-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, 2024-03-30\n\n\nstatus: 90%\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/status/waku-sharding":{"title":"Waku Sharding","links":[],"tags":[],"content":"vac:tke::status:waku-sharding §\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 Waku Sharding: 2024-07-01, 2024-07-30\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nTBD\nJustification §"},"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, 2024-02-04\n\n\nstatus: 100%\nCC: Martin\n\nDescription §\nWaku economic analysis"},"vac/tke/g/waku/general-incentives":{"title":"Waku General Incentives","links":[],"tags":[],"content":"vac:tke::waku:general-incentives §\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nGive feedback and assist Waku’s team in drafting incentivization mechanisms."},"vac/tke/g/waku/rln-membership":{"title":"Waku RLN Membership","links":[],"tags":[],"content":"vac:tke::waku:rln-membership §\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 :, 2024-02-05, 2024-03-30\n\n\nstatus: 30%\nCC: Martin\n\nDescription §\nDesigh a comprehensive strategy for RLN memberships, perhaps following the NFT-like approach. Strategy should consider pricing mechanisms, payment options, dev/node compensation and project sustainability, security, etc."},"vac/tke/g/waku/rln-risks-L2":{"title":"Waku RLN Risks","links":[],"tags":[],"content":"vac:tke::waku:rln-risks-L2 §\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nDrive the discussion around feasibility/risks for RLN on L2, leading to a recommendation of a specific L2."},"vac/tke/g/waku/rln-risks-attacks-vectors":{"title":"Waku RLN Attacks Vectors","links":[],"tags":[],"content":"vac:tke::waku:rln-risks-attacks-vectors §\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nRisk/attack analysis for RLN; recovery mechanisms."},"vac/tke/g/waku/store-incentives":{"title":"Waku Store Incentives","links":[],"tags":[],"content":"vac:tke::waku:store-incentives §\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 :, 2024-02-05, 2024-03-30\n\n\nstatus: 20%\nCC: Martin\n\nDescription §\nGive feedback and assist Waku’s team in drafting store incentivization MVP."},"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/status/L2-deployment","vac/tke/g/status/waku-sharding","vac/tke/g/status/incentivized-communitities","vac/tke/g/codex/economic-analysis","vac/tke/g/codex/cdx","vac/tke/g/codex/cdx-fees","vac/tke/g/codex/cdx-insurance","vac/tke/g/codex/cdx-lender","vac/tke/g/codex/testnet-incentive","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/tax-system","vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/slot-repair","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/bandwidth-incentives","vac/tke/g/nomos/economic-analysis","vac/tke/g/nomos/cryptarchia-wealth-concentration-known-stake","vac/tke/g/nomos/cryptarchia-wealth-concentration-estimated-stake","vac/tke/g/nomos/whitepaper","vac/tke/g/nomos/tdc-objectives","vac/tke/g/nomos/mixnet-incentives","vac/tke/g/nomos/selfish-behavior","vac/tke/g/nomos/rewarded-actions","vac/tke/g/nomos/penalizable-actions","vac/tke/g/nomos/validator-rewards","vac/tke/g/nomos/delegation-research","vac/tke/g/nomos/enshrined-delegation","vac/tke/g/nomos/transaction-fee","vac/tke/g/nomos/supply-policy","vac/tke/g/nomos/shared-liquidity","vac/tke/g/nomos/non-private-L2-consensus","vac/tke/g/waku/economic-analysis","vac/tke/g/waku/rln-membership","vac/tke/g/waku/rln-risks-L2","vac/tke/g/waku/rln-risks-attacks-vectors","vac/tke/g/waku/store-incentives","vac/tke/g/waku/general-incentives","vac/tke/g/finance/growth-models","vac/tke/g/finance/real-option-models"],"tags":["p2p","vac"],"content":"vac:tke:: §\n\nstatus: §\n\nsnt-lightpaper\nSNT-governance-proposal\nSNT-staking\nL2-deployment\nwaku-sharding\nincentivized-communitities\n\ncodex: §\n\neconomic-analysis\ncdx\ncdx-fees\ncdx-insurance\ncdx-lender\ntestnet-incentive\nproof-aggregators\ntax-system\ncontract-initiation\ncontract-matching\ncontract-defaults\ncontract-finalization\nslot-repair\nrecovery-auction\nbandwidth-incentives\n\nnomos: §\n\neconomic-analysis\ncryptarchia-wealth-concentration-known-stake\ncryptarchia-wealth-concentration-estimated-stake\nwhitepaper\ntdc-objectives\nmixnet-incentives\nselfish-behavior\nrewarded-actions\npenalizable-actions\nvalidator-rewards\ndelegation-research\nenshrined-delegation\ntransaction-fee\nsupply-policy\nshared-liquidity\nnon-private-L2-consensus\n\nwaku: §\n\neconomic-analysis\nrln-membership\nrln-risks-L2\nrln-risks-attacks-vectors\nstore-incentives\ngeneral-incentives\n\nfinance: §\n\ngrowth-models\nreal-option-models\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"},"vac/updates/2023-11-27":{"title":"2023-11-27 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDig into the secure/noise part of libp2p\nWrite a prologue with the client and server certificates in the noise protocol\n\n\nnimlibp2p:vac:maintenance\n\nYamux window size configurable\nFix yamux / relay interaction; Add 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(yamux): yamux uses wrong direction during dcutr https://github.com/status-im/nim-libp2p/pull/992\nfix(multiaddress): add quic-v1 multiaddress support https://github.com/status-im/nim-libp2p/pull/988\nfix(dcutr): handle tcp/p2p addresses https://github.com/status-im/nim-libp2p/pull/989\nfix(identify): do not add p2p and relayed addrs to observed addr manager https://github.com/status-im/nim-libp2p/pull/990\n\n\nnimlibp2p:vac:maintenance\n\nnew issue: Cannot run tests on Apple M1 MacOS https://github.com/status-im/nim-libp2p/issues/993\nResearch VM hosting providers - Akash Network added https://docs.google.com/spreadsheets/d/1VL6QpDdBgYC1Ld0Nr-cpNv9bRht3nQkBQUF1pNerBDs/edit?usp=sharing\nCI workflow is failing frequently Testing Nimble lock file - resolving Nimble install issues on Windows\n\nhttps://github.com/status-im/nim-libp2p/issues/975\nhttps://github.com/status-im/nim-libp2p/tree/fix/ci-workflow-stability\nhttps://discord.com/channels/864066763682218004/1172153963559260231\nfix: move workflows for Nim Devel and legacy i386 from “Daily” -> comments about to be resolved\nshould the version be pinned?: https://github.com/status-im/nim-libp2p/pull/968\n\n\n\n\n\nvac:tke: §\n\nvac:tke::nomos:economic-analysis\n\nFrederico has been joining in remotely to relevant talks at Nomos offsite\nContinuing research of PoS economics and token distributions, posted some initial simulation results, evolving further (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nMartin returning from DevConnect and Waku offsite, will formulate followups for next steps\nShare EigenTrust python implementation w/ Sergei, and adapt for client-server type systems (@Matty)\n\n\n\nvac:dst: §\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\ncont’ simulations (500kb msgs, 4 chunks, 250 nodes)\n\n\neng-10ktool:vac:bandwidth-test:\n\nWrite experiments in notion\nInvestigate CPU bottleneck in 3rd machine\nChanged waku deployment to work in batches\nSyncronized gossipsub nodes injection for better comparisons with waku\nRun 1k simulation for comparison and gather data\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nImplemented and merged 3rd and 4th PRs :\nmake framework support dynamic number of nodes\n\nadd multi-node tests (that work on any number of nodes)\nsubscribe / unsubscribe tests\nreached 43 tests\n\n\nIssues reported:\n\nre-subscribe to previously unsubscribed topic fails\nlogs are floaded\n\n\nstarted writing document on Waku implementations diffs\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nRemove duplicated code\n\nPR\n\n\nFinish implementing store tests\n\nPR 1\nPR 2\n\n\nSqlite Bug: Not saving WakuMessage.ephemeral\n\nIssue\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nwrote 5 tests related to filter push and relay - invalid data https://github.com/waku-org/go-waku/pull/916\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nGetting familiar with treekem as a possible solution for the group chat scenario.\nWrite a document on TreeKEM vs ADKG\n\n\nadmin/misc\n\nStarted a comparison between Waku specifications https://www.notion.so/Comparison-Waku-35-Waku-37-5ee9aac6cc72466a95d624865a561da6\n\n\nzerokit:vac:maintenance\n\nworked on a PR to update multiplier (https://github.com/vacp2p/zerokit/pull/224)\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nWorked on getting the Cetora CI integration into mergable state and landed it https://github.com/vacp2p/minime/pull/43\nAdded Certora CI integration to our foundry template https://github.com/vacp2p/foundry-template/pull/10\nWorking through the Certora tutorials to learn CVL\n\n\nstatus:communites-contracts-maintenance\n\nAdded Certora CI integration and reactivate old formal verification rules https://github.com/status-im/communities-contracts/pull/24\nfinished testing CommunityVault https://github.com/status-im/communities-contracts/pull/22\n\n\nstatus:status-network-token-v2\n\nRefactored token controller and added destroyTokens API https://github.com/status-im/status-network-token-v2/pull/1\n\n\nstatus:governance-contract-mvp\n\nimplement Proposal.sol contract\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nWorking on a review of all L2 and Zk Rollups that are trying to do “state separation”\nResearching how to build a UTXO to Account based adapter and viceversa\nCompiled documents on research topics: Verkle trees, enhanced privacy\nstudied about dual architecture L2 from its docs; created a report about it; includes some questions\n\n\nproofsystems:vac:benchmarks\n\nFixed comments on a PR for a GWC implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/17\nResearch PoC ProtoGalaxy implementation (https://github.com/arnaucube/protogalaxy-poc)\nReviewed Halo2-GWC PR.\nReviewed Halo2-SHPLONK PR.\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStarted researching BaseFold (https://eprint.iacr.org/2023/1705.pdf)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nResults for different machines were not found for given signatures for latency. Probably the logs are processed in different timewindow; investigating\n\n\nvalpriv:vac:tor-push-paper\n\nFinalizing and updating changes, better figures\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nworked on different performance evaluation metrics, and finalized their implementation in simulation scripts. The details are reflected in ‘Results and Discussion’ section\nFinalized simulation scenarios, and corresponding theoratical estimates. The details are reflected in ‘Results and Discussion’ section\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nUpdated photo names and location in 71/STATUS-PUSH-NOTIFICATION RFC https://github.com/vacp2p/rfc/pull/629\napply feedback\nwhisper mailserver - https://github.com/jimstir/rfc/blob/mailserver1/content/docs/rfcs/mailserver.md https://github.com/jimstir/rfc/blob/mailserver1/content/docs/rfcs/whipser-mailserver.md\n\n\nwaku:waku-keystore\n\nFixed Draft, ready for review - https://github.com/vacp2p/rfc/pull/631\n\n\nadmin/misc\n\nlooked for improvements for COSS - https://github.com/jimstir/rfc/tree/1/COSS-Improvements/content/docs/rfcs/1\n\n\n"},"vac/updates/2023-12-04":{"title":"2023-12-04 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nTrying to make the last handshake work:\n\nRe-write the webrtc-transport\nRe-write datachannel to understand why the webrtc doesn’t connect\nSpend some time on the noise protocol\nIt appears the problem comes from SCTP\n\n\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\nfix(dcutr): update the DCUtR initiator transport direction to Inbound https://github.com/status-im/nim-libp2p/pull/\n\n\nnimlibp2p:vac:maintenance\n\nfix: remove forgotten “matrix-prep” job https://github.com/status-im/nim-libp2p/pull/997\nVM hosting providers updated https://www.notion.so/991bb915e4634248a764832e56f53160?v=24979d84f52f4df2b779bf5eb24ec3c5&pvs=4\nProject requirements for P2P CI added https://www.notion.so/782270f71b72438e963e0e5ef73358d9?v=5560c9000535403c9f72862eb9775ff9&pvs=4\nCI workflow is failing frequently; Testing Nimble lock file - Installed Windows 2019 - resolving Nimble install issues on Windows\n\nhttps://github.com/status-im/nim-libp2p/issues/975\nhttps://github.com/status-im/nim-libp2p/tree/fix/ci-workflow-stability\n-https://discord.com/channels/864066763682218004/1172153963559260231\n\n\nfix: move workflows for Nim Devel and legacy i386 from “Daily” -> comments resolved, commits resubmited with GPG signature https://github.com/status-im/nim-libp2p/pull/968\nInvestigate flaky tests issue PR [Ongoing discussion]\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nStill waiting for further Codex feedback on next steps for litepaper\n\n\nvac:tke::status:SNT-staking\n\nThis week followup with SC team on staking contract implementation (may be delayed due to Martin out with covid)\n\n\nvac:tke::nomos:economic-analysis\n\nOffsite documents will be released this week, Frederico will review and participate in their planning meeting for next steps on week and month\n\n\nvac:tke::waku:economic-analysis\n\nDiscussed EigenTrust reputation with Sergei, deprioritzed to first design simpler system\nMartin still out, when back will sync w/ Waku team for offsite debrief and identify next steps\nFor now, TE team is actively commenting on Sergei’s github issues to formalize Waku specs\n\n\n\nvac:dst: §\n\nanalysis-gsub-model:vac:refactoring\n\nThe different cases and runs can now be partly automated\n\n\neng-10ktool:vac:bandwidth-test:\n\nRun more simulations, do more in depth analysis\nUpdate repositories with latest changes\nUpdate notion information regarding Kubernetes cluster\nCreated plots and put everything in notion (https://www.notion.so/Results-dec50e8dc3e5426ab4f34c712de0b4f\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nFilter subscribe PR:\n\ncovers subscribe creation and update\nreached 67 tests\n\n\nIssue reported gowaku: encoding/hex: odd length hex string error when subscribing\nIssue reported nwaku: pubsubTopic not required as described in the specs\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nBegin lightpush tests PR - WIP\nFound a Lightpush.publish attribute type bug Issue\ndirection attribute related functionality\n\nPR\nRefactor from ascending to direction for consistency\nHistoryQuery.direction Default value fix\ndirection attribute from bool to enum\n\n\nMerged PR\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 5 tests related to filter - coverage improvement https://github.com/waku-org/go-waku/pull/931\nOpened & got fixed issue “unsubscribe all with unrelated peer” https://github.com/waku-org/go-waku/issues/933\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\nwork on retry strategy for rpc calls in rln-relay: https://github.com/waku-org/nwaku/issues/2217\n\n\nsecure-channels:waku:ethereum-chat\n\nCompletion of the group chat approach using UPKE.\nInclusion of an elliptic-curve variation of UPKE.\nImprovements on the RFC and solving questions from Waku team.\ncreated a document about comparison treeKEM and ADKG in terms of security, complexity, and additional features. (WIP)\n\n\nzerokit:vac:maintenance\n\nresearched issue https://github.com/vacp2p/zerokit/issues/78\n\n\nadmin/misc\n\ninvestigate having the membership tree onchain: https://github.com/waku-org/research/issues/56\nworked with waku to have the membership tree onchain, successfully integrated in https://github.com/vacp2p/rln-contract/pull/31, moved to foundry template as well (will sync with SC unit)\n\n\n\nvac:sc:: §\n\nstatus:status-network-token-v2\n\nSome cleanup https://github.com/status-im/status-network-token-v2/pull/2\nAdded certora integration for CI https://github.com/status-im/status-network-token-v2/pull/3\nAdded sepolia deployment config https://github.com/status-im/status-network-token-v2/pull/4\nDeployed SNTV2 on Sepolia\n\nhttps://sepolia.etherscan.io/address/0xE452027cdEF746c7Cd3DB31CB700428b16cD8E51\nhttps://github.com/status-im/status-network-token-v2/pull/6\n\n\n\n\nvac:maintenance:misc\n\nAdded certora integration for CI to governance https://github.com/vacp2p/governance/pull/3\nResearched SAT and SMT solvers to get a better understanding of how Certora works\nDeployed OP SNT to OP Sepolia\n\nPR for bridge UI https://github.com/ethereum-optimism/ethereum-optimism.github.io/pull/591\nPR for addresses and sepolia config https://github.com/logos-co/optimism-bridge-snt/pull/29\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nWorked on different L2 and Rollups focusing on privacy (Az, Pol, Zc)\nLooking on UTXO - Account based traslation (Car)\nVerkle tree document (WIP)\nBegin to survey newer PCSs to see if any may yield better results than KZG. 1, 2, 3\nBegin reading VM SMT\nDelved into the L2 protocol and understood how they use hybrid states and UTXO based execution. And extract some insight from the architecture.\nDocumented L2 protocol and its hybrid execution (WIP)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\naggregation, block proposal time, tor diagnostic to consider and add.\n\n\nvalpriv:vac:tor-push-paper\n\nFinalizing, adding discussion, revising figures\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\ncarried out experiments on shadow simulator for GissipSub improvements paper. The experiments check the performance of proposed schemes against increasing network size, increasing message sizes and increasing publishers.\nMost of the simulations are done successfully. Some large simulations may take 1-2 more days\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nCreated short summaries, added some new abstracts, added references - https://github.com/vacp2p/rfc/pull/640\nhttps://github.com/vacp2p/rfc/pull/639\nhttps://github.com/vacp2p/rfc/pull/638\nhttps://github.com/vacp2p/rfc/pull/637\nhttps://github.com/vacp2p/rfc/pull/636\nhttps://github.com/vacp2p/rfc/pull/635\nhttps://github.com/vacp2p/rfc/pull/634\nhttps://github.com/vacp2p/rfc/pull/633\n\n\nwaku:waku-usage\n\nUpdated waku2 usage - https://github.com/vacp2p/rfc/pull/6\n\n\n"},"vac/updates/2023-12-11":{"title":"2023-12-11 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDebugging SCTP\n\n\nnimlibp2p:vac:maintenance\n\nYamux\n\nRe-write misleading parts (eg sendQueueSize)\nStart writing explanations/comments\ncont’ https://github.com/status-im/nim-libp2p/pull/987\n\n\nadded the hp tests to nim-libp2p (they run with every PR)\nworking on the nim-libp2p releases\n\n\n\nvac:tke: §\n\nvac:tke::status:SNT-staking\n\nResuming conversation with SC team on staking contract and Certora training\nstarting to discuss with Pablo on Waku sharding to support decentralized scaling of Status\n\n\nvac:tke::nomos:economic-analysis\n\nIncorporating changes in consensus from Carnot to Ouroboros\nResearch how delegation is used in comps of Cardano, Polkadot, and EigenLayer, compared against privacy restrictions given Nomos objectives\n\n\nvac:tke::waku:economic-analysis\n\nSharding discussion w/ Pablo on Waku\nContinuing GitHub issue feedback on Waku incentives and reputation (bottom up approach)\nAlso start a business model analysis and implications for next steps with the protocol (top down approach)\n\n\n\nvac:dst: §\n\nanalysis:nomos:simulation-analysis\n\nThe goals and the responsibilities for the paper reaffirmed\nAnalysis correctly and switfly found parameter issues in the small-tree simulations (which follow a different control path); met with Gusto and it is fixed now\n\n\nanalysis-gsub-model:vac:refactoring\n\n95% done, barring minor stylistics and input re-structuring branch(https://github.com/vacp2p/research/tree/0xFugue-waku-scaling-rewrite)\n\n\nanalysis-gsub-model:status:control-messages\n\nThe blog post is one 20% done: the overall design of Waku explained and modelling focus defined draft(https://github.com/vacp2p/vac.dev/tree/0xFugue-waku-model)\n\n\neng-10ktool:vac:bandwidth-test:\n\nTest new kernel parameters\nInvestigame uptimes for ram on simulations\nInvestigate packets drop\nSolve issues with libp2p versions (https://www.notion.so/Notes-423c72646a0944d1bd7889d7dec30bb4)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nContinued implementing lightpush tests\nDecided on way forward with direction refactor PR: Merge.\nLightpush SEGFAULT on publishing message over size limit; Issue\n\n\n\nvac:acz: §\n\nadmin/misc\n\nparticipate @ waku hackerhouse, ethindia\n\n\nrlnp2p:waku:rln-relay-enhancments\n\nassist in benchmarking rln tree onchain, report: https://github.com/waku-org/research/issues/72\n\n\nsecure-channels:waku:ethereum-chat\n\nFamiliarization with RFC9420 and RFC9180.\nConfection of several comparisons to get to SoA:\n\nTreeKEM vs ART.\nHPKE vs UPKE.\n\n\nWork on using Ethereum as Authentication Service.\nCreated a document about Farcaster’s Async Triple-Ratchet Protocol (WIP)\nResearching about Triple-Ratchet protocol from literature.\n\n\nzerokit:vac:maintenance\n\nresearched issue https://github.com/vacp2p/zerokit/issues/115\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nContinued researching Certora and formal verification\nreviewed old Certora specs\nExploring Requirements for Smart Contracts in a Privacy-preserving Environment (for logos research call)\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nResearched different L2 and Rollups focusing on privacy (Az, Pol, Zc, Nmd, Ada)\nReviewed Az Ugur’s doc\nDiscussed on Zc for a proposal model\nProduced a full doc on Pol architecture\nContinue with Verkle tree document for complexity estimates for various cases.\nWrote brief survey on (newer PCSs) (Pending upload): 1, 2, 3\nContinued reading VM SMT\nBegan reading towers over binary fields\nresearched how to update the public state by a private execution\nWorked on a proposal about a public state that we can update by a private TX\nRead about how Zcash update their public state\nCheck a paper about Zcash-like execution on Ethereum\n\n\nproofsystems:vac:benchmarks\n\nFixed comment for a PR for GWC implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/17\nFixed comment for a PR for SHPLONK implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/18\nFixed github issues on zk-explorations repo\n\n\nproofsystems:vac:research-existing-proof-systems\n\nWriting BaseFold writeup (https://eprint.iacr.org/2023/1705.pdf)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nseparate measurement for aggregation from attestation, block proposal, sync committee.\n\n\nvalpriv:vac:tor-push-paper\n\nShared to-be-submitted arxiv version\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted simulations for relatively large network (upto 6000 nodes with 50KB and upto 1000 nodes with 1MB messages), on DST test server\nResult analysis is complete. Looking into one anomaly (increased latency seen for approximately 1% nodes in Reduced Sending method)\nFinalizing graphs and results presentation\n\n\n\nvac:rfc: §\n\nwaku:waku-usage\n\nupdated waku-usage - https://github.com/vacp2p/rfc/pull/627\n\n\nwaku:waku-keystore\n\nUpdated waku-keystore, ready for feedback - https://github.com/vacp2p/rfc/pull/631\n\n\n"},"vac/updates/2023-12-18":{"title":"2023-12-18 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nSCTP:\n\nfix: the receive callback is now correctly setup\nfix: remove the send delay (using the nagle protocol)\ngetting stuck on a weird message received from the JS-libp2p\n\n\nDataChannel:\n\nfix: move readloop from accept to new\nTrying to changes multiple things in order to change the behaviour of JS-libp2p:\n\nreversing the initiators\ndelaying the noise handshake\nremoving the open stream\n\n\n\n\nall relevant nim-webrtc changes are here : https://github.com/status-im/nim-webrtc/pull/4\n\n\nnimlibp2p:vac:maintenance\n\nimprovement(ci): improve ci daily workflows - https://github.com/status-im/nim-libp2p/pull/1002\nMerge unstable into master - https://github.com/status-im/nim-libp2p/pull/1003\nReading about Zero Copy feature and looking for it on Chronos and Libp2p\nUpdate nim-libp2p version in Nimbus - https://github.com/status-im/nimbus-eth2/pull/5667\nFlood publishing - https://github.com/sigp/lighthouse/pull/4383 and https://github.com/libp2p/rust-libp2p/pull/\nchore: improve CI workflow stability https://github.com/status-im/nim-libp2p/pull/1004\nfix: make matrix include customizable for daily workflows https://github.com/status-im/nim-libp2p/pull/1000\nCI workflow is failing frequently PR 1004 is ready for review - Nimble lock for different Nim versions\nTest Case: FloodSub message size validation 2\n\nManaged to reproduce failure on computer when running isolated.\nDove into code, and pursued a couple possible threads.\n\n\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nCodex confirmed not able to followup on litepaper until 2024\nGeneral research of how comparable testnets run incentives for their net\n\n\nvac:tke::status:SNT-staking\n\nStaking contract depriortized by SC team\nUpdate John on initial findings on Waku sharding, sync on next steps roadmap discussion with Waku\nNo other priorities for SNT team at this time\n\n\nvac:tke::nomos:economic-analysis\n\nResearching leader selection and finality, impact on wealth concentration\nAdding statistical framework to define validator rewards (optimization function)\n\n\nvac:tke::waku:economic-analysis\n\nCall w/ Waku on incentives and revenue sources\nModeling the various proposed approaches to RLN\nReading and responding to Sergei’s latest incentivization documents\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nKeep investigating packets drop (https://www.notion.so/Results-2-eac3e52d512e469db57dc145aa65e603)\n\nCheck bandwidth per node with same rate and load (Correct)\nStrange behavior with 20MB/s on network.\n\n\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nImplemented filter unsubscribe tests\n\ncovers unsubscribe and unsubscribe-all APIs\nreached 92 interop tests\n\n\nIssues reported:\ngowaku: Strage error when retrieving messages\ngowaku: Reopened and closed again the log flood issue\nnwaku: Wrong response format to filter/v2/subscriptions\nnwaku: Relay publish regression\nInvestigated and figured out how to automate tests requested by the waku team\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nFinished lightpush tests\nPagingDirection Refactor PR\nFound one failing test when running test_all\n\nWakuNode2 - Validators::Spam protected topic accepts signed messages\nOnly happens when running literally all of them, not one specific.\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 5 tests related to lightpush - coverage improvement https://github.com/waku-org/go-waku/pull/957\nGot clarity on bug: unequal rules enforcement for contentTopic syntax https://github.com/waku-org/go-waku/issues/958\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nIncluded all materials related to MLS in the RFC\nImproved several aspects of the RFC (improve organization, delete some parts, etc)\nDiscuss difference of ADKG+DR and Asycn Triple-Ratchet algorithm from Farcaster.\nRead about repudiation term in messaging protocols and create a note about it.\nCheck the MLS report in Notion\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-maintenance\n\nDeployed CommunityTokenDeployer contracts on production networks\n\nMainnet, Arbitrum, Optimism\nDeployment addresses\n\nhttps://www.notion.so/Contract-Deployment-Addresses-d6dd98b1b4f6461d82eec6ab18b852c8\nPR: https://github.com/status-im/communities-contracts/pull/25\n\n\n\n\nInvestigated a bug in foundry that prevented us from signing transactions on ledger\n\nhttps://github.com/foundry-rs/foundry/issues/6516\n\nUse version mentioend in this issue for deployments via ledger for now\n\n\n\n\nstarted docs on new specs https://notes.status.im/JsEoWi8rSaqa-s3b2LCF5A?view\nstarted implementing the first new specs\nreview deployer contract properties doc https://notes.status.im/s/291mb-8nA\n\n\nvac:maintainance/misc\n\nCreated a multisig wallet for out team on Arbitrum (similar to the one on OP)\n\n\ncodex-token-tmp-milestone\n\nmeeting + adding ideas to https://docs.google.com/document/d/1lH6dPSuSzGIFmbJeaXNmx8cIU7dveI9KxE1rxdoKagQ/edit#heading=h.f8xnzmojer6t\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nReadings on privacy-focused models (Az, Nmd, Zc, Ada, Ola)\nBrief notes on Hyperproofs\nNotes on Ring Signatures\nRead paper on security for UTXO based on DAGs; notes after meeting.\nResearch miblewimble (goal 1)\nReviewed Halo2 PR’s GWC and SHPLONK\nNote about the similarities and differences Az and Pol\nRead about Zcash from its whitepaper section 3.4 Transactions and Treestates, and investigate how a shielded address can generate a public balance.\n\n\nproofsystems:vac:research-existing-proof-systems\n\nfinished BaseFold writeup\nstarted researching Arecibo (https://blog.lurk-lang.org/posts/arecibo-supernova/)\n\n\nproofsystems:vac:benchmarks\n\nStarted a refactoring for halo2 PRs https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\ntested sync role success, gathered aggregated message latency, tested alltorbroadcast for all validator messages\n\n\nvalpriv:vac:tor-push-paper\n\nRevised graphs with std dev/mean, added inclusion difference\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted simulations and results and analysis/presentation for all test scenarios.\nArticle writeup is almost complete (will be concluded by today)\n\n\n\nvac:rfc: §\n\nadmin/misc\n\nCreated pr for a few 1/COSS changes\n\nProposal for description - https://github.com/vacp2p/rfc/pull/645\nProposal for adding github names - https://github.com/vacp2p/rfc/pull/644\nProposale for draft delete - https://github.com/vacp2p/rfc/pull/654\n\n\nUpdated store link and formats - https://github.com/vacp2p/rfc/pull/653\nUpdated usage - https://github.com/vacp2p/rfc/pull/627\n\n\n"},"vac/updates/2023-12-25":{"title":"2023-12-25 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nFixing bumper jobs - https://github.com/status-im/nim-libp2p/issues/1005\nRemove rules related to Nim 1.2 jobs from master branch on github settings\nReading and Understanding\n\nDisable flood publishing https://github.com/sigp/lighthouse/pull/4383\nMore lenient flood publishing https://github.com/libp2p/rust-libp2p/pull/3666\nTesting latency on different flood publish strategies https://github.com/sigp/gossipsub-testground/pull/15\ntesting gossipsub(flood publish) with quic https://github.com/ackintosh/gossipsub-testground/p\n\n\nCase 'FloodSub message size validation 2':\n\nIssue: Combination between message size and timeout; Big message size takes a big time, and sometimes exceeds timeout\nStill begs the question: “Why it passed when running the full suite instead of the isolated test\n\n\n\n\n\nvac:tke: §\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nKeep investigating packets drop (https://www.notion.so/Results-3-43142115f7764d3ca9954490f232b242)\n\nCreated same test node with Rust (borrowed some time from Alex)(https://github.com/vacp2p/dst-gossipsub-test-node-rust/tree/master)\n\nGot some preliminary results (https://www.notion.so/Results-Rust-011fb77dea4b482ba8283f1adb762c9c)\n\n\n\n\nsync with p2p team regarding weird behavior\nUse iperf to create artificial bandwidth and keep investigating (Done, no package drop).\n\n\nadmin/misc\n\nhiring\n\n\nvac:dst:software-testing:waku:test-automation-js-waku\n\nInvestigated and helped fixing js-waku tests that failed with latest nwaku\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nImplemented the idle subscription tests requested by the nwaku team + multi-node filter tests: PR\nIssues reported:\n\nhttps://github.com/waku-org/go-waku/issues/967\nhttps://github.com/waku-org/go-waku/issues/968\nhttps://github.com/waku-org/go-waku/issues/969\nhttps://github.com/waku-org/go-waku/issues/970\nhttps://github.com/waku-org/go-waku/issues/971\nhttps://github.com/waku-org/go-waku/issues/972\nhttps://github.com/waku-org/nwaku/issues/2315\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nTest failure\n\nInvestigate\nIssue\n\n\nMerge\n\nDirection refactor\n\nPR\n\n\nStore Tests\n\nPR1\nPR2\n\n\nLightpush Tests\n\nPR\n\n\n\n\nImplemented autoshard tests\n\nMissing one. Asked about how to mock.\n\n\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nWorked on Ethereum as Authentication Service. (https://www.notion.so/WiP-Ethereum-based-Authentication-cb7b0ff07ba74886847ec8e23e8a7a62)\nSpecification for the MLS in our setting. (https://github.com/vacp2p/rfc/blob/master/content/docs/rfcs/70/README.md)\nRFC updates: ADKG + DR removed and replaced with MLS.\n\n\n\nvac:sc:: §\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nFinished researching Az, Pol, Ola\nContinue readings on privacy-focused models (Nmd, Zc)\nLooking at privacy related questions for UTXO\nContinue with binary towers paper\nContinued research on mimblewimble.\nRead HEX-Bloom\nRead NOTRY; this paper deals with messaging, but has an interesting property in their scheme called avowal and proof of non-knowledge.\nWork on propsal about the private execution that affects public state and start to write it.\nRead a paper about the proposal\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted article writeup for GossipSub scaling for large messages\n\n\n\nvac:rfc: §\n\nwaku:waku-keystore\n\nMade changes based on feedback for waku-RLN-keystore - https://github.com/vacp2p/rfc/pull/631\n\n\nadmin/misc\n\nRead waku2 specs, message, filter, store, payload - https://rfc.vac.dev/spec/10/\nread libp2p docs to prepare for excutable specs of waku2 node\n\n\n"},"vac/updates/2024-01-01":{"title":"2024-01-01 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/01 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance:\n\nCase 'FloodSub message size validation 2':\n\nRun tests in different mac envs: VM: Failure; M2: Success\nThe previous tests support the hypothesis this is timeout/cpu-power related\n\n\nOther flaky tests?\n\nEither the previous VM or M2 didn’t find any other failing tests (just one attempt, though):\n\ntestpubsub: Only 'FloodSub message size validation 2' fails.\ntestdaemon: Stuck after a couple logs regarding IPs.\ntestnative: Success\n\n\n\n\n\n\n\nvac:tke: §\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nFixed behavior issues in Rust node (https://github.com/vacp2p/dst-gossipsub-test-node-rust)\nSimulation results (https://www.notion.so/Results-Rust-011fb77dea4b482ba8283f1adb762c9c)\nPython libp2p is not stable (https://libp2p.io/implementations/), and with no changes from the last 6 months. Not using for comparisons.\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nImplemented the filter push/get messages and filter ping tests: PR\nIssues reported:\n\nhttps://github.com/waku-org/nwaku/issues/2319\nhttps://github.com/waku-org/nwaku/issues/2320\nhttps://github.com/waku-org/nwaku/issues/2322\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nCreate Autosharding Tests PR\n\nPR\n\n\nInvestigate and add simple mocking mechanism\nBegin working in Connection Peer Management Tests\n\nPR\n\nDone: Migrations, PeerStorage\nIn Progress: Protobuf Serialisation, WakuPeerStorag\n\n\n\n\n\n\n\nvac:acz: §\nvac:sc:: §\nvac:nescience: §\n\nproofsystems:vac:research-existing-proof-systems\n\nconitinued researching Arecibo (https://blog.lurk-lang.org/posts/arecibo-supernova/)\nStarted reading CycleFold (https://eprint.iacr.org/2023/1192.pdf)\n\n\nproofsystems:vac:benchmarks\n\nprepared Halo2 common PR (https://github.com/vacp2p/zk-explorations/pull/23)\nWorked on a refactoring for halo2 PRs https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21\n\n\nstate-separation:vac:state-separation-doc\n\nContinue with mimblewimble\nResearch Ugur’s idea\nRead about private and public kernel circuits from Az.\nFinish the research about how we can update public state with a private execution.\nUpdate the proposal because last version is not applicable.\n\n\n\nvac:dr: §\nvac:rfc: §\n\nwaku:waku-keystore\n\nUpdated keystore to be more descriptive for some sections. Ready for feedback - https://github.com/vacp2p/rfc/pull/631\n\n\nadmin/misc\n\nWorked on implementing 14/WAKU2-MESSAGE for excutable spec\n\n\n"},"vac/updates/2024-01-08":{"title":"2024-01-08 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/08 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance:\n\nflaky tests: trying out a hypothesis about runners specs\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nUpdate Notion and Tokenomics Design Canvas (TDC) for Codex (@Matty)\nAdd new Collateral Insurer role to litepaper\nFollow up with Codex on litepaper feedback and next steps for testnet incentive design and token allocation\n\n\nvac:tke::status:SNT-staking\n\nUpdate Notion and TDC for SNT (@Matty)\nFollow up with John on Wednesday call for 2024 Status plan\n\n\nvac:tke::nomos:economic-analysis\n\nClean up Nomos Notion and update TDC (@Frederico)\nFinish agent based simulations on wealth concentration impacted by leader selection\nRead darkpaper when Nomos team has finished incorporating team comments and can share (expect it this week)\n\n\nvac:tke::waku:economic-analysis\n\nClean up Waku Notion, and create a best thinking draft of TDC (@Martin)\nFinalize and share L2 overview with Waku business model meeting Tue\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nGather all data from Kubernetes and create document with plots (https://www.notion.so/Nim-Rust-comparison-9dc4e4c3c0914773971608e8af911943)\nCompare nim, rust and waku bandwidth, packet and times.\nEnd of the week got stucked because some Kubernetes issues. They are fixed now\nRan some gowaku simulations. Results differ a lot from nwaku (half bandwidth, no packet loss).\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nRetested some fixes\nFixed tests related to 1MB message\nRemoved deprecated RPC protocol and cleaned up the code\nInvestigated with Prem some node connection issues/regression\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nclarified testing priorities with Waku:\n\nRLN\nPeer Exchange\nDiscv5\nPeer Connection Management\n\n\nOpen Issue [bug: SqliteDriver WakuMessage attribute saving]\n\nAfter further investigation with Ivan we decided it behaves as expected\nIssue\n\n\nLightpush\n\nUpdated PR with comments PR\n\nBlocked until SEGFAULT solved\n\n\n\n\nAutosharding\n\nImplemented and merged tests PR\nRequested help for overloaded function mock test case PR; Nim Forum\n\n\nPeer Connection Management\n\nImplemented and merged tests PR\nThorough investigation on module types and base58\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 10 test to improve store tests coverage https://github.com/waku-org/go-waku/pull/993\nGo-Waku node operations on Pi 4 (hobby activity)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\ncontinue work on proof of concept for state transition proof for onchain roots in rln: https://github.com/vacp2p/rln-contract/issues/32\n\n\nsecure-channels:waku:ethereum-chat\n\nCreated a 4-step approach for Ethereum as Authentication Service article\n\n\n\nvac:sc:: §\n\ncodex:codex-airdrop-contract-exploration\n\nadd possible token airdrop solutions https://docs.google.com/document/d/1lH6dPSuSzGIFmbJeaXNmx8cIU7dveI9KxE1rxdoKagQ/edit#heading=h.f8xnzmojer6t\n\n\nstatus:community-contracts-maintenance\n\nstart implementing the first new specs based on https://notes.status.im/JsEoWi8rSaqa-s3b2LCF5A?view\nreview deployer contract properties doc https://notes.status.im/s/291mb-8nA\n\n\n\nvac:nescience: §\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished researching Arecibo (https://blog.lurk-lang.org/posts/arecibo-supernova/)\nStarted writing CycleFold writeup (https://eprint.iacr.org/2023/1192.pdf)\n\n\nproofsystems:vac:benchmarks\n\nContinued working on a refactoring for halo2 PRs https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21\nReviewed halo2-common PR\n\n\nstate-separation:vac:state-separation-doc\n\nDiscuss UTXO/Merkle on discord\nReviewd literature concerning pruning Merkle trees in Bitcoin and other UTXO systems; mentioned in the original white paper but never implemented due to issues with history.\nDiscuss recursiveness of Nova\nWork on notes for mimblewimble (pending upload)\nFinish the first version of the report about how we can update public state with a private execution, here is the report.\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nInvestigated the latency spikes issue with floodpublish for large messages. The problem was small TCP cwnd at start of connection, same is the case with floodpublish peers, and latencies accumulate for multi-hop paths\n\nSending dummy data immidiately after connection setup resolves the problem.\nHowever, this can make peers vulnerable to buffer overflow attacks\n\n\n\n\n\nvac:rfc: §\n\nmisc\n\nCreated 14/WAKU2-MESSAGE update pr - https://github.com/vacp2p/rfc/pull/655\nStarted waku excutables spec document - https://github.com/vacp2p/rfc/blob/waku2-excutables/content/docs/rfcs/11/executable/README.md\ndraft pr for content topics clarity, this may not be necessary - https://github.com/vacp2p/rfc/pull/656\n\n\n"},"vac/updates/2024-01-15":{"title":"2024-01-15 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/15 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDatachannel\n\nInvestigate on why the js-datachannel handshake work, but not the channel creation\n\n\nSCTP\n\nFind an issue with sctp_recv\nWe didn’t get sctp_recvinfo mandatory for the datachannel\nCould be a similar cause on why js-datachannel doesn’t receive our data\n\n\nCreate an SCTP message decoder\n\n\nnimlibp2p:vac:maintenance\n\nAdd comments to Yamux https://github.com/status-im/nim-libp2p/pull/1006\nTried timeout hypothesis for tests\n\nTests didn’t fail, but given they’re flaky, is not evidence enough; Merge and see how that impacts builds.\n\n\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nReading https://github.com/libp2p/rust-libp2p/pull/4914, https://github.com/libp2p/rust-libp2p/issues/4667\nTrying to understand their implementation and how we can implemente something similar in nim-libp2p\nReading about TCP slow start and initial window\n\n\nmisc/admin\n\nHelp with nim-unittest2 https://github.com/status-im/nim-unittest2/pull/35\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\non hold until Matty is back form holidays\n\n\nvac:tke::status:SNT-staking\n\nUpdate Notion and TDC for SNT (@Martin)\nFollow up with John on Tuesday call for 2024 Status plan\nStaking contract revision due to rework from Pascal (@Martin)\n\n\nvac:tke::nomos:economic-analysis\n\nClean up Nomos Notion and update TDC (@Frederico)\nFinish agent based simulations on wealth concentration impacted by leader selection (@Frederico)\nRead darkpaper when Nomos team has finished incorporating team comments and can share (expect it this week)\n\n\nvac:tke::waku:economic-analysis\n\nfocus research on sustainability, compare different models (@Martin)\nprepare for meeting with Matt Nemmer (@Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nAdd 3rd machine to simulations and get more plots.\n\nInvestigate weird results\n\n\nInvestigate if results from go-waku are correct.\nCreate a simple node with go-libp2p\n\n\n\nvac:qa: §\n\nsoftware-testing:waku:test-automation-interop-testing\n\nBugfix testing and fixed tests related to maximum subscription count(@Florin)\n\n\nsoftware-testing:waku:test-plans\n\nPeer & connection management test plan(@Florin)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nStarted working on RLN test coverage(@Alex)\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nRLN tests coverage(@Roman)\nFixed minor bug(@Roman)\n\n\n\nvac:acz: §\n\n\nrlnp2p:waku:rln-relay-v2\n\nPatched rln-contract with foundry template - https://github.com/vacp2p/rln-contract/pull/34\nrln-v2 branch on rln-contract - https://github.com/vacp2p/rln-contract/pull/35 (deployed to sepolia and polygon zkevm testnet)\nPlanning for rln-v2 in nwaku - https://github.com/waku-org/nwaku/issues/2345\n\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nPrepare presentation for logos research call\n\n\n\nsecure-channels:waku:ethereum-chat\n\nImproving parts of the RFC. (https://github.com/vacp2p/rfc/blob/master/content/docs/rfcs/70/README.md)\nStudy of SIWE (EIP-4361) as an authentication solution. (https://www.notion.so/WiP-Ethereum-based-Authentication-cb7b0ff07ba74886847ec8e23e8a7a62)\nKept working on Quarantined TreeKEM.\n\n\n\nsecure-channels:waku:ethereum-chat\n\nRead about SIWE and extracting some questions about the usage of it.\n\n\n\nmisc\n\nAdded FFI bindings to stealth commitment implementation in rust - https://github.com/rymnc/erc-5564-bn254/commit/9ecb6cf53ce49e638ce0de2e50d06a5e2ed2c487\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-maintenance\n\nImplemented Certora rules as preparation for the upcoming Certora training\nIntroduced script to run multiple certora specs\nAdded implemented rules to PROPERTIES.md\n\nhttps://github.com/status-im/communities-contracts/pull/26\n\n\n\n\nstatus:snt-staking-contract-maintenance\n\nFixed a bug that prevents unstaking from actually working\n\nhttps://github.com/logos-co/staking/pull/41\n\n\nAdded tests for some basic staking functionality, ensuring multiplier points are minted and point correctly\n\nhttps://github.com/logos-co/staking/pull/42\nhttps://github.com/logos-co/staking/pull/43\n\n\n\n\nmaintenance/misc\n\nSepolia SNT now bridgable to OP Sepolia\n\nhttps://github.com/ethereum-optimism/ethereum-optimism.github.io/pull/591#event-11423844729\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nExtensive research on privacy-focused models (@Moudy) and existing techniques (@Marvin)\nGeneral research on how to handle order of execution and calling to integrate in the proposal\nUpdated Notion with Explication Notes @Moudy and State Update @Ugur\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on revised results for GossipSub Improvements paper. Completed for TCP cwn and IDONTWant (Still to do for staggered sending)\nWorked on latency spikes issue for FloodPublish\n\n\n\nvac:rfc: §\n\nmisc\n\nStarted working on new RFC for stealth commitments - https://github.com/vacp2p/rfc/pull/658\nMerged - https://github.com/vacp2p/rfc/pull/653\nFixed last week’s blocker, trouble running py-libp2p\n\n\nwaku:waku-keystore\n\nMade changes based on feedback - https://github.com/vacp2p/rfc/pull/6\n\n\n"},"vac/updates/2024-01-22":{"title":"2024-01-22 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/22 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFind/investigate a bug with usrsctp not sending the correct messages.\n\n\nnimlibp2p:vac:quic\n\nInvestigate what we need to implement: mainly wrap DTLS 1.3\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nmake forward (relay) messages non priority - https://github.com/status-im/nim-libp2p/pull/100\n\n\nnimlibp2p:vac:maintenance:\n\n“Timeout increase” approach to fix some of the flaky timeout tests\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nadd insurer role to the litepaper (@Matty)\nmake sure litepaper is up-to-date (address comments, etc.) (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nget general plan from John on Tuesday (@Martin)\nreview litepaper and TDC (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nClean up Nomos Notion and update TDC (@Frederico)\nFinish agent based simulations on wealth concentration impacted by leader selection (@Frederico)\nRead darkpaper when Nomos team has finished incorporating team comments and can share (expect next week)\n\n\nvac:tke::waku:economic-analysis\n\nprepare for meeting with Matt Nemmer (@Martin)\nresearch around sustainability model following Franck post (@Martin)\nwork on L2 discussion with Cyprien (@Martin)\nreview litepaper and TDC (@Matty)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nInvestigate 3 machine results\nFinish go-libp2p node and get simulation results\n\nhttps://www.notion.so/Nim-Rust-Go-comparison-9dc4e4c3c0914773971608e8af911943\n\n\n\n\n\nvac:qa: §\n\nvac:qa:software-testing:waku:test-automation-js-waku\n\nFixed tests related to content topic limit update PR1 and PR2(@Florin)\n\n\nvac:qa:software-testing:waku:test-plans\n\nDiscv5(@Florin)\nPeer exchange(@Florin)\n\n\nvac:qa:software-testing:waku:interop-testing\n\nNightly go and nim interop workflows reporting to WAKU/DEV/test-reports discord channel(@Roman)\nAdjusted tests and marked known failures with xfail so the nightly reports look better(@Florin)\n\n\nvac:qa:software-testing:waku:test-automation-nwaku\n\nImproved RLN tests: Node and Group Manager(@Alex)\n\n\nvac:qa:software-testing:waku:test-automation-go-waku\n\nImproved RLN unit tests coverage(@Roman)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\nPresent rln-v2 and v3 at logos research call\n\n\nzerokit:vac:maintenance\n\nAttempted integrating circom-witness-rs into zerokit for faster witness generation, realized that a few operations, bitand and shr are not implemented.\n\n\nmisc\n\nrln-v3 proposal doc - https://hackmd.io/@rymnc/rln-v3-proposal (linked in notion as well - https://www.notion.so/RLNP2P-e2865a91b50d4928b2e8d14916adb586)\n\n\nsecure-channels:waku:ethereum-chat\n\nInclusion of SIWE in the RFC (deprecation of the NIZK approach).\nPreparation of internal notes on Quarantined TreeKEM.\nCheck the subprotocol and algorithms of RFC for the implementable of the RFC in notion\n\n\nzerokit:vac:maintenance\n\nworked on a workaround for https://github.com/vacp2p/zerokit/pull/224\n\n\n\nvac:sc:: §\n\nstatus:snt-staking-contract-maintenance\n\nAnalyzed application properties for formal verification together with Tokenomics team\n\nNotes https://notes.status.im/rA5eYiLlSYWDDLnaXRfPdg?both\n\n\nMerged pending bugfix a test PRs\n\nhttps://github.com/logos-co/staking/pull/41\nhttps://github.com/logos-co/staking/pull/42\nhttps://github.com/logos-co/staking/pull/43\nhttps://github.com/logos-co/staking/pull/44\n\n\n\n\nstatus:community-curation-contracts\n\nDeployed community curation dapp contracts on Optimism Sepolia\n\nPR with deployment config\n\nhttps://github.com/status-im/community-dapp/pull/107\n\n\n\n\n\n\n\nvac:nescience: §\n\nvac:nes:state-separation:vac:state-separation-doc\n\nFinished researching Privacy-focused models and Update notion with two different documentations: Ola and Namada\nReviewed and researched the Private State Update proposal and Update notion with an extended document for requirements\nMade a decision for milestones and how to achieve them (Add link), more info will be in the milestone document\nFinish up loose ends for Mimblewimble, Verkle tree notes (additions/deletions)\nBegin research on signature verification (Shielded)\nAdded a report about The Functions’ Order of Calling and Execution(WIP) in notion\nExplored the complexity side of the shielded-deshielded execution arhitecture\n\n\nvac:nes:proofsystems:vac:research-existing-proof-systems\n\nContinued writing CycleFold writeup (https://eprint.iacr.org/2023/1192.pdf)\n\n\nvac:nes:proofsystems:vac:benchmarks\n\nExperimented with Arecibo\nFixed comments on refactoring PR\nMade a decision for milestones, more info will be in the milestone document\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nWorked on staggered message sending issue (Used the newly implemented message queuing support).\n\nTesting and finalizing the code. Will finish by tommorrow.\n\n\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegin going through list of needs in terms of current design and design document\n\n\n\nvac:rfc: §\n\nmisc\n\nWorked on stealth commitments RFC, communicated with Aaryamann - https://github.com/vacp2p/rfc/pull/658\nWorked on Waku2 message update - https://github.com/vacp2p/rfc/pull/655\nrevisited website checked changes, looks ready\n\n\nwaku:waku-keystore\n\nWas approved by Aaryamann - https://github.com/vacp2p/rfc/pull/631\n\n\n"},"vac/updates/2024-01-29":{"title":"2024-01-29 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/29 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFix some bugs related to our way of debugging\nDeep dive into JS js libp2p for interop testing\nworking on figuring out why the noise handshake is blocked by the JS\n\n\nnimlibp2p:vac:maintenance\n\nHelp Waku with a websocket issue\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\ncont’ work on making forward messages non priority - https://github.com/status-im/nim-libp2p/pull/1009\n\n\n\nvac:tke: §\n\ncodex:economic-analysis\n\nadd insurer role to the litepaper (@Matty)\nmake sure litepaper is up-to-date (address comments, etc.) (@Matty)\n\n\nstatus:SNT-staking\n\nget general plan from John on Tuesday (@Martin)\nreview litepaper and TDC (@Matty)\n\n\nnomos:economic-analysis\n\nClean up Nomos Notion and update TDC (@Frederico)\nFinish agent based simulations on wealth concentration impacted by leader selection (@Frederico)\nRead darkpaper when Nomos team has finished incorporating team comments and can share (expect next week)\n\n\nwaku:economic-analysis\n\nprepare for meeting with Matt Nemmer (@Martin)\nresearch around sustainability model following Franck post (@Martin)\nwork on L2 discussion with Cyprien (@Martin)\nreview litepaper and TDC (@Matty)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nTalk with p2p team about control messages; Found error in compilation\nAdd queue metrics data to Prometheus/Grafana\n\nDo simulations and check this metric\nMetrics are scrapped but building is failing\n\n\nPushed go-waku in kubernetes\n\n“Reached” 2k nodes, but there is a huge packet loss and latency times. Didn’t try more because it was consuming 1Gig of Bandwidth, and didn’t want to get the servers blocked again.\n\n\n\n\nadmin/misc\n\nPrepare onboarding new team member\n\n\n\nvac:qa: §\n\nsoftware-testing:waku:test-plans\n\nRLN test plan(@Florin)\nRLN issues found:\n\nSpam messages not dropped(@Florin)\nPostgres error regression(@Florin)\nRelayed messages are not stored(@Florin)\n\n\nKEYSTORE_PASSWORD env variable issue(@Roman)\nRLN meeting discussion(@QA_Team)\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nRemove dependency on hardcoded private keys for Ganache(@Roman)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nPrepared local dev enviroment(@Roman)\nRLN\n\nImplemented more RLN tests PR(@Alex)\nFound unintended behaviour where RLN wasn’t enabled for all intended topics(@Alex)\n\n\nAutosharding\n\nReview and discard mock-related PR(@Alex)\n\n\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\ndownstreamed rln-v2 to waku-rln-contract: https://github.com/waku-org/waku-rln-contract/pull/11, with full test coverage\nremoved websocket dependence from waku-rln-relay: https://github.com/waku-org/nwaku/pull/2364 (improves robustness, pre-requisite for rln-v2 integration)\n\n\nsecure-channels:waku:ethereum-chat\n\nCompletion of the internal notes on Quarantined TreeKEM\n(https://www.notion.so/WiP-Notes-on-the-MLS-protocol-cccc3faad97b4c00ae88bdec40f58e1e)\nImprovements on the RFC. RFC ready (review required). (https://github.com/vacp2p/rfc/blob/master/content/docs/rfcs/70/README.md)\nDetect two possible gaps against the implementation one is xed448 in and Quarantined TreeKEM in Rust\n\n\nzerokit:vac:maintenance\n\nfixed some infallible conversions: https://github.com/vacp2p/zerokit/pull/229\nstumbled upon rayon issue here https://github.com/vacp2p/zerokit/issues/55, read rayon docs, trying to find a solution\n\n\n\nvac:sc:: §\n\nadmin/misc\n\non-site Certora training\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nDefined the new Roadmap including different tasks and deadlines\nResearched signature verification and Adress hiding in (Shielded and Deshielded) executions (Marvin)\nResearched Deshielded and Shielded execution vs. different approaches to define and expand the proposal (Moudy)\nIdentified security issues on the combination of SE and DE and proposed possible salt mechanism as a possible solution to the issue (WIP)(Uugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished writing CycleFold writeup (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nExplored Arecibo and started updating the documentation (Moudy)\nExplored the 2 different Halo2 implementation variants and started updating the documentation (Moudy)\nResearched adn explored how recursion works in different ZKP we are benchmarking (Moudy)\nFinished working on a refactoring for [halo2 PRs](https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21) (Rostyslav)\nGot refactoring [halo2 PRs](https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21) merged (Rostyslav)\nStarted working on arecibo benchmark (Rostyslav)\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nUsed newly implemented queues (with event fire) to form weighted queues. But event fire mechanism results in much higher delays\nTrying to enable weighted queue forwarding to support message staggering\n\n\n\nvac:rfc: §\n\nmisc\n\nWorked on new RFC index repo - https://github.com/vacp2p/rfc-index/pull/1\nWaku message update ready for review - https://github.com/vacp2p/rfc/pull/655\nStarted waku v2 (spec 10) update - https://github.com/vacp2p/rfc/pull/661\n\n\n"},"vac/updates/2024-02-05":{"title":"2024-02-05 Vac weekly","links":["tags/head"],"tags":["vac-updates","head"],"content":"Vac 2024/02/05 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFix a bug in Datachannel.read (reading the last message received instead of the first one)\nFix a bug due to an Sctp delay (set it to 0ms was the solution)\nFind a bug in the conception of WebRTCStream. ReadOnce should be Length-prefixed.\n\ntry to fix it by re-writing ReadOnce, but due to the nature of this proc (inheritance issue) it doesn’t work\nwrite a RawWebRTCStream to make the length readable without issue\n\n\nFix a bug with the endianness of the datachannel protocol id\nE2E Done!\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nfeat: make relayed messages non priority (don’t use an explicit queue for priority msgs) - https://github.com/status-im/nim-libp2p/pull/1015\nfeat: drop msgs to be relayed waiting for too long in the queue - https://github.com/status-im/nim-libp2p/pull/1015\n\n\nnimlibp2p:vac:maintenance\n\nInvestigate dependencies issues\n\nFound possible problem/s\n\nLack of versioning\nNo major version clamping\nUsing#head\n\n\nTemporary workaround: Clamp/Pin (to git hash) libp2p dependencies’ versions\n\nPR\n\n\n\n\nImprove documentation [In Progress]\n\nBuilding go-libp2p-daemon\nGetting Started\nPR\n\n\nMerge timeout increase\nImproved checkExpiring\n\nNow it’ll outpout an error message when it fails due to timeout\n\nNot the most visible message\n\n\n\n\n\n\n\nvac:tke: §\n\nadmin/misc:\n\nMatty Handoff document finished and share with team on Wed (@Matty)\nTeam Lead Evaluation Criteria finished and share with team on Wed (@Matty)\nStrengths and development areas for Frederico and Martin, shared with Corey, Daniel, and Jarrad (@Matty)\n\n\ncodex:economic-analysis\n\nfinalize all Codex notion including Dragan’s comments to litepaper (@Matty)\nWednesday call with Codex team get in sync on next steps\n\n\nstatus:SNT-staking\n\nstaking contract implementation becoming a priority, refresh latest progress with SC team (@Martin)\n\n\nnomos:economic-analysis\n\nReading whitepaper and updating TDC (@Frederico)\nPorting wealth concentration simulation code to GPU to decrease runtimes (@Frederico)\n\n\nwaku:economic-analysis\n\nContinue Waku Network of Networks design discussion with Franck, concerns around forking (@Martin)\nResearch similar abstract p2p validation protocols (e.g. former Keep Network)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nTry to get a stable nim-libp2p version for simulations. Investigated with Alex about building issues with nimble.\nAnalized libp2p metrics, everything normal so far\ncall with p2p team\nScale testing for 10K project\n\nsetup go-waku experiment at scale\nSuccessfully simulated a 2,150 node simulation and gathered some basic metrics\nModified Kubernetes to allow for more pods to allow for (in theory) scaling to 10k+\nFailed simulations at 10000 and 5000 nodes - current limits seem to be around ~4800 or so\nPrometheus is a definite bottleneck - need to switch to a scaled/sharded Prometheus/Thanos setup\nAttempting one last simulation over the weekend at 4200 nodes\n\n\nDiagnosing 10K project bottlenecks\n\nIdentified a major potential bottleneck in the form of control plane traffic going over Wireguard / large packet load over WG causing swarm collapse\nwill test the new theory later by re-deploying on Vac Kubernetes with a local control plane + local traffic (while still complying with infra team requirements)\n\n\n\n\n\nvac:qa: §\n\nsoftware-testing:waku:test-plans\n\nSharding test plan(@Florin)\n\n\nsoftware-testing:waku:interop-testing\n\nRelayed messages reach recently started peer with a big delay(@Florin)\nRLN registration support and tests(@Roman)\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nReviewed remaining work and added summary and approach(@Roman)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nClean and work with Gabriel to verify fix(@Alex)\nReview lighpush fixes and adjust unit tests(@Alex)\n\nLearned how to generate coverage report for NWaku and prepared small PR to have a shortcut(@Roman)\n\n\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nrln-v1 to v2 commitment migrator: https://github.com/waku-org/waku-rln-contract/pull/11/commits/886891b57ae54e439563023dd50161fec5ee29f1\nuse rln-v2 contract in nwaku: https://github.com/waku-org/nwaku/pull/2381\nupdate c ffi bindings and serde in nwaku: https://github.com/waku-org/nwaku/pull/2385 (issues: https://github.com/waku-org/nwaku/issues/2378 and https://github.com/waku-org/nwaku/issues/2377)\nuse rln-v2 in registration and membership insertion mechanism: https://github.com/waku-org/nwaku/pull/2392 (wip)\n\n\nsecure-channels:waku:ethereum-chat\n\nRFC updating, following comments and suggestions.\nDiscussion of use cases for the secure messaging protocol\nSearch and investigate existing secure messaging apps\n\n\nzerokit:vac:maintenance\n\nworked on a workaround for this issue https://github.com/vacp2p/zerokit/issues/55\n\n\n\nvac:sc:: §\n\nstatus:snt-staking-contract-maintenance\n\nReview Certora work\nPR https://github.com/logos-co/staking/pull/47\nWorking on solutions for Staking Contact issues https://notes.status.im/lNd8kcVmQEWcDYEldpl26Q\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nCompleted research on SE and DE focusing on security issues while combining both models (Moudy)\nRewrote a full version of state update proposal for security and privacy threats (Moudy)\nResearched address hiding and signature verification and wrote a proposal for address hiding and signature verification (Marvin)\nAdded a report about the security issue and a possible solution(salt mechanism) and investigated about the security of the SE/DE (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStarted looking at Reverie whitepaperand BaseFold implementation (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nFinished working on arecibo benchmark (Rostyslav)\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted message staggering in the form of weighted message queues\n\nIts showing 10% better result than priority queuing, but Async Queue overhead still requires some work\n\n\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegin reviewing Range Proof example\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nworked on rfc-index adding rest of rfc, fixing links, and chaging headers - https://github.com/vacp2p/rfc-index/pull/1\nworked on waku/specs adding rfcs - https://github.com/waku-org/specs/tree/waku-RFC\n\n\n"},"vac/updates/2024-02-12":{"title":"2024-02-12 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/02/12 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nCleaning / commenting\nImplementing the client side of SCTP\nImplementing the closing part of SCTP / DataChannel\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nMaking it ready to be merged - https://github.com/status-im/nim-libp2p/pull/1015 (feat: message prioritization with immediate peer-published dispatch and queuing for other msgs)\n\n\nnimlibp2p:vac:maintenance\n\nimprovement: enhanced checkExpiring macro with custom timeout - https://github.com/status-im/nim-libp2p/pull/1023\nLog checkExpiring failure\n\nPR\n\nMerged\n\n\n\n\nAdded suggestions to building documentation\n\nPR\n\n\nGathered all dependencies modifications in the same PR\n\nPR\n\n\n\n\n\nvac:tke: §\n\nnomos:economic-analysis\n\ntested a new data layout for the PoS-GPU code (to allow a large number of blocks per epoch);\nimplemented a CPU-only code that outperformed the GPU (thanks to a trick given by David and Alexander);\nran simulations about wealth concentration and observed leader election on Cryptarchia.\n\n\ncodex:economic-analysis\n\nreviewed comparables tokenomics (Filecoin);\nreviewed the state of CDX token, inc. insurance model.\n\n\nwaku:economic-analysis\n\nreviewed Martin’s work on RLN pricing\n2x Waku RLN calls (Tokenomics, L2 for RLN) and follow-ups\n\n\nstatus:SNT-staking\n\ncontinuing work on Status DeFi analysis\ncontinuing work on Status staking contract\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nTalk again with p2p team about versioning\nDone simulations for Yamux\nRe-do simulations without using Wireguard. Packet loss is the same if not even higher (?)\nPlan how to structure the 10k tool framework\nOptimized publisher and added a debug flag to get DNS resolve times.\nBriefly ran a full 10K scale simulation, as well as other simulations at 7.5K, 8K, 5K and 0.1K\nScaled metrics up by sharding it then adding Thanos (via bitnami charts) Query and Thanos Query Frontend to aggregate the metrics\nDealing with various scaling issues as they come up\nAdded latency delay to pods, allowing us to do arbitrary amounts of latency in Waku nodes\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nRLN registration support and tests(@Roman + @Florin)\nAutomatically notify nwaku developes when nightly interop tests fail(@Florin)\n\n\nwaku:test-automation-js-waku\n\nConnection and peer management new tests and refactoring(@Florin)\n\n\nwaku:test-automation-nwaku\n\nLighpush fixes(@Alex)\n\nPeer Exchange tests(@Alex)\n\n\nUpdate QA milestones(@Florin)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nuse rln-v2 in registration and membership insertion mechanism: https://github.com/waku-org/nwaku/pull/2392\nrln-v2 nonce manager: https://github.com/waku-org/nwaku/issues/2415\n\n\nsecure-channels:waku:ethereum-chat\n\nKeep working in the updates of the RFC.\nStart writing the blog article about the SMP, with the use cases and the main features in mind.\nCreation of an Overleaf project on secure channel setup with Ethereum.\nCheck two SoK papers for comparison security mechanism; paper1 paper2\nStudy the security mechanisms of dm3, Tor Messenger and Briar.\nStart an internal report comparing different messaging protocols.\n\n\nzerokit:vac:maintenance\n\nresearched this issue https://github.com/vacp2p/zerokit/issues/21\n\n\nmisc\n\nOpened PRs to implement bitand & shr in circom-witness-rs: https://github.com/philsippl/circom-witness-rs/pull/14 & https://github.com/philsippl/circom-witness-rs/pull/13\n\n\n\nvac:sc:: §\nvac:rfc: §\n\nmisc\n\nWorked waku/specs repo - https://github.com/waku-org/specs/pull/1\nWorked on vac rfc repo - https://github.com/vacp2p/rfc-index\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nComparing mixnet Nym to figure out new design/proposal\nReviewing Nym paper and design\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nResearched the Transaction Directed Acyclic Graph (TDAG) framework to aggregate in SE and DE and produced a documentation about it (Moudy)\nStarted reading about the Privacy Directed Acyclic Graph (PDAG) framework (Moudy)\nMade progress on the integration of Cryptographic primitives in SE and DE (Ugur)\nMade progress on adress hiding and signature verification document (Marvin)\nStarted producing notes about Field Merkle Trees (Marvin)\nStarted creating the one-tier low-level framework for SE and DE kernel circuits by adding public and private data (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nContinued looking at Reverie whitepaper and Binius implementation (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nFixed PR#24 comments and merged Arecibo benchmark implementation(Rostyslav)\n\n\n"},"vac/updates/2024-02-19":{"title":"2024-02-19 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/02/19 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nhttps://github.com/status-im/nim-libp2p/pull/960\nTesting made it clear that the WebRtcMuxer wasn’t finished\n\nFix an oversight regarding datachannel incoming streams\nGet the streamId from SCTP to WebRtcTransport (missing a SCTP flag)\nFix a bug with binary-serialization (missing a compilation flag)\nFix a possible infinite loop that could occur while closing a stream\nFix WebRtcMuxer.new() (missing the connection field)\n\n\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nMore improvements, now merged - https://github.com/status-im/nim-libp2p/pull/1015 (feat: message prioritization with immediate peer-published dispatch and queuing for other msgs)\nMaking it ready to be merged - https://github.com/status-im/nim-libp2p/pull/1017 (feat: drop msgs to be relayed waiting for too long in the queue)\nWriting https://www.notion.so/Gossipsub-latency-improvements-9748092d135643ffb092939d9460fed0\nPlanning on how to check the IDONTWANT info before relaying a msg\n\n\n\nvac:tke: §\n\nnomos:cryptarchia-wealth-concentration-estimated-stake\n\nimplemented one more metric about wealth concentration (@Frederico)\nprepared the Figures that go into the report about Nomos wealth concentration (@Frederico)\nreview Frederico’s work on wealth concentration (Martin)\n\n\ncodex:cdx\n\ndesigned a diagram with Codex interactions (@Frederico)\ncreated a copy of the original Codex litepaper on GitHub (@Frederico)\ncatch up on latest developments to prepare for the call on Fr. (@Martin)\n\n\nwaku:economic-analysis\n\ncatch up on Sergei’s ongoing work (@Martin)\nanalyze the proposed store v3 protocol from a token economics perspective (@Martin)\nproceed with defining RLN pricing properties and suggest suitable mechanisms (@Martin)\n\n\nstatus:SNT-staking\n\nreviewing Ricardo’s new implementation of the staking contract (resolving the accounting issue) (@Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nUsing framework to get Thanos metrics\n\nFirst draft PR (https://github.com/vacp2p/10ksim/pull/3)\n\n\nStarted plotting module aswell (https://github.com/vacp2p/10ksim/tree/plotter)\n\n\neng-10ktool:vac:bandwidth-test\n\nSpun up a new test tracking page\nRan a few (~3-4) simulations trying to test new metric scale\nFixed a major issue with a node which improved our bandwidth by ~1/3rd\n\nThis also dropped packet loss to under 100 pps even under massive loads\n\n\nBrought distributed storage (CubeFS) properly online\nRe-ran simulations with Nwaku - stable swarms up to about 2000 peers, we were unable to see connections above that\nVLAN migrations continue\n\n\n\nvac:qa: §\n\nwaku:test-automation-js-waku\n\nRefactor and handle mocha hooks timeouts gracefully(@Florin)\nAdjust tests regarding latest failures on nwaku latest(@Florin)\n\nIssues reported:\n\nhttps://github.com/waku-org/js-waku/issues/1845\nhttps://github.com/waku-org/js-waku/issues/1835\nhttps://github.com/waku-org/js-waku/issues/1848\n\n\n\n\n\n\nwaku:interop-testing\n\nAdjust tests regarding latest failures(@Florin)\n\nIssues reported:\n\nhttps://github.com/waku-org/go-waku/issues/1034\nhttps://github.com/waku-org/nwaku/issues/2436\nhttps://github.com/waku-org/nwaku/issues/2437\n\n\n\n\nRLN support and tests added(@Roman)\n\nIssues reported:\n\nmessage not delivered during interop test\nhealth check endpoint needed\n\n\n\n\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\n\n\nwaku:test-automation-nwaku\n\nFinish investigating peer exchange and extend negative cases(@Alex)\n\n\nadmin/misc\n- Yamux PR(@Alex)\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nserde tests for rln-v2 in nwaku: https://github.com/waku-org/nwaku/pull/2421\nsolved previously known issue of waku-rln-relay continuing to run when the tree is in a bad state. now, whenever the node detects something wrong with the eth rpc endpoint, it disconnects and crashes: https://github.com/waku-org/nwaku/pull/2429\n\n\nrlnp2p:waku:rln-relay-enhancements\n\nimproved node setup with TWN config is set: https://github.com/waku-org/nwaku/pull/2423\ndeprecate wss/ws support from nwaku for eth rpc endpoint: https://github.com/waku-org/nwaku/pull/2442 & follow up: https://github.com/waku-org/nwaku/pull/2444\nupdated waku.test fleet config with http url instead of ws: https://github.com/status-im/infra-waku/pull/11\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nupdated docs for rln-relay in nwaku-compose: https://github.com/waku-org/nwaku-compose/pull/52\n\n\nsecure-channels:waku:ethereum-chat\n\nCompleted a first draft of the following sections of the paper: Introduction; Related work; MLS and SIWE.\nFinished the doc about comparion of the security mechanisms of Tor Messenger, Briar and update the existing doc in notion.\nStudy about the stealth addresses for anonymous secure chat.\n\n\nzerokit:vac:maintenance\n\nstarted working on a serde implementation of issue https://github.com/vacp2p/zerokit/issues/21\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-maintemance\n\nfix certora specs in github PRs (upgrade certoraRun)\nadd rule for setMaxSupply\nclean up spec\nimport config from r4bbit’s PR\n\n\nstatus:community-contracts-token-import\n\nstarted working on (Allow for community vaults to keep track of deposited tokens) https://github.com/status-im/communities-contracts/issues/31\n\n\nstatus:staking-contracts-v1\n\nMultiplier points estimation issue\n\nhttps://github.com/logos-co/staking/issues/48\n\n\nRefactor MP logic and fix bugs https://github.com/logos-co/staking/issues/51\n\nhttps://github.com/logos-co/staking/pull/52\n\n\nUpdated existing tasks based on latest discussions\nAdded new tasks to plan milestone\n\n\nstatus:community-contracts-multitoken\n\nCreated new milestone and tasks for upcoming effort to implement a new token contract for the desktop team\n\nhttps://github.com/status-im/communities-contracts/milestone/4\n\n\n\n\nvac:maintainance/misc\n\nAdd deployment address to sticker market repo\n\nhttps://github.com/status-im/sticker-market/pull/15\n\n\nAdded project board automation to relevant repos\n\nhttps://github.com/status-im/communities-contracts/pull/37\nhttps://github.com/status-im/communities-contracts/pull/39\nhttps://github.com/vacp2p/foundry-template/pull/15\nhttps://github.com/logos-co/staking/pull/50\n\n\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nWorked on Waku specs, should be ready for first merge - https://github.com/waku-org/specs/pull/1\nStarted updating COSS, not ready for feedback - https://github.com/vacp2p/rfc-index/tree/1-COSS\nWorked on Vac RFC Index, updated some files and updated readme - https://github.com/vacp2p/rfc-index/pull/2\n\n\nwaku:core-rfc-updates\n\nWorked on updating 10/Waku2 based on feedback - https://github.com/vacp2p/rfc/pull/661\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nadded new design ideas (https://docs.google.com/document/d/15X4vJTK_Hr3g3K01XF77R3KCqLI8LIm3/edit?usp=sharing&ouid=109850114495777070500&rtpof=true&sd=true)\n\n\nvalpriv:vac:tor-push-poc\n\nmerging torpush changes in the latest nimbus-eth2 stable release\n\n\nvalpriv:vac:tor-push-paper\n\nrevised last comments about structure\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nCreated a PR to minimize the relay peers set based on idontwant/receieved messages. https://github.com/status-im/nim-libp2p/pull/1027\n\nshowing small bandwidth and latency improvement with the increasing message sizes (still to test on very large messages)\n\n\n\n\nzk:codex:storage-proofs-open-problems-review\n\nProvide feedback on Range Proof example\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nResearched the Privacy Directed Acyclic Graph (PDAG) framework for privacy guarantees (Moudy)\nMade progress on the integration of Cryptographic primitives in SE and DE (Ugur + Moudy)\nMade progress on adress hiding and signature verification focusing on RingCT (Marvin)\nFinished the report about SE and DE kernel circuits in notion. (Ugur)\nStudied about a problem about nullifying randomization of notes (Ugur)\n\n\nproofsystems:vac:benchmarks\n\nFinished updating Arecibo document (Moudy)\nFinished updating halo2 document (Moudy)\nUpdated the main Benchmarks document (Moudy)\nBegin theoretical complexities for various proof systems (Rostyslav + Moudy + Marvin)\n\n\n"},"vac/updates/2024-02-26":{"title":"2024-02-26 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/02/26 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nYamux simulations https://github.com/status-im/nim-libp2p/pull/1029\n\nDebug the stairs showed with the metrics\nIt was due to a couple of error / bug:\n\nOn nwaku a ping connection opened wasn’t closed\nOn yamux the timeout wasn’t implemented\n\n\nThe implementation + testing of the implementation showed a sneaky bug (fixed)\n\n\n\n\nnimlibp2p:vac:webrtc-transport\n\nMerged the DataChannel giant PR https://github.com/status-im/nim-webrtc/pull/4\nMaintenance on nim-mbedtls https://github.com/status-im/nim-mbedtls/\nDebugging some issues with the interaction between the clients parts of dtls and sctp https://github.com/status-im/nim-webrtc/pull/5\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nTested and found issues with PR and possibly more that already exist - https://github.com/status-im/nim-libp2p/pull/1015 (feat: message prioritization with immediate peer-published dispatch and queuing for other msgs)\nExperimental PR - https://github.com/status-im/nimbus-eth2/pull/5911 - to test fixes for the above. It has been deployed to https://metrics.status.im/d/pgeNfj2Wz23/nimbus-fleet-testnets?orgId=1&from=now-6h&to=now&var-instance=erigon-10.ih-eu-mda1.nimbus.holesky&var-container=beacon-node-holesky-libp2p&refresh=5s\nCheck nimbus/libp2p discord channel for more info on the above.\n\n\nnimlibp2p:vac:maintenance\n\nBriefly investigate interop failing tests; Flaky: Added them to flaky tests doc\n\n\n\nvac:tke: §\n\nnomos:cryptarchia-wealth-concentration-estimated-stake\n\nfinalizing the report about wealth concentration on Nomos (@Frederico)\ncaught up with Frederico’s work on wealth concentration (@Martin)\n\n\nnomos:tdc-objectives\n\ncontinued reading the whitepaper and filling the TDC (@Frederico)\n\n\ncodex:cdx\n\nappended the CDX token interactions with the feedback from the Codex team (@Frederico)\nreviewed Codex team suggestions about data retrievability on other protocols (@Frederico)\n\n\nwaku:rln-membership:\n\ncaught up with Martin’s work on RLN pricing (@Frederico)\nprepare for and lead the discussion on RLN pricing, follow-ups (@Martin)\n\n\nstatus:SNT-staking\n\nhelped Martin with questions about radCAD model (@Frederico)\nreviewing Ricardo’s new implementation of the staking contract (resolving the accounting issue) (@Martin)\nexplore concepts and architecture for the staking module (role of relayer, vault factory) (@Martin)\nupdated the radCad model to reflect latest thinking on MPs (@Martin)\n\n\nwaku:general-incentives\n\nread papers suggested by Jarrad (@Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nSet up cluster without K3s (with Wings’s help) and test P2P PR 1045\nKeep working on Thanos metrics scrapping: PR: https://github.com/vacp2p/10ksim/pull/3\nGathered detailed metrics for paper on Waku scaling\nRan 4 simulations\nVarious metrics tuning on Emerald k8s\nCompletely rebuilt the Kubernetes cluster (and about 80% of the lab)\n\nNew cluster is called Opal, the sequel to Emerald\nUses Cilium (on top of the Multus metaplugin) for much higher network performance\nEntirely bare metal, currently 3 nodes (pending 4th node returning, happening by EOW)\nUses the new VLAN structure, clean credentials\n\n\nFixed an issue with Metrics still using Longhorn\nFigured out how to use the backup and restore tool Velero\nAdded KubeVirt for virtual machine hosting and management inside Kubernetes\n\nWill make it easier for us to provision machines for other teams\nBacked by Rook-Ceph\n\n\nMany tweaks to Kubernetes, Cilium, metrics, and more - see https://www.notion.so/Opal-Kubernetes-Cluster-Lab-Rebuild-4c8472546b0d47f5b05debacf9c7ac29\nFixed multiple major networking issues with the lab (again)\nAdded the ability to multi-home k8s pods through Multus (ie: attach them to multiple networks)\nDebugged and fixed a huge issue with TLS certificate issuance through Let’s Encrypt - turned out to be Cloudflare’s fault (Universal SSL basically broke my LE DNS-01 challenges, hard)\nScaled up Redis to 18 nodes (6 master, 12 replicas) for additional safety under heavy load\n\n\n\nvac:qa: §\n\nwaku:test-automation-js-waku\n\nPeer exchange tests(@Florin)\n\nIssues reported:\n\nhttps://github.com/waku-org/js-waku/issues/1858\nhttps://github.com/waku-org/js-waku/issues/1860\n\n\n\n\nUpgrade and test CI with nwaku v0.25.0(@Florin)\n\n\nwaku:interop-testing\n\nRemove deprecated flag(@Florin)\nFixed RLN_CREDENTIALS - Waku moved to use HTTP instead of WebSocket(@Roman)\nWaku node health/reliability(@Roman)\n\nKeep collecting info for issues:\n\nhttps://github.com/waku-org/nwaku/issues/2369\nhttps://github.com/waku-org/docs.waku.org/issues/165\n\n\n\n\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\n\nIssues reported:\n\nhttps://github.com/waku-org/go-waku/issues/1044\n\n\n\n\n\n\nwaku:test-automation-nwaku\n\nFinished Implementing Peer Exchange tests(@Alex)\nUnittest Library - Added Feature Request for nested suites(@Alex)\nFix imports and test related to missing imports(@Alex)\nBrief look on Connection & Peer Management(@Alex)\nStart working on Discv5 tests(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nincluded a PoC for small trees < 255 leaves where the root can be included onchain trustlessly via a view call - https://github.com/vacp2p/rln-contract/pul\n\n\nadmin/misc\n\nassisting waku research team with waku papers\n\n\nsecure-channels:waku:ethereum-chat\n\nCompleted a first version of the paper, including the detection a possible mitigation of lost messages.\nUpdate the internal Notion page.\nPrepare presentation for the Logos Research Call\nFinished the research about integration of ERC-5564 and EIP-4361(SIWE).\nStart to study about the anonymous chatting with stealth addresses.\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-token-import\n\nimplemented Vault.depositERC20\n\nhttps://github.com/status-im/communities-contracts/pull/53\n\n\n\n\nstatus:staking-contract-v1\n\nreview\n\nfix: StakeManager migration fixes and certora rules\n\n\nRefactor and fixes for StakeManager\n\nrefactor(StakeManager): refactor multiplier points logic\nfix(StakeManager): properly init accs and checks init\nfix(StakeManager): check for valid migration address\nfix(StakeManager): use a correct MP formula\nrefactor(StakeManager): change MIN_LOCKUP_PERIOD to 2 weeks\n\n\nResearch and fix for division precision loss\n\nchore: add gas-report for all contracts\nchore(StakeManager): add test for process account and unstake\nfix(StakeManager): use OpenZeppelin Math to avoid precision loss in int divisions\n\n\n\n\nvac:maintainance/misc\n\nFoundry Template\n\nimplemented gas-report\nimplemented command to prepare for commits\nresearch on EOL error in prettier for .json files\n\n\nSticker Market\n\nPublished Sticker Types from Mainnet in Sepolia\n\n\nInvestigated issue of ENS not working on Sepolia in Status Desktop\n\nhttps://github.com/status-im/status-desktop/issues/13697#issuecomment-1960877592\n\n\n\n\nstatus:community-contracts-maintenance\n\nDeployed communities contracts on OP Sepolia\n\nCommunityTokenDeployer\n\nhttps://sepolia-optimism.etherscan.io/address/0xcE2A896eEA2F585BC0C3753DC8116BbE2AbaE541#code\n\n\nCommunityOwnerTokenRegistry\n\nhttps://sepolia-optimism.etherscan.io/address/0xfFa8A255D905c909379859eA45B959D090DDC2d4#code\n\n\nCommunityOwnerTokenFactory\n\nhttps://sepolia-optimism.etherscan.io/address/0x420be6568c6e09782ceae1575495cd6c1c7ea04d#code\n\n\nCommunityMasterTokenFactory\n\nhttps://sepolia-optimism.etherscan.io/address/0x99F0Eeb7E9F1Da6CA9DDf77dD7810B665FD85750\n\n\nPR adding addresses to project README\n\nhttps://github.com/status-im/communities-contracts/pull/52\n\n\n\n\nInvestigated Certora rule issues for CollectiblveV1 token\n\nhttps://github.com/status-im/communities-contracts/pull/48\n\n\nCollectibleV1 is now CommunityERC721\n\nhttps://github.com/status-im/communities-contracts/pull/51\n\n\n\n\nstatus:community-contracts-batch-tx-ext\n\nImplemented safeBatchTransferFrom capabilities in BaseToken\n\nhttps://github.com/status-im/communities-contracts/pull/45\n\n\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nMerge Waku specs after Hanno feedback - https://github.com/waku-org/specs/pull/1\nWorked on COSS, still in draft - https://github.com/vacp2p/rfc-index/pull/4\n\n\nwaku:core-rfc-updates\n\nWorked on updating 17/WAKU-RLN-RELAY - https://github.com/vacp2p/rfc/pull/667\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nStill refining suggested ideas. slow this week.\n\n\nvalpriv:vac:tor-push-poc\n\nMerged the branch torpush and rebased but encountered several conflicts. Still testing and in progress on boarding for holesky\n\n\nvalpriv:vac:tor-push-paper\n\naddressed the feedback\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nConducted tests on [PR-1015], [PR-1017], [PR-1027], [PR-1028] against different scenarios\nadded notion page on large message transmissions for GossipSub https://www.notion.so/GossipSub-Improvements-Impact-of-Flood-Publishing-on-Large-Messages-9c6f15a6f1364adeade91d674ecdcb55\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nWorked on better message forwarding. Sorting on TxTime showed slightly improved results. Now Limiting senders to further saturate bandwidth for senders\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegin examining Reverie in terms of idea mentioned in the Discord feedback thread\n\n\nadmin/misc\n\nStudy RLN code for stateless proofs; this provides additional insight on how Merkle trees/Verkle trees can and should be coded better which is beneficial for Nescience notes in the long run.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nFinished researching the Privacy Directed Acyclic Graph (PDAG) framework for privacy guarantees\nStarted looking at monitoring issues\nStarted looking at Nullifier issues to avoid linkeability\nResearch joinsplit and optimistic rollups for monitoring\nBegin documents on joinsplit and monitoring\n\n\nproofsystems:vac:benchmarks\n\nWritten a first expanded draft for Benchmarks research paper\nResearch for table comparison\n\n\nproofsystems:vac:benchmarks\n\nprepared explanation for Halo2 GWC and SHPlonk implementations (https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#2eb24a7ce01447bebbf8f5f966aede7a and https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#26d2fc825c9845f1a0ee6288f18694ce)\nprepared explanation for Arecibo implementation (https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#4fd8570d40d14e228f4d9dc08e0c2ab1)\nFixed various PRs comments\nAdded verify benchmark for Nova Circom + number of constraints (https://github.com/vacp2p/zk-explorations/pull/25)\nAdded verify benchmark for Nova Bellman + number of constraints (https://github.com/vacp2p/zk-explorations/pull/30)\nAdded verify benchmark for Arecibo + number of constraints (https://github.com/vacp2p/zk-explorations/pull/29)\nAdded verify benchmark for Plonky2 + number of constraints (https://github.com/vacp2p/zk-explorations/pull/26)\nResearched- state-separation:vac:state-separation-doc\nFinished researching the Privacy Directed Acyclic Graph (PDAG) framework for privacy guarantees\nStarted looking at monitoring issues\nStarted looking at Nullifier issues to avoid linkeability\nResearch joinsplit and optimistic rollups for monitoring\nBegin documents on joinsplit and monitoring\n\n\nproofsystems:vac:benchmarks\n\nWritten a first expanded draft for Benchmarks research paper\nResearch for table comparison\n\n\nproofsystems:vac:benchmarks\n\nprepared explanation for Halo2 GWC and SHPlonk implementations (https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#2eb24a7ce01447bebbf8f5f966aede7a and https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#26d2fc825c9845f1a0ee6288f18694ce)\nprepared explanation for Arecibo implementation (https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#4fd8570d40d14e228f4d9dc08e0c2ab1)\nFixed various PRs comments\nAdded verify benchmark for Nova Circom + number of constraints (https://github.com/vacp2p/zk-explorations/pull/25)\nAdded verify benchmark for Nova Bellman + number of constraints (https://github.com/vacp2p/zk-explorations/pull/30)\nAdded verify benchmark for Arecibo + number of constraints (https://github.com/vacp2p/zk-explorations/pull/29)\nAdded verify benchmark for Plonky2 + number of constraints (https://github.com/vacp2p/zk-explorations/pull/26)\nResearched ways to calculate halo2 constrain ways to calculate halo2 constrain\n\n\n"},"vac/updates/2024-03-04":{"title":"2024-03-04 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/03/04 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nSctp and Dtls client done: https://github.com/status-im/nim-webrtc/pull/5\nAdds a lot of comments some refactoring to improve (I hope) the readability https://github.com/status-im/nim-webrtc/pull/6\nClosing the streams/connections: starts to test and think about it to make it bulletproof\n\n\nnimlibp2p:vac:maintenance\n\nInvestigating issues related to https://github.com/status-im/nim-libp2p/pull/1032\n\n\n\nvac:tke: §\n\nnomos:tdc-objectives\n\nexpanded the objectives & requirements part of the TDC (@Frederico)\n\n\ncodex:cdx\n\nincorporated into Codex Litepaper all material about Codex on GitHub (@Frederico)\nreviewed the causal loop diagragam for Codex (@Frederico)\nreviewed the stock and flow diagram for Codex (@Frederico)\n\n\nwaku:rln-membership:\n\nPrepare a summary of the RLN membership model including user journey mapping (@Martin)\nReview the pricing of Farcaster, etc. (@Martin)\n\n\nwaku:general-incentives\n\nFollow up with general research into Waku strategy based on the IFT strategy call. (@Martin)\n\n\nstatus:SNT-staking\n\nContinue the review of the staking contract (@Martin)\nUnderstand the severity of precision loss (due to Solidity constraints) and resulting discrepancy between the contract logic and radCad simulations (@Martin)\nAssist the SC team in further checks and definition of testing scenarios (@Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nWork on plotting module in the Kubernetes framework\n\nModified main yaml to add plotting options\nCreated plotter class to group there all functionalities\nStructured plotter to be able to group several experiments in same plot in an automatic manner\n\n\nLots of calls with Wings to test the lab, launch simulations, discuss about problems and so on.\n\n\nDeployed iBGP for Calico\n\nWhich got the IP addresses wrong at first, fixed by editing Node annotations\nLater removed BGP due to numerous issues with it\n\n\nNumerous, numerous Kubernetes tests and improvements\n\nTried Cilium briefly\nSwitched from Cilium to Calico\nReinstalled entire cluster as Calico transition broke things (due to CNI switch without reinstall being a bad idea)\n\n\nScale testing revealed that Linux has limits per node that prevent us from scaling beyond about ~1400 waku nodes per physical host when running on bare metal\nCreated a new architecture for running tests\n\nHybrid between bare metal and virtualised Kubernetes\nRook-Ceph (Storage) and Prometheus-Thanos (Metrics) stacks run on bare metal, as does all management\nThe rest runs in a KubeVirt based deployment system.\n\nWe deploy what we’re calling “opal fragments” (fractions of the Opal Kubernetes cluster) - Kubernetes workers dedicated solely to running nwaku deployments.\n\n\nCan deploy 5000 nodes in < 8 minutes, with stable mesh forming around 25 minutes into deployment\n\n\nExperimented with various opal fragment deployments - 56x nodes seems to be the most stable configuration\n\nMuch higher than this (especially with poor allocation of cores) causes instability in the CNI (Calico)\n\nWhich causes monitoring issues as nodes drop out of Prometheus monitoring\nAnd can mess with the mesh\n\n\nInstability is lower with lower # of connections\n\n\nDebugging CoreDNS issues - believe we’ve found a bug in CoreDNS and its interactions with HeadlessServices, returning NXDOMAIN even for valid hostnames about 1 in 5.5 to 6 queries.\nRan repeated simulations to get a stable simulation for testing.\nBuilt a new “accelerated bootstrap” mode for simulations\n\nvac:qa: §\n\nwaku:test-automation-js-waku\n\nFix flaky tests(@Florin)\nClose milestone(@Florin)\n\n\nwaku:test-automation-sharding\n\nImprove static sharding and autosharding tests coverage for js-waku(@Florin)\nIssue reported:(@Florin)\n\nhttps://github.com/waku-org/js-waku/issues/1874\n\n\n\n\nwaku:interop-testing\n\nWaku node health/reliability(@Roman)\nIssue updated:\n\nhttps://github.com/waku-org/go-waku/issues/1014)\n\n\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\nIssue updated:\n\nhttps://github.com/waku-org/go-waku/issues/1044\n\n\n\n\nwaku:test-automation-nwaku\n\nPeer Exchange(@Alex)\n\nResultify fetchPeerExchangePeers\n\n\nDiscv5(@Alex)\n\nImplement tests and simplify and reduce code\n\n\nPeer & Communication Management(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nimproved testing for rln-v2 onchain mode: https://github.com/waku-org/nwaku/pull/2482\nimproved testing for rln-v2 static/offchain mode: https://github.com/waku-org/nwaku/pull/2484 (pending review)\n\n\nsecure-channels:waku:ethereum-chat\n\nFinish the presentation for the Logos Research Call.\nImprove the research paper.\nConsidering replacing MLS with another protocol.\nAdd an overview on anonymity and SIWE integration in notion.\nStudy on hierarchical deterministic wallets for anonymous login.\nStudy the openmls crate for demo implementation.\n\n\nzerokit:vac:maintenance\n\ntaken a look on this issue https://github.com/vacp2p/zerokit/issues/47\n\n\nadmin/misc\n\nassist with waku research paper\nstealth commitment protocol over waku PoC: https://github.com/waku-org/nwaku/pull/24\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-token-import\n\nfinished PR erc20/erc721 deposit PR\nimplemented withdraw function for tokens sent directly to the contract https://github.com/status-im/communities-contracts/pull/59\n\n\nstatus:staking-contracts-v1\n\nReviewed and merged PRs\nContinue work on coverage\nImplemented additional deployment script for new StakeManagers\n\nhttps://github.com/logos-co/staking/pull/72\n\n\nWorked on fixing certora specs\n\nhttps://github.com/logos-co/staking/pull/73\nhttps://github.com/logos-co/staking/pull/74\nhttps://github.com/logos-co/staking/pull/75\n\n\nFixed a bug that allows StakeManagers to reset another one’s Stakemanagers epoch while it’s in migration\n\nhttps://github.com/logos-co/staking/pull/76\n\n\n\n\nstatus:community-contracts-maintenance\n\nRelease version 1.0.0 of communities contracts\n\nChangelog: https://github.com/status-im/communities-contracts/blob/main/CHANGELOG.md#100-2024-02-28\n\n\n\n\nvac:maintainance/misc\n\nWorked on Logos Research call presentation\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nworked rfc process - https://github.com/vacp2p/rfc-index/pull/8\nworked on pull request for rfc-index - https://github.com/vacp2p/rfc-index/pulls\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nRefined and working on https://docs.google.com/document/d/15X4vJTK_Hr3g3K01XF77R3KCqLI8LIm3/edit\n\n\nvalpriv:vac:tor-push-poc\n\nSuccessfully merged , built the torpush while rebasing from stable nimbus.\n\n\nvalpriv:vac:tor-push-paper\n\nImproved and revised the draft. like citing tor related attacks with relevance for tor push while making many other minor points and clarification https://www.overleaf.com/project/6499e467346d9f56b2971caa\nCreated a notion page on findings on large message handling: https://www.notion.so/Performance-Evaluation-of-Different-Pull-Requests-for-Large-Message-Handling-4d47672820114732b9f248f6bf18946e\nMerged PR-1027, PR-1028 and used TxTime sorting on SendPeerList. Additionally used semaphors to limit simultaneous transmissions. Improves results in some cases and shows large fluctuations in other messages\nConfigured shadow simulation for variable latency and bandwidths. Trying to build some automated scripts (requires adding edges among all peers, and adding all nodes with variable latency/bandwidth). NetworkX package in python can help writing network in gml format\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nResearched and discussed about monitoring issues and how to adapt solutions to our proposal (Moudy + Marvin)\nResearched and discussed about nullifeir problems and how to solve them (Moudy + Ugur)\nStudied untraceability and unlinkability features of PDAGs to create our version of PDAGs (Ugur)\nStared working on reward mechanisms for monitoring (Marvin)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished writing Reverie writeup (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nWorked on refining the Benchmark paper and drafted a full version (Moudy)\nWent through the Benchmarks paper and discussed about modifications to make and general output (Moudy + Rostyslav)\nModified Halo2 SHPLONK, Halo2 GWC and Plonky2 circuits (Rostyslav)\nPrepared a paragraph on Nova vs SuperNova difference and Nova vs Halo2 recursion (Rostyslav)\n\n\n"},"vac/updates/2024-03-11":{"title":"2024-03-11 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/03/11 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFinish commenting and refactoring Sctp and DataChannel https://github.com/status-im/nim-webrtc/pull/6 (merged)\nTry to implement CI and make it work on differents OS (it fails) https://github.com/status-im/nim-webrtc/pull/1\nMove usrsctp from nim-webrtc to its own repository: https://github.com/status-im/nim-usrsctp\nClean nim-webrtc for the review\n\nUDP: https://github.com/status-im/nim-webrtc/pull/8\nStun: https://github.com/status-im/nim-webrtc/pull/9\nDTLS: https://github.com/status-im/nim-webrtc/pull/10\nSCTP: https://github.com/status-im/nim-webrtc/pull/11\nDataChannel: https://github.com/status-im/nim-webrtc/pull/12\n\n\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nReviewing and discussing https://github.com/status-im/nim-libp2p/pull/1051. It’s related to prio queues in GossipSub.\n\n\nnimlibp2p:vac:maintenance\n\nCreating questions for interview.\nTrying to run interop tests with chronos 3 - https://github.com/status-im/nim-libp2p/pull/1055\nvarious PR reviews\n\n\nnimlibp2p:vac:maintenance\n\nproto3 repeated uint32 handling\n\nIssue\nDouble check jacek’s answer: All good.\nsingle topic in rpc message\n\nIssue\nImplement fix PR\n\n\ngraceful shutdown\n\nIssue Investigated and requested more info\n\n\n\n\n\n\n\nvac:tke: §\n\nwaku:rln-membership:\n\nPrepare a summary of the RLN membership model including user journey mapping (need to discuss with Waku team further) (Martin)\nPrepare and iterate on the token economy suggestions for Waku (Martin)\nFollow-ups from the Tokenomics call (Martin)\n\n\nstatus:SNT-staking\n\nContinue to monitor development and give feedback for the staking contract (Martin)\nAssist the SC team in further checks and definition of testing scenarios (Martin)\nFollow-ups from the Status Chain IFT Strategy call (Martin)\n\n\nnomos:tdc-objectives\n\nfinalized the objectives & requirements part of the TDC (inc. mixnet nodes below) (Frederico)\n\n\nnomos:mixnet-incentives\n\nunderstood the mixnet incentivization problem (Frederico)\nread Nym reward sharing scheme for mixnets (a comparable) (Frederico)\nanalysed the differences between single vs. multi-staking approaches (Frederico)\n\n\nwaku:general-incentives\n\ncaught up with Martin’s tokenomics proposal (Frederico)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nMain thing is to retrieve waku simulations Data and plot them\n\nPrepare deliverable for Waku\n\nFinish running several simulations with different sizes and message rates\nExtract data\nPrepare and clean plots\nDiscuss again with Wings what we should explain in the deliverable\n\n\n\n\nAdd tests to plotter module\nScrapping PR aproved by Alex: https://github.com/vacp2p/10ksim/pull/3\nDeliverable for Waku simulations\nDiscussions with some friends about how to scale further\n\nNoted that there was at least 8 layers for every packet to pass through with current setup\n\n\nNetwork restructuring - OVS + Mellanox OFED + asap2 attempts\n\nAdded Proxmox to Vaxis and Nia (converting them)\n\nAdded Mellanox OFED drivers\nUpdated firwmare\nMoved to OpenvSwitch networking\n\n\n\n\nDeployed Kubernetes onto the new machines\n\n\n:vac:lab\n\nPreparing for power upgrades\nAdded Vaxis, Nia, new 64 core nodes\nAdded new 25G switch\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nUse fixed versions for dependecies(@Florin)\nAdjustments and improvements(@Florin)\nTried to reproduce the disconnecting light clients issue and found a similar issue(@Florin)\n\n\nwaku:test-automation-sharding\n\nUnit and interop tests(@Florin)\nDiscovered autosharding is hardcoded for cluster ID 1(@Florin)\nHelp js-waku devs to improve CI error handling(@Florin)\nRaised issue for flaky CI test(@Florin)\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\nClosed triggerDiscovery issue(@Roman)\nImprove unit test coverage for peer exchange(@Roman)\n\n\nwaku:test-automation-nwaku\n\nKEYSTORE_PASSWORD env variable is not effective - resolved(@Roman)\nTrying to reproduce, fix and add new test case for metadata protocol disconnecting light clients issue(@Alex)\nSolved some issues related to metadata connection between two nodes.(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\nOptimized the Nullifier Table usage to O(1) reads to detect double signaling: https://github.com/waku-org/nwaku/pull/2508\nFixed execution error when trying to fetch metadata from a freshly created tree (nwaku side): https://github.com/waku-org/nwaku/pull/2516\n\n\nrlnp2p:waku:rln-relay-v2\n\nWrap up tests for rln-relay-v2: https://github.com/waku-org/nwaku/pull/2501 (pending review)\n\n\nzerokit:vac:maintenance\n\nFix execution error when trying to fetch metadata from a freshly created tree (zerokit side): https://github.com/vacp2p/zerokit/pull/231 (rln-v1) & https://github.com/vacp2p/zerokit/pull/232 (rln-v2)\n\n\nsecure-channels:waku:ethereum-chat\n\nExplore a proposal on decentralized CGKA by Weidner et al. as a replacement for the MLS protocol.\n\n\nsecure-channels:waku:ethereum-chat\n\nCheck the literature for related the papers CoCoA, 2, 3, and DCGKA\nQuickly check the literature to see if there are any improvements in MLS and its problems.\nStarted to focus on DCGKA by reading Ramses’ note\n\n\nzerokit:vac:maintenance\n\nresearched Rust for Android for issue #47\n\n\nadmin/misc\n\nFixed compilation without the postgres feature in nwaku: https://github.com/waku-org/nwaku/pull/2500\nwaku research paper\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-token-import\n\nfinished withdrawal PR\nadded tests for erc20 withdrawal https://github.com/status-im/communities-contracts/pull/60\nstarted a POC for Vault migration to discuss about https://github.com/status-im/communities-contracts/issues/32\n\n\nstatus:staking-contracts-v1\n\nContinue work on coverage\nFixed broken certora rule to get CI green again\n\nhttps://github.com/logos-co/staking/pull/78\n\n\nAdded invariant to ensure Vault accounting preserves ERC20 balances\n\nhttps://github.com/logos-co/staking/pull/56\n\n\nWorked on pending Certora rule to get them pass on CI\n\nhttps://github.com/logos-co/staking/pull/58\nhttps://github.com/logos-co/staking/pull/57\nhttps://github.com/logos-co/staking/pull/81\n\n\n\n\nvac:maintainance/misc\n\nAnalysis of SNT impact on ethereum state\nResearch on Market Makers of other wallets\nLogos Research call preparation and presentation\n\nSlides: https://docs.google.com/presentation/d/1pdW3JZxqh7t_Aqd-cfIi1_JP4_8gyCk5XDBeY3nsrrE/edit?usp=sharing\nVideo: https://drive.google.com/file/d/1NGZWkEAWMoeHMQXpIi2fStyzQYqbfSKG/view?pli=1\n\n\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nadded markdown-lint workflow to rfc-index- https://github.com/vacp2p/rfc-index/pull/24\nfinished moving final open waku specs from vac/rfc - https://github.com/vacp2p/rfc/pulls\n\n\nmisc\n\nworked on pr for 64/WAKU2-NETWORK - https://github.com/vacp2p/rfc-index/pull/5\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nMoved the content to notion https://www.notion.so/privacy-preserving-validator-network-e92ab3e563074a538bb0e13e5c9321e6\n\n\nvalpriv:vac:tor-push-poc\n\nRunning holesky validators, getting over sync/deposit issue\n\n\nvalpriv:vac:tor-push-paper\n\nImproved the draft https://www.overleaf.com/project/6499e467346d9f56b2971caa\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nCompleted topology generation scripts for shadow simulator. PR4 now supports running simulations with variable latency, bandwidth, packet loss ratio, and also allows adjusting network/message size, fragmentation and publisher settings\nCreated a notion page on message forwarding/queuing in other libp2p implementations (go-libp2p):\nCreated a vac forum post on large message handling\n\n\nadmin/misc\n\nReviewed Waku-RLN paper\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nResearched accumulators and how to combine them to Homomorphic encryption + prepared a document about it (Moudy)\nResearched how to make salt approach dynamic and will prepare a document about it (Moudy)\nBegan reading portions of Nexus VM and GKR-based VM (Marvin)\nRead various papers concerning reward mechanisms for miners/observers. 1, 2, 3, 4, 5 (Marvin)\nAlmost completed report about SE/DE in PDAGs (Ugur)\nRead accumulators about Zerocoin nullifier mechanism in this paper (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\ntook a look at Nexus VM and LatticeFold (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nWorked on abstract, tables for paper (Moudy)\nWorked on researching Nova vs. Supernova (Moudy)\nStarted Nova vs. Halo2 recursion vs. aggregation (Moudy)\nPrepared explanation for Nova Bellman implementation (Rostyslav)\nConducted local benchmark testing (Rostyslav)\n\n\n"},"vac/updates/2024-03-18":{"title":"2024-03-18 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/03/18 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\npreparing interview\nreviewing PRs\nGraceful Shutdown (1007) Fix\n\nPR\n\n\nSingle topic for RPC Message (1052)\n\nPR Update PR with suggestions\n\n\n\n\n\nvac:tke: §\n\nadmin/misc\n\nreviewed CVs (Frederico)\nInterviews with candidates (Martin)\n\n\nnomos:mixnet-incentives\n\ndeveloped a pricing model for packets routed through the mixnet (Frederico)\nmodified Nym reward allocation mechanism to Nomos constraints (Frederico)\n\n\ncodex:cdx\n\ndesigned the CDX insurance model (Frederico)\n\n\nstatus:L2-deployment\n\nkicked off a list of L2 comparables, focused on business models and ecosystem incentivization (Frederico)\nKicking off work on incentives for L2 (Martin)\n\n\nwaku:rln-membership:\n\nProposing new RLN membership structures to the team - other than price per membership (Martin)\nFollow-ups to Franck’s response to our material we presented last week (Martin)\n\n\nstatus:SNT-staking\n\nContinue to monitor development and give feedback for the staking contract (Martin)\nAssist the SC team in further checks and definition of testing scenarios (Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nFinish plotter module tests and prepare PR (ongoing)\nImprove framework scraping interval (https://github.com/vacp2p/10ksim/issues/8)\nTry kubernetes API portforwading again\nSimulations:\n\nUpdated waku to 0.26\nChanged some parameters (flags, memory available, etc)\nResults with 3k matches perfectly with 1K in terms of bandwidth.\n\nBootstrap now doens’t crash. Caused by OOM previously.\n\n\n\n\n\n\neng-10ktool:vac:bandwidth-test\n\nVarious simulations, gathering additional data\nCalls with @Alberto, helping fix scraping\nAttempted to get hardware offloading working on existing ConnectX-4 LX adapters\n\nConclusion was it’s not possible (NVIDIA deprecated the offloading for CX4LX) but we’re now in a good place to try offloading on the new CX6s once they arrive\nCX6s are at the post office waiting for pickup -> installation\n\n\n\n\nadmin/misc\n\nMet with Codex team re: helping with Codex testnet\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nFinished js-waku sharding tests and prepared PR for review(@Florin)\nIssues found:(@Florin)\n\nAllow subscribeToContentTopic to use other cluster IDs\nApplicationInfo to PubsubTopic doesn’t take clusterId into consideration\n\n\n\n\nwaku:interop-testing\n\nCreated scripts to help reproduce bugs 2512 and 1034(@Florin)\nImprove logs for manual debug(@Florin)\nFound go-waku regression/issue(@Florin)\nWaku node health/reliability Issue 2369 - updated and Issue 165 - updated(@Roman)\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\nIssues found:(@Roman)\n\nMetadata might not always be available\nDescribe topic event transition between libp2p and peer manager level\n\n\nImprove unit test coverage for peer exchange(@Roman)\nImprove unit test coverage for Discv5(@Roman)\n\n\nwaku:test-automation-nwaku\n\nResultify fetchPeerExchangePeers(@Alex)\nSimplify imports(@Alex)\nFix and add test cases for Metadata protocol disconnecting light clients 2491(@Alex)\nMerge Peer Exchange Tests PR(@Alex)\nMerge Discv5 PR(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nrln-relay v2 integrated into nwaku: https://github.com/waku-org/nwaku/issues/2345\n\n\nsecure-channels:waku:ethereum-chat\n\nPrepare a Notion page containing a specification for the DCGKA algorithm.\nThink and propose solutions to some the DCGKA limitations.\nhttps://www.notion.so/DCGKA-Specification-5a0b67a3ce674ae3a5220b560015cd2c#8f9f17014e5a479788da2544d64a993e\nStudy Ramses’ notes in Notion\nRead about Jitsi in this paper\nRead about difficulties on decentralization of MLS section 8.5 of paper\n\n\nmisc\n\ngnark-rln implementation: https://github.com/vacp2p/gnark-rln\nadded multiple curves to rust stealth address repo: https://github.com/vacp2p/erc-5564-rs\nassist with deploying waku-rln-contract to waku-simulator\n\n\n\nvac:sc:: §\n\nstatus:staking-contracts-v1\n\nMerged coverage improvements\nFinished ironing out all pending certora rules\n\nhttps://github.com/logos-co/staking/pull/81\nhttps://github.com/logos-co/staking/pull/82\nhttps://github.com/logos-co/staking/pull/85\nhttps://github.com/logos-co/staking/pull/86\nhttps://github.com/logos-co/staking/pull/57\n\n\n\n\n\n\nstatus:community-contracts-token-import\n\nReviewed/discussed migration options for community vaults\n\nhttps://github.com/status-im/communities-contracts/issues/32#issuecomment-1997000297\n\n\n\n\n\n\nvac:maintainance/misc\n\nResearch on ENS Usernames to change release delay\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nMarkdown lint does not lint files, proposed fix- https://github.com/vacp2p/rfc-index/pull/25\nOpen the proposal to COSS changes - https://github.com/vacp2p/rfc-index/pull/4\n\n\nmisc\n\ncreate website repo - https://github.com/vacp2p/rfc-website\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nFinalized and share the related proposal()\nhttps://www.notion.so/privacy-preserving-validator-network-e92ab3e563074a538bb0e13e5c9321e6\n\n\nvalpriv:vac:tor-push-poc\n\nholesky validators registration and execution\n\n\nvalpriv:vac:tor-push-paper\n\nhttps://www.overleaf.com/project/6499e467346d9f56b2971caa\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nImplemented IMReceiving message for use with IDontWant message to improve GossipSub performance against v. large message. Experimental PR is available for review/discussion.\n\nThis is just a prototype experiment showing 40% bandwidth reduction and more than 10% latency reduction for 1MB messages.\nRequires feedback, as it needs new message inclusion\n\n\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nConducted results for different IDontWant/IMReceiving message use cases. The results are available in VAC forum post.\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegan examining current version of Codex system’s description\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nDrafted document about privacy improvements for state separation (Moudy)\nContinue work on monitoring (Marvin)\nDefined new milstones (Moudy)\nCompleted report about SE/DE in PDAGs see in Notion (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nchecked out this Hypernova implementation and continued reading LatticeFold (Rostyslav)\nDefined new milstones (Moudy)\n\n\nproofsystems:vac:benchmarks\n\nOverlooked at the paper and continued researching Nova vs. Supernova/ Nova vs. Halo2 recursion vs. aggregation (Moudy)\nDefined new milstones (Moudy)\nWorked on enhancing Nova-Scotia performance (Rostyslav)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nDefined new milestones (Moudy)\n\n\n"},"vac/updates/2024-03-25":{"title":"2024-03-25 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/03/25 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nStun protocol: Trying to understand how to implement the ICE lite protocol without breaking everything done so far https://github.com/status-im/nim-webrtc/pull/9\nSctp protocol: Unregister address after closing https://github.com/status-im/nim-webrtc/pull/11\nnim-libp2p: Add comments https://github.com/vacp2p/nim-libp2p/pull/960\nDataChannel: First draft on closing stream https://github.com/status-im/nim-webrtc/pull/12\nUDP/Dtls: small fixes\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nfeat: add max number of elements to non-prio queue - https://github.com/vacp2p/nim-libp2p/pull/1077j\n\n\nnimlibp2p:vac:maintenance\n\nvarious PR reviews\npreparing for hiring interviews and interviewing\n\n\n\nvac:tke: §\n\nwaku:general-incentives\n\nContinuing the discussion with the Waku team on the marketplace idea (Martin)\nreviewed the discussion about Waku marketplace (Frederico)\n\n\nwaku:rln-membership:\n\nScoping out and working on the deliverables for RLN design (Martin)\n\n\nstatus:SNT-staking\n\nFull review of the MP logic within the smart contract (Martin)\nSupporting the SC team ad hoc (Martin)\n\n\nstatus:L2-deployment\n\nReviewing airdrop strategies of existing L2s (Martin)\nlisted business models and ecosystem incentivization of L2 comparables (Frederico)\n\n\ncodex:cdx\n\nRevisiting fundraising docs and starting a closer cooperation with Matt (Martin)\ndesigned the CDX insurance model as a liquidity pool (Frederico)\nevaluated token allocation and initial distribution of comparables (Frederico)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nFinish plotter module tests and prepare PR (ongoing)\nThanos PR merged (https://github.com/vacp2p/10ksim/pull/15)\nCreate class to manage data (https://github.com/vacp2p/10ksim/pull/16).\nhardware offloaded for Waku testing\n\nBuilt 24 new Kubernetes workers, configured them with static IPs and all tuning\nGot new CX6 cards updated, configured, installed and working\nAchieved hardware offloading; but:\nRunning a Waku workload, two interesting things happened\n\nWhen we started the publisher, the load increased until the physical nodes become so unusably slow that they needed IPMI intervention to come back to life\nChecking the offloadeded flows during the test (prior to publishing) showed no offloaded routes or flows.\n\n\nWe need to figure out how to get our workload offloaded correctly.\n\n\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nMerged js-waku sharding tests PR(@Florin)\nAdd repro scripts folder(@Florin)\nInterop sharding tests draft PR(@Florin)\nRechecked some fixes for older bugs(@Florin)\nGo-waku sharding tests pr(@Roman)\nIssues found:\n\nautosharding resolves content topics to wrong shard(@Florin)\ndont harcode clusterid for autosharding in go-waku(@Florin)\nsubscription not found when node is started with —pubsub-topic flag(@Florin)\nonly receive messages if someone subscribes explicitly via REST API to a pubsubTopic(@Florin)\nephemeral field is ignored(@Florin)\ndata race occurs when publishing to unsubscribed pubSubTopic(@Roman)\n\n\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager PR 1062 - merged(@Roman)\nImprove unit test coverage for Discv5 PR 1051 - pending on 1059(@Roman)\nIssues found:\n\nrace condition while setting boot nodes for Discv5(@Roman)\n\n\n\n\nwaku:test-automation-nwaku\n\nMetadata protocol disconnecting light clients(@Alex)\n\nMerged PR\n\n\nPeer & Communication Management(@Alex)\n\nContinue implementing tests\nFix minor bug, peerId duplicated when adding to PeerStore\n\n\n\n\nwaku/maintenance-nwaku\n\nFix macos tests(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\ninvestigate and improve robustness of rln-relay, still in progress - https://github.com/waku-org/nwaku/pull/2537, https://github.com/waku-org/nwaku/pull/2545\n\n\nsecure-channels:waku:ethereum-chat\n\nCreated a PR with a first version of the RFC on the proposal for the decentralized communication protocol.\nhttps://github.com/vacp2p/rfc-index/blob/ETH-SECPM-DEC/vac/raw/Decentralized%20messaging%20Ethereum.md\nStarted exploring UPKE as a potential tool for the decentralized protocol.\nDiscussed with Ugur some aspects of DCGKA around causal order.\n\n\nsecure-channels:waku:ethereum-chat\n\nAttached some comments on DCGKA specification in notion\nResearch about causal ordering and create a small doc about it in notion\nQuickly check the paper that compares and analyzes DCGKA (https://eprint.iacr.org/2022/1531.pdf)\nDiscuss with Ramses about decent SIWE, complexity and causal ordering.\nStarted to examine DCGKA implementation to understand which causal ordering is used in this repo\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-token-import\n\nstarted Vault migration PR https://github.com/status-im/communities-contracts/pull/62\n\n\nvac:maintainance/misc\n\nResearch overview on DEX aggegators\n\n\nstatus:staking-contracts-v1\n\nWorked on deposit cooldown period implementation\n\nBunch of questions came up\n\nDiscussion: https://github.com/logos-co/staking/issues/14#issuecomment-2007432214\n\n\nWIP branch: https://github.com/logos-co/staking/commit/8c5dd440404d6184937fa65deec67e00b24e159b#diff-b710313a5571054e746fc0e0d1332e5894fc76a55ffb035711d912c00bf8f826\n\n\n\n\n\nvac:rfc: §\nLast week:\n\nmisc\n\nOpened waku-metadata to move to draft - https://github.com/vacp2p/rfc-index/pull/6\nWorked on workflow to sync rfc website - https://github.com/vacp2p/rfc-index/pull/27\nCreated workflow fix for markdown lint - https://github.com/vacp2p/rfc-index/pull/25\nFixed broken links - https://github.com/vacp2p/rfc-index/pull/26\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nFeedback waiting competing/ proposal (https://docs.google.com/document/d/1UNOJfA-4f6tco3ozuiyLIbfDkf70Mh_6OqEfB8vmblE/edit?usp=sharing)\n\n\nvalpriv:vac:tor-push-poc\n\ncould not launch holesky validators yet this week.\n\n\nvalpriv:vac:tor-push-paper\n\nFinished changes as per feedback; next feedback round\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nPlayed with IDontWant messags with different arrangements. Mainly investigated reduced message sending with/without hello messages.\nReduced sending shows nearly 5-10% latency and 20-25% bandwidth reduction when message sizes reach beyond 600 KB.\nThe findings are available as notion page\n\nInterestingly {Reduced sending + IDontWant} without IHAVE messages shows similar performance to {Reduced sending + IDontWant + IHAVE}\n\n\n\n\nzk:codex:storage-proofs-open-problems-review\n\nFinish examining current version of Codex system’s description\nRead Balazs’ notes on Plonk\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nWorked on Defining state separation’s SE and DE using PDAGs (Moudy)\nLooked at nullifiers and their role in the architecture (Moudy)\nWorked on different components for State Separation Architecture (Moudy)\nResearched accumulators and trying to study how to integrate them (Moudy)\nUpdated report according to the meeting with Moudy about SE/DE in PDAGs (Ugur)\nReading on scalable privacy NC + state of art accumulation (Ugur)\nContinued with monitoring (Marvin)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nchecked out PNova implementation + finished reading LatticeFold (Rostyslav)\nBegan reading Mangrove (Marvin)\n\n\nproofsystems:vac:benchmarks\n\nStill working on the paper since new findings are arising (i.e. Nova Scotia not using Groth16) (will focus on that this week) (Moudy)\nDealt with server issues + prepared paragraph on difference in Nova-Scotia and Nova-Bellman (Rostyslav)\n\n\n"},"vac/updates/2024-04-02":{"title":"2024-04-02 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/04/02 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFix the WebRTC CI on Windows/MacOS\nMbed-TLS: improve installation/code generation\nAddress all the comments on UDP\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nBump libp2p and fix compilation issue - https://github.com/status-im/nimbus-eth2/pull/6132\nBump libp2p and use new gossipsup constructor - https://github.com/status-im/nimbus-eth2/pull/6148\n\n\nnimlibp2p:vac:maintenance\n\nReviewing PRs\n\n\n\nvac:tke: §\n\nwaku:general-incentives\n\nPossibly continuing marketplace discussion with Waku (Martin)\n\n\nwaku:rln-membership:\n\nWorking on the proposal for RLN design (Martin)\n\n\nstatus:SNT-staking\n\nSupporting the SC team ad hoc (Martin)\nDiscussing using the staking contract at the org level (Martin)\n\n\nstatus:L2-deployment\n\nFurther research into airdrop and incentive strategies of existing L2s (Martin)\n\n\nnomos:mixnet-incentives\n\nadjusted pricing function to account for measurement costs (Frederico)\nverified that the modifications of the reward split scheme are correct (Frederico)\n\n\nnomos:cryptarchia-wealth-concentration-estimated-stake\n\nreviewed blog posts (Frederico)\n\n\ncodex:cdx\n\nreviewed latest marketplace proposal (Fred\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nDelayed simulations.\nFinished plotter module tests ready to review (https://github.com/vacp2p/10ksim/pull/19)\nFinished data class, related PR already merged (https://github.com/vacp2p/10ksim/pull/16)\nImprovements for scrapping, related and merged PRs (https://github.com/vacp2p/10ksim/pull/17 and https://github.com/vacp2p/10ksim/pull/18)\nInvestigate attacknet (https://twitter.com/ethPandaOps/status/1769773689979974006)\n\n\neng-10ktool:vac:bandwidth-test\n\nMany many fixes to get Kubernetes with OpenvSwitch + offloading + VMs working\n\nReinstalled 3 nodes with new Debian + Proxmox flavour\nInstalled Mellanox OFED drivers\nExperimented with VirtIO network, managed to eventually get SR-IOV and Virtual Functions working\n\n\nWaku - Benchmarked 1-worker (one worker as one eighth of a 64 core node) cluster\n\nIndications are we can scale to ~14k nodes if scaling is linear, vs CPU usage observed on 1-worker\nHad 243 Waku nodes, including publishing, running on the worker or 1/8th node with headroom to spare\nNetwork offloading appears to about 2x as efficient CPU wise when running Waku\n\n\nFurther fixes for offloading setup once SR-IOV was working\nWaku - Reinstalled 24 workers, then wiped them all and reinstalled 8 of them :(\nDiagnosed incredibly complicated packet loss issues (which turned out to be caused by cloned VMs - note to self - clean up /etc/machine-id next time!)\nWaku - Benchmarked 8-worker cluster (1 physical 64-core), scaled to 1200 nodes, hit major issue with Calico\n\nDocumented here - https://github.com/projectcalico/calico/issues/8676\n\n\nAdded caching to Harbor, further investigated removing Harbor rate limits\nDiscovered that adding multiple jobservice workers to Harbor makes rate limits higher\n\nDeployed 6 jobservice workers in Harbor\n\n\nRemoved Vaxis and Nia from Kubernetes to help with CPU accounting since they host worker VMs\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nSharding interop tests(@Florin)\n\nAdded around 70 new tests so far\n\n\nIssues found:\n\nnode crashes when there are many flags to the docker start command(@Florin)\nnode can be started on multiple clusters(@Florin)\nall REST API calls return 200 with empty response(@Florin)\n\n\nSharding tests update(@Roman)\nClosed issue: data race occurs when publishing to unsubscribed pubSubTopic(@Roman)\n\n\nwaku:test-automation-go-waku\n\nMerged Discv5 PR(@Roman)\nClosed issue: race condition while setting boot nodes for Discv5(@Roman)\n\n\nwaku:test-automation-nwaku\n\nPeer & Communication Management(@Alex)\n\nContinue implementing tests\nFound a couple weird behaviours\n\n\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nFinish the examination DCGKA ref implementation repo\nStarted to write a report about the examination of vector clocks used in DCGKA ref implementation\nChecked that there is the motivation why we chose DCGKA in rfc\n\n\nzerokit:vac:maintenance\n\ngithub removed semaphore commit we used, was fixing CI issue\n\n\n\nvac:sc:: §\nvac:rfc: §\n\n\n\nvac:rfc-process-update\n\nWorked on workflow to sync rfc website - https://github.com/vacp2p/rfc-index/pull/29\nAdded some format changes to eth-secpm-dec - https://github.com/vacp2p/rfc-index/pull/28\nRfc-website is ready - https://github.com/vacp2p/rfc-website/tree/mas\n\n\n\n\n\nvac:dr: §\n\nunstructured-p2p-improvements-survey\n\nLooked into different aspects of libp2p specifications (including gossipsub versions and corresponding discussions). Also looked into the corresponding nim-libp2p works.\nFollowed discussions/PRs on libp2p specs and libp2p implementations\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nRefined the State Separation PDAGs doc and add changes together with Ugur (Moudy + Ugur)\nWorked on gathering important components for state separation (Moudy)\nResearched and identified accumulators/nullifiers to integrate (Moudy)\nDiscussed monitoring with Moudy, and continued with monitoring (Marvin + Moudy)\nDiscussed with Moudy about PDAG report and next version of proposal on state-separation (Ugur + Moudy)\nStarted to write a draft of the next version of proposal on state-separation (Ugur)\nRead about mutator set including Merkle Mountain Range and Bloom filters (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\ncheck out Sirius docs (Rostyslav)\nstarted writing LatticeFold writeup (Rostyslav)\nWork on write up for Mangrove (Marvin)\n\n\nproofsystems:vac:benchmarks\n\nKept working on the paper since new findings are arising (i.e. Nova Scotia not using Groth16) (Moudy)\nConducted server testing (Rostyslav)\n\n\n"},"vac/updates/2024-04-08":{"title":"2024-04-08 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/04/08 §\ngeneral §\n\nLogos offsite Athens: many Vac CCs are attending\n\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nMerge UPD https://github.com/status-im/nim-webrtc/pull/8\nRework Stun https://github.com/status-im/nim-webrtc/pull/9\n\nMandatory for browser to browser\n\n\n\n\nnimlibp2p:vac:maintenance\n\nFind and fix a (nasty) bug in both valueOr/withValue templates\n\nPR: https://github.com/vacp2p/nim-libp2p/pull/1079\n\n\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nfix: remove explicit param from GossipSubParams constructor - https://github.com/vacp2p/nim-libp2p/pull/1080\nReviewing PRs\nWorking on using gossipsub score to penalize peers when their non-prio queue reaches the limit. No PR yet, only local tests.\n\n\n\nvac:tke: §\n\nadmin/misc\n\ntravelled to All-hands in Athens (Frederico, Martin)\n\n\nnomos:mixnet-incentives\n\nunderstodd the parameter that controls the loss of competitiveness experienced by a Sybil attacker (Frederico)\n\n\ncodex:cdx\n\nreviewed materials about Codex in view of next week’s offsite (Frederico)\nReview open questions and provide input (Martin)\n\n\nwaku:general-incentives\n\nLooking at Swarm city\n\n\nwaku:rln-membership:\n\nPresent and collect feedback on the RLN Proposal (draft, Martin)\nStart a structured discussion and follow-ups based on this document in Athens (Martin)\n\n\nstatus:SNT-staking\n\nMeeting the SC team in Athens (Frederico, Martin)\nFollowing-up on the org fundraising talks with Carl in Athens (Martin)\n\n\nstatus:L2-deployment\n\nFurther brainstorming for product differentiation in Athens (Frederico, Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nRestart simulations (delayed)\nImprove scrapping tests (https://github.com/vacp2p/10ksim/pull/20https://github.com/vacp2p/10ksim/pull/20)\nAdd option to download node logs (https://github.com/vacp2p/10ksim/pull/21 after 20 is merged)\nFinished rebuild of Kubernetes nodes, optimisations\nRan various simulations at a few different scales\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nMerged sharding tests PR part 1(@Florin)\nSharding tests update PR 1060 - in progress(@Roman)\nIssue found: subscription to many static sharding topics hangs(@Roman)\n\n\nwaku:interop-testing\n\nFix broken allure history links(@Florin)\nLight push tests in progress(@Florin)\nIssues found:(@Florin)\n\nstrange errors when light pushing messages with payload >= 300 kb for both nwaku and go-waku\nlightpush on non subscribed pubsub topic hangs\nlightpush fails with Failed to request a message push: dial_failure after the peer node restarts\nmissing RequestId field error when lightpush has unexpected payload of content topic\n\n\n\n\nwaku:test-automation-nwaku:\n\nPeer & Conn Mgmt testing. Almost finished, need to sort out some issues in a meeting with some waku person.(@Alex)\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nUpdate the report about vector clocks in reference impplementation of DCGKA.\n\n\nzerokit:vac:maintenance\n\ncontinued fixing semaphore related issues\n\n\n\nvac:sc:: §\n\nadmin/misc\n\noffsite\n\n\n\nvac:rfc: §\n\nadmin/misc\n\noffsite\n\n\n\nvac:dr: §\n\ngossipsub-improvements-paper\n\nLooked into different program control aspects in nim (semaphores, Futures, Queues, Async framework), needed for message staggering\nLooked into the possible changes required for message staggering (still a work in process)\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nWorked on the draft of the State Separation PDAGs doc (Moudy)\nContinued research about accumulators and mutator sets (Moudy)\nMet with Ugur for PDAGs + Accumulators (Moudy)\nDrafted list of components (Moudy)\nFinish the first draft of Mutator set in Notion (Ugur)\nChecked the page about MMRs and Mutator set that Moudy notion page (Moudy + Ugur)\nStarted to write reports about the candidates of nullifiers for our state separation (Ugur)\nUpdate the all-in-one document for state separation and share with Moudy (Ugur + Moudy)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nchecked out Sirius code (Rostyslav)\ncontinue writing LatticeFold writeup (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\ncontinued working on Mangrove (Marvin)\ncontinued conducting server testing, got prelimenary results (Rostysla\n\n\n"},"vac/updates/2024-04-15":{"title":"2024-04-15 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/04/15 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nHuge rework on Stun protocol https://github.com/status-im/nim-webrtc/pull/9 (ready for review)\nRework Dtls protocol to take account of the Stun rework https://github.com/status-im/nim-webrtc/pull/10 (ready for review aswell)\n\n\n\nvac:tke: §\n\nadmin/misc\n\nattended the All-hands presentations and discussions (Frederico, Martin)\ntraveled back from Athens (Frederico, Martin)\n\n\nnomos:mixnet-incentives\n\npresented the current state of the mixnet incentives to the Nomos team (Frederico)\n\n\ncodex:cdx\n\ndiscussed the missing parts of the Tokenomics model in the Codex offsite (Frederico)\ndiscussed Codex L2 use case with Cyprian (Frederico)\ndiscussed Codex tokenomics with Finance team (Frederico)\nReview open questions and provide input ahead of the Codex offsite (Martin)\n\n\nstatus:SNT-staking\n\ndiscussed staking and aggregation with the SC team (Frederico, Martin)\n\n\nwaku:general-incentives\n\nAnalyzing the new ideas discovered in Athens - RLN ID and utilization of the payment mechanism for the RLN purchase (Martin)\n\n\nwaku:rln-membership:\n\nfollow-ups based on the discussion in Athens (Martin)\n\n\nstatus:L2-deployment\n\nMeeting and brainstorming with Cyprian in Athens (Martin, Frederico)\n\n\n\nvac:dst: §\n\nadmin/misc\n\nVarious contributors @ Athens for Logos Offsite\nCollaborations with Codex\n\nnode designs (incl. pricing)\ncollateral scaling mechanisms (“dynamic collateral”)\n\n\nTalked with Nomos about testing mixnet and graph visualisation\nDiscussed Nomos testing and DST service needs\nMet with Yiannis from Probe Lab\n\nExploring areas to collab; focus was on partnerships, what areas DST can help with, “low/zero cost” knowledge exchange\n\n\nTeam: Discussed future directions, next few weeks to months worth of work\n\n\neng-10ktool:vac:bandwidth-test\n\nInvestiage the usage of kustomize for deployment\nUpdate scrapper test and utils merged https://github.com/vacp2p/10ksim/pull/20 Pod log downloader to be merged now https://github.com/vacp2p/10ksim/pull/21\nMultiple attempted runs towards 10K\n\nFirst successful 10K run 2024-04-15 10:30am in Athens at 10,847 nodes\n\n\nImprovements:\n\nenable NUMA support in VMs for better scale\nall nodes now boot automatically as lab comes up\nImplemented critical improvements to large scale simulations per Calico team.\n\n\nMeetings with Waku team\n\nTalked about next deliverables and checked their paper about Waku\nDiscussed Nwaku vs go-waku CPU usage and scalability, needs; potential waku network sharding strategy (dynamic sharding); current Waku testing results, future needs\nDiscussed need for Waku tracing - need to be able to output a simple Received message ID: messageID message from Waku to stdout.Met with Ivan (Waku)\n\n\n\n\n:vac:lab\n\nScaling improvements, added 3 hosts, improved power distribution, migrated all hosts to OVS, Codex preparation work, NVMe install + debug.\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nLight push tests merged(@Florin)\nStore draft pr(@Florin)\nIssues found:\n\ncontentTopic naming not consistent in the store response where is’s content_topic(@Florin)\nnode doesn’t store messages if relay is disabled(@Florin)\nfailed to negotiate protocol: protocols not supported: [/vac/waku/store/2.0.0-beta4] when the peer node has store disabled(@Florin)\n\n\n\n\nwaku:test-automation-sharding\n\nSharding tests update(@Roman)\nClosed subscription to many static sharding topics hangs(@Roman)\nIssue found: message won’t be sent over from node1 to node2 with sharded topic subscription(@Roman)\n\n\nwaku:maintenance-nwaku\n\nAdd ARM64 Docker support for Linux/MacOS(@Roman)\n\n\nwaku:test-automation-rln\n\nRLN relay tests draft PR(@Roman)\n\n\nadmin/misc\n\nOffsite(@Alex)\n\n\n\nvac:acz: §\nLast week:\n\nzerokit:vac:zerokit-v0.5\n\nplanning issue for zerokit v0.5.0\nwip: remove tree height 32 resources\n\n\nrlnp2p:waku:rln-relay-enhancements\n\nbrought down tree sync time by parallelizing rpc calls\n\n\nsecure-channels:waku:ethereum-chat\n\nPlanning for Secure channels with Ethereum\nResearch on possible solutions to metadata management in DCGKA (use of UPKE and stealth addresses)\nIdea: zk-MLS\n\n\nadmin/misc\n\nDiscussions at Logos All hands offsite with various projects on how the ACZ team plugs into their research & engineering\nFirst Vac ACZ offsite, meeting notes. Planning for Secure channels with Ethereum done.\nmost CCs ooo after travel from All hands offsit\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nLogos All-Hands Offsite\n\nSee notes: https://notes.status.im/et-wl6KFTYW4bjtKUpM5tw?view#SC1\n\n\nSwap Aggregator Research\n\nAirswap Research notes\n\nhttps://notes.status.im/fJ2YoaiBS4qd94RtK2zHJA?view\n\n\n\n\n\n\n\nvac:rfc: §\n\nwaku:core-rfc-updates\n\nWorked on rln relay and waku executables for waku-rln-relay, will be creating a new pr next week\n\n\nmisc\n\nreviewed rfc-website, found new problems and open web development tickets with acid-in\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nfeat: behaviour penalty when non-priority queue reaches maxNumElementsInNonPriorityQueue https://github.com/vacp2p/nim-libp2p/pull/1083\n\n\nnimlibp2p:vac:maintenance\n\nupdate libp2p branch when unstable changes https://github.com/status-im/nimbus-eth2/pull/6202\nOpenend issue peer doesn’t respect backingOff https://github.com/vacp2p/nim-libp2p/issues/1084\nCoding interview\nReviewing PRs\n\n\n\nvac:dr: §\n\nunstructured-p2p-improvements-survey\n\nLooked into the gossip issue regarding large number of small messages in farcaster network\nLooked into different gossipsub specifications/discussions etc.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on message forwarding from priority/non-priority queues for possible performance improvements and message staggering. Still a work in progress. Expected to complete in this weak.\n\n\n\nvac:nes: §\n\nadmin/misc\n\nMoudy + Marvin all week @ All hands offsite\nUgur 2 days off + 1 day @ACZ offsite\n\n\nstate-separation:vac:state-separation-doc\n\nCreated a draft about the possible usages of Mutator sets in our nullifier systems in notion (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nchecked out Sirius code (Rostyslav)\ncontinue writing LatticeFold writeup (Rostyslav)\n\n\n"},"vac/updates/2024-04-22":{"title":"2024-04-22 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/04/22 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nreview stun pr\nAddress comments on STUN protocol\nResearch on ICE protocol\nStart implementing ICE protocol\n\n\nnimlibp2p:vac:maintenance\n\nuse a mock rng in tests https://github.com/vacp2p/nim-libp2p/pull/1085\ndebug ping interop test\n\n\n\nvac:tke: §\n\ncodex:cdx\n\nreviewed Codex priority list and document outcomes (Frederico)\nread the whitepaper (Frederico)\ncaught up with Wings’ proposal for collateral incentive model (Frederico)\nReviewing Codex offsite outcomes and reading the whitepaper (Martin)\n\n\nnomos:mixnet-incentives\n\ncaught up with the current state with Marcin (Frederico)\nconcluded analysis of parameter to control competitiveness loss of sybil attackers\n\n\nstatus:L2-deployment\n\njoined discussions with Cyp (Frederico)\nStarting work on L2 profiling and attempting to narrow down key narratives/features (Martin)\n\n\nwaku:general-incentives\n\nReviewing protocol design decisions and changes made in Athens, mapping out implications for the incentive design (Martin)\n\n\nwaku:rln-membership:\n\nReviewing the RLN decisions and changes made in Athens, mapping out implications for the RLN design (Martin)\n\n\nstatus:SNT-staking\n\nResearch into swap feature in cooperation with the SC team (Martin)\n\n\n\nvac:dst: §\n\nadmin/misc\n\nMeetings with Codex, prep for Codex testnet\n\n\neng-10ktool:vac:bandwidth-test\n\nBegan implementing message reliability measurement using message ID logs\n\nMessage tracking code\nVisualisation code\n\n\nRan several simulation attempts, ran into network issues believed related to the power event. Found several things misbehaving\nRead Waku paper\nControl plane improvements, Kubernetes and Ceph cleanup, replacement parts for control plane\nNetwork weirdness, still sorting\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nMerged store tests part 1(@Florin)\nUpdate tests based on fixes(@Florin)\nIssue reopened(@Florin)\n\n\nwaku:test-automation-sharding\n\nGo-waku sharding tests update(@Roman)\nNim sharding tests(@Alex)\nIssue found: message won’t be sent over from node1 to node2 with sharded topic subscription - would need to be separated from PR1060(@Roman)\n\n\nwaku:test-automation-rln\n\nRLN relay tests(@Roman)\nIssue found: RLN in on-chain dynamic mode not working\n\n\nwaku:test-automation-nwaku\n\nPeer & Connection Management tests(@Alex)\nIssues found:(@Alex)\n\nPeerInfo instance affects listed protocols\nSome PeerStore metadata is not filled in\nPeer Reconnection not working?\nENR shouldn’t be used for pruning\n\n\n\n\nadmin/misc\n\nStarted to read the nomos docs and begin to familiarize myself with nomos(@Florin)\nTried to build and run nomos node and nomos specs(@Florin)\nConducted interview with Sandarv on Thursday(@Roman)\nOOO one day (@Florin)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancements\n\nresultify and clean up rln-relay code\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nBlog post/RFC on Light RLN verifiers\n\n\nzerokit:vac:zerokit-v0.5\n\nQoL traits to the Hasher assoc.Type\nRemoved tree height 32 from rln\n\n\nsecure-channels:waku:ethereum-chat\n\nGeneration of flow diagrams for several MLS procedures\nResearch on improving the privacy in DCGKA\n\n\nadmin/misc\n\nreduced availability since one CC is off (Ugur)\n\n\n\nvac:sc:: §\nvac:rfc: §\n\nwaku:core-rfc-updates\n\ncreated rln-relay update pr, opened discussion for more to stable - https://github.com/vacp2p/rfc-index/pull/32\nmerged WAKU-METADATA move to draft - https://github.com/vacp2p/rfc-index/pull/6\n\n\nmisc\n\nfound new problems with rfc-website, in contact Jhino to fix\nstarted reading Codex spec marketplace - https://github.com/codex-storage/codex-research/blob/master/design/marketplace.md\n\n\n\nvac:dr: §\n\nunstructured-p2p-improvements-survey\n\nStudied/investigated different techniques/works targetted on perfromance improvements against message sizes and counts\nLooked for funding opportunities in the Ethereum eco-system that align with our research directions\n\n\nzk:codex:storage-proofs-open-problems-review\n\nDiscussed with Codex their specific needs in terms of documents, as well as received their list of papers and three problems in full detail. Discord thread and List\n\n\nadmin/misc\n\nWork on notes concerning BloomFilter, MMR, and Field Merkle.\nBegan working on a document on tangibles\n\n\nvac:dr:anon:vac:waku-anonymity-analysis\n\nRead Waku Adversarial Models and Tor Push.\nStarted documenting Waku Anonymity Analysis - WiP.\n\n\n\nvac:nes: §\n\nadmin/misc\n\nUgur from 15 to 23 April\nMarvin from 15 to 17 April\n\n\nstate-separation:vac:state-separation-doc\n\nWorked on defining and identifying State Separation Components (Moudy)\nRead Ugur’s notes on Mutators 1 and 2 (Marvin)\nWork on notes for MMR, Bloom Filters (potentially more useful for DR) (Marvin)\n\n\nproofsystems:vac:benchmarks\n\nAlmost finished the draft of the Benchmarks paper (still some details to add) (Moudy)\nconducted conducting server testing and got 6 PRs merged (Rostyslav)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nStarted looking at existing ZkVms in order to use them to add privacy on top (Moudy)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished writing LatticeFold writeup\n\n\n"},"vac/updates/2024-04-29":{"title":"2024-04-29 Vac weekly","links":["0x520434D97e5eeD39a1F44C1f41A8024cB6138772"],"tags":["vac-updates"],"content":"Vac 2024/04/29 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nYet another rework on Stun protocol: https://github.com/status-im/nim-webrtc/pull/9\n\nBetter error management\nImplement a Lite (and server sided) version of the ICE protocol.\nrewrite tests & stunMessageHandler\nImplement BindingRequest\n\n\n\n\nnimlibp2p:vac:maintenance\n\ndebug ping interop test - https://github.com/vacp2p/nim-libp2p/pull/1086\nopened issue about potential js-libp2p bug - https://github.com/libp2p/js-libp2p/issues/2505\nlibp2p dev process\n\n\n\nvac:tke: §\n\nadmin/misc\n\nprepared an onboarding doc for new hire (Frederico)\nupdated TKE landing page (Frederico)\n\n\ncodex:cdx\n\nupdated the TKE litepaper with offsite discussion and whitepaper (Frederico)\nReviewing Codex offsite outcomes and reading the whitepaper (Martin)\n\n\nnomos:mixnet-incentives\n\nread the new mixing gadget proposal (Frederico)\nadapted the Mixnet incentivization work with new proposal (Frederico)\n\n\nstatus:L2-deployment\n\njoined discussions with Cyp (Frederico)\n\n\nwaku:general-incentives\n\nReviewing protocol design decisions and changes made in Athens, mapping out implications for the incentive design (Martin)\n\n\nwaku:rln-membership:\n\nReviewing the RLN decisions and changes made in Athens, mapping out implications for the RLN design (Martin)\n\n\nstatus:SNT-staking\n\nResearch into swap feature in cooperation with the SC team (Martin)\n\n\nstatus:L2-deployment\n\nStarting work on L2 profiling and attempting to narrow down key narratives/features (Martin)\n\n\n\nvac:dst: §\n\nadmin/misc\n\nDeployed 250TB(x2) volume for Codex, created VacLab + Kubernetes access for Codex staff\n\n\neng-10ktool:vac:bandwidth-test\n\nFirst version of message tracking + data dumping done\nRan various simulations - fixed issues blocking sims, fixed issue with new bootstrap sim\n\nFound weird Yamux behaviour still exists\nNo bootstrap bias found\n\n\nKubernetes cleanup, instability fixes, performance fixes\nDeployed iBGP between all Kubernetes hosts and migrated LoadBalancers into MetalLB BGP\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nRefactoring PR that adds common steps and removes flakyness(@Florin)\nReviewed and commented on Roman’s PR(@Florin)\nReopened: contentTopic naming not consistent in the store response bug(@Florin)\n\n\nwaku:maintenance-js-waku\n\nuse nwaku:v0.27.0 and adjust tests for it(@Florin)\nunskip fixed test(@Florin)\n\n\nnomos:test-automation-cryptarchia\n\nMeeting with Nomos devs(@Florin)\nRead more of Nomos specs and start working at a test plan(@Florin)\n\n\nwaku:test-automation-sharding\n\nSharding tests update(@Roman)\nReviewed PR(@Alex)\nStore Issue(@Alex)\n\n\nwaku:test-automation-nwaku\n\nPeer & Connection Management Reviewed PR(@Alex)\n\n\nwaku:test-automation-rln\n\nRLN relay tests in progress(@Roman)\nbug: RLN in on-chain dynamic mode not working closed(@Roman)\nBegin implementing tests. Draft PR(@Alex)\n\n\nadmin/misc\n\nInterviewing and reviewing code challenges for QA candidates(@Florin and @Roman)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancements\n\nimproved ci for rln-relay enabled images\ndiscussed with nwaku team and increased recovery time for rln-relay failure to 1 minute\nimproved error handling/exception raising\nLazyIMT approach partially downstreamed to waku-rln-contract and deployed on cardona zkevm-testnet\nenhanced rln-db-inspector capabilities by detecting empty leaves\nresultify rln-relay 1/n reviews addressed and merged\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\npresented rln: zero to hero to nwaku+chatsdk team @ status all hands, explained all versions of rln and their trade-offs\nupdates to blog post/RFC on Light RLN verifiers\n\n\nsecure-channels:waku:ethereum-chat\n\nUpdated the DCGKA’s Notion with aspects concerning privacy\nUpdated flow diagrams for MLS\nStart working on flow diagrams for the DCGKA.\nResearch on the best approach to UPKE.\n\n\nadmin/misc\n\nDaniel + Aaryamann @ status all hands: agenda\npresented stealth address scheme over Waku to waku + status team\nreduced availability for a few CCs\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nSwap Aggregator Research\n\nResearched CoW Protocol and Cow Swap\n\nNotes (WIP): https://notes.status.im/5q0HiAKORf6V1fQgong31Q?both\n\n\nResearched Metamask Swap\n\nNotes on the Metamask Swap research https://notes.status.im/5yw7WvqRQqaREdJ0hbyWoQ?view\n\n\n\n\nZodiac Modules\n\nReviewed code of SAFE and zodiac modules to get a better understanding of the system\n\nhttps://github.com/gnosisguild/zodiac-modifier-roles/tree/main\n\n\n\n\n\n\n\nvac:rfc: §\n\nmisc\n\nCreated an open issue to use rfc-website repo, but some problems are still being worked on. - https://github.com/status-im/infra-misc/issues/271\nRead Nomos docs on Notion, suggesting a raw rfc for Block format for base layer. Opened disussion if good for first rfc.\nRead codex docs in codex-research repo. Started Codex Marketplace raw rfc, not complete, should be able to complete a draft next week and try to get feedback from Codex - https://github.com/vacp2p/rfc-index/blob/codex-marketplace/codex/marketplace.md\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nCompleted staggered message sending mechanism, for large messages (making some fixes: getting LPStreamClosedError in some runs)\nWorked on resetting the build environment for shadow. chronos/chronicles upgrade was causing some compilation errors\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegan reading WARPfold, Beyond Circuit\n\n\nvac:dr:anon:vac:waku-anonymity-analysis\n\nContinued working on Waku Anonymity Analysis - WiP.\nRead about libp2p and GossipSub and started documenting - WiP\nLooked into options that could lower the latency for Tor Push\n\nOther anonymity networks and mixnet options such as I2P, Loopix, etc.\nSome P2P options as well (but they are not as widely used as Tor)\nlooking into Dandellion++ and its Comparison to Tor Push.\n\n\n\n\n\nvac:nes: §\n\nadmin/misc\n\nUgur ooo from 15 to 23 April\n\n\nstate-separation:vac:state-separation-doc\n\nConducted some research on what is needed to have all the essential components of the state separation (transaction types, cryptography behind it, trees, filters, etc) (Moudy)\nWorked on monitoring document (Marvin)\nStarted to work on trees in state-separation (Ugur)\nCrated a doc about privacy in executions note (Ugur)\n\n\nproofsystems:vac:benchmarks\n\nDecided to rewrite the benchmarks paper as a detailed blogpost (need to conduct and update some pieces of research) (Moudy)\nInvestigate Halo2 high iterations bug (Rostyslav)\nPrepared paragraph on Halo2 bug (Rostyslav)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nHad a high level look at existing ZkVms (Moudy)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStarted reading about Greco zk proofs (Rostyslav)\nCheck out Jolt implementation (Rostyslav)\n\n\n"},"vac/updates/2024-05-06":{"title":"2024-05-06 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/05/06 §\nvac:p2p: §\n\nadmin/misc\n\nCCs ooo\n\n\nnimlibp2p:vac:webrtc-transport\n\nAddress comments on Stun protocol https://github.com/status-im/nim-webrtc/pull/9\n\n\n\nvac:tke: §\n\nadmin/misc\n\nonboarded our new team member (Frederico, Martin)\nGetting familiar with protocols (Juan)\nFew introductory meetings (Juan)\n\n\ncodex:cdx\n\nreviewed and complemented the TKE part of Codex litepaper (Frederico)\nReviewing Frederico’s changes to the litepaper (Martin)\nProvided some feedback into Codex (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nreviewed and restructured of the previous work (Frederico)\n\n\nwaku:general-incentives\n\nFollowing internal debates and docs mapping progress from Athens (Martin)\n\n\nstatus:SNT-staking\n\nResearch into swap feature in cooperation with the SC team, chats with potential partners (Martin)\n\n\nstatus:L2-deployment\n\nFurther work on L2 economic model, focusing on fundametal questions and constraints (Martin)\n\n\n\nvac:dst: §\n\nadmin/misc\n\nMeetings to discuss milestones\nFinished deploying CubeFS for the Codex team (for accessing storage)\n\n\neng-10ktool:vac:bandwidth-test\n\nAdjusted Kubernetes workers to the new network structure\nAlberto ran into deployment issues which we solved\nRan two attempts at a 10K Waku sim and a 2k sim @ 10 msg/sec\nRedo simulations with versions 0.26 and 0.27\n\nUse waku 0.27 and ensure yamux still works ok\n\nDoesn’t work ok, neither with 0.26 and 0.27\n\nInitially delayed by lab issues, solved by end of week\n\n\n\n\nExtract more information regarding discv5 (mem/cpu)\n\nNot finished before of lab issues with Prometheus monitoring\n\n\n\n\nRefactored message tracking code\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nAdd mandatory shard flag(@Florin)\nIssue found(@Florin)\nReopened again(@Florin)\n\n\nnomos:test-automation-cryptarchia\n\nTest plan(@Florin)\n\n\nwaku:test-automation-sharding\n\nSharding tests update. PR 1060 - merged(@Roman)\nbug: message won’t be sent over from node1 to node2 with sharded topic subscription. Issue 1086 - in progress(@Roman)\n\n\nwaku:test-automation-rln\n\nRLN relay tests. PR 30 - in progress(@Roman)\nbug: node won’t start with RLN in on-chain dynamic mode. Issue 2662 - open(@Roman)\n\n\nwaku:test-automation-sharding\n\nUpdated Sharding PR with comments(@Alex)\n\n\nwaku:test-automation-rln\n\nVarious testing code improvements and utilities(@Alex)\nFinally unblocked onchain “invalid contract” tests(@Alex)\n\n\nadmin/misc\n\n2CCs OOO Wednesday -> Friday\n1CC OOO on Monday/Wednesday\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancements\n\ninvestigated and testing missed leaves solution\nfix waku keystore segfault on incorrect appInfo\nfixed logging for debug logs in nwaku\nintegrated lazyIMT into rln-v2 for gas estimates for waku research\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nmerged in rln light verifiers rlog, cross-posted to vac forum pending crosspost to ethresearch.\n\n\nzerokit:vac:maintenance\n\naddressed some issues in installing dependencies\nremoved rln-wasm from the benchmarks (there are none)\n\n\nzerokit:vac:zerokit-v0.5\n\ncreated pr add ark-zkey support\nstarted to work on tests and benches review regarding release v0.5\nremove tree_height_32 merged\n\n\nsecure-channels:waku:ethereum-chat\n\nWork on the role of the AS in the RFC architecture.\nWork on the role of the SIWE approach.\nExamine the reference implementation of DCGKA and updated distributed group membership part of the notion note.\nStudy on the SIWE-like approach from the updated RFC as related to issue #4.\n\n\nadmin/misc\n\nsynced with pse and waku research team, pse will start work on the next version of RLN, using the same primitives from semaphore v4. We have disagreed with their approach since it adds unnecessary complexity. we may use a fork of it if they continue making it like semaphore v4.\nupdated pending milestones on roadmap\n1 CC onboarding\n1 CC ooo on May day\n\n\n\nvac:sc:: §\n\nstatus:swap-aggregator\n\nfinished research on metamask swap adapters\nContinued research on CoW Protocol\nContinued working on notes and slides\n1inch swap router research\n\n\nvac:maintenance/misc\n\nSmart contract security research\n\nParticularly inflation attacks\n\n\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nCreated pr for Codex marketplace raw RFC, got feedback - https://github.com/vacp2p/rfc-index/pull/36\nHad a sync meeting with Codex marketplace team on Thursday, for questions\n\n\nnomos:specs-init\n\nStarted Nomos Data Availablity RFC, not complete, should complete next week for feedback\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on staggered message sending, draft PR is ready for review. Still need to add adaptive behavior in terms of wait-time, number of simultaneous-transmissions (WIP).\nCompleted tests from the above PR. Analyzing results (Looking for rationale for one anamoly: idontwant message is not showing good results in a network with dissimilar bandwidth/latencies)\n\n\nzk:codex:zk-consulting\n\nContinued conversation with Codex team on feedback.\nContinued work on notes for Beyond Circuit and WarpFold.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nDiscussed Waku Anonymity Analysis and completed documenting.\nStarted documenting initial discussions on designing a base Anonymity Layer - WiP.\nRead Tor Push and Dandellion++ solutions - WiP\nLooked into Nym mixnet - WiP.\n\n\nmisc\n\nBegan rough drafts on blogs; Verkle Trees\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nWorked on State Separation Components and discussed with Ugur on how to proceed with the first part of the architecture (Moudy + Ugur)\nExamine the needs for state separation in terms of trees (Ugur)\nStarted to write a prototype about the overview of an end-to-end execution (Ugur + Moudy)\n\n\nproofsystems:vac:benchmarks\n\nHad a slight look on what is going regarding other benchmarks done by others (Moudy)\nContinued server testing (Rostyslav)\nOpened up aggregator issue (Rostyslav)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nHad a high level look at existing ZkVms (Moudy)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nContinued reading about Greco zk proofs (Rostyslav)\nStarted checking out Ligetron (Rostyslav)\n\n\n"},"vac/updates/2024-05-13":{"title":"2024-05-13 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/05/13 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nfix(CI): rename branch from unstable to master in bumper workflow https://github.com/vacp2p/nim-libp2p/pull/1097\nfix(yamux): set EoF when remote peer half closes the stream in yamux https://github.com/vacp2p/nim-libp2p/pull/1086\nreviewing PRs\n\n\n\nvac:tke: §\n\ncodex:cdx\n\nreviewed and extended Codex’ Value Capture Mechanisms (Frederico)\nreviewed and discussed the new Slot Reservation proposal with Codex team (Frederico)\nReviewed, commented, and discussed the tokenomics part of the whitepaper (Juan)\nRead on slot reservation proposals (Juan)\nProvided feedback on codex’s market validation respose document (Juan)\nCatching up on the discussion around marketplace mechanisms (Martin)\n\n\nstatus:L2-Deployment\n\nFurther work on L2 economic model, focusing on fundametal questions and constraints (Martin)\nStarted working towards a swap aggregator model (Juan)\n\n\nwaku:general-incentives\n\nReviewing protocols mentioned by Franck (Martin)\nIdentifying key actionable items (Martin)\n\n\nstatus:SNT-staking\n\nSync with SC team on the swap feature, chats with potential partners (Martin)\nIdentifying implications of L2 economic model on SNT staking and its current design (Mart\n\n\n\nvac:dst: §\n\nadmin:misc\n\nMeetings re: milestones, ad hoc discussions\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nBlocked due to Kubernetes issues in lab\nIssues resolved now, deployments resume on Tuesday evening (14th/15th of May)\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nFirst 10k simulation with metrics\n\nDeployment - https://asciinema.org/a/ZzyqtVrcJW6cVwTI0CJDsBWC5\nk9s - https://asciinema.org/a/4gmnHckrQgYgtwx85ItixRlY0\n\n\nDeployed new Ruby cluster for better DNS + control plane stability\n\nManages 10K simulations - reliably!\n-API becomes unstable at that scale, which is solvable\n\n\n\n\nvac:dst:tooling:vac:visualiser-tool:\n\nPR to be merged regarding code structure and first waku message tracking functionality: PR\n\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nDebugging issues with distributed storage system used to support Codex nodes\nSetup access for Codex team\n\n\nvac:dst:deployment-and-analysis:nomos:mixnet\n\nContinue to follow up with Nomos team\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nbug: message won’t be sent over from node1 to node2 with sharded topic subscription - some new info from debbuging(@Roman)\n\n\nwaku:test-automation-rln\n\nRLN relay tests merged(@Roman)\nbug: node won’t start with RLN in on-chain dynamic mode\nIssue 2662 - open - retested with PR 2664 without better outcome(@Roman)\nNode readiness with /health check(@Roman)\nSkip health check for go-waku(@Roman)\nContinue testing for RLN, Call with Aaryamann. Made some advancements(@Alex)\n\n\nadmin/misc\n\nOOO All week(@Florin)\nOOO From Monday until Wednesday(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancements\n\nuse arkzkey variant of zerokit libs in nwaku\nwindow of roots should be accepted as valid health status of rln-relay\ndedicated timebox to help QA setup rln-relay\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\ndraft of rln-v3 rlog\n\n\nzerokit:vac:zerokit-v0.5\n\ninclude arkzkey libs in nightly releases\nmerged PR add ark-zkey support\npublished zerokit v0.4.4 release with arkzkey support release v0.4.4\nfinished test and benches refactoring chore(rln): tests and benchmarks review\nupdated docs for rln-v2 to include new serde format chore(rln): updating docs\ncreated new task in release v0.5 and merged it fix(rln): Remove resources folder, update missed docs\n\n\nsecure-channels:waku:ethereum-chat\n\nStudy on the necessity of SIWE-like protocol related to issue #4\nCheck ERC-725 and ERC-735 and a KeyManager Repository for some insight instead of SIWE-like authentication systems.\n\n\nadmin/misc\n\nroadmap updated\n\n\n\nvac:sc:: §\n\nstatus:swap-aggregator\n\nprepared presentation on metamask swap\n1 inch aggregator research\nuser privacy on Paraswap integration\nFinished preparing CoW protocol preso\nMet with TKE and StatusChain team to discuss plans\n\nUnfortunately things are still blurry and being brainstormed\n\n\n\n\nvac:maintainance/misc\n\nENS usernames release delay update\nFine-tuned job description for Solidity engineer\nCreated onboarding guide for new hires\n\n\n\nvac:nim: §\n\ntooling:nimble\n\nWorking on passing all tests when SAT on.\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nUpdated CODEX-MARKETPLACE rfc, will ask for second round of feedback next week - https://github.com/vacp2p/rfc-index/pull/36\nStarted node dispersal rfc, will ask for feedback next week\n\n\nnomos:specs-init\n\nStarted data availibility rfc, should be able to complete first draft next week and ask for feedback - https://github.com/vacp2p/rfc-index/blob/nomos-da/nomos/data-availability.md\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nLooked in to previous staggered message sending approach. Require manualy resetting nim/nimble to match the branch dates. The performance evaluation results are available here\nAs no gains are seen, looking for other possible improvements (delayed elimination of peers from queues on receiving idontwants), adapting stagger delays to peer speeds/scores. still a WIP\n\n\nvac:admin\n\nWork on blog drafts for Verkle Trees, KZG, and BloomFilters.\n\n\nzk:codex:zk-consulting\n\nProvided feedback on bkomuves’ notes on Codex tracking proofs.\nBegan report on Groth16 as final compression layer, and current state of pairing-based recursion proof systems.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued working on Anonymity Layer - WiP.\nRead Tor Push and Dandelion++ solutions\n\nStill can’t figure out the actual advantage of using onion encryption.\nIn the pub-sub model, adding delays and/or relaying through an anonymity/mix overlay network should offer the desired level of protection.\nHowever, such an overlay network will be similar to Dandellion++ only.\nStill trying to figure out how to overcome the shortcomings in Dandellion++.\n\n\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc-01\n\nSynced on monitoring (Marvin)\n\n\nstate-separation:vac:state-separation-architecture-01\n\nWorked extensively on the architecuture of state separation and made some improvements (Ugur + Moudy)\nFinished the 5-page doc for the framework of the prototype with some charts related to the type of executions (Ugur)\nEnriched the prototype with the details for the first draft (Moudy + Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nContinued reading about Greco zk proofs (Rostyslav)\nFinished checking out Ligetron (Rostyslav)\nWrote a small summary paragraph on LatticeFold (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nStarted the writings and wrapped up some parts to reflect main differences between the major analyzed proof systems (especially regarding proofs agg vs recursion) (Moudy)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nPrepared requirements to look into existing ZkVms and what are the important keys we need to assess (Moudy)\n\n\n"},"vac/updates/2024-05-21":{"title":"2024-05-21 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/05/21 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\ncheck use outside test definition https://github.com/status-im/nim-unittest2/issues/43\nfeat(service): add wildcard address resolver https://github.com/vacp2p/nim-libp2p/pull/1099\n\n\n\nvac:tke: §\n\n`admin“\n\n1.5 CC day off\n\n\ncodex:cdx\n\nread Codex business related docs (Frederico)\nreviewed and extended Codex’ Incentive Mechanisms (Frederico)\nReviewing internal and external materials (Martin)\nCommented on Codex tokenomics and on investor strategy docs (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\ncontinued the restructure of the previous work under a newly defined strategy (Frederico)\n\n\nstatus:L2-deployment\n\ncaught up with the current state (Frederico)\nLooking into further L2 economic models, internal discussions (Martin)\nDiscussion with LiFi team (Juan)\nFinished writeup on swap aggregator (Juan)\n\n\nwaku:general-incentives\n\ncaught up with the current state (Frederico)\nSync with the Waku team and mapping out potential for TKE support after reprioritization (Martin)\nUpdating Waku Tokenomics Notion (Martin)\n\n\nstatus:SNT-staking\n\nChats with potential partners for the swap product; analysis of the industry (Martin)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nRepeated deployments with waku v0.26\n\n1 to 3K nodes, with 1 msg per 1, 5, 10 seconds\n\n\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nRan 10K deployments to test noise levels post-insulation\nContinued work on metrics + DNS stability\n\n\nvac:dst:tooling:vac:visualiser-tool:\n\nFinished implementing the visualization part as a Jupyter notebook\n\nStill remaining: Evaluate how to propperly visualize thousands of nodes\n\n\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nAnalyzed Yamux issue\n\nLooks like keep-alive flag was the root of the cause (at waku level).\n\n\n\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nMigrated Codex VacLab storage to SeaweedFS\nRe-created Codex Kubernetes access\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nstore content topic fix(@Florin)\nstore v3 PR(@Florin)\nworked with SP to translate the store v3 message hashing mechanism from nim to python (@Florin)\ninvestigated with Richard some interop store v3 issues(@Florin)\nupdate lightpush tests with big payloads based on latest nwaku fix(@Florin)\n\n\nwaku:test-automation-sharding\n\nMerge Nwaku PR and closed the milestone(@Alex)\n\n\nwaku:test-automation-nwaku\n\nMerge Peer & Connection Management PR and closed the milestone(@Alex)\n\n\nwaku:test-automation-rln\n\nFinally get node to node onchain test working(@Alex)\nBriefly investigate alternative methods. Didn’t manage to get it working, left for later, worth investigating: Improve developer experience and discard potential bugs.(@Alex)\n\n\nnomos:test-automation-cryptarchia\n\nRead Nomos documentation and related papers(@Alex)\n\n\nadmin/misc\n\nCatch up with things that I missed while on vacation(@Florin)\nOOO All week(@Roman)\n\n\n\nvac:acz: §\n\nsecure-channels:waku:fd-design\n\nImprovements on the DCGKA-based approach\nDocument the UPKE scheme\nCreated a small doc about ERC ERC-725 and ERC-735 in Notion\nStudy on a proposal authentication protocol based on SIWE + AS together.\nRead Ramses’ UPKE notes\n\n\nsecure-channels:waku:mls-design\n\nStarted preparing the talk for Brussels.\n\n\nzerokit:vac:zerokit-v0.5\n\nmerged PR about getting subtree root: subtree root PR\nfound bugs in tree behavior: Incorrect behavior of trees in override_range function\nmerged PR about checking and storing zero leaves indices: zero leaves PR\nin part of zero leaves PR: started to research better implementation for leaves storage (done with the idea of using bloom filter and its improvements - both had worse performance)\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nwrapped up and published rln-v3 rlog\n\n\nsecure-channels:waku:ethereum-chat\n\nstarted implementing design of de-MLS smart contracts\n\n\nrlnp2p:waku:rlnv2-e2e\n\nnew milestone discussion and agreement with waku research\nstarted converting waku-rln-contract to standalone repo since their requirements are more specific now\n\n\nstealth-address-kit:vac:research\n\npresented stealth address kit to the EIP Discussions call with the SC t\n\n\n\nvac:sc:: §\nvac:nim: §\n\ntooling:vac:compiler\n\nUpdates nimble https://github.com/nim-lang/Nim/pull/23601 After it gets merged it needs to be backported.\nBackport: https://github.com/nim-lang/Nim/pull/23600 https://github.com/nim-lang/Nim/pull/23599\n\n\ntooling:vac:editor\n\nAuto updates lsp when the local lsp is used (https://github.com/nim-lang/vscode-nim/commit/1b542e337095b74260b94e5f9ede5715035eafc5)\nUpload the artifacts from the last release so user can get the extension without using the marketplace: https://github.com/nim-lang/vscode-nim/releases/tag/v0.9.0\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nUpdated CODEX-MARKETPLACE rfc, ready for another round of feedback - https://github.com/vacp2p/rfc-index/pull/36\nCreated new dispersal rfc, still in draft - https://github.com/vacp2p/rfc-index/pull/39\n\n\nnomos:specs-init\n\nWorked on data availibility rfc, work still in progess\n\n\nvac:rfc-index\n\nmoved vac raw specs to raw folder - https://github.com/vacp2p/rfc-index/pull/37\ncreated pr to move rln-v1 to draft, still in draft - https://github.com/vacp2p/rfc-index/pull/40\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nCompleted staggered message sending approach for current (priority queues). The branch is available as draft PR for discussions.\nThe implementation shows upto 5% latency gains on most of the test runs, and significant bandwidth saving is achieved.\n\n\nzk:codex:zk-consulting\n\nWorked on questions that Codex raised concerning Beyond the Circuit that they have.\nBegan reviewing proposed proof algorithm draft\nProvided feedback on notes 1 and 2.\n\n\nvac:admin\n\nWorked on BloomFilter, KZG, and Verkle Trees blogs and presentation for LOGOS research call.\nProvided feedback on Akshaya’s notes as requested 1, 2, 3, 4.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nSynced with Daniel on current progress and milestone.\nResearched onion encryption for anonymous routing in GossipSub (WiP) and other mixnet solutions for comparison.\nBegan reading On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies to understand the attack on Dandelion better\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nReviewed and discussed the architecuture of state separation and took some decisions regarding the smart contracts types (Ugur + Moudy)\nImproved the prototype by adding private-only and public-only smart contracts (Ugur)\nCreated examples of executions consist of two functions for end-to-end execution (Moudy + Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStarted working on a writeup about Greco zk proofs (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nDid further review on what should be included in the blogpost (was put on hold to finish the zkvms research list etc) (Moudy)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nPublished a detailed issue including the list of the Zkvms that we need to look into and all the requirements to cover (Moudy)\nStarted researching existing zkVM’s (Team)\n\n\n"},"vac/updates/2024-05-27":{"title":"2024-05-27 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/05/27 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nStun protocol: merged :tada: https://github.com/status-im/nim-webrtc/pull/9\n\nRework getAttribute\nAdd callbacks for username & password\nAddress Diego’s comments\n\n\n\n\nnimlibp2p:vac:maintenance\n\nadd wildcard address resolver PR review https://github.com/vacp2p/nim-libp2p/pull/1099\nset EoF when remote peer half closes the stream in yamux review https://github.com/vacp2p/nim-libp2p/pull/1086\nfinished and merged https://github.com/vacp2p/nim-libp2p/pull/1086\nimproved https://github.com/vacp2p/nim-libp2p/pull/1099\nPR reviews\n\n\n\nvac:tke: §\n\nadmin\n\n1 CC day off\n\n\ncodex:cdx\n\nfinalized the TKE part of Whitepaper (Frederico)\nImproved code for Codex ABM, now at a better state, ready to start testing (Juan)\ninitial steps towards experimental design to simulate CDX security<>demand/supply & price (Juan)\nQuick reviewed Filecoin report (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\ncontinued the restructure of the previous work under a newly defined strategy (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed the SN economy proposal (Frederico)\nDrafting first docs on the economic model and identifying missing pieces, iterating on this with Cyp (Martin)\n\n\nwaku:rln-membership\n\nReviewing existing research into RLN and compatibility with the new design (Martin)\nReviewed RLN documents. (Juan)\n\n\nstatus:SNT-staking\n\nreviewed the swap aggregator work (Frederico)\nReviewing Juan’s work on swaps (Martin)\nFinished document on swap aggregator (Juan)\nperformed additional experiment on time window vs fulfilment (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nRepeat simulations with waku v0.27\n\nFound, documented potential Waku regression\nCreated bandwidth plots with weird results\n\n\nChanges to publisher\n\nPR https://github.com/vacp2p/10ksim/pull/30\n\n\nRe-doing requested deployments\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nSome PRs:\n\nFirst visualizer simple PR\nFound issue where simulation data is stored incorrectly.\n\nPR to check for this\n\n\nPR: Improved querying to get multiple simulation times at once\nPR: Add parameter for selecting how many datapoints we want in the plots\nPR: Rebase Wings deploy yamls into master\n\n\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nstore v3 - added 70 tests so far(@Florin)\n9 store v3 issues found:(@Florin)\n\nstore v3 returns error waku message hash parsing error: Incorrect base64 string for some cursors\npassing a cursor that doesn’t correspond to any message in the store will return all messages\nnwaku crashes for a store v3 request with invalid cursor format\nstore v3 local queries time out\nstore v3 response format issues\nstandardize store types by using camel case instead of [snake case]7(https://github.com/waku-org/go-waku/issues/1107)\npubsubTopic and contentTopics are required for store v3 requests\nstore v3 returns error illegal base64 data at input byte\nstore v3 - passing a cursor that doesn’t correspond to any message in the store will return all messages\n\n\nupdate all response fields to be camelCase(@Florin)\nsmall fix for ligh push dial fail error(@Florin)\n\n\nnomos:test-automation-cryptarchia\n\nRead Nomos ocumentation and related papers(@Alex)\nDelve into codebase to understand structure(@Alex)\nWorking in fixing coverage(@Alex)\n\nPR\nHelper PR\n\n\n\n\nadmin/misc\n\nInterview and reviewed QA Candidate code challenge(@Florin)\n1CC OOO All week\n\n\n\nvac:acz: §\n\nsecure-channels:waku:mls-design\n\nCreated authentication and login document for MLS design in notion\n\n\nzerokit:vac:zerokit-v0.5\n\nFix json serialization and update tests PR\nPublished release v0.5 on github\nreleased on crates.io\n\n\nrlnp2p:waku:rlnv2-e2e\n\nDeprecated waku-rln-contract in favour of waku-rlnv2-contract which uses vacp2p/foundry template directly instead of inheriting from vacp2p/rln-contract due to evolving business case and divergence from base offering of vacp2p/rln-contract\nReduced gas usage for waku-rlnv2-contract with onchain root from 250k gas to 104k gas for most insertions, some insertions vary depending on the leaf index due to recalculation of the merkle tree cache (anywhere between 150k-230k). still acceptable.\nAdded test vectors with kats from zerokit\nDeployed on sepolia for accurate gas measurements\n\n\nstealth-address-kit:vac:maintenance\n\nfeat(curves): integrate bw6_761\nchore(curves): simplify integration of new curves\nchore(StealthAddressOnCurve): refactor common utilities and traits\nfeat(curves): add pallas & vesta\nchore(release): v0.1.0 and released on crates.io\nfeat(curves): add secp256r1\nfeat(curves): add secp256k1\n\n\n\nvac:sc:: §\n\nvac:maintenance/misc\n\nUpdated ENS Usernames to allow custom release delay on deploy https://github.com/status-im/ens-usernames/pull/128\nMigrated ENS Usernames in Sepolia with 600 seconds of release delay on 0x3174DceF2649Ef7D3585cFC52d45586cF0d0dC90\nWIP: ENS usernames migrate to forge\nresearch on Zodiac contracts and Safe modules\nResearched proxy patterns\n\nTransparent proxies\nUUPSUpgradables\n\n\nInterviewed first candidate\n\n\n\nvac:nim: §\n\ntooling:vac:nimble\n\nAdd supports for nimDir flag. See the comment in the PR https://github.com/nim-lang/nimble/pull/1221\nFixed an issue where nim bin was wrongly constructed on win\n\n\ntooling:vac:lsp\n\nuse nimDir when available https://github.com/nim-lang/langserver/pull/200\n\n\ntooling:vac:compiler\n\nnimcheck issue on win (https://github.com/nim-lang/Nim/issues/23624) Fix needs to be reworked\nBackport nimble sat to 2.0 and 1.6 https://github.com/nim-lang/Nim/pull/23643 https://github.com/nim-lang/Nim/pull/23644\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nHad sync meeting with marketplace team on Thursday\nUpdated marketplace rfc, need to make changes based on feedback - https://github.com/vacp2p/rfc-index/pull/36\n\n\nnomos:specs-init\n\nWorked on data availibility rfc, need more time to finish rough draft\n\n\nadmin/misc\n\nOpened discussion for rln-v1 move to draft, and recieved feedback - https://github.com/vacp2p/rfc-index/pull/40\ncreated pr on waku/specs to end move to draft update for WAKU/METADATA and WAKU/NETWORK - https://github.com/waku-org/specs/pull/15; https://github.com/waku-org/specs/pull/16\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nConducted simulations results/code analysis for staggered message sending PR\nIdentified one potential issue related to IHAVE/IWANT messages.\nLooked into GossipSub specifications and other libp2p (go and rust) implementations for IHAVE/IWANT message flows\n\n\nvac:admin\n\nFinished presentation for Logos Research call\nFinished BloomFilter blog draft.\nFocus on Nescience\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nAddressed Marvin’s comments on anonymity layer notes.\nWorked Anonymity Layer - WiP.\nMet with Youngjoon to understand the practical considerations in designing anonymous communication for Nomos.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nAdditional reviews of the architecuture of state separation. (Moudy)\nWork on the input and outputs in the aggregation circuit for the state-separation prototype. (Ugur)[ACZ]\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nWorked on the list of ZkVMs. Mainly covered: ZkMove, ZkWasm, PiecrustVM. (Moudy)\nWorked on zkVM list. Covered: NovaNet, zkLLVM, Lurk. (Rostyslav)\nWorked on zkVM list. Mainly covered: Ceno, Ola, Valida, RISC-0.(Marvin)[DR]\nWorked on zkVM list. Mainly covered: SP1, Powdr, Miden, and zkOS. (Ugur)[ACZ]\n\n\n"},"vac/updates/2024-06-03":{"title":"2024-06-03 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/06/03 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDTLS protocol https://github.com/status-im/nim-webrtc/pull/10\n\nAdds comments & improve PR presentation\nSolve some problems appearing with the merge of Stun protocol\nTrying to solve the CI with prerequisites installation in nim-mbedtls\n\n\nChore PR (renaming)\n\n\nnimlibp2p:vac:maintenance\n\nreview and finalize various chore PRs\n\n\n\nvac:tke: §\n\nadmin\n\nreviewed and updated TKE milestones (Frederico)\n\n\ncodex:cdx\n\nreviewed research reports about competitors (Frederico)\nstructureed and started developing Codex agent-based model (Frederico)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nproduced better comparisons between the fork-choice rules (Frederico)\nfinalized the single Jupyter notebook that replicates all computations (Frederico)\ncontinued the restructure of the previous work under a newly defined strategy (Frederico)\n\n\nwaku:general-incentives\n\ncaught up with the current state (Frederico)\n\n\nwaku:rln-membership\n\nReviewed existing research into RLN and compatibility with the new design (Martin)\n\n\nstatus:SNT-staking\n\nReviewed Juan’s work on swaps (Martin)\n\n\nstatus:L2-deployment\n\nDrafted first docs on the economic model and identifying missing pieces, iterating on this with Cyp (Martin\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nDeploy additional Ruby control plane nodes for better stability.\n\nPartially deployed, being finished today\n\n\nInvestigate Waku regression\nPR: New Publisher merged. Tested with 3K Nodes.\nFixed data retrieval issues with Pushprox that affected simulations.\nChanged Waku parameters to better test waku v0.27\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nAsync meetings with libp2p team to inform testing\nPR: Added deployment files in 10k repo for nim-libp2p.\nChanged DST-node branch to use nimbus build system.\nDeployed 1K nimlibp2p nodes and gathered data\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nNew weekly Monday meeting with Waku team about reliability\nWaku is interested in using the visualiser tool in their test fleet. Got an SSH tunnel for Elastic access.\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nMerged store v3 - added 70 tests(@Florin)\nSpent 1 day investigating potential reliability issues that turned out to be misconfigs(@Florin)\n\n\nwaku:test-automation-status-go-cli\n\nCall with Pablo regarding requirements and deliverables(@Florin)\nStarted creating a test framework around the status go cli tool(@Florin)\n\n\nwaku:test-automation-rln\n\nFix: occasional failure to check published message for RLN tests(@Roman)\n\n\nnomos:test-automation-cryptarchia\n\nChore: cryptarchia unit tests update in progress(@Roman)\nExample how coverage changes in the report: Before -> After (@Roman)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nchore(tests): add kats test for merkle proof\nchore: integrate uups proxy\nchore: scaffold deployments\nmerged tests PR after addressing reviews\n\n\nstealth-address-kit:vac:maintenance\n\nchore: refactor into 2 crates, example and sdk\nchore: v0.2.0-beta release\nchore: refactor deps, make lib lighter\n\n\nvalidator-privacy:nimbus:productionize-tor-push\n\nreviewed codebase and paper\n\n\nsecure-channels:waku:mls-design\n\nStudy on login and authentication options for MLS design in terms of decentralization, adding a conclusion to doc\nExamine login mechanism of a self-hosted messaging app based on matrix named element see in github\nFinished the (first version) of the presentation for the EthCC Brussels.\n\n\nsecure-channels:waku:mls-poc\n\ntried to implement poc using openmls and centralised DS -> not finished, found that using decentralised approach is better\nstarted to investigate how to use waku as DS\n\n\nconsulting:codex:proxy-re-encryption\n\nattended kick-off call, meeting notes with action points for next steps\n\n\nadmin/misc\n\nadded codex proxy re-encryption to roadmap pr and merged\n\n\n\nvac:sc:: §\n\nvac:maintenance/misc\n\ninitial Certora setup for codex contracts https://github.com/codex-storage/codex-contracts-eth/pull/113\nWIP: ENS usernames to latest solidity\nWIP: ENS usernames migrate to forge\nENS Usernames to new ENS registry\nProxies and Upgradeable contracts research\nPresented proxy patterns in EIP discussions call\n\n\n\nvac:nim: §\n-tooling:vac:compiler\n\nnimcheck rework previous solution: https://github.com/nim-lang/Nim/pull/23625\n-tooling:vac:nimble\nchange it to dump (https://github.com/nim-lang/nimble/pull/1221)\n-tooling:vac:lsp\nchange it to use dump (https://github.com/nim-lang/langserver/pull/200)\nunify nimble dump calls and extract type https://github.com/nim-lang/langserver/pull/201\nspeed up dump by caching calls (https://github.com/nim-lang/langserver/pull/202)\n-tooling:vac:editor\nuse nimble dump when available to retrieve the nimDir for run and debug (https://github.com/nim-lang/vscode-nim/pull/64) and https://github.com/nim-lang/vscode-nim/pull/65\nfixes compilation issue with latest version 2.0 https://github.com/nim-lang/vscode-nim/compare/main…jmgomez:fixcompilationissuever20?expand=1\n\nvac:rfc: §\n\ncodex:specs-init\n\nUpdated marketplace rfc, made changes based on feedback - https://github.com/vacp2p/rfc-index/pull/36\n\n\nnomos:specs-init\n\nWorked on data availibility rfc, created pr still in draft - https://github.com/vacp2p/rfc-index/pull/\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nExperimented with different optimizations for minimizing the impact of IWant messages. Additionally, we can skip sending IWant if we have received multiple IDontWants for the same msgID; implemented this in PR that shows reasonable improvement.\n\n\nvac:admin\n\nLogos Research call presentation\nMet with Aaryamann concerning blog formatting.\n\n\nzk:codex:zk-consulting\n\nBegan document on proposed proof algorithm draft, and began notes on Groth16 as a wrapper.\nBegan reading Circle STARK, ECFFT1 and ECFFT2 to focus on variations of FFT optimizations.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nReading Nym Network white paper. This addresses several open questions we had: strong adversarial model, reputation system that ensures reliability and mitigates Sybil attacks, uses verifiable random functions for node selection, maintains list of active nodes, prevent long-term correlation attacks by rotating active nodes every hour, rewards for nodes.\nBegan investigating an open source libp2p-nym implementation in Rust\n\n\n\nvac:nes: §\n\nvirtual-machine-creation:vac:vm-foundations\n\nwork on list of ZkVMs\n\nContinued entering data on Nexus, Jolt, o1VM.\nFound new benchmarks for SP1, Jolt and Valida\nOla and snarkOS. [DR]\nCompiled information for Valida, Ola, snarkOS, RISC0 and Valida into the zkVM table. [DR]\ncompiled information for P1, Powdr, Miden, zkOS, Aleo(snarkVM), and zkMIPS in zkVM table [ACZ]\n\n\n\n\nproofsystems:vac:research-existing-proof-systems\n\ncontinue working on a writeup about Greco zk proofs\n\n\n"},"vac/updates/2024-06-10":{"title":"2024-06-10 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/06/10 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nmbedtls: Try differents way to fix the installation on windows due to CI errors\n\nUpdate the version of MbedTLS (a bit too overkill)\nChange pip / python version\nUse pip requirement file\nChange the packages constraints.\n\n\nmbedtls: Work on MacOS CI failing.\n\n\nnimlibp2p:vac:maintenance\n\nreleased v1.3.0\ngossipsub 1.2 https://github.com/vacp2p/nim-libp2p/pull/1106\nfix(services): setup services before peerinfo is updated https://github.com/vacp2p/nim-libp2p/pull/1120\nfix(multicodec): remove unnecessary “!=” operator https://github.com/vacp2p/nim-libp2p/pull/1112\nFormatting https://github.com/vacp2p/nim-libp2p/pull/1118\nfix(gossipsub): pubsubpeer is created with wrong gossipsub version https://github.com/vacp2p/nim-libp2p/pull/1116\n\nInvestigate flaky tests: Couldn’t replicate\n\n\nCI cleanup and streamlining\n\nPR\nMissing: Converting Daily to minver-maxver, and consider changing coverage from full workflow to step after tests.\n\n\n\n\n\nvac:tke: §\n\nadmin\n\n5 (Martin) + 4 (Frederico) days off\nupdated the TKE milestones (Frederico)\n\n\ncodex:cdx\n\nreviewed the latest modifications in the Whitepaper (Frederico)\nWorked on improving code for simulations (efficiency, refactoring etc.) -> This efficiency is needed for MC simulations (Juan)\nResearched Filecoin government models for Agatha after discussion (Juan)\n\n\nstatus:SNT-staking\n\nStarted reading Cyp’s blogpost on SNT (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:10k\n\nContinue attempts at “10k with metrics”, further optimisations\nBring back missing nodes\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\n9x simulations with waku v0.27.\nInvestigate v0.26/v0.28 mesh stability issues https://github.com/waku-org/nwaku/issues/2780\nFixed error in our LivenessProbe deployment yaml, met with Ivan from Waku about this\nGrafana Loki briefly installed and configured and setup; removed due to issues it caused\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nRebased the nimbus build system code to a new branch: https://github.com/vacp2p/dst-gossipsub-test-node/tree/dockerized-nimbus-bs\nFound error with nimble and 1.2.0 version of Nimlip2p (https://discord.com/channels/864066763682218004/1247474261996867684)\nSimulations with 1.2, 1.2.1 and 1.3.0.\n\nYamux and mplex\nhttps://www.notion.so/Nim-libp2p-report-May-2024-7b1c6a06e667440894b554d77f7c7886\n\n\n\n\nvac:dst:tooling:vac:deployer-tool\n\nPR for ignoring bootstrap-midstrap nodes during plotting https://github.com/vacp2p/10ksim/pull/32\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nStarted working on dynamic configuration for visualiz\n\n\n\nvac:qa: §\n\nwaku:test-automation-status-go-cli\n\ninitial PR reviewed and merged with one to one messages functionality(@Florin)\nreviewed and tested subsequent improvement PR from Pablo(@Florin)\ndiscussed results and future work on the ticket(@Florin)\n\n\nwaku:interop-testing-02\n\nstarted looking at discv5 tests(@Florin)\nTest/peer connection management PR 45 - in progress(@Roman)\n\n\nnomos:test-automation-cryptarchia\n\nchore: cryptarchia unit tests update PR 657 - on hold till 17th June (@Roman)\n\n\nwaku:test-automation-rln\n\nCreate issues (@Alex)\n\nMember doesn’t exist after registration\nImprove RLN experience\nRLN Flags issues\n\n\nRLN v2(@Alex)\n\nIntroductory meeting\nCheckout docs and have a look at the tooling\n\n\n\n\nvac:test-automation-nim-libp2p\n\nInvestigate flaky tests: Couldn’t replicate(@Alex)\nCI cleanup and streamlining(@Alex)\n\nPR\nMissing: Converting Daily to minver-maxver, and consider changing coverage from full workflow to step after tests.\n\n\n\n\n\nvac:acz: §\n\nsecure-channels:waku:mls-design\n\nFinished the EthCC presentation.\nStudy on onchain parts of mls-design\n\n\nconsulting:codex:proxy-re-encryption\n\nWorked in the PRE report.\nPerformed research in alternatives to PRE. ABE might be a plausible alternative.\n\n\nsecure-channels:waku:mls-poc\n\nre-design general idea of decentirlized architecture: Delivery Service is represented by Waku Node and doesn’t require additional service\nwent through example of using Waku rust bindings in other project\nstarted to figure out what data we need to store/get on-chain\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nsetup certora on the codex repo\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/113\n\n\nENS usernames to latest solidity\nENS usernames migrate basic tests to forge\nsoft audited codex contracts\n\n\n\nvac:nim: §\n\ntooling:vac:compiler\n\nC++ Issue (https://github.com/nim-lang/Nim/issues/23657) fix: https://github.com/nim-lang/Nim/pull/23666\nC++ Issue research https://github.com/nim-lang/Nim/issues/23656\nNimSuggest should handle not known files [WIP]\n\n\ntooling:vac:lsp\n\nIssue research https://github.com/nim-lang/langserver/issues/203\nFixes an issue where wrong project was auto guessed and Test to cover it. (https://github.com/nim-lang/langserver/pull/206)\nAdd Tests to CI: https://github.com/nim-lang/langserver/pull/205 https://github.com/nim-lang/langserver/pull/205\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nWorked on data availibility rfc, still in draft - https://github.com/vacp2p/rfc-index/pull/41\n\n\nadmin/misc\n\nadded changes based on feedback for rln-v1 - https://github.com/vacp2p/rfc-index/pull/40\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nBegan work on research blog post for gossipsub improvements for large messages. Specifically, looked into the outcomes/rationales of previous performance experiments conducted for large messages, revisited posts/discussions on large messages handling for compiling work\n\n\nzk:codex:zk-consulting\n\nContinued document on proposed proof algorithm draft.\nContinued reading Circle STARK, ECFFT1 and ECFFT2 with the emphasis to produce notes on CFFT and ECFFT.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nExamine libp2p-nym\nRead GossipSub specs.\nBegan work on an initial proposed model. Performed calculations for the probability of deanonymization with a high fraction of malicious nodes (35-40%) for random mixed nodes. Results similar to top 5 AS-level adversaries.\n\n\n\nvac:nes: §\n\nvirtual-machine-creation:vac:vm-foundations\n\nwork on list of ZkVMs\n\nFinished entering data on Nexus, Jolt, o1VM.\nStarted going through codebases ov zkVMs.\nCovered and fulfilled the table for Stellar and Cairo in zkVM table.[ACZ]\nSanity checked RISC0 and Valida from Marvin, Nexus and Jolt from Rostyslav, Cairo and Stellar from Moudy.[ACZ]\n\n\n\n\nproofsystems:vac:research-existing-proof-systems\n\nContinue working on a writeup about Greco zk proofs.\n\n\nstate-separation:vac:state-separation-architecture-01\n\nStudy on the racing conditions for state-separation prototype. [ACZ]\n\n\n"},"vac/updates/2024-06-17":{"title":"2024-06-17 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/06/17 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFix nim-mbedtls MacOS installation\nMerge small chore PR https://github.com/vacp2p/nim-webrtc/pull/13\nDTLS ready to review https://github.com/vacp2p/nim-webrtc/pull/10\n\n\nnimlibp2p:vac:maintenance\n\nhttps://github.com/vacp2p/nim-libp2p/pull/843\n\nOlder PR about races conditions; Find/implement solutions to fix it\n\n\nfix(CI): rebuild website job https://github.com/vacp2p/nim-libp2p/pull/1125\nfix(readme): update links https://github.com/vacp2p/nim-libp2p/pull/1126\nfix(CI): generate website job https://github.com/vacp2p/nim-libp2p/pull/1124\nfix(tests): testautorelay https://github.com/vacp2p/nim-libp2p/pull/1121\nfix(tests): flaky testdaemon https://github.com/vacp2p/nim-libp2p/pull/1123\nchore(formatting): format the whole codebase using nph 0.5.1 https://github.com/vacp2p/nim-libp2p/pull/1118\nfix(gossipsub): pubsubpeer is created with wrong gossipsub version https://github.com/vacp2p/nim-libp2p/pull/1116\n\n\n\nvac:tke: §\n\nadmin\n\n2 (Frederico) + 5 (Martin) days off\nchanged the TKE milestones after getting feedback (Frederico)\nanalysis of Risk Quant Lead candidate task (Frederico)\nMet with Martin to discuss hand-off (Juan)\n\n\ncodex:cdx\n\ncleaned up Litepaper (Frederico)\nKept working on simulations code, greatly improved efficiency (Juan)\nWrote piece on Filecoin government (Juan)\n\n\ncodex:testnet-incentive\n\ncaught up the current thinking of the Codex team (Frederico)\n\n\nstatus:SNT-staking\n\nCommented Cyp’s blogpost (Juan)\nDiscussed further directions on the swap aggregator (Juan)\n\n\nstatus:L2-deployment\n\nStarted work on catsfishing (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nMeeting with Codex team members comparing DSNs and offering a competive analysis\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nRunning attempts at “10k with metrics”, new tests with noise dampening\nBrought back missing nodes\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nContinued debugging waku regression\nRepeated deployments with 0.28, and compared with 0.27.\nGave feedback to Gabriel@Waku about change in Waku logging\n0.28 deployment for Ivan/Hanno, plotting message time distribution to all peers.\n\nIvan specifically requested different sizes and latencies- vac:dst:deployment-and-analysis:waku:midscale\n\n\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nContinue work on injecting elastic information in visualiser\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nTried to repeat simulations with different message size and latency witn 1.2.0 and 1.3.0\n\nCouldn’t obtain data, still trying to figure out why\n\n\n\n\n\nvac:qa: §\n\nwaku:test-automation-status-go-cli\n\ncontact request tests - merged(@Florin)\nprivate groups tests - in progress(@Florin)\nreviewed Pablos’s PR where he fixed and added new functionality to status-cli(@Florin)\n\n\nwaku:interop-testing-02\n\nTest/peer connection management in progress(@Roman)\n\n\nnomos:test-automation-cryptarchia\n\nchore: cryptarchia unit tests update on hold till 17th June(@Roman)\nchore: cryptarchia ledger unit tests update in progress(@Roman)\n\n\nwaku:test-automation-rln\n\nInvestigate and fix waku-simulator issues with docker/podman on windows and fedora(@Alex)\nBegan running tests(@Alex)\n\n\nwaku:maintenance-nwaku\n\nAnswer open issues(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nchore(tests): add kats test for merkle proof\nchore: integrate uups proxy\nchore: scaffold deployments\nmerged tests PR after addressing reviews\n\n\nstealth-address-kit:vac:maintenance\n\nchore: refactor into 2 crates, example and sdk\nchore: v0.2.0-beta release\nchore: refactor deps, make lib lighter\n\n\nvalidator-privacy:nimbus:productionize-tor-push\n\nreviewed codebase and paper\n\n\nsecure-channels:waku:mls-design\n\nStudy on login and authentication options for MLS design in terms of decentralization, adding a conclusion to doc\nExamine login mechanism of a self-hosted messaging app based on matrix named element see in github\nFinished the (first version) of the presentation for the EthCC Brussels.\n\n\nsecure-channels:waku:mls-poc\n\ntried to implement poc using openmls and centralised DS -> not finished, found that using decentralised approach is better\nstarted to investigate how to use waku as DS\n\n\nconsulting:codex:proxy-re-encryption\n\nattended kick-off call, meeting notes with action points for next steps\n\n\nadmin/misc\n\nadded codex proxy re-encryption to roadmap pr and merged\n\n\n\nvac:sc:: §\n\nvac:maintenance/misc\n\nSetting up first certora rules in Codex repo\nENS usernames migrate remaining tests to forge\nENS usernames forge\n\nhttps://github.com/status-im/ens-usernames/issues/129\nhttps://github.com/status-im/ens-usernames/tree/foundry-template-test\n\n\nResearched EIP4626 tokenized vaults and security vulnerabilities\nPresented research to team\nMeeting with Finance and Security to discuss plans with Zodiac modules\n\nFinance will set up deploy script to create a SAFE with multisig and zodiac roles modifier + scope guard\n\nSC team and Security team will review deploy scripts\nSC team will deploy contracts on behalf of finance\n\n\n\n\nRebased Ricardos work on ENS username repo refactor\n\nBranch: https://github.com/status-im/ens-usernames/commits/foundry-template/\nAlso had session with him about ironing out some processes\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:compiler\n\nFix an issue in nimsuggest where unknown files werent being handled: https://github.com/nim-lang/Nim/pull/23696\nBackports: https://github.com/nim-lang/Nim/pull/23702 and https://github.com/nim-lang/Nim/pull/23701\nFix: “#23695: On Linux, “nimsuggest” crashes if Nim is installed in /usr/bin and the library in /usr/lib/nim” https://github.com/nim-lang/Nim/pull/23697\n\n\ntooling:vac:lsp\n\nImplements the extension/status endpoint (https://github.com/nim-lang/langserver/commit/3879966eed20f04ce4254b67c5c6496c06358b79)\nIt’s useful for asserting in tests in a reliable way as it exposes the langserver and nimsuggest instances current status (i.e. main file, known files, etc.) It can also be useful to create a specific window in extension to quickly inspect the current status for a given project\n\n\ntooling:vac:editor\n\nImplements Show NimLangServer Status command. (https://github.com/nim-lang/vscode-nim/pull/67)\nRight now is just outputing into the output window. In the near future we are going to build a separate window to inspect it.\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nWorked on data availability rfc, not ready for feedback, still in draft - https://github.com/vacp2p/rfc-index/pull/41\n\n\nadmin/misc\n\nClosed and moved issues from rfc old repo; archived old repo (https://github.com/vacp2p/rfc)\nUpdated readme on rfc-website - https://github.com/vacp2p/rfc.vac.dev/pull/2\n\n\n\nvac:dr: §\n\nvac:admin\n\nTeam synced outside of standup for additional feedback.\n(Marvin) Began investigating gossipsub lazy message issue as prep for testing.\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nBegan work on research blog post for gossipsub improvements for large messages: WIP draft\n\n\nzk:codex:zk-consulting\n\nWrote notes on a binding issue in Codex proposal notes along with a solution.\nWrote brief notes for PolyMath.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nStarted writing Anonymized GossipSub Transport Protocol (AGTP) specification -WiP.\n\n(AGTP will be renamed as the name is not fitting; just WiP atm)\nResearched ways to prevent adversarial senders from abusing the mixnet to DoS single exit nodes; current issue: this could potentially lead to honest exit nodes being penalized and ignored.\n\n\nInvestigated mining techniques; selected proof of work for now.\n\n\n\nvac:nes: §\n\nvirtual-machine-creation:vac:vm-foundations\n\nwork on list of ZkVMs\n\nFinished entering data on missing Zkvms info. [Moudy]\nStarted going through codebases ov zkVMs. [Rostyslav]\nUpdated and integrated additional information on Github and Table lists. [Moudy]\nStarted discussions about the selection of Zkvms and how to add privacy requirements.[Team]\n\n\n\n\nstate-separation:vac:state-separation-architecture-01\n\nReviewed the state separation architecture prototype. [Moudy]\nStarted defining important traces and working through a first draft. [Moudy]\nReviewed the prototype and extracted the rest of possible topics to obtain the scope of the blogpost. [UGUR] [ACZ]\nWork on a demo example of state separation execution for the prototype for each kind of TX. [UGUR + MOUDY] [ACZ]\nExamine the private execution project named sarma\n\n\n"},"vac/updates/2024-06-24":{"title":"2024-06-24 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/06/24 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nMerged new PeerEvent https://github.com/vacp2p/nim-libp2p/pull/843/\nMerged Yamux: change a Future into a AsyncEvent because it makes more sense https://github.com/vacp2p/nim-libp2p/pull/1133/\nfeat: add maxSize to TimedCache https://github.com/vacp2p/nim-libp2p/pull/1132\nchore: add .git-blame-ignore-revs https://github.com/vacp2p/nim-libp2p/pull/1130\nchore: delete branch folders from gh-pages https://github.com/vacp2p/nim-libp2p/pull/1127\n\n\nnimlibp2p:vac:webrtc-transport\n\nDTLS https://github.com/vacp2p/nim-webrtc/pull/10\n\nAdds testing\nSome refactorization (remove useless code/change names/comments/splitting files etc..\n\n\n\n\nnimlibp2p:vac:gossipsub-perf-improvements\n\nImprovements related to Gossipsub 1.2 https://github.com/vacp2p/nim-libp2p/issues/1131\n\n\n\nvac:tke: §\n\nadmin\n\n2 CC days-off\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nperformed statistical analysis of simulation results (Frederico)\nread paper about StakeSure (Frederico)\nDiscussed statistical analysis of simulation results w/Frederico (Juan)\n\n\ncodex:cdx\n\nfinalized the Litepaper (Frederico)\nprepared a “Codex in one slide” doc (Frederico, Juan)\nworked on simulations (Juan)\n\n\ncodex:testnet-incentive\n\nkicked off the testnet incentives report (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed all docs (Frederico, Juan)\nMeeting with Swiss legal councel for status (Frederico, Juan)\nWorked on CowSwap comparison (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:10k\n\nVarious (1-10k) 0.27 deployments with full hardware, measurements\n\n“Right on the edge” with Prometheus\nWill be backing up Prometheus and replacing with VictoriaMetrics\n\n\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nRepeat multiple simulations for Gabriel(Waku) until found the issue\nSimulations for version v0.29\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nCall and chat with Zoltan. Helped him analyze some waku-simulator results with visualizer.\nStarted cleaning/creating more utilities for Zoltan so he can use it on his own.\nDeployed VictoriaLogs to replace Loki and finally get logs from each container\nPrep work for switching to VictoriaMetrics for better telemetry\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nDo simulations, gather data and perform analysis for nimlibp2p\n\nAnalysis with 50KB and 500KB, 1.2 and 1.3 versions, with mplex and yamux\n\n\n\n\n\nvac:qa: §\n\nwaku:test-automation-status-go-cli(@Florin)\n\nprivate groups tests - merged\ncommunity actions tests - in progress\n\n\nwaku:interop-testing-02(@Roman)\n\nTest/peer connection management\nPR 45 - merged <- issues processed\nbug: could not register RLN\nIssue 2837 - open - new implementation TBD\n\n\nnomos:test-automation-cryptarchia(@Roman)\n\nchore: cryptarchia unit tests update\nPR 657 - in progress\nchore: cryptarchia ledger unit tests update\nPR 660 - in progress - one last state not simulated\n\n\nvac:test-automation-nim-tooling(@Roman)\n\ntest: use Nimble to manage Nim\nPR 71 and PR 222\n\n\nwaku:test-automation-rln(@Alex)\n\nRLN v2 Testing\n\nRun tests both in old and new (waku:v0.30.0-rc.0) nwaku image\nVarious fixes and two helper scripts - PR\nFound Issues:\n\nRLN_RELAY_MSG_LIMIT error handling\nRestarting node containers don’t load keystore\nExcessive memory usage on nodes with big message sizes\n\n\n\n\n\n\n\nvac:acz: §\n\nsecure-channels:waku:mls-poc\n\nCreate PR with de-MLS PoC\nFixed most of comments after first review\nStarted to work with applying redis pub-sub approach\n\n\nsecure-channels:waku:mls-design\n\nPreparation of the talk for EthCC Brussels.\n\n\nconsulting:codex:proxy-re-encryption\n\nResearch on alternative approaches to PRE.\nCreation of report on research.\n\n\nadmin/misc\n\n1 CC was ooo 18th, 19th and 20th (public holiday)\n\n\nrlnp2p:waku:rlnv2-e2e\n\nrlnv2 fork fully merged into nwaku\nchore(zerokit): bump submodule\nfix(rln-relay): clear nullifier log only if length is over max epoch gap\nassist with waku-simulator testing\n\n\nstealth-address-kit:vac:maintenance\n\nchore(StealthAddressOnCurve): reuse scalar field from Projective\nfix: gitattributes, github pages deployment\nchore: add benchmarks\nchore(release): v0.2.0\nvarious documentation added, 1, 2 and 3, visible on docsrs\n\n\nzerokit:vac:maintenance\n\nchore(rln): further refactoring of interface\nchore(release): v0.5.1 released to crates.io now that confirmed compatibility with nwaku\n\n\n\nvac:sc:: §\n\nstatus::ens-usernames-maintenance\n\nFinshed the migration to foundry\n\nhttps://github.com/status-im/ens-usernames/pull/130\n\n\n\n\nfinance::access-control-safes-support\n\nMet with finance and went through deployment scripts for access control safes\n\n\nstatus:staking-contracts-v1\n\nRefactored staking contract functions to be more descriptive\n\nhttps://github.com/logos-co/staking/pull/93\n\n\nFixed a bug that lock() increases account.initialMP\n\nhttps://github.com/logos-co/staking/pull/94\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:editor\n\nImplements a panel to inspect the lsp status so we can easily debug it https://github.com/nim-lang/vscode-nim/pull/68\n\n\ntooling:vac:lsp\n\nwip project setup. Improves status, better handling on unknown files #209 https://github.com/nim-lang/langserver/pull/209\nReuses nimsuggests instances in kwnon files (https://github.com/nim-lang/langserver/pull/211)\nImplements entryPoint (https://github.com/nim-lang/langserver/pull/212)\nWIP Project Setup pending PR\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nContinued work on data availability rfc, still in draft. Currently believe all sections are included but all sections are not to elaborate. - https://github.com/vacp2p/rfc-index/pull/41\n\n\ncodex:specs-init\n\nMoved marketplace spec to codex org repo, and made some changes based on feedback - https://github.com/codex-storage/codex-spec/pull/1\nreading for vaildator role rfc\n\n\n\nvac:dr: §\n\nvac:admin\n\nRead Nomos’ notes on Proof of Equivalence\nBegan writing Fiat-Shamir blog\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nWorked on blog post for gossipsub improvements for large messages. Still a WiP, need to add summary and references. (ready for review)\n\n\nzk:codex:zk-consulting\n\nMet with Balazs to discuss IPA and binding.\nBegan reading Blazas’ most recent proposal\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinue documenting Anonymized GossipSub Protocol (AGP) specification.\n\nFinished PoW section\n\n\nInvestigate issues related to wrapping published messages into Sphinx Packet Format\n\n\n\nvac:nes: §\n\nvirtual-machine-creation:vac:vm-foundations\n\nwork on list of ZkVMs\n\nSanity check of the entire list of Zkvms.[Moudy]\nUpdated and integrated additional information on Github and Table lists.[Moudy]\nAdded a new table with score for Zkvm implementation.[Moudy]\nPrepared a document with a list of primitives and privacy requirements needed to implement on top of existing Zkvms.[Moudy + Marvin] + [DR]\nProvided data on why zkLLVM, Lurk, Novanet, Ola, SnarkOS are not zkVMs. [Rostyslav]\nSanity checks Cairo and Piecrust. [Rostyslav]\nAdded missing data on zkVMs. [Rostyslav]\nScored SP1, JOLT, Nexus, RISC0, Valida, O1VM. [Rostyslav]\nProvided information why SP1, zkMIPS, Miden, and Aleo(SnarkVM) are zkVM and why zkOS, Powdr are not. [Ugur][ACZ]\nProvide why (or why not zkVM) zkVM for Valida, Nexus, Jolt, Ceno and RISC0. [Marvin][DR]\n\n\n\n\nstate-separation:vac:state-separation-architecture-01\n\nWorked on defining and answering several questions about Nesceince. [Moudy]\nReviewed part of the prototype. [Moudy]\nStarted to answering some questions related to blogpost for state separation. [Ugur][ACZ]\n\n\n"},"vac/updates/2024-07-01":{"title":"2024-07-01 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/01 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nremoving asyncspawn on yamux\n\nIssue: https://github.com/vacp2p/nim-libp2p/issues/1134\nPR: https://github.com/vacp2p/nim-libp2p/pull/1140\nfix: spamming peer is disconnected and seen cache doesn’t grow indefinitely https://github.com/vacp2p/nim-libp2p/pull/1139\n\n\n\n\nnimlibp2p:vac:webrtc-transport\n\nTrying to fix the linking issue on Windows/MBed-TLS\nFix of the trackers (opening / closing connections and transports)\n\n\nnimlibp2p:vac:quic\n\nQuic Transport https://github.com/vacp2p/nim-libp2p/pull/725\n\n\nnimlibp2p:vac:gossipsub-perf-improvements\n\nfeat: iDontWant is sent only for gossipsub 1.2 or higher https://github.com/vacp2p/nim-libp2p/pull/1135\n\n\n\nvac:tke: §\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\ncontinued the statistical analysis of simulation results (Frederico)\nprepared and ran more simulations (Frederico)\n\n\ncodex:testnet-incentive\n\ncontinued developing the testnet incentives report (Frederico)\n\n\ncodex:cdx\n\nlight work on simulations, will retake this week (Juan)\n\n\nwaku:general-incentives\n\nreviewed the latest incentivization proposal (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed the catsfishing project (Frederico)\nreviewed the past work on GMX and veSNT (Frederico)\nworked CowSwap comparison, caught a few bugs. Mostly focused on this (Juan)\nreviewed and provided coments on the past work on GMX and veSNT (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nRan version 1.1 deployments @ 500KB\nhttps://www.notion.so/Nim-libp2p-report-June-2024-7e6fa14c829d4660be6739817e07956f\n\n\nvac:dst:tooling:vac:visualizer-tool\n\nWorked with Zoltan, handed over some new utils/features\nTweaked VictoriaLogs deployment to enable new visualiser\nCreated new experimental realtime visualiser (separate codebase for now)\n\nUses VictoriaLogs to scrape\nWill look at crossover/integration down the track\n\n\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nRan Waku v0.29 deployments to measure Waku without peer discovery and get a baseline idea of DiscV5’s performance (in terms of mesh behaviour) and bandwidth usage.\n\nRan into scaling issues, could not go beyond low (~40-80) number of well connected peers in a 1000 node cluster\nRepeated attempts with same results consistently\nWill repeat with new parameters\n\n\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\nchore: refactor setup relay node for sharding (@Roman)\nPR 48 - in progress(@Roman)\n\n\nnomos:test-automation-cryptarchia\n\nchore: cryptarchia unit tests update(@Roman)\nPR 657 - merged\nchore: cryptarchia ledger unit tests update (@Roman)\nPR 660 - merged\n\n\nvac:test-automation-nim-tooling\n\ntest: use Nimble to manage Nim (@Roman)\nPR 222 - report created\n\n\nwaku:test-automation-rln\n\nRun more simulations(@Alex)\nFound two possible issues with waku simulator that need some investigating:(@Alex)\n\nNodes don’t receive all messages\nNot all nodes are sending messages\n\n\nPost issue mentioned in past weekly: Memory usage issue(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nchore(rln-relay): add chain-id flag to wakunode and restrict usage if mismatches rpc provider\ndeployed waku-rlnv2-contract to linea sepolia\nredeployed waku-rlnv2-contract to linea sepolia & polygon zkevm testnet (cardona) with new params decided by Waku team\ncreated linea sepolia testnet faucet to bootstrap new operators for Waku\nassist with waku-simulator testing of rln-relay-v2\n\n\nstealth-address-kit:vac:maintenance\n\nmaintenance release v0.3.1\nupdated benchmarks with clean testing bench\n\n\nsecure-channels:waku:mls-design\n\nPreparation of the talk for EthCC Brussels.\n\n\nsecure-channels:waku:mls-poc\n\nupdated interface regarding smart contract integration in this PR and merged it into main\nchanged delivery service provider to redis in redis-approach PR\nfeat(sc_keystore): initialize smart contract template\nchore(sc_keystore): add interface of smart contract\nchore(sc_keystore): initial implementation\n\n\nconsulting:codex:proxy-re-encryption\n\nFinish the PRE report.\n\n\nadmin/misc\n\nCCs getting ready for ethcc Brussels\n1 CC day OOO\n\n\n\nvac:sc:: §\n\ncodex::contracts-formal-verification\nfinished base certora setup and first specs but blocked on a few errors\nstatus:staking-contracts-v1\n\nReseach on MP estimation\nMeeting with Tokeneconimcs\nPaired with Ricardo to clarify misunderstanding of the semantics of initialMultiplierPoints and currentMultiplierPoints\n\nEnded up making changes to these so that they match the semantics\n\nhttps://github.com/logos-co/staking/pull/95#event-13284131380\n\n\n\n\nRebased pending work on cooldown period implementations\n\nhttps://github.com/logos-co/staking/pull/92\n\n\n\n\nfinance::access-control-safes-support\n\nFinished reviewing the deployment scripts of the access control safes\nDeployed the access control safes together with finances team\n\nRepository\n\nhttps://github.com/logos-co/access-control-safes\n\n\nRecording (private, can be requested)\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:lsp\n\nCompletes projectsetup (Note tests are missing but will add them after the chronos refactor)\nTrim Nimsuggest instances, improve heuristics: https://github.com/nim-lang/langserver/commit/fe0d9edff537f2dd653e011963c1b56ee95b9536\nIntroduces extension/statusChanged #215 (https://github.com/nim-lang/langserver/pull/215)\n\nTest it works in multiple combinations of Nim/Nimble versions\n\n\n\n\ntooling:vac:editor\n\nHooks into the nimlangserver statusChanged notification https://github.com/nim-lang/vscode-nim/pull/69\n\n\ntooling:vac:compiler\n\nbump nimble https://github.com/nim-lang/Nim/pull/23766\n\n\ntooling:vac:nimble\n\nAutomatically adds binaries to entryPoints #1230 https://github.com/nim-lang/nimble/pull/1230\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nOpened pr for first draft of data availability rfc for feedback - https://github.com/vacp2p/rfc-index/pull/41\n\n\ncodex:specs-init\n\nDid some reading of proof of storage codex articles for validator rfc\n\n\n\nvac:dr: §\n\nvac:admin\n\nFinished draft for Bloom filters blog; ready for review.\nWorked on draft for Fiat-Shamir blog; almost ready for review.\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nCompleted blog post for gossipsub improvements for large messages.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nLearned about shadow simulator.\nStarted learning testground simulator. Done with installation and basic reads.\nCurrently going through other gossipsub and gossipsub hardening repos for testground to learn about making/running testplans\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued working on Anonymized GossipSub Transport Protocol (AGP) specification. Specifically, worked on the mix context and sphinx packet creation section, corrected deanonymization probability, and addressed feedback.\n\n\nzk:codex:zk-consulting\n\nProvided feedback on Blazas’ most recent proposal\nContinued research on foreign arithmetic.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nWork on the document of Execution Types as part of our Q2 Milestones:\n\nWorked on the document [Ugur][ACZ]\nReviewed and integrated the document for publication [Moudy]\n\n\nWork on the document of Cryptographic Infrastructure and Nullification Strategy as part of our Q2 Milestones:\n\nWorked on the document [Ugur][ACZ]\nReviewed and integrated the document for publication [Moudy]\n\n\nRevisit the type of authenticated data storage such as SMT, Mutator Sets for blogpost. [Ugur][ACZ]\nStudy about the “Nescience state-separation as an add-on for the Dapps”. [Ugur][ACZ]\nAnswered questions related to Nescience (needs some polishing). [Moudy][Ugur][ACZ]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nReviewed Cairo and Piecrust [Rostyslav]\nFinished Scoring zkVMs [Rostyslav]\nStaring going through materials on ring signatures provided by Marvin [Rostyslav]\nProvide Rostyslav with a list of resources for ring signatures [Marvin][DR]\n\n\nBegin compiling a list comparing privacy zkVMs from the list to Nescience. [Marvin][DR]\n\n\n"},"vac/updates/2024-07-08":{"title":"2024-07-08 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/08 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nadd proper tracker management: https://github.com/vacp2p/nim-webrtc/pull/17\nfix the DTLS windows compilation bug\n\n\nmisc/admin\n\nreviewing stuff\nfix old unittest2 issue: https://github.com/status-im/nim-unittest2/pull/44\n\n\nnimlibp2p:vac:quic\n\nfix: make the tests pass https://github.com/status-im/nim-quic/pull/41\nchore: add initial logging https://github.com/status-im/nim-quic/pull/42\nchore: upgrade ngtcp2 to 1.6.0 https://github.com/status-im/nim-ngtcp2/pull/6\n\n\n\nvac:tke: §\n\nadmin\n\n2 + 5 + 1 CC days off\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nran simulations and analyze results related to the wealth concentration (Frederico)\n\n\nstatus:L2-deployment\n\nanalysed the SNT token utility (Frederico)\nstarted rewriting the GMX/veSNT model with the newest constraints (Frederico)\ncontinued research on cow swap, finally cor enough data and context to tell a story (Juan)\nMet with Agata to discuss legal aspect of swap aggregator; need to discuss paraswap with broader team (Juan)\nlight catch up on catsfishing (Juan)\n\n\n\nvac:dst: §\n\nadmin/misc\n\n2 + 4 CC days off\ncatch up last week conversations\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nStarted discv5 analysis and simulations\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nRun and test nimlibp2p v1.4.0\n\n\nvac:dst:tooling:vac:visualizer-tool\n\nNew “DST Visualiser”/NodeJS Visualiser tool for realtime visualisation\n\nused for Waku marketing\n\n\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\nretested bug fixes and removed xfailed tests for fixed bugs(@Florin)\nfix connection error message(@Florin)\nadd peer store capacity to go-waku start flags(@Florin)\nchore: refactor setup relay node for sharding(@Roman)\nPR 48 - merged\nTest/peer exchange(@Roman)\nPR 51 - in progress\n\n\nwaku:test-automation-status-go-cli\n\ndiscussions on the community actions PR regarding how to make the tests create less data(@Florin)\n\n\nvac:test-automation-nim-libp2p\n\nstart creating test plan for YAMUX(@Florin)\n\n\nwaku:test-automation-rln\n\nRun simulations(@Alex)\nDebugged a missmatch between expected sent messages vs actual received messages(@Alex)\n\nRoot cause: Injection script (Simulation tool). Explains a lot of issues I had.\nIssue: Reported by Tanya a couple days prior without me knowing\n\n\n\n\nadmin/misc\n\nOOO 1 + 1 CC Day\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\ntest(rln-relay): aggressive polling for networks with short block times\nfix(rln_keystore_generator): improve error handling for unrecoverable failure\nassistance with deploying rlnv2 fork on waku.test fleet\n\n\nstealth-address-kit:vac:maintenance\n\nchore: deduplicate ffi types generated per elliptic curve by using a prelude for the ffi module\nchore: add Makefile targets to generate bindings for foreign languages (C, Nim), some other trivial Makefile changes\n\n\nsecure-channels:waku:mls-poc\n\nIntegrated smart contract into project PR\nStarted to work with CLI interface for demo: open PR\nfeat: initial implementation of smart contract for de-mls\nchore: add anvil to de-mls for prototyping\nchore: deploy contracts with broadcast modifier\nchore: add Makefile target to run full example e2e\ngeneral debugging\nreview of the repo before demo @ ethcc\n\n\nadmin/misc\n\nupdated acz milestones\nadmin work for CCs traveling to brussels (ethcc).\nFirst review cycle retro with Ekaterina\n\n\n\nvac:sc:: §\n\ncodex::contracts-formal-verification\n\ntalked with the Certora team and we found a bug in their prover and they are fixing it\nthey also helped with some changes in the setup and we are waiting for a PR from them\nPRs updating our foundry template\n\nhttps://github.com/vacp2p/foundry-template/pull/29\nhttps://github.com/vacp2p/foundry-template/pull/30\n\n\n\n\nstatus:staking-contracts-v1\n\nResearch & dev on MP estimation\n\n\n\nvac:nim: §\n\ntooling:vac:nimble\n\nImproves nim installation by using csources (same as atlas)\n(https://github.com/nim-lang/nimble/pull/1233)\nIssues:\n\nRemove nimble from nim compilation Fixes #1175 (above)\nnimble -v may bootstrap Nim compiler from sources #1232\n(https://github.com/nim-lang/nimble/issues/1232)\nhelp should not download package list on a clean setup #1227\n(https://github.com/nim-lang/nimble/issues/1227)\nFix https://github.com/nim-lang/nimble/pull/1234\n\n\nAdds a test that verifies that the required Nim is the one used by nimble when compiling and running the package\nhttps://github.com/nim-lang/nimble/pull/1235\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nreading for codex vaildator rfc, started first draft\n\n\nadmin/misc\n\nchanges to 1/COSS - https://github.com/vacp2p/rfc-index/pull/4\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nLooked into blogposts from probelabs: duplicates in gossipsub and mesh dynamicity\nFollowed libp2p spec meeting, and tried following open PR related to gossipsub 1.3.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on understanding testground simulator; required learning docker.\nFound a ping test plan for nim-libp2p.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued work on Anonymized GossipSub Transport Protocol (AGP) specification. Specifically, mixnode setup section, finished peer ID and key generation, key management, key rotation and libp2p host configuration for a dedicated mix context, and completed outline for the mixnet protocol.\nWorked on a peer discovery mechanism using Discv5.\n\nExamined Sphinx packet construction and a Golang implementation.\n\n\n\n\nzk:codex:zk-consulting\n\nWork on a document that provides more details to Codex’s Dynamic Storage Proposal\nWorked on updatable rows proof, and considered repeated data issue.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nWork on the document of Execution Types as part of our Q2 Milestones:\n\nHandeled Marvin’s questions and feedback about state separation [Moudy]\n\n\nWork on the document of Cryptographic Infrastructure and Nullification Strategy as part of our Q2 Milestones:\n\nReviewed and added some specific topics [Moudy]\n\n\nWorked on the missing components and started prioritizing some of them [Moudy]\nPrepare document comparing Nescience to other privacy zkVMs [Marvin] [DR]\nReviewed and provided feedback on Execution Types document [Marvin] [DR]\nExtracting the missing components for State-separation and add them into a notion page [Ugur] [ACZ]\nDiscussed with Moudy and choose the two bullets from the missing components list namely, key management & addresses and Nullifiers [Ugur] [ACZ]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nWent through materials on ring signatures provided by Marvin and through CCS repos [Rostyslav]\nStarted going through MPC materials prepared by Marvin [Rostyslav]\nStaring going through materials on ring signatures provided by Marvin [Rostyslav]\nProvided Rostyslav some additional information on MPCs [Marvin][DR]\nReviewed SP1, Nexus, Risc0 and zkMIPS for scoring [Oleksandr]\n\n\nReviewed the list of comparison between existing ZkVMs and Nescience and added some specific details [Moudy]\nDiscussed with Rostyslav and Oleksandr about how to proceed for implementing primitives and what to focus on for scoring [Moudy]\n\n\n"},"vac/updates/2024-07-15":{"title":"2024-07-15 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/15 §\nvac:p2p: §\nLast week:\n\nnimlibp2p:vac:maintenance\n\nchore: enable Nim 2.0.x and fix compilation issues\nfix: support ipv6 dual stack\nchore: update os images on ci\ngcc 14 support\n\n\nnimlibp2p:vac:quic\n\nQuic Transport\n\n\n\nvac:tke: §\n\nadmin:\n\nETHcc (Juan)\n5 CC days off\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nfixed a bug in the wealth concentration code (Frederico)\nran again all simulations and analyze all results related to the wealth concentration (Frederico)\nstarted developing the code to analyse the selfish behavior when choosing the fork rule (Frederico)\n\n\nwaku:general-incentives\n\nanalysed the current RLN incentivization proposal (Frederico)\n\n\nstatus:L2-deployment\n\nanalysed and expanded the SNT token utility (Frederico)\ncontinued rewriting the GMX/veSNT model with the newest constraints (Frederico)\ndiscussed the current demands of the cats fishing project (Frederico & Juan)\nFinalised analysis on CoWSwap (Juan)\n\n\ncodex:testnet-incentive\n\ndiscussed the testnet incentives with the Codex team (Frederico & Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:10k\n\nInstall and configure VictoriaMetrics\n3x 10k simulations\n\nStill running into OOM issues\nGot to 9000 nodes at one point accounted for\nStill needs tuning\n\n\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nAnalyse behaviour and bandwidth usage of discv5 when establishing/stabilising mesh\nDiscussed discv5 logging with Gabriel\nMeasure time-to-stable-mesh with different numbers of nodes.\nFound an issue with relay connections.\nLots of simulations and deployments to get VictoriaMetrics implemented and stable\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\ninvestigated interop failures(@Florin)\nupdate interop tests to use cluster_id != 0(@Florin)\nTest/peer exchange - PR 51 - merged(@Roman)\nfix: cluster_id 0 for peer store related tests - PR 56 - in progress(@Roman)\n\n\nwaku:test-automation-status-go-cli\n\nimplement community reuse and merge PR(@Florin)\n\n\nvac:test-automation-nim-libp2p\n\ncreated test plan for YAMUX(@Florin)\nGot familiar with existing tests(@Roman)\nGenerated actual coverage report for Yamux(@Roman)\nTest 2.0.6 compilation fixes(@Alex)\nFinish Cleanup CI PR(@Alex)\n\n\nwaku:test-automation-rln\n\nMeeting with Tanya to solve reproducibility issues(@Alex)\nRan simulations to debug Tanya’s found bugs(@Alex)\n\nFound behaviour differs between computers.\nMetrics bug\n\n\nRan simulations to try to isolate Tanya’s bug’s variables(@Alex)\n\n\nadmin/misc\n\nreview challenges and interview QA Candidates(@Florin)\nstart creating slides for QA presentation(@Florin)\nOOO 1 CC Day\n\n\n\nvac:acz: §\n\nadmin/misc\n\n3 CCs at ethcc\n1 CC ooo full week\n\n\n\nvac:sc:: §\n\nadmin/misc\n\n5 CC days ooo\n\n\ncodex::contracts-formal-verification\n\nintegrated changes from the Certora team\nfixed foundry template PRs\n\n\nstatus:staking-contracts-v1\n\ncont’ reseach on MP estimation\n\n\n\nvac:nim: §\n\ntooling:vac:editor\n\nImplement notification panel in the extension: https://github.com/nim-lang/vscode-nim/pull/72\nPrepare release (to be sync up with Nims) https://github.com/nim-lang/vscode-nim/pull/73\n\n\ntooling:vac:nimble\n\nFix an issue with the CI and win https://github.com/nim-lang/nimble/pull/1\n\n\n\nvac:rfc: §\n\nadmin/misc\n\n@ ethcc\n\n\n\nvac:dr: §\n\nadmin/misc\n\nFinish rlog for Bloom filters and Cuckoo filters\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued work on Anonymized GossipSub Protocol (AGP) specification. Specifically, details of the custom mixnet protocol [WiP], and encode next hop and delays into beta.\nLooked into the Sphinx implementation in Go.\nLooked into the overall implementation and algorithm design choices.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nLooked into testground documentation and example test plans in more detail. Currently, issues with extended delays and occasional failure reports the test ground daemon.\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nProvide feedback on gossipsub rlog\n\n\nzk:codex:zk-consulting\nExamined proof of replication, and discussion whether this is relevant for software level.\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nWorked on execution types and completed private and shielded executions. [Moudy]\nGave a structure to the blogpost. [Moudy]\nSelected some components to focus on. [Moudy]\nReviewed and added some specific topics to the document of Cryptographic Infrastructure and Nullification Strategy as part of our Q2 Milestones. [Moudy]\nProvided feedback on Cryptographic Infrastructure and Nullifications document. [Marvin][DR]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nWent through MPC materials [Rostyslav]\nReviewed scuttlebutt repo [Rostyslav]\nRead about Power of Tau ceremony paper [Rostyslav]\nReviewed powersoftau repo [Rostyslav]\nReviewed all of the zkVM’s in the list [Oleksandr]\nProvide Rostyslav with partial homomorphic resources. [Marvin][DR]\nAdd supplemental resources for primitives to Primitives Document. [Marvin][DR]\n\n\n\n\n"},"vac/updates/2024-07-22":{"title":"2024-07-22 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/22 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nready to review: https://github.com/vacp2p/nim-webrtc/pull/10\nPR for testing + fixing: https://github.com/vacp2p/nim-webrtc/pull/16\nmbedtls : fix missing import (only on windows)\nfix windows library linking\nfix nim-devel error on the stack (value not stored)\nfix macos error with asynchronous closing stun\n\n\nnimlibp2p:vac:maintenance\n\ngcc 14 support - https://github.com/status-im/nim-bearssl/pull/62\nadd ubuntu 24 and gcc 14 - https://github.com/status-im/nim-chronos/pull/553\n\n\n\nvac:tke: §\n\nadmin\n\nWorking towards ETHcc report (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nunderstood the cryptoeconomic perspective of PoW for Executors (Frederico)\ncontinued developing the code to analyse the selfish behavior when choosing the fork rule (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed the work about CoW swap (Frederico)\nunderstood how fishs are modeled in the Cats Fishing project (Frederico)\nFinalised CoWSwap comparisson work and simulations (Juan)\nWrote a presentation for the CowSwap comparison (Juan)\nDiscussed legal aspects of sucha model (Juan)\nWorked on CatsFishing (Juan)\ncatch up on current state (Martin)\n\n\ncodex:testnet-incentive\n\nreviewed discussion with Codex team and mapped out next steps (Frederico)\n\n\nwaku:general-incentives\n\ncatch up on current state (Martin)\n\n\ncodex:cdx\n\nMinor work on simulations (J\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nDiscussions with Hanno about what to check in DiscV5\nAdd parsing code for VictoriaMetrics compatibility\nWhile measuring reliability, found three separate issues:\n\nProblems with logging. Missing messages were not logging because of REST (fixed)\nProblem with duplicated hash messages (TODO)\nProblem with missing messages\n\n\nRun simulations for Waku v0.31\n\nhttps://www.notion.so/2039-78aeac4f220a49ea97e780b7bb60c412\n\nIssue still present: https://github.com/waku-org/nwaku/issues/2892\n\n\nComments can be found here\n\n\nInvestigated network issues reported that affected even very small deployments\n\nUnable to reproduce, but switches were rebooted between report and tests\n\n\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nContinue metrics scaling + VictoriaMetrics fixes\n10K report - multiple simulations to prepare for it\n\n10k being reliably reached, metrics still choking\n\n\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nMeeting (Alberto x Wings) to discuss Visualiser split and show each other the tools created\n\n“DST Visualiser” (nodejs/react) to be used for live analysis\n“Debug Visualiser” (python3) to be for more extensive post-simulation analysis/“playback”\n\n\nTesting visualiser on a 10K swarm\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\nfix light push failures(@Florin)\nadjust tests to new rate limits(@Florin)\nfix: cluster_id 0 for peer store related tests.PR 56 - merged(@Roman)\n\n\nvac:test-automation-nim-libp2p\n\nstarted creating test plan for Gossipsub(@Florin)\n\n\nwaku:test-automation-status-go-cli\n\ndiscussions with waku and status team regarding future work(@Florin)\n\n\nnomos:test-automation-cryptarchia\n\nchore: Da full replication unit tests update\nPR 675 - in review(@Roman)\nchore: Da kzgrs unit tests update\nPR 676 - in progress(@Roman)\n\n\nvac:test-automation-nim-libp2p\n\nUpdate CI Cleanup PR with suggestions(@Alex)\n\n\nwaku:test-automation-rln\n\nFix coverage and run(@Alex)\nRun simulations to give more data for these issues(@Alex)\n\nbug: restarting compose fails loading keystore\nPossible memory consumption issue\n\n\nUpdate MAX_MESSAGE_LIMIT README PR(@Alex)\n\n\nadmin/misc\n\ncreated slides for QA presentation(@Florin)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nInvestigated and found root cause of invalid messages in nwaku & spam messages in nwaku, discussing with team for mitigation\n\n\nsecure-channels:waku:mls-poc\n\nPreparing the inclusion of the on-chain component in the RFC: reading the repos and figuring out the architecture.\nResearch on finality times on different L2s for onchain component.\nFinished work with CLI integration and merged PR\nMerged small fix regarding getting own message PR\nCreated a demo of using cli video link\nStarted fixing the functionality regarding the smart contract and local cache - adding multiple keys during registration, remove unused functionality open PR\n\n\nzerokit:vac:maintenance\n\nstarted a discussion about improving zkey processing time by switching to preprocessing (more details in discord thread)\n\n\nadmin/misc\n\nSubmission of proposal for delivering a talk in Devcon Bangkok. Same presentation as for EthCC Brussels but including latest advances.\nCCs getting tickets for devcon\nUpdate the ethcc notes (for full doc in notion)\n\n\n\nvac:sc:: §\n\ncodex::contracts-formal-verification\n\nmerge certora PR + cleanup and rebase to make PR ready\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/113\n\n\nHad kick-off meeting with Certora and Codex to get Marketplace contracts formally verified\n\nWaiting for certora to provide first properties to work on\nNext session we’ll discuss list of properties to work on after that\n\n\n\n\nstatus:staking-contracts-v1\n\nHad a couple of pair programming sessions with Ricardo to tackle MP estimation\n\nFew problems we ran into:\n\nPrecision loss results in wrong calculation\nEpochs beyond limit epoch generate wrong pending MP estimations\n\n\nCreated a fuzz test that demos the issue\n\nhttps://github.com/logos-co/staking/commit/60d80bf4b2cf0fd14e9de70bc39c31c42b0a4e34#diff-2561530a5f24910605d8693b034e64a26a98817f46fd17ae12004dab5c943bfdR688-R718\n\n\nWould like to learn how to turn that fuzz test into a Certora rule\n\n\nMeeting with Status Chain and TKE\n\nDiscussed high level goals\nSome details about staking protocol still unclear\nConsidering moving MP calculation out of staking entirely and do it offchain (as XP)\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:lsp\n\nResearch the correct approach to refactor the lsp so changes as small as possible.\nMost things are figured but we still need to find the best way to support stdio.\nSmall changes needed to json_rpc so we can use it for the lsp\nhttps://github.com/status-im/nim-json-rpc/pull/222\nBump lsp so it can be released\nhttps://github.com/nim-lang/langserver/pull/219\n\n\ntooling:vac:nimble\n\nFixed a regression introduced by wrongly taggin a Nim release: https://github.com/nim-lang/nimble/pull/1245\nImprove test on Nim versioning https://github.com/nim-lang/nimble/pull/1235\n\n\ntooling:vac:editor\n\nFix Nim version and improve coloring of the notifications:\nhttps://github.com/nim-lang/vscode-nim/pull/75\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nMade some changes to DA rfc, still need to revisit - https://github.com/vacp2p/rfc-index/pull/41\n\n\ncodex:specs-init\n\nwas able to work on Codex validator rfc, still in draft - https://github.com/vacp2p/rfc-index/pull/83\n\n\n\nvac:dr: §\n\nvac/admin\n\nAdded section on filters in RLN to the Bloom Filter rlog; rlog posted.\nWorked on Fiat-Shamir rlog.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nContinued worked on testground simulator. Specifically, developed understanding about writing test plans, and run/play with different example test plans (from other libp2p implementations).\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued working on Anonymized GossipSub Protocol (AGP) specification. Specifically, completed the implementation details of the custom mixnet protocol, extend Sphinx to support address + destination of combined size tk, recommend appropriate cryptographic algorithms, made some changes to the approach followed in Sphinx Go implementation, to improve performance.\nBegin to implement Sphinx library in Go.\n\n\nzk:codex:zk-consulting\n\nBegan notes on Testudo.\nProvide feedback on proof of replication\nContinued work on document for Codex’s storage proof.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nFinished working on execution types covering the 3 different types (Private, Shielded, Deshielded) [Moudy]\nWorked on different components for the state separation Blogpost. [Moudy]\nReviewed key management and lists of primitives from Ugur and Marvin. [Moudy]\nCreate a doc for cryptographic primitives inside and ouside of the kernel circuits in notion. [Ugur + Moudy][ACZ]\nExpand the missing components for State-Separation file in notion. [Ugur + Moudy][ACZ]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nContinued going through partial homomorphic encryption schemes’ materials [Rostyslav]\nReviewed elgamal-encryption, rsa-algorithm repo [Rostyslav]\nInvestingated workaround to use Rust code for Valida [Oleksandr]\nWork on cryptographic primitives list needed to be added for zkVMs. [Marvin][DR]\n\n\n\n\n"},"vac/updates/2024-07-29":{"title":"2024-07-29 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/29 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nhttps://github.com/vacp2p/nim-webrtc/pull/11\nChange files architecture similarly to others WebRTC PRs\nMake different changes in anticipation of Diego’s future comments\nSolve TODOs\nAdapt SCTP closing to DTLS change\nFix examples\n\n\nnimlibp2p:vac:maintenance\n\nFinish CI Cleanup PR\nDouble check gcc14 support\nCheck failing Windows test, locally it passes\nCheck failing interop test\n\n\n\nvac:tke: §\n\nadmin:\n\n1 CC day off (Frederico)\nWorked on ETHcc report (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nadvanced reports of studies 1 and 2 of the wealth concentration (Frederico)\nreviewed the state of the whole Nomos project (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed the state of the SN (Frederico)\nreviewed the state of Cats Fishing project (Frederico)\nassisting defining the incentive structures (Martin)\nworking towards a minimal economy formalization for cats fishing (Martin)\nworking towards a minimal economy formalization for cats fishing (Juan)\n\nDocument on monetisation for the game\n\n\nRecorded swap agregator status document (Juan)\n\n\nstatus:SNT-staking\n\nidentifying functional overlap with the need of the L2 incentive structure (Martin)\n\n\ncodex:cdx\n\nreviewed the simulation code (Frederico)\nworking on simulation code (Juan)\n\n\ncodex:testnet-incentive\n\nreviewing latest progress, identifying missing pieces (Martin)\n\n\nwaku:general-incentives\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale:\n\nContinue work with Gabriel re: stuck node bug\n\n~150 simulations performed with different versions to hunt down bug\n\nWas able to reproduce the bug\nAll signs point to nim-chronos/chronicles.\n\n\n\n\nFound issue with publisher\nRedeployed VictoriaLogs to fix issues with Midscale logging\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nRedeployed and tuned VictoriaMetrics for 10K simulation scale\n\nAbout 7 changes discovered, primarily to do with resource allocation\n\n\nVarious 10K simulations to gather data/test stability\n\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nCall with Ben from Codex to ensure testnet deployment works\n\nStill hitting permissions bugs\n\n\n\n\nadmin/misc\n\nProvided TKE team with a dedicated fileshare + password protected frontend\n\n\n\nvac:qa: §\n\nwaku:test-automation-status-go-cli\n\nadded hybernate tests(@Florin)\nfixed management of big log files(@Florin)\nmake tests more stable(@Florin)\n\n\nwaku:interop-testing-02\n\nadjust store propagation delay(@Florin)\nIssue 2837 - closed - RLNv2 registration works(@Roman)\n\n\nvac:test-automation-nim-libp2p\n\nstarted creating test plan for PubSub(@Florin)\nFinish CI Cleanup PR(@Alex)\nDouble check gcc14 support(@Alex)\nCheck failing Windows test, locally it passes(@Alex)\nCheck failing interop test(@Alex)\n\n\nnomos:test-automation-data-availability\n\nchore: Da full replication unit tests update(@Roman)\nPR 675 - merged\nchore: Da kzgrs unit tests update(@Roman)\nPR 676 - in progress ~70%\n\n\nwaku:test-automation-rln\n\nFix gcc14 support, but gabriel beat me to the PR (@Alex)\nBring RLN PR up to date and fix tests(@Alex)\n\nFound couple flaky tests, I think, need further checking\n\n\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nFixed an issue in an nwaku PR to validate user message limit\nattempted to finish deprecating the tree sync strategy, discovered a blocker in upstream library\n\n\nsecure-channels:waku:mls-poc\n\nPreparation of notes regarding the onchain component of the RFC.\nReview of smart contract\nMerged PR about fixing the functionality regarding the smart contract and local cache - adding multiple keys during registration, remove unused functionality.\nDiscussion on discord about on-chain component\nStarted integration new on-chain api with current code (will open PR on this week)\nchore(sc_keystore): add Ownable to the contracts for access control\nfix(makefile): account for change in run function signature\nchore(bindings): regenerate contract bindings\nchore(contract): remove keypackage refs, regen bindings\n\n\nzerokit:vac:maintenance\n\nAnalysed current code in case of data serialization result in discord\nAdd small benchmark for different solution: benchmarks\n\n\nconsulting:codex:proxy-re-encryption\n\nReview of a proposal by Balasz with potential interest.\n\n\nadmin/misc\n\nscoped out next release of zerokit, v0.6.0\n\n\n\nvac:sc:: §\n\nstatus:staking-contracts-v1\n\nCreated explainer videos about staking protocol, it’s implementation and challenges we’re solving\nMet with Status Chain + TKE to discuss path forward\n\nConsidering dropping XP/MP compounding in staking protocol and simplifying it\nXP program and next staking version still to be finalized\n\n\n\n\ncodex::contracts-formal-verification\n\nHad a call with certora to discuss first application properties for us to implement\n\nDocument can be found here\n\nhttps://www.notion.so/Certora-Application-Properties-V2-b93f70fbaa0744a785460413f37afa6a\n\n\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:nimble\n\nBump and auto detect version: https://github.com/nim-lang/nimble/pull/1247\nTroubleshooting release issues\nRelease: https://github.com/nim-lang/nimble/releases/tag/v0.16.0\n\n\ntooling:vac:editor\n\nRelease https://github.com/nim-lang/vscode-nim/releases/tag/v1.0.0\nTroubleshooting release issues\n\n\ntooling:vac:lsp\n\nRefactor in preparation to chronos migration: https://github.com/nim-lang/langserver/pull/222\nTroubleshooting release issues\n\n\n\nvac:rfc: §\n\nadmin/misc\n\nooo\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nWas able to compile nim-testground-sdk and run basic ping tests. Some manually selected commit dependencies to avoid compilation failures of newest commits.\nWas able to integrate simulation script with sdk, and install nim-libp2p (commit dating to staggered sending) along with other dependencies (manually). Still facing a few compilation errors (expecting to fix these errors in a couple of days).\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nLooked into the possibility of handling large message counts in gossipsub. Required looking into some abstract details about farcaster network.\n\n\nzk:codex:zk-consulting\nFinished notes on Testudo.\nContinued work on document for Codex’s storage proof.\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\n\n\nWorked and expanded different components of state separation (executions, addresses, keys, nullification) [Moudy]\n\n\nMake progress with the blogpost [Moudy]\nAssisted with keys and addresses. [Moudy + Marvin + Ugur] [DR][ACZ]\n\nExamine how Ola/zcash keys system works: Ola1, Ola2, and zcash technical specs.\nDiscussed potential modifications to streamline this approach for Nescience, and possible concrete choices to be made.\n\n\nAssisted with lifecycles of UTXOs; provided answers to various questions. [Moudy + Marvin + Ugur] [DR][ACZ]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nWent through partial homomorphic encryption schemes’ materials. [Rostyslav]\nSet up SP1, RISC0. [Rostyslav]\nContinue looking for suitable repos + testing the base case. [Rostyslav]\nRead RISC0’s Poseidon254 implementation. [Oleksandr]\nRead Reinforced Concrete whitepaper. [Oleksandr]\nSet up Valida, zkMIPS, zkWASM. [Oleksandr]\n\n\n\n\n"},"vac/updates/2024-08-05":{"title":"2024-08-05 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/08/05 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDTLS: address Diego’s comments https://github.com/vacp2p/nim-webrtc/pull/10\n\n\nnimlibp2p:vac:maintenance\n\nDiscuss with Ivan about https://github.com/vacp2p/nim-libp2p/pull/1155\nReview PRs\n\n\nnimlibp2p:vac:maintenance\n\nfix: add gcc 14 support\nfix(ci): windows-amd64 (Nim version-1-6)\nfix(test): interop transport\nreviewing PRs\nCI Cleanup - PR\n\nUpdate with windows fix, now tests pass (except interop, which is not yet merged, but currently not required)\nRollback ubuntu-24.04 on i386, errors out\nDiscovered another flaky - Logs\n\n\nFix windows issue - PR\n\nInvestigate thoroughly. Quite sure it’s a Nimble issue, later today I’ll post an issue on their github.\n\n\n\n\nnimlibp2p:vac:quic\n\nevaluating quic implementations - https://github.com/cloudflare/quiche\n\n\n\nvac:tke: §\n\nadmin:\n\n1 CC day off (Frederico)\nFinalized first draft of strategy doc (Juan)\nupdated the TKE milestones (Status Network, Frederico)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\ncontinued writing the reports of studies 1 and 2 of the wealth concentration (Frederico)\nReviewed and provided feedback to Frederico’s work here (Juan)\n\n\nstatus:L2-deployment\n\nmodeled the location of fishes (Frederico)\nassisting defining the incentive structures, revising new proposed XP system (Martin)\nworking towards a minimal economy formalization for cats fishing based on feedback from Ned (Martin)\nMeeting with Ned, worked towards monetization document (Juan)\nFinished work on NPV analysis for swap aggregator (Juan)\n\n\nstatus:SNT-staking\n\nidentifying functional overlap with the need of the L2 incentive structure - again with the new XP proposal (Martin)\n\n\nwaku:general-incentives\n\npreparing for the call next week, identifying discussion points and actionable items (Martin)\n\n\ncodex:cdx\n\ncleaned up code (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nAttempt to fix Codex Kubernetes access\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nTest runs of 10K on latest Waku\nContinued metrics instability around 10k\n\n\nvac:dst:deployment-and-analysis:waku:midscale:\n\nRefactor log analysis code for Waku to use with Waku Simulator\nGet extended logs regarding future logging\n\nPotential bug in nimlibp2p’s yamux protocol\nmplex looks more promising\n\n\nExtended libp2p report\n\nAdd 1.1 results with other sizes than 500KB\nhttps://www.notion.so/Nim-libp2p-v1-3-0-regression-testing-June-2024-7e6fa14c829d4660be6739817e07956f\n\n\n\n\nadmin/misc\n\nPrepare DST presentation for Waku team\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\nupdate CI to use images from docker hub(@Florin)\nchore: RLNv2 tests update(@Roman)\nPR 62 - in progress - Lightpush remaining to test\n\nIssue 2946 - open\nIssue 2949 - open\n\n\n\n\nvac:test-automation-nim-libp2p\n\ncreated test plan for PubSub(@Florin)\ncreated test plan for FloodSub(@Florin)\nCI Cleanup - PR(@Alex)\n\nUpdate with windows fix, now tests pass (except interop, which is not yet merged, but currently not required)\nRollback ubuntu-24.04 on i386, errors out\nDiscovered another flaky - Logs\n\n\nFix windows issue - PR(@Alex)\n\nInvestigate thoroughly. Quite sure it’s a Nimble issue, later today I’ll post an issue on their github.\n\n\nBegin checking interop issue(@Alex)\n\n\nnomos:test-automation-data-availability\n\nchore: DA kzgrs unit tests update(@Roman)\nPR 676 - in review - kzgrs-backend will undergo rewrite for the next 2 weeks\n\n\nwaku:test-automation-rln\n\nMerge RLN PR(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nAssisted qa team in debugging nwaku tests\nchore(keystore): verbose error message when credential is not found\n\n\nsecure-channels:waku:mls-poc\n\nImprove the notes on the onchain component of the RFC.\nSync with team on payloads and ordering of the involved steps in adding members to groups.\nIntegration with new on-chain api branch\nfix(contract): convert to acl\n\n\nconsulting:codex:proxy-re-encryption\n\nFinish reading the proposal.\n\n\nanon:vac:gossipsub-anonymity\n\nTeam reviewed rfc and relevant protocols\n\n\n\nvac:sc:: §\n\nstatus:staking-contracts-v1\n\nfixed estimation of multiplier points (still needs tests)\nStill have to keep in mind that Status Chain decides against such a path\n\nhttps://github.com/logos-co/staking/commit/c1f283876cb47408d4e0db3b253ad1662004ecfa\n\n\nReviewed CovNFT from Optimism to see if we can take ideas from it\n\nhttps://github.com/GovNFT/contracts/blob/b7ce6ad869a8136a36f8130577ec7d21b2f785e4/src/GovNFT.sol\n\n\nUpgraded certora-cli on CI\n\nhttps://github.com/logos-co/staking/pull/96\n\n\n\n\ncodex::contracts-formal-verification\n\nWorked on implementing CVL rule described in https://github.com/codex-storage/codex-contracts-eth/issues/132\n\nTogether with Certora we’ve concluded that it’s likely not worth it anymore because those fields aren’t used for anything (they used to be used for fuzz tests it seems)\n\n\n\n\nstatus:community-contracts-maintenance\n\nUpgraded certora-cli on CI\n\nhttps://github.com/status-im/communities-contracts/pull/63\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:nimble\n\nReturns the nim directory prioritising the one used by the project instead of the one in the installed pkg list dir: https://github.com/nim-lang/nimble/pull/1250\n\n\ntooling:vac:lsp\n\nshould not crash when the projectMapping fileRegex is set to a non existing file fixes #221 (https://github.com/nim-lang/langserver/pull/223)\n\nFixes https://github.com/nim-lang/langserver/issues/221\n\n\nMigration to LSP\n\nComplete preparation refactor https://github.com/nim-lang/langserver/pull/222\nResearch best way to combine stdio and socket\n\n\n\n\ntooling:vac:editor\n\nIssue: New version of the plugin does not work on Windows https://github.com/nim-lang/vscode-nim/issues/78\n\n\ntooling:vac:compiler\n\nbump nimble https://github.com/nim-lang/Nim/pull/23918\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nWorked on codex validator, reading updated docs. Still in draft - https://github.com/vacp2p/rfc-index/pull/83\nHad a sync meeting with codex marketplace\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nWorked on large message handling blogpost. All comments are addressed; still WIP.\nLooked into IHAVE/IWANT message processing, small messages and peer scoring function for libp2p specs meeting\n\n\nzk:codex:zk-consulting\nBegan notes on Spartan.\nRead optimization of sumcheck for use in Spartan improvements.\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nMainly worked on the blogpost [Moudy]\nWorked on making keys and addresses concrete and riefly reviewed Aztec keys and addresses scheme. [Marvin][DR]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nContinued going through primitives and looking for suitable repos. [Rostyslav]\nPrepared testing for the base case for SP1 and RISC0. [Rostyslav]\nWrote simple arithmetic tests for Valida, zkMIPS, zkWASM. [Oleksandr]\n\n\nStarted working on blogpost. [Moudy]\n\n\n"},"vac/updates/2024-08-12":{"title":"2024-08-12 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/08/12 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDTLS: lot of fixes / changes\n\nhttps://github.com/vacp2p/nim-webrtc/pull/10\nadd trackers\nremove asyncspawn\na lot of fields are no longer exposed\nimprove comments\n\n\n\n\nnimlibp2p:vac:maintenance\n\nYamux Future leaks\n\nhttps://github.com/vacp2p/nim-libp2p/pull/1171\nhttps://discord.com/channels/864066763682218004/1270398374293667950\nFind a fix to the leak\n\n\nStart looking at the async exception tracking\n\nhttps://github.com/vacp2p/nim-libp2p/pull/1172\n\n\nfix: infinite loop when connection is aborted before being accepted\nfix(transport): tcp accept fixes\nInvestigate interop status and begin working towards solution\nBegin test plans: Implement gossipsub’s peer discovery test cases, some utility code and small refactor\n\nDraft PR\n\n\nDeeply investigate “unsub-sub backoff” test case, seemingly weird behaviour\nIssues: Rendezvous: Unsubscribed peers may be discovered - Issue\nPrepare interview and interview candidat\n\n\nnimlibp2p:vac:quic\n\ncreate a nim wrapper for cloudflare quiche\n\n\n\nvac:tke: §\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nFinish log analysis PR (ready for review)\nHelp Gabriel with mplex Future logging investigation\nRevisit message hash duplication issue\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nPerformed regression analysis for nim libp2p 1.5:\n\nRepeated 100-bytes results with version 1.2\nInitial 1.5 tests\nAfter Diego’s loop fix: https://github.com/vacp2p/nim-libp2p/pull/1166\n\n\n\n\nadmin/misc\n\nWings OOO last week\nHelping Jakub remove old DST-DeepResearch infra\n\nStill in progress\n\n\nDST Presentation for Status/Waku\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\ncheck lighpush errors and report issue(@Florin)\nadjust tests based on the latest lightpush changes(@Florin)\nstart looking at e2e tests(@Florin)\nchore: RLNv2 tests update(@Roman)\nPR 62 - merged\n\n\nnomos:test-automation-data-availability\n\nTest plan for Data Availability(@Florin)\nchore: Da kzgrs unit tests update(@Roman)\nPR 676 - merged\n\n\nvac:test-automation-nim-libp2p\n\nPost nimbledeps issue - Issue(@Alex)\nInvestigate interop status and begin working towards solution(@Alex)\nBegin test plans: Implement gossipsub’s peer discovery test cases, some utility code and small refactor.(@Alex)\n\nDraft PR\n\n\nIssues(@Alex)\n\nRendezvous: Unsubscribed peers may be discovered - Issue\n\n\nDeeply investigate “unsub-sub backoff” test case, seemingly weird behaviour(@Alex)\nPrepare interview and interview candidate(@Alex)\n\n\n\nvac:acz: §\n\nsecure-channels:waku:mls-poc\n\nFinished a new version of the onchain component in the RFC\nReviewed and left comments onchain component doc in notion\nFinished new flow for adding members to the group, update api regarding new smart contract: PR\n\n\nconsulting:codex:proxy-re-encryption\n\nIncluded a review of the proposal to Codex’s Notion document on plausible deniability.\n\n\nrlnp2p:waku:rlnv2-e2e\n\nwip implementation of new rln contract spec\n\n\nanon:vac:gossipsub-anonymity\n\nContinued implementing the Mix protocol PoC in Nim\nImplemented manual serialization, Proof of Work (PoW), tag manager, and Sphinx packet wrapping.\n\n\nadmin/misc\n\nStarted considering a new organization for the ACZ Notion page. The idea of the new organization is to highlight the cryptographic research done (and forthcoming) in ACZ.\n1 cc ooo one day\n\n\n\nvac:sc:: §\n\nstatus:staking-contracts-v1\n\nReviewed Status chain team work, written suggestions for the project\nMeeting with Status chain\n\nOnce again talked about desired features\nConcluded that we’ll keep MP within the staking protocol as internal measurement unit\nStake SNT -> gain MP -> get XP\n\n\nReviewed work on MP estimation\n\nFixed Estimation of MPs when staking on middle of epoch (normal user case)\nFound and fixed bugs: staking too low amounts (less than 53), doubled totalStaked on estimation\nDebugged the whole estimation and MP generation code on many different cases (see debug code here)\nAlso discussed outstanding things to be done for estimation\nCreated PR as base for discussion\n\nhttps://github.com/logos-co/staking/pull/97\n\n\n\n\n\n\ncodex::contracts-formal-verification\n\nMeeting with Certora\n\nClarified some open questions about Codex\nDiscussed open questions about CVL\n\nFound a bug in the prover that will be fixed by certora\n\n\n\n\nImplemented certora rules\n\nRequest state changes\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/142\n\n\nTotal supply == sumOfBalances\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/146\n\n\nTotal sent <= total received\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/147\n\n\nProof can’t be missing when in period\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/148\n\n\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:lsp\n\nChronos migration WIP: https://github.com/nim-lang/langserver/pull/225\n\n\ntooling:vac:editor\n\nFixes parameters for running nimlangserver.cmd on Windows fixes #80 #84\n\nhttps://github.com/nim-lang/vscode-nim/pull/84\n\n\nRelease https://github.com/nim-lang/vscode-nim/pull/85 https://github.com/nim-lang/vscode-nim/releases/tag/v1.0.1\n\n\ntooling:vac:compiler\n\nBump nimble https://github.com/nim-lang/Nim/pull/23918\n\n\nmisc\n\nTroubleshoot issues, review PRs\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nWorked on codex validator rfc, after discussion will be added to marketplace rfc\nMade some changes to marketplace rfc - https://github.com/codex-storage/codex-spec/pull/1\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nFinalized large message handling blogpost. The revised version is ready for review\nParticipated in libp2p specs meeting. Had to go through some potential suggestions regaring IHAVE/IWANT message handling.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nFinally able to compile and run staggered message sending simulation in test ground. Had to play with nimble/sdk files to get it compiled.\n\nStill facing issues regarding network reachability. But that can be resolved (looking into other testground SDKs for network connectivity)\nStill need to be able to parse and analyze output files.\n\n\n\n\nzk:codex:zk-consulting\n\nRead Mova and began notes\nContinued notes on Spartan\nWorked on in-node aggregation\n\n\n\nvac:nes: §"},"waku/2023-milestones":{"title":"2023 Milestones","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\nLink: https://github.com/waku-org/pm/issues/92\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1929\nhttps://github.com/fryorcraken/milestone-update/\n\n\n\nEpic: Simulation with 10k nodes\n\nLink: https://github.com/waku-org/pm/issues/85\nIssues in Epic:\nhttps://github.com/vacp2p/research/issues/191\n\nEpic: PostgreSQL in service node: Further optimisations\n\nLink: https://github.com/waku-org/pm/issues/84\nIssues in Epic:\nhttps://github.com/waku-org/nwaku/issues/1894\nhttps://github.com/waku-org/nwaku/issues/1893\nhttps://github.com/waku-org/nwaku/issues/1888\nhttps://github.com/waku-org/nwaku/issues/1885\nhttps://github.com/waku-org/nwaku/issues/1842\nhttps://github.com/waku-org/nwaku/issues/1841\nhttps://github.com/waku-org/nwaku/issues/1840\nhttps://github.com/waku-org/nwaku/issues/1604\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\nLink: https://github.com/waku-org/pm/issues/87\n\nEpic: 3.4: Further memberships\n\nLink: https://github.com/waku-org/pm/issues/72\n\nEpic: 3.3: Membership for Status Communities\n\nLink: https://github.com/waku-org/pm/issues/71\n\nEpic: 3.2: Basic DoS protection in production\n\nLink: https://github.com/waku-org/pm/issues/70\nIssues in Epic:\n\nhttps://github.com/waku-org/go-waku/issues/732\nhttps://github.com/waku-org/go-waku/issues/731\nhttps://github.com/waku-org/go-waku/issues/655\n\n\n\nEpic: 1.5: Launch and dogfood integrated public Waku Network MVP\n\nLink: https://github.com/waku-org/pm/issues/68\nIssues in Epic:\n\nhttps://github.com/waku-org/research/issues/1\n\n\n\nEpic: 1.4: Sharded peer management and discovery\n\nLink: https://github.com/waku-org/pm/issues/67\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1941\nhttps://github.com/waku-org/nwaku/issues/1940\nhttps://github.com/waku-org/js-waku/issues/1505\nhttps://github.com/waku-org/js-waku/issues/1504\nhttps://github.com/waku-org/go-waku/issues/727\nhttps://github.com/waku-org/go-waku/issues/680\nhttps://github.com/waku-org/go-waku/issues/679\nhttps://github.com/waku-org/go-waku/issues/678\n\n\n\nEpic: 1.3: Node bandwidth management mechanism\n\nLink: https://github.com/waku-org/pm/issues/66\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1947\nhttps://github.com/waku-org/nwaku/issues/1946\nhttps://github.com/waku-org/nwaku/issues/1945\nhttps://github.com/waku-org/nwaku/issues/1938\nhttps://github.com/waku-org/js-waku/issues/1503\nhttps://github.com/waku-org/go-waku/issues/677\n\n\n\nEpic: 1.2: Autosharding for autoscaling\n\nLink: https://github.com/waku-org/pm/issues/65\nNo issues in Epic description.\n\nEpic: 2.3: Basic distributed Store services\n\nLink: https://github.com/waku-org/pm/issues/64\n\nEpic: 2.2: Sharded capability discovery for light protocols\n\nLink: https://github.com/waku-org/pm/issues/63\nIssues in Epic:\n\nhttps://github.com/waku-org/js-waku/issues/1506\n\n\n\nEpic: 2.1: Production testing of existing protocols\n\nLink: https://github.com/waku-org/pm/issues/49\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1950\nhttps://github.com/waku-org/nwaku/issues/1948\nhttps://github.com/waku-org/nwaku/issues/1888\nhttps://github.com/waku-org/js-waku/issues/1463\nhttps://github.com/waku-org/js-waku/issues/914\n\n\n\nEpic: Dogfood RLN in production\n\nLink: https://github.com/waku-org/pm/issues/51\nNo issues in Epic description.\n\nEpic: Open membership mechanism\n\nLink: https://github.com/waku-org/pm/issues/52\n\nEpic: RLN validation in production\n\nLink: https://github.com/waku-org/pm/issues/55\n\nEpic: Autosharding - dogfooding\n\nLink: https://github.com/waku-org/pm/issues/58\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\nLink: https://github.com/waku-org/pm/issues/90\nIssues in Epic:\n\nhttps://github.com/fryorcraken/milestone-update/\nhttps://github.com/waku-org/js-waku/issues/1589\nhttps://github.com/waku-org/js-waku/issues/1435\nhttps://github.com/waku-org/js-waku/issues/337\nhttps://github.com/waku-org/js-waku/issues/1595\nhttps://github.com/waku-org/js-waku/issues/1597\n\n\n\nEpic: Automated Release processes\n\nLink: https://github.com/waku-org/pm/issues/86\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1889\nhttps://github.com/waku-org/js-waku/issues/1543\nhttps://github.com/waku-org/waku-rust-bindings/issues/67\n\n\n\nEpic: End-to-end testing\n\nLink: https://github.com/waku-org/pm/issues/34\nIssues in Epic:\n\nhttps://notes.status.im/s/iylE6wdli#\nhttps://github.com/waku-org/go-waku/issues/608\n\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\nLink: https://github.com/waku-org/pm/issues/88\nIssues in Epic:\n\nhttps://github.com/waku-org/go-zerokit-rln/issues/5\nhttps://github.com/waku-org/go-waku/issues/732\nhttps://github.com/waku-org/nwaku/issues/2033\nhttps://github.com/fryorcraken/milestone-update/\n\n\n\nEpic: REST API service node\n\nLink: https://github.com/waku-org/pm/issues/82\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1988\nhttps://github.com/waku-org/nwaku/issues/1985\nhttps://github.com/waku-org/nwaku/issues/1910\nhttps://github.com/waku-org/nwaku/issues/1909\nhttps://github.com/waku-org/nwaku/issues/1872\nhttps://github.com/waku-org/nwaku/issues/1652\nhttps://github.com/waku-org/nwaku/issues/1214\nhttps://github.com/waku-org/nwaku/issues/1076\nhttps://github.com/waku-org/nwaku/issues/938\nhttps://github.com/waku-org/go-waku/issues/264\n\n\n\nEpic: NodeJS Library\n\nLink: https://github.com/waku-org/pm/issues/81\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1332\n\n\n"},"waku/2024-gantt":{"title":"2024-gantt","links":[],"tags":[],"content":"Waku Roadmap 2024 Gantt Chart §\nStatus short term work only:\n\nreliability for 1:1 chat and communities\nup to 100 communities\n\nColour legend:\n\nRed: engineering work to deliver the feature.\nOther: test and telemetry work to ensure quality\n\nAnything prefixed TBC is pending confirmation of estimate with the team.\nCompletion dates are delivery of the code + dogfooding.\nIf too hard to read, try to see this fine in GitHub.\ngantt\n dateFormat YYYY-MM-DD\n axisFormat %d-%b\n weekday monday\n \n%% Milestones overview with deliverables\n section Store Service Upgrade\n Store v3-beta (msg hash): crit, milestone, after storev3-br, 0\n Store v3 (sync): crit, milestone, after storev3-r storev3-g storev3-n, 0\n DoS protection for req-res protocols: crit, milestone, after dosreqresn dosreqresj dosreqresg, 0\n PostgreSQL maintenance: crit, milestone, after pgsql, 0\n (metric) Count store messages: milestone, after count-store-msg, 0\n section Direct Message Reliability\n (testing) direct messages: milestone, after test-direct-msg, 0\n Review connection management: crit, milestone, after review-conn-mgmt-1 review-conn-mgmt-2, 0\n (tooling) filter and light push protocols: milestone, after lite-proto-tester, 0\n (telemetry) Fleet logging: milestone, after telem-fleet-logging, 0\n (telemetry) direct message reliability: milestone, after telem-d-msg-rel, 0\n Reliability Protocol for Relay: crit, milestone, after rel-relay-g rel-relay-n, 0\n Reliability Protocol for Resource-Restricted Clients: crit, milestone, after rel-reqres-g rel-reqres-j, 0\n Review MVDS usage and fail path: crit, milestone, after mvds, 0\n TBC User apps for large scale dogfooding: milestone, after user-app-gui, 0 \n section E2e reliability protocol\n (telemetry) Multicast message reliability: milestone, after telem-m-msg-rel, 0\n E2e reliability protocol PoC: milestone, crit, after e2e-rel-r, 0\n E2e reliability protocol Status integration: milestone, crit, after e2e-rel-g, 0\n section Static Sharding - dedicated shards\n (telemetry) Measure Bandwidth: milestone, after telem-bandwidth, 0\n Sharding peer mgmt and discovery hardening: crit, milestone, after sh-peer-mgmt-j sh-peer-mgmt-n sh-peer-mgmt-g, 0\n (testing) Custom shard impl of Communities: milestone, after test-custom-shard, 0\n\n%% Tasks\n section golang eng 1\n %% Estimation TBC - Prem says fine, waiting on 2nd opinion\n TBC Review connection management: crit, review-conn-mgmt-1, 2024-05-13, 8w\n Review MVDS usage and fail path: crit, mvds, after review-conn-mgmt-1, 6w\n Investigation and fixing of bugs discovered during dogfooding/usage/simulations: go-bugs-1, after mvds, 8w\n section golang eng 2\n Reliability Protocol for Relay (go): crit, rel-relay-g, 2024-05-13, 12w\n (testing) direct messages: test-direct-msg, after rel-relay-g, 4w\n TBC (testing) Custom shard impl of Communities: test-custom-shard, after test-direct-msg, 4w\n %% TBC estimate\n TBC E2e reliability protocol Status integration: crit, e2e-rel-g, after e2e-rel-r, 6w\n section golang eng 3\n Store v3 (go-waku client only): crit, storev3-g, 2024-02-26, 2024-05-24\n %% Estimate TBC - assuming parallel work possible\n TBC Review connection management: crit, review-conn-mgmt-2, after storev3-g, 8w\n Sharding peer mgmt and discovery hardening (go-waku): crit, sh-peer-mgmt-g, after review-conn-mgmt-2, 8w\n section golang eng 4\n Store v3 (sync): crit, 2024-02-08, 2024-04-26\n Reliability Protocol for Resource-Restricted Clients (go): crit, rel-reqres-g, 2024-05-13, 10w\n (metric) Count store messages: count-store-msg, after rel-reqres-g, 2w\n Investigation and fixing of bugs discovered during dogfooding/usage/simulations: go-bugs-2, after count-store-msg, 8w\n section golang eng 5\n DoS protection for req-res protocols (go-waku client only): crit, dosreqresg, 2024-05-20, 4w\n (telemetry) Multicast message reliability: telem-m-msg-rel, after dosreqresg, 4w\n section golang eng 6\n (telemetry) direct message reliability: telem-d-msg-rel, 2024-05-13, 6w\n (telemetry) Measure Bandwidth: telem-bandwidth, after telem-d-msg-rel, 8w\n section test eng 1\n Peer and connection management tests: sim-conn-mgmt, 2024-05-13, 4w\n (simulation) Functionality and stress test store v3: sim-storev3, after sim-conn-mgmt, 4w\n %% This is Store Service Upgrade - item (2) in DST simulation - start with small scale to get faster results\n (simulation) Compare store topologies: sim-store-cmp, after sim-storev3, 6w\n (simulation) relay reliability performance impact: sim-relay-rel, after sim-store-cmp sim-req-res rel-relay-g rel-relay-n, 4w\n (simulation) req-res reliability performance impact: sim-reqres-rel, after sim-relay-rel rel-reqres-g, 6w\n section research eng 1\n End-to-end reliability protocol - PoC: crit, e2e-rel-r, 2024-05-23, 20w\n section research eng 2\n %% Only dogfooding remaining\n Store v3-beta (msg hash): crit, storev3-br, 2024-01-01, 2024-05-23\n Store v3 (sync) research + RFC: crit, storev3-r, 2024-03-25, 14w\n Store v3 - follow-up: after storev3-r, 8w\n Peer mgmt - follow-up: after storev3-r, 8w\n section nim eng 1\n PostgreSQL Maintenance: crit, pgsql, 2024-01-01, 2024-07-31\n Reliability Protocol for Relay (nwaku + RFC): crit, rel-relay-n, 2024-06-19, 12w\n section nim eng 2\n DoS Protection for Req-Res Protocols: crit, dosreqresn, 2024-02-01, 18w\n (tooling) filter and light push protocols: lite-proto-tester, 2024-05-13, 2024-07-03\n Store v3-beta + v3 (dogfooding placeholder): storev3-df, after storev3-br storev3-r, 4w\n %% More hardening expected to deprecate or separate store v2 from v3 driver\n TBC Store v3-beta + v3 (nwaku hardening): crit, storev3-n, after storev3-df dosreqresn, 3w\n (telemetry) Fleet logging: telem-fleet-logging, after dosreqresn, 4w\n section nim eng 3\n Sharding peer mgmt and discovery hardening (nwaku): crit, sh-peer-mgmt-n, 2024-05-13, 12w\n section js eng 1\n Reliability for Req-Res Protocols (light client + RFC): crit, rel-reqres-j, 2024-05-01, 12w\n section js eng 2\n %% Buidling idle apps and integrating in telemetry service to learn\n Reliability for Req-Res Protocols (light client + RFC): crit, rel-reqres-j, 2024-05-01, 12w\n Sharding peer mgmt and discovery hardening (light client + RFC): crit, sh-peer-mgmt-j, 2024-06-01, 12w\n section js eng 3 (dev rel)\n %% TBC timing and estimate\n TBC User apps for large scale dogfooding - GUI and Gamification: user-app-gui, 2024-06-01, 4w\n"},"waku/2024-milestones":{"title":"2024 Milestones","links":[],"tags":[],"content":"Milestone Store Service Upgrade §\nDue Date: 2024-09-20\nWith this milestone, the store protocol becomes more easily usable for reliability purposes.\nMoreover, nwaku PostgreSQL implementation will enable better disk space management and enable operators to hard cap the used disk space.\nDeliverable: Store v3-beta - Message Hashes §\nEnable the Waku Network to provide distributed and synchronised store services.\nAn improved version of the Store protocol, marking a crucial increment towards a synchronisation protocol:\n\nintroduces the concept of deterministic message hashes to index messages\nconsiders the Store as a key-value store\nallows for querying a list of keys (message hashes) from the Store\nallows for querying for the full message content (values) of a set of keys from the Store\nkeeps all previous value-based filtering (e.g. content topic, timestamp) in place\n\nDeliverable: Store v3 - store synchronisation §\nUpgrade the Store service capability in the network from a collection of local, unsynchronised,\nsemi-centralised (trusted) service nodes to a decentralised service capability in the network with inter-node synchronisation.\nBuilding on Store v3-beta, this version of Store includes basic synchronisation between nodes. This will probably include:\n\na protocol/heuristic to resume store services after an offline period\na protocol/heuristic to periodically compare local key-value store with other nodes and find missing keys\na protocol/heuristic to periodically download the messages (values) for missing keys from other store nodes\n\nDeliverable: DoS protection for req-res protocols and metrics §\nAdd local DoS protection service nodes by applying request rate limitation on non relay protocols, including store.\n\nApply some limited bandwidth limitation on service protocols\nProvide failsafe mechanisms to third party apps / client side help for request rejection mechanisms\n\nDeliverable: PostgreSQL Maintenance §\nProvide a solution on how to best handle PostgreSQL database growth and pruning, so that node operators can predict database size and avoid disruptions due to full disk space.\nDeliverable: Metric: Count store messages §\nMessage-finder is used to compare the number of Status messages across Status nodes to understand the potential discrepancies and odd behaviour of messages being inserted in the past in a given channel.\nThis deliverable captures the message count on all Waku fleets to use as a metrics of the efficacy of store sync.\nMilestone Direct Message Reliability §\nDue Date: 2024-09-02\nWith this milestone, connectivity issues in Status Mobile and Desktop are solved and tested.\nUsage of store v3-beta casts a wide net on potential message loss, at the cost of bandwidth overhead (but still lower than current usage of storev2).\nReview of MVDS usage for all direct messages is done to ensure that critical messages (request to join, contact request, 1:1 messages, private group) are delivered.\nDeliverable: Enable testing of direct messages §\nProduce a CLI that enables black-box testing of the Waku integration in status-go. Focus should be on direct messages, including peer management and strategies when network connectivity is lost. This is to enable (1) of the Vac/QA dependencies. Note the CLI should sit under the Status Communities logic layer and focus on message delivery.\nDirect messages are used for critical chat features: contact request, community join request and response, 1:1 chat and private group.\nCurrently, if the connection is dropped, the recovery strategies implemented in status-go often fail.\nThe Waku team would provide a set of binaries to enable Vac/QA team to setup non-regression functional test (black box/e2e) as well as Vac/DST to run simulations in unreliable environments (latency, connection drop) to ascertain the reliability of the software, before it is touched by Status QA team.\nThe API of such binaries would be defined based on the needs from the Vac/QA-DST team.\nVac QA team is not expected to proceed with an extensive testing of the Communities functionality, but instead proceed with testing of direct message sending/reception considering various potential network faults.\nDeliverable: Review connection management strategy and back-off and fix long disconnection issues §\nReview disconnection and peer management in status-go and go-waku for both relay and light client protocols.\nEnsure that broken scenarios from dogfooding and Vac/QA testing are covered. Including but not limited to desktop sleep/hibernate and failure to send messages after current backoff strategy.\nThis includes moving peer management logic from status-go to go-waku for better separation of concerns.\nDeliverable: Tooling: filter and light push protocols §\nImplement a testing telemetry tool, a.k.a. lite-protocol-tester, that can measure the reliability of light push and filter from nwaku PoV. That tool should enable injecting messages, and produce the right logging. DST’s log tracing tool can then be used to create reports. This will help us to measure the current estate and evolution of the upcoming enhancements.\nDeliverable: Telemetry: fleet logging §\nEnsure that nwaku nodes in the status fleet log messages to enable traceability on both relay and filter/light push. Also ensure that sync (store v3) does highlight missed messages and related time to enable investigation on why 2 nodes were not synced.\nDeliverable: Telemetry: direct message reliability §\nReview and ensure the telemetry service can provide accurate statistics on message reliability with a mix of online presence report, message sending and receiving.\nThe measurement should be specific to direct messages to ensure that deliverables above do improve reliability in real usage.\nThis should include content topic data, to be used for later optimization.\nFor both Desktop and Mobile. Telemetry service should also be updated to ensure it covers the disconnection scenario for itself.\nNote that from Status’ team experience, the telemetry statistics have usually been more optimistic than reality, especially when there is a full network drop (ie, no messages going out).\nDeliverable: Reliability Protocol for Relay §\nDefine a protocol that leverages store v3-beta, to improve reliability when using Waku Relay, for both delivery and reception of messages.\nThis enables a local node to ensure it has the same view of the network as its peers.\nDeciding on how store v3-beta queries should be triggered and how often should be part of the protocol specifications.\nNote this does not provide end-to-end delivery as it only permits a local node to verify that its view of the network is similar to connected peers (and not peers further away in the network).\nThe reference implementation will be done in nwaku: The API should be simple and remove the need for protocol knowledge by the developer (e.g. send/receive verbs).\nThis should also be used by the light push and filter service (as service nodes).\nA similar logic should be implemented in Golang and used in status-go. RFC and collaboration with the nwaku team is expected to ensure similar implementation in both languages.\nDeliverable: Reliability Protocol for Resource-Restricted Clients §\nDefine and implement a protocol that improves reliability in web and mobile environments.\nIn this particular instance, js-waku will be the reference implementation of the designed protocol to enable focus of the js-waku team on resource-restricted environment and of the nwaku team on relay and service node matters/usage.\nThis deliverable includes the implementation of this protocol in go-waku (nwaku excluded). Work should be done in parallel and feed from each other.\nThe intent is to compose light push, filter and store v3-beta in combination.\nDeliverable: User apps for large scale dogfooding §\nNote: new deliverable, stemmed from discussion with js-waku team who have been working on resource-restricted reliability since earlier this year. Yet to be estimated and planned.\nJustification: testing and simulations have limitations in the context of heterogeneous network behaviour. The best testing comes from the real world/network environment, with real users.\nIt is expected that not all users will enable opt-in telemetry and that there will be a delay between library improvements and roll out.\nDeliverable: Review MVDS usage and fail path §\nReview MVDS usage for direct messages and ensure that the fail path is handled correctly with either feedback on the UI or automated retries.\nMVDS protocol is already in use for some direct messages. Ensure it is the case for contact requests, join requests, 1:1 chat and private groups.\nAlso review the fail path for MVDS (are messages retried later or is there feedback/retry on the UI)?\nThe output of this is likely to include GUI change recommendations to add retry buttons or just simply retry indefinitely (for contact requests etc) in addition to some logic change (e.g. ensure the retry happens after reconnection).\nMilestone End-to-end reliability protocol §\nDue Date: 2024-09-02\nTo solve reliability is to solve two problems:\n\nHigh heuristic that messages are received and sent\nAbility to know whether messages are received or sent\n\nProblem (1) can never be 100% reliable in a network environment. The previous milestones focused on it.\nTo solve (2), is to create an end-to-end protocol, sender to recipient, that enables the ability to know whether recipient(s) have received messages.\nWith this milestone, we design and deliver a first PoC for an end-to-end reliability protocol.\nThis protocol will be specified and implemented in the Status app for Status Communities chat rooms.\nDeliverable: Telemetry: multicast message reliability §\nReview and ensure the telemetry service can provide accurate statistics on message reliability with a mix of online presence report, message sending and receiving.\nThe measurement should be specific to multicast messages to ensure that deliverables above do improve reliability in real usage.\nThis should include content topic data, to be used for later optimization.\nFor both Desktop and Mobile.\nNote that from Status’ team experience, the telemetry statistics have usually been more optimistic than reality, especially when there is a full network drop (ie, no messages going out).\nDeliverable: End-to-end reliability protocol - PoC §\nDesign a protocol that enables end-to-end reliability for Status Communities channels.\nThe output is an agnostic RFC and a reference implementation in Golang (similar to MVDS library). However, it should take in account the context of Status Communities and leverage related properties (e.g. mostly online community owner nodes).\nThis deliverable does not include the integration in status-go, but it should provide enough information to then review with the Status app team how this protocol should be used in Status Communities. Parameters such as bandwidth usage and reliability level (e.g. N% of users acks) can then be discussed with the app team before implementation, as well as the type of messages that need such functionality (e.g. status update vs chat message in channel).\nDeliverable: End-to-end reliability protocol - Status integration §\nIntegrate the previously designed protocol in status-go with parameters agreed with the Status product team. Provide the right REST API (if needed) to ensure this is tested by Vac/QA.\nHarden the library as needed.\nMilestone Static Sharding - dedicated shards §\nDue Date: 2024-09-30\nCreating a new community on its dedicated shard would be tested and working, including assigning a pre-shared key for opt-in message signing (weak DoS protection).\nCommunity creation on a default shard (32) to remain (up to app team to hide button or not) to enable mass creation of communities on shared shard for QA testing purposes.\nVac QA and DST are asked to look at Status Communities behaviour, whereas previously the focus was on direct messages reliability (one layer lower).\nFinally, telemetry service will be updated to include bandwidth usage statistics, with a fine breakdown to understand top bandwidth consumers (control msg, chat msg, etc). Additionally, the DST team is asked to run simulations with a focus on bandwidth usage.\nDeliverable: Telemetry: Measure Bandwidth §\nAdd bandwidth measurements to the self-report (opt-in) telemetry service, including a message type breakdown (ctrl, chat, etc) when possible as well as other protocols such as discovery.\nUsage of non-waku bandwidth should also be considered (bittorrent, RPC) to have a full picture in case of report of high bandwidth usage by users.\nDeliverable: Sharding peer management and discovery hardening §\nFurther testing and improvement of peer management in the context of sharding in all Waku implementations. The aim is to ensure that nodes are connected to other nodes of interested shards. As the number of shards (several communities) increase, some improvement on the logic should be needed.\n(1) nwaku and go-waku need to follow the same pattern here in terms of relay peer management. For Relay peer management:\n\nremove named sharding to simplify peer management\nreview per-shard peer management metrics (e.g. mesh health per subscribed shard)\nmonitor and adapt peer management strategy across both go-waku and nwaku for various shard subscription scenarios (e.g. up to 100 pubsub topic subscriptions) in an integrated deployment\n\n(2) go-waku and nwaku should also follow the same patterns in terms of managing filter/ligh tpush clients (i.e. always keep a predictable amount of open slots for clients) with similar steps to the above to harden the strategy\n(3) go-waku and js-waku should follow the same patterns in terms of managing service peers within clients.\n(4) Capture recommendations in an RFC and use it as a discussion and decision medium across implementations.\nDeliverable: Enable testing of custom shard implementation for Communities §\nCreate/update CLI with REST API to enable creation and usage of static communities on own dedicated shard for Vac/QA to proceed with testing of various scenarios.\nThis CLI should also enable running simulations of bandwidth usage by communities, including ctrl messages.\nThis includes the setup of a pre-shared key to protect the shard and fixing any bug reported.\nNote that the ability to create communities on a custom shard and assign a pre-shared key for DoS protection is already implemented in status-go.\nNote that telemetry service should include shard specific reports.\nMilestone Bandwidth optimization and protocol review §\nDue Date: TBD\nBandwidth measurement from the previous milestone may lead to improvement that should be tackled with this milestone. This should be done in tandem with tackling low-hanging/high value items of the Status Community protocols potential scaling problems.\nFinally, usage of content topics should be reviewed to align with Waku’s recommendation, clear migration strategy, caveat and benefits should be outlined, such as future usage of auto-sharding and reduction of topics used by a single user for more efficient use of services.\nDeliverable: Status Communities protocol scaling/bandwidth optimization recommendation §\nSome of the Status Communities protocols potential scaling problems have already been mitigated. However, further work may be needed and identified from simulations and telemetry.\nThe output of this deliverable is to compile a list of recommendations, for both Waku and Status Communities protocol. This should include potential benefits of changes and enable scheduling the work between Status and Waku teams.\nDecision on the work to be done and planning it should be part of the output of this milestone.\nThis could include review of discv5 implementation in go-waku and nwaku if bandwidth usage is excessive.\nDeliverable: Review usage of content topics in Status Chat and Communities protocol §\nThe usage of content topics in Status is aligned with Wakuv1. Waku v2 comes with a new recommended format that enables auto-sharding.\nMoreover, single Status users currently use a high number of content topics, which may have an impact on performance of req-res protocols such as store and filter.\nSuch impact is to be measured in a previous milestone by Vac DST.\nThe output of this deliverable should be an RFC update on how content topics should be used, backed with simulations when performance improvement is expected.\nIt should include migration strategy and potential impact on the product.\nMilestone Scale up number of Communities §\nDue Date: TBD\nProceed with next steps to scale up the number of communities with a focus on testing and configure rendezvous which would enable a large number of communities on their own shard, with the caveat of a more federated global topology.\nThe rendezvous nodes of a community would be a centralised infra to a community.\nAlso proceed with enhancing of the current decentralised discovery protocol to pave the way towards less centralised topology.\nDeliverable: Usage of rendezvous §\nTest libp2p rendezvous in nwaku (server) and go-waku (client) to have it ready as a replacement of discv5 to enable over 100 communities.\nThis should mainly be around configuration, testing and potential bug fixing.\nRendezvous discovery is federated-like and non-private. It is an existing libp2p protocol.\nDeliverable: DoS protection for req-res protocols and metrics (go-waku as service node) §\nReplicate the DoS protection (local rate limit) logic from nwaku to go-waku as Status Desktop do serve filter and light push node.\nIf Desktop nodes get DoS via light push/filter service, then it can be disabled, however this may compromise scalability of mobile and would involve deploying more fleet.\nAs the desktop/mobile ratio is uncertain, best to have this implemented.\nMilestone Nwaku in Status Desktop (Relay, *nix) §\nDue Date: TBD\nWith this milestone, Status Desktop builds on Linux and Mac can use nwaku instead of go-waku.\nGo-waku will still be used for Windows (Desktop) and Status Mobile.\nDeliverable: Nwaku in Golang desktop §\nProvide a Golang library that uses the nwaku bindings (relay+store API) in a desktop environment. The bindings must be usable without RLN for the context of Status Desktop application.\nDeliverable: Nwaku in Golang: Relay §\nExpose and demonstrate the usage of relay protocols/API usef on go-waku by status-go in the Golang nwaku bindings.\nBuild on the previous by adding the APIs used by status-go in relay mode. Proceed with dogfooding of said APIs in PoC app to confirm their behaviour in Golang Desktop environment.\nThis includes work to ensure that the relay reliability protocol implemented in nwaku is used and other libp2p protocols such as autonat, circuit-relay client and hole-punching.\nLight client protocols are out of scope.\nDeliverable: Nwaku in Status Desktop (Relay, *nix) §\nUse nwaku instead of go-waku in Status Desktop and produce a working and distributable special (no light client) build for Linux and Mac OS environments.\n“Light client” mode should be disabled for this build as only relay protocols are implemented.\nWindows builds are also out of scope.\nThis includes an abstraction layer to enable the other builds to still use go-waku:\n\nDesktop Windows\nDesktop “prod” (with both light client and relay modes, via go-waku)\nMobile\n\nCLIs created for Vac/QA should also be produced with nwaku to enable QA and DST to run tests/simulations.\nMilestone Scale 1:1 chat messages PoC §\nDue Date: 2024-11-30\nImproved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.\nMoving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.\nDeliverable: RLNv2 in nwaku §\nImproved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.\nMoving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.\nNote this only concerns native libraries using nwaku.\nDeliverable: Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap §\nA review of RLN security parameters and functionality in preparation for mainnet deployment.\nAnalyse RLN deployment in the Waku proto-network and evaluate its DoS protection performance as well as review with the Status app team the potential cost mode of RLN:\n\nShould staking be introduced, especially to improve resilience against adversarial membership registrations?\nShould slashing be introduced or does the existing gossipsub scoring method provide enough protection?\nWhich chain or L2 should we target for memberships?\nWhat token should be used?\nDo we need a combination of msg/sec and msg allocation/day rate limiting?\n\nDeliverable: Provision RLN for light push clients PoC §\nDesign and implement a protocol that attaches RLN proof for messages received by light push services, enabling light clients to use the network without RLN.\nWith this deliverable, nwaku nodes deployed as service nodes lend their RLN memberships to light clients. Enabling Status app to offer a free tiers usage of RLN Relay for 1:1 chat messages.\nThis is a first PoC, learnings around RLN rate limit parameters, need of multiple RLN managements and service capability are expected to drive further development.\nDeliverable: Pay for RLN provision first PoC §\nProof of concept of paying for RLN provision to a light client by a service node.\nA POC payment mechanism that incorporates PoC versions of the three Waku service marketplace elements:\n\na price offer/negotiation mechanism\na proof of payment system\na local reputation mechanism to distinguish between “good” and “bad” service nodes\n\nSuch a PoC would enable discussion with the Status app team on a potential way to provide a paid tier to 1:1 chats users."},"waku/collaboration/guidelines-for-collaboration":{"title":"Guidelines for Collaboration","links":[],"tags":["waku","collaboration"],"content":"Guidelines for Collaboration §\nVisibility Into Work and Productivity §\n\nDaily Standup The stand-up channel on the Waku Discord server is where core contributors share their daily stand up summarizing their daily planned tasks.\nWeekly Report: Every Friday, all team members must add a comment to the Epic GH issue they own and worked on the past week or planned to work on next week. See Waku project management for more.\nTrack your work with Github issues: Make sure to always have an open Github issue corresponding to your current task. Follow the following post for some insights on how to write good Github issues.\nQuality Github pull requests: Github issues are (typically) followed by one or multiple Github pull requests (PR) to address the task(s) set out in the issue. PRs should be of reasonable size and with proper documentation. All commits within the PR should be signed. Do not forget to request PR review from your peers when your PR is ready. Before merging an open PR, all commits should be rebased on master and squashed into a single commit with a semantic commit message. Use the following guides on how to make a good PR\n\nAnatomy of a perfect pull request\nHow to write a perfect pull request. This post expands on good PR documentation and communication.\n\n\nPR Reviews: Spend a portion (10-20%) of your daily work reviewing other team members’ Pull requests. This will allow a swift and smooth development process.\nSeek feedback Do not hesitate to seek feedback from the senior members of the team, especially those who work closely with you.\nCommunicate effectively: Know the team members that are relevant to your project and get their feedback and comments on your project when need be.\n\nCommunication media §\n\nBasic principle: Waku is an open-source protocols and software. We are part of a wider community. As such, your first instinct should be to communicate as openly as possible in the forum/channel most suited to your query. That said, we have channels for team-internal communications that relate to project management, team travel or other more personal conversations.\nDiscord server: it takes a while to get used to the bewildering number of channels on the Waku Discord server. Here are some guidelines to help you get started:\n\n#intros: a good place to introduce yourself to the community once you’ve joined\n#gm: a quick “good morning” when you start your day adds to a friendly environment and shows other community members that you’re online\n#stand-up: daily one-liners indicating what your focus will be for the day\n#support: general support questions related to Waku protocols or the organisation\n#nwaku-contribute, #go-waku-contribute, #js-waku-contribute: discussions related to the nim, go and JavaScript Waku v2 clients respectively\n#team-pm-private: team-internal discussions related to Waku Product project management.\nWe maintain various team-internal channels, including #afk, #watercooler, #events, and more, which facilitate sharing while we work\n\n\nExamples:\n\nYou’re getting started and have a question related to the nwaku codebase: ask away in the open #nwaku-contribute channel. Feel free to tag specific people that you think may help, but don’t be too surprised if other community members jump in with an answer.\nWhile reading a Waku RFC you have a suggestion on how to improve the protocol: ping the team on the open #support channel for general question about protocols, or #rfc if it is about phrasing or clarity in the RFC. You could also create a GH issue in the vacp2p/rfc repository.\nYou want to inform the team that you’re off sick: use the team-internal #afk channel.\n\n\n\nAutonomy and Motivation §\n\nAlignment with principles: Waku follows a set of principles as described in https://status.im/about/, a good understanding of those is vital to making a meaningful contribution to the team. Should you have any questions regarding the principles, do not hesitate to reach out to your team members for more insights and explanations.\nFamiliarize yourself with relevant tools and tech Your work involves knowledge of the basics of Git and Github e.g., creating issues, pull requests (PRs), branches, merging, rebasing, etc. Spend some time and familiarize yourself with these concepts.\n"},"waku/collaboration/nwaku-release-process":{"title":"nwaku Release Process","links":["waku/collaboration/test-nwaku-on-status"],"tags":["waku","collaboration","nwaku"],"content":"Testing week §\nOn each release, we establish a testing period of one week, when we lock the waku.test fleet so that it only runs the target version. During that period, we need to continuously stress that fleet from the sandbox machine, for example.\nIt is important to make sure the waku-simulator works as expected and the nodes can establish connections among themselves.\nDuring that week, the release owner needs to check the Kibana logs from the previous month (since the last release was deployed) looking for possible crashes or errors in waku.test & waku.sandbox. These are the most relevant logs to check:\n\n(fleet: "waku.test" OR fleet: "waku.sandbox") AND message: "SIGSEGV"\n\nMake sure that Status client works properly when connected to a fleet running on the release candidate version. For it, please follow its corresponding guide.\nRelease Calendar §\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nNameDateRelease Ownernwaku-versionwakuv2.test deployment2024-01-15SP0.24.0wakuv2.prod deployment2024-01-22SP0.24.xwakuv2.test deployment2024-02-12Zoltan0.25.0wakuv2.prod deployment2024-02-19Zoltan0.25.xwaku.test deployment2024-03-11Zoltan0.26.0waku.sandbox deployment2024-03-18Zoltan0.26.xwaku.test deployment2024-04-15Gabriel0.27.0waku.sandbox deployment2024-04-22Gabriel0.27.xwaku.test deployment2024-05-13Gabriel0.28.0waku.sandbox deployment2024-05-20Gabriel0.28.xwaku.test deployment2024-06-10Ivan0.29.0waku.sandbox deployment2024-06-17Ivan0.29.xwaku.test deployment2024-06-24Ivan0.30.0waku.sandbox deployment2024-06-26Ivan0.30.xwaku.test deployment2024-07-22Ivan0.31.0waku.sandbox deployment2024-07-24Ivan0.31.xwaku.test deployment2024-08-26Zoltan0.32.0waku.sandbox deployment2024-08-28Zoltan0.32.xwaku.test deployment2024-09-23Zoltan0.33.0waku.sandbox deployment2024-09-25Zoltan0.33.xwaku.test deployment2024-10-28Gabriel0.34.0waku.sandbox deployment2024-10-30Gabriel0.34.x"},"waku/collaboration/onboarding-guide":{"title":"Onboarding Guide","links":[],"tags":["waku","collaboration"],"content":"Onboarding guide §\nWelcome to Waku! There’s quite a lot to learn so take your time. Here are a few links and some things to start with.\nVac & Waku §\nVac is a wide team that builds public good protocols for the decentralized web - vac.\nWaku originated as an incubation project within Vac with the goal of defining and implementing decentralized communication protocols. We have since evolved into a standalone team, while maintaining close collaboration with Vac, which continues to facilitate the RFC process - waku.\nAt Waku, each team member may split their working hours between research and sw development, depending on the team goals and personal interests.\n\nResearch: describe protocols in a formal/scientific way - https://github.com/waku-org/research.\nSW development: materialization of the protocols into software components - https://github.com/waku-org.\n\nCollaboration Guideline §\nHave a read at our Collaboration Guidelines to acquaint yourself with our collaboration best practices.\nStarter tasks §\n\n\nComplete the BambooHR tasks (can be followed in parallel with other tasks.).\n\n\nTry out the Status app\n\n\nGet familiar with Nim.\nRecommendations:\n\nStatus Nim Style Guide\nNim Language\n“Nim in Action” book (Dominik Picheta)\n“Mastering Nim” book (Andreas Rumpf)\nExercism course on Nim\n“Computer Programming with the Nim Programming Language” book (Stefan Salewski)\n\n\n\nMeet the Waku specification\nWaku is a communication layer for Web3.\nThere are three main Waku-client implementations:\n\nnwaku: Nim implementation aimed to be used by the infrastructure nodes.\ngo-waku: Golang implementation aimed to be used by the Desktop app.\njs-waku: JavaScript implementation designed to be run by web browsers.\n\nAside from the Waku project, Vac also gives a big contribution in the next ones:\n\nLogos, a Blockchain protocol whose clients would be built in Nim and Rust - Logos.\nCodex, a decentralized storage protocol (IPFS) - code-research, nim-codex.\n\n\n\nBuild nwaku. We encourage all core contributors to run a long-lived nwaku node as an operator. More details here.\nUseful resources:\n\nExamples\nDocs\n\n\n\nSkim specs (primarily Vac, but also Status) and try to get a picture of how things fit together. You do not have to read all the specifications all at once (it may get a bit confusing). We suggest start reading them in the following order, it is just a suggestion, feel free to do it the way you want!:).\n\n\nWhile reading RFCs note that there are two versions of WAKU namely WAKU1 and WAKU2. Vac RFCs related to WAKU2 are WAKU2 prefixed whereas other ones are prefixed by WAKU or WAKU1. For example, 8/WAKU-MAIL and 13/WAKU2-STORE are RFCs for WAKU1 and WAKU2, respectively.\n- 1/COSS\n- 10/WAKU2\n- 16/WAKU2-RPC\n- 11/WAKU2-RELAY | 14/WAKU2-MESSAGE | 23/WAKU2-TOPICS | 26/WAKU2-PAYLOAD\n- 12/WAKU2-FILTER\n- 19/WAKU2-LIGHTPUSH\n- 13/WAKU2-STORE\n- 18/WAKU2-SWAP\n- 27/WAKU2-PEERS\n- 15/WAKU2-BRIDGE\n\nJoin the Vac, Waku, and Nimbus Discord servers and say hi!\nRecommended: go through the list of existing open issues in the project repo (nwaku, go-waku or js-waku) you’ll mostly be working on and familiarise yourself with the current state of the project. This may take a while, but is an excellent exercise to get acquainted with some important conversations and project history. We encourage new contributors to ask questions in the comment sections of any past issues. You could even self-assign some issues that’s currently unassigned which you’d like to tackle! For this, the good-first-issue tag on Github may come in as a handy filter.\n\nResources §\nVac §\n\nVac overview\nVac.dev writeups\nVac RFCs/Specs\nCOSS process\n10/WAKU2 main spec\nVac forum\nVac 2021 Q3 priorities\nWaku v2 training session\nVac Sustainability and business workshop\n\nStatus §\n\nStatus whitepaper\nStatus principles\nStatus main client spec\nStatus specs\nStatus Discuss\nNimbus team\nnim-libp2p\n\nEcosystem §\n\nEthereum\nlibp2p\nlibp2p specs\n"},"waku/collaboration/test-nwaku-on-status":{"title":"Test nwaku on Status","links":[],"tags":["waku","status","collaboration","nwaku"],"content":"This document is based on the following recorded session\nIn order to test Nwaku on Status, you need to first deploy your release candidate to the shards.staging fleet. You will also need to build status-desktop by following the instructions here.\nOnce we are able to run status-desktop locally, run\nmake run ARGS="--enable-fleet-selection --datadir=./datadir1"\nThis will open Status Desktop. Create a new account, and once logged in go to Settings->Advanced->Fleet and select shards.staging\n\nAfter selecting the fleet, Status Desktop will close and you will need to run again\nmake run ARGS="--enable-fleet-selection --datadir=./datadir1"\nLog in with the password you set previously, and check thatshards.staging is configured\n\nIn the Advanced section again, please enable the following options:\n\nFull developer mode\nDebug\nNode Management\nEnable creation of sharded communities\nEnable Community Creation\n\nSome of these options might also close your Status Desktop window. If so, run again Status Desktop with the same command as before and check that all the above configurations are enabled.\nNow, open a new terminal and run a new instance of Status Desktop using a different directory for its database. For example\nmake run ARGS="--enable-fleet-selection --datadir=./datadir2"\nFollow the same steps as with the other Status Desktop instance, only changing the datadir flag\nWith the previous step completed, enter the Node Management section and check that both instances are connected to peers\n\nIn one of the accounts, copy the link to its profile\n\nAnd then, in the other account, send it a contact request\n\nMake sure you get a notification for it in your other window and accept the contact request\n\nChat between both accounts and check that messages get delivered properly\n\nFinally, test that the Store nodes work properly.\nFor it, close one of the windows and from the open window send messages to it.\nRe-run the Status Desktop instance you just closed and check that you receive the messages sent to you when you were offline.\nSome extra operations that we can run to double check everything is ok are:\n\nIn Node Management run the RPC method {"method":"settings_nodeConfig"} and check in the output that you are connected to the right fleet\nSimilarly, you can run the RPC method {"method":"wakuext_peers"} to get the list of peers\nCheck in Settings→Advanced→History nodes the history nodes we are connected to\n\nTo do: define how to test Status Communities"},"waku/index":{"title":"Waku Roadmap","links":["waku/collaboration","waku/process","tags/waku-updates","waku/reports","waku/2024-milestones","waku/2023-milestones"],"tags":["waku","roadmap","overview"],"content":"Roadmap Overview §\nTo learn more about Waku please visit the website, github, and docs.\n\nCollaboration\nProcess\nWeekly updates\nReports\n2024 Milestones\n2023 Milestones\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/process":{"title":"Process","links":[],"tags":["waku"],"content":"Resources §\n\nWaku Github: https://github.com/waku-org/\nEngineering Processes: https://github.com/waku-org/pm/blob/master/PROCESS.md\n\nMotivation and Goal §\nImplement the following attribute when delivering:\n\nClear tracking of work across the teams so that when we says that a milestone is delivered, then:\n\nit is usable by all types of users (operators, web devs, system devs).\nIt is documented (docs, dev rel)\nIt is of high quality (QA, Dogfooding)\n\n\nItems (epic, milestones) can be easily be closed and marked as complete thanks to:\n\nMinimal external dependencies\nMinimal intra-team dependency\nFinite, well-define scope.\n\n\nEach milestone and the effort needed to achieve it has a clear value thanks to a well-defined, value-driven, minimal, scope.\n\nTerminology and Scope §\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nNameNumber ofTimeframeTeam ScopeOwnerDescriptionMilestone?Pencilled for the year, planned for 2 quartersMost subteamsWaku LeadA, or cohesive set of, feature(s).EpicSeveral per milestoneSet for a milestoneUsually one subteam or external team (e.g. DST)Subteam Lead or MemberMilestone work for a given subteam.TaskMany per EpicSet monthly-ish, delivered weeklyOne subteam or individualTeam MemberMay be one or several piece of work, client specific.\nMilestone Definition §\nA Milestone:\n\nProvides a tangible user benefit: The milestone should aim to provide a distinct benefit or feature to the user, whether they are end users, operators or developers. In some case, a milestone may be a bundle of small features. The bundle of features should be cohesive and the benefit to the users should be easy to summarize. Most likely, a bundle milestone will be scoped to a given track.\nMinimal Scope: The milestone should be trimmed to a minimal scope, encompassing only what is just enough to assess the potential impact of these features on the project’s metrics (e.g. number of users, revenue). This means descoping any advanced features and aiming for a MVP-level delivery.\nTransversal: While the vertical scope of a milestone should be minimal, the delivery should be complete in terms of research, engineering, QA, documentation and dev rel assets so that the feature can be pushed to users once the milestone is marked as complete. Feedback loops should be as small as possible to ensure the value of a milestone is measured in a timely manner.\nAttached Estimate: An estimate should be associated with the milestone to facilitate the measurement of potential ROI. Additionally, tracking the estimate versus the actual progress is crucial for identifying any deviation and making informed decisions (e.g., deciding whether to continue if we learn the estimate is likely to be overrun).\n\nMilestone scoping process flow §\nPhase 1: Waku lead defines the scope within the Milestone. The scope is then discussed asynchronously in the comments of the GitHub issue by relevant subteams and stakeholders, scope of Epics and subtasks are defined.\nPhase 2: During a Waku PM call, the team reviews the Milestone to confirm scope or identify areas that require additional scoping.\nPhase 3: If the scope is agreed upon, the team can proceed to create Epics and schedule work for kickoff.\nEpics and Workflow §\nA milestone is divided in Epics. Each epic is assigned to a given subteam.\nEach Waku subteam lead (or selected member) is accountable for the delivery of their epic.\nTypically, each milestone will be divided in the following epics:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nEpic Label PrefixOwner Sub-teamOutputDescriptionE:researchWaku ResearchPoC, RFC, Protocol Simulations/StudiesInitial work done by the research team to create or change a protocol. Engineering-only Milestones may not have such epicE:nwakunwakuMVP quality softwareBring software to MVP level, proceed with re-architecture of PoC if needed, ensure functionality is usable, refine APIs, auto-generated/API documentation, ensure interoperability worksE:js-wakujs-wakuMVP quality software, including all supported env (e.g. React Native & Web)Implement protocol in js-waku, same as nwaku.E:bindingsnwakuMVP quality software for supported bindings (WIP)Expose new protocol/features on binding APIs.E:go-wakugo-wakuMVP quality software, include all supported bindings (i.e. C and Rust)Implement protocol in go-waku, only if needed by Status app.E:qaVac/DSTRFC-based + functionality based tests, both unit and integration tests.Test engineers take over and complete unit tests + add scenarios in integration test framework. In future, also add scenario to benchmark suite.E:dogfoodjs-waku, nwaku, bindingsLab example updates, own nodes updated, etc.Each dev team proceed by dogfooding the feature/API by using it themselves. Whether it is running their own node, or updating a selected number of examples. Go-waku can dogfood directly in status-go.E:docsDocDocumentation (not auto-generated)Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. This includes both coding guides but also a presentation ready visual documentation of the protocol behaviour.E:eco-devEco DevDev Rel assets (examples, video tutorial, etc), comms plan (X threads, blog posts)Dev Rel can now prepare assets to push the feature to developers, comms can prepare copies to communicate about it, BD can push it to projects and partners.\nflowchart LR\n subgraph milestone [Milestone]\n scope[Define scope and estimate] \n end\n subgraph researchE [E:research]\n scope-->research[RFC + Protocol Simulation + PoC] \n end\n subgraph nwakuE [E:nwaku]\n research-- Handover -->nwaku[MVP, API, Code doc, unit test]\n end\n subgraph js-wakuE [E:js-waku]\n research-- Handover -->js-waku[MVP, API, Code doc, unit test]\n end\n subgraph go-wakuE [E:go-waku]\n research-- Handover -->go-waku[MVP, API, Code doc, unit test]\n end\n subgraph go-wakuE [E:bindings]\n research-- Handover -->go-waku[API, Code doc, unit test]\n end\n subgraph qaE [E:qa]\n nwaku--Handover-->QA[QA, extended, interop and RFC-based testing]\n js-waku--Handover-->QA\n go-waku--Handover-->QA\n end\n subgraph dogfoodE [E:dogfood]\n nwaku-->Dogfooding[Developer use new software and API, interoperability]\n js-waku-->Dogfooding\n go-waku-->Dogfooding\n end\n subgraph docsE [E:docs]\n Dogfooding-- Handover -->Docs[Update and create guides and protocol documentation]\n end\n subgraph ecodevE [E:eco-dev]\n Dogfooding-- Handover -->Eco-Dev[Dev Rel and BD assets, plan Comms]\n Docs-->Eco-Dev\n end\n\nEngineering-Only Milestones §\nSome milestones may not involve the Waku Research team. In this case, the flow still applies but E:research is skipped.\nChat SDK and other Special SDK Work §\nThe Chat SDK team is focusing on go-waku integration in status-go and follows Status’ PM for issues and labelling.\nOnce the team starts building an independent Chat (or other) SDK, the flow will be as above but with research handled by VAC/ACZ and only one dev team:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nEpic PrefixOwner Sub-teamOutputDescriptionE:aczVac/ACZRFCRFC describing a specific, likely agnostic protocolE:chat sdkChat SDKPoC and then MVP quality software, Application RFCImplement the ACZ RFC, define API and application protocol\nHandover to QA, Docs, Eco Dev with MVP quality software is still expected down the track but may be pending growing teams.\nAccountability §\nEach epic should have an owner per subteam.\nMost epics will have a unique owner (e.g. a Waku Research team member owns a E:research epic).\nFor Dogfood and QA epics, one owner per client should be set.\nThe epic owner is responsible for breaking down the work in smaller issues in the related repo.\nFor research team, it is expected that most of the research work is done by the epic owner, which includes:\n\nCapturing problem statement\nDesigning protocol/solution\nImplementing PoC in reference implementation\nRunning tests/simulations to confirm behaviour (to be offloaded to test engineer)\n\nFor development teams, it is expected that design/break down is done by the epic owner.\nBut actual work can be picked up by other team member.\nEpic owner must:\n\nUnderstand the change and its implications,\nLiaise with researcher for any doubt or questions or design issues related to specific client/use case,\nCreate issues (Tasks) to break down work in client repo, include an acceptance criteria in each issue to ensure that the objective/end goal/behaviour is clearly described.\n\nIt is likely that the epic owner will do the core change or first change for a given epic.\nHowever, subsequent/other changes may be picked up in parallel or sequentially by other team members.\nHence:\n\ndependencies must be clearly stated in Task issue description\nTeam members must assign Task issues to themselves when work starts\nTeam members must update issues to track progress\n\nThe program manager should ensure that epics are getting the right assignee in a timely fashion.\nFor example, when research work starts for a given milestone, epic owners from development team should be assigned, so they know to participate in discussions.\nProgram manager should also ensure that issues are being created in a timely fashion,\nan is encouraged to use client PM call as a forum to check epics to be assigned, for example when a given epic is near completion.\nHandovers §\nThe following handovers are defined:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nHandoverExpectations when handing overExpectations when accepting handoverResearch to development teams- RFC PR is merged - PoC PR is merged- RFC content and PoC are reviewed - Own code and functionality - Own minor RFC changesDevelopment teams to QA- Happy path and selected error path tests exist - APIs are implemented to enable interop testing- Review RFC - Review existing testsDevelopment teams to Docs- Working usage of API is provided - Auto-generated documentation for public API is present- Review examples - Understands functionality Docs to Eco Dev- Docs PR is merged with functioning code- Understands functionality - Execute guides\nThe group or person handing over is expected to initiate a sync (meeting) or async (chat or GitHub) discussion to go through the output and overview.\nOnce the handover is accepted, the given epic can be closed.\nGitHub Usage §\nA Milestone:\n\nMUST have a matching GitHub issue in the https://github.com/waku-org/pm repo with milestone label assigned.\nMUST have a GitHub Milestone in https://github.com/waku-org/pm repo, to which relevant Epics are added.\nThe GitHub milestone MUST be used to track progress.\n\nAn Epic:\n\nMUST have a matching GitHub issue in the https://github.com/waku-org/pm repo.\nMUST have a label with format E:<prefix> <epic name>.\nSHOULD be added to a GitHub Milestone.\nSHOULD have a Planned Start and Due Date set (these are GitHub projects fields you can find in the Projects section of the issue view sidebar).\nMAY list Tasks present in other repos.\nMUST have assignee(s), who represent the epic owner (see accountability)\n\nA Task:\n\nMAY be tracked as a todo item in a GitHub Issue (Task or Epic),\nOR MAY be tracked as a single GH issue\n\nthat MUST be labelled with related Epic label (E:...),\n\n\nOR MAY be tracked as a GH Pull Request\n\nthat MUST have a reference to the related GitHub Task or Epic issue\n\n\nMUST have an acceptance criteria and/or a list of tasks (that can be other GH issues).\n\nFinally, for Tasks that do not belong to a given Epic or Milestone:\n\nMUST have either labels:\n\nbug: This is a bug, likely reported by a user\nenhancement: This is an enhancement out of the scope of the technical roadmap, likely reported by a user\n\nMajor enhancements should be carefully reviewed and prioritized.\n\n\ndocumentation: Documentation improvement or correction.\ndependencies: Upgrade dependencies in a timely manner to avoid time wasting when the dependency upgrade becomes critical.\n\n\n\nWhich means, in terms of navigation:\n\nWork for a Milestone is described in the related GitHub issue and tracked in the GitHub milestone.\nIn the GitHub milestone, we have a list of Epics to be achieved, the Epics are being closed as the work is done and handed over.\nTo look at remaining work for an Epic, one need to look at all issues (Tasks) with the corresponding Epic label (E:...)\n"},"waku/reports":{"title":"Waku Reporting","links":["waku/monthly-reports/2023-sept","waku/monthly-reports/2023-oct"],"tags":["wakureporting"],"content":"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\nMonthly Reports §\n\n2023 September\n2023 October\n"},"waku/templates/weekly-update-template":{"title":"TEMPLATE 2024-MM-DD Waku Weekly","links":[],"tags":[],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\nnext:\nblockers:\n\n\n\nStore v3 - store synchronisation\n\nachieved:\nnext:\nblockers:\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\nnext:\nblockers:\n\n\n\nPostgreSQL Maintenance\n\nachieved:\nnext:\nblockers:\n\n\n\nMetric: Count store messages\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - Direct Message Reliability §\n\n\nEnable testing of direct messages\n\nachieved:\nnext:\nblockers:\n\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\nnext:\nblockers:\n\n\n\nTooling: filter and light push protocols\n\nachieved:\nnext:\nblockers:\n\n\n\nTelemetry: fleet logging\n\nachieved:\nnext:\nblockers:\n\n\n\nTelemetry: direct message reliability\n\nachieved:\nnext:\nblockers:\n\n\n\nReliability Protocol for Relay\n\nachieved:\nnext:\nblockers:\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\nnext:\nblockers:\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\nnext:\nblockers:\n\n\n\nReview MVDS usage and fail path\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - End-to-end reliability protocol §\n\n\nTelemetry: multicast message reliability\n\nachieved:\nnext:\nblockers:\n\n\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\nnext:\nblockers:\n\n\n\nEnd-to-end reliability protocol - Status integration\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\n\nTelemetry: Measure Bandwidth\n\nachieved:\nnext:\nblockers:\n\n\n\nSharding peer management and discovery hardening\n\nachieved:\nnext:\nblockers:\n\n\n\nEnable testing of custom shard implementation for Communities\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nRLNv2 in nwaku\n\nachieved:\nnext:\nblockers:\n\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\nnext:\nblockers:\n\n\n\nProvision RLN for light push clients PoC\n\nachieved:\nnext:\nblockers:\n\n\n\nPay for RLN provision first PoC\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - Scale up number of Communities §\n\n\nUsage of Rendezvous\n\nachieved:\n\nnext:\nblockers:\n\n\n\n\n\nDoS protection for req-res protocols and metrics (go-waku as service node)\n\nachieved:\n\nnext:\nblockers:\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\nnext:\nblockers:\n\nBugs §\n\nachieved:\nnext:\nblockers:\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:\n\nPresented two talks last week. Logos + Waku at Web3Privacy meetup and RLN at DCxPrague.\nEthGlobal Istanbul - 20 projects submitted and contributed with production and mentorship\nsecured talks and presented at Libp2p day and EthGlobal\nrepresented Waku in pragma booth\nHelped organise Status-wide meetup during DevConnect\n\n\nnext:\n\npublish tic-tac-toe blog post\nmigrate examples from personal repository to examples repository and take responsibility of examples repo\nedit and send video tutorials for review for comms\nwrite event proposal for co-hosting LibP2P day in EthIndia along with Protocol Labs during the Waku hacker house\nEthIndia production works (finding venue, vendors for swag and booth)\nprocess and deliver devconnect feedback\nhelp draft devconnect winner promotions\nonboard the devconnect winners to Waku discord to Hackathon-winners channel\nprepare event report of Devconnect with help from Lou\nprepare KPI document for Eth India with help from Lou\n\n\n"},"waku/updates/2023-11-27":{"title":"2023-11-27 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Network Can Support 10K Users §\n\n\nachieved:\n\nconfirmed no unknown blockers from Waku’s side to continue dogfooding in conversation with Status Communities\ncontinuing team-internal dogfooding of a test community using static sharding https://github.com/waku-org/pm/issues/97. See dogfooding report\nfleet ownership training: held session for stakeholders on responsibilities - https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741\n\n\n\nnext:\n\ncontinue dogfooding of Status Desktop with Status staging fleet with test community (https://github.com/waku-org/pm/issues/97)\nfix issue of store fleet not connecting to bootstrap fleet due to enr shards mismatch https://github.com/status-im/infra-shards/issues/23\n\n\n\nrisks:\n\nFleet Ownership doc defines fleet maintainer and owner. Status team yet to clarify who is the fleet owner for Status Communities.\nQA by Status team to be planned on staging static sharding fleet; Waku team has done internal dogfooding (report). Any change to the staging static sharding fleet should then be tested by QA before being deployed to prod (e.g. # of Postgres instances). Status has committed to this testing on 28Nov call.\nStatus team expressed will to deploy static sharding prod fleet and use it for all users: This is not recommended until proper QA is done on stagning static sharding fleet as it could impact other Status app activities.\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 team since November 2023 to drive effort.\nDependency on Vac/DST to conclude ~1k nodes simulations; lack 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.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: fix issue of using default clusterID as 16 for shards fleet, dogfooding of status-desktop with shards fleet, debug issues in connection to fleet. See dogfooding report\nnext: continue dogfooding\nachieved: fix pubsub topic used for store queries, logic for finding free port when initializing torrent service, add back changes related to default shard that were reverted before, store clusterID in app database, refactor mailserver cycle to not require having an active connection to a store node\nnext: dogfooding\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nnext: Pending DST simulations of 10k nodes gossipsub network.\nrisks:\n\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under vac:dst:eng-10ktool.\n\n\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.\n\n\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\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\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nInternal dogfooding of proto-network continues.\njs-waku work continues.\nnwaku optimization around peer management are underway.\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. Tracked with #102\n\n\n\n4.1: Basic front end for node operator §\n\nachieved: follow ups and reduction of FE image;\nnext: double check with cors solved, minor improvements and fixes\n\n1.5: Launch and dogfood integrated public Waku Network MVP §\n\nachieved: come up with go-waku-compose to run a go-waku node in order to dogfood the public waku network\nnext: fix issues in go-waku-compose to support secure websockets and auto-fetch public IP\n\n1.4: Sharded peer management and discovery §\n[nwaku] chore: add sharding information to peer storage\n\nachieved: merged and closed\n\n[nwaku] chore: add sharding information to peer storage\n\nachieved: updated peer storage to include ENR\nnext: review feedback cycle\n\n[js-waku] feat: Deprecate Named Sharding and Update Lightpush Client API\n\nachieved: PR ready and currently in review-iteration phase ( #1697 )\nnext: to be merged\n\n[js-waku] feat: add new metadata protocol\n\nnext: unblock this issue by merging #1697\n\n1.2: Autosharding for autoscaling §\n[nwaku] chore: allow fetching cached messages by content or pubsub topic\n\nachieved: PR merged DONE!\n\n2.1: Production testing of existing protocols §\n[nwaku] feat: Migrate deployments to PostgreSQL\n\nachieved: Preparing environment to stress one single database with multiple Postgres clients writing and reading simultaneously.\nnext: Extend Postgres benchmarking report from previous results and start analyzing the performance of status.test fleet where three nodes will use one single database.\n\nPresentation Readiness §\n[js-waku] feat: filter subscription API\n\nachieved: PR opened and currently under review-iteration phase ( #1725 )\nnext: merge PR\n\nOther Work §\nEnhancements §\n[nwaku] chore(REST): adding to /admin/v1/peers response lightpush and filter v2 peer info\n\nachieved: merged PR and closed issue\n\n[js-noise] feat: allow parameterization of handshakes\n\nachieved: implemented parameterization of DH, Cypher and Hash\n\nBugs §\n[nwaku] bug: incomplete data sent or received log appearing when WSS is enabled\n\nachieved: attempted reproducing, haven’t gotten it to happen yet\nnext: succeed reproducing and fix\n\n[nwaku] bug: relay publish fails with 400 Bad Request when message contains meta field\n\nachieved: analyzed issue and started implementing fixes\nnext: continue implementing the solution\n\n[nwaku] bug: relay push with malformed timestamp crashes nwaku\n\nachieved: analyzed issue, found and implemented fix, raised PR in nim-json-serialization repo and implemented feedback. Merged fix and opened a PR in nwaku updating the dependency.\nnext: get nwaku PR reviewed y merge\n\n[go-waku] bug: duplicate validator for topic error when trying to re-subscribe to previously unsubscribed topic\n\nachieved: fix relay subscribe API issue causing failure in resubscription to a pubsubtopic, return appropriate errors in relay REST API\n\nDocumentation §\n[docs.waku.org] Advanced docs for js-waku\n\nachieved: published manage filter guide, finished react docs\nnext: ECIES and symmetric encryption/decryption\n\n[docs.waku.org] Docs general improvement/incorporating feedback (2023)\n\nachieved: added light mode toggle, updated the logos preset, added TWN guide, updated docs design and structure\n\nEcosystem Development §\n\n\nachieved:\n\nDocumentation refactor based on feedback\nPreparing react hooks for release\nEthIndia organizing\nWaku hackerhouse organizing\nETHIstanbul winner tweets\n\n\n\nnext:\n\nAnnounce react hooks\nWaku hackerhouse\n\n\n"},"waku/updates/2023-12-04":{"title":"2023-12-04 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Network Can Support 10K Users §\n\nachieved:\n\nconfirmed no unknown blockers from Waku’s side to continue dogfooding in conversation with Status Communities\ncontinuing team-internal dogfooding of a test community using static sharding https://github.com/waku-org/pm/issues/97. See dogfooding report\nfleet ownership training: held session for stakeholders on responsibilities - https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741\n\n\nnext:\n\ncontinue dogfooding of Status Desktop with Status staging fleet with test community (https://github.com/waku-org/pm/issues/97)\nfix issue of store fleet not connecting to bootstrap fleet due to enr shards mismatch https://github.com/status-im/infra-shards/issues/23\n\n\nrisks:\n\nFleet Ownership doc defines fleet maintainer and owner. Status team yet to clarify who is the fleet owner for Status Communities.\nQA by Status team to be planned on staging static sharding fleet; Waku team has done internal dogfooding (report). Any change to the staging static sharding fleet should then be tested by QA before being deployed to prod (e.g. # of Postgres instances). Status has committed to this testing on 28Nov call.\nStatus team expressed will to deploy static sharding prod fleet and use it for all users: This is not recommended until proper QA is done on stagning static sharding fleet as it could impact other Status app activities.\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 team since November 2023 to drive effort.\nDependency on Vac/DST to conclude ~1k nodes simulations; lack 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.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: fix issue of using default clusterID as 16 for shards fleet, dogfooding of status-desktop with shards fleet, debug issues in connection to fleet. See dogfooding report\nnext: continue dogfooding\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nnext:\n\nPending DST simulations of 10k nodes gossipsub network.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked undervac: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.\njs-waku work continues.\nnwaku optimization around peer management are underway.\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. Tracked with #102\n\n\n\n4.1: Basic front end for node operator §\n[nwaku] bug: access-control-allow-origin should be set to localhost\n\nachieved: understood and applied initial fixes, tested, found bug and got it to work\nnext: add tests for changes in presto, raise PRs in both presto and nwaku\n\n1.4: Sharded peer management and discovery §\n[nwaku] feat: Peer management with shard as a dimension\n\nachieved: sharded peer management final version in review\nnext: review feedback\n\n1.2: Autosharding for autoscaling §\n[nwaku] chore: allow fetching cached messages by content or pubsub topic\n\nachieved: PR merged DONE!\n\n[js-waku] feat: Autosharding API for req-resp protocols\n\nachieved: config node for static/autosharding, test all protocols against autosharding RPC endpoints on nwaku\nnext: config application and version on node creation, only discover nodes of same shard\n\n[js-waku] (https://github.com/waku-org/js-waku/issues/1500)\n\nachieved: all protocols can be configured to use autosharding for determining pubsub topics\nnext: make autosharding the default behavior when running js-waku\n\nOther Work §\nEnhancements §\n[go-waku] feat: use current timestamp when not provided in relay rest api\n\nachieved: return error in relay API when message gossipsub threshold is crossed, fill messageTimestamp if RLN is enalbed and not set in WakuMessage, improve errors returned for filter unsubscribe APIs\n\nBugs §\n[nwaku] bug: incomplete data sent or received log appearing when WSS is enabled\n\nachieved: reproduced it, did superficial checks but couldn’t get deep enough to find the root cause\nnext: continue investigating\n\n[go-waku-compose] fix: automatic fetching of public ip not working\n\nachieved: made go-waku-compose ready to run go-waku node to support the public waku network\n\nDocumentation §\n[go-waku] doc: best practice to handle disconnection when sending messages over relay\n\nachieved: provided a short-term approach to address message send/receive issues during disconnections, intiated discussions in nimbus and vac channels to find out possible approaches being used in other protocols using gossipsub\n\nEcosystem Development §\n\nachieved:\n\nReviewed upcoming Waku press release\nCreated new bounties: 1, 2\nReviewed expectations for EthIndia and the Waku Network\n\n\n\nChat SDK §\nchat-sdk-tracking\n\nachieved: Running custom built desktop with status-go, working on community store node\nnext: continue working on community store node\nblocker: no so far\n\nProject Management §\n\nachieved:\n\nOpen discussion around project management, milestones and expectations from Logos Program.\nEnsure critical work for Status app is tracked and planned: 1, 2\nVarious hiring activies: BD, Growth lead and how to handle js-libp2p maintenance\nReview Status plans around testing static sharding and ensure potential risks are understood.\nFind a spot to host studies and simulation output as part of our commitment to build in the open and awarness of potential deplatforming: [1, Waku Discord]\nDrafting updated PM tracking proposal\n\n\nnext:\n\nResume discussion around Nim usage and multiple clients in Waku: 1\nReview 2023 achievements and start planning 2024 milestones.\nShare proposal doc to Waku cc’s for review\n2024 Research milestone tracking\n\n\n\nBasic Dev Rel Assets\n\nachieved: Lead conversion process and community engagement process docs completed\n"},"waku/updates/2023-12-11":{"title":"2023-12-11 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Network Can Support 10K Users §\n\nachieved:\n\nfixed issue of store fleet not connecting to bootstrap fleet due to enr shards mismatch https://github.com/status-im/infra-shards/issues/23\ncontinuing team-internal dogfooding of a test community using static sharding https://github.com/waku-org/pm/issues/97. See dogfooding report\nbenchmarked various ways for large postgresql deployments: https://github.com/status-im/infra-status/issues/37\n\n\nnext:\n\ncontinue dogfooding of Status Desktop with Status staging fleet with test community (https://github.com/waku-org/pm/issues/97)\n\n\nrisks:\n\nFleet Ownership doc defines fleet maintainer and owner. Status team yet to clarify who is the fleet owner for Status Communities.\nQA by Status team to be planned on staging static sharding fleet; Waku team has done internal dogfooding (report). Any change to the staging static sharding fleet should then be tested by QA before being deployed to prod (e.g. # of Postgres instances). Status has committed to this testing on 28Nov call.\nStatus team expressed will to deploy static sharding prod fleet and use it for all users: This is not recommended until proper QA is done on stagning static sharding fleet as it could impact other Status app activities.\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 team since November 2023 to drive effort.\nDependency on Vac/DST to conclude ~1k nodes simulations; lack 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.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: fix peer manager to take into account the ENR seq to determine if a peer is new or not and fix incorrect number of connected peers per topic. Register lightpush protocol correctly in go-waku. Drop pubsub topic bridging. Use shards.test fleet as default (in status-go and desktop)\nnext: continue dogfooding / fixing issues\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nResearched various ways of deploying shared postgresql instances for large deployments: https://github.com/status-im/infra-status/issues/37\n\n\nnext:\n\nPending DST simulations of 10k nodes gossipsub network.\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 §\n1.4: Sharded peer management and discovery §\n[nwaku] feat: Peer management with shard as a dimension\n\nachieved: sharded peer management and store pruning PR merged\n\n1.2: Autosharding for autoscaling §\n[js-waku] feat: make autosharding default node behavior\n\nachieved: open PR to reintroduce (but deprecate) name sharding alongside auto/static sharding without breaking APIs\nnext: update all examples to use autosharding\nblocker: need review on https://github.com/waku-org/js-waku/pull/1723\n\nSupport Many Platforms - 2024-04-30 §\nREST API service node §\n[docs.waku.org] REST API/ NodeJS\n\nachieved: added references for the REST API\n\nOther Work §\nResearch §\n[research] Onchain RLN tree+root: Proof Of Concept\n\nachieved: We present a proof of concept change in the RLN contract to store the whole membership tree on-chain + its Merkle root. This lowers sync time from several minutes to a few seconds, but at a cost of x10 the membership insertion cost. It also makes light clients lighter since proof verification becomes stateless (Merkle root can be accessed onchain, without having to sync the tree). We also present go-waku-light, to showcase the newly introduced features and how they are meant to be used.\n\nEnhancements §\n[nwaku] chore: avoid blocking the whole waku node when retention policy is being applied\n\nachieved: avoid blocking the whole waku node when the retention policy is being applied\n\nDocumentation §\n[docs.waku.org] Encryption documentation\n\nachieved: push initial draft for symmetric, ECIES, message signing\nnext: merge and deploy encryption docs #145\n\n[docs.waku.org] Docs general improvement/incorporating feedback (2023)\n\nachieved: add RN warning, add certbot instructions, improve nwaku-compose guide\n\nChores §\n[nwaku] Bump vendor dependencies for release 0.23.0\n\nachieved: bumped nim-dnsdisc dependencies\nnext: bump nim-waku dependencies\n\nEco Dev §\n\nachieved: 51 projects submitted at EthIndia hackathon\n"},"waku/updates/2023-12-18":{"title":"2023-12-18 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-12-18 Waku weekly §\nTargeted dogfooding for Status Communities §\n\nachieved: fix panic on logout, publish messages async, fix loading message history for communities, fix invalid bootnodes being used on status desktop, status dogfooding, raise issues and optimizations needed wrt light protocols usage in status-go and improvements to be done in nwaku,\nnext: continue dogfooding / fixing issues\n\nSupport Many Platforms - 2024-04-30 §\nPresentation Readiness §\n[js-waku] feat: filter subscription API\n\nachieved: rebasing\nnext: error handling via event emitter as well. plan if restructuring is required.\n\nOther Work §\nEnhancements §\n[nwaku] feat: Have additional Admin REST API endpoints that helps node operator in monitoring\n\nachieved: improved logging and merged. Created locally a new REST endpoint that returns the information of all the filter subscriptions on a service node\nnext: add unit tests, update documentation and open PR\n\n[research] Sync store baseline understanding\n\nachieved: PoC of Prolly Tree (fixing a Bug), insertion and deletion of data into it.\nnext: a writeup about Prolly trees PoC in issue, further testing, generating some operational data details such as memory consumption using RLN specs.\n\nBugs §\n[nwaku] bug/regression: Relay connection works no more\n\nachieved: reproduced the issue both in testing framework and with local nodes, analyzed logs and narrowed down to the commit where things got broken\nnext: continue investigating, find root cause and fix\n\n[nwaku] bug: no messages returned from store node when multiple content topics and start/end time are used\n\nachieved: bug fix store service in nim-waku when the query used more than one content topic\n\nDocumentation §\n[docs.waku.org] Document how to use k-anonymity with content topic\n\nachieved: add content topic buckets consideration #153\n\nChores §\n[nwaku] Bump vendor dependencies for release 0.23.0\n\nachieved: bump all nim-waku vendor dependencies\n"},"waku/updates/2023-12-25":{"title":"2023-12-25 Waku weekly","links":[],"tags":["waku-updates"],"content":"Happy Holidays!\n1.3: Node bandwidth management mechanism §\n\nachieved: make configurable the max message size in nim-waku https://github.com/waku-org/nwaku/pull/2298\n\n1.2: Autosharding for autoscaling §\n[js-waku] feat: make autosharding default node behavior\n\nachieved: merged PR that implements autosharding after feedback. PR to reintroduce named sharding ready for review\nnext: update all examples to use autosharding\n\nOther Work §\nChat SDK §\n[chat-sdk] chat-sdk tracking\n\nachieved: close connections for filter light client, draft a doc about messages on the relay\nnext: work on user cannot join the community bug\n\nResearch §\n[nwaku] feat: experimental incentivize store protocol\n\nachieved: continued discussion on incentivization RFC\nnext: move towards implementation\n\nEnhancements §\n[nwaku] feat: Have additional Admin REST API endpoints that helps node operator in monitoring\n\nachieved: improved initial implementation. Added unit tests, updated documentation, opened and got approved PR.\nnext: verify if there’s other places where the new endpoint should be document before merging\n\n[research] Sync store baseline understanding\n\nachieved: PoC of Prolly Tree feature complete, Postgres retention policy PR, diff protocol ground work started.\nnext: pending technical writeup about Prolly trees PoC in issue, Diff protocol, generating some operational data details such as memory consumption using RLN specs.\n\nBugs §\n[nwaku] bug/regression: Relay connection works no more\n\nachieved: reproduced, investigated, found root causes and fixed\n\n[nwaku] bug: lack of error checking in publish\n\nachieved: reproduced, investigated and started improving error handling\nnext: continue with the implementation\n\nPM §\n\nachieved: proposed Waku strategy draft to team and started discussions\nnext: continue Waku strategy discussion, publish strategy/discuss with Logos leadership, continue drafting Waku roadmap for 2024\n"},"waku/updates/2024-01-08":{"title":"2024-01-08 Waku weekly","links":[],"tags":["waku-updates"],"content":"2024-01-08 Waku weekly §\nWaku Network Can Support 10K Users §\nTargeted dogfooding for Status Communities §\n\nachieved: status-mobile dogfooding, debug and attempt to identify root cause of filter delay issue\nachieved: attempt to identify root cause of filter delay issue, work on upgrading status-go to use Go 1.21 (to use latest go-libp2p), use latest go-waku version and identify missing commits between release and develop branch\nnext: continue dogfooding / fixing issues\n\nWaku Network Gen 0 - 2023-12-01 §\n1.5: Launch and dogfood integrated public Waku Network MVP §\n\nachieved: add new metrics and make go-waku-compose dashboard functional, dogfooding the network with go-waku node\nnext: fix few pending items in dashboard\n\nOther Work §\nEnhancements §\n[nwaku] feat: Have additional Admin REST API endpoints that helps node operator in monitoring\n\nachieved: got feedback about improved error handling. Added it to the code, got a segfault from the testing framework, investigated and found the root cause.\nnext: define how to proceed based on the testing issue and merge the PR\n\n[nwaku] feat: Have additional Admin REST API endpoints that helps node operator in monitoring\n\nachieved: improved initial implementation. Added unit tests, updated documentation, opened and got approved PR.\nnext: verify if there’s other places where the new endpoint should be documented before merging\n\n[waku-rust-bindings] Peer discovery & management \n\nachieved: Added dns discovery parameters to the node config\n\n[research] Sync store baseline understanding\n\nachieved: 1-day work this week due to time off, nim implementation of Prolly trees\nnext: Diff protocol discussion, Sync mechanism on wire query protocol discussion, generating some operational data details such as memory consumption using RLN specs.\n\n[go-waku] feat: parameterizable number of connections per IP\n\nachieved: Maintain parity between nwaku and go-waku clients\n\nBugs §\n[nwaku] bug: sort order ignored in store nodes\n\nachieved: created v0.23.1-rc.0 and deployed in status.test fleet.\nnext: Deploy v0.23.1 to both status.test and status.prod after having the approval from @richard-ramos and @mprakhov\n\n[nwaku] bug: lack of error checking in publish\n\nachieved: fixed compilation errors, got it to work and tested it\nnext: add test cases to the codebase and open PR\n\n[go-waku] bug: filter/v2/subscriptions take a lot of time and even timeout sometimes\n\nachieved:fix panic when static peer is also discovered dynamically, fix ENR Waku field population for Fitler, analyze data races identified\n\n[go-waku] bug: update examples to use autosharding\n\nachieved: update basic_relay example to use static and autosharding\n\nDocumentation §\n[go-waku] bug: update examples to use autosharding\n\nachieved: update basic_relay example to use static and autosharding\n\n[go-waku] chore: create docs for setting up a systemd service and exit codes\n\nachieved: Added systemd template and docs\nnext: Add env variables suggested by infra\n\nPM §\n[pm] Waku Research - Post Gen 0 Milestones and Epics\n\nachieved: Significantly refined milestones and epics and started getting feedback from stakeholders\nnext: Further stakeholder engagement. Define work needed to improve RFC process.\n\nChores §\n[nwaku] Bump vendor dependencies for release 0.24.0\n\nachieved: bump dependencies to prepare the v0.24.0.\n"},"waku/updates/2024-01-22":{"title":"2024-01-22 Waku weekly","links":[],"tags":["waku-updates"],"content":"Waku Update §\n\nCurrently the Waku team is focused on completing the remaining critical TWN Generation 0 Milestone Epics, the Status Integration, and various bug fixes and enhancements.\nWaku’s development is divided among 5 teams: nwaku, go-waku, js-waku, chat-sdk, and ecosystem-development.\n2024 Milestones and Epics are currently being structured, kickoffs slated begin first week of February.\nThe go-waku and chat-sdk teams were at the Status integration Doha offsite January 13 - 21.\n\nWaku Network Gen 0 §\nOpen Epics\n\nAutosharding for autoscaling | js-waku | critical | 66%\nNode bandwidth management mechanism | nwaku | not critical | 0%\nSharded peer management and discovery | js-waku | critical | 87%\nLaunch and dogfood integrated public Waku Network MVP | nwaku | critical | 0%\nProduction testing of existing protocols | js-waku & nwaku | critical | 40%\nSharded capability discovery for light protocols | js-waku & go-waku | critical | 0%\nBasic DoS protection in production | go-waku & research | critical | 28%\nBasic front end for node operator | js-waku & nwaku | critical | 83%\n\nJanuary 22 Update §\nnwaku §\nTWN Connectivity\nPrepare release 0.24.0\n\nachieved: big picture solutions for TWN connectivity problem , coordinate nwaku v0.24 release candidate\nnext: Nwaku v0.24.0 test and release, autosharding/cluster-id error handling, moar connectivity research\n\nbug: restart loop of current master\n\nachieved: investigated, found the root cause and solution. Afterwards, got requested a change in logging, implemented it and raised PR.\nnext: get confirmation that the change in logging meets Infra’s needs and get the PR reviewed and merged\n\nfeat: REST API - large messages does not seem to be rejected by relay auto api\n\nachieved: developed and tested an initial working implementation\nnext: after talking to Franck, will implement it differently with a more generalized message verification logic\n\nchore: improve POST /relay/v1/auto/messages/{topic} error handling\n\nachieved: fix compilation errors, open PR, implement feedback and merge\n\nbug: incomplete data sent or received log appearing when WSS is enabled\n\nachieved: investigated code, ran private images with logs on nim-libp2p and analyzed results. Talked to nim-libp2p team to further understand where the failure happens\nnext: investigate further with the new understanding after talking with nim-libp2p team\n\nchore: review waku-simulator deployment and improve tracking processes\n\nachieved: found that simulator’s nwaku image wasn’t getting updated with latest master. Requested Infra for the fix and verified afterwards that it’s working properly\nnext: talk with stakeholders to see what metrics/logs we should keep track of and how\n\nbug: Filter doesn’t receive messages after subscribing and restarting\n\n_achieved:_ investigated and fixed cause of failing test\n\nchore: Refactor of FilterV2 subscription management with Time-to-live maintenance\n\nachieved: Filter V2 subscription management reworked: new Time-to-live tracking, configurable limits of peers served and suvbscriptions per peer. Subscription per request is raised from 30 to 100 (hardcoded)\n\nbug: access-control-allow-origin should be set to localhost\n\nachieved: Alignment with Eugen (presto and chronos maintainer) is made upon the solution to be applied on presto rest server class.\nnext: Once new desing is ready and pushed to presto library, we can add the already prepared “allowed origin” matching mechanism that will enable proper CORS header in response to rest request.\n\nfeat: Enforce service specific rate limits\n\nnext: measurement of usage rates of store protocol to be added (also add to grafana dashboard), add configurable limits (query per sec/min)\n\njs-waku §\nchore: upgrade lip2p\nfeat: set cluster ID as optional when specifying shard info\nfeat: Peer management with shard as a dimension\n\nachieved:\n\nupgrade libp2p to 1.X\nimproved how params are handled between consumer-facing and internal functions\nfix failing tests for autosharding peer mgmt\n\n\n\nallow user to pass content topic to createSubscription\nfeat: sdk function to setup autosharding node with application and version\nfeat: determine bootstrap behavior based on sharding type\n\nnext:\n\nallow creating subscriptions with just content topics\nsetup node with just application and version\ndetermine boostrap behavior based on sharding type\n\n\n\nDecouple sharding logic from internal classes to SDK\n\nblockers:\n\nneed review of issue for decoupling sharding logic\n\n\n\nfeat: simplify rln-js\nfeat: simplify API of bootstrapping, connection to MetaMask\nchore: investigate interop test failures\nchore: fix go-waku interop tests\n\nachieved:\n\nSimplified rln-js\nStep 1 to improve API\ninterop tests with nwaku\nidentified problems with go-waku\n\n\n\nUser Pays Own RLN Membership\n\nnext:\n\nnew cred registration example (based on prev examples)\ncontinue with improvements\naction if needed to improve testability with go-waku\nsome bugs found in rln\n\n\n\nfeat!: protocols filter peers per shard\nfeat: SDK for redundant usage of filter/lightpush\n\nachieved:\n\nmerged: sharded peer management\nmerged: redundant peers for lightpush & filter\n\n\n\nfeat: local storage as a discovery layer\nfeat: SDK for redundant usage of filter/lightpush\n\nnext:\n\nIntroducing Local Storage as a discovery layer, handle renewing of faulty redundant peers (TODO 3) on feat: SDK for redundant usage of filter/lightpush\n\n\n\ngo-waku §\nbug: filter delay errors\n\n\nachieved:\n\ninvestigated and identified the root-cause of bug: filter delay errors and provided a solution\nstarted documenting tips/approach to help message loss debug issues for status QA both from status-go and waku perspective Debugging\n\n\n\nnext:\n\ninvestigate and identify root-cause of message loss while using relay ⁠Unable to Receive msgs while us…\nfinish documenting message loss debugging\n\n\n\nbug: filter delay errors\nContact requests are not received without restart\n\n\nachieved:\n\ninvestigation with Jakub and Igor to find out the reason why store request were taking a long time to be retrievedsage reliability issues were present on CI for filter.\ninvestigate and fix Contact requests are not received without restart (some commits were missing in desktop master branch.\nStatus x Waku war room at Doha\n\n\n\nnext:\n\nfix issues reported in ⁠status\n\n\n\neco-dev §\n[BOUNTY] Build dApp of Your Choice Using Waku (Decentralized Communication) and Vue.js\n\nachieved:\n\nthorough review and feedback\n\n\nnext:\n\nfinal review and approval\n\n\n\nadd content topic buckets consideration\n\nachieved:\n\nmerged add content topic buckets consideration on content topic consideration, playing around with Noise encryption\n\n\n\n[Epic] Encryption documentation\n\n\nnext:\n\ncreating an initial draft for Noise docs, go-waku docs migration\n\n\n\nachieved :\n\ncompleted and recorded videos with 2 teams for builder spotlight, positioning call is completed, revised the cheatsheet based on ethindia feedback\n\n\n\nnext :\n\nget the videos reviewed\n\n\n"},"waku/updates/2024-01-29":{"title":"2024-01-29 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Update §\n\n2024 Milestones have been defined, to be structured and prioritized this week, subject to change pending approval from stakeholders.\nRemaining open TWN Gen 0 Milestone items to be priorirized in 2024 Milestones and Epics.\n\nWaku Network Gen 0 §\nOpen Epics\n\nAutosharding for autoscaling | js-waku | critical | 75%\nNode bandwidth management mechanism | nwaku | not critical | 0%\nSharded peer management and discovery | js-waku | critical | 87%\nLaunch and dogfood integrated public Waku Network MVP | nwaku | critical | 0%\nProduction testing of existing protocols | js-waku & nwaku | critical | 40%\nSharded capability discovery for light protocols | js-waku & go-waku | critical | 0%\nBasic DoS protection in production | go-waku & research | critical | 28%\nBasic front end for node operator | js-waku & nwaku | critical | 83%\n\nBlocked : Add implementation of PRESTO middleware.\n\n\n\nJanuary 29 Update §\nWaku’s development is divided among 6 teams: research, nwaku, go-waku, js-waku, chat-sdk, and ecosystem-development.\nResearch §\nrln-proof-witness\nCreate RLN proof without having the whole tree\n\nachieved:\n\nCreate proof of concept where light clients can generate their own rln proofs without having to sync the whole tree.\nDog food above PoC and get feedback\nStart with rln in gossipsub paper\n\n\n\nWaku Research - Post Gen 0 Milestones and Epics\n\nachieved: created outline doc for new Specs/RFC process: https://www.notion.so/Waku-Specs-Process-Improvements-3bca80fe10804aeaa7a184143bdca07d, first designs for new Store protocol, refined effort estimates\nnext: implement new Specs process, create milestone/epic related issues, work on draft Store protocol improvement\n\nTWN Connectivity\n\nachieved: read Meridian paper and wrote how it could be used in TWN, reading on Discv5 topic advert design problems\nnext: discuss with VAC topic experts?\n\nnwaku §\nfeat: Enforce service specific rate limits\n\nachieved: implemented a simple lightpush and store request rate limit with configurable defaults\nnext: prior PR need to finish some more tests\n\nbug: access-control-allow-origin should be set to localhost\n\nblocked: Eugen done a presto PR utilizing new chronos middleware design, added comments due we need some change on it prior able to use it.\n\nfeat: sharded peer management Round 2\n\nachieved: added sharded peer management config flag, feedback\nnext: review & merge\n\nchore: improved error handling when config uses cluster-id and pubsub topics\n\nachieved: improved error handling for cluster and shard config\nnext: review & merge\n\nbug: restart loop of current master\n\nachieved: got feedback for the PR, implemented fix and merged\n\nbug: RLN validator is only added for statically configured pubsub topics\n\nachieved: analyzed issue, implemented a solution, tested and raised PR\nnext: get feedback on the PR, implement it and merge\n\nfeat: REST API - large messages does not seem to be rejected by relay auto api\n\nachieved: investigated how to approach the issue using generalized validators, implemented a solution, tested and raised PR\nnext: get feedback on the PR, implement it and merge\n\ngo-waku §\n\n\nachieved:\n\ndocument tips and how to debug message loss for status team Debugging\nfix updating lastProcessedBlock even if no RLN membership event is present fix: update lastProcessedBlock even if no RLN membership event is present\nfix issue in connectionStatus reporting fix: minor issues in connectionstatus report\ninclude a basic lightClient example chore: example update\nimprove logging chore: set log level for all loggers based on logger passed , https://github.com/waku-org/nwaku/pull/2366\nsupport for multiple peer selection for filter feat: support multiple peer selection for filter client\n\n\n\nnext:\n\ninvestigate message loss in status-mobile ci\ninvestigate if gossipsub scoring can be monitored and reported to app as unhealthy https://github.com/waku-org/go-waku/issues/1017\ndogfooding status desktop and mobile and investigate and support status team for any other message reliability issues\n\n\n\nachieved:\n\nfix: add support to aarch64-linux-android in go-zerokit-rln-arm: fix: add support to aarch64-linux-android\nfix: handle community shard unassignment: fix: handle community shard unassignment and update\n\n\n\nnext:\n\nwork on status/waku integration items\n\n\n\njs-waku §\n\n\nachieved:\n\nsimplified rln-js example;\nreleased part of improvements for User Pays Own RLN Membership\ndone with investigating test\n\n\n\nnext:\n\nnew cred registration example (based on prev examples)\nfinish improvements for rln\nbugs found in rln\nimprove tests (issue tbd)\n\n\n\nachieved:\n\ndecouple sharding params out of core classes Decouple sharding logic from internal classes to SDK\n\n\n\nnext:\n\nallow creating subscriptions with just content topics allow user to pass content topic to createSubscription\n\n\n\nachieved:\n\nlightpush & filter use multiple peers instead of one feat: lightpush & filter send requests to multiple peers\nlocal storage as a discovery layer (in progress)\nfixing interop tests (in progress) fix(tests): append p2p with the multiaddrs from ENR, chore(tests): update max content topics on lightpush from 30 to 100\n\n\n\nnext:\n\nmerge local storage discovery (https://github.com/waku-org/js-waku/pull/1811),\nmoving message-hash into core (https://github.com/waku-org/js-waku/pull/1810),\n\n\n\nEcosystem-development §\nCommunity/Partners §\n\nachieved: Waku Community Space https://twitter.com/Waku_org/status/1750927368644919722\nnext: Logos x HOPR space, 30 days of web3 presentation\n[BOUNTY] Build dApp of Your Choice Using Waku (Decentralized Communication) and Vue.js\nachieved: final reviews, approved\n\nPost by community member bounty hunter: https://x.com/wolz_codelife/status/1751955673603002459?s=20\nwaku-org/bounties\n\n\nachieved: collected and reviewed a few options for Bounty platforms\nnext: create dummy bounties to see how things work\n\nDocs §\nIntegrate benchmark and research into website\n\nachieved: review of linked PR https://github.com/waku-org/docs.waku.org/pull/157\nnext: follow up on integrating spell check into the research and nwaku repos\n[Epic] Encryption documentation\nnext: (still ongoing) initial noise encryption docs\nCreate a FAQ and troubleshooting guide\nnext: starting the technical FAQ drafting\n\nDevRel §\n\nachieved:\n\nbuilder spotlight video with MrFox team\n2 tutorial videos reviewed by comms\nmonthly community twitter space: https://twitter.com/Waku_org/status/1750927368644919722\n\n\nnext:\n\ncomplete all the tutorial videos\nworkshop presentations for ethlatam\nmore builder spotlight videos\ncalls with node operators\n\n\n\nStatus Integration §\nchat-sdk §\n\nachieved: started the conversation with Hanno on permission-less communities\nnext: agree on an approach on permission-less communities.\nachieved: research and draft hash based message query to store node spec\nnext: discuss on the iteration of hash based message query\n"},"waku/updates/2024-02-05":{"title":"2024-02-05 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Update §\n\n2024 Milestone work breakdowns underway. Target date estimates, Epics and sub-tasks to be created following scope sign off.\n\nResearch §\n\nachieved:\n\nscript to benchmark rln\nstarted rln+gossipsub paper, some plots\ntidying TWN Connectivity Research issue\nWaku Sync overview first draft\nstarted implementation of incentivization RFC\nstarting on protobuf codec for eligibility proofs\nfirst draft for new Store protocol that is simpler, more feature-rich and store-sync ready\n\n\nnext:\n\nContinue onchain merkle proofs PoC + paper\nWaku Sync overview finalization and Sync protocol first draft\naddress review comments, refine design of new Store protocol\n\n\nblocked:\n\nMerkle proofs from onchain blocked by this suspected bug in zk-kit\n\n\n\nnwaku §\n\nachieved:\n\nREST endpoint can serve its own messages as well as act as store-client\nadd simple dictionary with known words so that cSpell doesn’t complain\nworked on how to make the tests not to core dump\nstart creating basic py-waku structure that allows to create a py-waku module that can be imported in Python projects.\nstart using nph formatter extension\nPR is under review - covers LightPush and Store request rate limiting\n“bug fix” in README.md\nAdd new panel to show num msgs per shard\napplied all the feedback from the reviews. Changed the validation logic in our codebase so that the same validator runs for all pubsub topics. Applied fixes for autosharding endpoint. Merged PRs, closed issue.\nfixed decoding error when trying to send a message with the new meta field\nadded debug logs in nim-websock dependency and reproduced the issue with them for further investigation\nhelped debug and find root cause of a long-standing failed test for dynamically added pubsub topics\nmerged better error handling when cluster id and shards are used\nmerged sharded peer manager experiment\nmerged vendor bump for version 0.25.0\n\n\nnext:\n\nfinalize demo implementation (demo in terms uses Presto un-released feature) on refactor Waku RestService to utilize middleware approach and solve CORS headers issue.\nprepare Release 0.25.0 release and test it.\nwrap up the py-waku repository and make it clear that it is a PoC and is not going to be continued in short-term.\nwait until the 0.4 version of the nph extension is released and then we perform the actual migration.\nadd metrics and dashboard, update configuration doc\ndebug failed tests\n\n\n\njs-waku §\n\nDecouple sharding logic from internal classes to SDK\nachieved:\n\nSDK functions for creating a subscription to a content topic using a callback or returning a stream\n\n\nnext:\n\nfunction like above but starts a node with default settings as well\n\n\nblocker:\n\nremove requirement to pass a peer ID to above function\n\n\n\ngo-waku §\n\nachieved :\n\nSupport getting peers by shard via PeerExchange\nIdentified some improvements/changes to be done in go-waku based on status use-case to status-go feat: notify app when peer scores for all connected relay peers goes below thresholds & feat: Report shard/pubsubTopic specific connection health/status\nAdded rate limiter option to lightpush\nAdded support for multiple public keys per topic (likely to not get merged due to issues found)\n\n\nnext:\n\nImplement\n\n\n\nChatSDK §\n\nachieved:\n\nClarify the data flow for a community creation when external operator is paid to provide resources\n\n\nnext:\n\ncontinue store rfc reviews, continue analysis of filter unsubscribe issue\ncontinue permissionless communities setup\n\n\n\nEcoDev §\nDocs §\n\nachieved:\n\nspell check has been integrated into the research and nwaku repos\n\n\nnext:\n\nre-review the linked PR and close it\n\n\nblocker:\n\nI’ve been unable to get the noise-js example to pair with another peer\n\n\n\nEcosystem Development §\n\nachieved:\n\nRecorded 2 builder spotlight videos\nAdded faqs\nStarted drafting the optimism grant proposal\nLogos x HOPR space, Web3Privacy, 30 days of web3\n\n\nnext:\n\nTidied up metrics dashboard and host it with help from vaclav/infra\nCreate rln/node setup cheatsheet\nPrepare for ethdenver\nKick off out-of-band node incentivization discussion\n\n\n\nSolutions §\nPrometheus metrics view\n\nachieved:\n\nbasic metrics (num of connectable nodes and avg ping) added to the dashboard\n\n\nnext:\n\nmodify NetworkMonitor to work with The Waku Network\n\n\n\nStatus Integration §\n\nachieved:\n\nInvestigated and found out root-cause for message loss issue identified in status-desktop\nInvestigated and found out root-cause for message loss issue identified in status-mobile CI\nReview status-go usage of Waku to identify improvements/changes\nfixed missing cluster ID in node config\nadded peer count to logs when sending msg via relay\nfixed history sync regardless of using a data plan or wifi\nfix: full nodes will run filter and lightpush\n\n\nnext:\n\nSupport status integration in case of message loss or Waku related issues\nContinue reviewing status-go code from Waku usage perspective of sharding\nContinue working on bug fixes or issues related to status-go x waku integration\n\n\n"},"waku/updates/2024-02-19":{"title":"2024-02-19 Waku Weekly","links":[],"tags":["waku-updates"],"content":"This update covers the two week span between February 5th -19th.\nresearch §\n\nachieved:\n\nCreated a C wrapper API for negentropy and moved it as a submodule into nwaku https://github.com/waku-org/negentropy/pull/2, https://github.com/waku-org/nwaku/pull/2448\nRerun nwaku latency measurements with latest nwaku release + new plots: https://github.com/waku-org/research/pull/86\nDraft for “practical use of rln in gossipsub” paper ready, peer review ongoing.\nfurther work in PoC incentivization https://github.com/waku-org/nwaku/pull/2419\nonboarding and local ethereum chain tools research\nOpened up the discussions of waku as a sovereign chain: https://github.com/waku-org/research/issues/84\nWaku latency simulations in a real environment: https://github.com/waku-org/research/pull/85\nWork on practical usage of rln in gossipsub paper: https://github.com/waku-org/research/pull/82\nBenchmarked rln in different platforms: https://github.com/waku-org/nwaku/pull/2410\nimplemented the first version of a codec for incentivization PoC: https://github.com/waku-org/nwaku/issues/1961\nresearch post tidying, negentropy C++ bindings first draft, https://github.com/waku-org/research/issues/80 https://github.com/waku-org/nwaku/pull/2403\nrefined new Store protocol design based on community input https://github.com/waku-org/research/issues/81\n\n\nnext:\n\nimprove the C API and integrate into nwaku and test the integration\ncontinue modifications in zk-kit library to allow onchain merkle proofs: https://github.com/privacy-scaling-explorations/zk-kit/pull/162\nPoC implementation and research papers - continued\ndeploy local ethereum chain for waku-simulator https://github.com/waku-org/waku-simulator/issues/17\nResume work on onchain proofs, upstream bug fixed\nAnalyze data + report on latency simulations\ngather feedback, continue PoC implementation; plan working on the academic conference submission (Waku poster)\nnegentropy C++ bindings continues\nmore reviewers and comments, gain consensus, start plan for PoC implementation https://github.com/waku-org/research/issues/81\n\n\n\nnwaku §\n\nachieved:\n\nNwaku Sync protocol bindings improvements https://github.com/waku-org/nwaku/issues/2426\nNwaku Store v3 first draft\nfound fixes for keystore generation error and for running nwaku-compose without keystore. Validated fixes, and merged both PRs. Closed issue https://github.com/waku-org/nwaku-compose/issues/32\ndesigned and started refactor https://github.com/waku-org/nwaku/issues/2441\nimplemented fix, opened PR, improved the solution after feedback and merged https://github.com/waku-org/nwaku/issues/2406\nimplemented feedback and merged https://github.com/waku-org/nwaku/issues/2214\napply PoC to handle disk through partitions management https://github.com/waku-org/nwaku/issues/1885\nshare knowledge on waku-nodejs-bindings https://github.com/waku-org/nwaku/issues/2420\naccept base64 payloads; make private key optional by generating a random one if not defined; simplified error handling. https://github.com/waku-org/nwaku/issues/2420\npublish and subscribe to waku messages using nwaku, fixed event callback setup. https://github.com/waku-org/waku-rust-bindings/pull/87\nHelped to define the C-bindings milestone https://github.com/waku-org/pm/issues/121\nsimpler ctx mgmt. Param now receiving void* instead of void** https://github.com/waku-org/nwaku/pull/2398\noverview the partition approach https://github.com/waku-org/nwaku/issues/1885\ndefined part of bindings milestone with emphases in go (for status-go) and rust https://github.com/waku-org/pm/issues/121\nstarted the integration of nwaku with waku-rust-bindings, compiling and doing FFI nwaku succesfully. https://github.com/waku-org/pm/issues/121\nadded support to yamux https://github.com/waku-org/nwaku/issues/2331\nfinished implementation, debugged and fixed failed tests, opened PR https://github.com/waku-org/nwaku/issues/2214\nimplemented solution, opened PR, implemented feedback and merged https://github.com/waku-org/nwaku/issues/2349\ninvestigated, tried to reproduce. Found out that it got unintentionally fixed by a recent PR, closed issue https://github.com/waku-org/nwaku/issues/2371\ngetting introduced to our C-bindings codebase https://github.com/waku-org/pm/issues/121\nPR is under review - covers LightPush and Store request rate limiting next: fix nim-chronos’ TokenBucket wrong replenis. https://github.com/waku-org/nwaku/issues/2032\nRC release done, test has ran, changelog done https://github.com/waku-org/nwaku/issues/2402\n\n\nnext:\n\ncontinue with the refactor https://github.com/waku-org/nwaku/issues/2441\narchive update to fullfill Store v3 requirements https://github.com/waku-org/nwaku/issues/2425\nmanual tests to ensure it works properly https://github.com/waku-org/nwaku/issues/1885\nexpose additional bindings functions and add function to free alloc memory https://github.com/waku-org/waku-rust-bindings/pull/87\nContinue defining C-binding epics https://github.com/waku-org/pm/issues/121\ntry the “partition table” implementation approach plus “partition truncate”. https://github.com/waku-org/nwaku/issues/1885\nexpose existing nwaku’s bindings functions and test rust-bindings. Investigate packaging nwaku for mobile. https://github.com/waku-org/waku-rust-bindings/pull/87\nlast mile of implementation (demo in terms uses Presto un-released feature) on refactor Waku RestService to utilize middleware approach and solve CORS headers issue. https://github.com/waku-org/nwaku/issues/2223\n\n\nblocker:\n\nPostgres doesn’t provide a native mechanism to limit the maximum stored size. If the partition+truncate approach doesn’t work properly, we will dismiss the “size” retention policy and just keep the “capacity” and “time” for Postgres. https://github.com/waku-org/nwaku/issues/1885\n\n\n\njs-waku §\n\nachieved:\n\nimplemented and merged @waku/local-discovery to store healthy connected peers in the local state, and use these peers to connect with when an application restarts https://github.com/waku-org/js-waku/issues/1463\nreplaced all use of nwaku’s deprecated JSON RPC API with REST API https://github.com/waku-org/js-waku/issues/1826\nadded SDK functions for creating a node and subscription given a peer id and content topic https://github.com/waku-org/js-waku/issues/1764\nmade improvements based on feedback and merged decoupling of sharding logic out of core protocol logic https://github.com/waku-org/js-waku/issues/1808\nfinished SDK function for creating a subscription (with or without a node) using a content topic and peer id next: implement fixes/improvements from review https://github.com/waku-org/js-waku/issues/1764\n\n\nnext:\n\ncycling stored peers with new peers (discover new peers with peer-exchange) to increase decentralisation\norient protocol implementations to be strictly based on the RFCs https://github.com/waku-org/pm/issues/114#issuecomment-1934535353\nmove WakuNode class to SDK with above functions as private class functions\n\n\n\ngo-waku §\n\nachieved:\n\nexecuted a version of bindings with updated dependencies in go-waku for a couple of days to confirm memory leak is gone. https://github.com/waku-org/waku-rust-bindings/issues/86\narrive at approach and implement topic connection health reporting based on sharding https://github.com/waku-org/go-waku/issues/1021\ninitial version of client side for storev3 https://github.com/waku-org/go-waku/pull/1028\n\n\nnext:\n\nrelease a new version of rust bindings\n\n\n\nchat-sdk §\n\nachieved:\n\ndraft the comparison doc about build client with REST API\nattempting to merge: https://github.com/status-im/status-go/pull/4532\ncreating test code for the selection of store nodes in communities: https://github.com/status-im/status-go/issues/4357\n\n\n*next:\n\ncontinue work on the sending messages with cli\nplan next permission-less community tasks\n\n\n\neco-dev §\n\nachieved:\n\nevents page\npresentation for ETHLATAM\nworking on metrics dashboard https://github.com/waku-org/metrics.waku.org/issues/14\ndeployed the research section of the docs https://github.com/waku-org/docs.waku.org/issues/155\nadded the new filter configurations per nwaku 0.25.0 release https://github.com/waku-org/docs.waku.org/pull/158\nSecret Network space\nminor tweak to nwaku metrics https://github.com/waku-org/nwaku/pull/2430\nupdated instructions, added ENV file configuration, recommended docker as the default way to run nodes https://github.com/waku-org/docs.waku.org/issues/154\nsome repo org for waku metrics and restarted supabase https://github.com/waku-org/metrics.waku.org/issues/6\nworkshop and prize descriptions handed over to ethlatam\ncomposing cheatsheets for RLN membership and how to run a node\nnetworkmonitor now supports RLN and thus can be deployed for The Waku Network https://github.com/waku-org/nwaku/pull/2401\ntested and provided a minor fix for py-waku, create new issues for cbindings based on this https://github.com/waku-org/py-waku/pull/1\n\n\nnext:\n\ncomplete metrics dashboard improvements, start drafting protocols comparison blog and send presentations to comms for review\nfinish up the FAQ section for the docs platform https://github.com/waku-org/docs.waku.org/issues/152\ndeploy the new pages on the docs https://github.com/waku-org/docs.waku.org/pull/166\nreview PR https://github.com/waku-org/research/pull/83 to add cspell to the research repo\nsome ui improvements in the metrics dashboard\ncommunity call agenda for february\nethlatam presentation\nblog post : unbiased comparison of web3 communication protocols\ndeploy new version of NM, add new metrics to internal and public dashboards\n\n\n\nwaku-status-integ §\n\nachieved:\n\ninvestigate contact ack loss issue identified in mobile-CI after filter-manager PR https://github.com/status-im/status-mobile/pull/18769\n\n\nnext:\n\nsupport status integration in case message loss or Waku related issues\n\n\n"},"waku/updates/2024-04-26":{"title":"2024-04-26 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Research Milestones §\nStore Incentivisation\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/17\n\nachieved: discuss incentivization with Akhil\nnext: plan out incentivization PoC (Lightpush instead of Store?)\nblockers: (no longer a blocker) the deadline for the academic paper final version\n\n\n\nRLN in resource-restricted clients\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/18/views/1\n\nachieved: New Merkle tree integration (LazyIMT) integrated https://github.com/alrevuelta/go-waku-light/pull/2 and new version of contract using said tree https://github.com/vacp2p/rln-contract/pull/31 (with Ar. help). PoC ready to get Merkle proofs from the contract using the finally merged https://github.com/privacy-scaling-explorations/zk-kit/pull/162. With this tree, we can assume the increase in gas cost and in exchange we get roots and merkle proofs onchain.\nnext: Continue work in go-waku-light and prepare an end to end PoC to showcase this new feature. Write a report with findings and tradeoffs for future reference.\nblocker: “VacRlnContract” is not compatible with “WakuRlnContract”. This https://github.com/vacp2p/rln-contract/pull/31 should be adapted to work with waku nodes (required for the PoC). Awaiting Vac’s support.\n\n\n\nRLNv2\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/21/views/1\n\nachieved: merged PR to remove go-waku from waku-simulator\nnext: update to RLNv2\nblockers: deployment still not working on wakusim host, but there is an issue for infra to debug and I can continue by using the wakudev host\n\n\n\nStore v3 - Waku Sync\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/20/views/1\n\nStore v3 - message hashes\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/16/views/1\n\nStatus Integration §\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/5/views/2\n\nin-progress:\n\n[nwaku] Add logging of hashes to all nodes\n\n\n\n\n\nEngineering Milestones §\nJSON RPC Deprecation\n\nStatus: Completed\nProject: https://github.com/orgs/waku-org/projects/8/views/1\n\nComposing Waku Protocols to Improve Reliability\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/9/views/1\n\ncompleted:\n\n[js-waku] chore: protocol implementations in @waku/core should be as unopinionated as possible\n\n\nin-progress:\n\n[js-waku] feat: Store reliability\n\n\n\n\n\nOperator Feature Requests\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/13/views/1\n\ncompleted:\n\n[nwaku] chore: detailed json report on /health endpoint\n[nwaku] chore: Extend node isReady with more mature checks and result returned\n\n\n\n\n\nBindings (Rust, NodeJS, Golang)\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/6/views/6\n\nin-progress:\n\n[nwaku] chore: migrate DiscV5 and DNS Discovery from app.nim to waku_node.nim\n\n\nnext:\n\n[nwaku] chore: support setting DiscV5 and DNS-discovery in libwaku\n\n\n\n\n\nNode Bandwidth Management Mechanism\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/11\n\nin-progress:\n\n[js-waku] feat: prefer error code for req-res protocol over exception\n\n\n\n\n\nOther Work §\nBugs §\nIn Progress §\n\n[js-waku] bug: lightPush is not able to keep node connections\n[js-waku] bug: remote peer fault\n[js-waku] bug: filter subscription stops without occasional pings\n[nwaku] bug: wakunode2 systemd unit restarts about 10-15x per day\n[nwaku] bug: SIGSEGV with RLN\n[nwaku] bug: build error on new AMD cpu’s (ubuntu 22.04 LTS)\n[nwaku] bug: Peer Reconnection not working?\n[nwaku] bug: nwaku <> js-waku interop tests failing\n\nNext §\n\n[nwaku] bug/regression: node ca be started on multiple clusters\n[nwaku] bug: autosharding resolves content topics to wrong shard\n[nwaku] bug: Store REST API returns invalid digest\n\nEnhancements §\nIn Progress §\n\n[nwaku] chore: review waku-simulator deployment and improve tracking processes\n[nwaku] feat: add WakuMessage’s meta field to db schema\n[nwaku] chore: Address more attack vectors in rate limiting non-relay protocols\n[js-waku] feat: filter.createSubscription accept ShardParams\n\nNext §\n\n[js-waku] chore: move to js-waku repo\n[js-waku] feat: better developer experience\n\nEcosystem Development §\nBD §\n\nCalls with prospects\nAdvancing ongoing going leads\nQualified prospects\nCreated a validation tracking database\nEvent planning done for the upcopming quarters\n\nSolution Engineering §\n\nWorking on slides for talks in May/June\nTrying to get js-waku working in projects again - so far resulted in filed issues\nupdated nwaku to 0.27.0 in awesome-akash\ncalls with BD\nassisting Portrait with some architectural decisions\nassisting Dria with nwaku REST API\n\nDev Rel §\n\ntoken2049 (20+ leads)\nlibp2p rpgf nomination completed\nsorting out ethdenver leads, sorting out crm\ndrafting Railgun blog article\nforwarding portrait.so interview to comms\ninterview preparation for Railgun <> waku\nEthdam feedback/summary\n\nComms and Events §\n\nX: 1441 new followers ( +11%), 47.8% engagement rate ( +58%), 15889 likes (+47%) - we hit 10k on Twitter - yay!\nLinkedin: 11 new followers\nDiscord: +44 (2.6%)\n1 PR went live, about W3PN and Logos, mentioning Waku - https://cointelegraph.com/press-releases/logos-partners-with-web3privacy-now-to-advance-digital-privacy\nWe’v interviewed Portrait founder at ETHDam - video sent for editing\n\nEvents §\n\nIvan gave a presentation and spoke at the panel at https://web3fc.xyz/\nGuru attended token2049\nETHDam summary doc - https://docs.google.com/document/d/1kgR8q-WMWJ56kGav6MiFYqkA2eDudc_lFUpdYM3sQ8s/edit and photos\n\nDocs §\n\nmerged the general FAQ\ndeprecated the JSON-RPC RFC spec\nWaku RFC website followup\n"},"waku/updates/2024-05-15":{"title":"2024-05-15 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Research Milestones §\nStore Incentivisation\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/17\n\nin-progress:\n\n[nwaku] feat: experimental incentivize store protocol\n\n\n\n\n\nRLN in resource-restricted clients\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/18/views/1\n\nachieved: PR for message validation in lightpush before relaying.\nnext: continue lightpush attaching RLN proofs to messages received from clients.\n\n\n\nRLNv2\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/21/views/1\n\nachieved: Test implementation WIP.\nnext:\n\nContinue planning for next waku fork (RLNv2 + onchain root/proofs) See: https://github.com/waku-org/research/issues/96 (future section). RLN v2 testing. New smart contract with both features. Prepare presentation for DLT conference.\nTest implementation continued and testing.\n\n\n\n\n\nStore v3 - Waku Sync\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/20/views/1\n\nachieved:\n\nExplored if there is a way to prune the negentropy storage based on timestamp.\nTtype state machine implementation and pruning mechanism.\n\n\nnext:\n\nwrite subrange wrappers for negentropy and use subranges to sync.\nusing hashes to fill the archive with the missing messages.\n\n\n\n\n\nStore v3 - message hashes\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/16/views/1\n\nachieved:\n\nbug fixes\n\n\nnext:\n\nfix compatability with Waku sync\n\n\n\n\n\nEngineering Milestones §\nComposing Waku Protocols to Improve Reliability\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/9/views/1\n\ncompleted:\n\n[js-waku] refine Filter\n[js-waku] chore: protocol implementations in @waku/core should be as unopinionated as possible\n[js-waku] feat: SDK for redundant usage of filter/lightpush\n[js-waku] bug: lightPush is not able to keep node connections\n[js-waku] https://github.com/waku-org/js-waku/issues/2002\n\n\nin-progress:\n\n[js-waku] feat: peer management for protocols (with disconnection management)\n\n\nnext:\n\n[js-waku] investigate suspended js-waku in suspended mode\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/11/views/1\n\ncompleted:\n\n[nwaku] chore: Address more attack vectors in rate limiting non-relay protocols\n\n\nin-progress:\n\n[nwaku] feat: Rate limit phase#3 - peer request rate registration and prioritization\n[nwaku] feat: Proper bandwidth metrics per shard\n[nwaku] feat: Enforce service specific rate limits\n\n\nnext:\n\n[nwaku] feat: Failsafe mechanism (guide) for BW limiting\n\n\n\n\n\nBindings\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/6/views/6\n\n[nwaku] chore: support setting DiscV5 and DNS-discovery in libwaku\n\n\n\nOther Work §\nBugs §\nIn Progress §\n\n[js-waku] feat: map/use correct bootstrap nodes fleet according to the configured pubsub topic\n[js-waku] test: create scripts for running light-push/filter and measuring ratio of messages sent and received\n[nwaku] bug: flaky test fails on MacOS\n[nwaku] bug: nwaku <> js-waku interop tests failing\n[nwaku] bug: Peer Reconnection not working?\n[nwaku] bug: build error on new AMD cpu’s (ubuntu 22.04 LTS)\n[nwaku] bug/regression: node ca be started on multiple clusters\n\nNext §\n\n[js-waku] bug: ApplicationInfo to PubsubTopic doesn’t take clusterId into consideration\n[nwaku] bug: Deserialization error on POST /relay/v1/auto/messages with ephemeral field in body\n[nwaku] bug: running testwaku can hang in some cases of UPnP or nat-pmp networking\n[nwaku] bug: Store REST API returns invalid digest\n[nwaku] bug: autosharding resolves content topics to wrong shard\n\nEnhancements §\nIn Progress §\n\n[js-waku] feat: map/use correct bootstrap nodes fleet according to the configured pubsub topic\n[nwaku] feat: light protocol tester application\n\nNext §\n\n[js-waku] feat: improve reuse of pubsub/content topic configuration\n[js-waku] feat: better developer experience\n[nwaku] feat: RLN-proofs as a lightpush service\n[nwaku] Add a flag to require minimum number of peers to publish a message on relay\n\nEcosystem Development §\nBD §\n\nQualified two leads\nAdvanced one lead toward deal\nSet up two meetings with potential partners\n\nDev Rel §\n\nThe Waku Network hit 500 nodes - yay!\nEvents page update\nThe Graph blog article draft\nThe Graph interview\n\nComms and Events §\n\nX: +489\nLinkedin: +7\nDiscord: +44\nWaku intro finalized - https://www.youtube.com/watch?v=nIWx5Vp_Qxk\n2 “how to run nodes” tutorials went live\nPublished Montly newsletter\nRailgun interview went live\nBuilder Spotlight went live\n\nDocs §\n\nImplemented a script on waku.org for automatic creation and updating of the specs section\nSubmitted a pull request to the specs repository to fix broken links and adjust the front matter\nGot the specs repo PR approved and merged Follow up with Hanno on RFC website plans Added high level overview of waku simulation results\n"},"waku/updates/2024-06-24":{"title":"2024-06-24 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[nwaku] PR bug fixes\n[chat] hash based query for outgoing messages https://github.com/status-im/status-go/pull/5217\n\n\nblockers:\n\n[chat] awaiting reviews\n[chat] unable to reproduce CI failures\n\n\n\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[nwaku] waku-simulator testing\n[chat] Dogfooding and fixes for routine that checks for missing messages https://github.com/status-im/status-go/pull/5281\n\n\nblockers:\n\n[chat] awaiting reviews\n[chat] unable to reproduce CI failures\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] Rate limit phase3: implemented per peer request rate checks\n[nwaku] BW metrics per shard: implemented per shard metric collection\n\n\nnext:\n\n[nwaku] Rate limit phase3: Some polishing and test cases needed to finish\n[nwaku] Rate limit phase3: add rate limit metrics to dashboard\n[nwaku] BW metrics per shard: needs some tests and add section onto dashboard\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] enhance partition creation: https://github.com/waku-org/nwaku/issues/2783\n[nwaku] validate that time retention policy works well: https://github.com/waku-org/nwaku/issues/2807\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nEnable testing of direct messages\n\nachieved:\n\n[chat] set up nightly tests & 1:1 messages tests https://github.com/status-im/status-cli-tests/pull/1\n[chat] set up nightly tests for contact requests https://github.com/status-im/status-cli-tests/pull/3\n[chat] CLI bugs and improvements for usage in nightly tests https://github.com/status-im/status-go/issues/5266\n\n\nnext:\n\n[chat] set up nightly tests for group chats and community join requests\n[chat] investigate remaining tests failing\n\n\n\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] Pause peer connector if node is offline https://github.com/status-im/status-go/pull/5340, https://github.com/waku-org/go-waku/pull/1125\n[chat] Fix usage of context for DiscV5 https://github.com/status-im/status-go/pull/5347\n[chat] Fix in status-go to filter peers by shard\n[chat] Dogfood light client with peer exchange enabled\n\n\nnext:\n\n[chat] Investigate / fix DiscV5 not finding valid peers in shards.test fleet\n[chat] make filter working along with peer exchange and debug connectivity issues with peers returned via peerExchange\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[nwaku] lite-protocol-tester works on waku-simulator\n[nwaku] configurable stress conditions\n[nwaku] intensive stress test had been ran (45 nodes (relay + service nodes) + multiple publisher light client and a filter client receiver)\n[nwaku] ran with different conditions\n[nwaku] in co-op with Alberto analyzing topology and message flows\n\n\nnext:\n\n[nwaku] exclude docker limitations from the seen failed message deliveries\n\n\n\n\n\nTelemetry: direct message reliability\n\nachieved:\n\n[nwaku] implemented two different ways to log received message information. One based on libp2p observers https://github.com/waku-org/nwaku/pull/2800 which we won’t use in practice. And one by adding the logs in a new nim-libp2p branch https://github.com/vacp2p/nim-libp2p/pull/1128\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] started to look at the current status-go implementation\n\n\nnext:\n\n[nwaku] carry on with the implementation in nwaku - https://github.com/waku-org/nwaku/issues/2819\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[chat] Improve filter subscription management in LightClient: various fixes wrt filter subscriptions and making lightNode work with peerExchange enabled https://github.com/status-im/status-go/pull/4665\n[chat] dogfooding light client in desktop\n[chat] fixed issue found while dogfooing, remove stale subs and update ping interval https://github.com/waku-org/go-waku/pull/1119\n[js-waku] improved peer management for light push protocol https://github.com/waku-org/js-waku/issues/2002\n[js-waku] worked on updating js-waku to store v3 https://github.com/waku-org/js-waku/issues/2029\n[js-waku] improving offline recoverability for Filter https://github.com/waku-org/js-waku/issues/2024\n\n\nnext:\n\n[js-waku] continue with moving to store v3 https://github.com/waku-org/js-waku/issues/2029\n[js-waku] continue with offline recoverability for Filter https://github.com/waku-org/js-waku/issues/2024\n\n\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\n\n[js-waku] settled on the base implementation of dogfooding app https://github.com/waku-org/lab.waku.org/pull/68\n\n\nnext:\n\n[js-waku] provide front end for dogfooding app\n[js-waku] provide basic telemetry framework\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] draft changes for reset MVDS epoch for online peers https://github.com/status-im/status-go/pull/5349\n\n\nnext:\n\n[chat] continue MVDS review https://github.com/orgs/waku-org/projects/33\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[nwaku] continued gathering wide input on e2e reliability proposal: https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/\n[nwaku] performed basic calculations to understand mathematical properties of proposed protocol, probabilistic model\n\n\nnext:\n\n[nwaku] stakeholders sync on next steps\n[nwaku] set scope for POC implementation\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] start testing and investigating discv5 performance and possible issues https://github.com/waku-org/nwaku/issues/2810\n[nwaku] started deep review of peer manager logic opened PR with small fix to be able to update peers’ ENRs https://github.com/waku-org/nwaku/pull/2818\n[nwaku] reproduced with DST team issues forming stable mesh https://github.com/waku-org/nwaku/issues/2780 and analyzed logs. Found that connections aren’t being answered and started investigating a prospective problematic place in the code.\n\n\nnext:\n\n[nwaku] continue with discv5 and peer manager investigations\n[nwaku] continue investigating issuer forming a stable mesh\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\nRLNv2 in nwaku\n\nachieved:\n\n[research] Published The Waku Simulator book: https://waku-org.github.io/waku-simulator/. It explains how to use waku-simulator to test different scenarios.\n[research] completed RLNv2 test plan, waku-simulator updates\n\n\nnext:\n\n[research] Integrate waku spammer: https://github.com/waku-org/nwaku/pull/2821\n[research] Assist with rlnv2 testing.\n[research] execute RLNv2 test plan\n\n\n\n\n\nOther Work §\nResearch §\n\n[Deliverable] Store Incentivisation (first iteration/POC)\n\n[research] achieved: opened a PR for a PoC incentivization testing: https://github.com/waku-org/nwaku/pull/2816\n[research] next: start outlining a minimal specification for RLN-as-a-service\n\n\n\nReliability §\n\nachieved\n\n[chat] Increase store query pagesize https://github.com/status-im/status-go/pull/5341\n[chat] Fix peer counter for statsu-desktop https://github.com/status-im/status-go/pull/5348\n[chat] Change order of rpc text input https://github.com/status-im/status-desktop/pull/15169\n\n\n"},"waku/updates/2024-07-01":{"title":"2024-07-01 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[chat] set lower max delivery attempts for outgoing messages https://github.com/status-im/status-go/pull/5382\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] BW metrics per shard: implemented per shard metric collection - https://github.com/waku-org/nwaku/issues/1945\n[nwaku] Added dashboard panels for relay per shard traffic\n[nwaku] Added dashboard panels for non-relay protocols data traffic\n[nwaku] Added dashboard panels for non-relay protocols request rates\n\n\nnext:\n\n[nwaku] Rate limit phase3: Some polishing and test cases needed to finish\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] analyse a database blocking issue: https://github.com/waku-org/nwaku/issues/2838\n\n\nnext:\n\n[nwaku] fix database blocking issue with solution detailed in https://github.com/waku-org/nwaku/issues/2838\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nEnable testing of direct messages\n\nachieved:\n\n[chat] small logging cli issue\n[chat] testing private group chats https://github.com/status-im/status-cli-tests/pull/4\n\n\n\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] investigating connectivity and discv5 issues\n[chat] fix peerExchange to filter peers by shard https://github.com/status-im/status-go/pull/5350/\n[chat] filter peers used for circuit-relay based on shards https://github.com/waku-org/go-waku/pull/1130\n[chat] Dogfood lightClient by enabling peerExchange\n\n\nnext:\n\n[chat] missing messages verification https://github.com/status-im/status-go/pull/5281\n[chat] store node query after sleep https://github.com/status-im/status-go/pull/5422\n[chat] investigate further peer connectivity issues by dogfooding\n[chat] refactor peer-manager for lightClient\n[chat] remove limit on connections when using relay\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[chat] lite-protocol-tester works on waku-simulator\n[chat] configurable stress conditions\n[chat] re-run some critical test for nicer logs for analysis\n[chat] analysed run results\n[chat] waku dogfooding telemetry https://github.com/status-im/telemetry/pull/20\n\n\nnext:\n\n[chat] new run with analysis on Alberto’s log analysis tool\n[chat] run lite-protocol-tester on shards.staging\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] started the implementation in nwaku - https://github.com/waku-org/nwaku/issues/2819\n\n\nnext:\n\n[chat] spec the reliability protocol for relay\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[js-waku] continued with using pool approach for protocols https://github.com/waku-org/js-waku/pull/2047\n[js-waku] store v3 migration https://github.com/waku-org/js-waku/pull/2036\n\n\nnext:\n\n[js-waku] complete ongoing efforts\n[js-waku] get back to offline state handling https://github.com/waku-org/js-waku/issues/2024\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] Improve MVDS: reset epoch for online users https://github.com/status-im/mvds/pull/5\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] Discovery on e2e reliability and bloom filters. Started working on a POC on a standalone repo.\n\n\nnext:\n\n[research] move to go-waku and continue with the POC\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] analyse discv5 performance and possible issues https://github.com/waku-org/nwaku/issues/2810\n[nwaku] fixed issues forming mesh by DST team https://github.com/waku-org/nwaku/issues/2780 https://github.com/waku-org/nwaku/pull/2824\n[nwaku] Added small enhancements to the peer manager https://github.com/waku-org/nwaku/pull/2823, https://github.com/waku-org/nwaku/pull/2831\n[nwaku] Opened PR adding logs requested by DST for discv5 investigation https://github.com/waku-org/nwaku/issues/2841 https://github.com/waku-org/nwaku/pull/2811\n[nwaku] Opened PR adding peer origin information to the /admin/v1/peers REST endpoint https://github.com/waku-org/nwaku/pull/2848\n\n\nnext:\n\n[nwaku] continue with discv5 and peer manager investigations\n[nwaku] Implement a permanent customizable logging solution for nim-libp2p\n[nwaku] deprecate named sharding\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nRLNv2 in nwaku\n\nachieved:\n\n[research] Various debugging and bug fixing, executing https://github.com/waku-org/pm/issues/168\n\n\nnext:\n\n[research] Deliver 0.30.0 with RLNv2 in nwaku\n\n\n\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\n\n[research] RLNv2 debugging, test plan, waku-simulator updates\n\n\nnext:\n\n[research] RLNv2 release candidate testing\n\n\n\n\n\nProvision RLN for light push clients PoC\n\nachieved:\n\n[research] continued testing of merged feature\n\n\nnext:\n\n[research] deploy service to existing fleets and dogfood with js-waku\n\n\n\n\n\nPay for RLN provision first PoC\n\nachieved:\n\n[research] PR for incentivization PoC (without on-chain interaction yet)\n\n\nnext:\n\n[research] add on-chain interaction to the PoC - txid lookup as proof of payment\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[chat] status-go: expose wakuext_enr\n[chat] use UTC format for geth.log timestamp\n[chat] use IP addresses instead of dns to store multiaddresses\n[chat] waku enr decoder tool https://github.com/waku-org/enr-decoder/\n[js-waku] remove relay dependency https://github.com/waku-org/js-waku/pull/2040\n\n\n\nBugs §\n\nachieved:\n\n[chat] do not write tcp port 0 and remove 100 chars length limit for multiaddresses\n[chat] fix ctx not available when starting telemetry client\n[nwaku] Mount Metadata in wakucanary https://github.com/waku-org/nwaku/issues/2720\n[nwaku] duplicate message forwarding to filter client https://github.com/waku-org/nwaku/issues/2320\n\n\nnext:\n\n[nwaku] peer exchanges return nodes that no longer exist. - https://github.com/waku-org/nwaku/issues/2414\n\n\n"},"waku/updates/2024-07-08":{"title":"2024-07-08 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] take up reported bugfixes after afk; continue with service rollout\n[chat] tuning store hash query to shorten the confirmation time of outgoing messages Reset MVDS epoch after peer is online\n\n\nnext:\n\n[research] start with storev3 benchmarking test plan\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[Epic: nwaku] Node Bandwidth Management Features\n\nBW metrics per shard: implemented per shard metric collection - feat: Proper bandwidth metrics per shard\nAdded dashboard panels for relay per shard traffic\nAdded dashboard panels for non-relay protocols data traffic\nAdded dashboard panels for non-relay protocols request rates\n\n\n[nwaku] feat: Enforce service specific rate limits\n\nFinalizing last phase of the feature:\n\nAdded per peer filtering of high users\nFilter service specific limits for ping and subscribe per peer\n\n\n\n\n\n\nnext:\n\n[nwaku] [Epic: nwaku] Node Bandwidth Management Features\n\nAdd distinction between gross/net inbound traffic of shards.\n\n\n[nwaku] feat: Enforce service specific rate limits\n\nfinish testing, add more unit tests\n\n\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] new issue to create sonda tool, a canary for store services: chore: create sonda tool\n\n\nnext:\n\n[nwaku] start implementation of sonda tool\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] feat: filter peers stored in cache by cluster-id in peer-exchange\n[chat] feat: expose router and mesh peers to obtain list of peers in mesh\n[chat] improve relay peer connectivity and refactor peerManager to support lightMode feat: modify peer-manager to consider relay target peers\n[chat] enable peerExchange in relay for better peer discovery chore: enable pxClient in relay and increase relay peer connections\n[chat] fix peerExchange peer source and enable peerExchange in lightClient fix: enable pxclient and filter peerExchange peers returned\n[chat] query store node when back from sleep: missing communityRequestToJoin message\n[chat] IMO of what to do regarding receive reliability: Receive message reliability for Status desktop\n\n\nnext:\n\n[chat] expose rpc methods to obtain list of peers by topic, and list of peers in mesh\n[chat] lightClient topic health reporting and peer connectivity improvements\n[chat] when back online only request from store node since last time not 24 hours\n[chat] investigate connection management for outgoing messages\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[chat] optimize filter subscriptions by aggregating them feat: optimize filter subs and feat: aggregate filter subscriptions to do bulk subs with peer\n[nwaku] stress test on waku-simulator\n\n\nnext:\n\n[nwaku] add rln support\n[nwaku] run lite-protocol-tester on shards.staging\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[chat] draft reliability for relay protocol spec feat: reliability for relay protocol\n[nwaku] carry on with the implementation in nwaku - feat: enhance reliability thanks to StoreV3\n\n\nnext:\n\n[chat] continue with the reliability protocol\n[nwaku] submit first PR in nwaku - feat: enhance reliability thanks to StoreV3\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[nwaku] Accepted new lightpush protocol definition with detailed fail case support - Enhance light push protocol\n[js-waku] filter uses dynamic peer management feat(filter): peer/subscription renewal with recurring Filter pings\n[js-waku] reliability with renewals due to offline state feat!: improve offline state handling for Filter subscription\n[js-waku] reliability RFC Add “req-res protocol reliability” spec\n\n\nnext:\n\n[nwaku] Implement: feat: Enhance lightpush protocol error handlingwaku-org/nwaku/issues/2722\n[js-waku] reliability RFC Add “req-res protocol reliability” spec\n[js-waku] reliability with renewals due to offline state feat!: improve offline state handling for Filter subscription\n\n\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\n\n[js-waku] minor improvements to feat: add first version of dogfooding app and getting unblocked with latest nwaku release\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] reset MVDS epoch after peer is back online Reset MVDS epoch after peer is online\n\n\nnext:\n\n[chat] continue mvds review\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] started exploring POC in go-waku as an example application\n[research] researched Vac’s de-MLS protocol for possible integration\n\n\nnext:\n\n[research] continue with the POC starting with a minimal working version first\n\n\nblockers:\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] added origin of peers in admin rest endpoint as per request, to debug and further understand discovery performance chore: adding origin to peers admin endpoint\n[nwaku] discussed with nim-libp2p team and tested a version of logging errors on publish to understand how often messages are not sent without returning errors\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nRLNv2 in nwaku\n\nachieved:\n\n[research] RLNv2 config for the Waku Network: chore: add TWN parameters for RLNv2\n[research] bug fix in RLN, vulnerability: fix(rln): nullifierlog vulnerability\n\n\nnext:\n\n[research] assist to deploy 0.30.0 release and integrate it in The Waku Network\n\n\n\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\n\n[research] continuing the execution of RLN in resource-restricted network: [Epic: Dogfooding] Deliver RLN v2 + RLN in resource-restricted to The Waku Network\n[research] simulations using the waku simulator for different purposes\n[research] expanded RLNv2 testing, assisted with simulating and debugging vulnerabilities\n\n\nnext:\n\n[research] assist to deploy 0.30.0 release and integrate it in The Waku Network\n[research] complete execution of RLNv2 test scenarios\n\n\n\n\n\nPay for RLN provision first PoC\n\nachieved:\n\n[research] added chain interaction to incentivization POC\n\n\nnext:\n\n[research] draft a specification for RLN mainnet deployment\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] deployment of release v0.30.1, which adds RLNv2\n[js-waku] prepare for next release\n\n\nnext:\n\n[js-waku] release last reliability improvements\n\n\n\nBugs §\n\nachieved:\n\n[chat] fix: panic due to enr having more than 300 bytes\n[chat] fix: ignore ws from circuit relay addresses, and allow non multiaddresses in multiaddrs ENR key\n[chat] fix failing wakuv2 tests\n[nwaku] bug: build error on new AMD cpu’s\n[nwaku] Various bug fixes:\n\nFrom chat team:\n\nbug: timestamp should be set to 0 if not provided in REST API\nbug: Store REST API returns invalid digest\n\n\nFrom Vac-QA:\n\nbug: Some PeerStore metadata is not filled in\nbug: PeerInfo instance affects listed protocols\nbug: Lightpush’s publish type error\nbug: Relay publish returns Failed to publish: timedout when a peer filter node is disconnected\nbug: Test failure on test_all\nhandle rln_msg_limit issue\n\n\nNim 2.0 readiness:\n\n[nwaku] bug: incorrect import paths pointing outside the repository\n\n\n\n\n\n\nnext:\n\n[nwaku] peer exchange returns nodes that no longer exist\n\n\n"},"waku/updates/2024-07-15":{"title":"2024-07-15 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] improved migration script & migration tests\n\n\nnext:\n\n[research] storev3 benchmark test plan\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] BW metrics per shard: implemented per shard metric collection feat: Proper bandwidth metrics per shard\n[nwaku] Added dashboard panels for relay per shard traffic\n[nwaku] Added dashboard panels for non-relay protocols data traffic\n[nwaku] Added dashboard panels for non-relay protocols request rates\n[nwaku] Finished and under review: feat: DOS protection of non relay protocols - rate limit phase3\n[nwaku] Added per peer filtering of high users\n[nwaku] Load balancing compensation applied to token replenish\n[nwaku] Filter service specific limits for ping and subscribe per peer\n\n\nnext:\n\n[nwaku] Separate add distinction between gross/net inbound traffic of shards.\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] Designed and implemented the first version of the Sonda tool chore: create sonda tool, which is about to open for review.\n[nwaku] Better partition creation approach to avoid database AccessExclusiveLock - fix: postgres_driver - better partition creation without exclusive access\n\n\nnext:\n\n[nwaku] Get Sonda reviewed and implement feedback\n[nwaku] Tackle the following so that the cursor bug is fulfilled chore(archive): archive and drivers refactor\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nEnable testing of direct messages\n\nachieved:\n\n[chat] chore: allow cli to run on a different fleet\n\n\n\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] refactor: ping a subset of connected peers, feat: bump go-waku to introduce new keep alive interval\n[chat] feat: wakuext_relayPeersByTopic\n[chat] fix: missing messages delay should be substracted\n[chat] feat: use mesh peers instead of all peers for determining topic health\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[chat] refactor and merge the spec for relay reliability feat: reliability for relay protocol\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[js-waku] RFC clarifications Add “req-res protocol reliability” spec\n[js-waku] peer cycling complete feat: peer management for protocols (with disconnection management)\n\n\nnext:\n\n[nwaku] Implement: feat: Enhance lightpush protocol error handling\n\n\n\n\n\nUser apps for large scale dogfooding\n\nblockers:\n\n[js-waku] waiting for release of nwaku 0.30.2\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] summarize the message types that are using MVDS\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] raised a draft PR for e2e reliability POC in go-waku with new message structure, lamport timestamp, bloom filter, buffer and sync\n\n\nnext:\n\n[research] ACK handling, request missing messages, resend message\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] investigating connectivity issues. Decreased connectivity loop interval chore: setting connectivity loop interval to 30 seconds\n[nwaku] final checks and deprecating named sharding chore: deprecating named sharding\n\n\nnext:\n\n[nwaku] Refactor code now that named sharding is removed, and deprecate pubsub-topic configuration\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nRLNv2 in nwaku\n\nachieved:\n\n[research] Completed milestone shipping RLNv2 and stateless light clients: [Epic: Dogfooding] Deliver RLN v2 + RLN in resource-restricted to The Waku Network\n\n\n\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\n\n[research] Blog post announcing the new feature: Post RLN-V2 + Stateless Light Clients\n[research] completed RLNv2 e2e testing\n\n\nnext:\n\n[research] Some work with go-waku-light to showcase stateless light clients in The Waku Network\n[research] Conference presenting Waku poster\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] bumped vendor dependencies for v0.31.0. Start using Nim 2.0.8 - chore: Bump dependencies for v0.31.0\n[chat] refactor: remove namedsharding usage in status-go refactor: only use shards\n[chat] fix : filter uninstall and reinstall issue in status-go fix: don’t resubscribe filters unless there is a change in shard for community\n\n\n\nBugs §\n\nachieved:\n\n[nwaku] bug: peer exchange returns nodes that no longer exist\n\n\nnext:\n\n[nwaku] bug: failed to retrieve peer info via peer exchange protocol\n\n\n"},"waku/updates/2024-07-22":{"title":"2024-07-22 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] Proof of concept of store testing with waku-simulator\n\n\nnext:\n\n[research] Storev3 test plan and integrating tools for testing\n\n\nblockers:\n\n[research] Some complexities around merging/testing, currently handled by nwaku team\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] BW metrics per shard: implemented per shard metric collection feat: Proper bandwidth metrics per shard\n[nwaku] Added dashboard panels for relay per shard traffic\n[nwaku] Added dashboard panels for non-relay protocols data traffic\n[nwaku] Added dashboard panels for non-relay protocols request rates\n[nwaku] Released feat: Enforce service specific rate limits\n\nAdded per peer filtering of high users\nLoad balancing compensation applied to token replenish\nFilter service specific limits for ping and subscribe per peer\n\n\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] Improved and merged Sonda - canary service to check liveness of store nodes\n[nwaku] Merged store-v3 cursor fix chore(archive): archive and drivers refactor\n\n\nnext:\n\n[nwaku] PostgreSQL query optimizations chore: query performance in PostgreSQL by avoiding ordering in queries\n[nwaku] PostgreSQL enhance retention policy: bug: retention policy does not work when postgres db is over loaded\n[nwaku] PostgreSQL enhance query performance chore: improve postgres query performance\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] feat: flag to enable/disable missing message verification\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[chat] added support for 2 lightpush peers to be used for better reliability feat: support for lightpush to use more than 1 peer\n[chat] fix metadata protocol from disconnecting light-clients and only use clusterID and accept connections from lightclients fix: for light node do not check for matching shards but only clusterID\n\n\nnext:\n\n[nwaku] Little enhancement for network connectivity, use bootstrap enr’s to connect to any kind of network and detect shardings\n[nwaku] Auto select service peers and use them randomly for testing on both sides.\n[nwaku] run lite-protocol-tester on shards.staging\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] started local sqlite registry implementation feat: enhance reliability thanks to StoreV3\n[chat] config to enable/disable storev3 confirmations for sent messages feat: flag to enable/disable sent message store query confirmations\n\n\nnext:\n\n[nwaku] carry on with implementation feat: enhance reliability thanks to StoreV3\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[js-waku] improved renewal of peers for Filter feat(filter): peer/subscription renewal with recurring Filter pings\n[js-waku] check for missing messages from Filter subscriptions feat: validate messages for individual filter nodes & perform renewals\n[js-waku] peer renewal and keep alive improvements feat: fix peer renewal, change Filter keep alive\n\n\nnext:\n\n[nwaku] Implementing: feat: Enhance lightpush protocol error handling\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] status messages need for e2e reliability collected\n[chat] fix_: delivered message should not send envelope sent signal\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] implemented ACK handling, request missing messages, resend message\n\n\nnext:\n\n[research] comprehensive tests for the poc\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[research] review of discv5 both spec and nim implementation\n[research] compiled audit of discovery status quo and potential future strategies\n[nwaku] Creating versions for DST team to test discv5 and message reliability\n[nwaku] Proposing new solution to log received message info from nim-libp2p. Created custom version for DST team to use chore: creating branch to test Waku’s received messages\n[nwaku] Started investigating and implementing improvements for connection management of bootstrap only nodes bug: Node accepts connections when configured for just discovery\n[nwaku] Improved logging chore: improving logging under debugDiscv5 flag, chore: logging content topic of spam messages\n[nwaku] Investigated at depth discv5’s implementation bug: discv5 not returning enough peers\n\n\nnext:\n\n[research] review other discovery methods and state of implementation in nim\n[research] review metrics collected and add more if needed\n[research] implement identified discv5 improvement strategies\n[nwaku] Get feedback on nim-libp2p’s logging solution\n[nwaku] Refactor code now that named shading is removed, and deprecate pubsub-topic configuration\n[nwaku] Continue discussing and analyzing discv5’s performance and possible improvements\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[chat] chore: rename shards.staging to status.staging\n[chat] chore: rename shards.staging to status.staging\n[chat] chore: bump go-libp2p\n[chat] enable metadata protocol regardless of cluster-ID used\n[js-waku] chore: enforce access modifiers\n[js-waku] chore: bump @waku peer dependencies\n[js-waku] improve network options handling chore: throw if more than one network config is passed\n\n\nnext:\n\n[nwaku] deploy release v0.31.0 Prepare release 0.31.0\n\n\n\nBugs §\n\nachieved:\n\n[chat] investigation of slowness to retrieve messages in storenode message counter\n[nwaku] Build nwaku image for Windows - feature: support Windows 11\n\n\nnext:\n\n[nwaku] Manage stale peers dynamically with better reliability fix: peer-exchange issue\n[nwaku] bug: failed to retrieve peer info via peer exchange protocol\n\n\n"},"waku/updates/2024-07-29":{"title":"2024-07-29 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] completed first draft of storev3 benchmark test plan\n\n\nnext:\n\n[research] implementing test tools, finalising test plan\n\n\nblockers:\n\n[research] not clear on HW setup on which benchmarking should be done\n\n\n\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[research] last online timestamp periodically saved to new sqlite db, store client query for last messages, tests\n\n\nnext:\n\n[research] reviews, hand-off to nwaku team for merging\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] Node Bandwidth Management Features\n[nwaku] Enforce service specific rate limits\n[nwaku] Separate add distinction between gross/net inbound traffic of shards. chore: Distinction between gross/net trafic in bandwidth per shard metric\n\n\nnext:\n\n[nwaku] dogfooding\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] Improved Sonda’s Grafana dashboard chore: show relative metrics instead of absolute in Sonda\n[nwaku] Improved Sonda’s logging chore: including UTC time in Sonda logs\n[nwaku] Analysed that messages_lookup is a good approach chore: improve postgres query performance\n\n\nnext:\n\n[nwaku] Implement messages_lookup to enhance hashes-only queries chore: improve postgres query performance\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] Rate limit message publishing\n[chat] Disconnect all peers if ping to randomly choosen peers fails twice, chore: disconnect on subsequent ping failures\n[chat] improve lightclient connectivity by publishing their shard info in metadata fix: lightclient enr shards and fix: check for lightclient only if req doesn’t contain shards\n[chat] record connection failures for req/resp protocols\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[chat] Lightpush and Filter bandwidth metrics, feat: store filter and lightpush stats\n[nwaku] Little enhancement for network connectivity, use bootstrap enr’s to connect to any kind of network and detect shardings\n[nwaku] Auto-select service peers and use them randomly for testing on both sides.\n[nwaku] Run lite-protocol-tester on shards.staging\n\n\n\n\n\nTelemetry: direct message reliability\n\nachieved:\n\n[chat] Fix concurrent RW on map in telemetry server: fix: concurrent rw on map\n[chat] Improve storednode message counter dashboard: storenode-message-counter\n\n\n\n\n\nReliability Protocol for Relay\n\nnext:\n\n[nwaku] ongoing implementation in nwaku: feat: Enhance lightpush protocol error handling\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[chat] lightclient error handling\n[js-waku] health state of nodes feat: node and protocols health\n[js-waku] improve continuous peer discovery feat(peer-exchange): support continuous peer information updates\n\n\nnext:\n\n[js-waku] complete review for health state of node and continuous peer discovery\n\n\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\n\n[js-waku] dogfooding app is up and running https://lab.waku.org/dogfooding/\n\n\nnext:\n\n[js-waku] need to fix HTTP headers on the serving site, build basic dashboard\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] added comprehensive tests for the e2e reliability POC\n\n\nnext:\n\n[research] fixes arising from tests, some cleanup and prepare for dogfooding\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[research] adding metrics, manual testing\n[nwaku] Creating versions for DST team to test discv5 and message reliability\n[nwaku] improved nim-libp2p PR with custom logging observer chore: creating branch to test Waku’s received messages\n[nwaku] Opened issue and investigated the phenomenon of some nodes getting stuck and missing messages in DST simulations bug: node getting stuck and missing messages\n\n\nnext:\n\n[nwaku] Continue with the implementation of the bootstrap nodes connection limiting\n[nwaku] Refactor code now that named shading is removed, and deprecate pubsub-topic configuration\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] Revised nwaku nodes’ logging and moved added PRs in nwaku and nim-libp2p to downgrade particularly spammy logs chore: reduce loglevel to some too frequent or unnecessary logs\n[nwaku] Added a CI job verifying that new code is properly linted chore: adding lint job to the CI\n[nwaku] Started going over failed interop tests bug: nwaku <> js-waku interop tests failing\n[nwaku] Release candidate v0.31.0 looks nice from Status-QA PoV Prepare release 0.31.0\n[nwaku] Have the interop tests fixed and a working CI\n[nwaku] Little enhancement on tooling, now single file build/test-run available right from make\n[js-waku] better linting for classes chore: enforce access modifiers\n[js-waku] fix peer exchange tests chore(peer-exchange): use an event listener to gauge if the service is mounted\n[js-waku] remove a bit of tech debt chore: remove content_topic specific API\n\n\nnext:\n\n[nwaku] Perform release v0.31.0\n[js-waku] Release\n\n\n\nBugs §\n\nachieved:\n\n[nwaku] bug: RLN_RELAY_MSG_LIMIT handling\n[nwaku] feature: support Windows 11 made little progress on this it’s ongoing.\n[nwaku] bug: peer exchange returns nodes that no longer exist\n\n\nnext:\n\n[nwaku] bug: failed to retrieve peer info via peer exchange protocol\n[nwaku] building test-peer exchange app on top of the network to analyze peer-exchange behaviour again cache refresh rate.\n\n\n"},"waku/updates/2024-08-05":{"title":"2024-08-05 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] implemented basic testing tools for storev3 benchmarking\n\n\nnext:\n\n[research] run some tests against status.prod to get an idea of query times and bottlenecks, expand testing from there\n\n\n\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[research] store resume PR updates\n\n\nnext:\n\n[research] merge store resume PR\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] Simplification of store legacy code to prevent wrong partition creation - chore: Simplification of store legacy code\n[nwaku] Validate the need for bigger database servers because they were swapping too much\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nTelemetry: direct message reliability\n\nachieved:\n\n[chat] report peer id and number of connection failures to telemetry feat(telemetry)_: send connection failure metric, feat: handle metric for peer connection failure\n\n\nnext:\n\n[chat] update dial function in go-waku to propagate dial failures to status-go\n\n\nblockers:\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] Simplify implementation and start using callbacks for API clients feat: enhance reliability thanks to StoreV3\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[js-waku] validating filter messages, and performing renewals feat: validate messages for individual filter nodes & perform renewals\n[js-waku] health metric for node and protocols: feat: node and protocols health\n\n\nnext:\n\n[nwaku] ongoing implementation feat: Enhance lightpush protocol error handling\n[js-waku] message send retries for lightpush: feat(lightpush): add retries to failing peers\n\n\nblockers:\n\n[js-waku] store v3 blocked by nwaku 0.32 release: feat!: store v3\n\n\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\n\n[js-waku] add light push error metric and generic metric to dogfooding app feat: add light push error and generic waku metric, feat: record light push errors in dogfooding\n\n\nnext:\n\n[js-waku] remove metric from queue on duplicate key error dogfooding: remove metric from queue on duplicate key error\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] bump mvds for clearing old states chore_: bump mvds\n\n\nnext:\n\n[chat] move message hash query for outgoing messages to go-waku\n[chat] continue the request to join community test\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] Investigated bug: node getting stuck and missing messages. Created images for DST team to run and analyzed the resulting logs\n[research] added new metric and grafana dashboard focused on discovery, PR adding cluster filtering to Waku peer exchange\n\n\nnext:\n\n[nwaku] Continue investigating the issue, now trying to understand how async futures are handled by the dispatcher\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\nProvision RLN for light push clients PoC\n\nnext:\n\n[research] Investigate how to use Paymasters aka gasless transactions for users, paid by a smart contract. Goal, PoC with go-waku-light\n\n\n\n\n\nMilestone - Scale up number of Communities §\n\nUsage of Rendezvous\n\nnext:\n\n[research] rendez-vous discovery\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] Fixed failing js-waku interop tests and got CI to work again chore: changing default pubsub topic to its static sharding version\n[nwaku] Improving docs chore: updating doc reference to https rpc, switching RPC provider instructions from websocket to https, updating readme\n[nwaku] Bumped dependency for gcc 14 support chore: bumping nim-bearssl\n[nwaku] Deploy v0.31.0 in waku.prod and status.prod\n[chat] refactor: move rate limiter and priority queue from status-go to API package\n[chat] refactor: move missing messages logic from status-go to go-waku, \n[chat] remove unused code from wakuv2 refactor: extract missing messages logic to go-waku\n\n\nnext:\n\n[js-waku] peers used by different protocols to be different from one-another to increase footprint: feat: peer selection for protocols\n[js-waku] filter API to be simple (reliability user story): feat: use decoder as a seed for subscription\n\n\n\nBugs §\n\nachieved:\n\n[nwaku] building testing tools to analyze peer-exchange protocol and its behavior test: peer exchange testing tool\n[js-waku] continuous discovery updates for node information chore(peer-exchange): support updates of previously discovered peer’s addresses\n[chat] fix: missing wakuv2 fields in createAccountRequest toJson func fix: missing wakuv2 fields in createAccountRequest toJson func\n[chat] fix: storenode multiaddresses\n[chat] fix: handle scenario where the node’s ENR has no shard (due to shard update)\n\n\nnext:\n\n[nwaku] bug: failed to retrieve peer info via peer exchange protocol\n[chat] verify missing messages to determine if storenode sync was executed\n\n\n"},"waku/updates/2024-08-12":{"title":"2024-08-12 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[nwaku] PR review WIP to add Waku Sync feat: Nwaku Sync\n[js-waku] feat!: store v3\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] PR almost merged with optimizations in messageHash queries through lookup table chore: Optimize hash queries with lookup table\n[nwaku] submitted PR in infra-status to fine-tune the Postgres settings after having increased the hw specs store-db add more appropriate db settings for current db hw\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[nwaku] Started using liteprotocoltester tool to send lightpush msgs from a node located in Frankfurt and receiving through waku-filter in a node located in Sydney. Both are connected to one node in status.prod fleet.\n[nwaku] liteprotocoltester tool helped to discover duplicated messages problem\n\n\nnext:\n\n[nwaku] carry on with duplicated messages issue\n\n\n\n\n\nTelemetry: direct message reliability\n\nachieved:\n\n[chat] report peer id and number of connection failures to telemetry feat(telemetry)_: send connection failure metric, feat: handle metric for peer connection failure\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] Development of subscription awareness for delivery_monitor module feat: enhance reliability thanks to StoreV3\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[nwaku] ongoing implementation in nwaku feat: Enhance lightpush protocol error handling\n[js-waku] filter API refactor for ease and DX: feat(filter)!: new simpler filter API\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] bump mvds for clearing old states chore_: bump mvds\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] peer retrieval of missing messages, reconnect capability for tests, conflict resolution; and raised a final PR for POC\n\n\nnext:\n\n[research] address review comments, dogfooding\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] Continued investigating bug: node getting stuck and missing messages\n[nwaku] Found “Futures” leak in yamux and confirmed that it doesn’t happen on mplex. Opened an issue in nim-libp2p bug: yamux Futures leak and a PR in nwaku switching back to mplex chore: using mplex instead of yamux\n[nwaku] Got feedback from Nimbus and new potential ways to debug bug: node getting stuck and missing messages\n[nwaku] Completed bug: Node accepts connections when configured for just discovery, optimizing the connection management of discv5-only nodes\n[research] libp2p rendezvous wrapper impl. at the waku layer\n\n\nnext:\n\n[nwaku] Try the recommended debugging techniques\n[research] namespace definition, discovery strategy\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\n\n[research] raw spec PR for RLN contract mainnet deployment: Add WAKU2-RLN-CONTRACT spec for mainnet deployment\n\n\nnext:\n\n[research] continue the discussion around the PR, finalize the initial version of the spec\n\n\n\n\n\nPay for RLN provision first PoC\n\nachieved:\n\n[research] PoC with a paymaster in zksync, written in golang\n\n\nnext:\n\n[research] continue work with paymaster to sponsor tx fees in zksync\n\n\nblockers:\n\n[research] lots of issues deploying rln to zksync\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] upgraded the peer exchange mounting procedure - chore: upgrade peer exchange mounting](https://github.com/waku-org/nwaku/pull/2953)\n[nwaku] Successfully reproduced the PR exchange issue - bug: failed to retrieve peer info via peer exchange protocol\n[nwaku] Made progress on testing tools - test: peer exchange testing tool\n[chat] refactor: move rate limiter and priority queue from status-go to API package refactor: move rate limiter and priority queue from status-go to api package\n[chat] refactor: move missing messages logic from status-go to go-waku, refactor: extract missing messages logic to go-waku\n[chat] refactor: remove unused code from wakuv2\n\n\nnext:\n\n[nwaku] Resolve the PR exchange issue bug: failed to retrieve peer info via peer exchange protocol\n[nwaku] Complete peer exchange testing tools test: peer exchange testing tool\n\n\n\nBugs §\n\nachieved:\n\n[nwaku] fix: missing wakuv2 fields in createAccountRequest toJson func\n[chat] fix: storenode multiaddresses\n[chat] fix: handle scenario where the node’s ENR has no shard (due to shard update)\n\n\n"},"what-is-a-milestone":{"title":"What's in a Milestone","links":[],"tags":[],"content":"Rationale and Reasoning §\nA project’s goals and priorities are described at its top level by a list of Milestones. The list of these milestones should serve as a guidepost to anyone who is interested in what the project is working on, what the deliverables are of that work, and how that work is going.\n\n\n \n If you don't like "Milestone", call it whatever you want as long as it's in line with this description. \n \n \n\nThis document is an outline of how you should think about creating milestones for your project, and what information should be included in them such that the IFT Grant Process can be completed and everyone stays on the same page.\nProjects work to produce things for people, and a milestone describes, plans, and tracks those things. To that end, the deliverables are the key components to reason around what a milestone is for your project. Who are you building for, what are you building for them, and why do they care? A small group of deliverables and the justified impact they have towards their targeted audience should be enough to help someone understand what a project is doing.\nIn effect, a given milestone is a declaration of:\n\nHere’s what we want to happen\nThis is why this needs to happen\nHere’s how we’re going to make that happen\nThis is what we need to do it\nHere’s how you can watch\nThis is how confident we are that we can get it done (in time)\n\nThe scope of a given milestone is such that the total amount of work you plan for the year equates to ~4-5 individual milestones. For a small project, that’s focused and tight. For a large project, that’s cross-functional and broad. It is expected that larger projects have the appropriate project management resources to sub-divide their milestones in to sub-milestones, epics, and issues as appropriate.\nWe ask that the structure of the milestone is somewhat standardized across the IFT, as we have a lot of derivative and automation tasks to perform.\nHere’s a list of the sections that need to be included in each milestone:\n\nMilestone Title §\nA short name of the milestone that succinctly describes its aim and scope.\nEstimated Delivery Date §\nA timeline in which the work is expected to be delivered\nDescription §\nMore detail as to what you’re aiming to accomplish with this milestone and the justification for its inclusion to the project. This is the human readable encapsulation of the milestone. Someone reading it should be able to understand the general scope of the entire thing, with all other sections adding context and detail.\nResources Required §\n\nroles and % application to it\nexternal services consumed (Vac/IFT)\ninfrastructure\n\nThis information here, in combination with the IFT Finance team, should be enough to yield the required budget for the milestone. This allows for private financial information to stay appropriately separated while still allowing us to publish and broadcast the roadmaps (and their progress) to the broader communities.\nDeliverables §\nWhat are the tangible items that are the result of this milestone’s work, and who is the targeted audience for those items?\nIt is important to note that we’ve included the intended audience here. Is this a research PoC to be delivered to the Engineering team? Is this a mainnet launch that we need wide community broadcasting on? Is this an SDK being delivered to another IFT project? The appropriate communication of the deliverable should be considered here.\nTracking Metrics §\nHow we track progress on a given milestone is dependent upon what the goal of the milestone is and deliverables it aims to accomplish. As per Jarrad’s Strategy Document and mantra from previous talks, metrics around User Acquisition and Revenue Generation should be included wherever possibly appropriate. If it isn’t directly aimed at these two, its impact on how it facilitates it should be understood.\nNOTE: The IFT Insights team will closely monitor all of these and provide dashboards to relevant stakeholders such that progress and status can be monitored and acted upon.\nWork Breakdown §\nSince this is the highest level of “work package” that is considered throughout the org, a description of the way this is going to be broken up and managed should be itemized here. This section is a process of showing “this is explicitly how we plan to deliver this milestone.”\nNOTE: It is recommended that the broken down work is structured similarly so it can be understood and tracked, e.g. Milestone -> Epics -> Issues by the IFT Insights team, with each layer more narrowed in scope and explicit in detail. Each project has a significant level of autonomy on how they deliver on the agreed upon milestones and the associated project management and organization that entails it.\nPerceived Risks §\nEach milestone should include a section of what dependencies/assumptions/potential market changes there are that add risk to its completion. What factors come into play that can potentially affect the project delivery date, and how do each of them affect its delivery?"}} \ 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"},"codex/updates/2024-01-22":{"title":"2024-01-22 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Dec 15th - Jan 22th §\n\nThe Codex team is currently wrapping up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\n\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient §\nEpic: Wiring the Proving System §\n\nCompleted:\n\nWire Sampler to SlotBuilder\nExports fromBytes from the library\nConvert from 32 bytes\n\n\nOngoing:\n\nDataset expiry\nUpdate DataSampler to match updated SlotBuilder\nInvestigate: way to run codex tests through valgrind or similar tool\nIntegrate DataSampler in Marketplace callbacks\n\n\n\nEpic: Improve Client Stability §\n\nCompleted:\n\nUpdate to Chronos V4\nAdd exception handling for Chronos V4\nCompiler PR to Chronos V4 bugs\n\n\nOngoing:\n\nCodex CI improvements\nTrack down segfault issue after rebase of Chronos V4 PR\n\n\n\nMarketplace §\nEpic: End-to-end Testing §\n\nCompleted:\n\nAdd working testnet starter\nUpdates to Codex frontend include:\n\nAdd node storage information\nUpload page updates periodically\nChange error messages to appear below input area instead of an alert\n\n\nFinish the Github Workflow to compile, build and setup the circuit with included generated proof for testing\nInitial work on integration of the verifier into smart-contract suite, with passing storage proof tests\nRebase nim-ethers to the latest version, 0.7.1\nRebase create logging proxy had symbol resolution errors, created PR for nim-poseidon2 to resolve and complete rebase\nRebase multinode integration test refactor, had to remove upraises annotations from some callbacks in the tests\nRefactor add MarketError, refactoring ethers error handling, reviewing verifier integration in codex-contracts-eth\nComplete Github Workflow for testing, worked on integration of verifier into smart-contract suit.\nReleased 0.10.13 with improvements, released asynctest 0.5.0,\n\n\nOngoing:\n\nContinue work on Solidity verifier\n\n\n\nInfra §\n\nCompleted:\n\nResolve issues on docs.codex.storage\nAdd documentation about DNS names and convention\nCheck download speed for codex-storage-proofs-circuits\nSwitch from AWS Windows instance to Hetzner\n\n\nOngoing:\n\nDeploy a site to store circuit ceremony files\nDeploy Codex Storage nodes in Testnet cluster\n\n\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\n\nCompleted:\n\nDebug Groth16 implementation, discovered local bug in [constantine], made a CLI interface (+other improvements) for the Groth16 prover\nResearch and solve puzzles for ZK hack IV kickoff\nPlay with binary field used in the new Binius proof system\nCatchup with recent research (https://zkmesh.substack.com/p/zkmesh-dec-2023-recap)\nExplore Nova-Scotia, discussed hash padding\nUpdate Merkle tree proposal document\nExplore Ascon hash as a possible replacement for SHA256\n\n\nOngoing:\n\nPoC Ascon hash implementation in circom (not competitive with other hashes, at least not in circom)\nThink about how to implement SHA256 proofs\nMore learning about lookups and folding\nStart working out the details of an idea about how to do efficient proofs of computations on bits (eg. range checks, classical hash functions)\n\n\n"},"codex/updates/2024-01-29":{"title":"2024-01-29 Codex Weekly","links":[""],"tags":["codex-updates"],"content":"Codex Update Jan 22nd - Jan 29th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\n\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient §\nEpic: Nim Improvements §\n\nCompleted:\n\nFiled Atlas issue to restore handling forked repos\nFiled Atlas issue for handling “vendoring” style setups\n\n\nOngoing:\n\nReview Atlas graph updates and contribute\n\n\n\nEpic: Wiring the Proving System §\n\nCompleted:\nOngoing:\n\nDataset expiry\nUpdate DataSampler to match updated SlotBuilder\nInvestigate: way to run codex tests through valgrind or similar tool\nIntegrate DataSampler in Marketplace callbacks\n\n\n\nEpic: Improve Client Stability §\n\nCompleted:\nOngoing:\n\nContibue rebasing of unmerged Chronos V4 PR and build improvements PR + fixes to initial idea on builds\nContinue work on asynctest branch\nBug-fixing to track down the “file sizes differ” bug\nOther bugs to be fixed\n\n\n\nMarketplace §\nEpic: End-to-end Testing §\n\nCompleted:\n\nFix tests and replcae GPL licensed ZK verifier w/ MIT version that take JSON output from Circom in contract\nAdd formatting check to CI in codex-contracts-eth repo\nRebase Marketplace integration test refactor with erasure coding changes\n\n\n\nOngoing:\n\nPersistent Availabilities\n\nDesign Plan\n\n\nAdd duration to Codex frontend\nAdded a calendar for the expiry of creating ROSC’s\nWork to add ceremony files to Codex\n\nCeremony file distribution\nAdd Ceremony file hash to Marketplace’s Contract configuration\nAdd support to retrieve Ceremony file hash from Contract’s configuration\nAdd support for Ceremony file hash download from S3\n\n\nContinue work on updating nim-ethers to support JSON-RPC breaking changes and pulling out utils/json to its own library\n\n\n\nInfra §\n\nCompleted:\n\nDeploy a site to store circuit ceremony files\nAutomate Codex ceremony files upload to Cloudflare R2 using GitHub Actions\n\n\nOngoing:\n\nCreate Codex Helm chart\nDeploy Codex Storage nodes in Testnet cluster\n\n\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\n\nCompleted:\n\nImplement G2 curves (so most building blocks are now in place in my algebra backend to be able to experiment\nReview work from Hashcloak collaboration for zk backend benchmarking test suite\n\n\nOngoing:\n\nNew proof system design proposal\n\n\n"},"codex/updates/2024-02-05":{"title":"2024-02-05 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Jan 29nd - Feb 5th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient §\nEpic: Nim Improvements §\nCompleted:\n\nFiled issue for adding Atlas / non-Nimble support for packages\nStart working on Atlas command changes\n\nOngoing:\n\nCreate a repo as a place to start implementing some core async-threading tools for Chronos like worker pool & disk io on top of the ThreadSignalPtr primitive\n\nplans to support refc & orc\n\n\n\nEpic: Wiring the Proving System §\nCompleted:\n\nWrapped ark-circom in a C FFI via:\n\nnim-circom-compat and\ncircom-compat-ffi\n\n\n\nOngoing:\n\nIntegration of codex-storage-proofs-circuits with a PR in nim-codex\n\nEpic: Improve Client Stability §\nCompleted:\n\nUpdated profiler branch for debugging\nPorted the profiler to Chronos V4\nWrote separate test runner for two client test to try to figure out the origin of a file size bug which magically disappeared\n\nOngoing:\n\nFinish work to take down draft flag from PR Expiry per dataset\nWrite tests for PR Safe block deletion (with ref count)\nLook into the CI/docker packaging/local build tooling for Waku and Nimbus as part of build improvements PR\nChronos V4 branch\nPinned versions for Chronos and json-rpc\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nRebased multinode integration test refactor which had two failing tests due to the erasure coding changes\nRebased Marketplace integration test suite\nAdded support for Result types using formatIt for logging proxy\nFinished the verifier contract\nDeployed a dummy verifier on local networks for testing\nFinished updates to nim-ethers, all tests passing, including in Nim v2\nFixed an issue in the nim-ethers json-rpc update\n\nDerived Signers could not access the derived getAddress and sendTransaction when their async raises were updated with SignerError\n\n\n\nOngoing:\n\nContinue work on updating nim-ethers to support json-rpc breaking changes\nContinue work on supporting json-rpc breaking changes and pulling out utils/json to its own lib\nIntegrate contract changes into nim-codex\nLook into removing waitFor in integration tests\nReview and clean up nim-ethers changes\n\nTry to figure out a cleaner way to handle exceptions instead of catching all CatchableErrors\n\n\nStart tweaking the nim-json api to normalize both serialize and deserialize pragmas, with modes: OptOut, OptIn, and Strict\nWIP on adding PATCH call for Availabilities\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nFrobenius endomorphism & pairing implementation\nReview the Solidity Groth16 verifier\n\nOngoing:\n\nDAS simulator improvements to cover more diffusion models\nStart DAS sample query mechanism design\nProof recursion ideation\n"},"codex/updates/2024-02-12":{"title":"2024-02-12 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Feb 6th - Feb 12th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nEpic: Nim Improvements §\nCompleted:\n\nAdd Nim-matrix workflow to run on merge queue\nChanges to build improvements proposal so default version for the compiler is now represented as special version repo_version which can be accessed locally and in CI\n\nOngoing:\n\nNim memory profiler\n\nEpic: Wiring the Proving System §\nCompleted:\n\nIntegrated zk verifier into nim-codex\n\nOngoing:\n\nStarted reviewing the Circom circuit\n\nEpic: Improve Client Stability §\nCompleted:\n\nTwo PRs for testing framework (one PR #93, and one PR #94)\n\nOngoing:\n\nRun Continuous-Test outside of the cluster to reproduce ‘file size issue’\n\nEpic: Infra §\nCompleted:\nOngoing:\n\nCreate Codex Helm chart\nDeploy Codex Storage nodes in Testnet cluster #115\nTracking down the timeout issues in Codex\nUpdates to logtools\n\nNow understand what deploy IDs and test runs are (4 min video here);\n\n\nWorked on the block flow tracker\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nFixed decoding issue in nim-ethers\nWorkaround for that same decoding issue\n\nCan’t use the fix from nim-ethers yet, Codex is still on old version of chronos\n\n\nPublished nim-serde\n\nFinalized nim-serde api: now has two main pragmas, serialize and deserialize, that can be applied at the object-level or field-level:\nEach can set key (valid at field-level), ignore (valid at field-level), and mode (valid at object-level)\n\nmode can be one of:\n\nOptOut\nOptIn\nStrict\n\n\n\n\nMany more tests for the nim-serde lib — serialize OptIn, OptOut, Strict and deserialize OptIn, OptOut, Strict\nAdded a comprehensive README to nim-serde\nAdded CI to serde, with branch protection rules on master\nAdded support for deserializing seq[byte]\n\n\nUpdated nim-ethers json-rpc and chronos upgrade PR to use nim-serde instead of the json util. Created the PR https://github.com/codex-storage/nim-ethers/pull/64\n\nOngoing:\n\nWIP on finishing the Availabilities API endpoints tweaks\nTried to integrate nim-serde in nim-codex, but running into symbol clashes with parseJson, so changed parseJson to JsonNode.parse, still needs to be integrated into nim-codex\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\nOngoing:\n\nMore work on the algebra backend (pairings, APIs)\nWork towards an independent Groth16 prover (so that we can debug the Nim one) - an initial version of that seems to work now\n"},"codex/updates/2024-02-19":{"title":"2024-02-19 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Feb 13th - Feb 19th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient §\nEpic: Nim Improvements §\nCompleted:\n\nInitial PR up for Apatheia async-threading\nOngoing:\nStarted implementing an async-threading API\n\nEpic: Wiring the Proving System §\nCompleted:\nOngoing:\n\nCode review of the circom circuit\nProgress on prover integration\nDetermine why different amounts of data were being downloaded for different slot indices (and failing to release reservations due to be larger than the slotSize)\nGetting integration tests PR #662 into shape for merging\n\nIntegration tests were generally not using the right ec params (num nodes, dataset size, tolerance)\nAfter EC params were corrected, some of the tests were not working due to the recent async clock.now update\n\nCreated a revert PR for the async clock.now PR\n\n\n\n\n\nEpic: Improve Client Stability §\nCompleted:\nOngoing:\n\nStarted work on delegating expensive computations to a separate thread\nReviewing changes made to Apatheia\nStarted integrating apaethia into nim-codex\nRebasing two large PRs against latest master:\n\nSafe block deletion (with ref count)\nExpiry per dataset\n\n\n\nTesting §\nCompleted:\nOngoing:\n\nContinue work to track down the timeout issues in Codex\n\nDid a bunch of updates to logtools, which now understand what deploy IDs and test runs are (4 min video here);\n\n\nWorked on the block flow tracker in tandem with the logtools\n\nNot cancelling pending WantHave’s and under the right conditions this makes the peer implode\n\n\nMade some changes and opened PRs for test framework (one normal, and one tiny PR);\nMade changes to the build improvements proposal, so that the default version for the compiler is now represented as special version repo_version which can be accessed locally and in CI\n\nFor now this is hidden in this commit; started treating those PRs as low priority\n\n\nIsolated the Codex issue to a working hypothesis of failed cancel messages\n\nSmaller-scale test validation of above issue\nLearned how to actually slow down traffic on a given port\n\nIn the end that was not the issue, the issue being instead that peers need to create libp2p connections so they pop into each other’s PeerCtxStore\n\n\n\n\nPut together failing test for the cancellation issue\n\nGoes into testblockexc.nim\nNeed to provide a fix\n\n\n\nInfrastructure §\nCompleted:\n\nAdjust workflows for changelog generation #5\nFix Docker entrypoint NAT helper variables #706\n\nOngoing:\n\nCreate Codex Helm chart #58\nDeploy Codex Storage nodes in Testnet cluster #115\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nUpdated nim-ethers pull request to integrate serde\nRebased integration test refactor\nNim-serde changelog workflow in CI\nFinished moving nim-codex json util to serde\n\nOngoing:\n\nSee Epic: Wiring the Proving System\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nFirst working version of the Haskell Groth16 prover\n\nWork towards an independent Groth16 prover (so that we can debug the Nim one) - an initial version of that seems to work now\n\n\nReviewed improvements to the circuit\n\nOngoing:\n\nMore work on the algebra backend (pairings, APIs)\nStarted writing down some musings about aggregation (WIP)\nFound the bug in the Circom zkey usage preventing valid proof verification\n"},"codex/updates/2024-02-26":{"title":"2024-02-26 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Feb 20th - Feb 26th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nCompleted:\nOngoing:\n\nCodex team members heading to attend ETH Denver\n\nEpic: Nim Improvements §\nCompleted:\nOngoing:\nEpic: Wiring the Proving System §\nCompleted:\nOngoing:\nEpic: Improve Client Stability §\nCompleted:\nOngoing:\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nFinished PR for availabilities update endpoints\n\nRan into very weird bug in one of these:\n\nChronos server implementation, Presto or Nim’s HTTPClient\nCould not debug and decided to rather move from HTTP 204 response to 200 one\n\n\nCreated reproduction repo\nLogged the issue in Presto repo\n\n\nDebugged non-working Dist. testing contracts\n\nOngoing:\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nhelped with figuring out the Ethereum elliptic curve conventions\ngave an elliptic curve talk at the local university; slides for the interested\nfound the second bug in the Nim Groth16 prover (in Constantine again)\n\nOngoing:\n\nstarted thinking about the small / dynamic data problem\n"},"codex/updates/2024-03-04":{"title":"2024-03-04 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Feb 27th - Mar 4th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nCompleted:\n\nCodex team members attended ETH Denver\nOngoing:\n\nEpic: Nim Improvements §\nCompleted:\nOngoing:\n\nStarted a PR to fix Atlas after SAT integration\nFinishing basic fixes PR in Atlas\nextracted the profiler into its own library\n\nretained only the instrumentation modifications in our Chronos V4 branch\nafter we merge V4 into Codex (blocked by a bunch of issues), start a discussion with the Chronos folks to try to get the instrumentation part in\n\n\n\nEpic: Wiring the Proving System §\nCompleted:\nOngoing:\n\nCeremony file setup\n\nEpic: Improve Client Stability §\nCompleted:\nOngoing:\n\ntracked a Codex bug during a V4 merge which turned out to be a compiler bug\n\nwith consequences to Chronos\nbug resolution handled by Nim compiler team after being flagged as “showstopper”\n\n\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\n\nAdd IsSyncing to nim-ethers\nAdd sync check to codex startup\nIn-flight flag for outgoing blocks\n\nDiscord role rewards based on on-chain state and events\n\nPartially tested, requires fixed marketplace-dist-test\n\n\n\n\nUpdated and merged: fix for block-retransmit issue\nDebug isSync (nim-ethers update) and update to testnet-starter\n\nOngoing:\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nNim Groth16 prover finally appears to work correctly (though with the current workaround it also became significantly slower)\nMulti-threading support in the Nim Groth16 prover\n\nOngoing:\n\nThinking about using FRI commitment for storage proofs\n\nHash based, includes RS, outsourceable, easy to prove large/r data sets\n\n\nThinking about using KZG as updateable commitment\n\nWith efficient proofs for small/updateable data sets\n\n\nDebugging the multithreading bug in the prover\nchecking out new research\nSpeed up the “binary circuit” proposal by a factor of ~2x\nThinking about a (supposedly fast) dedicated SHA256 proof protocol, and how to implement it\n"},"codex/updates/2024-03-11":{"title":"2024-03-11 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 5th - Mar 11th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nEpic: Multithreading §\nCompleted:\n\nMarked PR as ready - scheduling erasure encoding and decoding on a thread pool\n\nOngoing:\n\nStarted work on scheduling prover computation on a thread pool\n\nEpic: Wiring the Proving System §\nCompleted:\nOngoing:\n\nMarked PR as ready - scheduling erasure encoding and decoding on a thread pool\nStarted work on scheduling prover computation on a thread pool\n\nEpic: Improve Client Stability §\nCompleted\n\nReasoning on why the profiler works the way it does\nClosed bug: fixes double lookups when block does not exist\n\nOngoing:\n\nSome triaging of bugs in the Codex repo, still some way to go\n\nMarketplace §\nEpic: End-to-end Testing §\nCompleted:\nOngoing:\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n\nCompleted:\n\nEthResearch post on sampling techniques (https://ethresear.ch/t/lossydas-lossy-incremental-and-diagonal-sampling-for-data-availability/18963)\nLogos X space with Leo and Danny\nMinor refactor the proof circuit PR\n\nOngoing:\n\nDAS simulator (https://github.com/codex-storage/das-research) paper prep (calls + work)\nShadow based P2P emulator for DAS (https://github.com/cskiraly/dst-gossipsub-test-node/tree/FullDAS)\nLooked into how circom handles custom gates (tldr: it’s easy to abuse for our own purposes, but snarkjs doesn’t implement anything)\nStarted working on prototyping stuff for the new proof system\n"},"codex/updates/2024-03-18":{"title":"2024-03-18 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 12th - Mar 18th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nClient §\nCompleted\n\nMarked PR as ready - scheduling erasure encoding and decoding on a thread pool https://github.com/codex-storage/nim-codex/pull/716\nPut together reasoning on why the profiler works the way it does;\nClosed a bug re: double lookups when block does not exist;\n\nOngoing\n\nStarted a PR to fix Atlas after SAT integration\nFinishing basic fixes PR in Atlas https://github.com/nim-lang/atlas/pull/120\nStarted work on scheduling prover computation on a thread pool\nFixing comments and rebasing large PRs:\nhttps://github.com/codex-storage/nim-codex/pull/631\nhttps://github.com/codex-storage/nim-codex/pull/678\nWork on Frontend\n\nImplemented dropdown list for expiry input\nStarted working on caching node information for displayed information\n\n\nSome triaging of bugs in the Codex repo, still some way to go;\n\nInfrastructure §\nCompleted\n\n✅ Install VictoriaMetrics in Testnet cluster #130\n✅ Adjust number of nodes in Testnet cluster #136\n✅ Redeploy Testnet cluster components #138\n✅ Install ELK in Testnet cluster #135\n\nOngoing\n\n�️ Install Oauth2 proxy in Testnet cluster #141\n�️ Deploy Testnet cluster components #57\n\nMarketplace §\nCompleted\n\nDiscussions about ceremony files retrival\nPR Reviews:\n\nhttps://github.com/codex-storage/codex-storage-proofs-circuits/pull/7\nhttps://github.com/codex-storage/codex-contracts-eth/pull/83\nhttps://github.com/codex-storage/nim-codex/pull/730\n\n\n\nOngoing\n\nWIP on merging https://github.com/codex-storage/nim-codex/pull/692\nWIP on persistant availabilities\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nEthResearch post on sampling techniques (https://ethresear.ch/t/lossydas-lossy-incremental-and-diagonal-sampling-for-data-availability/18963)\nDAS simulator (https://github.com/codex-storage/das-research) paper prep (calls + work)\nShadow based P2P emulator for DAS (https://github.com/cskiraly/dst-gossipsub-test-node/tree/FullDAS)\nLooked into how circom handles custom gates (tldr: it’s easy to abuse for our own purposes, but snarkjs doesn’t implement anything)\nMinor refactor the proof circuit PR\n\nOngoing\n\nStarted working on prototyping for the new proof system\n"},"codex/updates/2024-03-25":{"title":"2024-03-25 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 19th - Mar 25th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nClient §\nCompleted\n\nVarious fixes for prover-verifier integration\n\nhttps://github.com/codex-storage/nim-codex/pull/702\n\n\nSplit prover-verifier integration into several PRs and merged them into master\n\nhttps://github.com/codex-storage/nim-codex/pull/702#issuecomment-1986256598\\\n\n\n\nOngoing\n\nSyncing up with testnet owners to help think through our use cases and whether or not we have gaps in our QA/testing plan;\nPut together a small tutorial on deploying contracts on a local Geth network with some code.\n\nTesting §\nCompleted\n\nFixed proof generation is dist-test environment\nFixed crash in dist-test env related to blockchain inspection\nBring up-to-date continuous tests (enable transient-node and marketplace test scenarios)\nOngoing\nWhy do proofs with EC params 1-0 fail?\nNode response to fill-slot call is unreliable in geth env\nWrap up discord-reward bot\n\nInfrastructure §\nCompleted\n\n✅ Install Oauth2 proxy in Testnet cluster #141\n✅ Deploy Testnet cluster components #57\n✅ Install Vector in Testnet cluster #144\n✅ Configure monitoring in Testnet cluster #147\n✅ Send Codex and Geth Bootstrap nodes logs and metrics to the Testnet cluster #148\n\nOngoing\n\n�️ Configure Grafana dashboards for Testnet resources #154\n�️ Add Release workflow for Codex #749\n\nMarketplace §\nCompleted\n\nnim-ethers\n\nSupport Solidity’s custom errors\n\nhttps://github.com/codex-storage/nim-ethers/pull/69\n\n\nUpdate dependencies\n\nhttps://github.com/codex-storage/nim-ethers/pull/70\n\n\nFix flaky test\n\nhttps://github.com/codex-storage/nim-ethers/pull/71\n\n\nMerged fix for Solidity getters\n\nhttps://github.com/codex-storage/nim-ethers/pull/63\n\n\n\n\ncodex-contracts-eth:\n\nFinished verifier refactor:\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/83\n\n\n\n\ncodex-storage-proofs-circuits:\n\nMerged code review PR:\n\nhttps://github.com/codex-storage/codex-storage-proofs-circuits/pull/5\n\n\n\n\nquestionable:\n\nWorked out a way to handle generic Results in without statements:\n\nhttps://github.com/codex-storage/questionable/pull/59\n\n\n\n\n\nOngoing\n\nSee previous week\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nwrote an initial draft notes about Plonk; github (WIP)\n\nOngoing\n\nworking towards implementing a Plonkish prover with custom accelerator gadgets, so that we can test proof system ideas\nrealized that proof system idea has a botleneck; may still speed up Poseidon hashing, but the new botleneck is much worse for binary circuits like SHA256. To make the latter practical needs new ideas.\n"},"codex/updates/2024-04-01":{"title":"2024-04-01 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 26th - Apr 1st §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q1/Q2 public testnet release. An internal testnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nOngoing and new lines of research and development will soon begin in preparation for the next version of Codex that will be used for the mainnet release.. Here are the updates from different team members and their ongoing work.\nDevelopment is currently broken into three distinct teams:\n\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe different teams have actively moving on various fronts. The following are their team updates to various ongoing Epics.\nClient, Testing and Infrastructure §\nClient §\nCompleted\n\nCreated task for NAT traversal and gathered various info for it https://github.com/codex-storage/nim-codex/issues/753\nFinished work on scheduling erasure coding on a thread pool https://github.com/codex-storage/nim-codex/pull/716\n\nOngoing\n\nWorking on scheduling prover computation on a thread pool, draft PR in progress\nAddressing comments for large PRs\nhttps://github.com/codex-storage/nim-codex/pull/631\nhttps://github.com/codex-storage/nim-codex/pull/678\n\nTesting §\nCompleted\n\nDocumented issue for running Codex integration tests on certain macOS configurations https://github.com/codex-storage/codex-contracts-eth/issues/95\n\nInfrastructure §\nCompleted\n\nNone\n\nOngoing\n\n� Install Fluent Bit to get Testnet Kubernetes events\n� Adjust Vector config\n� Deploy ethereum web wallet for Testnet\n� Run Public RPC node on Testnet\n� Add more Codex Storage nodes\n� Use multi-stage builds for Rewarder #101\n� codex-testnet-starter updates\n�️ Configure Grafana dashboards for Testnet resources #154\n�️ Add Release workflow for Codex #749\n\nNim Tooling §\nCompleted\n\nAdd recursion limit for SAT (packaging) https://github.com/nim-lang/sat/pull/3\nDisable stacktrace on SAT solver to avoid stackoverflows in debug builds https://github.com/nim-lang/sat/pull/5#event-12262613353\nWrote up draft for Nimble Caching RFC https://hackmd.io/@elcritch/rJ4VrExJR\n\nMarketplace §\nCompleted\n\nRevisit design of https://github.com/codex-storage/nim-codex/issues/467\nReview https://github.com/codex-storage/nim-codex/pull/692\nReview https://github.com/codex-storage/nim-codex/pull/678, many reviews and ongoing discussion\nReview https://github.com/codex-storage/nim-codex/pull/730\nChore to remove no longer used compilation flag: https://github.com/codex-storage/nim-codex/pull/741\nTried to understand why an integration was indeterminately failing in CI and locally, thought was very difficult to reproduce\nMerged https://github.com/codex-storage/nim-codex/pull/704, which had the integration test failure. Re-running the failed test in CI was enough to get it to merge, but indicates there is an issue with this test\nRebased and merged MarketError PR: https://github.com/codex-storage/nim-codex/pull/670\nUpdated pausing slot queue design PR: https://github.com/codex-storage/codex-research/pull/188/\nRe-reviewed feat[marketplace]: add slot queue pausing PR #752 in Codex and started review of Expiry per dataset PR #678\nAdded protection branch rule for nim-ethers in Codex\nReviewed PRs #757, #752, #760, #69, and #70 in Codex\nReviewed comments for the Availability Patch PR and Pausing Queue PR in Codex\n\nOngoing\n\nDiscussed with team plans to improve integration tests: what they should cover, parallelism, and whether or not some could be replaced with unit tests. Also discussed some open issues and PR comments.\nContinued work on implementation of slot queue pausing. Most implementation in, need to add tests: https://github.com/codex-storage/nim-codex/tree/feat/marketplace/slot-queue-improvements\nWorked on updating a macro for Optionalize to add the serialize pragma annotation on the type. Tried to get the macro to read existing serialize annotations on the type and fields first but was taking too long, so moved on\nDiscussions about release branches, proof circuit assets, and versioning\nDiscussed Optionalize() macro and serialize pragma\nDiscussed the parallelism of integration tests\nProgress on Persistent Availabilities implementation\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nNone\n\nOngoing\n\nTrying to understand what can be salvaged from my binary circuit idea (by implementing and measuring stuff)\nWorking on the Plonk notes\n"},"codex/updates/2024-04-08":{"title":"2024-04-08 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Apr 2nd - Apr 8th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q2 public testnet release. An internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nThe Codex team is currently attending the week long Logos all hands off-site, attending ZK Summit and having their team specific off-site the following week.\n\nLogos and Codex Off-site Links (2024/04/01 - 2024/04/15) §\nThe following are links containing artifacts from both off-sites:\n\nCodex Athens Presentation\nCodex Athens Presentation Video Recording\nCodex Workshop Presentation\nCodex Athens Off-site Artifacts\n"},"codex/updates/2024-04-15":{"title":"2024-04-15 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Apr 9th - Apr 16th §\n\nThe Codex team continues to make progress with various initiatives to wrap up the demo for the Q2 public testnet release. An internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\nThe Codex team is currently attending the week long Logos all hands off-site, attending ZK Summit and having their team specific off-site the following week.\n\nLogos and Codex Off-site Links (2024/04/01 - 2024/04/15) §\nThe following are links containing artifacts from both off-sites:\n\nCodex Athens Presentation\nCodex Athens Presentation Video Recording\nCodex Workshop Presentation\nCodex Athens Off-site Artifacts\n"},"codex/updates/2024-04-22":{"title":"2024-04-22 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 16th - Mar 22nd §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\n\nmost members OOO\n\nMarketplace §\n\nmost members OOO\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nstarted looking into the Goldilocks field and Plonky2 (unfortunately, there appears to be NO documentation at all…)\nwrote a draft document about our proof research needs\n"},"codex/updates/2024-04-29":{"title":"2024-04-29 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update Mar 22nd - Mar 29th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\n\nMembers OOO\n\nMarketplace §\nCompleted\n\nWork on duration for expiry\nnim-codex PR https://github.com/codex-storage/nim-codex/pull/793\ncontracts PR https://github.com/codex-storage/codex-contracts-eth/pull/99\n\nOngoing\n\nwhitepaper review\nTokenomics discussions\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nNone\n\nOngoing\n\nWhitepaper review (90% done)\nCoordinating Vac cooperation\nTried to look a little bit into set accumulator schemes\n"},"codex/updates/2024-05-06":{"title":"2024-05-06 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update April 30th - May 6th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nNone\n\nOngoing\n\nSplitting two big PRs into a series of smaller ones\n\nExpiry per dataset\nSafe block deletion (with ref count)\n\n\nReviewing various PRs in the client\n\nMarketplace §\nCompleted\n\nTokenomics meeting to discuss existing questions, as well as the new slot reservations proposal\nDiscussion about the slot reservations proposal, in which we came up with a simplified version, opting to allow for emergent behaviors before adding to complexity\nDiscussion about fill reward curve\nDiscussion about the new slot reservations proposal\nReviews :\n\nhttps://github.com/codex-storage/nim-codex/pull/793\nhttps://github.com/codex-storage/codex-contracts-eth/pull/99\n\n\n\nOngoing\n\nWriting out new proposal for slot reservations as well as capturing the original bloem method idea\nTokenomics & Marketplace proposal discussions\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nDiscussion with marketplace team about slot fill reward and address window expansion curves\n\nOngoing\n\nStudying various FFT/NTT algorithms\nLooking at new research\nLooking a bit into the recent “Foreign Arithmetic” (SigmaBus) paper. Unfortunately it seems to be much less useful for us than originally thought.\n"},"codex/updates/2024-05-13":{"title":"2024-05-13 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update May 7th - May 13th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nOrganized new Kanban board to sort through new and existing Epics and Issues associated with ongoing work to test & fix bugs in the core client towards stability - two large items of focus for the coming two months is:\n\nEthCC Workshop Client work\nFirst release of Codex for the testnets\n\n\nFixed upload/addition of blocks but did not fix it in the advertising loop yet\nFinished evaluation of LevelDB vs SQLite\n\nOngoing\n\nSplitting two big PRs into a series of smaller ones\n\nExpiry per dataset\nSafe block deletion (with ref count)\n\n\n\nMarketplace §\nCompleted\n\nNew proposal for slot reservations and capturing the original bloem method idea; developed simplified version of slot reservations opting to allow for emergent behaviors before adding to complexity\nCompleted PR Reviews and merged:\n\nFeat: expiry specified with number of seconds\nFeat: expiry specified as duration\n\nFollow up fix with adding confirmation: https://github.com/codex-storage/nim-codex/pull/802\n\n\n\n\nUpdated Marketplace sections of Codex Whitepaper\n\nOngoing\n\nTokenomics meeting to discuss existing questions as well as the new slot reservations proposal\nDiscussion with Research team about fill reward curve\nApplication Properties for Codex contract\n\nLearning about Properties and how to write them in Certora system\n\n\nNew UI team sync\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nWrote down current thinking about tracking sets of proofs (WIP)\nNotes on Tracking proofs in Codex\n\nOngoing\n\nLearning about different FFT / NNT algorithms\nContinued work on Plonk notes\nCurrent focus is mainly on recursive proofs in the elliptic curve setting\n"},"codex/updates/2024-05-20":{"title":"2024-05-20 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update May 14th - May 20th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nPackaged self-contained LevelDB Nim project so no dependencies on system packages lifted from existing wrapper and then wrapped it in a datastore implementation\n\nPreliminary tests shows increased performance is as expected\n\n\nResolved issue with dependency bump and broken dependency chain and now stuck with serialization issue - bug was related to resolving to wrong deserializer and work on nim-serde and nim-RPC\n\nOngoing\n\nStarted work on LevelDB migration; Discord bot, reward system and chain inspection broken\nResolving failing integration tests re: expiry of the request in storage\nWorking on issue related to inability to see amount of tokens sent in block explorer\nDeploying faucet web app for testnet tokens (ETH & TST)\nWorking on Codex release workflow\nTrying to use DST’s k8s cluster and have not been able to use it yet\nMigrate dist test cluster from Digital Ocean to Hetzner and deploy different mointoring tools (e.g., Victoria Metrics) - parametrics logs replacing elastic search with similar API and CLI scrollingto be added to UI later on\n\nMarketplace §\nCompleted\n\nHelped with some work related to LevelDB integration\nAdded custom errors PR in nim-ethers that required attention\n\nOngoing\n\nWriting documentation around some of the Solidity code ahead of audit\nCoordinating audit with SC team (Vac) and looping in Security; still deciding on 2nd security audit company\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nSync w/ Client team about circom-compat\nStudying bulletproofs with the goal to try to use them in proof recursion, on the “wrong” curve - see writeup here\nUpdated thinking about proof recursion\nWrote a high-level overview explaining all the moving parts of a ZK proofs (different files and steps and their meaning)\n\nOngoing\n\nProposal for tracking proofs (more precisely, the multiset commitments in there) has a scaling problem, and started thinking about an alternative motivated by Plookup\nLooking more into Winograd-type FFT\n"},"codex/updates/2024-05-27":{"title":"2024-05-27 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update May 21th - May 27th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nN/A\n\nOngoing\n\nContinued work on LevelDB migration; failing unit test uncovered bug on race condition in one of the state machines in the Marketplace module and switch to LevelDB reveleaed it and changing timing of DB reproduced it; reproduced it in SQLite by putting a sleep statement and nothing wrong in LevelDB\n\nMarketplace picked this bug up\n\n\nDocker build problems; Rust build failed and Circom devices no longer building - rolled back Codex to previous Docker image and it doesn’t build anymore so not something changed on our end\nWorking on debugging Rust FFI threading\n\nMarketplace §\nCompleted\n\nContract deployment and security writeup\nMore adjustments to the slot queue PR, and merge\nRe-review of ethers custom errors PR\nMerge fix for forcing scope of deserialization\nRelease new version of nim-serde to unblock chronos v4\nBump serde version and merge\nMerged Remove overloaded UInt256.fromJson\nCleanup integration tests review\nAddressed Slot Reservations PR comments with some rewrites\n\nOngoing\n\n“Application Properties” writeup for Certora issues tracked here and ongoing discussion of issues here\nReviewing RFC spec for Marketplace\nBuilding frontend for the EthCC Demo that shows past and real time contract events, and downloads CIDs and displays as images\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nInitial Dynamic data proposal WIP\n\nOngoing\n\nUnderstanding aggregator node hybrid-system dynamics\n"},"codex/updates/2024-06-03":{"title":"2024-06-03 Codex Weekly","links":["(https:/discord.com/channels/895609329053474826/1230457525854539819/1245555994465931294)"],"tags":["codex-updates"],"content":"Codex Update May 28th - June 3rd §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nAdded custom Docker file for release workflow\n\nOngoing\n\nEthCC planning meeting with Marketplace\nContinued bug hunting and fixing towards stability of client\nPlanning around EthCC Codex demo logistics; Dockerized Codex in VMs, cloud VPN, and physical MikroTik router setup\nNaming conventions of testnet deployments\nNAT Traversal issues; AutoNAT issues not working as expected - formal writeup to come describing issues and potential solutions\nChallenges with DHT and peer discovery\nFast-track reviews of ‘rework async iter’, ‘safe block deletion’ and ‘expiry per dataset’ PRs\nExplore scalability issues with LevelDB and large node tests\n\nMarketplace §\nCompleted\n\nMarketplace discussion meeting (release branches/versions, conditional deployments, pointer calculation, contract gas estimates, upgradability legal implications)\n\nAdd freezing functionality for emergency use cases\nCall with Legal for POV of Contract’s security and upgradability\nCall with SC team (Vac) about Legal POV for Contract’s security and upgradability\n\n\nMarketplace team meeting with Legal about contract freezing/upgradability\nReview of Bug/sales race PR\nSales module concurrency issue - reworking fix after feedback\n\nOngoing\n\nMore progress on EthCC Demo frontend\nGas reporting plugin attempt to run against Codex integration tests\nInvestigate deploying unchanged contracts using hardhat-deploy and newer hardhat Ignition (created issue for upgrade)\nFrontend dev application reviews\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nL2 Deployment\n\nOngoing\n\nProxy re-encryption call with ACZ (Vac)\nInterviewing ZK engineer candidates\nEncryption options WIP\nSet commitment proposal with details WIP\n"},"codex/updates/2024-06-10":{"title":"2024-06-10 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update June 4th - June 10th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nSetup similar VPN from home to cloud VPN for router OS similar to MikroTik router and APs; purchased hardware to test - ordered physical SIM adapter for router\n\nOngoing\n\nWorkshop preparation\nOngoing scalability work; intially had to fix the Docker build and got updated build with LevelDB, odd stuff happening in cluster but 4.5GiB exchange for upload/download succeeded\nNAT Planning and roll out\n\nMarketplace §\nCompleted\n\nTBD\n\nOngoing\n\nWorkshop preparation\nCertora setup & integration\n\nWIP in the Certora’s Application Properties work\n\n\nPersistent Availabilities\nSlot Reservations\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nOngoing work on details of the dynamic data proposal (the proof parts)\nHelped Nomos with a small FFT issue\n\nOngoing\n\nLooking at new research\nWorking on Winograd-type NTT\nWorking on proof recursion\nLooking into more FFT/NTT algorithms (ECFFT, prime order FFT, etc; we need non-power-of-two sizes for foreign field arithmetic)\nReliability and Proof Frequency (WIP)\n"},"codex/updates/2024-06-17":{"title":"2024-06-17 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update June 11th - June 17th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nL2 assumptions, planning and deployment options\nNAT Traversal in Codex\n\nOngoing\n\nWorkshop preparations\nDeveloping single binary pipeline for releases\nSome splitting of PRs further into datastore and rework\nNeed this Safe block deletion (with ref count) PR approved\n\nMarketplace §\nCompleted\n\nMerged fix: createReservation lock\nL2 overview and Marketplace support/compatibility check\n\nOngoing\n\nWorkshop preparations\nLooking into more research about contract upgradability and industry practices\nReviews of Marketplace spec\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nFiguring out usable NTT options on the Grumpkin curve; WIP notes\n\nOngoing\n\nPrototyping with intent of a full implementation soon\n"},"codex/updates/2024-06-24":{"title":"2024-06-24 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update June 18th - June 24th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nMerged safe block deletion PR\n\nOngoing\n\nWorkshop preparations\n\nSlides presentation and complete demo run-through\n\n\nManifest initialization bug\nCrash fixing; second release failing because of CPU load - possible prover blocking I/O and need better threading (to use async profiler to resolve this)\nWork on scheduler\nWorking on bug fix for EC issues\n\nProblem with verifiable manifest (was not enabled for Athens demo) & tree roots issue\nCrashes resulting in SIGSEGV error\n\n\n\nMarketplace §\nCompleted\n\nHired full-stack dev to work on Codex App and some Client/Marketplace tasks\n\nOngoing\n\nWorkshop preparations\n\nFrontend session cookies issue - CORS requests problems; sticky sessions are problem for replicated services because reqeusts can be sent to different sessions, problem is how to persist RPC session w/ 3 RPC nodes and if you want to send all requests to same RPC node is problematic\n\n\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nPlausible deniability writeup from ACZ (Vac)\n\nOngoing\n\nDynamic data proposal WIP\n"},"codex/updates/2024-07-01":{"title":"2024-07-01 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update June 25th - July 1st §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nRelease pipeline for Linux setup (x64 & ARM for Ubuntu and MacOS)\n\nOngoing\n\nWorkshop preparations\n\nSlides presentation and complete demo run-through\n\n\nGeneral bug hunting and fixing towards baseline stability and BitTorrent-like performance\n\nMarketplace §\nCompleted\n\nWorkshop preparations\n\nOngoing\n\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nGathered all ZK related documents here\nWriteup on OTP-like encryption to prevent outsourcing attacks\n\nOngoing\n\nOngoing research into the details of folding\nInterviewing more ZK engineer candidates\n\nCreating take-home programming exercise\n\n\nThinking about how to describe Plonkish circuits\nLooking at new ZK research\n"},"codex/updates/2024-07-08":{"title":"2024-07-08 Codex Weekly","links":[],"tags":["codex-updates"],"content":"Codex Update July 2nd - July 8th §\n\nThe Codex team wrapped up a successful demo at the Logos off-site and now aims to prepare the demo for the Q2 public testnet release potentially coinciding with EthCC.\nAn internal devnet has been running for the past few weeks and has been used to test the latest version of Codex and can be accessed using the Codex Testnet Starter documentation.\n\nDevelopment is currently broken into three distinct teams:\n\nClient, Testing, and Infrastructure\nMarketplace\nResearch\n\nThe following are their team updates.\nClient, Testing and Infrastructure §\nCompleted\n\nWorkshop preparations\n\nSlides presentation and complete demo run-through\n\n\nRelease pipeline for Windows (x64 & ARM) setup\n\nOngoing\n\nGeneral bug hunting and fixing towards baseline stability and BitTorrent-like performance\nWriteup of Merkle Trees and Proof Tree\nEC in Codex\n\nMarketplace §\nCompleted\n\nWorkshop preparations\n\nOngoing\n\nWIP in the Certora’s Application Properties work\n\nResearch §\n2024 R&D Goals\n1. Proving system and aggregation improvements (folding or lookups)\n2. Aggregator/validator design\n3. DHT improvements\n4. Tokenomics and incentive design\n5. Bandwidth incentives\n6. Dynamic data (appendable data)\n7. Encryption\n\nCompleted\n\nN/A\n\nOngoing\n\nN/A\n"},"index":{"title":"","links":["terms-of-use","what-is-a-milestone","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.\nEvery year (starting this year), each project defines its plans in a number a milestones, which are then reflected and tracked here-in. You an read more about the contents of a given milestone and the various justifications for that content in What is a Milestone.\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":[],"tags":["nomos","roadmap","overview"],"content":"Nomos Overview §\nThe Nomos project building a blockchain for Network States. To learn more about the project, please visit the website\nNomos is currently in its research phase, and actively building a Testnet."},"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/2023-11-27":{"title":"2023-11-27 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Offsite §\n\nSummary of the offsite (daily): https://docs.google.com/document/d/1qJ_hP2FA7P3kB5TNi-tkFaWGmqlP8tZd9RC1dAlU5kw \nCarnot in a Privacy Setting under Mixnet Assumption: https://docs.google.com/document/d/1fICGvSkTCgvk879uaapzFzy6Qbzz6VkXX0lL_iJ8GJo\nPPoS + Carnot discussion - why Carnot will not be used for the base layer, exploring combinations of different approaches as well as a potential solution for fully private base layer\nMixnet: numerical experiments were conducted - more details here: https://docs.google.com/spreadsheets/d/1MaSBbfUGmJniILPvcQLxtyXqjBExUUEB6C2-YWNP6uI/edit#gid=0 \nData Availability: exploring cryptography, deciding on base layer structure, looking into super commitments, proving schemes.\nConclusions and next steps as a team for the implementation of the Nomos 1.0 Base Layer.\nFilmed presentation: Preliminary Privacy Analysis https://drive.google.com/file/d/1mrNWdJMX_WneUFNmHJn316uLrPXkBbMH/view?usp=sharing \nFilmed presentation: Last day summary PPoS - https://drive.google.com/file/d/1DlDi3bWglIRR3nJ6owjLemQSy9YiRSZY/view?usp=sharing \n\nPrivate PoS Tokenomics §\nResearch §\n\nValidator rewards function - https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4 \nSimulation results: https://github.com/logos-co/token-economics/blob/nomos-linear-reward-function/Nomos/multi_staking_rewards/linear_reward.ipynb**\n"},"nomos/updates/2023-12-04":{"title":"2023-12-04 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nProgress on the Mixnet implementation specification, with particular emphasis on integration on the rest of the system.\nDiscussing and analyzing possible strategies for cover traffic specially tailored to the consensus algorithm.\n\ndevelopment §\ntestnet §\ndevelopment §\n\nMerged Prometheus metrics service\n\nprivate PoS §\nresearch §\n\nWe consider leader election in PoS observed over some period of time by an adversary who wants to learn its stake with high “accuracy” and high “confidence”.\nFor the probability of stake greater than some threshold derived rigorous lower and upper bounds on this probability.\nFor the same probability considered an asymptotic long-time regime and developed a mathematical framework for this regime. \nVerification of above results by simulations is in progress. \nThe above will be a part of the  framework which will be used to get a more accurate estimate of the number of layers which are required to reduce anonymity failures in the mixnet. More details provided here\nAnalyzed how stake splitting affected leader rates in Crypsinous: Stake Splitting in Praos\n\ndata availability §\nresearch §\n\nDesigned a new super-commitment structure and explained it here. After some discussions, we agreed that  prover cannot temper the column entries by adding and subtracting some values but he can reorder the column entries. The proof does not guarantee column ordering. Solution methods for this were discussed, but since the focus was on a different structure design, this development was postponed for now.\nThought of a different design and explained it here. The main idea of the design is to take a commitment of commitments. As a result of the investigations, the structure is thought to be working. Cryptographic proof will be worked on.\nThe newly designed structures were compared with these existing schemes. It is thought that our current design will provide the whole advantages of Avail.\n\ndevelopment §\n\nContinuing DA mock implementation - splitting it into reviewable parts\n1D benchmarking\n\nmiscellaneous §\n\nThe Whitepaper now contains a whole new section on Light Nodes.\nCarnot’s role in Nomos has been updated.\nExplanations about privacy have been expanded and adapted to include the notion of resiliency.\nAdded other sections, like Multiple Base Layers and others related to Light Nodes.\nAdded new diagrams\n"},"nomos/updates/2023-12-11":{"title":"2023-12-11 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nCrypsinous over Mixnet contains the summarization of investigation into how Crypsinous will work in combination with the Mixnet\nIn the development section below, we will go into further into details in terms of how this researched affected the specification.\nThe discussions are still open and the specification is still prone to change.\n\ndevelopment §\n\nUpdated the Mixnet Specification according to the new research and analysis in the Crypsinous over Mixnet document. The gist of the document update is that every node emits real/cover packets with a rate in a Poisson distribution.\n\nA slot leader publishes 3 block proposals and several drop cover packets within a slot (a slot is published every 20s)\nAt that time, all of the other nodes emit only drop cover packets (“decoys”) within a slot.\nThe target mean packet delay is 2s.\nBased on this:\n\nDefined a packet emission mechanism\nRefined a packet delay calculation\nDefined a cover traffic strategy\n\n\n\n\n\ntestnet §\ndevelopment §\n\nNo updates\n\nprivate PoS §\nresearch §\n\nResearching on a potential problem of wealth concentration in the token engineering model that was reported by DarkFi since it contradicts the results we have calculated in the Validation Rewards\nPerformed additional research in terms of feasibility of learning total stake: the problem here is that we cannot compute relative stake based on what is the Crypsinous paper.\n\nTherefore we came up with Dynamic Lottery Function Difficulty adjustment\n\n\nRefined rigorous lower and upper bounds on the probability of stake greater than some threshold, i.e. “confidence”. The details can be seen in Notes on mathematical and statistical aspects of proof of stake consensus mechanisms\n\nThe upper bound was only available for prob. 0.9 and higher and a new version also allows for lower prob.\nThe latter is needed for a more accurate estimation of the number of layers in the mixnet.\nThe asymptotic result for the same probability also can be used only for higher values and extending this result for lower values is currently in progress\n\n\n\ndata availability §\nresearch §\n\nWriting of the new protocol specification complete - it is still open for discussion - comments and proposals with valid reasoning can still adjust the specification - anyone can comment.\nFor the historical records, the trail of thoughts, scenarios and improvements can be seen here.\nThe new specification was also looked at by the Nescience team - it has no cryptographical weaknesses.\nImplementation expected to start at the beginning of January.\nIn the future, we will evaluate additional Data Availability structures (based on internal literature) to see how they compare to what we have.\nthe DA node read/write API implementation is in progress - we have reviewed and reevaluated the initial plan to implement DA data dissemination and retrieval flows and created an action plan based on that.\n\ndevelopment §\n\nWe have performed simulations to confirm there will be no “flatness” issues with Carnot implementation.\nWe are currently in the process of finalizing the Carnot paper - the simulations action plan will also be shown there.\nFound additional proofs that simulations and rust Carnot implementation acts as expected in varying committee overlays - more info on Discord.\n"},"nomos/updates/2023-12-18":{"title":"2023-12-18 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nContinuing the research on the effects of wealth concentration within Ouroboros Crypsinous - more precisely fixing some of the code and running simulations. The results and reports will continue to be provided in the Notion doc.\nAlso, doing additional research into the Darkfi’s Crypsinous implementation (and why they are striving away from it)\nMixnet specification is done, currently in review - once additional comments have been added, will provide new updates\nThere have been some slight improvements in the Crypsinous over Mixnet document - not too major\nCompiled a high-level overview of the Ouroboros family\nStudying byzantine gossip and swarm consensus as part of the effort of solving the tagging attack problem (as alternatives to random subsampling and reliable broadcast) - some of the ideas involve the use of gradecast over byzantine gossip, but providing more details in the following week.\n\ndevelopment §\n\nSolved [an issue](https://github.com/logos-co/nomos-node/pull/544](https://github.com/logos-co/nomos-node/pull/544 ”https://github.com/logos-co/nomos-node/pull/544) that was causing problems with simulations (Carnot 10k nodes - Tree implementation returned different results when searching for child committee and then using child committee to find its parent)\nBy fixing the above and the depth calculation in the analysis script, the simulations stall has been fixed totally, and we are meeting in the deadlines in terms of releasing the Carnot papers - no additional showstoppers\n\ntestnet §\ndevelopment §\n\nNo updates\n\nprivate PoS §\nresearch §\n\nNormalize stake for lottery - we have a proof of convergence to expected fixed point and stability conditions for that fixed point: Analysis Summary\nWe’ve run simulations of the process and they confirm the stability conditions and convergence derived analytically (above)\nThere is still work to be done in terms of slots observation to understand a good measurement of leader rate as well as some additional confirmation of the analysis\nAnalysis of stake de-anonymization (details are [here](https://www.overleaf.com/read/xvgmfchdhgzh#acd15d](https://www.overleaf.com/read/xvgmfchdhgzh#acd15d ”https://www.overleaf.com/read/xvgmfchdhgzh#acd15d) and here): and here)\nUsed the lower bound (LB), asymptotic estimate (AE) and upper bound (UB) on the probability of stake greater than some threshold (“confidence”), within a given “accuracy”, to estimate the number of layers in the mixnet.\nThe UB (on the number of layers) is loose. The AE (for the number of layers) is close to the LB (on the number of layers), suggesting that LB is closer to true values (AE is in very good agreement with simulations). However, AE is only available for “confidence” higher than 0.6 and some “accuracies”\nFor the currently used lottery function, derived the maximum likelihood estimator of relative stake. The latter can be used by an adversary to infer the relative stake of a node\nAnalysis of fraction of compromised paths is currently in progress and more details will be provided in the following weeks\n\ndata availability §\nresearch §\n\nContinuing on the process of comparing different DA structures - the comparison can be found [here](https://www.notion.so/Comparison-of-DA-Structures-WIP-47350a408cbd4d8db545527b7a598ccf](https://www.notion.so/Comparison-of-DA-Structures-WIP-47350a408cbd4d8db545527b7a598ccf ”https://www.notion.so/Comparison-of-DA-Structures-WIP-47350a408cbd4d8db545527b7a598ccf) . Right now we are comparing Merkle Tree, RS+KZG and Merkle Tree+Snarks - based on the literature at the bottom of the aforementioned document.\nThe parameters we are currently comparing are proof size, prover time, verifier time and commitment size, but in terms of theoretical examples, not actual benchmarks.\n\ndevelopment §\n\nThe new read/write DA API is still in progress - there are conversations ongoing which can be seen in the draft PR\n\nmiscellaneous §\n\nThe architecture whitepaper is awaiting feedback and expected to be finalized in the first week of 2024 - the paper can be found on Discord\n"},"nomos/updates/2023-12-25":{"title":"2023-12-25 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nUsed bounds and asymptotic analysis to create a new version of the table (see this for reference) which estimates the number of layers needed in the mixnet protecting the network layer. The latter assumes a very simple lottery function where the probability of winning is equal to the relative stake.\n\ndevelopment §\n\nNo updates\n\ntestnet §\ndevelopment §\n\nWe are experiencing an issue with the file system on metal-01.he-eu-hel1.nomos.misc entering a read-only state. This is preventing any write operations on the system, impacting normal operations and services.\nNomos node stability investigation - found a main reason for tesnet failing after some time, consensus engine has some asserts that are not met during the run. I’m trying to replicate the same behaviour in integration tests.\n\nprivate PoS §\nresearch §\n\nA consensus reference page has been written detailing the path and the history of decisions made as a context to the other documents we have provided. It is important to mention that this is a living document that might be updated further in the future.\nUpdated the ongoing document of DarkFi Crypsinous implementation with new details.\nSummarized the findings and ideas from different papers around byzantine gossip and consensus. There are some ideas that might be useful to us in the future.\nFor the Crypsinous lottery function analyzed the maximum likelihood (ML) statistical inference framework. The latter can be used by an adversary for inference of stakes of nodes to infer relative stake. Formally the ML framework suggests that observations of election statistics of all nodes are required in order to infer relative stake of a single node. However, for long time observations there is a possibility that statistics for a single node are sufficient to infer its relative stake. The analysis of this scenario, which uses a “naive” estimator of relative stake, is currently in progress.\nNormalize stake for leader lottery: Summary with plots and equations can be found here.\nWe have a new analytical tool for analyzing the average of our process for learning stake, it lets us study how the process converges without the slow simulation runs and makes analytical work much simpler.\nWe found that our process for learning D will underestimate true total stake by up to 3% (depends on our choice of constants), we have some analytical bounds on the underestimate and confirmed them with simulation.\n\ndata availability §\nresearch §\n\nFinished the comparison article of DA structures (Merkle Tree, RS+KZG and Merkle Tree+Snarks) and reach the conclusion that the structure we designed is flexible. We can easily switch to the Merkle tree + Plonky2 structure in the future.\nSome additional research notes in terms of DA comparison can be found here.\nSkimming through NOTRY: Deniable messaging with retroactive avowal to check if there is anything interesting to us\n\ndevelopment §\n\nNo updates\n\nmiscellaneous §\n\nArchitecture whitepaper will be reviewed internally by the team in the following weeks.\n"},"nomos/updates/2024-01-08":{"title":"2024-01-08 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nThe Mixnet specification doc has been updated with new details after a discussion was help in terms of establishing connections in advance - Whenever a Mixnet topology is reconstructed, each mix node in the layer l establishes connections optimistically with all mix nodes in the layer L+1 , in order to reduce the latency of individual packet delivery - more details in the relevant comments in the linked Notion doc.\n\ndevelopment §\n\nNo updates\n\ntestnet §\ndevelopment §\n\nIncreased the storage limit in addition setting up firewall rules for the Nomos http ports - they are set in the same range for containers and host - more details here.\nOpened TCP ports 18080-18083 for HTTP - more details here. Also opened some additional ports\nAdded missing configuration and fixed conflicting rules for ports: Limit number of committed blocks in info requests - more info here; Receive blocks blobs in parallel - more info here; Set and get blocks tip without filtering - more info here.\nOptimized consensus related methods, the changes allow node to run without problems on a testnet: CI - more work in progress (in terms of DA specification)\n\nprivate PoS §\nresearch §\n\nAfter trying 6 attempts, we had a breakthrough in understanding variance of our learning process around the fixed point: this latest method shows very good agreement with simulation across the full parameter space that we tested - This sets up to answer some of the burning questions we have had for a while (How big should T be, how small should delta be, how fast does this converge).\nWe came up with a good measure of “centrality of stake”, this has allowed us to do much more informative simulations across the parameters that matter: More detailed update with plots in Notion: 2024-01-08 Progress\nAnalysis of total stake inference problem: the analytical framework, derived for the algorithm which uses Crypsinous lottery function stochastic process to estimate the total stake, was used to construct the simplest possible theory which describes expectation and variance of the total stake statistical estimator.\nSeveral approaches were tried, including mapping to the physical thermal relaxation process, but explained simulations but only for a limited scope of parameters.\nThe latest approach, which uses large stake expansion, leads to simple theory with a small number of parameters which explains simulations quite well. More details here.\nLarge numbers of validators issue has been documented - something that Carnot doesn’t solve implicitly - more details here.\n\ndata availability §\nresearch §\n\nWe have made a new design - the 2D Data Availability Structure based on a problem whether the execution zones perform the RS-encoding process correctly; it has been solved accordingly but it is costly due to the size of the data - more studies to come.\nThe protocols we have examined and also designed so far were compared on relevant data. Detailed information can be viewed here. Additionally, the total data size can be accessed by entering the data size and number of nodes here\n\ndevelopment §\n\nNo updates\n\nmiscellaneous §\n\nArchitecture whitepaper is being reviewedg.\nShared sequencing - compiled notes on some of the implications, architectural designs, discussions, inspirations and more, in an article here.\nNotes on the MTR Declaration of Decentralization provided [here](https://www.notion.so/Filip-8b260c1bfddd43cc9cd1211478be53e8 here- It is in an interesting proof of value approach (mix of PoS on main chain with a sidechain Relay/CER for the PoW, merged every sidechain’s 30 blocks), that they are utilizing, but I think that it has too many holes to fulfill - risks and attack vectors. Even though the ecosystem has been live for a couple of years, it never reached the heights they apparently planned. They focused too much on becoming “big” rather than building up from ground zero. However, the interesting design choice is their utilization of sidechains (more precisely their adaptors and connectors) in the attempt to connect to other ecosystems. The paper didn’t provide too many details about it though.\n"},"nomos/updates/2024-01-15":{"title":"2024-01-15 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nNo updates.\n\ndevelopment §\n\nRefined Mixnet specs: Decided to use libp2p even for direct QUIC connections for v1, so that we can use peer discovery and NAT traversal later on; Defined an initial approach to report on unresponsive mix nodes, though it should be improved later; Simplified the specification of using Sphinx packets, by abstracting the internal Sphinx spec ;Updated the calculation of lambda and mu by suggesting a refined approach of emission rates; Decided to start with only mixnode-defined delays.\nThree quarters of mixnet python specification code has been done; since it has been decided to move Sphinx out of the mixnet specs(see comments) - it will be moved to a new repo in order to be utilized properly; the basic structure and topology construction and Sphinx packet builder have also been added.\nResearch of QUIC and QUIC connections - what is available and what is the difference from the TCP connections\n\ntestnet §\ndevelopment §\n\nInitial node metrics PR has been merged - to reiterate, this will add metrics service + initial metrics for CL and DA mempools. We will continue the effort to collect data about other services in the coming weeks.\n\ncryptarchia §\nresearch §\n\nThe Private Proof of Stake milestone has been renamed to Cryptarchia in order to better reflect current work.\nUpdated the living document that showcases if the leader election function leads to wealth concentration - more precisely the stochastic fork choice rule - which seems to ignore the validator stake.\n[Analysis](https://www.overleaf.com/read/fzbrxvkwwscq#f2907c](https://www.overleaf.com/read/fzbrxvkwwscq#f2907c) of total stake inference problem: For the statistical estimator of the total stake D, the results of a large stake expansion were used to derive Gaussian approximation for the distribution of D. The latter was used to define “confidence” and “accuracy”. The large stake expansion was used to study other important properties, such as convergence rate of inference algorithm, and provides a relatively simple and compact set of relations between different parameters, such as number of nodes N, learning rate h, number of epochs T, stake mean and stake variance\nWe were able to answer most of the open questions (from previous weekly - remaining is analytical grounds for fast convergence) - How big should T be (# of slots in an epoch), How small should h be , How fast does this converge.\nWe have a general solution to the total stake inference problem - based on this document we have a good understanding of Accuracy, Convergence Rate and Stability.\nWriting of the Cryptarchia specification is well underway - you can check the latest version here.\nReviewed Ouroboros Praos, the focus was to understand the whole design and put a bit more attention at the design of the random beacon and some security assumptions. More on that in the notes.\n\ndevelopment §\n\nThe Cryptarchia development plan initially stated is still valid and has been updated. We will have the first milestone defined soon as well.\nRefactor consensus engine in preparation for adding a new consensus - PR.\n\ndata availability §\nresearch §\n\nThe DA Layer Comparison table has been finished and is currently in review and update phase. For the raw data, refer to this Google sheet\nBlock format specification has been added.\nDA API specification has been added.\n\ndevelopment §\n\nMerged a couple of small fixes for the nomos-chat app - more details here.\n\nmiscellaneous §\n\n3 interrelated topics that have the potential to create an interesting element of differentiation have been researched: turning Execution Zones into Plasma chains with ZK proofs (findings), solutions for instant deposit/withdrawal, solutions for ZK-bridging with the Base Layer (basically the CL layer, but as minimal as possible).\nPolygon Avail has been researched - findings.\nSimulations working principle (the Carnot paper Appendix) has been added.\nWhitepaper feedback review in progress.\nCarnot paper has been reviewed.\n"},"nomos/updates/2024-01-22":{"title":"2024-01-22 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nOne of the last pieces of the mixnet specification: “Defining topology update and entropy injection in a clear way” - we are close to a solution and will include new findings next week. To see the current proposal and differences being discussed (for example architecting the consensus and mixnet interaction) please check the GitHub PR. Code review is also in progress.\n\ndevelopment §\n\nTested libp2p stream protocol for the mixclient->mixnode and mixnode->mixnode communication. Concluded that’s very simple and appropriate for our case because it’s the fundamental protocol that is used for other libp2p protocols such as DHT. That’s basically not very different from the naive communication implementation over QUIC or TCP.\nCompleted several PRs (with code-review as well) Topology, Sphinx packet construction, Packet delays, Mix client Poisson emission.\nDesigned the updated Nomos Rust project structure for mixnet v1.\nAnalyzed the rust-libp2p QUIC transport in terms of configuration and implementation details.\n\ntestnet §\ndevelopment §\n\nRemoved the async-trait from the node as well as Overwatch.\nGrafana and related services addition to the testnet (new PR).\nPreparation for demo chat app bot, ability to send data from file, non-interactively (new PR).\nPrune Carnot old block PR has been completed and is currently in review.\nAdded a test for big blobs dissemination.\nLimited the number of in-flight requests performed by the chat app to avoid using too many descriptors - more details here.\n\ncryptarchia §\nresearch §\n\nUpdated the wealth concentration analysis with the new [chapter](https://www.notion.so/Does-Crypsinous-Leader-Election-Function-lead-to-wealth-concentration-in-PoS-b81f07a791b745438443f51f00ac258f?pvs=4#1df422f6cc204cb8b362f41cda260b8b about stake relativization algorithm. The section about known total stake is also in progress.\nStake relativization specification is complete.\nSet up an analytical framework which will be used to study the impact of using the (biased) total stake estimator on the leader election process. The central object of this framework is the joint probability distribution of two copies of the election process with the same (random) sampling noise, the same stake but different values of the total stake.\n\ndevelopment §\n\nNo updates, heavily in research.\n\ndata availability §\nresearch §\n\nDA API specification is written (likely to change due to active discussions).\nDA Layer Comparison article is almost finished - there are several comments still left to be resolved. Protocols were explained in more detail. Tables have been updated and to see the raw updated data on its own refer to this sheet.\n\ndevelopment §\n\nDA implementation plan is written (with active discussions it is likely to change).\n\nmiscellaneous §\n\nDevised a plan to take action for Nomos marketing and comms strategy: devised a couple of WIP docs (strategic one and mission one). We will start compiling our resources to help out the comms team with “ammo” for the Twitter and other social media.\nCarnot paper is currently being reviewed. Team feedback collected, several issues (for example of administrative and legal nature) were raised and will be addressed.\n"},"nomos/updates/2024-01-29":{"title":"2024-01-29 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nThe Mixnet specification is ready for review and can be frozen with the current version for v1 (until we find additional requirements during the implementation).\nDefined the mixnet topology update mechanism as a result of internal team discussions - conclusion: we should abstract a robustness layer that will handle mixnet configuration.\nRedefined mix destination: Instead of having an extra hop to the mix destination after L layers, we’re going to use the last mix layer as the mix destination (for message reconstruction).\nAlso, the problem of the common view of candidate nodes for mixnet participation was raised - how to ensure that the whole network will know which mixnodes are selected. As previously discussed, we confirmed that we need to have a dedicated staking action for registering candidate mixnet nodes on-chain - the sampling will be performed only from the list created by that staking action.\nThe PRs that entail the changes and piece them all together in the executable mixnet specification can be found here and here.\n\ndevelopment §\n\nAdded a couple of PRs in preparation for the mixnet rust development - crate structure, remove mixnet legacies 1, and remove mixnet legacies 2.\n\ntestnet §\ndevelopment §\n\nStarted the document on the design of Block Explorer 2. Also, added a PR regarding naive blocks query implementation from the storage layer (the PR is still open with an ongoing discussion).\nAdded a testnet basic bot to the chatapp non-interactive mode (PR). In more detail, we have previously added the ability to disseminate a file to the DA in the testnet, and we updated the chatapp with a similar functionality, which is used to have a bot that constantly pushes readable data to our DA in the testnet. This data (as opposed to file upload) will be readable by our testnet users and will be useful during the demos.\nContainer for the basic bot PR - performed some required changes to our testnet infrastructure.\n\ncryptarchia §\nresearch §\n\nUpdated the wealth concentration analysis chapter about stake relativization algorithm.\nStarted the Nomos Tokenomics Design Canvas that will be filled in with additional details in the future.\nWe have discussed an alternative path for the leader election function (stake relativization) in the. Refer to this comment for more details. This helped answer a high-priority question: Do we need to learn total stake?\nThe initial version of the Cryptarchia executable specification PR has been merged.\nAdded fork choice rule to the Cryptarchia executable specification.\nMerged implementation of slot leader election check to the Cryptarchia executable specification.\nAnalysis of Impacts of Approximate Total Stake - having considered two alternative election histories of a node (one when using the true stake and the other when using the approximate stake), the population study shows higher staked nodes are more impacted by errors in estimating total stake. Also, impact on the finality study shows high sensitivity to overestimates of stake. This was done by deriving the analytic expression for the Hamming distance between the two aforementioned histories which allows quantifying differences - for the detailed analytic work, refer to the Overleaf document.\n\ndevelopment §\n\nNo updates, heavily in research.\n\ndata availability §\nresearch §\n\nDA Layer Comparison article has been updated according to the latest review. In addition to that, we also provided details about the Ethereum Danksharding Protocol and its comparison to the Nomos DA protocol (according to our research).\nVID Certificate section in the DA API Specification has been added. In it, we explained the steps required to create VID Certificate and their order, described what data is sent to different participants (Nomos Zone, DA Node, Block Producer). We have reviewed it internally and added some new questions and comments - refer to the discussion for more details.\nBased on the definitions from the VID certificate, revised the Block DA Metadata structure with some minor updates, more precisely with the data that should be written in the block for DA.\n\ndevelopment §\n\nNo development updates.\n\nmiscellaneous §\n\nFinalized v0.5 of the darkpaper: updates according to feedback and new insights and strategy: rewritten several sections and eliminated a bunch of sections that were not satisfactory. Some changes of the darkpaper are conceptual, not just cosmetic, improving the strategical focus.\n"},"nomos/updates/2024-02-05":{"title":"2024-02-05 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nPolishing the mixnet specification regarding the topology algorithm and all parameters - we’ve had some concerns about it, so there are several ongoing discussions on Notion and GitHub in regards to answering them. For more details on the discussion, check this PR.\nWhile it has been postponed from v1, we will have to define the mix node identity soon for incentivization.\nAfter careful consideration and discussion, the topology update and public APIs PRs for core logic have been merged.\n\ndevelopment §\n\nAdded a utilities function of python mixnet to rust PR. Currently in review.\n\ntestnet §\ndevelopment §\n\nAdditional polishing (route separation) of the Naive blocks query implementation from the storage layer PR.\nAdded DA API for Explorer, while removing the unused API PR - currently in review.\nIntegrated the block explorer into the demo. Currently thinking about writing integration tests for it.\nTestnet fixes PR: the testnet ran on Linux with no issues; however, several fixes were needed for it to work on MacOS (about Grafana, Nomos chat bot params, and Nomos chat OpenSSL libs build version).\n\ncryptarchia §\nresearch §\n\nUpdated the wealth concentration analysis chapter about the stake relativization algorithm - specifically about the impact of the stake relativization.\nUpdated the Nomos Tokenomics Design Canvas with details about the “Validators” role. More roles to be entered in the coming weeks.\nAdded the fork choice rule PR as described in “Ouroboros Genesis: Composable Proof-of-Stake Blockchains with Dynamic Availability”. Tests will be added later.\n“Follower maintains ledger state as it follows the blockchain” PR. Leader coins are now spent when they become slot leaders. The next step is to have the leaderproof produce a new coin that the validator can then use to lead another slot.\nMerged the “Add header ID and message” PR.\nSummarized the mathematical analysis work in the Impact on Forks chapter and Reducing Forking chapter. More precisely, derived the probability of the “forking” event and the “empty slot” event when the approximate value of the total stake is used. Considered the large total stake and finite number of slots scenario to derive the typical number of forks and empty slots expected in the T number of slots. This framework was used to assess impacts of underestimation/overestimation of the total stake on the number of forks and empty slots. For the detailed mathematical analysis, check the Overleaf document.\n\ndevelopment §\n\nNo updates, heavily in research.\n\ndata availability §\nresearch §\n\nDA Document has been updated with new details based on the team review (specifically around adding more details about Ethereum Danksharding).\nMerged a mandatory PR containing a big chunk of primitives from the ETH specification that’s a dependency for building our DA specification. It will help us save a good amount of time during our implementation (and testing) of everything.\n\ndevelopment §\n\nStarted work on the DA Layer Implementation Details document. This is a an executable spec.\nThe sketch of the DA layer can be seen in this branch.\n\nmiscellaneous §\n\nThe website’s copywriting has been updated to reflect the changes from the Darkpaper.\nStarted publishing posts on X.\nWe have chosen several articles and will be publishing more detailed, scientific blog posts in the coming weeks. Once the specifications are complete, they will also be communicated via our social media.\nDarkpaper v0.5 published internally.\n"},"nomos/updates/2024-02-12":{"title":"2024-02-12 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nStarted the investigation of the mixnet participation problem. We have looked at Nym and how they constructed a mechanism for populating the mixnet. We extracted the design and described it in detail here. In short, they require the mixnet nodes to register on-chain; once there, they are randomly selected using weight as stake (plus delegated stake), and rewards are paid based on the mix node performance.\n\ndevelopment §\n\nNo development updates.\n\ntestnet §\ndevelopment §\n\nFixed the race for nomos log service PR.\nNomos-cli: Integrated the explorer into the nomos-cli in one PR with the integration tests coming in another one once it is unblocked (blocked due to the sled dependency).\n\ncryptarchia §\nresearch §\n\nNew details have been added to the Cryptarchia specification: the epoch transition, nonce specification, orphan proofs validation, leader lottery VRF details, leader coin evolution. With these additions, the Cryptarchia v1 is now ready internally.\nThe impact of approximate total stake (total stake underestimation/overestimation) document has been finalized and summarized. Awaiting internal review. For the mathematical analysis and results, please check the Overleaf document.\nWe have considered adversarial statistical inference of relative stake when the Ouroboros Crypsinous lottery function is used in the leader election process while assuming that only a fraction of election results are observed. For this scenario, we also derived a statistical estimator of relative stake. The analysis of the (naive) statistical estimator is currently in progress. The summary of this work is provided here while the detailed analysis can be found here.\nTokenomics Design Canvas has been updated with new objectives & requirements in addition to new sections.\nAdded a chapter about the “stake relativization algorithm” to the “Does Crypsinous’ Leader Election Function lead to wealth concentration in PoS?” document.\n\ndevelopment §\n\nNo updates, heavily in research.\n\ndata availability §\nresearch §\n\nThe DA Layer Comparison Table has been finalized, after several reviews and additional efforts.\nData Availability Specification has been updated according to recent comments.\nDA protocol details page has been created with the protocol diagrams included in the latest iteration.\nThe DA specification has been updated with new details. To see them and, in general, the progress of the DA specification, refer to this PR.\n\ndevelopment §\n\nDue to the focus on the DA Specification, protocol details, and the comparison table, no development updates.\n\nmiscellaneous §\n\nBlog coming this week and will be posted on the Nomos website (with the link on our X/Twitter).\n"},"nomos/updates/2024-02-19":{"title":"2024-02-19 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nBased on previous investigation, started a document about integrating the population strategy from Nym into the Cryptarchia setting. In it, while following an explicit staking assumption, it is assumed that a node that wants to be a mix node must register and stake on-chain. WIP with a lot of potential changes.\n\ndevelopment §\n\nImplementation WIP: defining structure for mixnode / mixclient.\nImplementation: concluded that the nymtech/sphinx crate can be used for our use case. For reference, previously we used a wrapper of sphinx developed in the nymtech/nym codebase - but now, we can use the nymtech/sphinx crate as it is.\nModified libp2p to use QUIC. Replaced TCP with QUIC in the nomos-libp2p crate, which will be used by the mixnet network backend: PR.\nFixed integration tests for QUIC. With the QUIC updates, some DA integration tests were failing - now they are working properly: PR.\n\ntestnet §\ndevelopment §\n\nCreated a document regarding embeddable databases with their analysis. In more detail, the document includes benchmark code, analysis of several rust-based DBs, a proposal for which DB we should use, and example code for our most important use cases.\n\ncryptarchia §\nresearch §\n\nUpdated the “Does Crypsinous’ Leader Election Function lead to wealth concentration in PoS?” document with new details about stake relativization - more precisely new simulations in regards to validators of certain ranges.\nStarted building out a NIZK (Non-interactive Zero-Knowledge) Glossary of terms that will be used for internal education as well as writing the specification.\nWIP: writing a how-to guide for reading/writing NIZK specifications. This will help us in the future when writing certain Nomos specifications.\nAnalysis of de-anonymization of relative stake: for adversarial inference of relative stake in the leader election process, considered statistical properties of (naive) maximum likelihood (ML) estimator of relative stake - in the naive ML approach, the relative stake of node i is obtained from the frequency of observed 1’s, representing vins in elections, and properties of lottery function. Also, analyzed statistical properties of the naive ML estimator of relative stake. The consequences of the aforementioned results for the mixnet are in progress and will be shared in the future. To see the math behind the analysis check the Overleaf document.\n\ndevelopment §\n\nNo tangible updates - but Cryptarchia rust implementation is in progress, more details in the coming weeks.\n\ndata availability §\nresearch §\n\nInitial DA API specification structure PR: defined mock zone, DA node and block producer to wrap DA spec and use it for encoding, dissemination and verification. Once the DA spec is near finalization, we will continue the mock implementation in python.\nDA Specification updated per reviews and comments. Likely more changes on the way (depending on review).\nStarted a document on studying VeriZEXE and Taiga designs. WIP, currently includes initial notes, likely to change.\n\ndevelopment §\n\nStarted implementing KZG core functionality of DA - more details in the upcoming weeks.\n\nmiscellaneous §\n\nFinalizing v0.6. of the darkpaper for internal release.\nFinalizing the first blog post for internal release.\n"},"nomos/updates/2024-02-26":{"title":"2024-02-26 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nAnalysis of the fraction of compromised paths in the mix network: developed an (asymptotic) analytical framework for the analysis of the fraction of compromised paths in the randomly generated mix network. Calculated the average and variance of the fraction of compromised paths. In the regime of a finite number of layers and very large width, the variance is vanishing, and the fraction of compromised paths becomes deterministic. Analysis of the large number of layers and large width regime is currently in progress.\nContinued the investigation of the mixnet population - analyzing the proof of mixing under the explicit staking assumption for Cryptarchia: Trying to reason the possibility to limit the number of active staking parties and uphold the same security properties as Nym has. In conclusion: without active participation of “users” (regular nodes) we cannot effectively measure the performance of the mixnet. On top of that, the engagement of the regular nodes must follow the same design as mixnet formation - it must be incentivized.\n\ndevelopment §\n\nImplemented the full spec of mixnet v1. Preparing to open a couple of small PRs by splitting a few of the bigger ones.\n\ntestnet §\ndevelopment §\n\nNo updates.\n\ncryptarchia §\nresearch §\n\nThe Tokenomics Design Canvas has been updated. Among other updates, it is important to mention that we added a new role to the canvas - Light nodes (Zone verifiers and replication providers).\nScraped cexplorer for the individual stake values held in Cardano’s: Notes.\nSimulations and plots to validate stake privacy analysis: Analysis.\nAnalysis of de-anonymization of relative stake: for adversarial inference of relative stake in the leader election process, considered statistical properties of maximum likelihood (ML) estimators of relative stake. A number of empty slots were included in the ML framework but lead to an inconsistent estimator of the relative stake - this result was confirmed in simulations. The ML framework was used to infer the relative stake in simulations using synthetic and real stake (Cardano) data. Simulations suggest that at least a 1/100 fraction of the network has to be observed at any time to infer the relative stake of the top 1% nodes with high probability within T=432000 time-slots. Summary and the detailed analysis.\n\ndevelopment §\n\nCryptarchia first PR - Cryptarchia engine - is ready for review - it’s mostly a translation from specs code apart from a few routines that were made more efficient. Additional things (e.g., orphan proofs) will be added in a future iteration.\n\ndata availability §\nresearch §\n\nStudied on the BLS threshold Signature. The detailed explanations of BLS-pairing and signature aggregation are finished - document.\nStudying Taiga designs (WIP) - This article discusses the architectural differences between the privacy-preserving execution environments Taiga, Zexe, and VeriZexe in the context of smart contract systems.\nStudied on the python implementation of KZG to understand the verification check problem. We solved the bug encountered previously - PR.\n\ndevelopment §\n\nDA API implementation for FullReplication protocol in progress: added Certificate Metadata definition and integration PR.\nResearch on SurrealDB - captured the notes as part of the greater DB research document.\nImplemented RocksDB storage service - PR. Based on this also opened the PR to start using RocksDB as the backend.\n\nmiscellaneous §\n\nv0.6 of Darkpaper is close to finalizing (internally). After the introduction is written, we will coordinate the public release.\nThe first blog (Is Network Anonymity Alone Sufficient for Proof of Stake Systems) is being finalized. We have one more round of comments to review and add the blog feature to the nomos.tech website. The next blog (regarding wealth concentration in PoS) is in progress.\n"},"nomos/updates/2024-03-04":{"title":"2024-03-04 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"network privacy and mixnet §\nresearch §\n\nStarted rewriting the “Populating mixnet” document, leading to the creation of a new document that combines both previous mixnet-related documents. Initial editing was done, a couple of minor sections have been added, and an additional section has been created that discusses a couple of cryptoeconomical problems requiring more investigation - WIP.\nMixnet Incentivization: started a new document that will contain the understanding of the mixnet incentivization problem.\nAnalysis of the fraction of compromised paths in the mix network: In the regime of a finite number of layers and very large width, the variance is vanishing, and the fraction of compromised paths, alpha, becomes deterministic. This, however, is no longer true when the number of layers and width of layers are both large. For this regime derived an analytic (asymptotic) expression for the probability that α belongs to some interval [alpha_0, alpha_1]. Verification of this analytic result by simulations is in progress, and the summary is here.\n\ndevelopment §\n\nMixnet network backend skeleton - PR.\nLibp2p stream read/write - PR.\nEmitting packets from mixclient using libp2p stream - PR.\nHandle outputs from mixnode using libp2p stream/gossipsub - PR.\nRefactor Poisson distribution implementation - PR.\nMix client Poisson emission - PR.\nMix node packet handling - PR.\nMix Packet / Fragment logic - PR.\nMove FisherYates to nomos-utils - PR.\nMixnet topology - PR.\nMix client/node unit tests PR.\nNote on the PRs above: tests will fail because the whole implementation has been split into small PRs. All tests will pass at the last PR that will be opened.\nTaking some time to refactor network adapter codes that are tightly coupled with only the libp2p network backend.\n\ntestnet §\ndevelopment §\n\nWIP: Integration for explorer - PR (marked as WIP since one of the unit tests is failing).\n\ncryptarchia §\nresearch §\n\nTokenomics design canvas has been updated with additional clarifications regarding the “Light node” role (both Zone verifiers and providers of replication).\nStake relativization has been updated as part of the Cryptarchia specification.\nStarted the Block rewards document to discuss and propose solutions to rewarding new block proposals.\n\ndevelopment §\n\nMerged all PRs for Cryptarchia here and here.\n\ndata availability §\nresearch §\n\nSeveral libraries were reviewed for the implementation of RS encoding. The usage of FFT in the implementation was examined. In the initial stage, details on how the implementation can be carried out were outlined here.\n\ndevelopment §\n\nKZG core functionality (working version) has been implemented - PR.\nStarted RS: implemented encoding.\nStarted RS: decoding implementation in progress.\nDA API Verified certificate selection from the mempool function - PR.\nDA API sign attestations in full replication - PR.\nDA API signer tests - PR.\n\ncoordination layer §\nresearch §\n\nThe examination of the Taiga design continues. Technical details and the cryptographic functions used are being researched. Verifiable encryption is under consideration, and existing libraries in the literature are being reviewed. Notes and questions related to the Taiga design are documented here (WIP).\nAs part of the same effort with the previous point, created two more documents here and here that envelop additional efforts on studying Taiga.\n\ndevelopment §\n\nNo updates at the moment, heavily in research.\n\nmiscellaneous §\n\n1 new blog post is in review regarding Wealth concentration in PoS systems. Currently in the first iteration.\n"},"nomos/updates/2024-03-11":{"title":"2024-03-11 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"cryptarchia §\nresearch §\n\nWe have updated the Cryptarchia specification with the update epoch stabilization schedule - PR.\nAnalysis of adversarial inference of relative stake: derived an equation that can be used to infer the Lagrange parameter in the maximum likelihood inference of relative stake - the details of the analysis.\n\ndevelopment §\n\nRemoved assumptions on Carnot being the consensus algorithm in the mempool: PR.\nSeparate ledger and consensus to prepare for integration: PR.\n\nmixnet (network privacy) §\nResearch §\n\nWork in Progress (WIP): The Mixnet Incentivization document has been initiated. Current open questions will be addressed, covering system design, mathematical analysis, and more.\nContinuing work on the mixnet with staking, incorporating modifications based on feedback. A section has been added concerning the hidden bonus of deanonymization. It’s a straightforward observation that random assignment of adversarial nodes can, in some cases, lead to a higher number of adversarial paths than naively expected. Also, a section about discussing the latency and anonymity relationship has been started. WIP document.\nAnalysis of the fraction of compromised paths in the mix network: using an asymptotic lower bound to estimate the probability that the fraction of compromised paths, α, belongs to the interval [α0​,α1​]. The analysis suggests that in the mixnet of size n=240 with L=3 layers sampled from N=800 nodes, where M=200 nodes are adversarial, α can be almost three times larger than the average (M/N)L which assumes a mixnet of infinite width. The parameters n=240, L=3, and N=800 are currently used in Nym’s mixnet. Here for ¼ of adversarial nodes, the fraction of compromised paths can be as high as 0.05. To compare, the average here is 0.02. Summary is provided here.\n\ndevelopment §\n\nAll PRs for Mixnet v1 implementation have been merged. We’ve taken some additional time to polish the code according to feedback.\nOne remaining PR we are working on is adding a compilation option to enable mixnet. We’re going to always enable mixnet in production, but we’ve discussed that it’s also good to remain in the libp2p-only compilation mode for development to unblock other dev topics until everything of mixnet becomes stable. Will be finished this early this week.\n\ndata availability §\nresearch §\n\nNo current updates.\n\ndevelopment §\n\nFinished RS core encode/decode: there was an issue with different FFT calls from different libraries that didn’t work and took a while to debug. They use floating numbers, and when rounding or using a big set of operations, precision leads to errors - PR.\nImplemented DA protocol encoder: PR.\nImplemented DA protocol verifier: PR.\nDA API mempool tests using a mock implementation PR - The previous PR defined an abstraction for verifying and filtering what to include in the generic mempool; this PR provides mock implementations for TX and Cert verification/filtering. WIP: DA API indexing for data blobs - adding an index to data blob in DA node when the certificate is observed in the block.\n\ncoordination layer §\nresearch §\n\nWe have begun a couple of study documents in terms of the Coordination Layer: What does it mean for an asset to be “inside” a Zone and Illustrated guide to “Mutator Sets and their Application to Scalable Privacy. With these documents, we want to solve questions and challenges before delving into the design.\nThe “Parallel Zero Knowledge Virtual Machine” paper has been reviewed, and a brief summary of GKR details has been shared.\n\ndevelopment §\n\nHeavily in research, no development updates.\n\ntestnet §\ndevelopment §\n\nExplorer works well now, can share the data directories with the node, and provide data through HTTP: PR.\n\nmiscellaneous §\n\nNomos has a new HackMD account - our team will be publishing various notes on it - mostly scientific in nature.\nBlog to be released this week. Stay tuned on our website.\n"},"nomos/updates/2024-03-18":{"title":"2024-03-18 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Cryptarchia §\nResearch §\n\nNo research updates at this moment.\n\nDevelopment §\n\nStake Relativization Specification - the spec implementation has revealed some bugs in our orphan proof handling logic. Those bugs are still being worked through in this PR.\nRefactored Cryptarchia implementation into ledger and consensus crates: PR.\nRefactored nomos header and block definition so that it’s now responsibility of the nomos-core crate: PR.\nAdded Cryptarchia consensus service: PR.\n\nMixnet (Network Privacy) §\nResearch §\n\nMixnet incentivization document has been further updated, more precisely the “Rewards” chapter that showcases the mathematic analysis and some of the parameters.\nFocused on researching the problem of mixing transactions by briefly investigating the economic perspective - emphasized on the fact that it can be a main source of the revenue for the mix network. Furthermore, we discussed the privacy perspective and potential negative impact on the privacy due to direct staking.\nStarted work on the Message Type Indistinguishability (WIP name) section, where we discuss the potential sizes of the messages, their impact on the throughput, mixnet capacity, and noted a rewarding thing leading to a negative on the privacy. Both this and the previous point can be found in this (WIP) document.\nAnalysis of the fraction of compromised paths in the mix network: optimized code which computes the (asymptotic) lower bound on the probability that the fraction of compromised paths, alpha, belongs to the interval [alpha_0, alpha_1]. The code takes the mixnet size n, sampled from N nodes where M nodes assumed to be adversarial, some initial fraction of compromised paths alpha_0 and outputs minimal fraction of compromised paths alpha_1 such that prob. that fraction of compromised paths belongs to the interval [alpha_0, alpha_1] is 1. The code can be used to design a program which optimizes the number of layers L given some threshold, on the alpha_1, which can be tolerated. However, one has to test if the asymptotic lower bound is suitable for this and gives alpha_1 which is not too loose. Summary of numerical results and simulations is provided in this document. Summary of analysis is provided in this document and the detailed analysis can be found in the Overleaf document.\n\nDevelopment §\n\nIntegrated mixnet network service for consensus, DA, and mempool: PR.\nUpdated nomos-node integration tests for Mixnet: PR.\nRefactoring mixnet code: PR - and further PRs to be opened soon.\n\nData Availability §\nResearch §\n\nA case for dispersing the same VID Certificate multiple times was discussed during development, shorter version can be found in this document (VID Related Open Questions chapter).\nBLS threshold details have been added in the relevant document. It was concluded that there could be a significant overhead in communication when using DKG. Instead, an agreement was reached to apply a different solution using aggregate BLS. The relevant changes have been updated in the specification document. At this stage, we will proceed with this method. To find the best solution for this part, we might ask for support from the VAC team.\n\nDevelopment §\n\nInitial DA API spec structure revised and merged: PR.\nTests using DA Protocol specs have been developed. Currently, there are 2 types of tests, which are showcased in the first PR and the second PR.\nFinalizing DA verifier protocol specification: PR.\nFinalizing DA encoding protocol specification: PR.\nFinalizing DA dispersal protocol specification. Full flow with tests included, using Encoders and Verifiers: PR. Also, they have gone through reviews and we started discussions in several PRs - #1, #2, #3\nAdded attesters bitfield to DA certificate. Missing compressed bitfield so we can use BLS aggregation of signatures as a threshold scheme: PR.\nAdded certificate verification specification.\n\nCoordination Layer §\nResearch §\n\nSynchronous Composability with Partial Transactions document with a proposed design.\nProgressed with the discussion on Atomic Asset Transfer w/ Taiga in this document.\nThe Taiga circuit structures have been reviewed again. Relevant comments have been added to the document.\n\nDevelopment §\n\nNo development updates.\n\nTestnet §\nDevelopment §\n\nNo updates at this moment.\n\nMiscellaneous §\n\nBlog is now live - feel free to take a look at the first article here. More to come soon!\n"},"nomos/updates/2024-03-25":{"title":"2024-03-25 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Cryptarchia §\nResearch §\n\nNo research updates at this moment.\n\nDevelopment §\n\nFixed a bug in the Cryptarchia spec regarding try_create_fork to find parent block.\nStake Relativization Executable Specification is done: PR. Also, implementing stake relativization revealed some bugs in our Cryptarchia spec which took some time to debug and write tests for. Also, the stake relativization spec has been updated with learnings from the implementation (changes were mostly around time management since we need the inferred total stake to be stable by the time we enter the next epoch).\nRegarding block rewards, our proposal would be to postpone this work for when we will have the CL available, as it’s likely best done through a ‘special’ transaction (probably in a block body rather than in the header).\nAs discussed, at this moment, we will not support multiple consensus protocols in node.\n\nMixnet (Network Privacy) §\nResearch §\n\nMixnet incentivization document has been updated with additional problem statements: we are exploring how to make delegations private.\nAnalysis of the fraction of compromised paths in the mix network: The asymptotic lower bound (asympt. l.b.) on the probability that the fraction of compromised paths, \\alpha, belongs to the interval [\\alpha_0, \\alpha_1] was used to obtain an upper bound on the maximum fraction of compromised paths, \\alpha_max, in the mixnet of size n sampled from N nodes, where M nodes are adversarial.\nComparing the asympt. l.b. and simulations shows that the latter provides a very loose upper bound on \\alpha_max when the size of mixnet n is fixed and the number of layers L is increasing. However, the asympt. l.b. provides a better upper bound on \\alpha_max when the width of the mixnet n_1 is fixed and the number of layers L is increasing.\nDerived the probability distribution for the fraction of compromised paths \\alpha in the mixnet of size n=n_1 L, where n_1 is the number of nodes per layer and L is the number of layers, with m adversarial nodes when n_1 is very large. In this regime, the number of adversarial nodes in a layer is a random variable from the binomial distribution with parameters n_1 and m/n, such that on average n_1m/n nodes per layer are adversarial. Summary of numerical results and simulations is provided in this doc while Summary of analysis is provided here and the details of the analysis are in Overleaf.\nMixnet with staking design: Message Type Indistinguishability - extended the message type indistinguishability section of the staking design document, where we added a part about the impact of the pledged and delegated stake based rankings on the privacy. This part of the investigation, led to coining the Staking Security vs Privacy dilemma, where we describe a tension between staking security and privacy. In short, staking can increase chances for deanonymization. The details can be seen in this document.\n\nDevelopment §\n\nSome refactoring work on following PRs: #615, #616, #618.\nWIP: Testing if mix client/node emit packets according to the specified Poisson parameters.\nWIP: Testing if enough packets are mixed in each mix node.\nWIP: Working on making the aforementioned two as metrics (for monitoring).\n\nData Availability §\nResearch §\n\nNo research updates at this moment.\n\nDevelopment §\n\nFixed a new storage issue in windows build CI: PR.\nAdded a new block subscription to consensus service: PR.\nDA API testing: PR.\nAdded Certificate verification to specs: PR.\nFixed arbitrary data encoding in the Encoder specs: PR. There was an issue with this, we can only encode up to 31bytes per chunk using bls. Notice that bls uses 32bytes field elements, but some 32bytes elements would be higher than the bls_modulus, hence we need to use 31bytes.\nAdded duplicated blobs verification in verifier: Verifiers need to return the attestation in case a duplicated verification comes around, or skip it depending on different stages: PR.\nMoved current DA API implementation to draft: DA Protocol abstraction will change. Until we have an updated version, the DA API work is on hold.\n\nCoordination Layer §\nResearch §\n\nWe’ve been reading Taiga source code, and putting up minor contributions as we go through it: PR - taiga#262, taiga#260, taiga#259.\nReviewed Synchronous Composability with Partial Transactions. The relevant article has been reviewed, and comments have been added.\nDetails regarding the proof of equivalence have been explained and python code for random proof generation has been added to the following document.\nAs part of our research effort, compiled the notes on - Bitcoin L2s, New Architectures, Coordination Layer.\n\nDevelopment §\n\nNo development updates.\n\nTestnet §\nDevelopment §\n\nRemoved unused nomos services: old metrics service replaced with a Prometheus PR and old http API removed PR.\n\nMiscellaneous §\n\nA new blog post will be published this week: Tackling the Challenge of Wealth Concentration in PoS Blockchains with the simulations and scientific results.\nWe have exciting new ideas cooking about updating the Nomos documentation - stay tuned!\n"},"nomos/updates/2024-04-01":{"title":"2024-01-04 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Cryptarchia §\nResearch §\n\nUsed the probability that the naive estimator of relative stake is inside some interval which includes the true stake α, δ(α), to derive an algorithm that suggests how to divide the stake of a node in order to reduce the quality of statistical inference by an adversary. The interval [α(1−γ),α(1+γ)] is parameterized by the adversarial “accuracy” parameter γ. The probability δ(α) can be interpreted as adversarial “confidence” gained after Tq observations (on average), where T is the number of time-slots in one epoch and q is the fraction of observed slots (for example due to deanonymization failure of the mixnet), that the inferred stake is within the interval [α(1−γ),α(1+γ)]. Assuming q and γ, a node can use its stake α to compute the probability δ(α). The latter is a monotonically increasing function of α, and dividing α among a number of nodes reduces the adversarial “confidence,” thereby reducing the quality of adversarial inference. The details of the analysis can be found in the following document.\n\nDevelopment §\n\nCryptarchia fuzz tests: tried various fuzz testing strategies, but finally ended up with a simple but clear fuzz strategy, through which we can test Cryptarchia by simulating the environment where the block proposal delivery (p2p networking) is not synchronous and not predictable. The initial PR for the basic strategy has been opened. Also opened a small fix found by the fuzz test: PR.\n\nMixnet (Network Privacy) §\nResearch §\n\nDiscussed the Staking-Privacy dilemma and came to a conclusion that the Nym design needs to be fine-tuned to reduce the impact of the delegated stake on the probability of selection of a node. We also need to investigate a mysterious constant that “controls the loss of competitiveness experienced by a Sybil attacker when it partitions the stake into multiple pledges”.\nPrepared a recommendation for the first iteration of the mixnet staking. The main motivation was to present a simple staking design for mixnet that is inspired by Nym but is simplified and will be updated when our approach gets more mature.\n\nDevelopment §\n\nAdding metric APIs for Mixnet - still work in progress. A PR will be opened for a minimal but essential metric API this week. This should be enough for now because the entire mixnet architecture may change according to the mixnet staking design. The first metric is going to be the number of packets that are being mixed in each mix node, which can be considered as the quality of mixing. More details in the relevant document.\n\nData Availability §\nResearch §\n\nNomos DA specification has been rewritten - a document has been added on top of the original one to make certain mathematical and technical details more digestible.\n\nDevelopment §\n\nNomos DA verifier sketch: We have started putting all pieces in place for getting the DA protocol implemented and integrated in the node. This implies some cleaning and refactoring that have impact in the code base. We have a da-v1 branch where we will be incorporating everything until it is ready and stable to be added to master - PR.\nPublished a draft branch with the first working version of the Nomos DA protocol. This will make a lot of changes including removing of old attempts and experiments. Notice that this branch will hold a lot of changes but that most of them will be incrementally included (and reviewed).\nBranch added: KZG+RS core in rust, bytes_to_polynomial method - not working atm but we are debugging to see what is the issue (looks like roots of unity related).\nBranch added: DA indexer - work in progress, removed all previously proposed mocks and structures as da protocol changed substantially.\n\nCoordination Layer §\nResearch §\n\nTaiga: compiled a report on the current state as part of our research efforts.\nTaiga made the choice to use blake2s for VP commitments and Poseidon for resource commitments. The experiment looks at prover/verify time when blake2s is replaced with Poseidon, and we get a near doubling in performance. More details in our experiment. The details of the Blake2s with Poseidon implementation have been reviewed in this document. As part of examining the usage of Blake2s and Poseidon in the Taiga implementation, a summary providing general information about ZK-friendly hash functions has been prepared.\nThe survey on proof systems is underway: to summarize, Halo2 stands out in implementations for private transactions. Its use of Plonkish arithmetization and consideration of lookup arguments make Halo2 advantageous. As discussed earlier, we prefer not to use a trusted setup-related feature like KZG in the coordination layer. Consequently, proof protocols involving trusted setups, such as Groth16 and Plonk, are less favored. Generally, there are three common polynomial commitment schemes used in existing protocols: KZG, IPA, and FRI. A comparison of these schemes has been added to the report. Even if we don’t use Plonk, the use of Plonk-ish arithmetizations in Halo2 is significant for performance. In addition, Nova’s folding improvement is critical for performance, but it requires the use of R1CS instead of Plonkish. Sangria, a folding scheme using Plonkish methods, is a new design worth exploring. Finally, after outlining the general framework for the coordination layer, we believe that upgrading cryptographic sub-algorithms for performance will not be too challenging.\n\nDevelopment §\n\nNo development updates.\n\nTestnet §\nDevelopment §\n\nNo updates at the moment.\n\nMiscellaneous §\n\nNew blog will be published after reviews - Stake relativization.\nNomos team will be at All-hands next week.\n"},"nomos/updates/2024-04-08":{"title":"2024-01-08 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Note §\n\nThis is a weekly update from the part of the team that didn’t attend the All-Hands Event in Athens.\n\nMixnet (Network Privacy) §\nResearch §\n\nRegarding the current situation with the mixnet and staking, we have decided to focus on the simplest approach, that is only single-staking without stake delegation as suggested for the first iteration of the staking. Due to the simplicity of this approach, we can model it more precisely and learn more of its properties.\nWe have received a couple of comments regarding the mixnet from an external reviewer. The comments and our analysis can be seen in this document.\nReviewed an interesting critique of mixnets and suggestions on their improvements. One of them is the Poisson mixing design choice that is part of Nym and is claimed to be wrong. This led to a discussion on how to design a better mixing mechanism. We don’t know exactly what is broken in the Poisson mix; there are some claims and some proposals on how to solve the problem suggested in the presentation. We have asked for more paperwork supporting their claims and the authors of the presentation are working on it. In the meantime, a proposal has been prepared based on suggestions from the presentation.\nLooked at the Bittensor proposal (especially the idea of treating a node as a learning machine and combining it with a rewarding function), read through all of their papers. If we would like to use a similar approach then we must prove that the outcome of the mechanism cannot be biased - which might be very hard.\nOptimization of mixnets: written the initial specification and some functions for the algorithm which uses the (asymptotic) lower bound on the probability that the fraction of compromised paths belongs to some interval to compute the optimal number of layers. The details are provided in this document.\nAlso, tried to tighten the bound on this probability using the AM–GM and Markov’s inequalities, but trying this approach has not produced any improvements so far. The details are provided in this document.\n"},"nomos/updates/2024-04-15":{"title":"2024-01-15 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Note §\n\nThis is a weekly update from the part of the team that didn’t attend the All-Hands Event in Athens.\n\nMixnet (Network Privacy) §\nResearch §\n\nMixnet mixing problem: Based on the critique of the Loopix mixing design and proposed solutions, we have prepared an updated mixing design.\nWe are going to prepare a Mixnet empirical analysis tool, so that we can make sure that our Mixnet design meets a proper level of anonymity that we expect. This will probably be based on our executable specification, so that anyone in the team can run it easily whenever they want. Based on it, our reference implementation (Rust) will expose similar metrics, so that we can monitor its behavior in the testnet (probably in collaboration with Vac). This will be useful for finding the Poisson problem mentioned in the previous weekly, for example.\nNetwork bootstrapping/node registration: started thinking through the problem of network bootstrapping and the requirement of node registration. Looking for inspiration, details of the very early discussion can be found in this WIP document.\nOptimization of mixnets: derived an upper bound on the probability that the fraction of compromised paths, α, is greater than some threshold 1α1​. This new upper bound is non-asymptotic, i.e., for mixnets of any size n sampled from the population of N nodes, and much simpler to compute numerically than previously considered asymptotic bounds. Initial results of comparing this upper bound with simulations suggest that the bound is “practical”, i.e., can be much smaller than the trivial bound of 1, and can be used in optimization of mixnets. The summary of this work is provided in this document, and the detailed analysis can be found in the Overleaf document. Further simulations and work on the algorithm are currently in progress.\n"},"nomos/updates/2024-04-22":{"title":"2024-01-22 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"Cryptarchia §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMixnet (Network Privacy) §\nResearch §\n\nDefined metrics to be collected for Mixnet (for other components as well, but mainly for Mixnet). This list should be sufficient for now.\nInvestigated which empirical analysis had been done by Loopix paper and another paper, in order to design Nomos empirical analysis soon. When compared to our previous work, it isn’t so different. The main goal would be measuring the probability of linking an output message from a source message correctly. Still remains to determine if this should be for executable spec, or for a real implementation.\nPlanning the first collaboration with DST. This would focus on the Mixnet properties, but only simple metrics as the first step. Before starting the collaboration, we need to check if this list is really reasonable to be offloaded to DST.\nIn consideration on how we can avoid node distinction and registration, and while reviewing the Hopr design an idea arose of changing the layered mix topology (Nym) to a circular one which enables users to extend their number of hops freely, and using gossip pub-sub protocol as an underlying messaging to achieve mixing over P2P. Therefore, we are able to have at the same time privacy (and scalability) optimal layered mix (with flexibility of adjusting the level of anonymity - path length) that does not require registering node long-lasting public identifiers (IPs) and works on top of a P2P network. All this led to a sketch of a new type of a mix, the “Whirl” Mix.\nNew Network Privacy proposal has been made, based on the updated and clear vision/roadmap of Nomos.\nOptimization of mixnets: considered a scenario when all N nodes, where at most M nodes are adversarial, are used to construct the mixnet with L layers. Proved that in this case the fraction of compromised paths 𝛼α is at most (𝑀/𝐿)𝐿(M/L)L which was also verified by simulations. The histogram of 𝛼α obtained in simulations only has a long left tail. Properties of the above mixnet are very different from properties of mixnets of size n sampled from N nodes. Here the fraction of compromised paths is always bounded by 1. This suggests that for small (or moderate) N using all nodes could be more desirable. The summary of this work is provided in Notion while the details of the analysis can be found in Overleaf.\n\nDevelopment §\n\nNo development updates.\n\nData Availability §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nMerged KZG+RS core (implementation of the KZG and RS core methods): PR.\nImplemented and merged DA V1 encoder: PR.\nImplemented and merged DA V1 verifier: PR.\nDA mempool specific functionality for cert to vid conversion: network payload and mempool item in DA mempool now can differ if payload can be converted into the mempool item, PR.\nDA Indexer (WIP): implementation of metadata indexer had to be postponed as it depended on the certificate, vid and metadata definitions added in mempool split PR and da-protocol-v1 branch.\n\nCoordination Layer §\nResearch §\n\nStudied on the proof aggregation methods and also on the Jolt protocol (previously reviewed) for the survey. Added the updates (WIP - the aim is to complete it by the end of this week). A brief explanation about Jolt: It is designed to reduce prover costs by using lookup arguments. The reason for reviewing it is that its implementation was released in the past weeks. This version uses the Hyrax polynomial commitment, which results in higher verifier complexity (which is not ideal for Nomos). However, they mentioned that future versions would support different commitment schemes. Our priority is minimizing verifier costs, but if Jolt can offer good results for both prover and verifier, it might be worth considering. Release post of Jolt on X.\n\nDevelopment §\n\nSplit generic mempool into CL and DA mempools - this was needed as making it completely generic would have been impossible at some point. They are now free to deviate in both typing and behavior without affecting the other. The refactor was done so they can share as many available resources as possible: PR.\n\nTestnet §\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nWIP: Nomos Roadmap and Milestone Execution Plan.\nWealth Concentration in PoS, part 1 - published and posted on X.\nIntroduction to Nomos Architecture - in final stages, will be shared by Wednesday or Thursday.\n"},"nomos/updates/2024-04-29":{"title":"2024-01-29 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nPlanning the Mixnet v2 PoC simulation (WIP): To simulate the behavior of the new design, we need to cover some design options (such as the way of broadcasting, etc.). We’ll create a simulator with these options to find the optimal design.\nResearched the existing Mixnet simulators: They provide Python simulators focusing only on global passive adversaries (GPA) by measuring the Shannon entropy as a metric for anonymity (the uncertainty of linking an output message with a certain input message). We can adopt this practice for GPA analysis. For active adversary analysis, we need to figure out how to simulate tagging attacks and n-1 attacks (if necessary). For tagging attacks, we can probably perform an indirect analysis by measuring how many nodes a block is disseminated in before it’s selected/proposed.\nSummarized the requirements for the Mixing gadget.\nOptimization of mixnets: For a scenario when n nodes, sampled from N nodes with at most M adversarial nodes, we designed an algorithm. Given the number of nodes per layer n_1, the fraction of compromised paths which can be tolerated αm​ax, and the probability that the fraction of compromised paths is greater than 𝛼𝑚𝑎𝑥αm​ax, δ, the algorithm outputs the number of layers L: Summary. The algorithm is implemented in Python, but the code needs further refinement.\nAnalysis of anonymity and communication failures in the mix gadget: Assuming that k nodes are sampled from N nodes, where at most M nodes are adversarial, we derived the probability that all k nodes are adversarial and the probability that at least one node is adversarial. The latter is the probability of communication failure, and the former is the probability of anonymity failure. The probability of anonymity failure decreases with k, and the probability of communication failure increases with k. We derived upper bounds on these probabilities. For large N, the probability of anonymity failure is bounded above by 2(𝑀/𝑁)𝑘/𝜋2(M/N)k/π​, and the probability of communication failure is bounded by 1−𝜋(1−𝑀/𝑁)𝑘/21−π​(1−M/N)k/2. Note that M in the latter corresponds not only to adversarial but also to “slow” nodes or nodes with bad connections. The summary of this work is in progress.\nWork on analysis of the new mix gadget design is currently in progress.\n\nDevelopment §\n\nNo development updates.\n\nData Availability §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nInitial DA protocol benchmarking uncovered 2 performance issues that will be addressed as soon as possible: WIP.\nAdd Cert verification to DA mempool: - Merged payload to item conversion in mempool PR. Added certificate verification in da mempool PR merged.\nDA Indexer service definition: Service that is responsible for DA API functionality, is able to track new blocks and assign metadata to previously attested chunks PR. Note that the service is defined, but other services like storage are not yet integrated. These missing pieces will be the focus of upcoming weeks.\n\nPPoS/Consensus §\nResearch §\n\nWealth concentration document is in the process of reorganization with new studies being according to 8 parameters (see table 1 in the doc - we’re able to use way more realistic numbers as well, because software evolved), 3 classes of stakers (lower, mid, higher - we still lack a precise definition of them); and 3 fork-choice rules (lowest, highest, stochastic).\nThe first study assumes the relative stake is known and compares the 3 classes of stakers when the protocol enforces each of the 3 fork-choice rules under different parametrizations (sensitivity analysis).\nThe second study relaxes the assumption that the relative stake is known. We use and evaluate the impact of David and Alexander’s algorithm.\nThe third study relaxes the assumption that the protocol enforces the fork-choice rule. Each staker is allowed to use the rule of its choice.\nInvestigated the current state of the orphan proofs problem. After internal discussions, it was understood that this is a low priority for now, and we need to evaluate the real impact of this problem and how often it can happen first.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nCompleted the Proof Systems Survey: added updates on aggregation, folding schemes, and some protocols. Also, listed and grouped libraries with existing implementations. This week, there will be more detailed explanations about these libraries.\nCelestia ZK-Research Group messages have been summarized in a document with annotations and discussions around parts that might be important to us.\n\nDevelopment §\n\nNo development updates.\n\nTestnet + Insights §\nResearch §\n\nExtended the metrics and visualizations document by adding a planning block to match with yearly planning and resources.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nLatest discussions triggered the need for yearly planning modifications: Wrote a document explaining year expectations + resources planning.\nCreated an initial Vac QA collaboration document with cross-team interactions plan.\nMilestone Execution plan has been published.\nLogos - Nomos update added - this will be an introductory one with focus on progress of research and engineering in the future.\nNew Nomos blog to be published this week with another to be set to review.\n"},"nomos/updates/2024-05-06":{"title":"2024-05-06 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nTo specify adversary models, we analyzed and summarized two papers: 2013 P. Syverson & 2023 C. Diaz.\nBased on the above research, we defined the adversary model in the Mixnet v2: Proof of Concept, focusing on adversaries with partial visibility. Still, specific attack models must be defined so that we can simulate them. Currently, we are attempting things in reverse: imagining attacks that partially or completely break the protections that our design aims to provide. It’s still a work in progress in the same Notion page. Once this is complete, we can start implementing a simulation.\nBased on the previous week’s observations, we wrote a document containing a discussion on how to make the tagging attack less effective.\nAnalysis of anonymity and communication failures in the mix gadget (summary): Assuming that n nodes sample (with replacement) k nodes from the population with N nodes, where at most M nodes are adversarial, the fraction of k-subsets where all k nodes are adversarial, i.e., “anonymity failure” has occurred, is \\left(\\frac{M}{N}\\right)^k on average. The fraction of k-subsets where at least one node is adversarial, i.e., “communication failure” has occurred, is 1 - \\left(1 - \\frac{M}{N}\\right)^k on average. However, if n < N is finite, then deviation from these averages will be observed. For the fraction of k-subsets with anonymity failure, we derived an upper bound on the probability that the fraction of these k-subsets is greater than the average \\left(\\frac{M}{N}\\right)^k by the factor of 1+γ. The upper bound is decreasing with increasing n and γ. A similar upper bound is derived for the fraction of k-subsets with communication failure. Work on the analysis of these bounds and verification by simulation is currently in progress.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nDA Indexer implementation PR: Implemented AddIndex and GetRange functionality in Indexer service. When a list of VidCertificates is observed in a new Block, AddIndex is used to assign Metadata from VidCertificate to a blob that was attested. - When the user requests Range of Indexes for a given AppId, indexer collects available blobs for indexes and returns them in a list.\nDA Indexer + Mempool + Cryptarchia integration test: DA functionality relies on multiple services working together; a test to see if currently implemented parts are working was created.\nSome ideas and improvements were registered (low priority): Verified Certificate state and Investigate BlobDB storage.\n\nPPoS/Consensus §\nResearch §\n\nWealth concentration update: changes related to the introduction of the study structure, rearrangement based on new sections, and expanded explanations.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nDesigned a bridge withdrawal implementation. In designing, we found some bugs in CL, namely, anoma’s “single logic per resource” design is too limiting; it wasn’t possible to see how to implement a simple withdrawal in that design. The fix that was made was borrowed from Zexe, replacing the single note constraint with two types of constraints: birth and death constraints. There is a single birth constraint and arbitrarily many death constraints. Birth constraints govern how a note from a particular application can be produced. Death constraints are provided by the user and configure how a note can be spent; only one of the death constraints needs to be satisfied in order to spend a note.\nCreated the withdrawal CL test case.\nUpdated the Proof Systems survey according to comments. Explanations have been added to some of the sections. Additionally, existing zkp libraries have been reviewed to identify which proof methods are used.\nCoordination Layer Studies: a separate [section](A separate section for FRI has been added) for FRI has been added.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-05-13":{"title":"2024-05-13 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nClarified the adversary model further (WIP); we’ll develop it more by simulation. Attacks to be simulated are listed here, and are based on the adversary model in the same document. The related studies were referred to, including Waku’s documentation about adversarial models (provided by the Waku team).\nAnalysis of anonymity and communication failures in the mix gadget: Assuming that n nodes sample (with replacement) k nodes from the population with N nodes, where at most M nodes are adversarial, the average number of k-paths with anonymity and communication failures are, respectively, given by n \\left( \\frac{M}{N} \\right)^k and n \\left(1 - \\left(1 - \\frac{M}{N}\\right)^k\\right). Calculated an upper bound on the probability that the number of k-paths with these failures are greater than their respective averages by the factor 1+𝛾1+γ, where 𝛾>0γ>0. compared the above bounds with simulations showing that they are tight. Analysis of different cases of 𝑀/𝑁={½,⅓,¼,1/10}M/N={½,⅓,¼,1/10} suggests that, for reliability purposes, some combinations of n and k could be more advantageous than others. The summary of this work is provided here.\nStarted the investigation of the problem regarding mixing over a broadcasting channel, which is an interesting form of mixing in a sparse network. Using a broadcasting channel makes it impossible for an observer to learn who the recipient of the message is (assuming proper message relaying strategy). Making nodes indistinguishable requires a single cover traffic message per time slot, which is a step closer to ideal privacy. However, this has a great network overhead cost, which limits the scalability of the network significantly assuming a fixed bandwidth requirement per node. Also, made an observation about the impossibility of stake hiding, which is based on the fact that the network behavior of a node is reflected on the ledger and any disturbance of the node behavior must also be seen on the ledger. Document for reference.\n\nDevelopment §\n\nImplemented the simulation of “basic” mixnet behaviors (Modified Sphinx, Cover traffic, Broadcasting). They’re very naive but should be enough for running basic adversary simulations. The simulator is being implemented in the mixnet-v2-sim branch in the nomos-specs repository. Basic usage and development progress can be found in the README, though it’s still heavily WIP. Sphinx size: If the payload size is 330 bytes (32 bytes block hash + 288 bytes validator proof) and an incentive tx is 512 bytes (which may not be enough), and if the number of mix layers is 3, a Sphinx packet is 1937 bytes (subject to change).\n\nData Availability §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nDid benchmarks on DA, lib performance was way below expected and targets. Debugged issues, what was found is that the most problematic is proof generation. Discussed options for improvements: Parallelization (which is not really possible as is internally parallelized already) and amortized proof generation method. Ruse evaluation + Benchmarks can be found here.\n\nPPoS/Consensus §\nResearch §\n\nWealth concentration update: changes related to the introduction of the study structure, rearrangement based on new sections, and expanded/improved explanations.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nStudy on DA fast proof generation: research was conducted on fast proof generation in the DA domain. The Feist-Khovratovich technique was examined, and libraries implementing this method were investigated. The general structure of the method and the approach it attempts to implement are explained here.\nWrote a potential design for Mailboxes & Sovereign Transactions.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-05-20":{"title":"2024-05-20 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nSecurity of mixing over a broadcasting channel (document): We have been able to generalize the stake hiding impossibility observation, discuss a general countermeasure, and add a section on how to practically weaken this impossibility. We have extended the Global View section with more discussion regarding the overhead of broadcasting communication. A practical note regarding mixing failure and a sketch for a mechanism to recover from mixnet failure redundancy have been added. We have also started working on a partial view analysis.\n\nDevelopment §\n\nMixnet v2 Simulation: added adversary simulation. Currently, it includes only a passive adversary with a global view. More realistic adversaries will be added later (low priority for now). The current version of Mixnet v2 simulation can be found here. Please note that this document is WIP and not an experiment report, though it includes some plots. It shows what the simulation can do right now and what’s next. In progress: writing the first simulation result document to be shared internally so that we can plan ahead.\nWe internally agreed to start by simulating the simple behavior first and measuring the bandwidth usage, especially by broadcasting real messages without mixing. After that, we can turn on more complex behaviors (e.g., mixing & cover) and compare the results with the previous ones. This is because the simulation result with the whole set of behaviors may be too complex to analyze at the beginning when not everyone fully understands how the simulation works.\nWe found that the simulation speed is too slow with 100K nodes (not physical ones). The main reason is that the simulation is based on SimPy, which is single-threaded. However, the same poor performance was observed when another simulation framework in Python (Mesa) was tried. There may be some solutions (e.g., multiprocessing), but first, our aim is to produce the first meaningful simulation result with fewer nodes before improving it.\n\nData Availability §\nResearch §\n\nWe reviewed the FK20 algorithm again. Libraries for accelerating DA proof generation were reviewed. It appears there is some room for improvement, but it is not yet at the desired levels. Libraries: Rust-kzg, C-kzg, and Peerdas-kzg.\n\nDevelopment §\n\nDA Verifier service implementation: PR merged: the service for attesting the blobs.\nDA Verifier integration tests: Verifier service expects the DA protocol to implement a couple of traits for serialization, encoding, signing, etc. KZGRS backend is mostly implemented, but still needs some service-related utilities. This work is in the verifier-integration-tests branch.\nKZGRS performance review: as per the previous benchmarks on our KZGRS, we uncovered a few performance flaws. Those were addressed, but even then it did not reach our current targets. We have been checking and comparing with other implementations to see if we were doing anything wrong. We were not.\n\nPPoS/Consensus §\nResearch §\n\nExpanded/improved explanations of the results found in the Wealth Concentration in PoS document.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nStudies on binary field proof systems have been completed and documented. This week, we will also cover and take notes on Stwo (STARK prover) and check which parts we can use for the CL. These structures provide fast prover time. We need to discuss how much we need this on the CL side (because while providing fast prover time, it also increases proof size, which seems more important for us).\nThe Atomic Asset Transfer case has been started, but the text and diagrams lacked rigor. An implementation of the CL executable spec has begun, which can better sanity check the design. Details on Noir ZK language integration with Python: here.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nUpdated and improved the “Monitoring, instrumentation, and explorer” document - added a “milestones” section with the targets for the next iterations.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNew blog post has been released: Preventing Wealth Concentration in PoS Systems: The Role of Stake Relativisation.\n"},"nomos/updates/2024-05-27":{"title":"2024-05-27 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nSecurity of Mixing over Broadcasting Channel document has been updated with new details. We mapped the first few cases that we want to analyze through simulations; the Partial View section was added to the document. Analysis of partial view is much more complex than the Global View case, and the Global View does not seem to leak significant information. Thus, the observer in Partial View will need to play a probability game to learn something. However, there are routing attacks that can increase the field of view of the observer, so we should not neglect this case. We have also started working on the analysis of an alternative to broadcasting dissemination—peer to peer.\nAnalysis of random structures generated by the mix gadget, such as properties of hypergraphs, etc. was performed and summary can be found here.\n\nDevelopment §\n\nP2P Privacy Simulation: all simulation reports can be found in P2P Privacy: Simulation Results.\nPosted a report: P2P Privacy: Bandwidth Usage Patterns. Bandwidth was measured for both 1-to-all broadcasting and gossiping, with various parameters (mix layers & cover traffic) changed, so that we can gain insight into how bandwidth increases as parameters change. The document also shows how the simulation works. In short, we now have a framework to measure the performance of the protocol. The next simulation is evaluating anonymity with changing cover traffic patterns to find the optimal cover traffic strategy that guarantees a reasonable level of anonymity in the protocol.\nOne more (WIP) report can be found in (WIP) P2P Privacy: Anonymity. We are currently using the number of messages staying in each node over time as a metric to evaluate the level of anonymity. Although it may not be the best metric, it’s probably the most intuitive one for now.\n\nData Availability §\nResearch §\n\nThe details of the Semi-AVID protocol have been studied, the relevant implementation has been reviewed, and the document prepared.\nThe benchmark document for the results of NomosDA and Semi-AVID has been prepared. Values for Semi-AVID have been calculated and added to the table. We also computed the values for NomosDA. Based on feedback received, the table will be updated and recreated in regard to the latest values.\n\nDevelopment §\n\nKZGRS certificate implementation (PR merged), including: Certificate implementation required for verifier and indexer services, adding of DST tag to Nomos spec and the implementation (Nomos spec PR merged) and VID and Metadata for KZGRS DA protocol.\nAdded DA Verifier service improvements (PR merged).\n\nPPoS/Consensus §\nResearch §\n\nExpanded/improved explanations of the results in the “Does Crypsinous Leader Election Function Lead to Wealth Concentration in PoS” document. Also provided a single Jupyter notebook to replicate all computations.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nCL use case implementation in Python: made some progress towards a 1 input, 1 output test case for CL. PR #93, but it’s not yet working. Certain CL design bugs were found during implementation, which led to changing some parts of the specification.\nMinor crisis on prover key sizes preventing thin clients from generating a transaction. But the general opinion is that what we settled on should work for us (lazy prover key derivation).\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nNomos node insights document has been updated with new details.\n\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-06-03":{"title":"2024-06-03 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nContinued with the analysis of random structures generated by the mix gadget and outlined two possible approaches to the analysis of mix gadget.\nExplained how the timing attack by a passive adversary can be simulated: Tracing back message flows. In short, we can simulate an adversary who traces back message flows to identify original message senders (i.e. block proposers) and repeats this multiple times to find senders selected more often. This is not the perfect way, but our opinion is that we can enhance this to simulate more powerful adversaries.\n\nDevelopment §\nData Availability §\nResearch §\n\nDA benchmarks: we are running benchmarks to compare vs SemiAvid - including: updating and running benchmarks according to needed and requested data and creating a calculator for nomos-da benchmark results. The results can be seen here and the DA calculator script can be seen here.\nTo continue on the point above, we have updated the main document and created separate sub-tables for NomosDA, Semi-AVID, and fk20. Benchmark results were entered into the tables for ANBC, RB, and CT, and general tables were created. Diagrams for the relevant tables were added to the document. Upon rechecking the results, it was observed that the values were consistent within themselves.\n\nDevelopment §\n\nNo updates this week\n\nPPoS/Consensus §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nPoC for CL specification: got the 1-to-1 transfer test running (and passing).\nThe python crypto library we’ve been using so far has been buggy and slow (as in > 1minute startup time and slow ecc math). Tests are very slow to run. Trying to swap it out for some other ecc library, issue is that a lot of the more obscure curves are not well supported in python.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nUpdate current testnet with missing configs for cryptarchia PR merged: After the introduction of Cryptarchia, Nomos testnet was missing some consensus configuration. Also, exposed required configuration as environment variable. We improved docker build times by defining common base image for Nomos node as well. Also included several minor fixes that were required to deploy on testnet.nomos.tech.\nAfter the review and report on the testnet state, refined the plan for this iteration.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-06-10":{"title":"2024-06-10 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nMixnet v2 Simulation: invested time to improve/simplify the passive adversary attacks before running simulations with various parameter sets. Also running the passive adversary simulation with various parameter sets to find the optimal parameters/designs (the result is not posted in Notion yet).\nIntroduced an attack that monitors nodes which emit messages at promised timing (i.e., block interval). The description can be found here. This attack is expected to be disrupted by adding cover traffic. The confirmation of this will come once we run the attack with different cover traffic parameters.\nOptimized the timing attack (tracing back message paths) and quantified its result, as posted here. The confirmation of this will come once we run this simulation with different parameters (number of layers and delays).\nFor the analysis of the mix gadget, we have followed the “conventional” mix model research path: considering the most general scenario when n nodes sample k paths from the set of all nodes in the network [N]. We assumed that each node samples ( r ) of such ( k ) paths. We have shown that a node in a ( k )-path is also participating in other ( r - 1 + c_i ) ( k )-paths. Here ( c_i ) is a random variable from the binomial distribution with parameters ( rn ) and ( \\frac{k}{N} ). For ( k \\ll N ) and ( N ) large, ( c_i ) is a random variable from the Poisson distribution with parameter ( \\frac{k r n}{N} ). On average, a node is participating in ( \\frac{k r n}{N} + r ) ( k )-paths. We calculated an upper bound on the probability that node connectivity deviates from this average by the amount of ϵ\\epsilonϵ. The summary can be found here.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nFinished the benchmark document and all results are documented here. We will continue with NomosDA.\nWe were having an issue with the roots of unity that didn’t allow us to use FFTs. After an org-internal talk, we solved the issue, and now it is working (the problem was that we were using the wrong generator that worked for everything except the FFTs).\nStarted implementing FFT in specs as it is highly needed for FK20.\n\nDevelopment §\n\nNo updates this week.\n\nPPoS/Consensus §\nResearch §\n\nImproved the results in the wealth concentration document.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nStarted to review the Plonky3 details (the notes can be found here). Generally, we can say it’s an improved version of Plonky2 in terms of prover time - meaning we can use it in situations where we need more efficient prover time. Initially, it was more appropriate to use Plonky2 because Plonky3 was still in development, but considering that Risc0 and Succinct have also started using it, we can consider using the Plonky3 protocol as well. In any case, it has advantages over Plonky2.\nOn the other hand, we haven’t found any disadvantages in Plonky3. We thought proof size might be an issue, but they mentioned that they could reduce the proof size using recursion. In this case, it seems logical to use it for inner proof, but the details need to be examined. Perhaps conducting a similar benchmark study for inner and outer proofs as we did for DA would be beneficial.\nAfter discussing the CL Architecture, the most recent design making use of message buffers is now described here: CL Architecture.\nAfter making the decision to rewrite the CL spec in Rust due to the lack of crypto libraries in Python, we decided to halt the spec work in favor of the CL architecture design work that was more pressing.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nResearch §\n\nFinished base insights structure document (after discussion) - for the time being though, since it’s probably going to be a living document.\n\nDevelopment §\n\n(WIP) Tested our GELF tracing subscriber and connected it to Graylog in the testnet: subscriber is implemented and sends logs to the provided Graylog endpoint. However, the Graylog instance is spawned in the testnet, but manual steps need to be taken during every redeployment, which is not acceptable.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-06-17":{"title":"2024-06-17 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nMixnet v2 Simulation: ran the passive adversary simulation and posted the result here. We can see that the accuracy of timing attack (by passive adversary) significantly decreases as the number of mix layers and cover traffic increase. Next, we need to analyze this result along with bandwidth usages to find the optimal parameters of cover traffic and mix layers.\nAnalysis of the mix gadget: For the analysis of random graphs, generated by random sampling of k-paths in the mix gadget, wrote an interpretation of the result of this analysis. Based on this, looked at a more optimal approach for anonymous communication family of random graphs - notes.\nUpdated the sparse network section of the Security of Mixing over Broadcasting Channel document, as well as the models and finished the global view section. In the document, we have discussed what can be observed without cover traffic in our scenario, the cover traffic design, and how the cover traffic impacts on the observer capabilities to link the traffic.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nStudied on the Henosis design and wrote notes on it. It’s a study related to combining heterogeneous proofs in proof aggregation - this may be used as an inspiration in Nomos. The [code](https://github.com/availproject/Henosis/tree/main ”https://github.com/availproject/Henosis/tree/main) is available on GitHub.\nFK20 running specification in python: added tests to double check that generated proofs are the same.\nFK20 implementation in python: implemented FFT methods and added FFT parallelization version.\n\nDevelopment §\n\nDA HTTP API and integration to the node is still in progress.\n\nPPoS/Consensus §\nResearch §\n\nImproved the results in the wealth concentration document.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nWe’ve restarted the CL executable specification in rust (PR). The following parts have been specified: notes, nullifiers, ptx input, ptx output, partial tx. Still remaining to be specified: tx bundle of ptx’s, birth/death constraints, integration with SP1 snarks.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nFinished the tracing subscriber and connected it to Graylog in the testnet: - PR merged.\nImplemented minor changes to the CI for the updated rust version: PR.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-07-01":{"title":"2024-07-01 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nStarted writing the new mixnet executable specs. Completed: Global transmission rate, Peering degree limit, Noise per connection, Gossip-based Sphinx routing. Still to do: Time mixing.\nWIP: Updating mixnet simulation according to the new specs. The plan is to finish the first working version by the end of this week. It’s taking more time than expected because of the attempt to have reusability between specs and simulation. Now the plan is clear.\nGathered the outcome of our discussions and design decisions from the offsite and compiled a document that outlines the design of our mixnet gadget. WIP: work on the queuing mechanism for the mixnet gadget, taking into account what corrupted nodes can learn.\nWith the assumption that the “Are continuous stop-and-go mixnets provably secure?” paper is state of the art, studied it in great depth to find out how anonymity guarantees are usually derived. For our case, the most useful definition from the aforementioned work is user unlinkability. However, it uses two senders and one receiver, but in our case, we have only one sender, i.e., the leader node, and one receiver node. The latter requires a new definition of sender unlinkability. The summary can be found here.\nAssuming that anonymity guarantees and statistical independence of nodes are related, considered an approach that studies various “correlation functions,” such as mutual information, Hamming distance, etc. This work will be carried on in this document.\nWIP: analysis of correlation functions.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nWIP: First iteration of the PoC can be found here. That PR already runs a libp2p inside a very basic DA node. It is important to mention that the very limited py-libp2p is not great software. The last official release is from 2020, and it had to be cloned from GitHub to make it work at all. Then, there was an issue with its internals: it’s highly opinionated. Tried to reuse existing py code from mixnet by using asyncio but py-libp2p would refuse to work with it due to the lib’s internal setup with trio. It is also important to mention that this is an exploration of the libraries; the team is yet to decide whether libp2p will be used at all.\n\nDevelopment §\n\nFinishing FK20 Rust implementation.\nIncluded FK20 in DA encoder (PR).\nAdded Rayon parallelization to DA encoder (PR).\nImplemented cache for Toeplitz part-1 and integrated it into the encoder (PR).\nAdded benchmarks and missing parallelization features (PR).\nDA subnetwork assignment algorithm: Implemented re-hashing algorithm and initial experiments. Tried to implement and improve a few variations of the algorithm, but none of them were better than the original. Ran a few experiments (results and ideas will be shared later on).\nWrapped up DA HTTP endpoints for KZGRS backend PR. Pushed changes related to DA HTTP endpoints. They are generic and should be reused with the updated KZGRS protocol and dispersal as a black box.\n\nPPoS/Consensus §\nResearch §\n\nWIP: produce and analyze more simulation results using the relativization algorithm, as stated in the wealth concentration document.\nThe protocols suggested by Ethereum for the proof of validator protocol have been reviewed. As stated in the article, the use of a Merkle tree could be slow for proof generation. Therefore, a zk-SNARK solution using a lookup table is considered to be more efficient. The related protocols are summarized step-by-step here. Additionally, the SemaCaulk design will also be examined. There is already Rust code available here, but it has not yet been audited. The related protocol will be examined in more detail and feedback will be provided.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nIntegrated the Proof of Equivalence document and validated the design. It seems that we now have a protocol that meets the requirements.\nThe StarkNet DA structure was reviewed again for Proof of Equivalence.\nWIP: continuing with the PoC, understanding whether Risc0 is a viable option (progress).\nIntegration of Risc0 zone PoC into CL note and partial tx model: we have the zone POC hooked into the CL UTXO model, but proof times are not where we want them. We are currently at 8 minutes to generate a proof, almost all of that is coming from the Pedersen commitment to the note value. All the work is being done in this PR.\nWIP: Trying to bring the death constraint proof time down to something manageable.\nEvaluation of SP1’s viability for CL: SP1’s outer proof takes 13 minutes to prove. The numbers were confirmed with SP1 devs. This is too slow for us to use. SP1 devs suggested they may support swapping out plonky3 for groth16; If they do that, we should re-evaluate.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nTestnet updates from the testnet branch now (deployments happen from the testnet branch) - Nomos PR, Infra PR. This is done to have more control over what runs in the testnet.\nEnabling/Disabling tracing using feature flags or config at runtime - PR. Added the ability to build the node without tracing, or toggle tracing via config if built with this feature.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-07-08":{"title":"2024-07-08 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nThe new mixnet executable spec is being updated in the PR #98 but has not been merged yet. The new spec will be reviewed for changes that need to be updated in the executable spec.\nUpdated mixnet simulation is in the branch of nomos-specs, a PR hasn’t been opened yet because additional team discussion is needed to check whether it meets our analysis requirements. A document has been prepared to explain what the simulation can do and how its result can be used. Based on this, we will discuss what needs to be done as the next experiment.\nUpdated mixnet gadget document with queuing designs: added a section about queuing mechanisms. There are two flavors, one is time bounded and another is time unbounded. Time unbounded is better from the privacy perspective as an adversary will not know any upper time limit during which a message is going to be propagated. Also presented two versions of the unbounded with discussion about the design properties and their impact on privacy.\nStarted working on the level 1 noise generation mechanism, it is sketched in the NomMix design already but requires more refinement. In short, the idea is to introduce another type of noise (cover traffic) that will be limited to some threshold (to protect the network from spam) and its generation will be incentivized to encourage nodes to send it.\nDiscussed how to proceed with simulations and analysis of the mixnet. One of the outcomes is a design of a new model that can be used to describe the network which is connection oriented (rather than node oriented) - more details in the point below.\nTo model communication in the network, considered two approaches: the “node-centred” and “connection-centred” . The former assumes that only the state of a node (such as sending, receiving, etc.) is observed and the latter assumes that also connection is observed. Also, considered Hamming distance as a measure of distance between systems with LEVEL 0 and LEVEL 0 + LEVEL 2 noises, i.e. the difference between a system which “communicates” and “doesn’t communicate”. This work is summarised in this document.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nWIP: (DA python PoC) Executor large number of persistent connections to remote host test - During the offsite, there were some concerns raised that the executor might not be able to keep a large number of open connections to remote hosts. A test using a python DA Node and Executor was performed, having the executor connecting to multiple instances of DA Nodes on a remote machine. Results need to be formally documented, but simple tests of pushing data over thousands of persistent TCP connections to a remote host succeeded on commodity hardware.\nWIP: (DA python PoC) PoC of Executor dispersal and sampling protocol for direct connections - A simple executor node is in progress - initially it was used for the connections feasibility test, now it’s developed further to work with the DA Node used in the subnet PoC.\nCreated the Runnable DA PoC Specification.\nUpdated the GitHub repo with current code (Status: Simple python DA nodes and simple python DA Executor implemented; executor can send packets) - WIP PR.\nTweaked the DA encoder benchmark to cross-check data & column sizes.\n\nDevelopment §\n\nNo updates this week.\n\nPPoS/Consensus §\nResearch §\n\nWIP: fixing a bug that was found in the wealth concentration code and producing and analyzing all simulation results again, based on the fix.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nCL PoC plan has been added to Notion.\nDid a few more prover optimizations in this PR.\nSummary of all the CL specs has been created.\nThe Caulk paper is being studied. The protocol is understood in general terms. The SemaCaulk definitions have been reviewed. A general description and protocol steps have been added for the related protocol here. Since KZG is used instead of a Merkle tree, proof calculations are faster. Creating a proof of set membership involves precomputation and quick proof generation. Precomputation can be done early and updated efficiently, while proof generation is fast and constant-time.\nResearch has been done on which other zkVMs could be tested for the CL. Also talked to external contributors to get a second opinion on the topic. Written the initial notes (not very detailed) about the related protocols here.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nPrepared Nomos Explorer architecture document.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-07-15":{"title":"2024-07-15 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nPR #98: Updated/refined the mixnet executable spec according to the newly written (WIP) spec. It’s being reviewed at the moment and is soon to be merged.\nPR #104: Modified the Sphinx encoding to support an arbitrary length of mix route and arbitrary maximum size of payload. Now we can let nodes select the length of mix nodes (not to exceed the max limit) and encapsulate a message larger than 1K (hardcoded in Loopix Sphinx) into a single Sphinx packet, while ensuring that all Sphinx packets have the same size.\nPR #105: Updated the simulation according to the newly written (WIP) spec. Also made it accept different randomness seeds for each module to make each of them deterministic independently. This is the first working version, which we can extend over and over.\nWorked on the level 1 messaging noise generation section, focused mostly on the motivational part at the moment. It’s noteworthy that the effectiveness of the mechanism is tightly coupled with the application of the queuing mechanism. Currently working on a better way of presenting the whole motivation. However, this does not block defining the noise generation mechanism, which is the next thing to do.\nLooked at ways to model the queuing mechanism (temporal mix). Our current approach is to treat it as a timed pool mix, which is well studied and provides us with analytical tools that we can use. However, later on, it was realized that it might not be the best model to use as we are deviating from a general mix to a task-specific mix which we might not be able to reflect using the timed pool mix. Nevertheless, it still looks like a good starting point that we can modify for our particular needs.\nReviewed mixnet gadget specification, and consequently decided on how to move forward with simulations and further implementation.\nStarted an analysis of the queuing system: in particular, considered the random process (outlined in this document) which governs the out-queue of a single connection. The latter is a variant of the pool mix and we have set up an analytical framework, based on previous studies such as the paper “Towards an Information Theoretic Metric for Anonymity,” which will allow us to study statistical properties of out-queues. The summary can be found in this document.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nPR #672: Added the verifier benchmarks. The data from benchmarks can be seen in this Notion document.\nWIP: Started the libp2p nomos DA subnetworks implementation document.\nPR #100, direct DA connection protocol: Defined the executor to DA node direct connection message types using protobuf. The code is targeting the da-poc branch in Nomos Spec to be used with subnets PoC.\nPR #99: Finalized the first version of the Runnable DA nodes PoC (ready for review).\n\nDevelopment §\n\nNo updates this week.\n\nPPoS/Consensus §\nResearch §\n\nAdded the Proof of Leadership specification to Notion. The first implementation in Circom, the one with sha256 (that didn’t take review into account) can’t be executed right now due to hardware requirements—however, this will be solved with the machine the team can now use. The implementation with the Anemoi hash function (that takes reviews into account => Taylor of order 2, more note inputs etc.) is not released yet.\nWIP: Finalizing studies 1 and 2 of the wealth concentration work. Results and report about wealth concentration can be found here but still not in a readable format.\nWIP: Continued implementing the Python code to analyze the selfish behavior when choosing the fork rule. This is created by adapting the Cryptarchia spec from the nomos-spec repository.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nHad a deep dive into Preconfirmations and Based Sequencing and created this document based on it.\nPR #102: Implemented the nullifier proof (as part of the implementation of the user side of the cross zone atomic transfer PoC).\nPR #103: Set up the infrastructure for using risc0 for CL proofs and integrating the nullifier proof from PR #102 with the CL. The nullifier proof takes about 5 seconds on a local MacBook (without Groth16 wrapping).\nWIP: Started a design of a trustless bridge for user-zone funds.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nPR #673: Added a base debug span, consensus, and da-verifier span for tracing logs.\nInvestigated minor CI issues and made a temporal fix for Nomos Node to build with libp2p and rustls (discussion in the relevant PR #673). For now, the rustls version is pinned, will be reverted after this issue is resolved.\n\nUser Tools §\nResearch §\n\nStarted the nomos-lib document (main document to abstract what we need for different binaries external to the nomos-node).\nStarted the nomos-cli document (first approach to interact with the nomos network).\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nListed future research projects, as Key Differentiators of Nomos vs other projects, document.\nUpdated the nomos-pm repository issues for the insights dashboard.\n"},"nomos/updates/2024-07-22":{"title":"2024-07-22 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nAll new mixnet-related PRs in the nomos-specs have been closed. New PRs will be opened once we’re ready to write the technical specs.\nSimulations are now being added in the nomos-simulations repository.\nPR #6: The initial mixnet simulation is ready to be reviewed. This PR has some missing pieces that will be added in the next PRs (to make the PR smaller and easily check if the simulation works correctly).\nPR #7: Now using gossiping for broadcasting after mix.\nPR #9: Added dissemination time measurement.\nUpdated the Noisy lottery section and worked out the details of the level 1 messaging noise generation mechanism, with a collection of algorithms that gradually build up the complexity.\nAs a result of the process of reducing complexity and clarifying the objectives of what we want to analyze and simulate, written a dictated subsection for simulation and analytics for the queuing mechanism.\nAnalysis of the queuing system in the Nomos Mixnet node: considered a queue of messages where a message is removed with probability q from the queue, i.e. the “coin-flipping”. The number of attempts to remove a message from the queue follows a Geometric distribution with parameter q. The latter was verified by simulation of random sampling. Based on this, it follows that a message is delayed in a node by at least RΔ, where Δ is some constant related to the implementation of the queue, with probability (1-q)^R. The summary can be seen here.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nPR #100: Direct DA connection protocol - added session control message type, simplified Dispersal and Sample error messages. This has been merged into the da-poc branch, it’s now in the nomos-poc repo.\nPR #5: DA feasibility test for a large number of UDP connections - investigated how a large number of connections would affect different network topologies.\nPR #6 (moved from nomos-specs): Finalized and merged the PoC PR. Based on this, the documentation has been updated accordingly.\n\nDevelopment §\n\nNo updates this week.\n\nPPoS/Consensus §\nResearch §\n\nThe first version of the Proof of Validator has been prepared in this document.\nWIP: Finalizing studies 1 and 2 of the wealth concentration work (wasn’t able to do it last week because the simulations took way longer than expected). Results and report about wealth concentration are here but still not in a readable format.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nFinalized the Proof of Leadership specification with error analysis.\nPR #3 added - for Proof of Leadership circuits (in circom).\nPR #106: Defined and implemented the input proof. The input proof verifies the statement that the ptx input has a valid nullifier, the balance commitment was computed correctly, and reveals a death commitment that was used to spend the note.\nPR #4: Balance commitments had a design bug that had broken input/output unlinkability, now resolved.\nPR #7: Transfer PoC. This introduced 2 more types of CL proofs: Output and Bundle proofs. Also built up the proof infra around this to allow constructing a fully proved transfer transaction that could be placed on chain.\nPR #2: Defined and implemented the first version of zone funds death constraints.\nExpanded the Preconfirmations and Based Sequencing document with new research.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-07-29":{"title":"2024-07-29 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nRan the initial simulation to compare queuing mechanisms, but found that it’s better to design a specifically targeted simulation (which focuses only on queuing mechanisms) instead of using the full-cycle simulation (which simulates the full features of the protocol).\nWe prepared the simulation strategy, and simplified the simulator according to the strategy (maximizing code reuse). The simulation results can be found in the Queuing Mechanism: Message Dissemination Time Experiments, though this report is not the final version. The result consists of the largest set of data (It took 48h+). More analysis needs to be done on the result data to make a decision on the queuing mechanism and recommended parameters. So far, we found that the Noisy Coin Flipping Queue shows the optimal dissemination time compared to other queuing mechanisms, but we don’t want to jump to conclusions. Other aspects besides dissemination time need to be tested.\nIn the process of enabling better progress with simulations and analytical work, wrote a methodology document that will guide our efforts in understanding the queueing mechanism’s impact on the network and its general properties.\nAnalysis of the queueing system in the Nomos Mixnet node: considered a message going through k nodes where the queuing system of each node delays the message. Assuming that a message is removed with probability q from the queue, the probability distribution of the total delay is the negative binomial. From this follows that the average total delay is \\frac{k}{q}​. Calculated the upper bound on the probability that the total delay is greater than the average \\frac{k}{q} by the factor 1 + \\epsilon. The upper bound suggests that the mentioned probability is a monotonic decreasing function of k, q, and \\epsilon. The aforementioned work is summarized in Notion.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nDraft version of DA technical specification added.\n\nDevelopment §\n\nPR #678 DA Protobufs: DA Prost integration merged - generates rust structures for protofiles as a build step.\nPR #681 DA Protobufs: DA Network message types merged - Dispersal, Replication, and Sampling protocols defined as protofiles and exposed as a module in nomos-da/network/messages.\nPR #679 CI Improvements - DA Indexer integration tests improvement merged - Integration test now better determines when to expect a specific blob_id in a block received via the network. This test will be used with the new DA dispersal protocol.\nResearching attacks on DAS; understanding better the interactions between DAS and consensus, MEV, and the properties of our current design - summary.\nPR #680 - started implementing DA network stack: sketched up crates, created basic structure for 3 subprotocols (dispersal, replication, sampling), implemented Replication subprotocol (non-working, we have a bug). Also added base contract for the DA networking layer on the nomos node. That way we can start integrating it into the DA services.\nPR #683 - added DA network adapter trait in mempool (first step in adapting the mempool to continuously sample and verify).\n\nPPoS/Consensus §\nResearch §\n\nPR #10 - 1st Proof of Validator PR in Circom with Merkle tree.\nExtended the Proof of Validator specification.\nContinuation on reporting on studies 1 and 2 of the wealth concentration work (also redoing certain figures and improving the way results are compared) - results and report are getting in shape.\nPR #9 - Proof of Leadership spec implementation in risc0.\nWorked on the Caulk library to understand the details of the Caulk Rust implementation. There was an error when the prover was run multiple times during the proof verification process. This error was fixed. Additionally, benchmarked the proof and verification performances for different elliptic curves. The results are added to the spec document.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nThe circuit design and details used in the Zcash spec were reviewed. Sprout and Sapling circuits are older designs. The Orchard circuit is the most current version, and its cryptographic structure is already the design we are using as a reference. Relevant notes were added to this document.\nPR #8 - Nomos native zone deposit tx.\nWIP: Nomos native zones bridge deposit.\nPR #11 - added death constraints to the transfer scenario; in this scenario, we don’t do any interesting account abstraction so the death constraints are proofs of no-ops. With this change, CL is “feature complete” for the purposes of the PoC.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nPR #682 CI Improvements - Protoc build deps for testnet and Jenkins CI merged.\nPR #684 Rust 1.80 (opened, not merged yet) - added an allow[dead_code] for Nonce in consensus for Clippy. Unused methods in da libp2p will be handled in separate PRs.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-08-05":{"title":"2024-08-05 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nNomos Mix simulations: message dissemination time by queue type - Session 1: Measured message dissemination time using 20~80 number of nodes, for each 5 queue types. Noisy Coin-flipping queue shows the lowest dissemination time when there are less number of real messages flown in the network, but shows the worst, if not. Random Sampling queue or Permuted Coin-flipping queue show around 2x longer dissemination time compared to the Non-mixing queue, but the performance degradation is relatively low, as the number of real messages increase. This is the initial interpretation of the result, which we can’t make a conclusion based on.\nNomos Mix simulations: message dissemination time by queue type - WIP: Session 2: This experiment is still running. This runs more nodes (100~10000) than the session 1, to see how each queue performs in the larger network. Also preparing next experiments: measuring how long messages stay in the queue.\nExtended the methodology document with more parameters for message dissemination experiments. Found one paper that measures properties of the Monero network which also include the node connectivity levels, an extract of it can be found here.\nDesigned another type of experiment, that is devoted to observing the quality of “temporal mixing” for a single node on a single path. The results of which will give us better understanding of the predictability of delaying of each of the queues and guide our decision during the selecting process.\nThe results for the first session of simulations give some intuition about the impact of each of the parameters on the dissemination time. However, it’s too early to conclude as the quality of mixing is another part of the equation and it’s our main focus now.\nStarted looking at the payment mechanism for the mixnet.\nAnalysis of the queueing system in the Nomos Mixnet node: considered the FIFO (First In First Out) attack where two sender nodes send messages through k mix nodes to the receiver node. The latter is controlled by an adversary which is also capable of observing other nodes. For a mix node where a message is removed from its out-queue with probability q, derived an expression for the probability of success of the FIFO attack. This probability can be computed numerically by creating a large population of random variables (wrote a code for the latter). Using this framework, showed that the probability of success of the FIFO attack is a monotonic decreasing function of the number of mix nodes k and is bounded from below by ½. Also showed that having different q parameters for sender and mix nodes can reduce the probability of success of the FIFO attack. Finally, showed that heterogeneous latencies of connections can increase the probability of success of the FIFO attack.\n\nDevelopment §\n\nPrepared the engineering PoC in Notion.\n\nData Availability §\nResearch §\n\nDA technical specification has been updated.\n\nDevelopment §\n\nPR #686: DA BlobInfo instead of Certificate - Removed Certificate and Attestation definitions, introduced DispersedBlobInfo trait and implementations. Also updated the DA mempool, integration tests and other components to use BlobInfo.\n(WIP) DA Mock network service for CLI app: still in progress preparing various components for the updated CLI App.\nPR #685 - finished implementing/fixing the DA network replication layer.\n(WIP) Started implementing the DA network dissemination layer - finished the validator behaviour and started the executor behaviour.\n\nPPoS/Consensus §\nResearch §\n\nFinalized the Proof of Validator specifications.\nPR #10 - 2nd Proof of Validator in Circom with Caulk.\nThe implementation for the Caulk usage scenario was prepared, and the results were added to the document.\nStarted analyzing the usage of the PoL as a PoV.\nFinalizing reports 1 and 2 of the wealth concentration work: the results are mostly in shape.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nPR #17: integrate the zone withdrawal logic with CL ptx/note structure.\nPR #13: users could create as many zero-valued outputs as they’d like without affecting the balance of a partial tx, the implications of this was not clear so we decided to ban zero-valued outputs for now until we understand what is going on.\nPR #14: boilerplate for the user atomic transfer ptx.\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/2024-08-12":{"title":"2024-08-12 Nomos weekly","links":[],"tags":["nomos-updates"],"content":"P2P Privacy §\nResearch §\n\nImproved the simulation to avoid out-of-memory (OOM) issues—an unexpected bug. If we run heavy simulations with 90+ processes on the server, the total usage of system memory is very high, and OOM occurs after 10+ hours. We modified the handling of intermediate results to minimize memory usage.\nMeasuring the Message Dissemination Time by Queue Type (Session 2.1) - because the session 2.1 simulations are too slow, we are profiling the internal behaviour of the simulation to find if something is wrong. So far, everything looks fine. The amount of computations looks correct. But, there are still more things that we need to check at the moment.\nWorking on reducing the time complexity of the experiments from the parameters perspective and prepared reduced parameters for session 2, called 2.1. Afterwards, designed Session 3, and Session 4 for evaluating the behavior of a node with non-homogeneous peering degree. Finally, defined experiment 5 which should deprecate all previous experiments as it simulates most closely the behavior of the network. Relevant document.\nDesigned a responsive version (two flavors) of the queuing mechanism, that alters the probability of releasing the message from the queue when the same message is received from another queue by the node. This is a more elegant solution which should deprecate all others if performing well (delay and statistically wise). Relevant document.\nStarted drafting some high-level requirements for the pay-per-mix design. Heavy work in progress - relevant document.\nAnalysis of the queuing system in the Nomos Mixnet node: continued with the analysis of the FIFO (First In First Out) attack where two sender nodes, observed by an adversary, send messages through kkk mix nodes to the receiver node, corrupted by the adversary. Considered a scenario when a message is delayed by the sender node by 1qS\\frac{1}{q_S}qS​1​ (on average) and by the mix node by 1qM\\frac{1}{q_M}qM​1​ (on average). Here qSq_SqS​ and qMq_MqM​ are, respectively, probabilities of removing a message from the out-queue of sender and mix nodes. Computed the probability of success of the FIFO attack for different ratios ρ=qSqM\\rho = \\frac{q_S}{q_M}ρ=qM​qS​​. The probability of success of the FIFO attack approaches the lower bound 12\\frac{1}{2}21​, where the adversary doesn’t have any advantage over random guessing, with an increasing number of mix nodes kkk much faster for higher values of ρ\\rhoρ. However, even for higher values of ρ\\rhoρ the probability of success of the FIFO attack is increasing if the difference in latencies of connections, of two sender nodes to the first mix node, is greater than some threshold. This work is summarized in this document.\n\nDevelopment §\n\nNo updates this week.\n\nData Availability §\nResearch §\n\nUpdated the DA Technical Specification.\n\nDevelopment §\n\nPR #688 - Finished implementing/fixing the DA network dispersal layer: implemented executor behavior, implemented validator behavior and implemented interaction test for both behaviors.\n(WIP) PR #689 - Finished implementing/fixing the DA network sampling layer.\n(WIP) PR #690 - DA Mock network service for CLI app: all parts (services, adapters, etc.) are defined and interconnected, finishing up mock implementations. Progress is a bit slower than initially anticipated with the CLI App.\n\nPPoS/Consensus §\nResearch §\n\nConcluded that Caulk is not that interesting for improving proof of membership.\nFinalized the section about “Follow the Protocol” on the wealth concentration work.\nDropped the analysis of the PoV based on PoL analysis.\nPoV spec: The main motivation for implementing Caulk was its fast update process. We examined how many operations are required for Merkle-tree updates at specific depths and compared this with point addition and multiplication on the Caulk side. For Caulk, if the updates are to be made, this value is added linearly to the process, whereas this isn’t necessary for Merkle-tree. It was observed that at 2122^{12}212 notes, the values are almost equal, and even at 2202^{20}220 notes, the difference isn’t significant. For this reason, we agreed that itisn’t necessary to spend too much time on Caulk. Additionally, for Caulk, the proof of Pedersen equivalence would also disadvantage us in terms of proof size and constraints. The spec work for PoV has been completed. This is the latest version using a Merkle tree.\n\nDevelopment §\n\nNo updates this week.\n\nCoordination Layer §\nResearch §\n\nPR #15 - Added strong zone notes validation by zone ID.\nPR #16 - Added metadata to zone notes to allow for correct funds/state note validation.\nPR #19 - Refactored zone auth.\nPR #20 and PR #22 - Added support for atomic transactions.\nCreated a table for notable zkVMs in the literature, currently filling in the details by reviewing the designs.\nAdded the necessary details and definitions for ZCash in the relevant document.\nPR #21 - Integrated the zone deposit scenario.\nPR #23 - User side of the atomic transfer transaction.\nPR #24 - Full atomic transfer transaction.\nWith the previous three PRs (in combination with previous work), we’ve got the full atomic transfer transaction working end-to-end! We still need to do some performance work to ensure executors can build a transaction within the 20s target block time (current proof time is ~400s).\n\nDevelopment §\n\nNo updates this week.\n\nTestnet + Insights §\nDevelopment §\n\nNo updates this week.\n\nUser Tools §\nResearch §\n\nNo updates this week.\n\nDevelopment §\n\nNo updates this week.\n\nMiscellaneous §\n\nNo updates this week.\n"},"nomos/updates/Athens-Offsite-Notes":{"title":"Athens Offsite Notes","links":[],"tags":["nomos-updates","athens-all-hands"],"content":"Research §\nThe Nomos team has attended several meetings with different teams and internally. Most of these have been in terms of finding the right solutions for the Coordination layer, including but not limited to:\n\nProof aggregation techniques\nZK commitment schemes\nCL Inter-zone communication\nBridges\n\nBased on these discussions, we have compiled a preliminary version of the Coordination Layer Specification. There are still unknowns in this line of work, but we are of a unified mind that we are on the right track.\nEngineering §\nAt Nomos, there are some needs that could be covered by Vac. To be more precise: understanding on what Vac provides that could be helpful, understanding what is required for Vac to start on that support, a plan/pipeline for both teams to interact. Some of the proposals:\nDST:\n\nAt the moment, the most prominent project is the analysis of the Nomos mixnet.\nThis will serve as the first project interaction as it is also the highest priority.\nOngoing conversations on what is needed are already in place.\n\nQA:\n\nNomos node is in high need of a testing plan. But no real bandwidth for it.\nVac has specialized people with the experience and the workforce.\nCryptarchia and NomosDA would be the focus. But this is gonna be delayed until seen how the mixnet collaboration goes.\nAs part of this specifications will be reviewed by the Vac team so they can be improved. Eventually specifications will be forked and served as part of Vac too.\n\nComms §\n`Key Market Trends / Research §\nPrivacy Concerns:\n\nBuilding our case for privacy our protection and viability of the project. We need to define the terms of privacy and create that shield. Privacy is necessary for personal items to be possible, health, business, institutions. \n\nTechnical Narratives:\n\nLitenodes. Rules without a ruler\nData Availability Sampling\nRestaking\n\nDecentralisation \n\nWe can be more decentralised than any other blockchain ever. \n\n`Technical Milestones §\nProduct Development\n\n1st Milestone: Dark paper release, with a potential litepaper version.\n2nd Milestone: Testnet\n\n`Growth Plan  §\nTarget Audience: \n\nDegens: Refine for those who care and believers.\nInstitutions: Long term\nDevelopers/Contributors\nNode Operators: Long term.\n\nMovement Building (Community) - Educational Initiatives: \n\nRoles for incentivising culture, memes.\nAmbassador program\nDeveloper Outreach\n\nIncentive Programs \n\nLogos NFTs\nWhen we have zones we can get them to deploy during hackathons?\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/consulting/codex/proxy-re-encryption":{"title":"proxy-re-encryption","links":[],"tags":[],"content":"vac:acz:consulting:codex:proxy-re-encryption §\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 Proxy Re-Encryption: , 2024-05-27, 2024-09-30\n\n\nstatus: 50%\nCC: Ramses + 1\n\nDescription §\nTo embed and assist codex with their proxy re-encryption primitive.\nJustification §\nProxy re-encryption is necessary to provide plausible deniability to storage providers.\nDeliverables §\n\n A Document describing possible solutions: https://www.notion.so/Approaches-to-plausible-deniability-87c6fef92df946fcbc1327d51d936ce1?pvs=4\n Agreement and hardening of specification for the Codex team\n"},"vac/acz/consulting/nescience/zk-consulting":{"title":"Nescience ZK Consulting","links":[],"tags":[],"content":"vac:acz:consulting:nes:zk-consulting §\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 Nescience ZK Consulting: , 2024-01-01, 2024-12-31\n\n\nstatus: 30%\nCC: Ugur\n\nDescription §\nTo assist the Nescience team with their ZK needs.\nJustification §\nUgur has the expertise to assist Nescience with their zk research tracks.\nDeliverables §"},"vac/acz/consulting/nomos/init":{"title":"init","links":[],"tags":[],"content":"init cryptography consulting for nomos"},"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/waku/rlnv2-e2e","vac/acz/rlnp2p/vac/rln-doc-and-outreach","vac/acz/rlnp2p/vac/light-rln-verifiers","vac/acz/rlnp2p/vac/rln-light-clients","vac/acz/rlnp2p/status/rln-usage","vac/acz/zerokit/vac/zerokit-v0-4","vac/acz/zerokit/vac/zerokit-v0-5","vac/acz/zerokit/vac/maintenance","vac/acz/secure-channels/waku/mls-design","vac/acz/secure-channels/waku/mls-poc","vac/acz/secure-channels/waku/fd-design","vac/acz/secure-channels/waku/fd-poc","vac/acz/consulting/codex/proxy-re-encryption","vac/acz/consulting/nomos/init","vac/acz/consulting/nescience/zk-consulting","vac/acz/stealth-address-kit/maintenance","vac/acz/stealth-address-kit/research","vac/acz/validator-privacy/nimbus/productionize-tor-push"],"tags":["acz","vac"],"content":"vac:acz: §\n\nrlnp2p:waku: §\n\n production-readiness\n rln-membership-management\n rln-relay-enhancements\n rln-relay-enhancements_02\nrln-relay-erc20\n\n\n rlnv2-relay-integration\n\n\n rln-multi-epoch-constraints\n rlnv2-e2e\n\nrlnp2p:vac: §\n\n rln-doc-and-outreach\n light-rln-verifiers\n rln-light-clients\n\nrlnp2p:status: §\n\n rln-usage\n\nzerokit:vac: §\n\n zerokit-v0.4\n zerokit-v0.5\nmaintenance\n\nsecure-channels:waku: §\n\n mls-design\n mls-poc\n fd-design\n fd-poc\n\nconsulting:codex: §\n\n proxy-re-encryption\n\nconsulting:nomos: §\n\ninit\n\nconsulting:nes: §\n\n zk-consulting\n\nstealth-address-kit:vac: §\n\n maintenance\n research\n\nvalidator-privacy:nimbus: §\n\n productionize-tor-push\n"},"vac/acz/rlnp2p/status/rln-usage":{"title":"Status RLN Usage","links":[],"tags":[],"content":"vac:acz:rlnp2p:status:rln-usage §\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 Usage: , 2024-05-13, 2024-06-13\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\nTo describe an end-to-end user flow for a new user of the status app on how they can acquire an RLN membership.\nJustification §\nStatus will use RLN in the future, and we must first consult them on how to use it for seamless integration.\nDeliverables §\n\n Document describing end-to-end user flow\n"},"vac/acz/rlnp2p/vac/light-rln-verifiers":{"title":"Light RLN Verifiers","links":[],"tags":[],"content":"vac:acz:rlnp2p:vac:light-rln-verifiers §\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 Light RLN Verifiers: done, 2024-03-01, 2024-05-01\n\n\nstatus: 100%\nCC: Aaryamann\n\nDescription §\nMake use of cryptography techniques to improve trust assumptions and reduce off-chain complexity while verifying RLN proofs.\nJustification §\nA node attempting to verify RLN proofs takes nearly ~10 minutes to sync all the leaves. We should explore cost-effective solutions to make the root of the tree accessible onchain.\nDeliverables §\n\n PoC using tiered commitment trees: https://github.com/vacp2p/rln-contract/pull/37\n Deployed to sepolia and load tested: https://sepolia.etherscan.io/address/0xE7987c70B54Ff32f0D5CBbAA8c8Fc1cAf632b9A5\n Ethresearch post: https://ethresear.ch/t/tiered-commitment-trees-to-reduce-gas-costs-and-offchain-complexity/19484\n Vac forum post: https://forum.vac.dev/t/light-rln-verifiers-using-a-tiered-commitment-tree/290\n Vac blog post: https://vac.dev/rlog/rln-light-verifiers/\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-08-01, 2024-12-31\n\n\nstatus: 100%\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 §\n\n talk at progcrypto on RLN: https://www.youtube.com/watch?v=7xDxv8F70Jg&pp=ygUOcHJvZ2NyeXB0byBybG4%3D\n presented rln: zero to hero to nwaku+chatsdk team @ status all hands, explained all versions of rln and their trade-offs\n\n\n blog post/RFC on Light RLN verifiers: https://github.com/vacp2p/vac.dev/pull/136\n updated docs for rln-relay in nwaku-compose: https://github.com/waku-org/nwaku-compose/pull/52\n Present rln-v2 and v3 at logos research call: https://docs.google.com/presentation/d/1lcE5E3WKenueIULR_rhjtZU8Tdqv-7sPr6lpXPTaQSk/edit?usp=sharing\n RLN rlog on vac.dev: https://vac.dev/rlog/rln-anonymous-dos-prevention\n"},"vac/acz/rlnp2p/vac/rln-light-clients":{"title":"RLN Light Clients","links":[],"tags":[],"content":"vac:acz:rlnp2p:vac:rln-light-clients §\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 Light Clients: done, 2024-04-01, 2024-05-01\n\n\nstatus: 100%\nCC: Aaryamann\n\nDescription §\nMake use of zk-kit’s LazyIMTto have the merkle proof of a leaf accessible onchain, and the root as well, to allow for light rln provers and verifiers.\nJustification §\nA node attempting to verify RLN proofs takes nearly ~10 minutes to sync all the leaves. We should attempt to see if it is cheap enough to use the LazyIMT structure so that we can have the merkle proof accessible onchain.\nDeliverables §\n\n PoC (rln-v1): https://github.com/vacp2p/rln-contract/pull/31\n Deployed to cardona zkevm testnet: https://cardona-zkevm.polygonscan.com/address/0x16abffcab50e8d1ff5c22b118be5c56f801dce54\n PoC (rln-v2): https://github.com/vacp2p/rln-contract/pull/39\n Downstreamed to waku-rln-contract to estimate gas: https://github.com/vacp2p/rln-contract/pull/38\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nRLN VersionGas estimate for insertionrln-v190krln-v1 (lazyIMT)130krln-v2135krln-v2 (lazyIMT)210k"},"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 Status\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 Status\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: 90%\nCC:\n\nRamses\nAaryamann\n\n\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 §\nDynamic epoch sizes are required for users who have smaller messaging needs, to optimize for stake used.\nrln-v3 will allow that.\nDeliverables §\n\n design document: https://www.notion.so/rln-v3-PoC-b05af585f52f4b15a249184d4a627096\n PoC: https://github.com/vacp2p/gnark-rln/blob/9b05eddc89901a06d8f41b093ce8ce12fd0bb4e0/rln/rln.go\n blog post/ethresearch crosspost\n"},"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 Status\n\t\tRLN-RELAY enhancements :done, 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_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\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tRLN-RELAY enhancements 02:done, 2023-09-01, 2023-11-30\n\t\t\n\n\nstatus: 100%\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-e2e":{"title":"RLN v2 E2E integration","links":[],"tags":[],"content":"vac:acz:rlnp2p:waku:rlnv2-e2e §\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\tRLN v2 e2e Integration : , 2024-05-20, 2024-06-20\n\n\ndue: 2024-06-20\nstatus: 90%\n\nDescription §\n\n Come up with final gas estimation after the optimizations (RLN v2 + RLN in resource-restricted)\n Deliver end-to-end PoC working in The Waku Network showcasing the new features.\n Bug fixes found along testing\n New smart contract with both RLNv2 and RLN in resource-restricted clients changes.\n Deploy and consider using a L2 testnet.\n Deprecate tree sync in nwaku\n\nGoal §\nRun RLN relay v2 on TWN.\nDeliverables §\n\n https://github.com/waku-org/pm/issues/168\n https://github.com/waku-org/nwaku/issues/2758\n"},"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:done, 2023-11-01, 2024-02-29\n\n\nstatus: 100%\nCC: Aaryamann\n\nDescription §\n\nalso involves\n\nTKE\nimplemenations in various Waku versions\n\n\n\nJustification §\nrln-v2 brings multi message per epoch signaling which is favourable for all users of rln instead of abiding by one global rate limit.\nDeliverables §\n\n https://github.com/waku-org/nwaku/issues/2345\n"},"vac/acz/secure-channels/waku/fd-design":{"title":"Secure Channels - fully decentralized design","links":["vac/acz/secure-channels/waku/mls-design"],"tags":[],"content":"vac:acz:secure-channels:waku:fd-design §\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 FD Design: 2023-04-29, 2024-12-15\n\n\nstatus: 5%\nCC: Ramses, Ugur\n\nDescription §\n\nfollow up of mls-design\n\nWhile MLS, an established protocol, allows us to quicker release a secure key setup protocol with an Ethereum authenticator,\nMLS is federated in nature and makes reliability assumptions in regards to the underlying message dissemination layer.\nWe work towards mitigating this using on-chain components in the planned deliverables for the milestone linked above.\nHowever, we still desire a fully decentralized version that ideally does not require an on-chain component.\nThis Milestone tracks this effort.\nJustification §\nDeliverables §\n\nspecification (RFC)\n"},"vac/acz/secure-channels/waku/fd-poc":{"title":"Secure Channels - PoC of fully decentralized protocol","links":["vac/acz/secure-channels/waku/fd-design"],"tags":[],"content":"vac:acz:secure-channels:waku:fd-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 FD PoC: 2024-12-01, 2025-06-30\n\n\nstatus: 0%\nCC:\n\nDescription §\n\nPoC implementation of fd-design\n\nJustification §\nDeliverables §"},"vac/acz/secure-channels/waku/mls-design":{"title":"Secure Channels - MLS design","links":[],"tags":[],"content":"vac:acz:secure-channels:waku:mls-design §\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: done, 2023-09-12, 2024-05-31\n\n\nstatus: 100%\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\n https://github.com/vacp2p/rfc-index/blob/main/vac/raw/eth-secpm.md (specification)\n"},"vac/acz/secure-channels/waku/mls-poc":{"title":"Secure Channels - MLS PoC","links":["vac/acz/secure-channels/waku/mls-design"],"tags":[],"content":"vac:acz:secure-channels:waku:mls-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 MLS PoC: done, 2024-04-29, 2024-07-15\n\n\nstatus: 100%\nCC:\n\nEkaterina\nAaryamann\n\n\n\nDescription §\n\nproof of concept implementation of mls-design\nrepo: https://github.com/vacp2p/de-mls\nissues:\n\nhttps://github.com/vacp2p/de-mls/issues/1\nhttps://github.com/vacp2p/de-mls/issues/2\nhttps://github.com/vacp2p/de-mls/issues/3\n\n\n\nJustification §\nDeliverables §\n\nEngineers implementing the researchers advice on how to proceed with the PoC\n\n https://github.com/vacp2p/de-mls/issues/1\n https://github.com/vacp2p/de-mls/issues/2\n https://github.com/vacp2p/de-mls/issues/3\n https://github.com/vacp2p/de-mls/issues/4\n https://github.com/vacp2p/de-mls/issues/5\n https://github.com/vacp2p/de-mls/issues/6\n\n\n"},"vac/acz/stealth-address-kit/maintenance":{"title":"Stealth Address Kit Maintenance","links":[],"tags":[],"content":"vac:acz:stealth-address-kit: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 Stealth Address Kit Maintenance: , 2024-02-01, 2024-12-31\n\n\nstatus: 80%\nCC: Aaryamann\n\nDescription §\nContinue supporting and maintaining the stealth-address-kit repo.\nJustification §\nThis will be a viable privacy solution for status (private transfers) and waku (rln membership insertion)\nDeliverables §\n\n rename erc-5564-rs to stealth-address-kit\nThe following releases have been made -\n\n https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.3.1\n https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.2.0\n https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.1.0\n\n\n"},"vac/acz/stealth-address-kit/research":{"title":"Stealth Address Kit Research","links":[],"tags":[],"content":"vac:stealth-address-kit:research §\n\n\nnote: there is no gantt chart for this milestone\n\nDescription §\nFurther the research of the stealth address scheme and collaborate with EF researchers to do so.\nJustification §\nThis will be a viable privacy solution for status (private transfers) and waku (rln membership insertion)\nDeliverables §"},"vac/acz/validator-privacy/nimbus/productionize-tor-push":{"title":"Productionize Tor Push in Nimbus","links":[],"tags":[],"content":"vac:acz:validator-privacy:nimbus:productionize-tor-push §\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 Productionize tor push: , 2024-05-13, 2024-08-13\n\n\nstatus: 0%\nCC: Aaryamann\n\nDescription §\nTo make the tor push feature as accessible as running --tor-push:true while running a nimbus validator.\nJustification §\nImproved privacy guarantees for ethereum validators\nDeliverables §\n\n TBD\n"},"vac/acz/zerokit/vac/maintenance":{"title":"maintenance","links":[],"tags":[],"content":"ongoing: zerokit maintenance"},"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 Status\n\t\tv0.5 Release: done, 2023-10-01, 2024-06-01\n\n\nstatus: 100%\nCCs:\n\nEkaterina\nAaryamann\n\n\n\nDescription §\n\nRelease Planning issue: https://github.com/vacp2p/zerokit/issues/237\n\nDeliverables §\n\n https://github.com/vacp2p/zerokit/pull/239\n https://github.com/vacp2p/zerokit/pull/242\n https://github.com/vacp2p/zerokit/pull/243\n https://github.com/vacp2p/zerokit/pull/245\n https://github.com/vacp2p/zerokit/pull/246\n"},"vac/dr-ice/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-ice/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-ice/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-ice/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-ice/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-ice/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-ice/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-ice/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-ice/index":{"title":"Deep Research Service Unit - Icebox Milestones","links":["vac/dr-ice/valpriv/vac/tor-push-rln","vac/dr-ice/valpriv/vac/priv-validator-network","vac/dr-ice/valpriv/vac/mix-net-solution","vac/dr-ice/valpriv/nomos/validator-privacy","vac/dr-ice/consensus/nomos/carnot-paper_02","vac/dr-ice/consensus/nomos/carnot-bribary-article","vac/dr-ice/consensus/nomos/carnot-2-3rds-vote-aggregation","vac/dr-ice/consensus/nomos/blockchain-security-in-crypto-economic-models","vac/dr-ice/consensus/nomos/detecting-reporting-attacks-carnot","vac/dr-ice/consensus/nomos/stake-privacy-timing-attacks","vac/dr-ice/consensus/nomos/inter-chain-protocol","vac/dr-ice/consensus/nomos/multi-leader-and-multi-overlay-carnot"],"tags":["dr","vac"],"content":"vac:dr:valpriv:vac: §\n\ntor-push-rln\npriv-validator-network\nmix-net-solution\n\nvac:dr:valpriv:nomos: §\n\nvalidator-privacy\n\nvac:dr:consensus:nomos: §\n\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"},"vac/dr-ice/valpriv/nomos/validator-privacy":{"title":"validator-privacy","links":[],"tags":[],"content":""},"vac/dr-ice/valpriv/vac/mix-net-solution":{"title":"mix-net-solution","links":[],"tags":[],"content":""},"vac/dr-ice/valpriv/vac/priv-validator-network":{"title":"priv-validator-network","links":[],"tags":[],"content":""},"vac/dr-ice/valpriv/vac/tor-push-rln":{"title":"tor-push-rln","links":[],"tags":[],"content":""},"vac/dr/anon/vac/gossipsub-anonymity":{"title":"Gossipsub Anonymity Layer","links":[],"tags":[],"content":"vac:dr:anon:vac:gossipsub-anonymity §\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 Anonymity Layer: 2024-04-15, 2024-12-15\n\n\nstatus: 5%\nCC: Akshaya\n\nDescription §\nThis Milestone entails designing an anonymization layer for gossipsub, and by extension, IFT projects.\nThe primary objective of this anonymization layer is to serve as a cohesive anonymization solution for gossip-based projects,\nwith a specific focus on integrating it with the Logos projects Waku and Codex.\nCurrently, we’re uncertain whether the complete anonymization layer can be situated between gossipsub and the protocols of IFT projects.\nIt appears more plausible that we’ll establish a foundational element atop gossipsub,\nwith project-specific components integrated into the projects themselves,\nor introduce an intermediary layer between the general gossip anonymization protocol and the project protocols.\nThe Nomos team is crafting their own anonymization solution due to their unique requirements and their ability to leverage specific traffic patterns to enhance efficiency.\nNonetheless, the overarching objective for our anonymization network is to render our solution modular, enabling the inclusion of traffic pattern plugins that Nomos can define.\nOur initial exploration will revolve around extending our Tor push proposal.\nIn this approach, messages will traverse through an anonymization network before being disseminated via gossip protocols upon exiting the anonymization network.\nAdditionally, we aim to investigate the concept of embedding anonymization capabilities directly into gossipsub,\nrather than routing messages through a separate anonymization network before entering a standard gossipsub network operation.\nCurrently we view this anonymization solution as a P2P base layer, which the Vac P2P team will offer as part of libp2p.\nThis effort could potentially spawn an incubation project.\nThis effort would act as a basis for the Validator Privacy Network incubation project.\nJustification §\nCurrently, IFT projects do not provide enough anonymity guarantees.\nPrivacy protection, which entails anonymity, is part of the logos manifesto.\nDeliverables §\n\nreport comparing various approaches to realizing a gossipsub anonymization layer for IFT projects\n\nthis might entail identifying the need for in-project components (see description)\nhas to provide arguments why the proposed approach is expected to provide sufficient anonymity guarantees\n\n\ndocument describing benefits for each of Waku, Status, Codex, and Nimbus\nPaper on arxiv.com\n\nincluding security/privacy analysis\nshould offer improvements over Tor push.\nspam protection (integrate RLN)\nthe proposed solution MUST be practically applicable, efficient, and relevant (product-market fit)\n\n\ndraft specification of the base functionality (a usable subset of the functionality)\nPoC implementation of the base functionality\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/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/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/zk/codex/storage-proofs-open-problems-review","vac/dr/zk/codex/zk-consulting","vac/dr/g/nomos/reviews","vac/dr/anon/vac/gossipsub-anonymity"],"tags":["dr","vac"],"content":"vac:dr:valpriv:vac: §\n\n tor-push-poc\n tor-push-rel-work\ntor-push-paper\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\n\nvac:dr:zk:codex: §\n\n storage-proofs-open-problems-review\nzk-consulting\n\nvac:dr::nomos: §\n\nreviews\n\nvac:dr:anon:vac: §\n\ngossipsub-anonymity\n"},"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/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: 100%\nCC: Marvin\n\nDescription §\n\nhttps://github.com/codex-storage/zk-research-artifacts/blob/master/storage_proofs/storage_proof_musings.md\n\nJustification §\nDeliverables §\n\n sanity checks of existing documents\n"},"vac/dr/zk/codex/zk-consulting":{"title":"Codex Deep Research ZK consulting","links":[],"tags":[],"content":"vac:dr:zk:codex:zk-consulting §\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 zk-consulting: 2024-04-14, 2024-12-31\n\n\nstatus: 10%\nCC: Marvin\n\nDescription §\nThis Milestone comprises deep research ZK consulting for Codex:\nHere is a high level description of Codex ZK research problems: https://hackmd.io/1IZiFSiYSdyrbaKxKeUevg\n\nsummarizing existing research relevant for us (exactly which papers is kind of dynamically determined), in form of PDF notes and face-to-face explanations. We agreed with Marvin that this is probably the easiest way to get something going\nfinding a suitable set commitment scheme (for tracking which proofs are present / not present in an aggregated proof)\nfiguring out the details of recursion for elliptic-curve-and-pairing based schemes (while this is solved, more clarity on this is required)\n\nRegarding 3): Even if we end up using a non EC scheme for “large data”, KZG (and thus EC pairings) seems to be a much better choice for “small data”,\nso we will probably need this in any case (unless we can efficiently verify KZG proofs in a small field / FRI setting).\nSome of these tasks are explorative. Expected outputs are regular reports.\nA follow-up milestone for the next reporting period is expected.\nJustification §\nDeliverables §\n\nregular reports.\n"},"vac/dst-ice/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-ice/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-ice/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-ice/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-ice/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-ice/dr-support/vac/carnot-executable-spec":{"title":"Carnot 2-3rds Vote Aggregation Python Implementation","links":["vac/dr-ice/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-ice/index":{"title":"Distributed Systems Testing Service Unit - Milestone Icebox","links":["vac/dst-ice/wakurtosis/waku/gossipsub-topology-analysis","vac/dst-ice/wakurtosis/nomos/ci-integration","vac/dst-ice/wakurtosis/vac/rlog","vac/dst-ice/analysis/nomos/nomos-simulation-analysis","vac/dst-ice/analysis-gsub-model/vac/refactoring","vac/dst-ice/analysis-gsub-model/status/control-messages","vac/dst-ice/analysis-shadow/vac/shadow-basic-simulation","vac/dst-ice/analysis-shadow/vac/shadow-gossipsub-analysis","vac/dst-ice/analysis-shadow/waku/shadow-waku-relay-analysis","roadmap/vac/dst-ice/dr-support/vac/carnot-2-3rds-executable-spec"],"tags":["dst","vac"],"content":"vac:dst: §\n\nwakurtosis:waku: §\n\ngossipsub-topology-analysis\n\nwakurtosis:nomos: §\n\n ci-integration\n\nwakurtosis:vac: §\n\nrlog\n\nanalysis:nomos §\n\n simulation-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"},"vac/dst-ice/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: 100%\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-ice/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-ice/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-ice/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/deployment-and-analysis/codex/testnet":{"title":"Testnet","links":[],"tags":[],"content":"vac:dst:deployment-and-analysis:codex:testnet §\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 Testnet: 2024-05-01, 2024-12-31\n\n\nstatus: 15%\nCC: Wings\n\nDescription §\nAssist the Codex team with deploying and running a testnet for the Codex network.\n\nProvide a 256TB Storage Provider deployment, which should later build towards 1PiB\nProvide various support and analysis for how the testnet operates and help improve Codex\n\nJustification §\nDeliverables §\n\nMaterially assist Codex with rolling out testnet\nWorking SP storing real data\n"},"vac/dst/deployment-and-analysis/nomos/mixnet":{"title":"Mixnet","links":["tooling/vac/visualiser-tool"],"tags":[],"content":"vac:dst:deployment-and-analysis:nomos:mixnet §\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 Mixnet: 2024-05-01, 2024-12-31\n\n\nstatus: 10%\nCC: Wings\n\nDescription §\nAssist the Nomos team with deploying and running a mixnet at scale within VacLab.\n\nProvide analysis of the VacLab mixnet\nThrough Visualiser, provide visualisation tools and work with the Nomos team to implement privacy preserving metrics and measurements in Nomos to help understand the mixnet’s performance.\nWork with the Nomos team to deploy the visualisation tools for their own purposes.\n\nJustification §\nDeliverables §\n\nLab version of mixnet fully operational and rolled out\nWorking metrics via Visualiser Tool\n"},"vac/dst/deployment-and-analysis/vac/libp2p-version-testing":{"title":"Ongoing testing of specific monthly libp2p releases","links":[],"tags":[],"content":"vac:dst:deployment-and-analysis:vac:libp2p-version-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 LibP2P: 2024-05-15, 2024-12-31\n\n\nstatus: Ongoing\nCC: Wings\n\nDescription §\nThe Vac P2P team is transitioning nim-libp2p to a monthly release cycle.\nThis process involves selecting a commit hash to designate as the monthly version a week prior to release.\nDST will conduct stability tests on this version.\nThis also comprises analysing results as well as identifying and pinpointing bugs if any arise.\nSpecific issues might require several test runs and thorough analysis.\nOur aim is to increasingly automate this process.\nAdditional testing outside the scope of DST and this milestone comprises:\n\ntesting on a Nimbus test fleet\ntesting on a Waku test fleet\n\nJustification §\nDeliverables §\n\nMonthly report of libp2p testing outcomes\n"},"vac/dst/deployment-and-analysis/waku/10k":{"title":"10k Node Cluster","links":[],"tags":[],"content":"vac:dst:deployment-and-analysis:waku:10k §\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 10k: 2024-05-01, 2024-11-01\n\n\nstatus: 90%\nCC: Wings\n\nDescription §\nRun 10,000 Waku nodes actively passing messages in one network.\nGather bandwidth details, deliverability rate, retrieval times. Measure reliability, improve reliability and document deployment and analysis processes.\nGather QoS details such as latency, dropped packets, etc.\nJustification §\nDeliverables §\nDocumentation of both the deployment process and actual deployments.\nUseful analytics for the Waku team that can be used to improve the Waku software.\nResearch articles such as blog posts about the large scale clusters."},"vac/dst/deployment-and-analysis/waku/midscale":{"title":"Midscale","links":[],"tags":[],"content":"vac:dst:deployment-and-analysis:waku:midscale §\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 Midscale: 2024-05-01, 2024-11-01\n\n\nstatus: 20%\nCC: Wings\n\nDescription §\nRun deployments of between 1000 and 5000 Waku nodes actively passing messages in one network.\nTesting is to be done in this order of priority:\n\nMeasure relay bandwidth\nMeasure reliability of Waku message relaying\nMeasure usage of the DiscV5 protocol in the same scenario as (1).\nTest Store protocol at scale\nTest Waku relay+store reliability with nodes going offline/online\n\n\nIf nodes go online/offline, we should be able to retrieve missing messages from the store. This will also test Waku message relaying in a different way.\n\n\nFilter and lightpush tests\nMeasure (1) and (3) in heterogenous clusters involving different node implementations such as nwaku and go-waku\nMeasure (3) with Waku peer exchange protocol used for discovery by a subset of nodes.\nMeasure (1) with a mix of nodes using Resource-restricted device reliability protocol and peer exchange, meaning a small number of nwaku nodes serve store, light push and filter protocols and a high number of clients consume them. For example, 6-10 service nodes, 200 relay nodes and 1000 light nodes.\nThis should include connection and node churn impact on reliability for both relay and light clients.\n\nJustification §\nDeliverables §\nSimilar deliverables to 10k sim, but with focuses on smaller scale and more frequent deployments."},"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/tooling/vac/deployer-tool","vac/dst/tooling/vac/visualiser-tool","vac/dst/deployment-and-analysis/waku/10k","vac/dst/deployment-and-analysis/waku/midscale","vac/dst/deployment-and-analysis/nomos/mixnet","vac/dst/deployment-and-analysis/codex/testnet","vac/dst/deployment-and-analysis/vac/libp2p-version-testing","vac/dst/wakurtosis/waku/techreport","vac/dst/wakurtosis/waku/techreport_02","vac/dst/wakurtosis/waku/features","vac/dst/wakurtosis/nomos/ci-integration","vac/dst/wakurtosis/vac/retrospective-rlog","vac/dst/wakurtosis/vac/maintenance"],"tags":["dst","vac"],"content":"vac:dst: §\n\ntooling §\n\ndeployer-tool\nvisualiser-tool\n\ndeployment-and-analysis §\n\n10k\nmidscale\nmixnet\ntestnet\nlibp2p-version-testing\n\nwakurtosis:waku: §\n\n techreport\n techreport_02\n wakurtosis:features\n\nwakurtosis:nomos: §\n\n ci-integration\n\nwakurtosis:vac: §\n\nretrospective-rlog\n maintenance\n"},"vac/dst/tooling/vac/deployer-tool":{"title":"Deployer Tool","links":[],"tags":[],"content":"vac:dst:tooling:vac:deployer-tool §\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 Deployer Tool: 2024-05-01, 2024-11-01\n\n\nstatus: 80%\nCC: Alberto\n\nDescription §\nA first version of tool that allows deploying >10k gossipsub / waku relay nodes.\nThe tool should measure bandwidth usage per node and bundle the measurement data for analaysis.\nThe tool should be built in such a way that it can be used for other deployments as well.\nJustification §\nDeliverables §\n\nhttps://github.com/vacp2p/10ksim\n"},"vac/dst/tooling/vac/visualiser-tool":{"title":"Visualiser Tool","links":["vac/dst/tooling/vac/visualiser-tool.png"],"tags":[],"content":"vac:dst:tooling:vac:visualiser-tool §\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 Visualiser Tool: 2024-05-01, 2024-11-01\n\n\nstatus: 10%\nCC: Alberto\n\nDescription §\nA first version of tool that allows for visualising the message flow of a Waku network. It should be adaptable to other network types too (particularly Nomos, Codex)\nThis relies on a Grafana Loki deployment to store and query logs.\nJustification §\nDeliverables §\nA peer to peer network mapper that creates a visualisation something like this:\n\nThe tool should be able to visualise the message flow of a Waku network, by lighting up nodes in a graph as they receive messages, flashing a different colour for each message (or message type)."},"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/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/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/index":{"title":"Vac Roadmap","links":["vac/p2p/","vac/tke/","vac/dst/","vac/qa/","vac/acz/","vac/sc/","vac/nim/","vac/rfc/","vac/dr/","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\nqa: Quality Assurance\nacz: Applied Cryptography and Zero-knowledge\nsc: Smart Contracts\nnim: Nim\nrfc: RFC (Specifications)\n\nDeep Research §\n\ndr: Deep Research\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-architecture-01","vac/nes/state-separation/vac/state-separation-architecture-02","vac/nes/proofsystems/vac/research-existing-proofsystems","vac/nes/proofsystems/vac/benchmarks","vac/nes/zkvm/vac/vm-foundations","vac/nes/zkvm/vac/vm-ecosystem"],"tags":["zkvm","vac"],"content":"vac:nes:state-separation §\n\nstate-separation-architecture-01\nstate-separation-architecture-02\n\nvac:nes:proofsystems §\n\nresearch-existing-proofsystems\nbenchmarks\n\nvac:nes:zkvm §\n\nvm-foundations\nvm-ecosystem\n"},"vac/nes/proofsystems/vac/benchmarks":{"title":"Benchmarks","links":[],"tags":[],"content":"vac:nes: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, 2024-05-31\n\n\nstatus: 70%\nCC: team\n\nDescription §\nSince Nescience’s main goal is to be innovative in privacy technology (by building a virtual machine that prioritizes privacy,\nutilizing mainstream and specialized instruction sets optimized for Zero-Knowledge (ZK) applications),\na key focus is the evaluation of different proof systems especially new ones like the Nova-based proof system against alternatives to identify the best fit for our needs.\nThis milestone is important for advancing privacy-preserving technologies, setting a benchmark for the fair and effective comparison of ZKP systems.\nIt’s important for both our project’s infrastructure and the broader field. The diversity of ZKP system designs necessitates a standardized benchmarking approach to ensure fair comparison,\nrespecting each system’s unique features (which we are aiming to achieve and accomplish)\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\nWork Breakdown §\n\n\nBy conducting deep investigation of ZKP systems, we aim to demystify the complexities of cryptographic benchmarking and highlight our findings’ relevance to privacy technology advancement.\n\n\nBy rewriting circuits and using same techniques as recursive approach and Poseidon hash functions, we ensure that the comparison focuses on inherent system properties rather than external variables.\nThis approach will help normalize one of the key variables across systems, allowing for a more direct and fair comparison of their efficiency, scalability, and other critical metrics.\n\n\nDeliverables §\n\nResearch blog post\nPublic benchmark repo on Github (it includes and overall explanation, full circuits implementation and explanation, instructions to execute benchmarks, and testing results on diffferent machines)\nImplementation of recursive circuitsfor all current proof-systems (unless there is a good reason not to include one)\nscientific paper\n\nImpact: By selecting the most effective proof system, such as potentially Nova-based ones, based on superior performance,\nwe aim to strengthen our project’s foundation and contribute valuable insights to the privacy field and the scientific community.\nThis milestone can be useful to any team within the organization to help choose the correct proof system based on their needs\nand in general it help the scientific community to get useful insights to progress on different projects within the blockchain field."},"vac/nes/proofsystems/vac/research-existing-proofsystems":{"title":"Research Existing Proofsystems","links":[],"tags":[],"content":"vac:nes: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, 2024-12-31\n\n\nstatus: ongoing\nCC: team\n\nDescription §\nThis milestone demonstrates our commitment to a continuous and long-term effort aimed at the comprehensive analysis and study of various proof systems, both established and emerging.\nThe primary objective is to maintain cutting-edge relevance by staying alongside of the latest developments in proof systems, ensuring our projects are at the forefront of privacy technology.\nThis is important for sustaining our competitive edge and fostering innovation within our projects.\nThis milestone is foundational to our strategy, enabling us to swiftly adapt to new technologies and incorporate groundbreaking methods that enhance our privacy objectives.\nWork Breakdown §\nOur approach involves a systematic review of current and nascent proof systems, identifying those with the potential to advance our research and project goals.\nThis includes evaluating their applicability, efficiency, and the privacy enhancements they offer.\nBy doing so, we aim to uncover novel insights and techniques that can be integrated into our work, furthering our mission to deliver robust privacy solutions.\nDeliverables §\n\nBlog posts\nPotential benchmarks\n\nImpact: The ongoing research and analysis conducted under this milestone are expected to yield multiple benefits:\nidentification of promising proof systems that could revolutionize our approach to privacy, generation of innovative ideas for future development,\nand ensuring our projects remain relevant and impactful in the rapidly advancing field of blockchain and privacy technologies.\nThis milestone is valuable both internally and externally. Within our organization, it caters to the diverse needs of various teams that utilize proof systems for distinct purposes.\nSimilarly, it offers the scientific community access to essential insights across different systems without the need to delve into each one individually."},"vac/nes/state-separation/vac/state-separation-architecture-01":{"title":"State Separation Architecture 01","links":[],"tags":[],"content":"vac:nes:state-separation:vac:state-separation-architecture-01 §\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 Architecture 01: 2024-01-02, 2024-12-31\n\n\nstatus: 40%\nCC: Team\n\nDescription §\nThe main goal is to design and refine a sophisticated model of state separation within the Nescience project,\nwhich is aimed at distinctly segregating and managing public and private computational processes, including specialized operations such as shielded and deshielded activities.\nThis model is focused on improving privacy through the use of Zero-Knowledge Proofs (ZKPs) and overcoming obstacles related to the traceability\nand linkability of transactions by employing cutting-edge cryptographic methods and frameworks.\nThe goal is to create a nuanced architecture that adeptly balances public and private computational needs.\nIt will utilize an account-based system for public interactions and a UTXO (Unspent Transaction Output)-based method for private transactions,\neffectively combining the benefits of public state efficiency and transparency with the strong privacy safeguards of private states.\nThis effort aims to tackle critical issues in enhancing privacy, engaging deeply with a zero-knowledge virtual machine (zkVM), and achieving significant advances in privacy assurance.\nThe Nescience project elevates the concept of state separation to a new level, striking an unparalleled balance between privacy and scalability by enabling simultaneous public and private computations.\nUnlike existing initiatives, our model not only integrates these two states but also innovates within the private state to support trusted computing,\nachieving scalability without sacrificing privacy. We aim to redefine privacy-oriented technologies,\nwhich are often criticized for their sluggish performance, by introducing a fast, intuitive, and developer-friendly approach to state separation.\nFurthermore, we envision the public state serving as a vigilant monitoring layer, safeguarding privacy against any potential ZKP vulnerabilities or attacks,\nthereby assuring users of their data security.\nOur project distinguishes itself by offering a well-defined theoretical representation of state separation,\ncomplete with graphical analyses for a clearer comparison with other privacy-preserving solutions, thus addressing the lack of specificity and clarity in existing models.\nInteractions with the virtual machine (VM) are pivotal, involving two critical junctures.\nInitially, on the user (client) side, transactions that may contain multiple executions, including private, shielded, or deshielded types, are generated as ZK proofs.\nThese proofs, representing each execution, are then amalgamated into a single ZK proof for submission to the sequencer (VM).\nThe sequencer’s role is to aggregate transactions from users, verify the proofs, validate nullifiers for conflict detection,\nand then compile all verified proofs within an epoch to formulate a block.\nThis process also entails adjustments to the public state in response to the varied executions (public modifications, shielded, and deshielded executions).\nThe design criteria for the zkVM include the necessity for high recursion capabilities and sufficient efficiency to ensure usability in terms of memory and computational time on the user side.\nThis requirement is critical for compatibility with complex tasks like concealing certain information within zkVM operations,\naccommodating a significant volume of public and private inputs. The efficiency of verification, even in systems like Groth16 that offer theoretically constant-size verification times,\ncan be affected as the quantity of inputs grows, underscoring the need for a VM architecture that remains practical and responsive under varying loads.\nThis nuanced understanding underscores the project’s comprehensive approach to leveraging state separation for enhanced privacy and scalability,\nall while ensuring compatibility with an advanced zkVM framework.\nThe most significant impact of our state separation approach in the Nescience project lies in its innovative privacy features,\nwhich employ an account-based model for the public state and a UTXO-based model for the private state, allowing for individual or group-specific private states.\nThis method stands out by offering four distinct types of executions: public, private, shielded, and deshielded, each with unique characteristics to maintain privacy and scalability.\nPublic executions are transparent and swift, modifying accounts without the need for Zero-Knowledge Proofs (ZKPs).\nIn contrast, private, shielded, and deshielded executions, which involve transferring between public and private states or within private states,\nutilize ZKPs to protect sensitive information like addresses, transaction amounts, and smart contract invocations through kernel circuits.\nThese executions are further enriched by allowing transactions to comprise various execution types,\nensuring that sensitive data is processed on the user side with ZKPs to prevent exposure in the public state.\nFor example, transactions involving private tokens or smart contract interactions remain confidential, with minimal information reflected publicly.\nThis architecture addresses potential risks like linkability and double-spending through the innovative use of nullifiers and accumulators, enhancing privacy without sacrificing security.\nOur approach also introduces Private Directed Acyclic Graphs (PDAGs) as a tool for analyzing and enhancing privacy.\nAs an extension of Transaction Directed Acyclic Graphs (TDAGs), PDAGs are specifically designed to address and measure two critical aspects of privacy:\nunlinkability and untraceability. Unlinkability refers to the property that ensures individual transactions cannot be linked to each other,\nmaking it impossible to trace the flow of assets between transactions from an external observer’s perspective.\nThis feature is crucial for protecting user identities and preventing the exposure of transaction histories.\nUntraceability, on the other hand, ensures that it is infeasible to trace transactions back to their source or destination,\nproviding a further layer of privacy by obscuring the relationship between senders and receivers.\nThis means that, even if an entity were to observe the network, they would not be able to determine the parties involved in any given transaction.\nPDAGs incorporate these principles by structuring transaction records in a way that leverages the benefits of directed acyclic graphs (DAGs),\na type of data structure that allows for efficient data management and retrieval without the limitations of linear or hierarchical arrangements.\nIn the context of blockchain, DAGs enable faster transactions and greater scalability, while PDAGs extend these benefits with a focus on privacy.\nBy calculating unlinkability and untraceability metrics within a PDAG framework, it becomes possible to quantitatively assess the privacy level of a blockchain network.\nThis analytical approach allows for comparisons with other privacy-centric solutions, such as CoinJoin, Tornado Cash, and privacy-focused blockchains like Monero and Zcash.\nThrough PDAGs, developers can identify potential weaknesses in privacy measures and enhance the network’s resistance to analysis and tracking, ensuring a secure and private environment for users.\nBy incorporating decoy inputs in shielded and deshielded transactions, we further obscure the link between public and private states, significantly reducing the risk of privacy breaches.\nIn essence, the Nescience project’s state separation method not only advances privacy and scalability in blockchain technology\nbut also sets new standards in protecting user data through a sophisticated blend of theoretical models and practical implementations.\nThis approach not only addresses current privacy concerns but also lays the groundwork for future investigations into efficient and secure private state exchanges.\nTo provide a structured approach to the development of the advanced State Separation Architecture for the Nescience project,\nfocusing on privacy enhancement, we can break down the milestone into distinct sub-milestones, each with its own specific work breakdown and deliverables.\n\nJustification §\nWork Breakdown and Deliverables §\n\n\n\n Sub Milestone 1 (Q2 2024): Execution Types and Privacy Mechanism Design\n\nWork Breakdown: Define and design the distinct execution types (public, private, shielded, and deshielded) and their respective privacy mechanisms, integrating Zero-Knowledge Proofs (ZKPs) for enhanced privacy.\n\n\n\n Deliverables: Set of comprehensive deliverables, including an Execution Type Design Document that offers an in-depth analysis of the specifications and workflows for public, private, shielded, and deshielded executions in the Nescience state separation architecture -> Execution Types Document.\n\n\n\n\n\n\n Sub Milestone 2 (Q2 2024): Cryptographic Infrastructure and Nullification Strategy\n\nWork Breakdown: Develop the cryptographic infrastructure necessary for the state separation architecture, including nullifiers and accumulators, to prevent double-spending and ensure unlinkability of notes. First step would be identifying and selecting suitable cryptographic primitives for nullifiers and accumulators, then implementing the selected primitives in the architecture.\n\n\n\n Deliverables: A document providing a comprehensive guide on the implementation and integration of nullifiers and accumulators within the state separation model, detailing their specific roles and functions within the overall architecture -> Nullification Strategy Document.\n\n\n\n\n\n\n Sub Milestone 3 (Q3 2024): State Separation Document\n\nIntro: In this milestone, the first part (https://vac.dev/rlog/Nescience-A-zkVM-leveraging-hiding-properties) focuses on conducting detailed exploration of the multifaceted challenges,\npotential solutions, and alternatives that lay ahead building Nescience, a privacy-first blockchain project aiming to enable private transactions and provide a general-purpose execution environment\nfor classical applications. The second part aims to delve deeper into the selected strategic paths for developing a privacy-first blockchain, detailing the methodologies for addressing the identified challenges,\nthe decisions made to enhance privacy, and the expected outcomes.\nWork Breakdown: Document all the research findings, the development steps and the methodologies, explaining the utility and adoption process of each solution to reinforce privacy within the project and the shift in focus towards detailing the chosen paths for the project development, including the rationale behind these decisions and their alignment with privacy enhancements. Finally, Review future directions, potential areas of research, and ongoing development efforts to continue advancing privacy within the Nescience project\nDeliverables: Blog posts and/or scientific papers.\nImpact: By clearly articulating the exploration from identifying challenges to implementing solutions,\nPart Two of the State Separation Document aims to serve as a comprehensive guide and reference for enhancing privacy in blockchain technologies,\nmarking a significant milestone in the Nescience project’s development.\n\n\n\n Sub Milestone 4 (Q3 2024): Enhancing Transaction Privacy with Decoy Inputs\n\nWork Breakdown: Incorporate empty notes as decoy inputs for shielded and deshielded executions to enhance the untraceability and unlinkability of transactions. First we aim to design the mechanism for integrating decoy inputs into transactions to act as noise; then we develop a prototype that demonstrates the effectiveness of decoy inputs in enhancing transaction privacy.\nDeliverables: A prototype showcasing the implementation of decoy inputs, accompanied by evaluation results highlighting their impact on privacy enhancement.\n\n\n\n Sub Milestone 5 (Q4 2024): Nescience devnet deployment\n\nWork Breakdown: Deploy a Nescience Devnet by integrating simplified components into the zkVM and state separation architecture to achieve a fully functional Nescience environment. Add the necessary simplified components to the zkVM and state separation architecture such as P2P communication layer, Consensus layer, and Network layer. Focus on node deployment (Configure and start Nescience nodes on designated machines and ensure nodes operate independently, with a full structure that includes the consensus layer, network layer, etc.). Ideally, the Nescience Devnet should function autonomously, without reliance on external blockchain environments whereas existing components can be utilized ensuring that the system should be able to run on its own.\nDeliverables: A fully operational Nescience Devnet, capable of running nodes independently with integrated P2P communication, consensus, and network layers, all within the zkVM and state separation framework.\n\n\nRisks §\nWe currently have 2 open positions for hiring a 1) Zero Knowledge Research Engineer and a 2) Zero Knowledge Researcher.\nCurrently we are finding some difficulties in finding the best candidates for these positions and therefore we need to consume Vac resources (namely Ugur and Marvin) for a longer time to focus on Nescience projects."},"vac/nes/state-separation/vac/state-separation-architecture-02":{"title":"State Separation Architecture 02","links":[],"tags":[],"content":"vac:nes:state-separation:vac:state-separation-architecture-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 State Separation Architecture 02: 2025-01-02, 2025-12-31\n\n\nstatus: 0%\nCC: Team\n\nDescription §\ncontiunation of vac:nes:state-separation:vac:state-separation-architecture-02\nJustification §\nWork Breakdown and Deliverables §\n\n\nSub Milestone 1 (2025): TDAG & PDAG Integration for Privacy Enhancement\nWork Breakdown: Use Transaction Directed Acyclic Graphs (TDAGS) and Private Directed Acyclic Graphs (PDAGs) for a comparative analysis of the Nescience architecture’s privacy features. The main idea is to implement PDAGs to improve unlinkability and untraceability within the project, enhancing privacy features. This can be done by developing and integrating PDAG structure, oncluding data structures, algorithms and the integration mechanism with the existing system; by conducting thorough testing of the PDAG implementation to identify issues or areas of improvements; and by monitoring its performance and impact on privacy enhancement.\nDeliverables:\n\nReport on PDAG reearch and analysis.\nPDAG integration technical specifications and design documents.\nA functioning PDAG implementation with testing reports.\nDocumentation on PDAG privacy improvements and security analysis.\n\n\n\nSub Milestone 2 (2025): Kernel-based Architecture Implementation\nWork Breakdown: Develop a kernel-based framework for verifying private function executions accurately, using a recursive SNARKs approach to build and validate a call stack. This is to ensure robust proof of execution sacrificing computational resources (raising gas fees due to the intensive nature of generating SNARK proofs and handling recursive computations). We will focus on balancing the precision of recursive verification with its computational costs, aiming for a system that guarantees the integrity of private functions while managing resource use efficiently.\nDeliverables:\n\nA data structure to manage recursive function calls, ensuring efficiency and security.\nA system to securely accumulate and manage proof data for recursive calls, facilitating tamper-resistant proof handling.\nGeneration of intermediary SNARK proofs for each recursive call, with aggregation capabilities for comprehensive stack validation.\nEstablishment of a maximum recursion depth with enforcement mechanisms to prevent computational overflow.\nA fully integrated recursive verification system with extensive testing to ensure functionality, security, and performance under varied conditions.\n\n\n\nSub Milestone 3 (2025): Seamless Interaction Design\nWork Breakdown: Address the challenge of potential information leakage between private and public transactions by ensuring composability between contracts and secure integration of functions. Moreover, we would like to be able to create secure channels for contract composability and interaction layers that prevent private data exposure by implementing strategic safeguards against information leakage.\nDeliverables:\n\nIntermediary smart contracts for secure public-private interactions.\nConfidential sidechains and cross-chain protocols employement.\nFragmentation of data across shards for private interaction.\n\n\n\nSub Milestone 4 (2025 / 2026): zkVM deployment\nWork Breakdown: Our aim is to deploy our work in progress state separation architecture within a privacy-first zero knowledge virtual machine since it places an emphasis on privacy enhancements (which we need for our privacy-first zkVM).\nDeliverables: A functioning privacy-first zkVM that ensures that while private state data remains undisclosed, public state transitions can still be carried out and subsequently verified by third parties.\n\n\nSub Milestone 5 (2025 / 2026): State Separation Doc\nDescription: This open milestone is crucial for ensuring that our development aligns with the evolving needs and expectations of users and organization.\nWe aim not only to address the immediate challenges of developing a privacy-first blockchain but also to lay the groundwork for future innovations in blockchain privacy and security.\nNote: This is an ongoing and long term milestone with possible deliveries within the year 2024. The timing and nature of these deliveries are contingent upon our continuous findings\nand their subsequent impact on privacy for both the organization and the community.\nWork Breakdown:\n\nDocument all the research findings, the development steps and the methodologies.\nExplain the utility and adoption process of each solution to reinforce privacy within the project\nExplain the shift in focus towards detailing the chosen paths for the project development, including the rationale behind these decisions and their alignment with privacy enhancements.\nReview future directions, potential areas of research, and ongoing development efforts to continue advancing privacy within the Nescience project\n\nDeliverables\n\nBlog posts.\nScientific papers.\n\n\n"},"vac/nes/zkvm/vac/vm-ecosystem":{"title":"VM Ecosystem","links":[],"tags":[],"content":"vac:nes:zkvm:vac:vm-ecosystem §\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 VM ecosystem: 2025-01-01, 2025-12-31\n\n\nstatus: 0%\nCC: team\n\nDescription §\nWork Breakdown & Deliverables §\n\n\nSub Milestone 1 (2025): Deployment and Real-World Application Testing\nWork Breakdown: Deploy the privacy-centric zkVM in a controlled environment and test its real-world applicability and performance, focusing on privacy-preserving computations.\nDeliverables: An outline for deploying the zkVM in a test env, including infrastructure and security considerations, along with results of testings focusing on ptivacy preservation.\n\n\nSub Milestone 2 (2025): Community Engagement and Open-Source Contributions\nWork Breakdown: Engage with the cryptographic and privacy communities and teams within the organization to gather feedback, share insights, and contribute to the open-source ecosystem, fostering wider adoption and collaboration.\nDeliverables: Release of the developed cryptographic libraries and zkVM source code to the open-source community, accompanied by comprehensive documentation and guides for implementation and use.\n\n\nImpact: This plan underscores the goal for delivering a zkVM with strong focus on privacy enhancements. By identifying and integrating advanced cryptographic primitives, and considering the deployement within environments like Nexus VM or similar VMs, this milestone aims to make significant contributions to the field of privacy-preserving computation. Sub milestones may slightly change and some of them might be accomplished faster than others especially that during the previous period, we have focused on existing zkVMs and extensively studied the integration of cryptographic primitives to enhance pivacy."},"vac/nes/zkvm/vac/vm-foundations":{"title":"VM Foundations","links":[],"tags":[],"content":"vac:nes:zkvm:vac:vm-foundations §\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 VM Foundations: 2024-03-01, 2024-12-31\n\n\nstatus: 40%\nCC: team\n\nDescription §\nThe focus of this milestone is on the significant adaptation of a Zero-Knowledge Virtual Machine (zkVM) that places an emphasis on privacy enhancements. By modifying existing zkVM frameworks, the goal is to integrate advanced cryptographic primitives to create a highly secure, privacy-preserving computational environment. This includes exploring and implementing cutting-edge research in cryptographic techniques and ensuring these can be efficiently executed within our zkVM framework, with an example pathway through Nexus VM for specific Rust-based cryptographic implementations. The analysis includes RISC Zero, GKR-based VMs, and Layer 2 zkVMs, with a focus on their instruction set architectures, privacy capabilities, proof complexities, and specific innovations or limitations. This milestone will be divided in several sub-milestones in order to understand which paths to take and which path would better fit in order to get tangible output (see Work Breakdown and Deliverables)\n\nWork Breakdown & Deliverables §\n\n\n\n Sub Milestone 1: Privacy Cryptography Research and Selection\n\nWork Breakdown: Conduct exhaustive research into cryptographic primitives that enhance privacy, determining which are most applicable and promising for integration into a zkVM.\nDeliverables:\n\n\n\n A comprehensive review of current cryptographic techniques that enhance privacy, including signature schemes and MPC schemes, focusing on those with potential for zkVM integration -> 1. List of zkVMs and 2. In-depth Review.\n\n\n\n\n Analysis of selected cryptographic primitives for implementation in Rust, considering their compatibility with the zkVM environment, specifically within frameworks like Nexus VM -> List of Primitives and Privacy Requirements.\n\n\n\n\n\n\n Sub Milestone 2: Cryptographic Implementation and Testing (Related to Sub Milestone 1)\n\nWork Breakdown: Implement the selected cryptographic primitives in Rust (From Sub Milestone 1), ensuring they are optimized for privacy enhancement within the zkVM framework.\nDeliverables: Repo documenting the testing processes, performance evaluations, and optimizations applied to the cryptographic implementations to ensure privacy efficiency and scalability within the zkVM.\n\n\n\n Sub Milestone 3: zkVM Adaptation for Privacy\n\nWork Breakdown: Adapt an existing zkVM to integrate the implemented cryptographic primitives, prioritizing privacy preservation. For instance we can think about replacing Merkle trees with Verkle trees within existing VMs, or adding proof compression layer to replace logarithmic proof sizes with constant sized proofs. The possible prototype could potentially incorporate selected features and optimizations from the previous phases. This involves implementing privacy-preserving properties, selecting appropriate instruction sets, and integrating advancements such as Nova-based proof systems.\nDeliverables:\n\nPotential Privacy-Centric zkVM Prototype: A zkVM that integrates the Rust-based cryptographic libraries, showcasing enhanced privacy capabilities.\nDetailed documentation on performance metrics and comparative analysis with existing systems.\n\n\n\nImpact: This plan underscores the goal for delivering a zkVM with strong focus on privacy enhancements. By identifying and integrating advanced cryptographic primitives, and considering the deployement within environments like Nexus VM or similar VMs, this milestone aims to make significant contributions to the field of privacy-preserving computation. Sub milestones may slightly change and some of them might be accomplished faster than others especially that during the previous period, we have focused on existing zkVMs and extensively studied the integration of cryptographic primitives to enhance pivacy."},"vac/nim/core-libs/vac/chronos-maintainance":{"title":"chronos-maintainance","links":[],"tags":[],"content":""},"vac/nim/index":{"title":"Nim Unit","links":["vac/nim/tooling/vac/nim-suggest","vac/nim/tooling/vac/nimble","vac/nim/tooling/vac/compiler","vac/nim/tooling/vac/editor","vac/nim/tooling/vac/lsp","vac/nim/core-libs/vac/chronos-maintainance"],"tags":["nim","vac"],"content":"vac:nim: §\n\ntooling:vac: §\n\n nim-suggest\n nimble\n compiler\n editor\n lsp\n\ncore-libs:vac: §\n\n chronos-maintainance\n"},"vac/nim/tooling/vac/compiler":{"title":"compiler","links":[],"tags":[],"content":""},"vac/nim/tooling/vac/editor":{"title":"editor","links":[],"tags":[],"content":""},"vac/nim/tooling/vac/lsp":{"title":"lsp","links":[],"tags":[],"content":""},"vac/nim/tooling/vac/nim-suggest":{"title":"nim-suggest","links":[],"tags":[],"content":""},"vac/nim/tooling/vac/nimble":{"title":"nimble","links":[],"tags":[],"content":""},"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/qa/g/nomos/test-automation-cryptarchia":{"title":"Test Automation cryptarchia","links":[],"tags":[],"content":"vac:qa::nomos:test-automation-cryptarchia §\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 cryptarchia: 2024-05-01, 2024-08-31\n\n\nstatus: 0%\nCC: Florin, Alex, Roman\n\nDescription §\n\nCryptarchia test plan\nIntegration tests\nE2E tests\nPerformance tests\n\nJustification §\nDeliverables §"},"vac/qa/g/nomos/test-automation-data-availability":{"title":"Test Automation Data Availability","links":[],"tags":[],"content":"vac:qa::nomos:test-automation-data-availability §\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 Data Availability: 2024-07-29, 2024-10-31\n\n\nstatus: 0%\nCC: Florin, Roman\n\nDescription §\n\nTest plan\nUnit tests\nIntegration tests\nPerformance tests\n\nJustification §\nDeliverables §"},"vac/qa/g/vac/test-automation-nim-libp2p":{"title":"Test Automation nim-libp2p","links":[],"tags":[],"content":"vac:qa::vac:test-automation-nim-libp2p §\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 nim-libp2p: 2024-01-01, 2024-12-31\n\n\nstatus: 0%\nCC: Alex, Roman, Florin\n\nDescription §\nAdd tests and increase coverage for all the modules implemented in nim libp2p\nJustification §\nDeliverables §"},"vac/qa/g/vac/test-automation-nim-tooling":{"title":"Test Automation nim-tooling","links":[],"tags":[],"content":"vac:qa::vac:test-automation-nim-tooling §\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 nim-tooling: 2024-06-17, 2024-12-31\n\n\nstatus: 0%\nCC: Roman, Alex, Florin\n\nDescription §\n\nbuild process testing\ncontribution to Nim devel docker images\nNimble/Nim features testing\ncollect feedback from devs -> create issues\n\nJustification §\nDeliverables §"},"vac/qa/g/waku/interop-testing-02":{"title":"Interop Testing Part 2","links":[],"tags":[],"content":"vac:qa::waku:interop-testing-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 Interop Testing Part 2: 2024-07-01, 2024-12-31\n\n\nstatus: 0%\nCC: Florin, Roman\n\nDescription §\nAdd new coverage for the interop testing framework\n\npeer exchange\ndiscv5\npeer & connection management\nedge cases\nmore complex scenario\ncreate tests for known issues found by devs / node operators / integrators\n\nJustification §\nDeliverables §"},"vac/qa/g/waku/interop-testing":{"title":"Interop Testing","links":[],"tags":[],"content":"vac:qa::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-04-30\n\n\nstatus: 100%\nCC: Florin, Roman\n\nDescription §\nCreate an interop testing framework that can run Waku nodes and cover it’s\n\nfilter\nlightpush\nstore (incl. store v3)\nrelay\nnwaku <> go-waku interop\nci integrations\nnightly reports\n\nJustification §\nDeliverables §\n\nCreated scalable pytest framework\nReached ~ 320 tests\nCreated CI github actions workflows that:\n\nRuns nightly on latest nwaku and go-waku versions\nRuns tests between multiple nwaku nodes but with nwaku as service node and go-waku as client nodes in an interop way\nCan be run on demand against any nwaku / go-waku version\nPublishes nice reports with history and logs using github pages, check example\nNotifies waku discord channel about results of tests and pings developers if there are failures\n\n\nCoverage:\n\nfilter\nlightpush\nrelay\nstore\nsharding\n\n\nNwaku issues found:\n\n2719: store v3 response format issues\n2717: nwaku crashes for a store v3 request with invalid cursor format\n2716: passing a cursor that doesn’t correspond to any message in the store will return all messages\n2715: store v3 returns error “waku message hash parsing error: Incorrect base64 string” for some cursors\n2644: nwaku node fails to start without a shard flag\n2586: node doesn’t store messages if relay is disabled\n2582: contentTopic naming not consistent in the store response where is’s content_topic\n2567: lightpush fails with Failed to request a message push: dial_failure after the peer node restart\n2565: strange errors when light pushing messages with payload >= 300 kb\n2552: node ca be started on multiple clusters\n2550: node crashes with Message: AsyncEventQueue size exceeds limits when there are many flags to the docker start command\n2546: only receive messages if someone subscribes explicitly via REST API to a pubsubTopic\n2538: autosharding resolves content topics to wrong shard\n2512: some lightnodes are not receiving filter push in certain conditions\n2437: relay publish fails with 400 Bad Request when message contains an unknown field\n2436: relay publish fails with 400 Bad Request when message contains ephemeral field\n2388: relayed messages reach recently started peer with a big delay (~60 seconds)\n2380: Relayed messages are not stored when running nwaku with docker compose\n2372: failed to setup archive driver: Postgres has been configured but not been compiled. Check compiler definitions\n2371: multiple messages published in the same second via RLN RELAY are not dropped\n2320: Filter relay/v1/messages GET returns duplicate messages\n2319: Relay publish returns Failed to publish: timedout when a peer filter node is disconnected\n2315: updating a non existing subscriptions returns no error\n2299: Relay connection works no more\n2286: filter/v2/subscriptions response not in the expected format\n2255: pubsub topic not mandatory for filter/v2/subscriptions\n2214: relay publish fails with 400 Bad Request when message contains meta field\n2198: relay push with malformed timestamp crashes nwaku\n2147: store query cursor misbehaving for specific cursors\n2117: store response is empty when requests contains invalid cursor\n\n\nGo-Waku issues found:\n\n1110: store v3 - passing a cursor that doesn’t correspond to any message in the store will return all messages\n1109: store v3 returns error “illegal base64 data at input byte” for some cursors/hashes\n1108: pubsubTopic and contentTopics are required for store v3 requests\n1107: standardize store types by using camel case instead of snake case\n1106: store v3 local queries time out\n1087: failed to negotiate protocol: protocols not supported: [/vac/waku/store/2.0.0-beta4] when the peer node has store disabled\n1079: missing RequestId field error when lightpush has unexpected payload of content topic\n1078: lightpush on non subscribed pubsub topic hangs\n1076: strange errors when light pushing messages with payload >= 300 kb\n1074: all REST API calls return 200 with empty response\n1068: ephemeral field is ignored and not returned when retrieving messages even if the message contained this field\n1064: subscription not found if we start the node with the —pubsub-topic and we attempt to retrieve messages\n1061: dont harcode clusterid for autosharding\n1054: filter subscribe on a pubsubtopic from a different cluster id freezes\n1034: DELETE /relay/v1/subscriptions freezes in certain conditions\n988: invalid memory address or nil pointer dereference when trying to connect nodes\n972: filter/v2/subscriptions take a lot of time and even timeout sometimes\n971: Unsubscribing from one pubsubtopic seems to unsubscribe from all\n970: ping request failed with 503 when peer has no subscription\n969: PUT /filter/v2/subscriptions doesn’t exist\n968: 503 instead of 400 when a filter/v2/subscriptions bad request is sent\n967: filter/v2/subscriptions freezes when pubsubtopic is from the non-default (0) cluster\n960: Strange “not subscribed to pubsubTopic” errors for filter/v2/messages GET requests\n928: encoding/hex: odd length hex string for filter/v2/subscriptions POST requests\n923: discv5/discover.go messages flooding the docker DEBUG logs\n922: duplicate validator for topic error when trying to re-subscribe to previously unsubscribed topic\n914: REST relay publish returns HTTP 500 Internal Server Error instead of 4XX for invalid requests E:REST API service node\n\n\n"},"vac/qa/g/waku/maintenance-go-waku":{"title":"Maintenance go-waku","links":[],"tags":[],"content":"vac:qa::waku:maintenance-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 Maintenance go-waku: 2024-03-18, 2024-12-31\n\n\nstatus: 0%\nCC: Roman\n\nDescription §\nThis milestone comprises various (ad-hoc) tasks essential to maintaining and enhancing our project’s operational efficiency.\nIt is specifically designated for updates and fixes to tests that were introduced in previously closed milestones, ensuring that all our testing frameworks remain robust and up-to-date.\nIt also offers a space for small, ad-hoc developer requests, for instance, we can use this milestone when we are requested assistance with reproducing steps for a bug or to conduct an investigation into a specific failure.\nJustification §\nDeliverables §"},"vac/qa/g/waku/maintenance-js-waku":{"title":"Maintenance js-waku","links":[],"tags":[],"content":"vac:qa::waku:maintenance-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 Maintenance js-waku: 2024-03-18, 2024-12-31\n\n\nstatus: 0%\nCC: Florin\n\nDescription §\nThis milestone comprises various (ad-hoc) tasks essential to maintaining and enhancing our project’s operational efficiency.\nIt is specifically designated for updates and fixes to tests that were introduced in previously closed milestones, ensuring that all our testing frameworks remain robust and up-to-date.\nIt also offers a space for small, ad-hoc developer requests, for instance, we can use this milestone when we are requested assistance with reproducing steps for a bug or to conduct an investigation into a specific failure.\nJustification §\nDeliverables §"},"vac/qa/g/waku/maintenance-nwaku":{"title":"Maintenance nwaku","links":[],"tags":[],"content":"vac:qa::waku:maintenance-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 Maintenance nwaku: 2024-03-18, 2024-12-31\n\n\nstatus: 0%\nCC: Alex, Roman\n\nDescription §\nThis milestone comprises various (ad-hoc) tasks essential to maintaining and enhancing our project’s operational efficiency.\nIt is specifically designated for updates and fixes to tests that were introduced in previously closed milestones, ensuring that all our testing frameworks remain robust and up-to-date.\nIt also offers a space for small, ad-hoc developer requests, for instance, we can use this milestone when we are requested assistance with reproducing steps for a bug or to conduct an investigation into a specific failure.\nJustification §\nDeliverables §"},"vac/qa/g/waku/test-automation-go-waku":{"title":"Test Automation go-waku","links":[],"tags":[],"content":"vac:qa::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: 100%\nCC: Roman\n\nDescription §\n\nfilter (t)\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\n\nJustification §\nDeliverables §\n\n\nfilter:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_ping_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_proto_ident_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_push_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_subscribe_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/filter/filter_unsubscribe_test.go\n\n\n\nlightpush:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/lightpush/waku_lightpush_test.go\n\n\n\nstore:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/store/waku_store_client.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/store/waku_store_protocol_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/store/waku_store_query_test.go\n\n\n\nrelay:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/relay/waku_relay_test.go\n\n\n\npeer exchange:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/protocol/peer_exchange/waku_peer_exchange_test.go\n\n\n\npeer & connection management:\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/peermanager/connection_gater_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/peermanager/service_slot_test.go\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/peermanager/topic_event_handler_test.go\n\n\n\ndiscv5\n\nhttps://github.com/waku-org/go-waku/blob/master/waku/v2/discv5/discover_test.go\n\n\n\nCI integration\n\nhttps://github.com/waku-org/waku-interop-tests/actions/workflows/test_common.yml\ngo_waku_daily which is now changed.\n\n\n"},"vac/qa/g/waku/test-automation-js-waku":{"title":"Test Automation js-waku","links":[],"tags":[],"content":"vac:qa::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: 100%\nCC: Florin\n\nDescription §\n\nfilter (t)\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\n\nAdditional requirements:\nIt should be possible to choose the nwaku version the js waku test use (done via github actions inputs)\nJustification §\nDeliverables §\n\nfilter\nlightpush\nstore\nrelay\npeer exchange\npeer & connection management\nCI integration\n"},"vac/qa/g/waku/test-automation-nwaku":{"title":"Test Automation nwaku","links":[],"tags":[],"content":"vac:qa::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: 100%\nCC: Alex\n\nDescription §\n\nfilter (t)\nlightpush (t)\nstore (t)\nrelay\npeer exchange\ndiscv5\npeer & connection management\nCI integration\n\nJustification §\nDeliverables §\nFilter §\n- https://github.com/waku-org/nwaku/pull/2023\n- https://github.com/waku-org/nwaku/pull/2034\n- https://github.com/waku-org/nwaku/pull/2035\n- https://github.com/waku-org/nwaku/pull/2046\n- https://github.com/waku-org/nwaku/pull/2057\n- https://github.com/waku-org/nwaku/pull/2085\n- https://github.com/waku-org/nwaku/pull/2095\n- https://github.com/waku-org/nwaku/pull/2096\n\n* [tests/node/test_wakunode_filter.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_filter.nim)\n* [tests/waku_filter_v2/test_waku_client.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_filter_v2/test_waku_client.nim)\n\nLightpush §\n- https://github.com/waku-org/nwaku/pull/2269\n\n* [tests/node/test_wakunode_lightpush.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_lightpush.nim)\n* [tests/waku_lightpush/test_client.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_lightpush/test_client.nim)\n\nStore §\n- https://github.com/waku-org/nwaku/pull/2234\n- https://github.com/waku-org/nwaku/pull/2235\n- https://github.com/waku-org/nwaku/pull/2240\n\n* [tests/waku_store/test_client](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_store/test_client)\n* [tests/node/test_wakunode_store](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_store)\n\nRelay §\n- https://github.com/waku-org/nwaku/pull/2101\n- https://github.com/waku-org/nwaku/pull/2224\n\n* [tests/waku_relay/test_message_id.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_relay/test_message_id.nim)\n* [tests/waku_relay/test_protocol.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_relay/test_protocol.nim)\n\nPeer Exchange §\n- https://github.com/waku-org/nwaku/pull/2464\n\n* [tests/node/test_wakunode_peer_exchange.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_peer_exchange.nim)\n* [tests/test_relay_peer_exchange.nim (partial)](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/test_relay_peer_exchange.nim (partial))\n* [tests/waku_peer_exchange/test_protocol.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_peer_exchange/test_protocol.nim)\n* [tests/waku_peer_exchange/test_rpc_codec.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_peer_exchange/test_rpc_codec.nim)\n\nPeer & Connection Management §\n- https://github.com/waku-org/nwaku/pull/2321\n- https://github.com/waku-org/nwaku/pull/2566\n\n* [tests/node/peer_manager/peer_store/test_migrations.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/peer_manager/peer_store/test_migrations.nim)\n* [tests/node/peer_manager/peer_store/test_peer_storage.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/peer_manager/peer_store/test_peer_storage.nim)\n* [tests/node/peer_manager/peer_store/test_waku_peer_storage.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/peer_manager/peer_store/test_waku_peer_storage.nim)\n* [tests/node/test_wakunode_peer_manager.nim](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/node/test_wakunode_peer_manager.nim)\n\nDiscv5 §\n- https://github.com/waku-org/nwaku/pull/2487\n\n* [tests/waku_discv5/test_waku_discv5.nim (refactor and implementation)](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_discv5/test_waku_discv5.nim (refactor and implementation))\n* [tests/waku_enr/test_sharding.nim (refactor)](https://github.com/waku-org/nwaku/blob/840e012294d8fba7f989c87a6f69689fbd397c92/tests/waku_enr/test_sharding.nim (refactor))\n\nCI Integration §\n- None\n"},"vac/qa/g/waku/test-automation-rln":{"title":"Test Automation RLN","links":[],"tags":[],"content":"vac:qa::waku:test-automation-rln §\n\n%%{ \r\n init: { \r\n 'theme': 'base', \r\n 'themeVariables': { \r\n 'primaryColor': '#BB2528', \r\n 'primaryTextColor': '#fff', \r\n 'primaryBorderColor': '#7C0000', \r\n 'lineColor': '#F8B229', \r\n 'secondaryColor': '#006100', \r\n 'tertiaryColor': '#fff' \r\n } \r\n } \r\n}%%\r\ngantt\r\n tickInterval 1month\r\n dateFormat YYYY-MM-DD \r\n section Status\r\n Test Automation RLN: 2024-01-01, 2024-05-31\n\n\nstatus: 100%\nCC: Roman, Florin, Alex\n\nDescription §\n\nnwaku unit tests\njs-waku unit tests\ninterop off-chain tests\ninterop on-chain tests\n\nJustification §\nDeliverables §\nCode: §\n\nhttps://github.com/waku-org/waku-interop-tests/blob/master/tests/relay/test_rln.py\nhttps://github.com/waku-org/waku-interop-tests/blob/master/src/steps/rln.py\nhttps://github.com/waku-org/nwaku/pull/2356\nhttps://github.com/waku-org/nwaku/pull/2639\nhttps://github.com/waku-org/go-waku/pull/1003\nhttps://github.com/waku-org/go-waku/pull/1009\nhttps://github.com/waku-org/waku-simulator/pull/72\n\nIssues: §\n\nhttps://github.com/waku-org/nwaku/issues/2662\nhttps://github.com/waku-org/nwaku/issues/2837\nhttps://github.com/waku-org/nwaku/issues/2422\nhttps://github.com/waku-org/nwaku/issues/2602\nhttps://github.com/waku-org/nwaku/issues/2606\nhttps://github.com/waku-org/nwaku/issues/2901\nhttps://github.com/waku-org/nwaku/issues/2942\nhttps://github.com/waku-org/nwaku/issues/2822\nhttps://github.com/waku-org/nwaku/issues/2764\nhttps://github.com/waku-org/nwaku/issues/2763\nhttps://github.com/waku-org/nwaku/issues/2762\nhttps://github.com/waku-org/nwaku/issues/2743\nhttps://github.com/waku-org/nwaku/issues/2742\nhttps://github.com/waku-org/nwaku/issues/2822\nhttps://github.com/waku-org/nwaku/issues/2757\nhttps://github.com/waku-org/nwaku/issues/2946\nhttps://github.com/waku-org/nwaku/issues/2949\nhttps://github.com/waku-org/waku-simulator/issues/76\n"},"vac/qa/g/waku/test-automation-sharding":{"title":"Test Automation Sharding","links":[],"tags":[],"content":"vac:qa::waku:test-automation-sharding §\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 Sharding: 2024-01-01, 2024-04-30\n\n\nstatus: 100%\nCC: Roman, Florin, Alex\n\nDescription §\n\nnwaku unit tests\ngowaku unit tests\njs-waku unit tests\ninterop sharding tests\n\nJustification §\nDeliverables §\n\n\ngowaku:\n\nhttps://github.com/waku-org/go-waku/commit/a453c027b71cbf8d1b01d009e769d1b7d0faa8b5\n\n\n\ninterop:\n\nhttps://github.com/waku-org/waku-interop-tests/tree/master/tests/sharding\n\n\n\njs-waku:\n\nhttps://github.com/waku-org/js-waku/tree/master/packages/tests/tests/sharding\nhttps://github.com/waku-org/js-waku/blob/master/packages/utils/src/common/sharding.spec.ts\n\n\n\nnwaku:\n\nhttps://github.com/waku-org/nwaku/pull/2603\n\n\n"},"vac/qa/g/waku/test-automation-status-go-cli-2":{"title":"Status-go CLI Testing 2","links":[],"tags":[],"content":"vac:qa::waku:status-go-cli-testing-2 §\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 Status-go CLI Testing 2: 2024-08-19, 2024-12-31\n\n\nstatus: 0%\nCC: Florin\n\nDescription §\n\nReview the current test coverage of chat functionalities in status-go and proceed with further coverage. Start with community creation and usage in dedicated shards\nReview testing in status-go related to chat functionalities that rely on external systems (e.g., Waku fleet) and migrate them to an interoperable testing framework. Decouple CI tests from external/unreliable fleets\nTBD (discussions are still ongoing, Hanno will reach out to Status people to define the requirements)\n\nJustification §\nDeliverables §"},"vac/qa/g/waku/test-automation-status-go-cli":{"title":"Status-go CLI Testing","links":[],"tags":[],"content":"vac:qa::waku:status-go-cli-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 Status-go CLI Testing: 2024-06-01, 2024-09-02\n\n\nstatus: 100%\nCC: Florin\n\nDescription §\n\nTesting the reliability of message sending via the status-go CLI tool. See details\nTicket\nPotential tool to use\n\nJustification §\nDeliverables §\n\nCreated new framework that:\n\nbuilds and runs nodes using status cli tool\nprovides API to interact with different features\nruns tests for all requested features:\n\ncontact_request\ncreate_private_groups\nfetch_community\njoin_community\nleave_community\none_to_one_messages\nprivate_group_messages\n\n\nreuses communities to not clout the staging env\nruns each night on status master branch\ngenerates test report with history: https://status-im.github.io/status-cli-tests/122/\nfound multiple issues that are under investgation by Pablo\n\n\nAbility to simulate for all the above scenarios:\n\nLatency\nPacket loss\nLow bandwith\nHybernation\n\n\n\nPR list: §\n\nhttps://github.com/status-im/status-cli-tests/pull/1\nhttps://github.com/status-im/status-cli-tests/pull/2\nhttps://github.com/status-im/status-cli-tests/pull/3\nhttps://github.com/status-im/status-cli-tests/pull/4\nhttps://github.com/status-im/status-cli-tests/pull/5\nhttps://github.com/status-im/status-cli-tests/pull/6\n"},"vac/qa/g/waku/test-plan-rln":{"title":"Test Plan RLN","links":[],"tags":[],"content":"vac:qa::waku:test-plan-rln §\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 Plan RLN: 2023-02-01, 2024-02-29\n\n\nstatus: 100%\nCC: Florin\n\nDescription §\nTest plan for the Waku RLN relay.\nJustification §\nDeliverables §\n\nRLN Relay test plan\n"},"vac/qa/g/waku/test-plan-sharding":{"title":"Test Plan Sharding","links":[],"tags":[],"content":"vac:qa::waku:test-plan-sharding §\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 Plan RLN: 2023-12-01, 2024-02-29\n\n\nstatus: 100%\nCC: Florin\n\nDescription §\nTest plan for the Waku Sharding.\nJustification §\nDeliverables §\n\nSharding Test plan\n"},"vac/qa/g/waku/test-plans":{"title":"Test Plans","links":[],"tags":[],"content":"vac:qa::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: 100%\nCC: Florin\n\nDescription §\nunit + integration test\n(contains actually understanding the protocols, critically engage with the protocols)\n(instruct the engineer)\n\nfilter\nlightpush\nstore\nrelay\npeer exchange\ndiscv5\npeer & connection management\n\nJustification §\nDeliverables §\n\ntest plans\n"},"vac/qa/g/waku/ws-stress-testing":{"title":"WebSockets Stress Testing","links":[],"tags":[],"content":"vac:qa::waku:ws-stress-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 WebSockets Stress Testing: 2024-03-18, 2024-12-31\n\n\nstatus: 0%\nCC: Florin, Roman\n\nDescription §\n[WIP] : This milestone is designated as a specific request from the Waku Team, focusing on conducting a stress test to evaluate the robustness and reliability of the nim-websocket implementation versus HTTP.\n(more info will be added once the Waku 2024 milestones are finalized)\nJustification §\nDeliverables §"},"vac/qa/index":{"title":"QA Service Unit","links":["vac/qa/g/waku/test-plans","vac/qa/g/waku/test-plan-rln","vac/qa/g/waku/test-plan-sharding","vac/qa/g/waku/test-automation-js-waku","vac/qa/g/waku/test-automation-nwaku","vac/qa/g/waku/test-automation-rln","vac/qa/g/waku/test-automation-sharding","vac/qa/g/waku/test-automation-go-waku","vac/qa/g/waku/interop-testing","vac/qa/g/waku/interop-testing-02","vac/qa/g/waku/maintenance-js-waku","vac/qa/g/waku/maintenance-nwaku","vac/qa/g/waku/maintenance-go-waku","vac/qa/g/waku/ws-stress-testing","vac/qa/g/waku/test-automation-status-go-cli","vac/qa/g/waku/test-automation-status-go-cli-2","vac/qa/g/vac/test-automation-nim-libp2p","vac/qa/g/vac/test-automation-nim-tooling","vac/qa/g/nomos/test-automation-cryptarchia","vac/qa/g/nomos/test-automation-data-availability"],"tags":["dst","vac"],"content":"vac:qa:: §\n\nwaku: §\n\n test-plans\n test-plan-rln\n test-plan-sharding\n test-automation-js-waku\n test-automation-nwaku\n test-automation-rln\n test-automation-sharding\n test-automation-go-waku\n interop-testing\ninterop-testing-02\nmaintenance-js-waku\nmaintenance-nwaku\nmaintenance-go-nwaku\nws-stress-testing\n test-automation-status-go-cli\ntest-automation-status-go-cli-2\n\nvac: §\n\ntest-automation-nim-libp2p\ntest-automation-nim-tooling\n\nnomos: §\n\ntest-automation-cryptarchia\ntest-automation-data-availability\n"},"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-vote-2-3rds-vote-aggregation-specification","vac/rfc/rfc/nomos/specs-init","vac/rfc/rfc/waku/waku-keystore","vac/rfc/rfc/waku/core-rfc-updates","vac/rfc/rfc/vac/rfc-process-update","vac/rfc/rfc/vac/rfc-index","vac/rfc/rfc/nomos/carnot-threat-model-informational","vac/rfc/rfc/nomos/inter-chain-protocol-specification","vac/rfc/rfc/nomos/multi-leader-and-multi-overlay-carnot-specification"],"tags":["rfc","vac"],"content":"vac:rfc: §\n\nrfc:status: §\n\n port-status-specs\n\nrfc:nomos: §\n\n carnot-specification\n carnot-vote-2-3rds-vote-aggregation-specification\nspecs-init\n\nrfc:codex: §\n\nspecs-init\n\nrfc:waku: §\n\n waku-keystore\ncore-rfc-updates\n\nrfc:vac: §\n\n rfc-process-update\nrfc-index\n\nicebox §\n\ncarnot-threat-model-informational\ninter-chain-protocol-specification\nmulti-leader-and-multi-overlay-carnot-specification\n"},"vac/rfc/rfc/codex/specs-init":{"title":"specs-init","links":[],"tags":[],"content":"Init the effort of specifying Codex protocols.\nGo through existing docs and identify."},"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/nomos/specs-init":{"title":"specs-init","links":[],"tags":[],"content":"Init the effort of specifying Nomos protocols.\nGo through existing docs and identify."},"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/vac/rfc-index":{"title":"rfc-index","links":[],"tags":[],"content":"Build up and maintain rfc.vac.dev and https://github.com/vacp2p/rfc-index"},"vac/rfc/rfc/vac/rfc-process-update":{"title":"rfc-process-update","links":[],"tags":[],"content":"RFC process update"},"vac/rfc/rfc/waku/core-rfc-updates":{"title":"core-rfc-updates","links":[],"tags":[],"content":"Waku core RFC updates"},"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/contracts-formal-verification":{"title":"Contracts Formal Verification","links":[],"tags":[],"content":"vac:sc::codex:contracts-formal-verification §\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 Contracts Formal Verification: 2024-07-01, 2024-10-01\n\n\nstatus: 0%\nCC: r4bbit, gravityblast\n\nDescription §\nThis milestone entails the formal verification of the Codex marketplace smart contracts.\nThis should be done together with the Codex team as well as with Certora.\nIdeally, this will be done by regularly meeting with Certora and reviewing the rules that have been implemented by the Smart Contracts team.\nJustification §\nCodex is planning to launch a first version of their network by the end of 2024.\nTo ensure their marketplace system is secure they need to have their code audited and formally verified.\nDeliverables §\n\nApplication Properties for the marketplace smart contracts\nImplementation of properties in CVL rules\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: 100%\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/finance/access-control-safe-support":{"title":"Access Control Safe Support","links":[],"tags":[],"content":"vac:sc::finance:access-control-safe-support §\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 Contracts Formal Verification: 2024-06-01, 2024-12-31\n\n\nstatus: 0%\nCC: r4bbit\n\nDescription §\nThe finance team deploys various Safe multisig wallets for different finance strategies to generate yield.\nThese Safes follow a strict access control architecture by leveraging the Zodiac roles modifier module by Gnosis Guild.\nThe Smart Contracts team helps deploying these contracts as well as auditing any changes done to the deployment scripts.\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-batch-tx-ext":{"title":"Community Contracts CollectibleV1 Batch transaction Extension","links":[],"tags":[],"content":"vac:sc::status:community-contracts-batch-tx-ext §\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 CollectibleV1 Batch transaction Extension: 2024-02-19, 2024-03-21\n\n\nstatus: 100%\nCC: r4bbit\n\n**This milestone is updated on weekly basis. For a more up-to-date status head over to the milestone on GitHub.\nDescription §\nThis milestone extends the available token contracts that Status communities use to implement things like token gated permissions.\nAt the time of creating this milestone, two types of token contracts existed:\n\nCommunityERC20\nCollectibleV1\n\nThese are essentially ERC20 and ERC721 respectively, with some additional functionality, required by Status.\nIn this milestone, we’re adding support for batch transacting tokens of the BaseToken which CollectibleV1 is derived from.\nJustification §\nStatus Desktop needs to allow community owners to first deploy and mint a certain amount of their own token and then batch transact them to other accounts later on.\nRight now the only way to do this is to either use the contract’s mintTo() function, which mints to a list of accounts right away, or to perform multiple transactions for every token to be sent.\nDeliverables §\n\nBaseToken/CollectibleV1 batch transfer functions\nTests\nDocumentation\nApplication properties\nFormal verification\n"},"vac/sc/g/status/community-contracts-curation-dapp-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: 100%\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/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":"Community Contracts Token Import","links":[],"tags":[],"content":":sc:g:status:communty-contracts-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: 16%\nCC: Andrea\n\n**This milestone is updated on weekly basis. For a more up-to-date status head over to the milestone on GitHub.\nDescription §\nThis milestone is part of the effort to create “Community Vaults”.\nCommunity Vaults allow Status users to create communities that maintain their own token balances and later on allow for airdropping their tokens to other Status users or retail them.\nThis milestone focusses on the “token import”.\nThe naming is a bit misleading, but the basic idea is that users:\n\ncreate Status communities and deploy a “vault” contract\nthe vault contract acts as a wallet for the community\nany user can send ERC20 and ERC721 tokens to the vault\n\nJustification §\nDeliverables §\n\nCommunityVault smart contract implementation\nMigration/upgrade strategy for vaults\nAbility for users to deposit/import tokens to vault\nTests\nDocumentation\nFormal verification\n"},"vac/sc/g/status/community-contracts-vault-token-airdrop":{"title":"Community Vaults - Token Airdrop","links":[],"tags":[],"content":":sc:g:status:community-contracts-vault-token-airdrop §\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: Andrea\n\n**This milestone is updated on weekly basis. For a more up-to-date status head over to the milestone on GitHub.\nDescription §\nThis milestone focuses on the airdrop functionality of community vaults.\nThe general idea is that community owners and token masters can airdrop tokens that live in the community vault to other accounts and community members.\nPart of this milestone is to figure out which airdrop strategy makes most sense and then implementing it.\nJustification §\nDeliverables §\n\nAirdrop functionality in existing vault contracts\nDocumentation\nTests\nFormal verification\n"},"vac/sc/g/status/ens-usernames-maintenance":{"title":"ENS Usernames contracts maintenance","links":[],"tags":[],"content":"vac:sc::status:ens-usernames-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 Contracts Formal Verification: 2024-06-01, 2024-12-31\n\n\nstatus: 0%\nCC: Ricardo, r4bbit\n\nDescription §\nMaintaining and deploying the ens-usernames smart contracts, as well as ensuring their code is up to date.\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/minime-token-enhancement":{"title":"MiniMe 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: 100%\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/minime-token-maintenance":{"title":"MiniMe 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-v1":{"title":"Status Staking Contract V1","links":[],"tags":[],"content":"vac:sc::status:staking-contract-v1 §\n\nstatus: 52%\nCC: Ricardo\n\nDescription §\n**This milestone is updated on weekly basis. For a more up-to-date status head over to the milestone on GitHub.\nThis milestone focusses on the core functionality of the staking protocol.\nMeaning, any protocol characteristics and features that are needed for the protocol to function need to be properly implemented and tested.\nThis includes:\n\nStaking SNT and generating multiplier points\nCollecting and claiming rewards\nUnstaking funds\nMigration / upgrade to newer stake vaults\n\nThe milestone is considered done when the above is implemented, tested, documented and formally verified.\nJustification §\nDeliverables §\n\nSmart contracts implementation\nMigration strategy of vaults and stake managers\nTests\nDocumentation\nFormal verification\n"},"vac/sc/g/status/swap-aggregator":{"title":"Status Swap Aggregator","links":[],"tags":[],"content":"vac:sc::status:swap-aggregator §\n\nstatus: 0%\nCC: TBD\n\nDescription §\nThe exact details of this milestone are yet to be discussed. However, the general idea is to research if we could build a swap aggregator similar to MetaMask Swap and Rainbow Swap for Status.\nResearch has to be done in what existing system exist, how they work and how they capture revenue. Ideally we find a model that works for Status as well.\nJustification §\nBoth, MetaMask and Rainbow Wallet are making most of their revenue with their Swap protocols. With enough users, a small percentage of every trade could accumulate a significant amount of reoccuring revenue.\nDeliverables §\nTBD"},"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: 100%\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-contracts-curation-dapp-contracts","vac/sc/g/status/community-contracts-vault-token-airdrop","vac/sc/g/status/community-contracts-batch-tx-ext","vac/sc/g/status/snt-optimism-bridge","vac/sc/g/status/minime-token-enhancement","vac/sc/g/status/minime-token-maintenance","vac/sc/g/status/governance-contract-mvp","vac/sc/g/status/staking-contract-mvp","vac/sc/g/status/staking-contract-v1","vac/sc/g/status/staking-contract-maintenance","vac/sc/g/status/swap-aggregator","vac/sc/g/status/ens-usernames-maintenance","vac/sc/g/codex/review-codex-contracts","vac/sc/g/codex/contracts-formal-verification","vac/sc/g/vac/secureum-upskilling","vac/sc/g/vac/rln-contract-support","vac/sc/g/finance/access-control-safe-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\n community-contracts-curation-dapp-contracts\ncommunity-contracts-vault-token-airdrop\n community-contracts-batch-tx-ext\n SNT-optimism-bridge\n minime-token-enhancement\nminime-token-maintenance\ngovernance-contract-mvp\n staking-contract-mvp\nstaking-contract-v1\nstaking-contract-maintenance\nswap-aggregator\nens-usernames-maintenance\n\ncodex: §\n\n review-codex-contracts\ncontracts-formal-verification\n\nvac: §\n\n secureum-upskilling\nrln-contract-support\n\nfinance: §\n\naccess-control-safe-support\n"},"vac/tke/g/codex/bandwidth-incentives":{"title":"Codex Bandwidth Incentives","links":[],"tags":[],"content":"vac:tke::codex:bandwidth-incentives §\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\tBandwidth Incentives :, 2025-01-01, 2025-07-01\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nTBD\nJustification §\nAs part of Codex Technical Milestones #4 (“Bandwidth Incentives”).\nDeliverables §\n\nModeling and Simulations\nReport\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nReview of Bandwidth Provider role\nAnalysis of Bandwidth Provider costs, pricing, behavior and expectations\nEconomics and game theoretical analyses of the Bandwidth Providers\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/cdx-fees":{"title":"Codex Fee Mechanism","links":["vac/tke/g/codex/cdx","vac/tke/g/codex/cdx-insurance","vac/tke/g/codex/cdx-lender"],"tags":[],"content":"vac:tke::codex:cdx-fees §\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\tFees :, 2024-02-01, 2024-07-01\n\n\nstatus: 95%\nCC: Frederico\n\nDescription §\nUnderstand the mechanisms to implement protocol fees, e.g. burn-and-mint equilibrium model;\nJustification §\nUnderstand the security of the system. As part of the Codex Technical Milestone #5 (“Tokenomics”).\nDeliverables §\n\nSpecific parts of three chapters of the Codex Litepaper (Use Cases, Contract Lifecycle, and CDX Tokenomics) (the milestones cdx, cdx-insurance, and cdx-lender cover the remaining parts of these chapters).\nOne section of the Codex Whitepaper (CDX Tokenomics)\n\nTracking Metrics §\nCompletion of the respective sections in the Codex Litepaper and Whitepaper.\nWork breakdown §\nDefinition of value accrual, capture and incentive mechanisms of the Codex protocol.\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/cdx-insurance":{"title":"Codex Insurance Mechanism Analysis","links":["vac/tke/g/codex/cdx","vac/tke/g/codex/cdx-fees","vac/tke/g/codex/cdx-lender"],"tags":[],"content":"vac:tke::codex:cdx-insurance §\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\tInsurance Mechanism :, 2024-02-01, 2024-07-01\n\n\nstatus: 95%\nCC: Frederico, Juan\n\nDescription §\nMechanisms to make the system more stable\nJustification §\nUnderstand the roles that impact the performance and security of the protocol. As part of the Codex Technical Milestone #5 (“Tokenomics”).\nDeliverables §\n\nSpecific parts of three chapters of the Codex Litepaper (Use Cases, Contract Lifecycle, and CDX Tokenomics) (the milestones cdx, cdx-fees, and cdx-lender cover the remaining parts of these chapters).\nOne section of the Codex Whitepaper (CDX Tokenomics)\n\nTracking Metrics §\nCompletion of the respective sections in the Codex Litepaper and Whitepaper.\nWork breakdown §\n\nDefinition of insurance role.\nAnalysis of CDX impact on system security.\nComparison against protocols which don’t have any embeeded stabilization mechanism.\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/cdx-lender":{"title":"Codex Lender Analysis","links":["vac/tke/g/codex/cdx","vac/tke/g/codex/cdx-fees","vac/tke/g/codex/cdx-insurance"],"tags":[],"content":"vac:tke::codex:cdx-insurance §\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\tLender :, 2024-05-01, 2024-07-01\n\n\nstatus: 95%\nCC: Juan\n\nDescription §\nDesign and modeling of the lender role\nJustification §\nUnderstand the roles that impact the performance and security of the protocol. As part of the Codex Technical Milestone #5 (“Tokenomics”).\nDeliverables §\n\nSpecific parts of three chapters of the Codex Litepaper (Use Cases, Contract Lifecycle, and CDX Tokenomics) (the milestones cdx, cdx-fees, and cdx-insurance cover the remaining parts of these chapters).\nOne section of the Codex Whitepaper (CDX Tokenomics)\n\nTracking Metrics §\nCompletion of the respective sections in the Codex Litepaper and Whitepaper.\nWork breakdown §\n\nDefinition of insurance role.\nAnalysis of CDX impact on system security.\nComparison against protocols which don’t have any embeeded stabilization mechanism.\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/cdx":{"title":"Analysis of the Codex Token","links":["vac/tke/g/codex/cdx-fees","vac/tke/g/codex/cdx-insurance","vac/tke/g/codex/cdx-lender"],"tags":[],"content":"vac:tke::codex:cdx §\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\tCDX :, 2024-02-01, 2024-07-01\n\n\nstatus: 95%\nCC: Frederico\n\nDescription §\nCodex token as utility token for all participants (collateral and payment), impact on system security.\nJustification §\nDevelopment of Codex own utility token. As part of the Codex Technical Milestone #5 (“Tokenomics”).\nDeliverables §\n\nSpecific parts of three chapters of the Codex Litepaper (Use Cases, Contract Lifecycle, and CDX Tokenomics) (the milestones cdx-fees, cdx-insurance, and cdx-lender cover the remaining parts of these chapters).\nOne section of the Codex Whitepaper (CDX Tokenomics)\n\nTracking Metrics §\nCompletion of the respective sections in the Codex Litepaper and Whitepaper.\nWork breakdown §\n\nDefinition and analysis of Codex economy\nCDX as utility token for all participants (collateral and payment).\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/contract-defaults":{"title":"Codex Contract Default","links":["vac/tke/g/codex/contract-finalization","vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:contract-defaults §\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\tContract Defaults :, 2024-10-01, 2024-12-31\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDesign of the systemic slashing mechanism.\nJustification §\nAs part of Codex Technical Milestones #3 (“Marketplace Interactions”).\nDeliverables §\n\nModeling and Simulations of the slashing mechanisms\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-finalization, contract-initiation, contract-matching, proof-aggregators, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nReview consequences for SPs, Clients and PAs\nEconomic and game theoretical analysis of these consequences\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/contract-finalization":{"title":"Codex Contract Finalization","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:contract-finalization §\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\tContract Finalization :, 2024-10-01, 2025-01-01\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nSPs & Users obligations, data retrieval incentives, collateral retrieval, contract extension.\nJustification §\nAs part of the contract finalization process. As part of Codex Technical Milestones #3 (“Marketplace Interactions”).\nDeliverables §\n\nModeling and Simulations of the data retrieval process\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, proof-aggregators, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/contract-initiation":{"title":"Codex Contract Initiation","links":["vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:contract-initiation §\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\tContract Initiation :, 2024-10-01, 2024-12-31\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nMechanics of Codex contract initiation.\nJustification §\nAs part of Codex Technical Milestones #3 (“Marketplace Interactions”).\nDeliverables §\n\nModeling and Simulations of the Client behavior\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-matching, contract-defaults, contract-finalization, proof-aggregators, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nDefinition of default settings\nFacilitate the matching of pricing and collateral size\nAnalysis of client payment (full vs. partial upfront)\nAnalysis of potential gamifications and penalties\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/contract-matching":{"title":"Codex Contract Matching","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:contract-matching §\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\tContract Matching :, 2024-10-01, 2024-12-31\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine how slots are reserved and filled.\nJustification §\nAs part of the slot reservation mechanism. As part of Codex Technical Milestones #3 (“Marketplace Interactions”).\nDeliverables §\n\nModeling and Simulations of the slot reservation mechanism\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-defaults, contract-finalization, proof-aggregators, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nEconomics and game theoretical analysis of the Slot Reservation Mechanism\n\n### Perceived Risks\nTechnical and legal constraints."},"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, 2024-02-04\n\n\nstatus: 100%\nCC: Matty, Frederico, Martin\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/codex/proof-aggregators":{"title":"Codex Proof Aggregators","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:proof-aggregators §\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\tProof Aggregators :, 2024-07-01, 2024-10-01\n\n\nstatus: 10%\nCC: Frederico\n\nDescription §\nEconomics of the proof aggregator (incentives, costs, pricing).\nJustification §\nAs part of Codex Technical Milestones #1 (“Proof Aggregation”) and #2 (“Aggregator Network”).\nDeliverables §\n\nModeling and Simulations of the Proof Aggregator actor and process\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, contract-finalization, recovery-auction, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nDefinition of the Proof Aggregator role\nAnalysis of PA costs and pricing\nDefinition of the Proof Aggregation economy\nAnalysis of the interactions between PAs\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/recovery-auction":{"title":"Codex Recovery Auction","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/slot-repair","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:recovery-auction §\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\tRecovery Auction :, 2024-10-01, 2024-12-31\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine details of the auction mechanisms for the slot recovery.\nJustification §\nAs part of Codex Technical Milestones #6 (“Data Repair”).\nDeliverables §\n\nModeling and Simulations of the auction mechanism\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, contract-finalization, proof-aggregators, slot-repair, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nDefine what triggers and ends the auction recovery mechanism\nDesign the Dutch Auction\nEvaluate impact on CDX price stability\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/slot-repair":{"title":"Codex Slot Repair","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/tax-system"],"tags":[],"content":"vac:tke::codex:slot-repair §\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\tSlot Repair :, 2024-10-01, 2025-01-01\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDesign of the slot recovery mechanism.\nJustification §\nAs part of Codex Technical Milestones #6 (“Data Repair”).\nDeliverables §\n\nModeling and Simulations of the slot repair mechanism\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, contract-finalization, proof-aggregators, recovery-auction, and tax-system cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nEconomics and game theoretical analysis of the Slot Recovery Mechanism\nDefinition of the trigger of the Recovery Auction\nEnsure data availability.\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/tax-system":{"title":"Codex Tax System","links":["vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/slot-repair"],"tags":[],"content":"vac:tke::codex:tax-system §\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\tTax System :, 2024-07-01, 2024-10-01\n\n\nstatus: 10%\nCC: Frederico\n\nDescription §\nJustification §\nAs part of Codex Technical Milestones #1 (“Proof Aggregation”) and #2 (“Aggregator Network”).\nDeliverables §\n\nModeling and Simulations of the CDX stability\nOne section of the Codex Litepaper “Modeling” chapter (the milestones contract-initiation, contract-matching, contract-defaults, contract-finalization, proof-aggregators, recovery-auction, and slot-repair cover the remaining parts of this chapter).\n\nTracking Metrics §\n\nTimely delivery of the report\nAgreement with Codex team and stakeholders\n\nWork breakdown §\n\nDefinition of a tax system\nAnalysis of the application of taxes\nAnalysis of CDX price stability\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/codex/testnet-incentive":{"title":"Codex Testnet Incentives","links":[],"tags":[],"content":"vac:tke::codex:testnet-incentive §\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\tIncentivized Tesnet :, 2024-06-01, 2024-07-01\n\n\nstatus: 40%\nCC: Frederico, Martin, Juan\n\nDescription §\nDesign incentives for testnet.\nJustification §\nAs part of Codex Production Milestone #4 (Codex v1 Mainnet Launch).\nDeliverables §\nReport with analyses of incentives and expected consequences.\nTracking Metrics §\nDelivery of the report, and agreement with team and stakeholders.\nWork breakdown §\n\nDefinition of optimization goals\nDefinition of metrics\nAnalysis of incentives\n\n### Perceived Risks\nTechnical and legal constraints."},"vac/tke/g/finance/growth-models":{"title":"Financial Growth Models","links":[],"tags":[],"content":"vac:tke::finance:growth-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\tdateFormat YYYY-MM-DD\n\tsection Finance\n\t\tGrowth Models :, 2024-02-05, 2024-07-31\n\n\nstatus: 80%\nCC: Martin\n\nDescription §\nAd hoc assistance and consulting the use and further expansion of the growth model.\nJustification §"},"vac/tke/g/finance/real-option-models":{"title":"Finance Real Option Models","links":[],"tags":[],"content":"vac:tke::finance:real-option-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\tdateFormat YYYY-MM-DD\n\tsection Finance\n\t\tReal Option Models :, 2024-02-05, 2024-07-31\n\n\nstatus: 20%\nCC: Frederico\n\nDescription §\nDevelopment of pricing models based real option analysis.\nJustification §"},"vac/tke/g/nomos/cryptarchia-wealth-concentration-estimated-stake":{"title":"Cryptarchia Wealth Concentration Estimated Stake","links":[],"tags":[],"content":"vac:tke::nomos:cryptarchia-wealth-concentration-estimated-stake §\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 :, 2024-02-15, 2024-02-19\n\n\nstatus: 100%\nCC: Frederico\n\nDescription §\nUnderstand whether the algorithm that learns the total stake of the system affects wealth concentration. If so, under which conditions.\nJustification §\nNomos develops a private PoS system."},"vac/tke/g/nomos/cryptarchia-wealth-concentration-known-stake":{"title":"Cryptarchia Wealth Concentration Known Stake","links":[],"tags":[],"content":"vac:tke::nomos:cryptarchia-wealth-concentration-known-stake §\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 :, 2024-02-05, 2024-02-14\n\n\nstatus: 100%\nCC: Frederico\n\nDescription §\nUnderstand whether wealth concentration happens or not in traditional PoS. If so, under which conditions.\nJustification §\nNomos introduces a PoS system."},"vac/tke/g/nomos/delegation-research":{"title":"Nomos Delegation Research","links":[],"tags":[],"content":"vac:tke::nomos:delegation-research §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nUnderstand what other chains are doing with respect to delegation and restaking.\nJustification §\nAs part of Nomos PoS development."},"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, 2024-02-04\n\n\nstatus: 100%\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/nomos/enshrined-delegation":{"title":"Nomos Enshrined Delegation","links":[],"tags":[],"content":"vac:tke::nomos:enshrined-delegation §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine the best way is to incorporate delegation and restaking into Nomos.\nJustification §\nAs part of Nomos PoS development."},"vac/tke/g/nomos/mixnet-incentives":{"title":"Nomos Mixnet Incentives","links":[],"tags":[],"content":"vac:tke::nomos:mixnet-incentives §\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\tMixnet Incentives :, 2024-03-04, 2024-04-03\n\n\nstatus: 1%\nCC: Frederico\n\nDescription §\nSustainable mixnets need to be properly incentivized.\nJustification §\nAs part of Nomos privacy requirements."},"vac/tke/g/nomos/non-private-L2-consensus":{"title":"Nomos Non Private L2 Consensus","links":[],"tags":[],"content":"vac:tke::nomos:non-private-L2-consensus §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nThese will work likely with isolated pools. Since these are pools, would also be important to understand.\nJustification §\nAs part of Nomos development."},"vac/tke/g/nomos/penalizable-actions":{"title":"Nomos Penalizable Actions","links":[],"tags":[],"content":"vac:tke::nomos:penalizable-actions §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine actions that lead to a slash on Nomos.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/rewarded-actions":{"title":"Nomos Rewarded Actions","links":[],"tags":[],"content":"vac:tke::nomos:rewarded-actions §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine actions that lead to rewards on Nomos.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/selfish-behavior":{"title":"Nomos Validator Rewards","links":[],"tags":[],"content":"vac:tke::nomos:selfish-behavior §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nUnderstand what problems can emerge when validators modify the fork choice rule of the protocol to another one that best suits them.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/shared-liquidity":{"title":"Nomos Shared Liquidity","links":[],"tags":[],"content":"vac:tke::nomos:shared-liquidity §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nUnderstand the problem of L2 liquidity fragmentation in general.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/supply-policy":{"title":"Nomos Supply Policy","links":[],"tags":[],"content":"vac:tke::nomos:supply-policy §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine initial supply, distribution, allocations.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/tdc-objectives":{"title":"Nomos TDC Objectives","links":[],"tags":[],"content":"vac:tke::nomos:tdc-objectives §\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\tTDC Objectives :, 2024-02-05, 2024-03-13\n\n\nstatus: 70%\nCC: Frederico\n\nDescription §\nWrite the Objectives & Requirements section of the Token Design Canvas.\nJustification §"},"vac/tke/g/nomos/transaction-fee":{"title":"Nomos Transaction Fee","links":[],"tags":[],"content":"vac:tke::nomos:transaction-fee §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDesign block space pricing mechanism.\nJustification §\nAs part of Nomos PoS development."},"vac/tke/g/nomos/validator-rewards":{"title":"Nomos Validator Rewards","links":[],"tags":[],"content":"vac:tke::nomos:validator-rewards §\n\n\nstatus: 0%\nCC: Frederico\n\nDescription §\nDefine how much tokens are distributed as rewards to block proposers.\nJustification §\nAs part of PoS development."},"vac/tke/g/nomos/whitepaper":{"title":"Nomos Whitepaper","links":[],"tags":[],"content":"vac:tke::nomos:whitepaper §\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\tNomos Whitepaper :, 2024-02-05, 2024-02-29\n\n\nstatus: 100%\nCC: Frederico\n\nDescription §\nProvide feedback.\nJustification §"},"vac/tke/g/status/L2-deployment":{"title":"Status L2 deployment","links":[],"tags":[],"content":"vac:tke::status:L2-deployment §\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\tStatus L2 deployment: 2024-02-05, 2024-05-31\n\n\nstatus: 20%\nCC: Martin\n\nDescription §\nTBD\nJustification §"},"vac/tke/g/status/incentivized-communitities":{"title":"Incentivize Status Communitities","links":[],"tags":[],"content":"vac:tke::status:incentivized-communitities §\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nTBD\nJustification §\nTBD"},"vac/tke/g/status/snt-governance-proposal":{"title":"SNT Governance Proposal","links":[],"tags":[],"content":"vac:tke::status:SNT-governance-proposal §\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 Governance Proposal: 2023-09-01, 2024-06-30\n\n\nstatus: 50%\nCC: Martin\n\nDescription §\n\ntook precedence over SNT litepaper\nfirst draft being prepared for next review with John on 2023/09/12\norganizing snapshot voting\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, 2024-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, 2024-03-30\n\n\nstatus: 90%\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/status/waku-sharding":{"title":"Waku Sharding","links":[],"tags":[],"content":"vac:tke::status:waku-sharding §\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 Waku Sharding: 2024-07-01, 2024-07-30\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nTBD\nJustification §"},"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, 2024-02-04\n\n\nstatus: 100%\nCC: Martin\n\nDescription §\nWaku economic analysis"},"vac/tke/g/waku/general-incentives":{"title":"Waku General Incentives","links":[],"tags":[],"content":"vac:tke::waku:general-incentives §\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nGive feedback and assist Waku’s team in drafting incentivization mechanisms."},"vac/tke/g/waku/rln-membership":{"title":"Waku RLN Membership","links":[],"tags":[],"content":"vac:tke::waku:rln-membership §\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 :, 2024-02-05, 2024-03-30\n\n\nstatus: 30%\nCC: Martin\n\nDescription §\nDesigh a comprehensive strategy for RLN memberships, perhaps following the NFT-like approach. Strategy should consider pricing mechanisms, payment options, dev/node compensation and project sustainability, security, etc."},"vac/tke/g/waku/rln-risks-L2":{"title":"Waku RLN Risks","links":[],"tags":[],"content":"vac:tke::waku:rln-risks-L2 §\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nDrive the discussion around feasibility/risks for RLN on L2, leading to a recommendation of a specific L2."},"vac/tke/g/waku/rln-risks-attacks-vectors":{"title":"Waku RLN Attacks Vectors","links":[],"tags":[],"content":"vac:tke::waku:rln-risks-attacks-vectors §\n\n\nstatus: 0%\nCC: Martin\n\nDescription §\nRisk/attack analysis for RLN; recovery mechanisms."},"vac/tke/g/waku/store-incentives":{"title":"Waku Store Incentives","links":[],"tags":[],"content":"vac:tke::waku:store-incentives §\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 :, 2024-02-05, 2024-03-30\n\n\nstatus: 20%\nCC: Martin\n\nDescription §\nGive feedback and assist Waku’s team in drafting store incentivization MVP."},"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/status/L2-deployment","vac/tke/g/status/waku-sharding","vac/tke/g/status/incentivized-communitities","vac/tke/g/codex/economic-analysis","vac/tke/g/codex/cdx","vac/tke/g/codex/cdx-fees","vac/tke/g/codex/cdx-insurance","vac/tke/g/codex/cdx-lender","vac/tke/g/codex/testnet-incentive","vac/tke/g/codex/proof-aggregators","vac/tke/g/codex/tax-system","vac/tke/g/codex/contract-initiation","vac/tke/g/codex/contract-matching","vac/tke/g/codex/contract-defaults","vac/tke/g/codex/contract-finalization","vac/tke/g/codex/slot-repair","vac/tke/g/codex/recovery-auction","vac/tke/g/codex/bandwidth-incentives","vac/tke/g/nomos/economic-analysis","vac/tke/g/nomos/cryptarchia-wealth-concentration-known-stake","vac/tke/g/nomos/cryptarchia-wealth-concentration-estimated-stake","vac/tke/g/nomos/whitepaper","vac/tke/g/nomos/tdc-objectives","vac/tke/g/nomos/mixnet-incentives","vac/tke/g/nomos/selfish-behavior","vac/tke/g/nomos/rewarded-actions","vac/tke/g/nomos/penalizable-actions","vac/tke/g/nomos/validator-rewards","vac/tke/g/nomos/delegation-research","vac/tke/g/nomos/enshrined-delegation","vac/tke/g/nomos/transaction-fee","vac/tke/g/nomos/supply-policy","vac/tke/g/nomos/shared-liquidity","vac/tke/g/nomos/non-private-L2-consensus","vac/tke/g/waku/economic-analysis","vac/tke/g/waku/rln-membership","vac/tke/g/waku/rln-risks-L2","vac/tke/g/waku/rln-risks-attacks-vectors","vac/tke/g/waku/store-incentives","vac/tke/g/waku/general-incentives","vac/tke/g/finance/growth-models","vac/tke/g/finance/real-option-models"],"tags":["p2p","vac"],"content":"vac:tke:: §\n\nstatus: §\n\nsnt-lightpaper\nSNT-governance-proposal\nSNT-staking\nL2-deployment\nwaku-sharding\nincentivized-communitities\n\ncodex: §\n\neconomic-analysis\ncdx\ncdx-fees\ncdx-insurance\ncdx-lender\ntestnet-incentive\nproof-aggregators\ntax-system\ncontract-initiation\ncontract-matching\ncontract-defaults\ncontract-finalization\nslot-repair\nrecovery-auction\nbandwidth-incentives\n\nnomos: §\n\neconomic-analysis\ncryptarchia-wealth-concentration-known-stake\ncryptarchia-wealth-concentration-estimated-stake\nwhitepaper\ntdc-objectives\nmixnet-incentives\nselfish-behavior\nrewarded-actions\npenalizable-actions\nvalidator-rewards\ndelegation-research\nenshrined-delegation\ntransaction-fee\nsupply-policy\nshared-liquidity\nnon-private-L2-consensus\n\nwaku: §\n\neconomic-analysis\nrln-membership\nrln-risks-L2\nrln-risks-attacks-vectors\nstore-incentives\ngeneral-incentives\n\nfinance: §\n\ngrowth-models\nreal-option-models\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"},"vac/updates/2023-11-27":{"title":"2023-11-27 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDig into the secure/noise part of libp2p\nWrite a prologue with the client and server certificates in the noise protocol\n\n\nnimlibp2p:vac:maintenance\n\nYamux window size configurable\nFix yamux / relay interaction; Add 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(yamux): yamux uses wrong direction during dcutr https://github.com/status-im/nim-libp2p/pull/992\nfix(multiaddress): add quic-v1 multiaddress support https://github.com/status-im/nim-libp2p/pull/988\nfix(dcutr): handle tcp/p2p addresses https://github.com/status-im/nim-libp2p/pull/989\nfix(identify): do not add p2p and relayed addrs to observed addr manager https://github.com/status-im/nim-libp2p/pull/990\n\n\nnimlibp2p:vac:maintenance\n\nnew issue: Cannot run tests on Apple M1 MacOS https://github.com/status-im/nim-libp2p/issues/993\nResearch VM hosting providers - Akash Network added https://docs.google.com/spreadsheets/d/1VL6QpDdBgYC1Ld0Nr-cpNv9bRht3nQkBQUF1pNerBDs/edit?usp=sharing\nCI workflow is failing frequently Testing Nimble lock file - resolving Nimble install issues on Windows\n\nhttps://github.com/status-im/nim-libp2p/issues/975\nhttps://github.com/status-im/nim-libp2p/tree/fix/ci-workflow-stability\nhttps://discord.com/channels/864066763682218004/1172153963559260231\nfix: move workflows for Nim Devel and legacy i386 from “Daily” -> comments about to be resolved\nshould the version be pinned?: https://github.com/status-im/nim-libp2p/pull/968\n\n\n\n\n\nvac:tke: §\n\nvac:tke::nomos:economic-analysis\n\nFrederico has been joining in remotely to relevant talks at Nomos offsite\nContinuing research of PoS economics and token distributions, posted some initial simulation results, evolving further (@Frederico)\n\n\nvac:tke::waku:economic-analysis\n\nMartin returning from DevConnect and Waku offsite, will formulate followups for next steps\nShare EigenTrust python implementation w/ Sergei, and adapt for client-server type systems (@Matty)\n\n\n\nvac:dst: §\n\nanalysis-shadow:vac:shadow-gossipsub-analysis\n\ncont’ simulations (500kb msgs, 4 chunks, 250 nodes)\n\n\neng-10ktool:vac:bandwidth-test:\n\nWrite experiments in notion\nInvestigate CPU bottleneck in 3rd machine\nChanged waku deployment to work in batches\nSyncronized gossipsub nodes injection for better comparisons with waku\nRun 1k simulation for comparison and gather data\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nImplemented and merged 3rd and 4th PRs :\nmake framework support dynamic number of nodes\n\nadd multi-node tests (that work on any number of nodes)\nsubscribe / unsubscribe tests\nreached 43 tests\n\n\nIssues reported:\n\nre-subscribe to previously unsubscribed topic fails\nlogs are floaded\n\n\nstarted writing document on Waku implementations diffs\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nRemove duplicated code\n\nPR\n\n\nFinish implementing store tests\n\nPR 1\nPR 2\n\n\nSqlite Bug: Not saving WakuMessage.ephemeral\n\nIssue\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nwrote 5 tests related to filter push and relay - invalid data https://github.com/waku-org/go-waku/pull/916\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nGetting familiar with treekem as a possible solution for the group chat scenario.\nWrite a document on TreeKEM vs ADKG\n\n\nadmin/misc\n\nStarted a comparison between Waku specifications https://www.notion.so/Comparison-Waku-35-Waku-37-5ee9aac6cc72466a95d624865a561da6\n\n\nzerokit:vac:maintenance\n\nworked on a PR to update multiplier (https://github.com/vacp2p/zerokit/pull/224)\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nWorked on getting the Cetora CI integration into mergable state and landed it https://github.com/vacp2p/minime/pull/43\nAdded Certora CI integration to our foundry template https://github.com/vacp2p/foundry-template/pull/10\nWorking through the Certora tutorials to learn CVL\n\n\nstatus:communites-contracts-maintenance\n\nAdded Certora CI integration and reactivate old formal verification rules https://github.com/status-im/communities-contracts/pull/24\nfinished testing CommunityVault https://github.com/status-im/communities-contracts/pull/22\n\n\nstatus:status-network-token-v2\n\nRefactored token controller and added destroyTokens API https://github.com/status-im/status-network-token-v2/pull/1\n\n\nstatus:governance-contract-mvp\n\nimplement Proposal.sol contract\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nWorking on a review of all L2 and Zk Rollups that are trying to do “state separation”\nResearching how to build a UTXO to Account based adapter and viceversa\nCompiled documents on research topics: Verkle trees, enhanced privacy\nstudied about dual architecture L2 from its docs; created a report about it; includes some questions\n\n\nproofsystems:vac:benchmarks\n\nFixed comments on a PR for a GWC implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/17\nResearch PoC ProtoGalaxy implementation (https://github.com/arnaucube/protogalaxy-poc)\nReviewed Halo2-GWC PR.\nReviewed Halo2-SHPLONK PR.\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStarted researching BaseFold (https://eprint.iacr.org/2023/1705.pdf)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nResults for different machines were not found for given signatures for latency. Probably the logs are processed in different timewindow; investigating\n\n\nvalpriv:vac:tor-push-paper\n\nFinalizing and updating changes, better figures\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nworked on different performance evaluation metrics, and finalized their implementation in simulation scripts. The details are reflected in ‘Results and Discussion’ section\nFinalized simulation scenarios, and corresponding theoratical estimates. The details are reflected in ‘Results and Discussion’ section\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nUpdated photo names and location in 71/STATUS-PUSH-NOTIFICATION RFC https://github.com/vacp2p/rfc/pull/629\napply feedback\nwhisper mailserver - https://github.com/jimstir/rfc/blob/mailserver1/content/docs/rfcs/mailserver.md https://github.com/jimstir/rfc/blob/mailserver1/content/docs/rfcs/whipser-mailserver.md\n\n\nwaku:waku-keystore\n\nFixed Draft, ready for review - https://github.com/vacp2p/rfc/pull/631\n\n\nadmin/misc\n\nlooked for improvements for COSS - https://github.com/jimstir/rfc/tree/1/COSS-Improvements/content/docs/rfcs/1\n\n\n"},"vac/updates/2023-12-04":{"title":"2023-12-04 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nTrying to make the last handshake work:\n\nRe-write the webrtc-transport\nRe-write datachannel to understand why the webrtc doesn’t connect\nSpend some time on the noise protocol\nIt appears the problem comes from SCTP\n\n\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\nfix(dcutr): update the DCUtR initiator transport direction to Inbound https://github.com/status-im/nim-libp2p/pull/\n\n\nnimlibp2p:vac:maintenance\n\nfix: remove forgotten “matrix-prep” job https://github.com/status-im/nim-libp2p/pull/997\nVM hosting providers updated https://www.notion.so/991bb915e4634248a764832e56f53160?v=24979d84f52f4df2b779bf5eb24ec3c5&pvs=4\nProject requirements for P2P CI added https://www.notion.so/782270f71b72438e963e0e5ef73358d9?v=5560c9000535403c9f72862eb9775ff9&pvs=4\nCI workflow is failing frequently; Testing Nimble lock file - Installed Windows 2019 - resolving Nimble install issues on Windows\n\nhttps://github.com/status-im/nim-libp2p/issues/975\nhttps://github.com/status-im/nim-libp2p/tree/fix/ci-workflow-stability\n-https://discord.com/channels/864066763682218004/1172153963559260231\n\n\nfix: move workflows for Nim Devel and legacy i386 from “Daily” -> comments resolved, commits resubmited with GPG signature https://github.com/status-im/nim-libp2p/pull/968\nInvestigate flaky tests issue PR [Ongoing discussion]\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nStill waiting for further Codex feedback on next steps for litepaper\n\n\nvac:tke::status:SNT-staking\n\nThis week followup with SC team on staking contract implementation (may be delayed due to Martin out with covid)\n\n\nvac:tke::nomos:economic-analysis\n\nOffsite documents will be released this week, Frederico will review and participate in their planning meeting for next steps on week and month\n\n\nvac:tke::waku:economic-analysis\n\nDiscussed EigenTrust reputation with Sergei, deprioritzed to first design simpler system\nMartin still out, when back will sync w/ Waku team for offsite debrief and identify next steps\nFor now, TE team is actively commenting on Sergei’s github issues to formalize Waku specs\n\n\n\nvac:dst: §\n\nanalysis-gsub-model:vac:refactoring\n\nThe different cases and runs can now be partly automated\n\n\neng-10ktool:vac:bandwidth-test:\n\nRun more simulations, do more in depth analysis\nUpdate repositories with latest changes\nUpdate notion information regarding Kubernetes cluster\nCreated plots and put everything in notion (https://www.notion.so/Results-dec50e8dc3e5426ab4f34c712de0b4f\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nFilter subscribe PR:\n\ncovers subscribe creation and update\nreached 67 tests\n\n\nIssue reported gowaku: encoding/hex: odd length hex string error when subscribing\nIssue reported nwaku: pubsubTopic not required as described in the specs\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nBegin lightpush tests PR - WIP\nFound a Lightpush.publish attribute type bug Issue\ndirection attribute related functionality\n\nPR\nRefactor from ascending to direction for consistency\nHistoryQuery.direction Default value fix\ndirection attribute from bool to enum\n\n\nMerged PR\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 5 tests related to filter - coverage improvement https://github.com/waku-org/go-waku/pull/931\nOpened & got fixed issue “unsubscribe all with unrelated peer” https://github.com/waku-org/go-waku/issues/933\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\nwork on retry strategy for rpc calls in rln-relay: https://github.com/waku-org/nwaku/issues/2217\n\n\nsecure-channels:waku:ethereum-chat\n\nCompletion of the group chat approach using UPKE.\nInclusion of an elliptic-curve variation of UPKE.\nImprovements on the RFC and solving questions from Waku team.\ncreated a document about comparison treeKEM and ADKG in terms of security, complexity, and additional features. (WIP)\n\n\nzerokit:vac:maintenance\n\nresearched issue https://github.com/vacp2p/zerokit/issues/78\n\n\nadmin/misc\n\ninvestigate having the membership tree onchain: https://github.com/waku-org/research/issues/56\nworked with waku to have the membership tree onchain, successfully integrated in https://github.com/vacp2p/rln-contract/pull/31, moved to foundry template as well (will sync with SC unit)\n\n\n\nvac:sc:: §\n\nstatus:status-network-token-v2\n\nSome cleanup https://github.com/status-im/status-network-token-v2/pull/2\nAdded certora integration for CI https://github.com/status-im/status-network-token-v2/pull/3\nAdded sepolia deployment config https://github.com/status-im/status-network-token-v2/pull/4\nDeployed SNTV2 on Sepolia\n\nhttps://sepolia.etherscan.io/address/0xE452027cdEF746c7Cd3DB31CB700428b16cD8E51\nhttps://github.com/status-im/status-network-token-v2/pull/6\n\n\n\n\nvac:maintenance:misc\n\nAdded certora integration for CI to governance https://github.com/vacp2p/governance/pull/3\nResearched SAT and SMT solvers to get a better understanding of how Certora works\nDeployed OP SNT to OP Sepolia\n\nPR for bridge UI https://github.com/ethereum-optimism/ethereum-optimism.github.io/pull/591\nPR for addresses and sepolia config https://github.com/logos-co/optimism-bridge-snt/pull/29\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nWorked on different L2 and Rollups focusing on privacy (Az, Pol, Zc)\nLooking on UTXO - Account based traslation (Car)\nVerkle tree document (WIP)\nBegin to survey newer PCSs to see if any may yield better results than KZG. 1, 2, 3\nBegin reading VM SMT\nDelved into the L2 protocol and understood how they use hybrid states and UTXO based execution. And extract some insight from the architecture.\nDocumented L2 protocol and its hybrid execution (WIP)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\naggregation, block proposal time, tor diagnostic to consider and add.\n\n\nvalpriv:vac:tor-push-paper\n\nFinalizing, adding discussion, revising figures\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\ncarried out experiments on shadow simulator for GissipSub improvements paper. The experiments check the performance of proposed schemes against increasing network size, increasing message sizes and increasing publishers.\nMost of the simulations are done successfully. Some large simulations may take 1-2 more days\n\n\n\nvac:rfc: §\n\nstatus:port-status-specs\n\nCreated short summaries, added some new abstracts, added references - https://github.com/vacp2p/rfc/pull/640\nhttps://github.com/vacp2p/rfc/pull/639\nhttps://github.com/vacp2p/rfc/pull/638\nhttps://github.com/vacp2p/rfc/pull/637\nhttps://github.com/vacp2p/rfc/pull/636\nhttps://github.com/vacp2p/rfc/pull/635\nhttps://github.com/vacp2p/rfc/pull/634\nhttps://github.com/vacp2p/rfc/pull/633\n\n\nwaku:waku-usage\n\nUpdated waku2 usage - https://github.com/vacp2p/rfc/pull/6\n\n\n"},"vac/updates/2023-12-11":{"title":"2023-12-11 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDebugging SCTP\n\n\nnimlibp2p:vac:maintenance\n\nYamux\n\nRe-write misleading parts (eg sendQueueSize)\nStart writing explanations/comments\ncont’ https://github.com/status-im/nim-libp2p/pull/987\n\n\nadded the hp tests to nim-libp2p (they run with every PR)\nworking on the nim-libp2p releases\n\n\n\nvac:tke: §\n\nvac:tke::status:SNT-staking\n\nResuming conversation with SC team on staking contract and Certora training\nstarting to discuss with Pablo on Waku sharding to support decentralized scaling of Status\n\n\nvac:tke::nomos:economic-analysis\n\nIncorporating changes in consensus from Carnot to Ouroboros\nResearch how delegation is used in comps of Cardano, Polkadot, and EigenLayer, compared against privacy restrictions given Nomos objectives\n\n\nvac:tke::waku:economic-analysis\n\nSharding discussion w/ Pablo on Waku\nContinuing GitHub issue feedback on Waku incentives and reputation (bottom up approach)\nAlso start a business model analysis and implications for next steps with the protocol (top down approach)\n\n\n\nvac:dst: §\n\nanalysis:nomos:simulation-analysis\n\nThe goals and the responsibilities for the paper reaffirmed\nAnalysis correctly and switfly found parameter issues in the small-tree simulations (which follow a different control path); met with Gusto and it is fixed now\n\n\nanalysis-gsub-model:vac:refactoring\n\n95% done, barring minor stylistics and input re-structuring branch(https://github.com/vacp2p/research/tree/0xFugue-waku-scaling-rewrite)\n\n\nanalysis-gsub-model:status:control-messages\n\nThe blog post is one 20% done: the overall design of Waku explained and modelling focus defined draft(https://github.com/vacp2p/vac.dev/tree/0xFugue-waku-model)\n\n\neng-10ktool:vac:bandwidth-test:\n\nTest new kernel parameters\nInvestigame uptimes for ram on simulations\nInvestigate packets drop\nSolve issues with libp2p versions (https://www.notion.so/Notes-423c72646a0944d1bd7889d7dec30bb4)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nContinued implementing lightpush tests\nDecided on way forward with direction refactor PR: Merge.\nLightpush SEGFAULT on publishing message over size limit; Issue\n\n\n\nvac:acz: §\n\nadmin/misc\n\nparticipate @ waku hackerhouse, ethindia\n\n\nrlnp2p:waku:rln-relay-enhancments\n\nassist in benchmarking rln tree onchain, report: https://github.com/waku-org/research/issues/72\n\n\nsecure-channels:waku:ethereum-chat\n\nFamiliarization with RFC9420 and RFC9180.\nConfection of several comparisons to get to SoA:\n\nTreeKEM vs ART.\nHPKE vs UPKE.\n\n\nWork on using Ethereum as Authentication Service.\nCreated a document about Farcaster’s Async Triple-Ratchet Protocol (WIP)\nResearching about Triple-Ratchet protocol from literature.\n\n\nzerokit:vac:maintenance\n\nresearched issue https://github.com/vacp2p/zerokit/issues/115\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nContinued researching Certora and formal verification\nreviewed old Certora specs\nExploring Requirements for Smart Contracts in a Privacy-preserving Environment (for logos research call)\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nResearched different L2 and Rollups focusing on privacy (Az, Pol, Zc, Nmd, Ada)\nReviewed Az Ugur’s doc\nDiscussed on Zc for a proposal model\nProduced a full doc on Pol architecture\nContinue with Verkle tree document for complexity estimates for various cases.\nWrote brief survey on (newer PCSs) (Pending upload): 1, 2, 3\nContinued reading VM SMT\nBegan reading towers over binary fields\nresearched how to update the public state by a private execution\nWorked on a proposal about a public state that we can update by a private TX\nRead about how Zcash update their public state\nCheck a paper about Zcash-like execution on Ethereum\n\n\nproofsystems:vac:benchmarks\n\nFixed comment for a PR for GWC implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/17\nFixed comment for a PR for SHPLONK implementation of poseidon circuit for halo2 https://github.com/vacp2p/zk-explorations/pull/18\nFixed github issues on zk-explorations repo\n\n\nproofsystems:vac:research-existing-proof-systems\n\nWriting BaseFold writeup (https://eprint.iacr.org/2023/1705.pdf)\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\nseparate measurement for aggregation from attestation, block proposal, sync committee.\n\n\nvalpriv:vac:tor-push-paper\n\nShared to-be-submitted arxiv version\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted simulations for relatively large network (upto 6000 nodes with 50KB and upto 1000 nodes with 1MB messages), on DST test server\nResult analysis is complete. Looking into one anomaly (increased latency seen for approximately 1% nodes in Reduced Sending method)\nFinalizing graphs and results presentation\n\n\n\nvac:rfc: §\n\nwaku:waku-usage\n\nupdated waku-usage - https://github.com/vacp2p/rfc/pull/627\n\n\nwaku:waku-keystore\n\nUpdated waku-keystore, ready for feedback - https://github.com/vacp2p/rfc/pull/631\n\n\n"},"vac/updates/2023-12-18":{"title":"2023-12-18 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nSCTP:\n\nfix: the receive callback is now correctly setup\nfix: remove the send delay (using the nagle protocol)\ngetting stuck on a weird message received from the JS-libp2p\n\n\nDataChannel:\n\nfix: move readloop from accept to new\nTrying to changes multiple things in order to change the behaviour of JS-libp2p:\n\nreversing the initiators\ndelaying the noise handshake\nremoving the open stream\n\n\n\n\nall relevant nim-webrtc changes are here : https://github.com/status-im/nim-webrtc/pull/4\n\n\nnimlibp2p:vac:maintenance\n\nimprovement(ci): improve ci daily workflows - https://github.com/status-im/nim-libp2p/pull/1002\nMerge unstable into master - https://github.com/status-im/nim-libp2p/pull/1003\nReading about Zero Copy feature and looking for it on Chronos and Libp2p\nUpdate nim-libp2p version in Nimbus - https://github.com/status-im/nimbus-eth2/pull/5667\nFlood publishing - https://github.com/sigp/lighthouse/pull/4383 and https://github.com/libp2p/rust-libp2p/pull/\nchore: improve CI workflow stability https://github.com/status-im/nim-libp2p/pull/1004\nfix: make matrix include customizable for daily workflows https://github.com/status-im/nim-libp2p/pull/1000\nCI workflow is failing frequently PR 1004 is ready for review - Nimble lock for different Nim versions\nTest Case: FloodSub message size validation 2\n\nManaged to reproduce failure on computer when running isolated.\nDove into code, and pursued a couple possible threads.\n\n\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nCodex confirmed not able to followup on litepaper until 2024\nGeneral research of how comparable testnets run incentives for their net\n\n\nvac:tke::status:SNT-staking\n\nStaking contract depriortized by SC team\nUpdate John on initial findings on Waku sharding, sync on next steps roadmap discussion with Waku\nNo other priorities for SNT team at this time\n\n\nvac:tke::nomos:economic-analysis\n\nResearching leader selection and finality, impact on wealth concentration\nAdding statistical framework to define validator rewards (optimization function)\n\n\nvac:tke::waku:economic-analysis\n\nCall w/ Waku on incentives and revenue sources\nModeling the various proposed approaches to RLN\nReading and responding to Sergei’s latest incentivization documents\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nKeep investigating packets drop (https://www.notion.so/Results-2-eac3e52d512e469db57dc145aa65e603)\n\nCheck bandwidth per node with same rate and load (Correct)\nStrange behavior with 20MB/s on network.\n\n\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nImplemented filter unsubscribe tests\n\ncovers unsubscribe and unsubscribe-all APIs\nreached 92 interop tests\n\n\nIssues reported:\ngowaku: Strage error when retrieving messages\ngowaku: Reopened and closed again the log flood issue\nnwaku: Wrong response format to filter/v2/subscriptions\nnwaku: Relay publish regression\nInvestigated and figured out how to automate tests requested by the waku team\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nFinished lightpush tests\nPagingDirection Refactor PR\nFound one failing test when running test_all\n\nWakuNode2 - Validators::Spam protected topic accepts signed messages\nOnly happens when running literally all of them, not one specific.\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 5 tests related to lightpush - coverage improvement https://github.com/waku-org/go-waku/pull/957\nGot clarity on bug: unequal rules enforcement for contentTopic syntax https://github.com/waku-org/go-waku/issues/958\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nIncluded all materials related to MLS in the RFC\nImproved several aspects of the RFC (improve organization, delete some parts, etc)\nDiscuss difference of ADKG+DR and Asycn Triple-Ratchet algorithm from Farcaster.\nRead about repudiation term in messaging protocols and create a note about it.\nCheck the MLS report in Notion\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-maintenance\n\nDeployed CommunityTokenDeployer contracts on production networks\n\nMainnet, Arbitrum, Optimism\nDeployment addresses\n\nhttps://www.notion.so/Contract-Deployment-Addresses-d6dd98b1b4f6461d82eec6ab18b852c8\nPR: https://github.com/status-im/communities-contracts/pull/25\n\n\n\n\nInvestigated a bug in foundry that prevented us from signing transactions on ledger\n\nhttps://github.com/foundry-rs/foundry/issues/6516\n\nUse version mentioend in this issue for deployments via ledger for now\n\n\n\n\nstarted docs on new specs https://notes.status.im/JsEoWi8rSaqa-s3b2LCF5A?view\nstarted implementing the first new specs\nreview deployer contract properties doc https://notes.status.im/s/291mb-8nA\n\n\nvac:maintainance/misc\n\nCreated a multisig wallet for out team on Arbitrum (similar to the one on OP)\n\n\ncodex-token-tmp-milestone\n\nmeeting + adding ideas to https://docs.google.com/document/d/1lH6dPSuSzGIFmbJeaXNmx8cIU7dveI9KxE1rxdoKagQ/edit#heading=h.f8xnzmojer6t\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nReadings on privacy-focused models (Az, Nmd, Zc, Ada, Ola)\nBrief notes on Hyperproofs\nNotes on Ring Signatures\nRead paper on security for UTXO based on DAGs; notes after meeting.\nResearch miblewimble (goal 1)\nReviewed Halo2 PR’s GWC and SHPLONK\nNote about the similarities and differences Az and Pol\nRead about Zcash from its whitepaper section 3.4 Transactions and Treestates, and investigate how a shielded address can generate a public balance.\n\n\nproofsystems:vac:research-existing-proof-systems\n\nfinished BaseFold writeup\nstarted researching Arecibo (https://blog.lurk-lang.org/posts/arecibo-supernova/)\n\n\nproofsystems:vac:benchmarks\n\nStarted a refactoring for halo2 PRs https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21\n\n\n\nvac:dr: §\n\nvalpriv:vac:tor-push-poc\n\ntested sync role success, gathered aggregated message latency, tested alltorbroadcast for all validator messages\n\n\nvalpriv:vac:tor-push-paper\n\nRevised graphs with std dev/mean, added inclusion difference\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted simulations and results and analysis/presentation for all test scenarios.\nArticle writeup is almost complete (will be concluded by today)\n\n\n\nvac:rfc: §\n\nadmin/misc\n\nCreated pr for a few 1/COSS changes\n\nProposal for description - https://github.com/vacp2p/rfc/pull/645\nProposal for adding github names - https://github.com/vacp2p/rfc/pull/644\nProposale for draft delete - https://github.com/vacp2p/rfc/pull/654\n\n\nUpdated store link and formats - https://github.com/vacp2p/rfc/pull/653\nUpdated usage - https://github.com/vacp2p/rfc/pull/627\n\n\n"},"vac/updates/2023-12-25":{"title":"2023-12-25 Vac weekly","links":[],"tags":["vac-updates"],"content":"vac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nFixing bumper jobs - https://github.com/status-im/nim-libp2p/issues/1005\nRemove rules related to Nim 1.2 jobs from master branch on github settings\nReading and Understanding\n\nDisable flood publishing https://github.com/sigp/lighthouse/pull/4383\nMore lenient flood publishing https://github.com/libp2p/rust-libp2p/pull/3666\nTesting latency on different flood publish strategies https://github.com/sigp/gossipsub-testground/pull/15\ntesting gossipsub(flood publish) with quic https://github.com/ackintosh/gossipsub-testground/p\n\n\nCase 'FloodSub message size validation 2':\n\nIssue: Combination between message size and timeout; Big message size takes a big time, and sometimes exceeds timeout\nStill begs the question: “Why it passed when running the full suite instead of the isolated test\n\n\n\n\n\nvac:tke: §\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nKeep investigating packets drop (https://www.notion.so/Results-3-43142115f7764d3ca9954490f232b242)\n\nCreated same test node with Rust (borrowed some time from Alex)(https://github.com/vacp2p/dst-gossipsub-test-node-rust/tree/master)\n\nGot some preliminary results (https://www.notion.so/Results-Rust-011fb77dea4b482ba8283f1adb762c9c)\n\n\n\n\nsync with p2p team regarding weird behavior\nUse iperf to create artificial bandwidth and keep investigating (Done, no package drop).\n\n\nadmin/misc\n\nhiring\n\n\nvac:dst:software-testing:waku:test-automation-js-waku\n\nInvestigated and helped fixing js-waku tests that failed with latest nwaku\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nImplemented the idle subscription tests requested by the nwaku team + multi-node filter tests: PR\nIssues reported:\n\nhttps://github.com/waku-org/go-waku/issues/967\nhttps://github.com/waku-org/go-waku/issues/968\nhttps://github.com/waku-org/go-waku/issues/969\nhttps://github.com/waku-org/go-waku/issues/970\nhttps://github.com/waku-org/go-waku/issues/971\nhttps://github.com/waku-org/go-waku/issues/972\nhttps://github.com/waku-org/nwaku/issues/2315\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nTest failure\n\nInvestigate\nIssue\n\n\nMerge\n\nDirection refactor\n\nPR\n\n\nStore Tests\n\nPR1\nPR2\n\n\nLightpush Tests\n\nPR\n\n\n\n\nImplemented autoshard tests\n\nMissing one. Asked about how to mock.\n\n\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nWorked on Ethereum as Authentication Service. (https://www.notion.so/WiP-Ethereum-based-Authentication-cb7b0ff07ba74886847ec8e23e8a7a62)\nSpecification for the MLS in our setting. (https://github.com/vacp2p/rfc/blob/master/content/docs/rfcs/70/README.md)\nRFC updates: ADKG + DR removed and replaced with MLS.\n\n\n\nvac:sc:: §\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nFinished researching Az, Pol, Ola\nContinue readings on privacy-focused models (Nmd, Zc)\nLooking at privacy related questions for UTXO\nContinue with binary towers paper\nContinued research on mimblewimble.\nRead HEX-Bloom\nRead NOTRY; this paper deals with messaging, but has an interesting property in their scheme called avowal and proof of non-knowledge.\nWork on propsal about the private execution that affects public state and start to write it.\nRead a paper about the proposal\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted article writeup for GossipSub scaling for large messages\n\n\n\nvac:rfc: §\n\nwaku:waku-keystore\n\nMade changes based on feedback for waku-RLN-keystore - https://github.com/vacp2p/rfc/pull/631\n\n\nadmin/misc\n\nRead waku2 specs, message, filter, store, payload - https://rfc.vac.dev/spec/10/\nread libp2p docs to prepare for excutable specs of waku2 node\n\n\n"},"vac/updates/2024-01-01":{"title":"2024-01-01 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/01 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance:\n\nCase 'FloodSub message size validation 2':\n\nRun tests in different mac envs: VM: Failure; M2: Success\nThe previous tests support the hypothesis this is timeout/cpu-power related\n\n\nOther flaky tests?\n\nEither the previous VM or M2 didn’t find any other failing tests (just one attempt, though):\n\ntestpubsub: Only 'FloodSub message size validation 2' fails.\ntestdaemon: Stuck after a couple logs regarding IPs.\ntestnative: Success\n\n\n\n\n\n\n\nvac:tke: §\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nFixed behavior issues in Rust node (https://github.com/vacp2p/dst-gossipsub-test-node-rust)\nSimulation results (https://www.notion.so/Results-Rust-011fb77dea4b482ba8283f1adb762c9c)\nPython libp2p is not stable (https://libp2p.io/implementations/), and with no changes from the last 6 months. Not using for comparisons.\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nImplemented the filter push/get messages and filter ping tests: PR\nIssues reported:\n\nhttps://github.com/waku-org/nwaku/issues/2319\nhttps://github.com/waku-org/nwaku/issues/2320\nhttps://github.com/waku-org/nwaku/issues/2322\n\n\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nCreate Autosharding Tests PR\n\nPR\n\n\nInvestigate and add simple mocking mechanism\nBegin working in Connection Peer Management Tests\n\nPR\n\nDone: Migrations, PeerStorage\nIn Progress: Protobuf Serialisation, WakuPeerStorag\n\n\n\n\n\n\n\nvac:acz: §\nvac:sc:: §\nvac:nescience: §\n\nproofsystems:vac:research-existing-proof-systems\n\nconitinued researching Arecibo (https://blog.lurk-lang.org/posts/arecibo-supernova/)\nStarted reading CycleFold (https://eprint.iacr.org/2023/1192.pdf)\n\n\nproofsystems:vac:benchmarks\n\nprepared Halo2 common PR (https://github.com/vacp2p/zk-explorations/pull/23)\nWorked on a refactoring for halo2 PRs https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21\n\n\nstate-separation:vac:state-separation-doc\n\nContinue with mimblewimble\nResearch Ugur’s idea\nRead about private and public kernel circuits from Az.\nFinish the research about how we can update public state with a private execution.\nUpdate the proposal because last version is not applicable.\n\n\n\nvac:dr: §\nvac:rfc: §\n\nwaku:waku-keystore\n\nUpdated keystore to be more descriptive for some sections. Ready for feedback - https://github.com/vacp2p/rfc/pull/631\n\n\nadmin/misc\n\nWorked on implementing 14/WAKU2-MESSAGE for excutable spec\n\n\n"},"vac/updates/2024-01-08":{"title":"2024-01-08 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/08 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance:\n\nflaky tests: trying out a hypothesis about runners specs\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nUpdate Notion and Tokenomics Design Canvas (TDC) for Codex (@Matty)\nAdd new Collateral Insurer role to litepaper\nFollow up with Codex on litepaper feedback and next steps for testnet incentive design and token allocation\n\n\nvac:tke::status:SNT-staking\n\nUpdate Notion and TDC for SNT (@Matty)\nFollow up with John on Wednesday call for 2024 Status plan\n\n\nvac:tke::nomos:economic-analysis\n\nClean up Nomos Notion and update TDC (@Frederico)\nFinish agent based simulations on wealth concentration impacted by leader selection\nRead darkpaper when Nomos team has finished incorporating team comments and can share (expect it this week)\n\n\nvac:tke::waku:economic-analysis\n\nClean up Waku Notion, and create a best thinking draft of TDC (@Martin)\nFinalize and share L2 overview with Waku business model meeting Tue\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nGather all data from Kubernetes and create document with plots (https://www.notion.so/Nim-Rust-comparison-9dc4e4c3c0914773971608e8af911943)\nCompare nim, rust and waku bandwidth, packet and times.\nEnd of the week got stucked because some Kubernetes issues. They are fixed now\nRan some gowaku simulations. Results differ a lot from nwaku (half bandwidth, no packet loss).\n\n\nvac:dst:software-testing:waku:test-automation-interop-testing\n\nRetested some fixes\nFixed tests related to 1MB message\nRemoved deprecated RPC protocol and cleaned up the code\nInvestigated with Prem some node connection issues/regression\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nclarified testing priorities with Waku:\n\nRLN\nPeer Exchange\nDiscv5\nPeer Connection Management\n\n\nOpen Issue [bug: SqliteDriver WakuMessage attribute saving]\n\nAfter further investigation with Ivan we decided it behaves as expected\nIssue\n\n\nLightpush\n\nUpdated PR with comments PR\n\nBlocked until SEGFAULT solved\n\n\n\n\nAutosharding\n\nImplemented and merged tests PR\nRequested help for overloaded function mock test case PR; Nim Forum\n\n\nPeer Connection Management\n\nImplemented and merged tests PR\nThorough investigation on module types and base58\n\n\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nWrote 10 test to improve store tests coverage https://github.com/waku-org/go-waku/pull/993\nGo-Waku node operations on Pi 4 (hobby activity)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\ncontinue work on proof of concept for state transition proof for onchain roots in rln: https://github.com/vacp2p/rln-contract/issues/32\n\n\nsecure-channels:waku:ethereum-chat\n\nCreated a 4-step approach for Ethereum as Authentication Service article\n\n\n\nvac:sc:: §\n\ncodex:codex-airdrop-contract-exploration\n\nadd possible token airdrop solutions https://docs.google.com/document/d/1lH6dPSuSzGIFmbJeaXNmx8cIU7dveI9KxE1rxdoKagQ/edit#heading=h.f8xnzmojer6t\n\n\nstatus:community-contracts-maintenance\n\nstart implementing the first new specs based on https://notes.status.im/JsEoWi8rSaqa-s3b2LCF5A?view\nreview deployer contract properties doc https://notes.status.im/s/291mb-8nA\n\n\n\nvac:nescience: §\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished researching Arecibo (https://blog.lurk-lang.org/posts/arecibo-supernova/)\nStarted writing CycleFold writeup (https://eprint.iacr.org/2023/1192.pdf)\n\n\nproofsystems:vac:benchmarks\n\nContinued working on a refactoring for halo2 PRs https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21\nReviewed halo2-common PR\n\n\nstate-separation:vac:state-separation-doc\n\nDiscuss UTXO/Merkle on discord\nReviewd literature concerning pruning Merkle trees in Bitcoin and other UTXO systems; mentioned in the original white paper but never implemented due to issues with history.\nDiscuss recursiveness of Nova\nWork on notes for mimblewimble (pending upload)\nFinish the first version of the report about how we can update public state with a private execution, here is the report.\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nInvestigated the latency spikes issue with floodpublish for large messages. The problem was small TCP cwnd at start of connection, same is the case with floodpublish peers, and latencies accumulate for multi-hop paths\n\nSending dummy data immidiately after connection setup resolves the problem.\nHowever, this can make peers vulnerable to buffer overflow attacks\n\n\n\n\n\nvac:rfc: §\n\nmisc\n\nCreated 14/WAKU2-MESSAGE update pr - https://github.com/vacp2p/rfc/pull/655\nStarted waku excutables spec document - https://github.com/vacp2p/rfc/blob/waku2-excutables/content/docs/rfcs/11/executable/README.md\ndraft pr for content topics clarity, this may not be necessary - https://github.com/vacp2p/rfc/pull/656\n\n\n"},"vac/updates/2024-01-15":{"title":"2024-01-15 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/15 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDatachannel\n\nInvestigate on why the js-datachannel handshake work, but not the channel creation\n\n\nSCTP\n\nFind an issue with sctp_recv\nWe didn’t get sctp_recvinfo mandatory for the datachannel\nCould be a similar cause on why js-datachannel doesn’t receive our data\n\n\nCreate an SCTP message decoder\n\n\nnimlibp2p:vac:maintenance\n\nAdd comments to Yamux https://github.com/status-im/nim-libp2p/pull/1006\nTried timeout hypothesis for tests\n\nTests didn’t fail, but given they’re flaky, is not evidence enough; Merge and see how that impacts builds.\n\n\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nReading https://github.com/libp2p/rust-libp2p/pull/4914, https://github.com/libp2p/rust-libp2p/issues/4667\nTrying to understand their implementation and how we can implemente something similar in nim-libp2p\nReading about TCP slow start and initial window\n\n\nmisc/admin\n\nHelp with nim-unittest2 https://github.com/status-im/nim-unittest2/pull/35\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\non hold until Matty is back form holidays\n\n\nvac:tke::status:SNT-staking\n\nUpdate Notion and TDC for SNT (@Martin)\nFollow up with John on Tuesday call for 2024 Status plan\nStaking contract revision due to rework from Pascal (@Martin)\n\n\nvac:tke::nomos:economic-analysis\n\nClean up Nomos Notion and update TDC (@Frederico)\nFinish agent based simulations on wealth concentration impacted by leader selection (@Frederico)\nRead darkpaper when Nomos team has finished incorporating team comments and can share (expect it this week)\n\n\nvac:tke::waku:economic-analysis\n\nfocus research on sustainability, compare different models (@Martin)\nprepare for meeting with Matt Nemmer (@Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nAdd 3rd machine to simulations and get more plots.\n\nInvestigate weird results\n\n\nInvestigate if results from go-waku are correct.\nCreate a simple node with go-libp2p\n\n\n\nvac:qa: §\n\nsoftware-testing:waku:test-automation-interop-testing\n\nBugfix testing and fixed tests related to maximum subscription count(@Florin)\n\n\nsoftware-testing:waku:test-plans\n\nPeer & connection management test plan(@Florin)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nStarted working on RLN test coverage(@Alex)\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nRLN tests coverage(@Roman)\nFixed minor bug(@Roman)\n\n\n\nvac:acz: §\n\n\nrlnp2p:waku:rln-relay-v2\n\nPatched rln-contract with foundry template - https://github.com/vacp2p/rln-contract/pull/34\nrln-v2 branch on rln-contract - https://github.com/vacp2p/rln-contract/pull/35 (deployed to sepolia and polygon zkevm testnet)\nPlanning for rln-v2 in nwaku - https://github.com/waku-org/nwaku/issues/2345\n\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nPrepare presentation for logos research call\n\n\n\nsecure-channels:waku:ethereum-chat\n\nImproving parts of the RFC. (https://github.com/vacp2p/rfc/blob/master/content/docs/rfcs/70/README.md)\nStudy of SIWE (EIP-4361) as an authentication solution. (https://www.notion.so/WiP-Ethereum-based-Authentication-cb7b0ff07ba74886847ec8e23e8a7a62)\nKept working on Quarantined TreeKEM.\n\n\n\nsecure-channels:waku:ethereum-chat\n\nRead about SIWE and extracting some questions about the usage of it.\n\n\n\nmisc\n\nAdded FFI bindings to stealth commitment implementation in rust - https://github.com/rymnc/erc-5564-bn254/commit/9ecb6cf53ce49e638ce0de2e50d06a5e2ed2c487\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-maintenance\n\nImplemented Certora rules as preparation for the upcoming Certora training\nIntroduced script to run multiple certora specs\nAdded implemented rules to PROPERTIES.md\n\nhttps://github.com/status-im/communities-contracts/pull/26\n\n\n\n\nstatus:snt-staking-contract-maintenance\n\nFixed a bug that prevents unstaking from actually working\n\nhttps://github.com/logos-co/staking/pull/41\n\n\nAdded tests for some basic staking functionality, ensuring multiplier points are minted and point correctly\n\nhttps://github.com/logos-co/staking/pull/42\nhttps://github.com/logos-co/staking/pull/43\n\n\n\n\nmaintenance/misc\n\nSepolia SNT now bridgable to OP Sepolia\n\nhttps://github.com/ethereum-optimism/ethereum-optimism.github.io/pull/591#event-11423844729\n\n\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nExtensive research on privacy-focused models (@Moudy) and existing techniques (@Marvin)\nGeneral research on how to handle order of execution and calling to integrate in the proposal\nUpdated Notion with Explication Notes @Moudy and State Update @Ugur\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on revised results for GossipSub Improvements paper. Completed for TCP cwn and IDONTWant (Still to do for staggered sending)\nWorked on latency spikes issue for FloodPublish\n\n\n\nvac:rfc: §\n\nmisc\n\nStarted working on new RFC for stealth commitments - https://github.com/vacp2p/rfc/pull/658\nMerged - https://github.com/vacp2p/rfc/pull/653\nFixed last week’s blocker, trouble running py-libp2p\n\n\nwaku:waku-keystore\n\nMade changes based on feedback - https://github.com/vacp2p/rfc/pull/6\n\n\n"},"vac/updates/2024-01-22":{"title":"2024-01-22 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/22 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFind/investigate a bug with usrsctp not sending the correct messages.\n\n\nnimlibp2p:vac:quic\n\nInvestigate what we need to implement: mainly wrap DTLS 1.3\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nmake forward (relay) messages non priority - https://github.com/status-im/nim-libp2p/pull/100\n\n\nnimlibp2p:vac:maintenance:\n\n“Timeout increase” approach to fix some of the flaky timeout tests\n\n\n\nvac:tke: §\n\nvac:tke::codex:economic-analysis\n\nadd insurer role to the litepaper (@Matty)\nmake sure litepaper is up-to-date (address comments, etc.) (@Matty)\n\n\nvac:tke::status:SNT-staking\n\nget general plan from John on Tuesday (@Martin)\nreview litepaper and TDC (@Matty)\n\n\nvac:tke::nomos:economic-analysis\n\nClean up Nomos Notion and update TDC (@Frederico)\nFinish agent based simulations on wealth concentration impacted by leader selection (@Frederico)\nRead darkpaper when Nomos team has finished incorporating team comments and can share (expect next week)\n\n\nvac:tke::waku:economic-analysis\n\nprepare for meeting with Matt Nemmer (@Martin)\nresearch around sustainability model following Franck post (@Martin)\nwork on L2 discussion with Cyprien (@Martin)\nreview litepaper and TDC (@Matty)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nInvestigate 3 machine results\nFinish go-libp2p node and get simulation results\n\nhttps://www.notion.so/Nim-Rust-Go-comparison-9dc4e4c3c0914773971608e8af911943\n\n\n\n\n\nvac:qa: §\n\nvac:qa:software-testing:waku:test-automation-js-waku\n\nFixed tests related to content topic limit update PR1 and PR2(@Florin)\n\n\nvac:qa:software-testing:waku:test-plans\n\nDiscv5(@Florin)\nPeer exchange(@Florin)\n\n\nvac:qa:software-testing:waku:interop-testing\n\nNightly go and nim interop workflows reporting to WAKU/DEV/test-reports discord channel(@Roman)\nAdjusted tests and marked known failures with xfail so the nightly reports look better(@Florin)\n\n\nvac:qa:software-testing:waku:test-automation-nwaku\n\nImproved RLN tests: Node and Group Manager(@Alex)\n\n\nvac:qa:software-testing:waku:test-automation-go-waku\n\nImproved RLN unit tests coverage(@Roman)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-doc-and-outreach\n\nPresent rln-v2 and v3 at logos research call\n\n\nzerokit:vac:maintenance\n\nAttempted integrating circom-witness-rs into zerokit for faster witness generation, realized that a few operations, bitand and shr are not implemented.\n\n\nmisc\n\nrln-v3 proposal doc - https://hackmd.io/@rymnc/rln-v3-proposal (linked in notion as well - https://www.notion.so/RLNP2P-e2865a91b50d4928b2e8d14916adb586)\n\n\nsecure-channels:waku:ethereum-chat\n\nInclusion of SIWE in the RFC (deprecation of the NIZK approach).\nPreparation of internal notes on Quarantined TreeKEM.\nCheck the subprotocol and algorithms of RFC for the implementable of the RFC in notion\n\n\nzerokit:vac:maintenance\n\nworked on a workaround for https://github.com/vacp2p/zerokit/pull/224\n\n\n\nvac:sc:: §\n\nstatus:snt-staking-contract-maintenance\n\nAnalyzed application properties for formal verification together with Tokenomics team\n\nNotes https://notes.status.im/rA5eYiLlSYWDDLnaXRfPdg?both\n\n\nMerged pending bugfix a test PRs\n\nhttps://github.com/logos-co/staking/pull/41\nhttps://github.com/logos-co/staking/pull/42\nhttps://github.com/logos-co/staking/pull/43\nhttps://github.com/logos-co/staking/pull/44\n\n\n\n\nstatus:community-curation-contracts\n\nDeployed community curation dapp contracts on Optimism Sepolia\n\nPR with deployment config\n\nhttps://github.com/status-im/community-dapp/pull/107\n\n\n\n\n\n\n\nvac:nescience: §\n\nvac:nes:state-separation:vac:state-separation-doc\n\nFinished researching Privacy-focused models and Update notion with two different documentations: Ola and Namada\nReviewed and researched the Private State Update proposal and Update notion with an extended document for requirements\nMade a decision for milestones and how to achieve them (Add link), more info will be in the milestone document\nFinish up loose ends for Mimblewimble, Verkle tree notes (additions/deletions)\nBegin research on signature verification (Shielded)\nAdded a report about The Functions’ Order of Calling and Execution(WIP) in notion\nExplored the complexity side of the shielded-deshielded execution arhitecture\n\n\nvac:nes:proofsystems:vac:research-existing-proof-systems\n\nContinued writing CycleFold writeup (https://eprint.iacr.org/2023/1192.pdf)\n\n\nvac:nes:proofsystems:vac:benchmarks\n\nExperimented with Arecibo\nFixed comments on refactoring PR\nMade a decision for milestones, more info will be in the milestone document\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nWorked on staggered message sending issue (Used the newly implemented message queuing support).\n\nTesting and finalizing the code. Will finish by tommorrow.\n\n\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegin going through list of needs in terms of current design and design document\n\n\n\nvac:rfc: §\n\nmisc\n\nWorked on stealth commitments RFC, communicated with Aaryamann - https://github.com/vacp2p/rfc/pull/658\nWorked on Waku2 message update - https://github.com/vacp2p/rfc/pull/655\nrevisited website checked changes, looks ready\n\n\nwaku:waku-keystore\n\nWas approved by Aaryamann - https://github.com/vacp2p/rfc/pull/631\n\n\n"},"vac/updates/2024-01-29":{"title":"2024-01-29 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/01/29 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFix some bugs related to our way of debugging\nDeep dive into JS js libp2p for interop testing\nworking on figuring out why the noise handshake is blocked by the JS\n\n\nnimlibp2p:vac:maintenance\n\nHelp Waku with a websocket issue\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\ncont’ work on making forward messages non priority - https://github.com/status-im/nim-libp2p/pull/1009\n\n\n\nvac:tke: §\n\ncodex:economic-analysis\n\nadd insurer role to the litepaper (@Matty)\nmake sure litepaper is up-to-date (address comments, etc.) (@Matty)\n\n\nstatus:SNT-staking\n\nget general plan from John on Tuesday (@Martin)\nreview litepaper and TDC (@Matty)\n\n\nnomos:economic-analysis\n\nClean up Nomos Notion and update TDC (@Frederico)\nFinish agent based simulations on wealth concentration impacted by leader selection (@Frederico)\nRead darkpaper when Nomos team has finished incorporating team comments and can share (expect next week)\n\n\nwaku:economic-analysis\n\nprepare for meeting with Matt Nemmer (@Martin)\nresearch around sustainability model following Franck post (@Martin)\nwork on L2 discussion with Cyprien (@Martin)\nreview litepaper and TDC (@Matty)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test:\n\nTalk with p2p team about control messages; Found error in compilation\nAdd queue metrics data to Prometheus/Grafana\n\nDo simulations and check this metric\nMetrics are scrapped but building is failing\n\n\nPushed go-waku in kubernetes\n\n“Reached” 2k nodes, but there is a huge packet loss and latency times. Didn’t try more because it was consuming 1Gig of Bandwidth, and didn’t want to get the servers blocked again.\n\n\n\n\nadmin/misc\n\nPrepare onboarding new team member\n\n\n\nvac:qa: §\n\nsoftware-testing:waku:test-plans\n\nRLN test plan(@Florin)\nRLN issues found:\n\nSpam messages not dropped(@Florin)\nPostgres error regression(@Florin)\nRelayed messages are not stored(@Florin)\n\n\nKEYSTORE_PASSWORD env variable issue(@Roman)\nRLN meeting discussion(@QA_Team)\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nRemove dependency on hardcoded private keys for Ganache(@Roman)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nPrepared local dev enviroment(@Roman)\nRLN\n\nImplemented more RLN tests PR(@Alex)\nFound unintended behaviour where RLN wasn’t enabled for all intended topics(@Alex)\n\n\nAutosharding\n\nReview and discard mock-related PR(@Alex)\n\n\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\ndownstreamed rln-v2 to waku-rln-contract: https://github.com/waku-org/waku-rln-contract/pull/11, with full test coverage\nremoved websocket dependence from waku-rln-relay: https://github.com/waku-org/nwaku/pull/2364 (improves robustness, pre-requisite for rln-v2 integration)\n\n\nsecure-channels:waku:ethereum-chat\n\nCompletion of the internal notes on Quarantined TreeKEM\n(https://www.notion.so/WiP-Notes-on-the-MLS-protocol-cccc3faad97b4c00ae88bdec40f58e1e)\nImprovements on the RFC. RFC ready (review required). (https://github.com/vacp2p/rfc/blob/master/content/docs/rfcs/70/README.md)\nDetect two possible gaps against the implementation one is xed448 in and Quarantined TreeKEM in Rust\n\n\nzerokit:vac:maintenance\n\nfixed some infallible conversions: https://github.com/vacp2p/zerokit/pull/229\nstumbled upon rayon issue here https://github.com/vacp2p/zerokit/issues/55, read rayon docs, trying to find a solution\n\n\n\nvac:sc:: §\n\nadmin/misc\n\non-site Certora training\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nDefined the new Roadmap including different tasks and deadlines\nResearched signature verification and Adress hiding in (Shielded and Deshielded) executions (Marvin)\nResearched Deshielded and Shielded execution vs. different approaches to define and expand the proposal (Moudy)\nIdentified security issues on the combination of SE and DE and proposed possible salt mechanism as a possible solution to the issue (WIP)(Uugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished writing CycleFold writeup (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nExplored Arecibo and started updating the documentation (Moudy)\nExplored the 2 different Halo2 implementation variants and started updating the documentation (Moudy)\nResearched adn explored how recursion works in different ZKP we are benchmarking (Moudy)\nFinished working on a refactoring for [halo2 PRs](https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21) (Rostyslav)\nGot refactoring [halo2 PRs](https://github.com/vacp2p/zk-explorations/pull/22 https://github.com/vacp2p/zk-explorations/pull/21) merged (Rostyslav)\nStarted working on arecibo benchmark (Rostyslav)\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nUsed newly implemented queues (with event fire) to form weighted queues. But event fire mechanism results in much higher delays\nTrying to enable weighted queue forwarding to support message staggering\n\n\n\nvac:rfc: §\n\nmisc\n\nWorked on new RFC index repo - https://github.com/vacp2p/rfc-index/pull/1\nWaku message update ready for review - https://github.com/vacp2p/rfc/pull/655\nStarted waku v2 (spec 10) update - https://github.com/vacp2p/rfc/pull/661\n\n\n"},"vac/updates/2024-02-05":{"title":"2024-02-05 Vac weekly","links":["tags/head"],"tags":["vac-updates","head"],"content":"Vac 2024/02/05 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFix a bug in Datachannel.read (reading the last message received instead of the first one)\nFix a bug due to an Sctp delay (set it to 0ms was the solution)\nFind a bug in the conception of WebRTCStream. ReadOnce should be Length-prefixed.\n\ntry to fix it by re-writing ReadOnce, but due to the nature of this proc (inheritance issue) it doesn’t work\nwrite a RawWebRTCStream to make the length readable without issue\n\n\nFix a bug with the endianness of the datachannel protocol id\nE2E Done!\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nfeat: make relayed messages non priority (don’t use an explicit queue for priority msgs) - https://github.com/status-im/nim-libp2p/pull/1015\nfeat: drop msgs to be relayed waiting for too long in the queue - https://github.com/status-im/nim-libp2p/pull/1015\n\n\nnimlibp2p:vac:maintenance\n\nInvestigate dependencies issues\n\nFound possible problem/s\n\nLack of versioning\nNo major version clamping\nUsing#head\n\n\nTemporary workaround: Clamp/Pin (to git hash) libp2p dependencies’ versions\n\nPR\n\n\n\n\nImprove documentation [In Progress]\n\nBuilding go-libp2p-daemon\nGetting Started\nPR\n\n\nMerge timeout increase\nImproved checkExpiring\n\nNow it’ll outpout an error message when it fails due to timeout\n\nNot the most visible message\n\n\n\n\n\n\n\nvac:tke: §\n\nadmin/misc:\n\nMatty Handoff document finished and share with team on Wed (@Matty)\nTeam Lead Evaluation Criteria finished and share with team on Wed (@Matty)\nStrengths and development areas for Frederico and Martin, shared with Corey, Daniel, and Jarrad (@Matty)\n\n\ncodex:economic-analysis\n\nfinalize all Codex notion including Dragan’s comments to litepaper (@Matty)\nWednesday call with Codex team get in sync on next steps\n\n\nstatus:SNT-staking\n\nstaking contract implementation becoming a priority, refresh latest progress with SC team (@Martin)\n\n\nnomos:economic-analysis\n\nReading whitepaper and updating TDC (@Frederico)\nPorting wealth concentration simulation code to GPU to decrease runtimes (@Frederico)\n\n\nwaku:economic-analysis\n\nContinue Waku Network of Networks design discussion with Franck, concerns around forking (@Martin)\nResearch similar abstract p2p validation protocols (e.g. former Keep Network)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nTry to get a stable nim-libp2p version for simulations. Investigated with Alex about building issues with nimble.\nAnalized libp2p metrics, everything normal so far\ncall with p2p team\nScale testing for 10K project\n\nsetup go-waku experiment at scale\nSuccessfully simulated a 2,150 node simulation and gathered some basic metrics\nModified Kubernetes to allow for more pods to allow for (in theory) scaling to 10k+\nFailed simulations at 10000 and 5000 nodes - current limits seem to be around ~4800 or so\nPrometheus is a definite bottleneck - need to switch to a scaled/sharded Prometheus/Thanos setup\nAttempting one last simulation over the weekend at 4200 nodes\n\n\nDiagnosing 10K project bottlenecks\n\nIdentified a major potential bottleneck in the form of control plane traffic going over Wireguard / large packet load over WG causing swarm collapse\nwill test the new theory later by re-deploying on Vac Kubernetes with a local control plane + local traffic (while still complying with infra team requirements)\n\n\n\n\n\nvac:qa: §\n\nsoftware-testing:waku:test-plans\n\nSharding test plan(@Florin)\n\n\nsoftware-testing:waku:interop-testing\n\nRelayed messages reach recently started peer with a big delay(@Florin)\nRLN registration support and tests(@Roman)\n\n\nsoftware-testing:waku:test-automation-go-waku\n\nReviewed remaining work and added summary and approach(@Roman)\n\n\nsoftware-testing:waku:test-automation-nwaku\n\nClean and work with Gabriel to verify fix(@Alex)\nReview lighpush fixes and adjust unit tests(@Alex)\n\nLearned how to generate coverage report for NWaku and prepared small PR to have a shortcut(@Roman)\n\n\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nrln-v1 to v2 commitment migrator: https://github.com/waku-org/waku-rln-contract/pull/11/commits/886891b57ae54e439563023dd50161fec5ee29f1\nuse rln-v2 contract in nwaku: https://github.com/waku-org/nwaku/pull/2381\nupdate c ffi bindings and serde in nwaku: https://github.com/waku-org/nwaku/pull/2385 (issues: https://github.com/waku-org/nwaku/issues/2378 and https://github.com/waku-org/nwaku/issues/2377)\nuse rln-v2 in registration and membership insertion mechanism: https://github.com/waku-org/nwaku/pull/2392 (wip)\n\n\nsecure-channels:waku:ethereum-chat\n\nRFC updating, following comments and suggestions.\nDiscussion of use cases for the secure messaging protocol\nSearch and investigate existing secure messaging apps\n\n\nzerokit:vac:maintenance\n\nworked on a workaround for this issue https://github.com/vacp2p/zerokit/issues/55\n\n\n\nvac:sc:: §\n\nstatus:snt-staking-contract-maintenance\n\nReview Certora work\nPR https://github.com/logos-co/staking/pull/47\nWorking on solutions for Staking Contact issues https://notes.status.im/lNd8kcVmQEWcDYEldpl26Q\n\n\n\nvac:nescience: §\n\nstate-separation:vac:state-separation-doc\n\nCompleted research on SE and DE focusing on security issues while combining both models (Moudy)\nRewrote a full version of state update proposal for security and privacy threats (Moudy)\nResearched address hiding and signature verification and wrote a proposal for address hiding and signature verification (Marvin)\nAdded a report about the security issue and a possible solution(salt mechanism) and investigated about the security of the SE/DE (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStarted looking at Reverie whitepaperand BaseFold implementation (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nFinished working on arecibo benchmark (Rostyslav)\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nCompleted message staggering in the form of weighted message queues\n\nIts showing 10% better result than priority queuing, but Async Queue overhead still requires some work\n\n\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegin reviewing Range Proof example\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nworked on rfc-index adding rest of rfc, fixing links, and chaging headers - https://github.com/vacp2p/rfc-index/pull/1\nworked on waku/specs adding rfcs - https://github.com/waku-org/specs/tree/waku-RFC\n\n\n"},"vac/updates/2024-02-12":{"title":"2024-02-12 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/02/12 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nCleaning / commenting\nImplementing the client side of SCTP\nImplementing the closing part of SCTP / DataChannel\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nMaking it ready to be merged - https://github.com/status-im/nim-libp2p/pull/1015 (feat: message prioritization with immediate peer-published dispatch and queuing for other msgs)\n\n\nnimlibp2p:vac:maintenance\n\nimprovement: enhanced checkExpiring macro with custom timeout - https://github.com/status-im/nim-libp2p/pull/1023\nLog checkExpiring failure\n\nPR\n\nMerged\n\n\n\n\nAdded suggestions to building documentation\n\nPR\n\n\nGathered all dependencies modifications in the same PR\n\nPR\n\n\n\n\n\nvac:tke: §\n\nnomos:economic-analysis\n\ntested a new data layout for the PoS-GPU code (to allow a large number of blocks per epoch);\nimplemented a CPU-only code that outperformed the GPU (thanks to a trick given by David and Alexander);\nran simulations about wealth concentration and observed leader election on Cryptarchia.\n\n\ncodex:economic-analysis\n\nreviewed comparables tokenomics (Filecoin);\nreviewed the state of CDX token, inc. insurance model.\n\n\nwaku:economic-analysis\n\nreviewed Martin’s work on RLN pricing\n2x Waku RLN calls (Tokenomics, L2 for RLN) and follow-ups\n\n\nstatus:SNT-staking\n\ncontinuing work on Status DeFi analysis\ncontinuing work on Status staking contract\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nTalk again with p2p team about versioning\nDone simulations for Yamux\nRe-do simulations without using Wireguard. Packet loss is the same if not even higher (?)\nPlan how to structure the 10k tool framework\nOptimized publisher and added a debug flag to get DNS resolve times.\nBriefly ran a full 10K scale simulation, as well as other simulations at 7.5K, 8K, 5K and 0.1K\nScaled metrics up by sharding it then adding Thanos (via bitnami charts) Query and Thanos Query Frontend to aggregate the metrics\nDealing with various scaling issues as they come up\nAdded latency delay to pods, allowing us to do arbitrary amounts of latency in Waku nodes\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nRLN registration support and tests(@Roman + @Florin)\nAutomatically notify nwaku developes when nightly interop tests fail(@Florin)\n\n\nwaku:test-automation-js-waku\n\nConnection and peer management new tests and refactoring(@Florin)\n\n\nwaku:test-automation-nwaku\n\nLighpush fixes(@Alex)\n\nPeer Exchange tests(@Alex)\n\n\nUpdate QA milestones(@Florin)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nuse rln-v2 in registration and membership insertion mechanism: https://github.com/waku-org/nwaku/pull/2392\nrln-v2 nonce manager: https://github.com/waku-org/nwaku/issues/2415\n\n\nsecure-channels:waku:ethereum-chat\n\nKeep working in the updates of the RFC.\nStart writing the blog article about the SMP, with the use cases and the main features in mind.\nCreation of an Overleaf project on secure channel setup with Ethereum.\nCheck two SoK papers for comparison security mechanism; paper1 paper2\nStudy the security mechanisms of dm3, Tor Messenger and Briar.\nStart an internal report comparing different messaging protocols.\n\n\nzerokit:vac:maintenance\n\nresearched this issue https://github.com/vacp2p/zerokit/issues/21\n\n\nmisc\n\nOpened PRs to implement bitand & shr in circom-witness-rs: https://github.com/philsippl/circom-witness-rs/pull/14 & https://github.com/philsippl/circom-witness-rs/pull/13\n\n\n\nvac:sc:: §\nvac:rfc: §\n\nmisc\n\nWorked waku/specs repo - https://github.com/waku-org/specs/pull/1\nWorked on vac rfc repo - https://github.com/vacp2p/rfc-index\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nComparing mixnet Nym to figure out new design/proposal\nReviewing Nym paper and design\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nResearched the Transaction Directed Acyclic Graph (TDAG) framework to aggregate in SE and DE and produced a documentation about it (Moudy)\nStarted reading about the Privacy Directed Acyclic Graph (PDAG) framework (Moudy)\nMade progress on the integration of Cryptographic primitives in SE and DE (Ugur)\nMade progress on adress hiding and signature verification document (Marvin)\nStarted producing notes about Field Merkle Trees (Marvin)\nStarted creating the one-tier low-level framework for SE and DE kernel circuits by adding public and private data (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nContinued looking at Reverie whitepaper and Binius implementation (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nFixed PR#24 comments and merged Arecibo benchmark implementation(Rostyslav)\n\n\n"},"vac/updates/2024-02-19":{"title":"2024-02-19 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/02/19 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nhttps://github.com/status-im/nim-libp2p/pull/960\nTesting made it clear that the WebRtcMuxer wasn’t finished\n\nFix an oversight regarding datachannel incoming streams\nGet the streamId from SCTP to WebRtcTransport (missing a SCTP flag)\nFix a bug with binary-serialization (missing a compilation flag)\nFix a possible infinite loop that could occur while closing a stream\nFix WebRtcMuxer.new() (missing the connection field)\n\n\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nMore improvements, now merged - https://github.com/status-im/nim-libp2p/pull/1015 (feat: message prioritization with immediate peer-published dispatch and queuing for other msgs)\nMaking it ready to be merged - https://github.com/status-im/nim-libp2p/pull/1017 (feat: drop msgs to be relayed waiting for too long in the queue)\nWriting https://www.notion.so/Gossipsub-latency-improvements-9748092d135643ffb092939d9460fed0\nPlanning on how to check the IDONTWANT info before relaying a msg\n\n\n\nvac:tke: §\n\nnomos:cryptarchia-wealth-concentration-estimated-stake\n\nimplemented one more metric about wealth concentration (@Frederico)\nprepared the Figures that go into the report about Nomos wealth concentration (@Frederico)\nreview Frederico’s work on wealth concentration (Martin)\n\n\ncodex:cdx\n\ndesigned a diagram with Codex interactions (@Frederico)\ncreated a copy of the original Codex litepaper on GitHub (@Frederico)\ncatch up on latest developments to prepare for the call on Fr. (@Martin)\n\n\nwaku:economic-analysis\n\ncatch up on Sergei’s ongoing work (@Martin)\nanalyze the proposed store v3 protocol from a token economics perspective (@Martin)\nproceed with defining RLN pricing properties and suggest suitable mechanisms (@Martin)\n\n\nstatus:SNT-staking\n\nreviewing Ricardo’s new implementation of the staking contract (resolving the accounting issue) (@Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nUsing framework to get Thanos metrics\n\nFirst draft PR (https://github.com/vacp2p/10ksim/pull/3)\n\n\nStarted plotting module aswell (https://github.com/vacp2p/10ksim/tree/plotter)\n\n\neng-10ktool:vac:bandwidth-test\n\nSpun up a new test tracking page\nRan a few (~3-4) simulations trying to test new metric scale\nFixed a major issue with a node which improved our bandwidth by ~1/3rd\n\nThis also dropped packet loss to under 100 pps even under massive loads\n\n\nBrought distributed storage (CubeFS) properly online\nRe-ran simulations with Nwaku - stable swarms up to about 2000 peers, we were unable to see connections above that\nVLAN migrations continue\n\n\n\nvac:qa: §\n\nwaku:test-automation-js-waku\n\nRefactor and handle mocha hooks timeouts gracefully(@Florin)\nAdjust tests regarding latest failures on nwaku latest(@Florin)\n\nIssues reported:\n\nhttps://github.com/waku-org/js-waku/issues/1845\nhttps://github.com/waku-org/js-waku/issues/1835\nhttps://github.com/waku-org/js-waku/issues/1848\n\n\n\n\n\n\nwaku:interop-testing\n\nAdjust tests regarding latest failures(@Florin)\n\nIssues reported:\n\nhttps://github.com/waku-org/go-waku/issues/1034\nhttps://github.com/waku-org/nwaku/issues/2436\nhttps://github.com/waku-org/nwaku/issues/2437\n\n\n\n\nRLN support and tests added(@Roman)\n\nIssues reported:\n\nmessage not delivered during interop test\nhealth check endpoint needed\n\n\n\n\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\n\n\nwaku:test-automation-nwaku\n\nFinish investigating peer exchange and extend negative cases(@Alex)\n\n\nadmin/misc\n- Yamux PR(@Alex)\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nserde tests for rln-v2 in nwaku: https://github.com/waku-org/nwaku/pull/2421\nsolved previously known issue of waku-rln-relay continuing to run when the tree is in a bad state. now, whenever the node detects something wrong with the eth rpc endpoint, it disconnects and crashes: https://github.com/waku-org/nwaku/pull/2429\n\n\nrlnp2p:waku:rln-relay-enhancements\n\nimproved node setup with TWN config is set: https://github.com/waku-org/nwaku/pull/2423\ndeprecate wss/ws support from nwaku for eth rpc endpoint: https://github.com/waku-org/nwaku/pull/2442 & follow up: https://github.com/waku-org/nwaku/pull/2444\nupdated waku.test fleet config with http url instead of ws: https://github.com/status-im/infra-waku/pull/11\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nupdated docs for rln-relay in nwaku-compose: https://github.com/waku-org/nwaku-compose/pull/52\n\n\nsecure-channels:waku:ethereum-chat\n\nCompleted a first draft of the following sections of the paper: Introduction; Related work; MLS and SIWE.\nFinished the doc about comparion of the security mechanisms of Tor Messenger, Briar and update the existing doc in notion.\nStudy about the stealth addresses for anonymous secure chat.\n\n\nzerokit:vac:maintenance\n\nstarted working on a serde implementation of issue https://github.com/vacp2p/zerokit/issues/21\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-maintemance\n\nfix certora specs in github PRs (upgrade certoraRun)\nadd rule for setMaxSupply\nclean up spec\nimport config from r4bbit’s PR\n\n\nstatus:community-contracts-token-import\n\nstarted working on (Allow for community vaults to keep track of deposited tokens) https://github.com/status-im/communities-contracts/issues/31\n\n\nstatus:staking-contracts-v1\n\nMultiplier points estimation issue\n\nhttps://github.com/logos-co/staking/issues/48\n\n\nRefactor MP logic and fix bugs https://github.com/logos-co/staking/issues/51\n\nhttps://github.com/logos-co/staking/pull/52\n\n\nUpdated existing tasks based on latest discussions\nAdded new tasks to plan milestone\n\n\nstatus:community-contracts-multitoken\n\nCreated new milestone and tasks for upcoming effort to implement a new token contract for the desktop team\n\nhttps://github.com/status-im/communities-contracts/milestone/4\n\n\n\n\nvac:maintainance/misc\n\nAdd deployment address to sticker market repo\n\nhttps://github.com/status-im/sticker-market/pull/15\n\n\nAdded project board automation to relevant repos\n\nhttps://github.com/status-im/communities-contracts/pull/37\nhttps://github.com/status-im/communities-contracts/pull/39\nhttps://github.com/vacp2p/foundry-template/pull/15\nhttps://github.com/logos-co/staking/pull/50\n\n\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nWorked on Waku specs, should be ready for first merge - https://github.com/waku-org/specs/pull/1\nStarted updating COSS, not ready for feedback - https://github.com/vacp2p/rfc-index/tree/1-COSS\nWorked on Vac RFC Index, updated some files and updated readme - https://github.com/vacp2p/rfc-index/pull/2\n\n\nwaku:core-rfc-updates\n\nWorked on updating 10/Waku2 based on feedback - https://github.com/vacp2p/rfc/pull/661\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nadded new design ideas (https://docs.google.com/document/d/15X4vJTK_Hr3g3K01XF77R3KCqLI8LIm3/edit?usp=sharing&ouid=109850114495777070500&rtpof=true&sd=true)\n\n\nvalpriv:vac:tor-push-poc\n\nmerging torpush changes in the latest nimbus-eth2 stable release\n\n\nvalpriv:vac:tor-push-paper\n\nrevised last comments about structure\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nCreated a PR to minimize the relay peers set based on idontwant/receieved messages. https://github.com/status-im/nim-libp2p/pull/1027\n\nshowing small bandwidth and latency improvement with the increasing message sizes (still to test on very large messages)\n\n\n\n\nzk:codex:storage-proofs-open-problems-review\n\nProvide feedback on Range Proof example\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nResearched the Privacy Directed Acyclic Graph (PDAG) framework for privacy guarantees (Moudy)\nMade progress on the integration of Cryptographic primitives in SE and DE (Ugur + Moudy)\nMade progress on adress hiding and signature verification focusing on RingCT (Marvin)\nFinished the report about SE and DE kernel circuits in notion. (Ugur)\nStudied about a problem about nullifying randomization of notes (Ugur)\n\n\nproofsystems:vac:benchmarks\n\nFinished updating Arecibo document (Moudy)\nFinished updating halo2 document (Moudy)\nUpdated the main Benchmarks document (Moudy)\nBegin theoretical complexities for various proof systems (Rostyslav + Moudy + Marvin)\n\n\n"},"vac/updates/2024-02-26":{"title":"2024-02-26 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/02/26 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nYamux simulations https://github.com/status-im/nim-libp2p/pull/1029\n\nDebug the stairs showed with the metrics\nIt was due to a couple of error / bug:\n\nOn nwaku a ping connection opened wasn’t closed\nOn yamux the timeout wasn’t implemented\n\n\nThe implementation + testing of the implementation showed a sneaky bug (fixed)\n\n\n\n\nnimlibp2p:vac:webrtc-transport\n\nMerged the DataChannel giant PR https://github.com/status-im/nim-webrtc/pull/4\nMaintenance on nim-mbedtls https://github.com/status-im/nim-mbedtls/\nDebugging some issues with the interaction between the clients parts of dtls and sctp https://github.com/status-im/nim-webrtc/pull/5\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nTested and found issues with PR and possibly more that already exist - https://github.com/status-im/nim-libp2p/pull/1015 (feat: message prioritization with immediate peer-published dispatch and queuing for other msgs)\nExperimental PR - https://github.com/status-im/nimbus-eth2/pull/5911 - to test fixes for the above. It has been deployed to https://metrics.status.im/d/pgeNfj2Wz23/nimbus-fleet-testnets?orgId=1&from=now-6h&to=now&var-instance=erigon-10.ih-eu-mda1.nimbus.holesky&var-container=beacon-node-holesky-libp2p&refresh=5s\nCheck nimbus/libp2p discord channel for more info on the above.\n\n\nnimlibp2p:vac:maintenance\n\nBriefly investigate interop failing tests; Flaky: Added them to flaky tests doc\n\n\n\nvac:tke: §\n\nnomos:cryptarchia-wealth-concentration-estimated-stake\n\nfinalizing the report about wealth concentration on Nomos (@Frederico)\ncaught up with Frederico’s work on wealth concentration (@Martin)\n\n\nnomos:tdc-objectives\n\ncontinued reading the whitepaper and filling the TDC (@Frederico)\n\n\ncodex:cdx\n\nappended the CDX token interactions with the feedback from the Codex team (@Frederico)\nreviewed Codex team suggestions about data retrievability on other protocols (@Frederico)\n\n\nwaku:rln-membership:\n\ncaught up with Martin’s work on RLN pricing (@Frederico)\nprepare for and lead the discussion on RLN pricing, follow-ups (@Martin)\n\n\nstatus:SNT-staking\n\nhelped Martin with questions about radCAD model (@Frederico)\nreviewing Ricardo’s new implementation of the staking contract (resolving the accounting issue) (@Martin)\nexplore concepts and architecture for the staking module (role of relayer, vault factory) (@Martin)\nupdated the radCad model to reflect latest thinking on MPs (@Martin)\n\n\nwaku:general-incentives\n\nread papers suggested by Jarrad (@Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nSet up cluster without K3s (with Wings’s help) and test P2P PR 1045\nKeep working on Thanos metrics scrapping: PR: https://github.com/vacp2p/10ksim/pull/3\nGathered detailed metrics for paper on Waku scaling\nRan 4 simulations\nVarious metrics tuning on Emerald k8s\nCompletely rebuilt the Kubernetes cluster (and about 80% of the lab)\n\nNew cluster is called Opal, the sequel to Emerald\nUses Cilium (on top of the Multus metaplugin) for much higher network performance\nEntirely bare metal, currently 3 nodes (pending 4th node returning, happening by EOW)\nUses the new VLAN structure, clean credentials\n\n\nFixed an issue with Metrics still using Longhorn\nFigured out how to use the backup and restore tool Velero\nAdded KubeVirt for virtual machine hosting and management inside Kubernetes\n\nWill make it easier for us to provision machines for other teams\nBacked by Rook-Ceph\n\n\nMany tweaks to Kubernetes, Cilium, metrics, and more - see https://www.notion.so/Opal-Kubernetes-Cluster-Lab-Rebuild-4c8472546b0d47f5b05debacf9c7ac29\nFixed multiple major networking issues with the lab (again)\nAdded the ability to multi-home k8s pods through Multus (ie: attach them to multiple networks)\nDebugged and fixed a huge issue with TLS certificate issuance through Let’s Encrypt - turned out to be Cloudflare’s fault (Universal SSL basically broke my LE DNS-01 challenges, hard)\nScaled up Redis to 18 nodes (6 master, 12 replicas) for additional safety under heavy load\n\n\n\nvac:qa: §\n\nwaku:test-automation-js-waku\n\nPeer exchange tests(@Florin)\n\nIssues reported:\n\nhttps://github.com/waku-org/js-waku/issues/1858\nhttps://github.com/waku-org/js-waku/issues/1860\n\n\n\n\nUpgrade and test CI with nwaku v0.25.0(@Florin)\n\n\nwaku:interop-testing\n\nRemove deprecated flag(@Florin)\nFixed RLN_CREDENTIALS - Waku moved to use HTTP instead of WebSocket(@Roman)\nWaku node health/reliability(@Roman)\n\nKeep collecting info for issues:\n\nhttps://github.com/waku-org/nwaku/issues/2369\nhttps://github.com/waku-org/docs.waku.org/issues/165\n\n\n\n\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\n\nIssues reported:\n\nhttps://github.com/waku-org/go-waku/issues/1044\n\n\n\n\n\n\nwaku:test-automation-nwaku\n\nFinished Implementing Peer Exchange tests(@Alex)\nUnittest Library - Added Feature Request for nested suites(@Alex)\nFix imports and test related to missing imports(@Alex)\nBrief look on Connection & Peer Management(@Alex)\nStart working on Discv5 tests(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nincluded a PoC for small trees < 255 leaves where the root can be included onchain trustlessly via a view call - https://github.com/vacp2p/rln-contract/pul\n\n\nadmin/misc\n\nassisting waku research team with waku papers\n\n\nsecure-channels:waku:ethereum-chat\n\nCompleted a first version of the paper, including the detection a possible mitigation of lost messages.\nUpdate the internal Notion page.\nPrepare presentation for the Logos Research Call\nFinished the research about integration of ERC-5564 and EIP-4361(SIWE).\nStart to study about the anonymous chatting with stealth addresses.\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-token-import\n\nimplemented Vault.depositERC20\n\nhttps://github.com/status-im/communities-contracts/pull/53\n\n\n\n\nstatus:staking-contract-v1\n\nreview\n\nfix: StakeManager migration fixes and certora rules\n\n\nRefactor and fixes for StakeManager\n\nrefactor(StakeManager): refactor multiplier points logic\nfix(StakeManager): properly init accs and checks init\nfix(StakeManager): check for valid migration address\nfix(StakeManager): use a correct MP formula\nrefactor(StakeManager): change MIN_LOCKUP_PERIOD to 2 weeks\n\n\nResearch and fix for division precision loss\n\nchore: add gas-report for all contracts\nchore(StakeManager): add test for process account and unstake\nfix(StakeManager): use OpenZeppelin Math to avoid precision loss in int divisions\n\n\n\n\nvac:maintainance/misc\n\nFoundry Template\n\nimplemented gas-report\nimplemented command to prepare for commits\nresearch on EOL error in prettier for .json files\n\n\nSticker Market\n\nPublished Sticker Types from Mainnet in Sepolia\n\n\nInvestigated issue of ENS not working on Sepolia in Status Desktop\n\nhttps://github.com/status-im/status-desktop/issues/13697#issuecomment-1960877592\n\n\n\n\nstatus:community-contracts-maintenance\n\nDeployed communities contracts on OP Sepolia\n\nCommunityTokenDeployer\n\nhttps://sepolia-optimism.etherscan.io/address/0xcE2A896eEA2F585BC0C3753DC8116BbE2AbaE541#code\n\n\nCommunityOwnerTokenRegistry\n\nhttps://sepolia-optimism.etherscan.io/address/0xfFa8A255D905c909379859eA45B959D090DDC2d4#code\n\n\nCommunityOwnerTokenFactory\n\nhttps://sepolia-optimism.etherscan.io/address/0x420be6568c6e09782ceae1575495cd6c1c7ea04d#code\n\n\nCommunityMasterTokenFactory\n\nhttps://sepolia-optimism.etherscan.io/address/0x99F0Eeb7E9F1Da6CA9DDf77dD7810B665FD85750\n\n\nPR adding addresses to project README\n\nhttps://github.com/status-im/communities-contracts/pull/52\n\n\n\n\nInvestigated Certora rule issues for CollectiblveV1 token\n\nhttps://github.com/status-im/communities-contracts/pull/48\n\n\nCollectibleV1 is now CommunityERC721\n\nhttps://github.com/status-im/communities-contracts/pull/51\n\n\n\n\nstatus:community-contracts-batch-tx-ext\n\nImplemented safeBatchTransferFrom capabilities in BaseToken\n\nhttps://github.com/status-im/communities-contracts/pull/45\n\n\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nMerge Waku specs after Hanno feedback - https://github.com/waku-org/specs/pull/1\nWorked on COSS, still in draft - https://github.com/vacp2p/rfc-index/pull/4\n\n\nwaku:core-rfc-updates\n\nWorked on updating 17/WAKU-RLN-RELAY - https://github.com/vacp2p/rfc/pull/667\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nStill refining suggested ideas. slow this week.\n\n\nvalpriv:vac:tor-push-poc\n\nMerged the branch torpush and rebased but encountered several conflicts. Still testing and in progress on boarding for holesky\n\n\nvalpriv:vac:tor-push-paper\n\naddressed the feedback\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nConducted tests on [PR-1015], [PR-1017], [PR-1027], [PR-1028] against different scenarios\nadded notion page on large message transmissions for GossipSub https://www.notion.so/GossipSub-Improvements-Impact-of-Flood-Publishing-on-Large-Messages-9c6f15a6f1364adeade91d674ecdcb55\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nWorked on better message forwarding. Sorting on TxTime showed slightly improved results. Now Limiting senders to further saturate bandwidth for senders\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegin examining Reverie in terms of idea mentioned in the Discord feedback thread\n\n\nadmin/misc\n\nStudy RLN code for stateless proofs; this provides additional insight on how Merkle trees/Verkle trees can and should be coded better which is beneficial for Nescience notes in the long run.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nFinished researching the Privacy Directed Acyclic Graph (PDAG) framework for privacy guarantees\nStarted looking at monitoring issues\nStarted looking at Nullifier issues to avoid linkeability\nResearch joinsplit and optimistic rollups for monitoring\nBegin documents on joinsplit and monitoring\n\n\nproofsystems:vac:benchmarks\n\nWritten a first expanded draft for Benchmarks research paper\nResearch for table comparison\n\n\nproofsystems:vac:benchmarks\n\nprepared explanation for Halo2 GWC and SHPlonk implementations (https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#2eb24a7ce01447bebbf8f5f966aede7a and https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#26d2fc825c9845f1a0ee6288f18694ce)\nprepared explanation for Arecibo implementation (https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#4fd8570d40d14e228f4d9dc08e0c2ab1)\nFixed various PRs comments\nAdded verify benchmark for Nova Circom + number of constraints (https://github.com/vacp2p/zk-explorations/pull/25)\nAdded verify benchmark for Nova Bellman + number of constraints (https://github.com/vacp2p/zk-explorations/pull/30)\nAdded verify benchmark for Arecibo + number of constraints (https://github.com/vacp2p/zk-explorations/pull/29)\nAdded verify benchmark for Plonky2 + number of constraints (https://github.com/vacp2p/zk-explorations/pull/26)\nResearched- state-separation:vac:state-separation-doc\nFinished researching the Privacy Directed Acyclic Graph (PDAG) framework for privacy guarantees\nStarted looking at monitoring issues\nStarted looking at Nullifier issues to avoid linkeability\nResearch joinsplit and optimistic rollups for monitoring\nBegin documents on joinsplit and monitoring\n\n\nproofsystems:vac:benchmarks\n\nWritten a first expanded draft for Benchmarks research paper\nResearch for table comparison\n\n\nproofsystems:vac:benchmarks\n\nprepared explanation for Halo2 GWC and SHPlonk implementations (https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#2eb24a7ce01447bebbf8f5f966aede7a and https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#26d2fc825c9845f1a0ee6288f18694ce)\nprepared explanation for Arecibo implementation (https://www.notion.so/Nescience-cd358fe429b14fa2ab38ca42835a8451?pvs=4#4fd8570d40d14e228f4d9dc08e0c2ab1)\nFixed various PRs comments\nAdded verify benchmark for Nova Circom + number of constraints (https://github.com/vacp2p/zk-explorations/pull/25)\nAdded verify benchmark for Nova Bellman + number of constraints (https://github.com/vacp2p/zk-explorations/pull/30)\nAdded verify benchmark for Arecibo + number of constraints (https://github.com/vacp2p/zk-explorations/pull/29)\nAdded verify benchmark for Plonky2 + number of constraints (https://github.com/vacp2p/zk-explorations/pull/26)\nResearched ways to calculate halo2 constrain ways to calculate halo2 constrain\n\n\n"},"vac/updates/2024-03-04":{"title":"2024-03-04 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/03/04 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nSctp and Dtls client done: https://github.com/status-im/nim-webrtc/pull/5\nAdds a lot of comments some refactoring to improve (I hope) the readability https://github.com/status-im/nim-webrtc/pull/6\nClosing the streams/connections: starts to test and think about it to make it bulletproof\n\n\nnimlibp2p:vac:maintenance\n\nInvestigating issues related to https://github.com/status-im/nim-libp2p/pull/1032\n\n\n\nvac:tke: §\n\nnomos:tdc-objectives\n\nexpanded the objectives & requirements part of the TDC (@Frederico)\n\n\ncodex:cdx\n\nincorporated into Codex Litepaper all material about Codex on GitHub (@Frederico)\nreviewed the causal loop diagragam for Codex (@Frederico)\nreviewed the stock and flow diagram for Codex (@Frederico)\n\n\nwaku:rln-membership:\n\nPrepare a summary of the RLN membership model including user journey mapping (@Martin)\nReview the pricing of Farcaster, etc. (@Martin)\n\n\nwaku:general-incentives\n\nFollow up with general research into Waku strategy based on the IFT strategy call. (@Martin)\n\n\nstatus:SNT-staking\n\nContinue the review of the staking contract (@Martin)\nUnderstand the severity of precision loss (due to Solidity constraints) and resulting discrepancy between the contract logic and radCad simulations (@Martin)\nAssist the SC team in further checks and definition of testing scenarios (@Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nWork on plotting module in the Kubernetes framework\n\nModified main yaml to add plotting options\nCreated plotter class to group there all functionalities\nStructured plotter to be able to group several experiments in same plot in an automatic manner\n\n\nLots of calls with Wings to test the lab, launch simulations, discuss about problems and so on.\n\n\nDeployed iBGP for Calico\n\nWhich got the IP addresses wrong at first, fixed by editing Node annotations\nLater removed BGP due to numerous issues with it\n\n\nNumerous, numerous Kubernetes tests and improvements\n\nTried Cilium briefly\nSwitched from Cilium to Calico\nReinstalled entire cluster as Calico transition broke things (due to CNI switch without reinstall being a bad idea)\n\n\nScale testing revealed that Linux has limits per node that prevent us from scaling beyond about ~1400 waku nodes per physical host when running on bare metal\nCreated a new architecture for running tests\n\nHybrid between bare metal and virtualised Kubernetes\nRook-Ceph (Storage) and Prometheus-Thanos (Metrics) stacks run on bare metal, as does all management\nThe rest runs in a KubeVirt based deployment system.\n\nWe deploy what we’re calling “opal fragments” (fractions of the Opal Kubernetes cluster) - Kubernetes workers dedicated solely to running nwaku deployments.\n\n\nCan deploy 5000 nodes in < 8 minutes, with stable mesh forming around 25 minutes into deployment\n\n\nExperimented with various opal fragment deployments - 56x nodes seems to be the most stable configuration\n\nMuch higher than this (especially with poor allocation of cores) causes instability in the CNI (Calico)\n\nWhich causes monitoring issues as nodes drop out of Prometheus monitoring\nAnd can mess with the mesh\n\n\nInstability is lower with lower # of connections\n\n\nDebugging CoreDNS issues - believe we’ve found a bug in CoreDNS and its interactions with HeadlessServices, returning NXDOMAIN even for valid hostnames about 1 in 5.5 to 6 queries.\nRan repeated simulations to get a stable simulation for testing.\nBuilt a new “accelerated bootstrap” mode for simulations\n\nvac:qa: §\n\nwaku:test-automation-js-waku\n\nFix flaky tests(@Florin)\nClose milestone(@Florin)\n\n\nwaku:test-automation-sharding\n\nImprove static sharding and autosharding tests coverage for js-waku(@Florin)\nIssue reported:(@Florin)\n\nhttps://github.com/waku-org/js-waku/issues/1874\n\n\n\n\nwaku:interop-testing\n\nWaku node health/reliability(@Roman)\nIssue updated:\n\nhttps://github.com/waku-org/go-waku/issues/1014)\n\n\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\nIssue updated:\n\nhttps://github.com/waku-org/go-waku/issues/1044\n\n\n\n\nwaku:test-automation-nwaku\n\nPeer Exchange(@Alex)\n\nResultify fetchPeerExchangePeers\n\n\nDiscv5(@Alex)\n\nImplement tests and simplify and reduce code\n\n\nPeer & Communication Management(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nimproved testing for rln-v2 onchain mode: https://github.com/waku-org/nwaku/pull/2482\nimproved testing for rln-v2 static/offchain mode: https://github.com/waku-org/nwaku/pull/2484 (pending review)\n\n\nsecure-channels:waku:ethereum-chat\n\nFinish the presentation for the Logos Research Call.\nImprove the research paper.\nConsidering replacing MLS with another protocol.\nAdd an overview on anonymity and SIWE integration in notion.\nStudy on hierarchical deterministic wallets for anonymous login.\nStudy the openmls crate for demo implementation.\n\n\nzerokit:vac:maintenance\n\ntaken a look on this issue https://github.com/vacp2p/zerokit/issues/47\n\n\nadmin/misc\n\nassist with waku research paper\nstealth commitment protocol over waku PoC: https://github.com/waku-org/nwaku/pull/24\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-token-import\n\nfinished PR erc20/erc721 deposit PR\nimplemented withdraw function for tokens sent directly to the contract https://github.com/status-im/communities-contracts/pull/59\n\n\nstatus:staking-contracts-v1\n\nReviewed and merged PRs\nContinue work on coverage\nImplemented additional deployment script for new StakeManagers\n\nhttps://github.com/logos-co/staking/pull/72\n\n\nWorked on fixing certora specs\n\nhttps://github.com/logos-co/staking/pull/73\nhttps://github.com/logos-co/staking/pull/74\nhttps://github.com/logos-co/staking/pull/75\n\n\nFixed a bug that allows StakeManagers to reset another one’s Stakemanagers epoch while it’s in migration\n\nhttps://github.com/logos-co/staking/pull/76\n\n\n\n\nstatus:community-contracts-maintenance\n\nRelease version 1.0.0 of communities contracts\n\nChangelog: https://github.com/status-im/communities-contracts/blob/main/CHANGELOG.md#100-2024-02-28\n\n\n\n\nvac:maintainance/misc\n\nWorked on Logos Research call presentation\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nworked rfc process - https://github.com/vacp2p/rfc-index/pull/8\nworked on pull request for rfc-index - https://github.com/vacp2p/rfc-index/pulls\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nRefined and working on https://docs.google.com/document/d/15X4vJTK_Hr3g3K01XF77R3KCqLI8LIm3/edit\n\n\nvalpriv:vac:tor-push-poc\n\nSuccessfully merged , built the torpush while rebasing from stable nimbus.\n\n\nvalpriv:vac:tor-push-paper\n\nImproved and revised the draft. like citing tor related attacks with relevance for tor push while making many other minor points and clarification https://www.overleaf.com/project/6499e467346d9f56b2971caa\nCreated a notion page on findings on large message handling: https://www.notion.so/Performance-Evaluation-of-Different-Pull-Requests-for-Large-Message-Handling-4d47672820114732b9f248f6bf18946e\nMerged PR-1027, PR-1028 and used TxTime sorting on SendPeerList. Additionally used semaphors to limit simultaneous transmissions. Improves results in some cases and shows large fluctuations in other messages\nConfigured shadow simulation for variable latency and bandwidths. Trying to build some automated scripts (requires adding edges among all peers, and adding all nodes with variable latency/bandwidth). NetworkX package in python can help writing network in gml format\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nResearched and discussed about monitoring issues and how to adapt solutions to our proposal (Moudy + Marvin)\nResearched and discussed about nullifeir problems and how to solve them (Moudy + Ugur)\nStudied untraceability and unlinkability features of PDAGs to create our version of PDAGs (Ugur)\nStared working on reward mechanisms for monitoring (Marvin)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished writing Reverie writeup (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nWorked on refining the Benchmark paper and drafted a full version (Moudy)\nWent through the Benchmarks paper and discussed about modifications to make and general output (Moudy + Rostyslav)\nModified Halo2 SHPLONK, Halo2 GWC and Plonky2 circuits (Rostyslav)\nPrepared a paragraph on Nova vs SuperNova difference and Nova vs Halo2 recursion (Rostyslav)\n\n\n"},"vac/updates/2024-03-11":{"title":"2024-03-11 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/03/11 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFinish commenting and refactoring Sctp and DataChannel https://github.com/status-im/nim-webrtc/pull/6 (merged)\nTry to implement CI and make it work on differents OS (it fails) https://github.com/status-im/nim-webrtc/pull/1\nMove usrsctp from nim-webrtc to its own repository: https://github.com/status-im/nim-usrsctp\nClean nim-webrtc for the review\n\nUDP: https://github.com/status-im/nim-webrtc/pull/8\nStun: https://github.com/status-im/nim-webrtc/pull/9\nDTLS: https://github.com/status-im/nim-webrtc/pull/10\nSCTP: https://github.com/status-im/nim-webrtc/pull/11\nDataChannel: https://github.com/status-im/nim-webrtc/pull/12\n\n\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nReviewing and discussing https://github.com/status-im/nim-libp2p/pull/1051. It’s related to prio queues in GossipSub.\n\n\nnimlibp2p:vac:maintenance\n\nCreating questions for interview.\nTrying to run interop tests with chronos 3 - https://github.com/status-im/nim-libp2p/pull/1055\nvarious PR reviews\n\n\nnimlibp2p:vac:maintenance\n\nproto3 repeated uint32 handling\n\nIssue\nDouble check jacek’s answer: All good.\nsingle topic in rpc message\n\nIssue\nImplement fix PR\n\n\ngraceful shutdown\n\nIssue Investigated and requested more info\n\n\n\n\n\n\n\nvac:tke: §\n\nwaku:rln-membership:\n\nPrepare a summary of the RLN membership model including user journey mapping (need to discuss with Waku team further) (Martin)\nPrepare and iterate on the token economy suggestions for Waku (Martin)\nFollow-ups from the Tokenomics call (Martin)\n\n\nstatus:SNT-staking\n\nContinue to monitor development and give feedback for the staking contract (Martin)\nAssist the SC team in further checks and definition of testing scenarios (Martin)\nFollow-ups from the Status Chain IFT Strategy call (Martin)\n\n\nnomos:tdc-objectives\n\nfinalized the objectives & requirements part of the TDC (inc. mixnet nodes below) (Frederico)\n\n\nnomos:mixnet-incentives\n\nunderstood the mixnet incentivization problem (Frederico)\nread Nym reward sharing scheme for mixnets (a comparable) (Frederico)\nanalysed the differences between single vs. multi-staking approaches (Frederico)\n\n\nwaku:general-incentives\n\ncaught up with Martin’s tokenomics proposal (Frederico)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nMain thing is to retrieve waku simulations Data and plot them\n\nPrepare deliverable for Waku\n\nFinish running several simulations with different sizes and message rates\nExtract data\nPrepare and clean plots\nDiscuss again with Wings what we should explain in the deliverable\n\n\n\n\nAdd tests to plotter module\nScrapping PR aproved by Alex: https://github.com/vacp2p/10ksim/pull/3\nDeliverable for Waku simulations\nDiscussions with some friends about how to scale further\n\nNoted that there was at least 8 layers for every packet to pass through with current setup\n\n\nNetwork restructuring - OVS + Mellanox OFED + asap2 attempts\n\nAdded Proxmox to Vaxis and Nia (converting them)\n\nAdded Mellanox OFED drivers\nUpdated firwmare\nMoved to OpenvSwitch networking\n\n\n\n\nDeployed Kubernetes onto the new machines\n\n\n:vac:lab\n\nPreparing for power upgrades\nAdded Vaxis, Nia, new 64 core nodes\nAdded new 25G switch\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nUse fixed versions for dependecies(@Florin)\nAdjustments and improvements(@Florin)\nTried to reproduce the disconnecting light clients issue and found a similar issue(@Florin)\n\n\nwaku:test-automation-sharding\n\nUnit and interop tests(@Florin)\nDiscovered autosharding is hardcoded for cluster ID 1(@Florin)\nHelp js-waku devs to improve CI error handling(@Florin)\nRaised issue for flaky CI test(@Florin)\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\nClosed triggerDiscovery issue(@Roman)\nImprove unit test coverage for peer exchange(@Roman)\n\n\nwaku:test-automation-nwaku\n\nKEYSTORE_PASSWORD env variable is not effective - resolved(@Roman)\nTrying to reproduce, fix and add new test case for metadata protocol disconnecting light clients issue(@Alex)\nSolved some issues related to metadata connection between two nodes.(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\nOptimized the Nullifier Table usage to O(1) reads to detect double signaling: https://github.com/waku-org/nwaku/pull/2508\nFixed execution error when trying to fetch metadata from a freshly created tree (nwaku side): https://github.com/waku-org/nwaku/pull/2516\n\n\nrlnp2p:waku:rln-relay-v2\n\nWrap up tests for rln-relay-v2: https://github.com/waku-org/nwaku/pull/2501 (pending review)\n\n\nzerokit:vac:maintenance\n\nFix execution error when trying to fetch metadata from a freshly created tree (zerokit side): https://github.com/vacp2p/zerokit/pull/231 (rln-v1) & https://github.com/vacp2p/zerokit/pull/232 (rln-v2)\n\n\nsecure-channels:waku:ethereum-chat\n\nExplore a proposal on decentralized CGKA by Weidner et al. as a replacement for the MLS protocol.\n\n\nsecure-channels:waku:ethereum-chat\n\nCheck the literature for related the papers CoCoA, 2, 3, and DCGKA\nQuickly check the literature to see if there are any improvements in MLS and its problems.\nStarted to focus on DCGKA by reading Ramses’ note\n\n\nzerokit:vac:maintenance\n\nresearched Rust for Android for issue #47\n\n\nadmin/misc\n\nFixed compilation without the postgres feature in nwaku: https://github.com/waku-org/nwaku/pull/2500\nwaku research paper\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-token-import\n\nfinished withdrawal PR\nadded tests for erc20 withdrawal https://github.com/status-im/communities-contracts/pull/60\nstarted a POC for Vault migration to discuss about https://github.com/status-im/communities-contracts/issues/32\n\n\nstatus:staking-contracts-v1\n\nContinue work on coverage\nFixed broken certora rule to get CI green again\n\nhttps://github.com/logos-co/staking/pull/78\n\n\nAdded invariant to ensure Vault accounting preserves ERC20 balances\n\nhttps://github.com/logos-co/staking/pull/56\n\n\nWorked on pending Certora rule to get them pass on CI\n\nhttps://github.com/logos-co/staking/pull/58\nhttps://github.com/logos-co/staking/pull/57\nhttps://github.com/logos-co/staking/pull/81\n\n\n\n\nvac:maintainance/misc\n\nAnalysis of SNT impact on ethereum state\nResearch on Market Makers of other wallets\nLogos Research call preparation and presentation\n\nSlides: https://docs.google.com/presentation/d/1pdW3JZxqh7t_Aqd-cfIi1_JP4_8gyCk5XDBeY3nsrrE/edit?usp=sharing\nVideo: https://drive.google.com/file/d/1NGZWkEAWMoeHMQXpIi2fStyzQYqbfSKG/view?pli=1\n\n\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nadded markdown-lint workflow to rfc-index- https://github.com/vacp2p/rfc-index/pull/24\nfinished moving final open waku specs from vac/rfc - https://github.com/vacp2p/rfc/pulls\n\n\nmisc\n\nworked on pr for 64/WAKU2-NETWORK - https://github.com/vacp2p/rfc-index/pull/5\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nMoved the content to notion https://www.notion.so/privacy-preserving-validator-network-e92ab3e563074a538bb0e13e5c9321e6\n\n\nvalpriv:vac:tor-push-poc\n\nRunning holesky validators, getting over sync/deposit issue\n\n\nvalpriv:vac:tor-push-paper\n\nImproved the draft https://www.overleaf.com/project/6499e467346d9f56b2971caa\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nCompleted topology generation scripts for shadow simulator. PR4 now supports running simulations with variable latency, bandwidth, packet loss ratio, and also allows adjusting network/message size, fragmentation and publisher settings\nCreated a notion page on message forwarding/queuing in other libp2p implementations (go-libp2p):\nCreated a vac forum post on large message handling\n\n\nadmin/misc\n\nReviewed Waku-RLN paper\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nResearched accumulators and how to combine them to Homomorphic encryption + prepared a document about it (Moudy)\nResearched how to make salt approach dynamic and will prepare a document about it (Moudy)\nBegan reading portions of Nexus VM and GKR-based VM (Marvin)\nRead various papers concerning reward mechanisms for miners/observers. 1, 2, 3, 4, 5 (Marvin)\nAlmost completed report about SE/DE in PDAGs (Ugur)\nRead accumulators about Zerocoin nullifier mechanism in this paper (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\ntook a look at Nexus VM and LatticeFold (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nWorked on abstract, tables for paper (Moudy)\nWorked on researching Nova vs. Supernova (Moudy)\nStarted Nova vs. Halo2 recursion vs. aggregation (Moudy)\nPrepared explanation for Nova Bellman implementation (Rostyslav)\nConducted local benchmark testing (Rostyslav)\n\n\n"},"vac/updates/2024-03-18":{"title":"2024-03-18 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/03/18 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\npreparing interview\nreviewing PRs\nGraceful Shutdown (1007) Fix\n\nPR\n\n\nSingle topic for RPC Message (1052)\n\nPR Update PR with suggestions\n\n\n\n\n\nvac:tke: §\n\nadmin/misc\n\nreviewed CVs (Frederico)\nInterviews with candidates (Martin)\n\n\nnomos:mixnet-incentives\n\ndeveloped a pricing model for packets routed through the mixnet (Frederico)\nmodified Nym reward allocation mechanism to Nomos constraints (Frederico)\n\n\ncodex:cdx\n\ndesigned the CDX insurance model (Frederico)\n\n\nstatus:L2-deployment\n\nkicked off a list of L2 comparables, focused on business models and ecosystem incentivization (Frederico)\nKicking off work on incentives for L2 (Martin)\n\n\nwaku:rln-membership:\n\nProposing new RLN membership structures to the team - other than price per membership (Martin)\nFollow-ups to Franck’s response to our material we presented last week (Martin)\n\n\nstatus:SNT-staking\n\nContinue to monitor development and give feedback for the staking contract (Martin)\nAssist the SC team in further checks and definition of testing scenarios (Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nFinish plotter module tests and prepare PR (ongoing)\nImprove framework scraping interval (https://github.com/vacp2p/10ksim/issues/8)\nTry kubernetes API portforwading again\nSimulations:\n\nUpdated waku to 0.26\nChanged some parameters (flags, memory available, etc)\nResults with 3k matches perfectly with 1K in terms of bandwidth.\n\nBootstrap now doens’t crash. Caused by OOM previously.\n\n\n\n\n\n\neng-10ktool:vac:bandwidth-test\n\nVarious simulations, gathering additional data\nCalls with @Alberto, helping fix scraping\nAttempted to get hardware offloading working on existing ConnectX-4 LX adapters\n\nConclusion was it’s not possible (NVIDIA deprecated the offloading for CX4LX) but we’re now in a good place to try offloading on the new CX6s once they arrive\nCX6s are at the post office waiting for pickup -> installation\n\n\n\n\nadmin/misc\n\nMet with Codex team re: helping with Codex testnet\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nFinished js-waku sharding tests and prepared PR for review(@Florin)\nIssues found:(@Florin)\n\nAllow subscribeToContentTopic to use other cluster IDs\nApplicationInfo to PubsubTopic doesn’t take clusterId into consideration\n\n\n\n\nwaku:interop-testing\n\nCreated scripts to help reproduce bugs 2512 and 1034(@Florin)\nImprove logs for manual debug(@Florin)\nFound go-waku regression/issue(@Florin)\nWaku node health/reliability Issue 2369 - updated and Issue 165 - updated(@Roman)\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager(@Roman)\nIssues found:(@Roman)\n\nMetadata might not always be available\nDescribe topic event transition between libp2p and peer manager level\n\n\nImprove unit test coverage for peer exchange(@Roman)\nImprove unit test coverage for Discv5(@Roman)\n\n\nwaku:test-automation-nwaku\n\nResultify fetchPeerExchangePeers(@Alex)\nSimplify imports(@Alex)\nFix and add test cases for Metadata protocol disconnecting light clients 2491(@Alex)\nMerge Peer Exchange Tests PR(@Alex)\nMerge Discv5 PR(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-v2\n\nrln-relay v2 integrated into nwaku: https://github.com/waku-org/nwaku/issues/2345\n\n\nsecure-channels:waku:ethereum-chat\n\nPrepare a Notion page containing a specification for the DCGKA algorithm.\nThink and propose solutions to some the DCGKA limitations.\nhttps://www.notion.so/DCGKA-Specification-5a0b67a3ce674ae3a5220b560015cd2c#8f9f17014e5a479788da2544d64a993e\nStudy Ramses’ notes in Notion\nRead about Jitsi in this paper\nRead about difficulties on decentralization of MLS section 8.5 of paper\n\n\nmisc\n\ngnark-rln implementation: https://github.com/vacp2p/gnark-rln\nadded multiple curves to rust stealth address repo: https://github.com/vacp2p/erc-5564-rs\nassist with deploying waku-rln-contract to waku-simulator\n\n\n\nvac:sc:: §\n\nstatus:staking-contracts-v1\n\nMerged coverage improvements\nFinished ironing out all pending certora rules\n\nhttps://github.com/logos-co/staking/pull/81\nhttps://github.com/logos-co/staking/pull/82\nhttps://github.com/logos-co/staking/pull/85\nhttps://github.com/logos-co/staking/pull/86\nhttps://github.com/logos-co/staking/pull/57\n\n\n\n\n\n\nstatus:community-contracts-token-import\n\nReviewed/discussed migration options for community vaults\n\nhttps://github.com/status-im/communities-contracts/issues/32#issuecomment-1997000297\n\n\n\n\n\n\nvac:maintainance/misc\n\nResearch on ENS Usernames to change release delay\n\n\n\nvac:rfc: §\n\nrfc-process-restructuring\n\nMarkdown lint does not lint files, proposed fix- https://github.com/vacp2p/rfc-index/pull/25\nOpen the proposal to COSS changes - https://github.com/vacp2p/rfc-index/pull/4\n\n\nmisc\n\ncreate website repo - https://github.com/vacp2p/rfc-website\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nFinalized and share the related proposal()\nhttps://www.notion.so/privacy-preserving-validator-network-e92ab3e563074a538bb0e13e5c9321e6\n\n\nvalpriv:vac:tor-push-poc\n\nholesky validators registration and execution\n\n\nvalpriv:vac:tor-push-paper\n\nhttps://www.overleaf.com/project/6499e467346d9f56b2971caa\n\n\ngsub-scaling:vac:gossipsub-improvements-paper\n\nImplemented IMReceiving message for use with IDontWant message to improve GossipSub performance against v. large message. Experimental PR is available for review/discussion.\n\nThis is just a prototype experiment showing 40% bandwidth reduction and more than 10% latency reduction for 1MB messages.\nRequires feedback, as it needs new message inclusion\n\n\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nConducted results for different IDontWant/IMReceiving message use cases. The results are available in VAC forum post.\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegan examining current version of Codex system’s description\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nDrafted document about privacy improvements for state separation (Moudy)\nContinue work on monitoring (Marvin)\nDefined new milstones (Moudy)\nCompleted report about SE/DE in PDAGs see in Notion (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nchecked out this Hypernova implementation and continued reading LatticeFold (Rostyslav)\nDefined new milstones (Moudy)\n\n\nproofsystems:vac:benchmarks\n\nOverlooked at the paper and continued researching Nova vs. Supernova/ Nova vs. Halo2 recursion vs. aggregation (Moudy)\nDefined new milstones (Moudy)\nWorked on enhancing Nova-Scotia performance (Rostyslav)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nDefined new milestones (Moudy)\n\n\n"},"vac/updates/2024-03-25":{"title":"2024-03-25 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/03/25 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nStun protocol: Trying to understand how to implement the ICE lite protocol without breaking everything done so far https://github.com/status-im/nim-webrtc/pull/9\nSctp protocol: Unregister address after closing https://github.com/status-im/nim-webrtc/pull/11\nnim-libp2p: Add comments https://github.com/vacp2p/nim-libp2p/pull/960\nDataChannel: First draft on closing stream https://github.com/status-im/nim-webrtc/pull/12\nUDP/Dtls: small fixes\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nfeat: add max number of elements to non-prio queue - https://github.com/vacp2p/nim-libp2p/pull/1077j\n\n\nnimlibp2p:vac:maintenance\n\nvarious PR reviews\npreparing for hiring interviews and interviewing\n\n\n\nvac:tke: §\n\nwaku:general-incentives\n\nContinuing the discussion with the Waku team on the marketplace idea (Martin)\nreviewed the discussion about Waku marketplace (Frederico)\n\n\nwaku:rln-membership:\n\nScoping out and working on the deliverables for RLN design (Martin)\n\n\nstatus:SNT-staking\n\nFull review of the MP logic within the smart contract (Martin)\nSupporting the SC team ad hoc (Martin)\n\n\nstatus:L2-deployment\n\nReviewing airdrop strategies of existing L2s (Martin)\nlisted business models and ecosystem incentivization of L2 comparables (Frederico)\n\n\ncodex:cdx\n\nRevisiting fundraising docs and starting a closer cooperation with Matt (Martin)\ndesigned the CDX insurance model as a liquidity pool (Frederico)\nevaluated token allocation and initial distribution of comparables (Frederico)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nFinish plotter module tests and prepare PR (ongoing)\nThanos PR merged (https://github.com/vacp2p/10ksim/pull/15)\nCreate class to manage data (https://github.com/vacp2p/10ksim/pull/16).\nhardware offloaded for Waku testing\n\nBuilt 24 new Kubernetes workers, configured them with static IPs and all tuning\nGot new CX6 cards updated, configured, installed and working\nAchieved hardware offloading; but:\nRunning a Waku workload, two interesting things happened\n\nWhen we started the publisher, the load increased until the physical nodes become so unusably slow that they needed IPMI intervention to come back to life\nChecking the offloadeded flows during the test (prior to publishing) showed no offloaded routes or flows.\n\n\nWe need to figure out how to get our workload offloaded correctly.\n\n\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nMerged js-waku sharding tests PR(@Florin)\nAdd repro scripts folder(@Florin)\nInterop sharding tests draft PR(@Florin)\nRechecked some fixes for older bugs(@Florin)\nGo-waku sharding tests pr(@Roman)\nIssues found:\n\nautosharding resolves content topics to wrong shard(@Florin)\ndont harcode clusterid for autosharding in go-waku(@Florin)\nsubscription not found when node is started with —pubsub-topic flag(@Florin)\nonly receive messages if someone subscribes explicitly via REST API to a pubsubTopic(@Florin)\nephemeral field is ignored(@Florin)\ndata race occurs when publishing to unsubscribed pubSubTopic(@Roman)\n\n\n\n\nwaku:test-automation-go-waku\n\nImprove unit test coverage for peermanager PR 1062 - merged(@Roman)\nImprove unit test coverage for Discv5 PR 1051 - pending on 1059(@Roman)\nIssues found:\n\nrace condition while setting boot nodes for Discv5(@Roman)\n\n\n\n\nwaku:test-automation-nwaku\n\nMetadata protocol disconnecting light clients(@Alex)\n\nMerged PR\n\n\nPeer & Communication Management(@Alex)\n\nContinue implementing tests\nFix minor bug, peerId duplicated when adding to PeerStore\n\n\n\n\nwaku/maintenance-nwaku\n\nFix macos tests(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancments\n\ninvestigate and improve robustness of rln-relay, still in progress - https://github.com/waku-org/nwaku/pull/2537, https://github.com/waku-org/nwaku/pull/2545\n\n\nsecure-channels:waku:ethereum-chat\n\nCreated a PR with a first version of the RFC on the proposal for the decentralized communication protocol.\nhttps://github.com/vacp2p/rfc-index/blob/ETH-SECPM-DEC/vac/raw/Decentralized%20messaging%20Ethereum.md\nStarted exploring UPKE as a potential tool for the decentralized protocol.\nDiscussed with Ugur some aspects of DCGKA around causal order.\n\n\nsecure-channels:waku:ethereum-chat\n\nAttached some comments on DCGKA specification in notion\nResearch about causal ordering and create a small doc about it in notion\nQuickly check the paper that compares and analyzes DCGKA (https://eprint.iacr.org/2022/1531.pdf)\nDiscuss with Ramses about decent SIWE, complexity and causal ordering.\nStarted to examine DCGKA implementation to understand which causal ordering is used in this repo\n\n\n\nvac:sc:: §\n\nstatus:community-contracts-token-import\n\nstarted Vault migration PR https://github.com/status-im/communities-contracts/pull/62\n\n\nvac:maintainance/misc\n\nResearch overview on DEX aggegators\n\n\nstatus:staking-contracts-v1\n\nWorked on deposit cooldown period implementation\n\nBunch of questions came up\n\nDiscussion: https://github.com/logos-co/staking/issues/14#issuecomment-2007432214\n\n\nWIP branch: https://github.com/logos-co/staking/commit/8c5dd440404d6184937fa65deec67e00b24e159b#diff-b710313a5571054e746fc0e0d1332e5894fc76a55ffb035711d912c00bf8f826\n\n\n\n\n\nvac:rfc: §\nLast week:\n\nmisc\n\nOpened waku-metadata to move to draft - https://github.com/vacp2p/rfc-index/pull/6\nWorked on workflow to sync rfc website - https://github.com/vacp2p/rfc-index/pull/27\nCreated workflow fix for markdown lint - https://github.com/vacp2p/rfc-index/pull/25\nFixed broken links - https://github.com/vacp2p/rfc-index/pull/26\n\n\n\nvac:dr: §\n\nvalpriv:vac:val-priv-net\n\nFeedback waiting competing/ proposal (https://docs.google.com/document/d/1UNOJfA-4f6tco3ozuiyLIbfDkf70Mh_6OqEfB8vmblE/edit?usp=sharing)\n\n\nvalpriv:vac:tor-push-poc\n\ncould not launch holesky validators yet this week.\n\n\nvalpriv:vac:tor-push-paper\n\nFinished changes as per feedback; next feedback round\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nPlayed with IDontWant messags with different arrangements. Mainly investigated reduced message sending with/without hello messages.\nReduced sending shows nearly 5-10% latency and 20-25% bandwidth reduction when message sizes reach beyond 600 KB.\nThe findings are available as notion page\n\nInterestingly {Reduced sending + IDontWant} without IHAVE messages shows similar performance to {Reduced sending + IDontWant + IHAVE}\n\n\n\n\nzk:codex:storage-proofs-open-problems-review\n\nFinish examining current version of Codex system’s description\nRead Balazs’ notes on Plonk\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nWorked on Defining state separation’s SE and DE using PDAGs (Moudy)\nLooked at nullifiers and their role in the architecture (Moudy)\nWorked on different components for State Separation Architecture (Moudy)\nResearched accumulators and trying to study how to integrate them (Moudy)\nUpdated report according to the meeting with Moudy about SE/DE in PDAGs (Ugur)\nReading on scalable privacy NC + state of art accumulation (Ugur)\nContinued with monitoring (Marvin)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nchecked out PNova implementation + finished reading LatticeFold (Rostyslav)\nBegan reading Mangrove (Marvin)\n\n\nproofsystems:vac:benchmarks\n\nStill working on the paper since new findings are arising (i.e. Nova Scotia not using Groth16) (will focus on that this week) (Moudy)\nDealt with server issues + prepared paragraph on difference in Nova-Scotia and Nova-Bellman (Rostyslav)\n\n\n"},"vac/updates/2024-04-02":{"title":"2024-04-02 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/04/02 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFix the WebRTC CI on Windows/MacOS\nMbed-TLS: improve installation/code generation\nAddress all the comments on UDP\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nBump libp2p and fix compilation issue - https://github.com/status-im/nimbus-eth2/pull/6132\nBump libp2p and use new gossipsup constructor - https://github.com/status-im/nimbus-eth2/pull/6148\n\n\nnimlibp2p:vac:maintenance\n\nReviewing PRs\n\n\n\nvac:tke: §\n\nwaku:general-incentives\n\nPossibly continuing marketplace discussion with Waku (Martin)\n\n\nwaku:rln-membership:\n\nWorking on the proposal for RLN design (Martin)\n\n\nstatus:SNT-staking\n\nSupporting the SC team ad hoc (Martin)\nDiscussing using the staking contract at the org level (Martin)\n\n\nstatus:L2-deployment\n\nFurther research into airdrop and incentive strategies of existing L2s (Martin)\n\n\nnomos:mixnet-incentives\n\nadjusted pricing function to account for measurement costs (Frederico)\nverified that the modifications of the reward split scheme are correct (Frederico)\n\n\nnomos:cryptarchia-wealth-concentration-estimated-stake\n\nreviewed blog posts (Frederico)\n\n\ncodex:cdx\n\nreviewed latest marketplace proposal (Fred\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nDelayed simulations.\nFinished plotter module tests ready to review (https://github.com/vacp2p/10ksim/pull/19)\nFinished data class, related PR already merged (https://github.com/vacp2p/10ksim/pull/16)\nImprovements for scrapping, related and merged PRs (https://github.com/vacp2p/10ksim/pull/17 and https://github.com/vacp2p/10ksim/pull/18)\nInvestigate attacknet (https://twitter.com/ethPandaOps/status/1769773689979974006)\n\n\neng-10ktool:vac:bandwidth-test\n\nMany many fixes to get Kubernetes with OpenvSwitch + offloading + VMs working\n\nReinstalled 3 nodes with new Debian + Proxmox flavour\nInstalled Mellanox OFED drivers\nExperimented with VirtIO network, managed to eventually get SR-IOV and Virtual Functions working\n\n\nWaku - Benchmarked 1-worker (one worker as one eighth of a 64 core node) cluster\n\nIndications are we can scale to ~14k nodes if scaling is linear, vs CPU usage observed on 1-worker\nHad 243 Waku nodes, including publishing, running on the worker or 1/8th node with headroom to spare\nNetwork offloading appears to about 2x as efficient CPU wise when running Waku\n\n\nFurther fixes for offloading setup once SR-IOV was working\nWaku - Reinstalled 24 workers, then wiped them all and reinstalled 8 of them :(\nDiagnosed incredibly complicated packet loss issues (which turned out to be caused by cloned VMs - note to self - clean up /etc/machine-id next time!)\nWaku - Benchmarked 8-worker cluster (1 physical 64-core), scaled to 1200 nodes, hit major issue with Calico\n\nDocumented here - https://github.com/projectcalico/calico/issues/8676\n\n\nAdded caching to Harbor, further investigated removing Harbor rate limits\nDiscovered that adding multiple jobservice workers to Harbor makes rate limits higher\n\nDeployed 6 jobservice workers in Harbor\n\n\nRemoved Vaxis and Nia from Kubernetes to help with CPU accounting since they host worker VMs\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nSharding interop tests(@Florin)\n\nAdded around 70 new tests so far\n\n\nIssues found:\n\nnode crashes when there are many flags to the docker start command(@Florin)\nnode can be started on multiple clusters(@Florin)\nall REST API calls return 200 with empty response(@Florin)\n\n\nSharding tests update(@Roman)\nClosed issue: data race occurs when publishing to unsubscribed pubSubTopic(@Roman)\n\n\nwaku:test-automation-go-waku\n\nMerged Discv5 PR(@Roman)\nClosed issue: race condition while setting boot nodes for Discv5(@Roman)\n\n\nwaku:test-automation-nwaku\n\nPeer & Communication Management(@Alex)\n\nContinue implementing tests\nFound a couple weird behaviours\n\n\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nFinish the examination DCGKA ref implementation repo\nStarted to write a report about the examination of vector clocks used in DCGKA ref implementation\nChecked that there is the motivation why we chose DCGKA in rfc\n\n\nzerokit:vac:maintenance\n\ngithub removed semaphore commit we used, was fixing CI issue\n\n\n\nvac:sc:: §\nvac:rfc: §\n\n\n\nvac:rfc-process-update\n\nWorked on workflow to sync rfc website - https://github.com/vacp2p/rfc-index/pull/29\nAdded some format changes to eth-secpm-dec - https://github.com/vacp2p/rfc-index/pull/28\nRfc-website is ready - https://github.com/vacp2p/rfc-website/tree/mas\n\n\n\n\n\nvac:dr: §\n\nunstructured-p2p-improvements-survey\n\nLooked into different aspects of libp2p specifications (including gossipsub versions and corresponding discussions). Also looked into the corresponding nim-libp2p works.\nFollowed discussions/PRs on libp2p specs and libp2p implementations\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nRefined the State Separation PDAGs doc and add changes together with Ugur (Moudy + Ugur)\nWorked on gathering important components for state separation (Moudy)\nResearched and identified accumulators/nullifiers to integrate (Moudy)\nDiscussed monitoring with Moudy, and continued with monitoring (Marvin + Moudy)\nDiscussed with Moudy about PDAG report and next version of proposal on state-separation (Ugur + Moudy)\nStarted to write a draft of the next version of proposal on state-separation (Ugur)\nRead about mutator set including Merkle Mountain Range and Bloom filters (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\ncheck out Sirius docs (Rostyslav)\nstarted writing LatticeFold writeup (Rostyslav)\nWork on write up for Mangrove (Marvin)\n\n\nproofsystems:vac:benchmarks\n\nKept working on the paper since new findings are arising (i.e. Nova Scotia not using Groth16) (Moudy)\nConducted server testing (Rostyslav)\n\n\n"},"vac/updates/2024-04-08":{"title":"2024-04-08 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/04/08 §\ngeneral §\n\nLogos offsite Athens: many Vac CCs are attending\n\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nMerge UPD https://github.com/status-im/nim-webrtc/pull/8\nRework Stun https://github.com/status-im/nim-webrtc/pull/9\n\nMandatory for browser to browser\n\n\n\n\nnimlibp2p:vac:maintenance\n\nFind and fix a (nasty) bug in both valueOr/withValue templates\n\nPR: https://github.com/vacp2p/nim-libp2p/pull/1079\n\n\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nfix: remove explicit param from GossipSubParams constructor - https://github.com/vacp2p/nim-libp2p/pull/1080\nReviewing PRs\nWorking on using gossipsub score to penalize peers when their non-prio queue reaches the limit. No PR yet, only local tests.\n\n\n\nvac:tke: §\n\nadmin/misc\n\ntravelled to All-hands in Athens (Frederico, Martin)\n\n\nnomos:mixnet-incentives\n\nunderstodd the parameter that controls the loss of competitiveness experienced by a Sybil attacker (Frederico)\n\n\ncodex:cdx\n\nreviewed materials about Codex in view of next week’s offsite (Frederico)\nReview open questions and provide input (Martin)\n\n\nwaku:general-incentives\n\nLooking at Swarm city\n\n\nwaku:rln-membership:\n\nPresent and collect feedback on the RLN Proposal (draft, Martin)\nStart a structured discussion and follow-ups based on this document in Athens (Martin)\n\n\nstatus:SNT-staking\n\nMeeting the SC team in Athens (Frederico, Martin)\nFollowing-up on the org fundraising talks with Carl in Athens (Martin)\n\n\nstatus:L2-deployment\n\nFurther brainstorming for product differentiation in Athens (Frederico, Martin)\n\n\n\nvac:dst: §\n\neng-10ktool:vac:bandwidth-test\n\nRestart simulations (delayed)\nImprove scrapping tests (https://github.com/vacp2p/10ksim/pull/20https://github.com/vacp2p/10ksim/pull/20)\nAdd option to download node logs (https://github.com/vacp2p/10ksim/pull/21 after 20 is merged)\nFinished rebuild of Kubernetes nodes, optimisations\nRan various simulations at a few different scales\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nMerged sharding tests PR part 1(@Florin)\nSharding tests update PR 1060 - in progress(@Roman)\nIssue found: subscription to many static sharding topics hangs(@Roman)\n\n\nwaku:interop-testing\n\nFix broken allure history links(@Florin)\nLight push tests in progress(@Florin)\nIssues found:(@Florin)\n\nstrange errors when light pushing messages with payload >= 300 kb for both nwaku and go-waku\nlightpush on non subscribed pubsub topic hangs\nlightpush fails with Failed to request a message push: dial_failure after the peer node restarts\nmissing RequestId field error when lightpush has unexpected payload of content topic\n\n\n\n\nwaku:test-automation-nwaku:\n\nPeer & Conn Mgmt testing. Almost finished, need to sort out some issues in a meeting with some waku person.(@Alex)\n\n\n\nvac:acz: §\n\nsecure-channels:waku:ethereum-chat\n\nUpdate the report about vector clocks in reference impplementation of DCGKA.\n\n\nzerokit:vac:maintenance\n\ncontinued fixing semaphore related issues\n\n\n\nvac:sc:: §\n\nadmin/misc\n\noffsite\n\n\n\nvac:rfc: §\n\nadmin/misc\n\noffsite\n\n\n\nvac:dr: §\n\ngossipsub-improvements-paper\n\nLooked into different program control aspects in nim (semaphores, Futures, Queues, Async framework), needed for message staggering\nLooked into the possible changes required for message staggering (still a work in process)\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nWorked on the draft of the State Separation PDAGs doc (Moudy)\nContinued research about accumulators and mutator sets (Moudy)\nMet with Ugur for PDAGs + Accumulators (Moudy)\nDrafted list of components (Moudy)\nFinish the first draft of Mutator set in Notion (Ugur)\nChecked the page about MMRs and Mutator set that Moudy notion page (Moudy + Ugur)\nStarted to write reports about the candidates of nullifiers for our state separation (Ugur)\nUpdate the all-in-one document for state separation and share with Moudy (Ugur + Moudy)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nchecked out Sirius code (Rostyslav)\ncontinue writing LatticeFold writeup (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\ncontinued working on Mangrove (Marvin)\ncontinued conducting server testing, got prelimenary results (Rostysla\n\n\n"},"vac/updates/2024-04-15":{"title":"2024-04-15 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/04/15 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nHuge rework on Stun protocol https://github.com/status-im/nim-webrtc/pull/9 (ready for review)\nRework Dtls protocol to take account of the Stun rework https://github.com/status-im/nim-webrtc/pull/10 (ready for review aswell)\n\n\n\nvac:tke: §\n\nadmin/misc\n\nattended the All-hands presentations and discussions (Frederico, Martin)\ntraveled back from Athens (Frederico, Martin)\n\n\nnomos:mixnet-incentives\n\npresented the current state of the mixnet incentives to the Nomos team (Frederico)\n\n\ncodex:cdx\n\ndiscussed the missing parts of the Tokenomics model in the Codex offsite (Frederico)\ndiscussed Codex L2 use case with Cyprian (Frederico)\ndiscussed Codex tokenomics with Finance team (Frederico)\nReview open questions and provide input ahead of the Codex offsite (Martin)\n\n\nstatus:SNT-staking\n\ndiscussed staking and aggregation with the SC team (Frederico, Martin)\n\n\nwaku:general-incentives\n\nAnalyzing the new ideas discovered in Athens - RLN ID and utilization of the payment mechanism for the RLN purchase (Martin)\n\n\nwaku:rln-membership:\n\nfollow-ups based on the discussion in Athens (Martin)\n\n\nstatus:L2-deployment\n\nMeeting and brainstorming with Cyprian in Athens (Martin, Frederico)\n\n\n\nvac:dst: §\n\nadmin/misc\n\nVarious contributors @ Athens for Logos Offsite\nCollaborations with Codex\n\nnode designs (incl. pricing)\ncollateral scaling mechanisms (“dynamic collateral”)\n\n\nTalked with Nomos about testing mixnet and graph visualisation\nDiscussed Nomos testing and DST service needs\nMet with Yiannis from Probe Lab\n\nExploring areas to collab; focus was on partnerships, what areas DST can help with, “low/zero cost” knowledge exchange\n\n\nTeam: Discussed future directions, next few weeks to months worth of work\n\n\neng-10ktool:vac:bandwidth-test\n\nInvestiage the usage of kustomize for deployment\nUpdate scrapper test and utils merged https://github.com/vacp2p/10ksim/pull/20 Pod log downloader to be merged now https://github.com/vacp2p/10ksim/pull/21\nMultiple attempted runs towards 10K\n\nFirst successful 10K run 2024-04-15 10:30am in Athens at 10,847 nodes\n\n\nImprovements:\n\nenable NUMA support in VMs for better scale\nall nodes now boot automatically as lab comes up\nImplemented critical improvements to large scale simulations per Calico team.\n\n\nMeetings with Waku team\n\nTalked about next deliverables and checked their paper about Waku\nDiscussed Nwaku vs go-waku CPU usage and scalability, needs; potential waku network sharding strategy (dynamic sharding); current Waku testing results, future needs\nDiscussed need for Waku tracing - need to be able to output a simple Received message ID: messageID message from Waku to stdout.Met with Ivan (Waku)\n\n\n\n\n:vac:lab\n\nScaling improvements, added 3 hosts, improved power distribution, migrated all hosts to OVS, Codex preparation work, NVMe install + debug.\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nLight push tests merged(@Florin)\nStore draft pr(@Florin)\nIssues found:\n\ncontentTopic naming not consistent in the store response where is’s content_topic(@Florin)\nnode doesn’t store messages if relay is disabled(@Florin)\nfailed to negotiate protocol: protocols not supported: [/vac/waku/store/2.0.0-beta4] when the peer node has store disabled(@Florin)\n\n\n\n\nwaku:test-automation-sharding\n\nSharding tests update(@Roman)\nClosed subscription to many static sharding topics hangs(@Roman)\nIssue found: message won’t be sent over from node1 to node2 with sharded topic subscription(@Roman)\n\n\nwaku:maintenance-nwaku\n\nAdd ARM64 Docker support for Linux/MacOS(@Roman)\n\n\nwaku:test-automation-rln\n\nRLN relay tests draft PR(@Roman)\n\n\nadmin/misc\n\nOffsite(@Alex)\n\n\n\nvac:acz: §\nLast week:\n\nzerokit:vac:zerokit-v0.5\n\nplanning issue for zerokit v0.5.0\nwip: remove tree height 32 resources\n\n\nrlnp2p:waku:rln-relay-enhancements\n\nbrought down tree sync time by parallelizing rpc calls\n\n\nsecure-channels:waku:ethereum-chat\n\nPlanning for Secure channels with Ethereum\nResearch on possible solutions to metadata management in DCGKA (use of UPKE and stealth addresses)\nIdea: zk-MLS\n\n\nadmin/misc\n\nDiscussions at Logos All hands offsite with various projects on how the ACZ team plugs into their research & engineering\nFirst Vac ACZ offsite, meeting notes. Planning for Secure channels with Ethereum done.\nmost CCs ooo after travel from All hands offsit\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nLogos All-Hands Offsite\n\nSee notes: https://notes.status.im/et-wl6KFTYW4bjtKUpM5tw?view#SC1\n\n\nSwap Aggregator Research\n\nAirswap Research notes\n\nhttps://notes.status.im/fJ2YoaiBS4qd94RtK2zHJA?view\n\n\n\n\n\n\n\nvac:rfc: §\n\nwaku:core-rfc-updates\n\nWorked on rln relay and waku executables for waku-rln-relay, will be creating a new pr next week\n\n\nmisc\n\nreviewed rfc-website, found new problems and open web development tickets with acid-in\n\n\nnimlibp2p:vac:gossipsub-stagger-send\n\nfeat: behaviour penalty when non-priority queue reaches maxNumElementsInNonPriorityQueue https://github.com/vacp2p/nim-libp2p/pull/1083\n\n\nnimlibp2p:vac:maintenance\n\nupdate libp2p branch when unstable changes https://github.com/status-im/nimbus-eth2/pull/6202\nOpenend issue peer doesn’t respect backingOff https://github.com/vacp2p/nim-libp2p/issues/1084\nCoding interview\nReviewing PRs\n\n\n\nvac:dr: §\n\nunstructured-p2p-improvements-survey\n\nLooked into the gossip issue regarding large number of small messages in farcaster network\nLooked into different gossipsub specifications/discussions etc.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on message forwarding from priority/non-priority queues for possible performance improvements and message staggering. Still a work in progress. Expected to complete in this weak.\n\n\n\nvac:nes: §\n\nadmin/misc\n\nMoudy + Marvin all week @ All hands offsite\nUgur 2 days off + 1 day @ACZ offsite\n\n\nstate-separation:vac:state-separation-doc\n\nCreated a draft about the possible usages of Mutator sets in our nullifier systems in notion (Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nchecked out Sirius code (Rostyslav)\ncontinue writing LatticeFold writeup (Rostyslav)\n\n\n"},"vac/updates/2024-04-22":{"title":"2024-04-22 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/04/22 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nreview stun pr\nAddress comments on STUN protocol\nResearch on ICE protocol\nStart implementing ICE protocol\n\n\nnimlibp2p:vac:maintenance\n\nuse a mock rng in tests https://github.com/vacp2p/nim-libp2p/pull/1085\ndebug ping interop test\n\n\n\nvac:tke: §\n\ncodex:cdx\n\nreviewed Codex priority list and document outcomes (Frederico)\nread the whitepaper (Frederico)\ncaught up with Wings’ proposal for collateral incentive model (Frederico)\nReviewing Codex offsite outcomes and reading the whitepaper (Martin)\n\n\nnomos:mixnet-incentives\n\ncaught up with the current state with Marcin (Frederico)\nconcluded analysis of parameter to control competitiveness loss of sybil attackers\n\n\nstatus:L2-deployment\n\njoined discussions with Cyp (Frederico)\nStarting work on L2 profiling and attempting to narrow down key narratives/features (Martin)\n\n\nwaku:general-incentives\n\nReviewing protocol design decisions and changes made in Athens, mapping out implications for the incentive design (Martin)\n\n\nwaku:rln-membership:\n\nReviewing the RLN decisions and changes made in Athens, mapping out implications for the RLN design (Martin)\n\n\nstatus:SNT-staking\n\nResearch into swap feature in cooperation with the SC team (Martin)\n\n\n\nvac:dst: §\n\nadmin/misc\n\nMeetings with Codex, prep for Codex testnet\n\n\neng-10ktool:vac:bandwidth-test\n\nBegan implementing message reliability measurement using message ID logs\n\nMessage tracking code\nVisualisation code\n\n\nRan several simulation attempts, ran into network issues believed related to the power event. Found several things misbehaving\nRead Waku paper\nControl plane improvements, Kubernetes and Ceph cleanup, replacement parts for control plane\nNetwork weirdness, still sorting\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nMerged store tests part 1(@Florin)\nUpdate tests based on fixes(@Florin)\nIssue reopened(@Florin)\n\n\nwaku:test-automation-sharding\n\nGo-waku sharding tests update(@Roman)\nNim sharding tests(@Alex)\nIssue found: message won’t be sent over from node1 to node2 with sharded topic subscription - would need to be separated from PR1060(@Roman)\n\n\nwaku:test-automation-rln\n\nRLN relay tests(@Roman)\nIssue found: RLN in on-chain dynamic mode not working\n\n\nwaku:test-automation-nwaku\n\nPeer & Connection Management tests(@Alex)\nIssues found:(@Alex)\n\nPeerInfo instance affects listed protocols\nSome PeerStore metadata is not filled in\nPeer Reconnection not working?\nENR shouldn’t be used for pruning\n\n\n\n\nadmin/misc\n\nStarted to read the nomos docs and begin to familiarize myself with nomos(@Florin)\nTried to build and run nomos node and nomos specs(@Florin)\nConducted interview with Sandarv on Thursday(@Roman)\nOOO one day (@Florin)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancements\n\nresultify and clean up rln-relay code\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nBlog post/RFC on Light RLN verifiers\n\n\nzerokit:vac:zerokit-v0.5\n\nQoL traits to the Hasher assoc.Type\nRemoved tree height 32 from rln\n\n\nsecure-channels:waku:ethereum-chat\n\nGeneration of flow diagrams for several MLS procedures\nResearch on improving the privacy in DCGKA\n\n\nadmin/misc\n\nreduced availability since one CC is off (Ugur)\n\n\n\nvac:sc:: §\nvac:rfc: §\n\nwaku:core-rfc-updates\n\ncreated rln-relay update pr, opened discussion for more to stable - https://github.com/vacp2p/rfc-index/pull/32\nmerged WAKU-METADATA move to draft - https://github.com/vacp2p/rfc-index/pull/6\n\n\nmisc\n\nfound new problems with rfc-website, in contact Jhino to fix\nstarted reading Codex spec marketplace - https://github.com/codex-storage/codex-research/blob/master/design/marketplace.md\n\n\n\nvac:dr: §\n\nunstructured-p2p-improvements-survey\n\nStudied/investigated different techniques/works targetted on perfromance improvements against message sizes and counts\nLooked for funding opportunities in the Ethereum eco-system that align with our research directions\n\n\nzk:codex:storage-proofs-open-problems-review\n\nDiscussed with Codex their specific needs in terms of documents, as well as received their list of papers and three problems in full detail. Discord thread and List\n\n\nadmin/misc\n\nWork on notes concerning BloomFilter, MMR, and Field Merkle.\nBegan working on a document on tangibles\n\n\nvac:dr:anon:vac:waku-anonymity-analysis\n\nRead Waku Adversarial Models and Tor Push.\nStarted documenting Waku Anonymity Analysis - WiP.\n\n\n\nvac:nes: §\n\nadmin/misc\n\nUgur from 15 to 23 April\nMarvin from 15 to 17 April\n\n\nstate-separation:vac:state-separation-doc\n\nWorked on defining and identifying State Separation Components (Moudy)\nRead Ugur’s notes on Mutators 1 and 2 (Marvin)\nWork on notes for MMR, Bloom Filters (potentially more useful for DR) (Marvin)\n\n\nproofsystems:vac:benchmarks\n\nAlmost finished the draft of the Benchmarks paper (still some details to add) (Moudy)\nconducted conducting server testing and got 6 PRs merged (Rostyslav)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nStarted looking at existing ZkVms in order to use them to add privacy on top (Moudy)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nFinished writing LatticeFold writeup\n\n\n"},"vac/updates/2024-04-29":{"title":"2024-04-29 Vac weekly","links":["0x520434D97e5eeD39a1F44C1f41A8024cB6138772"],"tags":["vac-updates"],"content":"Vac 2024/04/29 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nYet another rework on Stun protocol: https://github.com/status-im/nim-webrtc/pull/9\n\nBetter error management\nImplement a Lite (and server sided) version of the ICE protocol.\nrewrite tests & stunMessageHandler\nImplement BindingRequest\n\n\n\n\nnimlibp2p:vac:maintenance\n\ndebug ping interop test - https://github.com/vacp2p/nim-libp2p/pull/1086\nopened issue about potential js-libp2p bug - https://github.com/libp2p/js-libp2p/issues/2505\nlibp2p dev process\n\n\n\nvac:tke: §\n\nadmin/misc\n\nprepared an onboarding doc for new hire (Frederico)\nupdated TKE landing page (Frederico)\n\n\ncodex:cdx\n\nupdated the TKE litepaper with offsite discussion and whitepaper (Frederico)\nReviewing Codex offsite outcomes and reading the whitepaper (Martin)\n\n\nnomos:mixnet-incentives\n\nread the new mixing gadget proposal (Frederico)\nadapted the Mixnet incentivization work with new proposal (Frederico)\n\n\nstatus:L2-deployment\n\njoined discussions with Cyp (Frederico)\n\n\nwaku:general-incentives\n\nReviewing protocol design decisions and changes made in Athens, mapping out implications for the incentive design (Martin)\n\n\nwaku:rln-membership:\n\nReviewing the RLN decisions and changes made in Athens, mapping out implications for the RLN design (Martin)\n\n\nstatus:SNT-staking\n\nResearch into swap feature in cooperation with the SC team (Martin)\n\n\nstatus:L2-deployment\n\nStarting work on L2 profiling and attempting to narrow down key narratives/features (Martin)\n\n\n\nvac:dst: §\n\nadmin/misc\n\nDeployed 250TB(x2) volume for Codex, created VacLab + Kubernetes access for Codex staff\n\n\neng-10ktool:vac:bandwidth-test\n\nFirst version of message tracking + data dumping done\nRan various simulations - fixed issues blocking sims, fixed issue with new bootstrap sim\n\nFound weird Yamux behaviour still exists\nNo bootstrap bias found\n\n\nKubernetes cleanup, instability fixes, performance fixes\nDeployed iBGP between all Kubernetes hosts and migrated LoadBalancers into MetalLB BGP\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nRefactoring PR that adds common steps and removes flakyness(@Florin)\nReviewed and commented on Roman’s PR(@Florin)\nReopened: contentTopic naming not consistent in the store response bug(@Florin)\n\n\nwaku:maintenance-js-waku\n\nuse nwaku:v0.27.0 and adjust tests for it(@Florin)\nunskip fixed test(@Florin)\n\n\nnomos:test-automation-cryptarchia\n\nMeeting with Nomos devs(@Florin)\nRead more of Nomos specs and start working at a test plan(@Florin)\n\n\nwaku:test-automation-sharding\n\nSharding tests update(@Roman)\nReviewed PR(@Alex)\nStore Issue(@Alex)\n\n\nwaku:test-automation-nwaku\n\nPeer & Connection Management Reviewed PR(@Alex)\n\n\nwaku:test-automation-rln\n\nRLN relay tests in progress(@Roman)\nbug: RLN in on-chain dynamic mode not working closed(@Roman)\nBegin implementing tests. Draft PR(@Alex)\n\n\nadmin/misc\n\nInterviewing and reviewing code challenges for QA candidates(@Florin and @Roman)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancements\n\nimproved ci for rln-relay enabled images\ndiscussed with nwaku team and increased recovery time for rln-relay failure to 1 minute\nimproved error handling/exception raising\nLazyIMT approach partially downstreamed to waku-rln-contract and deployed on cardona zkevm-testnet\nenhanced rln-db-inspector capabilities by detecting empty leaves\nresultify rln-relay 1/n reviews addressed and merged\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\npresented rln: zero to hero to nwaku+chatsdk team @ status all hands, explained all versions of rln and their trade-offs\nupdates to blog post/RFC on Light RLN verifiers\n\n\nsecure-channels:waku:ethereum-chat\n\nUpdated the DCGKA’s Notion with aspects concerning privacy\nUpdated flow diagrams for MLS\nStart working on flow diagrams for the DCGKA.\nResearch on the best approach to UPKE.\n\n\nadmin/misc\n\nDaniel + Aaryamann @ status all hands: agenda\npresented stealth address scheme over Waku to waku + status team\nreduced availability for a few CCs\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nSwap Aggregator Research\n\nResearched CoW Protocol and Cow Swap\n\nNotes (WIP): https://notes.status.im/5q0HiAKORf6V1fQgong31Q?both\n\n\nResearched Metamask Swap\n\nNotes on the Metamask Swap research https://notes.status.im/5yw7WvqRQqaREdJ0hbyWoQ?view\n\n\n\n\nZodiac Modules\n\nReviewed code of SAFE and zodiac modules to get a better understanding of the system\n\nhttps://github.com/gnosisguild/zodiac-modifier-roles/tree/main\n\n\n\n\n\n\n\nvac:rfc: §\n\nmisc\n\nCreated an open issue to use rfc-website repo, but some problems are still being worked on. - https://github.com/status-im/infra-misc/issues/271\nRead Nomos docs on Notion, suggesting a raw rfc for Block format for base layer. Opened disussion if good for first rfc.\nRead codex docs in codex-research repo. Started Codex Marketplace raw rfc, not complete, should be able to complete a draft next week and try to get feedback from Codex - https://github.com/vacp2p/rfc-index/blob/codex-marketplace/codex/marketplace.md\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nCompleted staggered message sending mechanism, for large messages (making some fixes: getting LPStreamClosedError in some runs)\nWorked on resetting the build environment for shadow. chronos/chronicles upgrade was causing some compilation errors\n\n\nzk:codex:storage-proofs-open-problems-review\n\nBegan reading WARPfold, Beyond Circuit\n\n\nvac:dr:anon:vac:waku-anonymity-analysis\n\nContinued working on Waku Anonymity Analysis - WiP.\nRead about libp2p and GossipSub and started documenting - WiP\nLooked into options that could lower the latency for Tor Push\n\nOther anonymity networks and mixnet options such as I2P, Loopix, etc.\nSome P2P options as well (but they are not as widely used as Tor)\nlooking into Dandellion++ and its Comparison to Tor Push.\n\n\n\n\n\nvac:nes: §\n\nadmin/misc\n\nUgur ooo from 15 to 23 April\n\n\nstate-separation:vac:state-separation-doc\n\nConducted some research on what is needed to have all the essential components of the state separation (transaction types, cryptography behind it, trees, filters, etc) (Moudy)\nWorked on monitoring document (Marvin)\nStarted to work on trees in state-separation (Ugur)\nCrated a doc about privacy in executions note (Ugur)\n\n\nproofsystems:vac:benchmarks\n\nDecided to rewrite the benchmarks paper as a detailed blogpost (need to conduct and update some pieces of research) (Moudy)\nInvestigate Halo2 high iterations bug (Rostyslav)\nPrepared paragraph on Halo2 bug (Rostyslav)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nHad a high level look at existing ZkVms (Moudy)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStarted reading about Greco zk proofs (Rostyslav)\nCheck out Jolt implementation (Rostyslav)\n\n\n"},"vac/updates/2024-05-06":{"title":"2024-05-06 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/05/06 §\nvac:p2p: §\n\nadmin/misc\n\nCCs ooo\n\n\nnimlibp2p:vac:webrtc-transport\n\nAddress comments on Stun protocol https://github.com/status-im/nim-webrtc/pull/9\n\n\n\nvac:tke: §\n\nadmin/misc\n\nonboarded our new team member (Frederico, Martin)\nGetting familiar with protocols (Juan)\nFew introductory meetings (Juan)\n\n\ncodex:cdx\n\nreviewed and complemented the TKE part of Codex litepaper (Frederico)\nReviewing Frederico’s changes to the litepaper (Martin)\nProvided some feedback into Codex (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nreviewed and restructured of the previous work (Frederico)\n\n\nwaku:general-incentives\n\nFollowing internal debates and docs mapping progress from Athens (Martin)\n\n\nstatus:SNT-staking\n\nResearch into swap feature in cooperation with the SC team, chats with potential partners (Martin)\n\n\nstatus:L2-deployment\n\nFurther work on L2 economic model, focusing on fundametal questions and constraints (Martin)\n\n\n\nvac:dst: §\n\nadmin/misc\n\nMeetings to discuss milestones\nFinished deploying CubeFS for the Codex team (for accessing storage)\n\n\neng-10ktool:vac:bandwidth-test\n\nAdjusted Kubernetes workers to the new network structure\nAlberto ran into deployment issues which we solved\nRan two attempts at a 10K Waku sim and a 2k sim @ 10 msg/sec\nRedo simulations with versions 0.26 and 0.27\n\nUse waku 0.27 and ensure yamux still works ok\n\nDoesn’t work ok, neither with 0.26 and 0.27\n\nInitially delayed by lab issues, solved by end of week\n\n\n\n\nExtract more information regarding discv5 (mem/cpu)\n\nNot finished before of lab issues with Prometheus monitoring\n\n\n\n\nRefactored message tracking code\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nAdd mandatory shard flag(@Florin)\nIssue found(@Florin)\nReopened again(@Florin)\n\n\nnomos:test-automation-cryptarchia\n\nTest plan(@Florin)\n\n\nwaku:test-automation-sharding\n\nSharding tests update. PR 1060 - merged(@Roman)\nbug: message won’t be sent over from node1 to node2 with sharded topic subscription. Issue 1086 - in progress(@Roman)\n\n\nwaku:test-automation-rln\n\nRLN relay tests. PR 30 - in progress(@Roman)\nbug: node won’t start with RLN in on-chain dynamic mode. Issue 2662 - open(@Roman)\n\n\nwaku:test-automation-sharding\n\nUpdated Sharding PR with comments(@Alex)\n\n\nwaku:test-automation-rln\n\nVarious testing code improvements and utilities(@Alex)\nFinally unblocked onchain “invalid contract” tests(@Alex)\n\n\nadmin/misc\n\n2CCs OOO Wednesday -> Friday\n1CC OOO on Monday/Wednesday\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancements\n\ninvestigated and testing missed leaves solution\nfix waku keystore segfault on incorrect appInfo\nfixed logging for debug logs in nwaku\nintegrated lazyIMT into rln-v2 for gas estimates for waku research\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nmerged in rln light verifiers rlog, cross-posted to vac forum pending crosspost to ethresearch.\n\n\nzerokit:vac:maintenance\n\naddressed some issues in installing dependencies\nremoved rln-wasm from the benchmarks (there are none)\n\n\nzerokit:vac:zerokit-v0.5\n\ncreated pr add ark-zkey support\nstarted to work on tests and benches review regarding release v0.5\nremove tree_height_32 merged\n\n\nsecure-channels:waku:ethereum-chat\n\nWork on the role of the AS in the RFC architecture.\nWork on the role of the SIWE approach.\nExamine the reference implementation of DCGKA and updated distributed group membership part of the notion note.\nStudy on the SIWE-like approach from the updated RFC as related to issue #4.\n\n\nadmin/misc\n\nsynced with pse and waku research team, pse will start work on the next version of RLN, using the same primitives from semaphore v4. We have disagreed with their approach since it adds unnecessary complexity. we may use a fork of it if they continue making it like semaphore v4.\nupdated pending milestones on roadmap\n1 CC onboarding\n1 CC ooo on May day\n\n\n\nvac:sc:: §\n\nstatus:swap-aggregator\n\nfinished research on metamask swap adapters\nContinued research on CoW Protocol\nContinued working on notes and slides\n1inch swap router research\n\n\nvac:maintenance/misc\n\nSmart contract security research\n\nParticularly inflation attacks\n\n\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nCreated pr for Codex marketplace raw RFC, got feedback - https://github.com/vacp2p/rfc-index/pull/36\nHad a sync meeting with Codex marketplace team on Thursday, for questions\n\n\nnomos:specs-init\n\nStarted Nomos Data Availablity RFC, not complete, should complete next week for feedback\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on staggered message sending, draft PR is ready for review. Still need to add adaptive behavior in terms of wait-time, number of simultaneous-transmissions (WIP).\nCompleted tests from the above PR. Analyzing results (Looking for rationale for one anamoly: idontwant message is not showing good results in a network with dissimilar bandwidth/latencies)\n\n\nzk:codex:zk-consulting\n\nContinued conversation with Codex team on feedback.\nContinued work on notes for Beyond Circuit and WarpFold.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nDiscussed Waku Anonymity Analysis and completed documenting.\nStarted documenting initial discussions on designing a base Anonymity Layer - WiP.\nRead Tor Push and Dandellion++ solutions - WiP\nLooked into Nym mixnet - WiP.\n\n\nmisc\n\nBegan rough drafts on blogs; Verkle Trees\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc\n\nWorked on State Separation Components and discussed with Ugur on how to proceed with the first part of the architecture (Moudy + Ugur)\nExamine the needs for state separation in terms of trees (Ugur)\nStarted to write a prototype about the overview of an end-to-end execution (Ugur + Moudy)\n\n\nproofsystems:vac:benchmarks\n\nHad a slight look on what is going regarding other benchmarks done by others (Moudy)\nContinued server testing (Rostyslav)\nOpened up aggregator issue (Rostyslav)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nHad a high level look at existing ZkVms (Moudy)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nContinued reading about Greco zk proofs (Rostyslav)\nStarted checking out Ligetron (Rostyslav)\n\n\n"},"vac/updates/2024-05-13":{"title":"2024-05-13 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/05/13 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nfix(CI): rename branch from unstable to master in bumper workflow https://github.com/vacp2p/nim-libp2p/pull/1097\nfix(yamux): set EoF when remote peer half closes the stream in yamux https://github.com/vacp2p/nim-libp2p/pull/1086\nreviewing PRs\n\n\n\nvac:tke: §\n\ncodex:cdx\n\nreviewed and extended Codex’ Value Capture Mechanisms (Frederico)\nreviewed and discussed the new Slot Reservation proposal with Codex team (Frederico)\nReviewed, commented, and discussed the tokenomics part of the whitepaper (Juan)\nRead on slot reservation proposals (Juan)\nProvided feedback on codex’s market validation respose document (Juan)\nCatching up on the discussion around marketplace mechanisms (Martin)\n\n\nstatus:L2-Deployment\n\nFurther work on L2 economic model, focusing on fundametal questions and constraints (Martin)\nStarted working towards a swap aggregator model (Juan)\n\n\nwaku:general-incentives\n\nReviewing protocols mentioned by Franck (Martin)\nIdentifying key actionable items (Martin)\n\n\nstatus:SNT-staking\n\nSync with SC team on the swap feature, chats with potential partners (Martin)\nIdentifying implications of L2 economic model on SNT staking and its current design (Mart\n\n\n\nvac:dst: §\n\nadmin:misc\n\nMeetings re: milestones, ad hoc discussions\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nBlocked due to Kubernetes issues in lab\nIssues resolved now, deployments resume on Tuesday evening (14th/15th of May)\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nFirst 10k simulation with metrics\n\nDeployment - https://asciinema.org/a/ZzyqtVrcJW6cVwTI0CJDsBWC5\nk9s - https://asciinema.org/a/4gmnHckrQgYgtwx85ItixRlY0\n\n\nDeployed new Ruby cluster for better DNS + control plane stability\n\nManages 10K simulations - reliably!\n-API becomes unstable at that scale, which is solvable\n\n\n\n\nvac:dst:tooling:vac:visualiser-tool:\n\nPR to be merged regarding code structure and first waku message tracking functionality: PR\n\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nDebugging issues with distributed storage system used to support Codex nodes\nSetup access for Codex team\n\n\nvac:dst:deployment-and-analysis:nomos:mixnet\n\nContinue to follow up with Nomos team\n\n\n\nvac:qa: §\n\nwaku:test-automation-sharding\n\nbug: message won’t be sent over from node1 to node2 with sharded topic subscription - some new info from debbuging(@Roman)\n\n\nwaku:test-automation-rln\n\nRLN relay tests merged(@Roman)\nbug: node won’t start with RLN in on-chain dynamic mode\nIssue 2662 - open - retested with PR 2664 without better outcome(@Roman)\nNode readiness with /health check(@Roman)\nSkip health check for go-waku(@Roman)\nContinue testing for RLN, Call with Aaryamann. Made some advancements(@Alex)\n\n\nadmin/misc\n\nOOO All week(@Florin)\nOOO From Monday until Wednesday(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rln-relay-enhancements\n\nuse arkzkey variant of zerokit libs in nwaku\nwindow of roots should be accepted as valid health status of rln-relay\ndedicated timebox to help QA setup rln-relay\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\ndraft of rln-v3 rlog\n\n\nzerokit:vac:zerokit-v0.5\n\ninclude arkzkey libs in nightly releases\nmerged PR add ark-zkey support\npublished zerokit v0.4.4 release with arkzkey support release v0.4.4\nfinished test and benches refactoring chore(rln): tests and benchmarks review\nupdated docs for rln-v2 to include new serde format chore(rln): updating docs\ncreated new task in release v0.5 and merged it fix(rln): Remove resources folder, update missed docs\n\n\nsecure-channels:waku:ethereum-chat\n\nStudy on the necessity of SIWE-like protocol related to issue #4\nCheck ERC-725 and ERC-735 and a KeyManager Repository for some insight instead of SIWE-like authentication systems.\n\n\nadmin/misc\n\nroadmap updated\n\n\n\nvac:sc:: §\n\nstatus:swap-aggregator\n\nprepared presentation on metamask swap\n1 inch aggregator research\nuser privacy on Paraswap integration\nFinished preparing CoW protocol preso\nMet with TKE and StatusChain team to discuss plans\n\nUnfortunately things are still blurry and being brainstormed\n\n\n\n\nvac:maintainance/misc\n\nENS usernames release delay update\nFine-tuned job description for Solidity engineer\nCreated onboarding guide for new hires\n\n\n\nvac:nim: §\n\ntooling:nimble\n\nWorking on passing all tests when SAT on.\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nUpdated CODEX-MARKETPLACE rfc, will ask for second round of feedback next week - https://github.com/vacp2p/rfc-index/pull/36\nStarted node dispersal rfc, will ask for feedback next week\n\n\nnomos:specs-init\n\nStarted data availibility rfc, should be able to complete first draft next week and ask for feedback - https://github.com/vacp2p/rfc-index/blob/nomos-da/nomos/data-availability.md\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nLooked in to previous staggered message sending approach. Require manualy resetting nim/nimble to match the branch dates. The performance evaluation results are available here\nAs no gains are seen, looking for other possible improvements (delayed elimination of peers from queues on receiving idontwants), adapting stagger delays to peer speeds/scores. still a WIP\n\n\nvac:admin\n\nWork on blog drafts for Verkle Trees, KZG, and BloomFilters.\n\n\nzk:codex:zk-consulting\n\nProvided feedback on bkomuves’ notes on Codex tracking proofs.\nBegan report on Groth16 as final compression layer, and current state of pairing-based recursion proof systems.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued working on Anonymity Layer - WiP.\nRead Tor Push and Dandelion++ solutions\n\nStill can’t figure out the actual advantage of using onion encryption.\nIn the pub-sub model, adding delays and/or relaying through an anonymity/mix overlay network should offer the desired level of protection.\nHowever, such an overlay network will be similar to Dandellion++ only.\nStill trying to figure out how to overcome the shortcomings in Dandellion++.\n\n\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-doc-01\n\nSynced on monitoring (Marvin)\n\n\nstate-separation:vac:state-separation-architecture-01\n\nWorked extensively on the architecuture of state separation and made some improvements (Ugur + Moudy)\nFinished the 5-page doc for the framework of the prototype with some charts related to the type of executions (Ugur)\nEnriched the prototype with the details for the first draft (Moudy + Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nContinued reading about Greco zk proofs (Rostyslav)\nFinished checking out Ligetron (Rostyslav)\nWrote a small summary paragraph on LatticeFold (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nStarted the writings and wrapped up some parts to reflect main differences between the major analyzed proof systems (especially regarding proofs agg vs recursion) (Moudy)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nPrepared requirements to look into existing ZkVms and what are the important keys we need to assess (Moudy)\n\n\n"},"vac/updates/2024-05-21":{"title":"2024-05-21 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/05/21 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\ncheck use outside test definition https://github.com/status-im/nim-unittest2/issues/43\nfeat(service): add wildcard address resolver https://github.com/vacp2p/nim-libp2p/pull/1099\n\n\n\nvac:tke: §\n\n`admin“\n\n1.5 CC day off\n\n\ncodex:cdx\n\nread Codex business related docs (Frederico)\nreviewed and extended Codex’ Incentive Mechanisms (Frederico)\nReviewing internal and external materials (Martin)\nCommented on Codex tokenomics and on investor strategy docs (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\ncontinued the restructure of the previous work under a newly defined strategy (Frederico)\n\n\nstatus:L2-deployment\n\ncaught up with the current state (Frederico)\nLooking into further L2 economic models, internal discussions (Martin)\nDiscussion with LiFi team (Juan)\nFinished writeup on swap aggregator (Juan)\n\n\nwaku:general-incentives\n\ncaught up with the current state (Frederico)\nSync with the Waku team and mapping out potential for TKE support after reprioritization (Martin)\nUpdating Waku Tokenomics Notion (Martin)\n\n\nstatus:SNT-staking\n\nChats with potential partners for the swap product; analysis of the industry (Martin)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nRepeated deployments with waku v0.26\n\n1 to 3K nodes, with 1 msg per 1, 5, 10 seconds\n\n\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nRan 10K deployments to test noise levels post-insulation\nContinued work on metrics + DNS stability\n\n\nvac:dst:tooling:vac:visualiser-tool:\n\nFinished implementing the visualization part as a Jupyter notebook\n\nStill remaining: Evaluate how to propperly visualize thousands of nodes\n\n\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nAnalyzed Yamux issue\n\nLooks like keep-alive flag was the root of the cause (at waku level).\n\n\n\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nMigrated Codex VacLab storage to SeaweedFS\nRe-created Codex Kubernetes access\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nstore content topic fix(@Florin)\nstore v3 PR(@Florin)\nworked with SP to translate the store v3 message hashing mechanism from nim to python (@Florin)\ninvestigated with Richard some interop store v3 issues(@Florin)\nupdate lightpush tests with big payloads based on latest nwaku fix(@Florin)\n\n\nwaku:test-automation-sharding\n\nMerge Nwaku PR and closed the milestone(@Alex)\n\n\nwaku:test-automation-nwaku\n\nMerge Peer & Connection Management PR and closed the milestone(@Alex)\n\n\nwaku:test-automation-rln\n\nFinally get node to node onchain test working(@Alex)\nBriefly investigate alternative methods. Didn’t manage to get it working, left for later, worth investigating: Improve developer experience and discard potential bugs.(@Alex)\n\n\nnomos:test-automation-cryptarchia\n\nRead Nomos documentation and related papers(@Alex)\n\n\nadmin/misc\n\nCatch up with things that I missed while on vacation(@Florin)\nOOO All week(@Roman)\n\n\n\nvac:acz: §\n\nsecure-channels:waku:fd-design\n\nImprovements on the DCGKA-based approach\nDocument the UPKE scheme\nCreated a small doc about ERC ERC-725 and ERC-735 in Notion\nStudy on a proposal authentication protocol based on SIWE + AS together.\nRead Ramses’ UPKE notes\n\n\nsecure-channels:waku:mls-design\n\nStarted preparing the talk for Brussels.\n\n\nzerokit:vac:zerokit-v0.5\n\nmerged PR about getting subtree root: subtree root PR\nfound bugs in tree behavior: Incorrect behavior of trees in override_range function\nmerged PR about checking and storing zero leaves indices: zero leaves PR\nin part of zero leaves PR: started to research better implementation for leaves storage (done with the idea of using bloom filter and its improvements - both had worse performance)\n\n\nrlnp2p:waku:rln-doc-and-outreach\n\nwrapped up and published rln-v3 rlog\n\n\nsecure-channels:waku:ethereum-chat\n\nstarted implementing design of de-MLS smart contracts\n\n\nrlnp2p:waku:rlnv2-e2e\n\nnew milestone discussion and agreement with waku research\nstarted converting waku-rln-contract to standalone repo since their requirements are more specific now\n\n\nstealth-address-kit:vac:research\n\npresented stealth address kit to the EIP Discussions call with the SC t\n\n\n\nvac:sc:: §\nvac:nim: §\n\ntooling:vac:compiler\n\nUpdates nimble https://github.com/nim-lang/Nim/pull/23601 After it gets merged it needs to be backported.\nBackport: https://github.com/nim-lang/Nim/pull/23600 https://github.com/nim-lang/Nim/pull/23599\n\n\ntooling:vac:editor\n\nAuto updates lsp when the local lsp is used (https://github.com/nim-lang/vscode-nim/commit/1b542e337095b74260b94e5f9ede5715035eafc5)\nUpload the artifacts from the last release so user can get the extension without using the marketplace: https://github.com/nim-lang/vscode-nim/releases/tag/v0.9.0\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nUpdated CODEX-MARKETPLACE rfc, ready for another round of feedback - https://github.com/vacp2p/rfc-index/pull/36\nCreated new dispersal rfc, still in draft - https://github.com/vacp2p/rfc-index/pull/39\n\n\nnomos:specs-init\n\nWorked on data availibility rfc, work still in progess\n\n\nvac:rfc-index\n\nmoved vac raw specs to raw folder - https://github.com/vacp2p/rfc-index/pull/37\ncreated pr to move rln-v1 to draft, still in draft - https://github.com/vacp2p/rfc-index/pull/40\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nCompleted staggered message sending approach for current (priority queues). The branch is available as draft PR for discussions.\nThe implementation shows upto 5% latency gains on most of the test runs, and significant bandwidth saving is achieved.\n\n\nzk:codex:zk-consulting\n\nWorked on questions that Codex raised concerning Beyond the Circuit that they have.\nBegan reviewing proposed proof algorithm draft\nProvided feedback on notes 1 and 2.\n\n\nvac:admin\n\nWorked on BloomFilter, KZG, and Verkle Trees blogs and presentation for LOGOS research call.\nProvided feedback on Akshaya’s notes as requested 1, 2, 3, 4.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nSynced with Daniel on current progress and milestone.\nResearched onion encryption for anonymous routing in GossipSub (WiP) and other mixnet solutions for comparison.\nBegan reading On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies to understand the attack on Dandelion better\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nReviewed and discussed the architecuture of state separation and took some decisions regarding the smart contracts types (Ugur + Moudy)\nImproved the prototype by adding private-only and public-only smart contracts (Ugur)\nCreated examples of executions consist of two functions for end-to-end execution (Moudy + Ugur)\n\n\nproofsystems:vac:research-existing-proof-systems\n\nStarted working on a writeup about Greco zk proofs (Rostyslav)\n\n\nproofsystems:vac:benchmarks\n\nDid further review on what should be included in the blogpost (was put on hold to finish the zkvms research list etc) (Moudy)\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nPublished a detailed issue including the list of the Zkvms that we need to look into and all the requirements to cover (Moudy)\nStarted researching existing zkVM’s (Team)\n\n\n"},"vac/updates/2024-05-27":{"title":"2024-05-27 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/05/27 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nStun protocol: merged :tada: https://github.com/status-im/nim-webrtc/pull/9\n\nRework getAttribute\nAdd callbacks for username & password\nAddress Diego’s comments\n\n\n\n\nnimlibp2p:vac:maintenance\n\nadd wildcard address resolver PR review https://github.com/vacp2p/nim-libp2p/pull/1099\nset EoF when remote peer half closes the stream in yamux review https://github.com/vacp2p/nim-libp2p/pull/1086\nfinished and merged https://github.com/vacp2p/nim-libp2p/pull/1086\nimproved https://github.com/vacp2p/nim-libp2p/pull/1099\nPR reviews\n\n\n\nvac:tke: §\n\nadmin\n\n1 CC day off\n\n\ncodex:cdx\n\nfinalized the TKE part of Whitepaper (Frederico)\nImproved code for Codex ABM, now at a better state, ready to start testing (Juan)\ninitial steps towards experimental design to simulate CDX security<>demand/supply & price (Juan)\nQuick reviewed Filecoin report (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\ncontinued the restructure of the previous work under a newly defined strategy (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed the SN economy proposal (Frederico)\nDrafting first docs on the economic model and identifying missing pieces, iterating on this with Cyp (Martin)\n\n\nwaku:rln-membership\n\nReviewing existing research into RLN and compatibility with the new design (Martin)\nReviewed RLN documents. (Juan)\n\n\nstatus:SNT-staking\n\nreviewed the swap aggregator work (Frederico)\nReviewing Juan’s work on swaps (Martin)\nFinished document on swap aggregator (Juan)\nperformed additional experiment on time window vs fulfilment (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nRepeat simulations with waku v0.27\n\nFound, documented potential Waku regression\nCreated bandwidth plots with weird results\n\n\nChanges to publisher\n\nPR https://github.com/vacp2p/10ksim/pull/30\n\n\nRe-doing requested deployments\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nSome PRs:\n\nFirst visualizer simple PR\nFound issue where simulation data is stored incorrectly.\n\nPR to check for this\n\n\nPR: Improved querying to get multiple simulation times at once\nPR: Add parameter for selecting how many datapoints we want in the plots\nPR: Rebase Wings deploy yamls into master\n\n\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nstore v3 - added 70 tests so far(@Florin)\n9 store v3 issues found:(@Florin)\n\nstore v3 returns error waku message hash parsing error: Incorrect base64 string for some cursors\npassing a cursor that doesn’t correspond to any message in the store will return all messages\nnwaku crashes for a store v3 request with invalid cursor format\nstore v3 local queries time out\nstore v3 response format issues\nstandardize store types by using camel case instead of [snake case]7(https://github.com/waku-org/go-waku/issues/1107)\npubsubTopic and contentTopics are required for store v3 requests\nstore v3 returns error illegal base64 data at input byte\nstore v3 - passing a cursor that doesn’t correspond to any message in the store will return all messages\n\n\nupdate all response fields to be camelCase(@Florin)\nsmall fix for ligh push dial fail error(@Florin)\n\n\nnomos:test-automation-cryptarchia\n\nRead Nomos ocumentation and related papers(@Alex)\nDelve into codebase to understand structure(@Alex)\nWorking in fixing coverage(@Alex)\n\nPR\nHelper PR\n\n\n\n\nadmin/misc\n\nInterview and reviewed QA Candidate code challenge(@Florin)\n1CC OOO All week\n\n\n\nvac:acz: §\n\nsecure-channels:waku:mls-design\n\nCreated authentication and login document for MLS design in notion\n\n\nzerokit:vac:zerokit-v0.5\n\nFix json serialization and update tests PR\nPublished release v0.5 on github\nreleased on crates.io\n\n\nrlnp2p:waku:rlnv2-e2e\n\nDeprecated waku-rln-contract in favour of waku-rlnv2-contract which uses vacp2p/foundry template directly instead of inheriting from vacp2p/rln-contract due to evolving business case and divergence from base offering of vacp2p/rln-contract\nReduced gas usage for waku-rlnv2-contract with onchain root from 250k gas to 104k gas for most insertions, some insertions vary depending on the leaf index due to recalculation of the merkle tree cache (anywhere between 150k-230k). still acceptable.\nAdded test vectors with kats from zerokit\nDeployed on sepolia for accurate gas measurements\n\n\nstealth-address-kit:vac:maintenance\n\nfeat(curves): integrate bw6_761\nchore(curves): simplify integration of new curves\nchore(StealthAddressOnCurve): refactor common utilities and traits\nfeat(curves): add pallas & vesta\nchore(release): v0.1.0 and released on crates.io\nfeat(curves): add secp256r1\nfeat(curves): add secp256k1\n\n\n\nvac:sc:: §\n\nvac:maintenance/misc\n\nUpdated ENS Usernames to allow custom release delay on deploy https://github.com/status-im/ens-usernames/pull/128\nMigrated ENS Usernames in Sepolia with 600 seconds of release delay on 0x3174DceF2649Ef7D3585cFC52d45586cF0d0dC90\nWIP: ENS usernames migrate to forge\nresearch on Zodiac contracts and Safe modules\nResearched proxy patterns\n\nTransparent proxies\nUUPSUpgradables\n\n\nInterviewed first candidate\n\n\n\nvac:nim: §\n\ntooling:vac:nimble\n\nAdd supports for nimDir flag. See the comment in the PR https://github.com/nim-lang/nimble/pull/1221\nFixed an issue where nim bin was wrongly constructed on win\n\n\ntooling:vac:lsp\n\nuse nimDir when available https://github.com/nim-lang/langserver/pull/200\n\n\ntooling:vac:compiler\n\nnimcheck issue on win (https://github.com/nim-lang/Nim/issues/23624) Fix needs to be reworked\nBackport nimble sat to 2.0 and 1.6 https://github.com/nim-lang/Nim/pull/23643 https://github.com/nim-lang/Nim/pull/23644\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nHad sync meeting with marketplace team on Thursday\nUpdated marketplace rfc, need to make changes based on feedback - https://github.com/vacp2p/rfc-index/pull/36\n\n\nnomos:specs-init\n\nWorked on data availibility rfc, need more time to finish rough draft\n\n\nadmin/misc\n\nOpened discussion for rln-v1 move to draft, and recieved feedback - https://github.com/vacp2p/rfc-index/pull/40\ncreated pr on waku/specs to end move to draft update for WAKU/METADATA and WAKU/NETWORK - https://github.com/waku-org/specs/pull/15; https://github.com/waku-org/specs/pull/16\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nConducted simulations results/code analysis for staggered message sending PR\nIdentified one potential issue related to IHAVE/IWANT messages.\nLooked into GossipSub specifications and other libp2p (go and rust) implementations for IHAVE/IWANT message flows\n\n\nvac:admin\n\nFinished presentation for Logos Research call\nFinished BloomFilter blog draft.\nFocus on Nescience\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nAddressed Marvin’s comments on anonymity layer notes.\nWorked Anonymity Layer - WiP.\nMet with Youngjoon to understand the practical considerations in designing anonymous communication for Nomos.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nAdditional reviews of the architecuture of state separation. (Moudy)\nWork on the input and outputs in the aggregation circuit for the state-separation prototype. (Ugur)[ACZ]\n\n\nvirtual-machine-creation:vac:vm-foundations\n\nWorked on the list of ZkVMs. Mainly covered: ZkMove, ZkWasm, PiecrustVM. (Moudy)\nWorked on zkVM list. Covered: NovaNet, zkLLVM, Lurk. (Rostyslav)\nWorked on zkVM list. Mainly covered: Ceno, Ola, Valida, RISC-0.(Marvin)[DR]\nWorked on zkVM list. Mainly covered: SP1, Powdr, Miden, and zkOS. (Ugur)[ACZ]\n\n\n"},"vac/updates/2024-06-03":{"title":"2024-06-03 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/06/03 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDTLS protocol https://github.com/status-im/nim-webrtc/pull/10\n\nAdds comments & improve PR presentation\nSolve some problems appearing with the merge of Stun protocol\nTrying to solve the CI with prerequisites installation in nim-mbedtls\n\n\nChore PR (renaming)\n\n\nnimlibp2p:vac:maintenance\n\nreview and finalize various chore PRs\n\n\n\nvac:tke: §\n\nadmin\n\nreviewed and updated TKE milestones (Frederico)\n\n\ncodex:cdx\n\nreviewed research reports about competitors (Frederico)\nstructureed and started developing Codex agent-based model (Frederico)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nproduced better comparisons between the fork-choice rules (Frederico)\nfinalized the single Jupyter notebook that replicates all computations (Frederico)\ncontinued the restructure of the previous work under a newly defined strategy (Frederico)\n\n\nwaku:general-incentives\n\ncaught up with the current state (Frederico)\n\n\nwaku:rln-membership\n\nReviewed existing research into RLN and compatibility with the new design (Martin)\n\n\nstatus:SNT-staking\n\nReviewed Juan’s work on swaps (Martin)\n\n\nstatus:L2-deployment\n\nDrafted first docs on the economic model and identifying missing pieces, iterating on this with Cyp (Martin\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nDeploy additional Ruby control plane nodes for better stability.\n\nPartially deployed, being finished today\n\n\nInvestigate Waku regression\nPR: New Publisher merged. Tested with 3K Nodes.\nFixed data retrieval issues with Pushprox that affected simulations.\nChanged Waku parameters to better test waku v0.27\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nAsync meetings with libp2p team to inform testing\nPR: Added deployment files in 10k repo for nim-libp2p.\nChanged DST-node branch to use nimbus build system.\nDeployed 1K nimlibp2p nodes and gathered data\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nNew weekly Monday meeting with Waku team about reliability\nWaku is interested in using the visualiser tool in their test fleet. Got an SSH tunnel for Elastic access.\n\n\n\nvac:qa: §\n\nwaku:interop-testing\n\nMerged store v3 - added 70 tests(@Florin)\nSpent 1 day investigating potential reliability issues that turned out to be misconfigs(@Florin)\n\n\nwaku:test-automation-status-go-cli\n\nCall with Pablo regarding requirements and deliverables(@Florin)\nStarted creating a test framework around the status go cli tool(@Florin)\n\n\nwaku:test-automation-rln\n\nFix: occasional failure to check published message for RLN tests(@Roman)\n\n\nnomos:test-automation-cryptarchia\n\nChore: cryptarchia unit tests update in progress(@Roman)\nExample how coverage changes in the report: Before -> After (@Roman)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nchore(tests): add kats test for merkle proof\nchore: integrate uups proxy\nchore: scaffold deployments\nmerged tests PR after addressing reviews\n\n\nstealth-address-kit:vac:maintenance\n\nchore: refactor into 2 crates, example and sdk\nchore: v0.2.0-beta release\nchore: refactor deps, make lib lighter\n\n\nvalidator-privacy:nimbus:productionize-tor-push\n\nreviewed codebase and paper\n\n\nsecure-channels:waku:mls-design\n\nStudy on login and authentication options for MLS design in terms of decentralization, adding a conclusion to doc\nExamine login mechanism of a self-hosted messaging app based on matrix named element see in github\nFinished the (first version) of the presentation for the EthCC Brussels.\n\n\nsecure-channels:waku:mls-poc\n\ntried to implement poc using openmls and centralised DS -> not finished, found that using decentralised approach is better\nstarted to investigate how to use waku as DS\n\n\nconsulting:codex:proxy-re-encryption\n\nattended kick-off call, meeting notes with action points for next steps\n\n\nadmin/misc\n\nadded codex proxy re-encryption to roadmap pr and merged\n\n\n\nvac:sc:: §\n\nvac:maintenance/misc\n\ninitial Certora setup for codex contracts https://github.com/codex-storage/codex-contracts-eth/pull/113\nWIP: ENS usernames to latest solidity\nWIP: ENS usernames migrate to forge\nENS Usernames to new ENS registry\nProxies and Upgradeable contracts research\nPresented proxy patterns in EIP discussions call\n\n\n\nvac:nim: §\n-tooling:vac:compiler\n\nnimcheck rework previous solution: https://github.com/nim-lang/Nim/pull/23625\n-tooling:vac:nimble\nchange it to dump (https://github.com/nim-lang/nimble/pull/1221)\n-tooling:vac:lsp\nchange it to use dump (https://github.com/nim-lang/langserver/pull/200)\nunify nimble dump calls and extract type https://github.com/nim-lang/langserver/pull/201\nspeed up dump by caching calls (https://github.com/nim-lang/langserver/pull/202)\n-tooling:vac:editor\nuse nimble dump when available to retrieve the nimDir for run and debug (https://github.com/nim-lang/vscode-nim/pull/64) and https://github.com/nim-lang/vscode-nim/pull/65\nfixes compilation issue with latest version 2.0 https://github.com/nim-lang/vscode-nim/compare/main…jmgomez:fixcompilationissuever20?expand=1\n\nvac:rfc: §\n\ncodex:specs-init\n\nUpdated marketplace rfc, made changes based on feedback - https://github.com/vacp2p/rfc-index/pull/36\n\n\nnomos:specs-init\n\nWorked on data availibility rfc, created pr still in draft - https://github.com/vacp2p/rfc-index/pull/\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nExperimented with different optimizations for minimizing the impact of IWant messages. Additionally, we can skip sending IWant if we have received multiple IDontWants for the same msgID; implemented this in PR that shows reasonable improvement.\n\n\nvac:admin\n\nLogos Research call presentation\nMet with Aaryamann concerning blog formatting.\n\n\nzk:codex:zk-consulting\n\nBegan document on proposed proof algorithm draft, and began notes on Groth16 as a wrapper.\nBegan reading Circle STARK, ECFFT1 and ECFFT2 to focus on variations of FFT optimizations.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nReading Nym Network white paper. This addresses several open questions we had: strong adversarial model, reputation system that ensures reliability and mitigates Sybil attacks, uses verifiable random functions for node selection, maintains list of active nodes, prevent long-term correlation attacks by rotating active nodes every hour, rewards for nodes.\nBegan investigating an open source libp2p-nym implementation in Rust\n\n\n\nvac:nes: §\n\nvirtual-machine-creation:vac:vm-foundations\n\nwork on list of ZkVMs\n\nContinued entering data on Nexus, Jolt, o1VM.\nFound new benchmarks for SP1, Jolt and Valida\nOla and snarkOS. [DR]\nCompiled information for Valida, Ola, snarkOS, RISC0 and Valida into the zkVM table. [DR]\ncompiled information for P1, Powdr, Miden, zkOS, Aleo(snarkVM), and zkMIPS in zkVM table [ACZ]\n\n\n\n\nproofsystems:vac:research-existing-proof-systems\n\ncontinue working on a writeup about Greco zk proofs\n\n\n"},"vac/updates/2024-06-10":{"title":"2024-06-10 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/06/10 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nmbedtls: Try differents way to fix the installation on windows due to CI errors\n\nUpdate the version of MbedTLS (a bit too overkill)\nChange pip / python version\nUse pip requirement file\nChange the packages constraints.\n\n\nmbedtls: Work on MacOS CI failing.\n\n\nnimlibp2p:vac:maintenance\n\nreleased v1.3.0\ngossipsub 1.2 https://github.com/vacp2p/nim-libp2p/pull/1106\nfix(services): setup services before peerinfo is updated https://github.com/vacp2p/nim-libp2p/pull/1120\nfix(multicodec): remove unnecessary “!=” operator https://github.com/vacp2p/nim-libp2p/pull/1112\nFormatting https://github.com/vacp2p/nim-libp2p/pull/1118\nfix(gossipsub): pubsubpeer is created with wrong gossipsub version https://github.com/vacp2p/nim-libp2p/pull/1116\n\nInvestigate flaky tests: Couldn’t replicate\n\n\nCI cleanup and streamlining\n\nPR\nMissing: Converting Daily to minver-maxver, and consider changing coverage from full workflow to step after tests.\n\n\n\n\n\nvac:tke: §\n\nadmin\n\n5 (Martin) + 4 (Frederico) days off\nupdated the TKE milestones (Frederico)\n\n\ncodex:cdx\n\nreviewed the latest modifications in the Whitepaper (Frederico)\nWorked on improving code for simulations (efficiency, refactoring etc.) -> This efficiency is needed for MC simulations (Juan)\nResearched Filecoin government models for Agatha after discussion (Juan)\n\n\nstatus:SNT-staking\n\nStarted reading Cyp’s blogpost on SNT (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:10k\n\nContinue attempts at “10k with metrics”, further optimisations\nBring back missing nodes\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\n9x simulations with waku v0.27.\nInvestigate v0.26/v0.28 mesh stability issues https://github.com/waku-org/nwaku/issues/2780\nFixed error in our LivenessProbe deployment yaml, met with Ivan from Waku about this\nGrafana Loki briefly installed and configured and setup; removed due to issues it caused\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nRebased the nimbus build system code to a new branch: https://github.com/vacp2p/dst-gossipsub-test-node/tree/dockerized-nimbus-bs\nFound error with nimble and 1.2.0 version of Nimlip2p (https://discord.com/channels/864066763682218004/1247474261996867684)\nSimulations with 1.2, 1.2.1 and 1.3.0.\n\nYamux and mplex\nhttps://www.notion.so/Nim-libp2p-report-May-2024-7b1c6a06e667440894b554d77f7c7886\n\n\n\n\nvac:dst:tooling:vac:deployer-tool\n\nPR for ignoring bootstrap-midstrap nodes during plotting https://github.com/vacp2p/10ksim/pull/32\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nStarted working on dynamic configuration for visualiz\n\n\n\nvac:qa: §\n\nwaku:test-automation-status-go-cli\n\ninitial PR reviewed and merged with one to one messages functionality(@Florin)\nreviewed and tested subsequent improvement PR from Pablo(@Florin)\ndiscussed results and future work on the ticket(@Florin)\n\n\nwaku:interop-testing-02\n\nstarted looking at discv5 tests(@Florin)\nTest/peer connection management PR 45 - in progress(@Roman)\n\n\nnomos:test-automation-cryptarchia\n\nchore: cryptarchia unit tests update PR 657 - on hold till 17th June (@Roman)\n\n\nwaku:test-automation-rln\n\nCreate issues (@Alex)\n\nMember doesn’t exist after registration\nImprove RLN experience\nRLN Flags issues\n\n\nRLN v2(@Alex)\n\nIntroductory meeting\nCheckout docs and have a look at the tooling\n\n\n\n\nvac:test-automation-nim-libp2p\n\nInvestigate flaky tests: Couldn’t replicate(@Alex)\nCI cleanup and streamlining(@Alex)\n\nPR\nMissing: Converting Daily to minver-maxver, and consider changing coverage from full workflow to step after tests.\n\n\n\n\n\nvac:acz: §\n\nsecure-channels:waku:mls-design\n\nFinished the EthCC presentation.\nStudy on onchain parts of mls-design\n\n\nconsulting:codex:proxy-re-encryption\n\nWorked in the PRE report.\nPerformed research in alternatives to PRE. ABE might be a plausible alternative.\n\n\nsecure-channels:waku:mls-poc\n\nre-design general idea of decentirlized architecture: Delivery Service is represented by Waku Node and doesn’t require additional service\nwent through example of using Waku rust bindings in other project\nstarted to figure out what data we need to store/get on-chain\n\n\n\nvac:sc:: §\n\nvac:maintainance/misc\n\nsetup certora on the codex repo\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/113\n\n\nENS usernames to latest solidity\nENS usernames migrate basic tests to forge\nsoft audited codex contracts\n\n\n\nvac:nim: §\n\ntooling:vac:compiler\n\nC++ Issue (https://github.com/nim-lang/Nim/issues/23657) fix: https://github.com/nim-lang/Nim/pull/23666\nC++ Issue research https://github.com/nim-lang/Nim/issues/23656\nNimSuggest should handle not known files [WIP]\n\n\ntooling:vac:lsp\n\nIssue research https://github.com/nim-lang/langserver/issues/203\nFixes an issue where wrong project was auto guessed and Test to cover it. (https://github.com/nim-lang/langserver/pull/206)\nAdd Tests to CI: https://github.com/nim-lang/langserver/pull/205 https://github.com/nim-lang/langserver/pull/205\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nWorked on data availibility rfc, still in draft - https://github.com/vacp2p/rfc-index/pull/41\n\n\nadmin/misc\n\nadded changes based on feedback for rln-v1 - https://github.com/vacp2p/rfc-index/pull/40\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nBegan work on research blog post for gossipsub improvements for large messages. Specifically, looked into the outcomes/rationales of previous performance experiments conducted for large messages, revisited posts/discussions on large messages handling for compiling work\n\n\nzk:codex:zk-consulting\n\nContinued document on proposed proof algorithm draft.\nContinued reading Circle STARK, ECFFT1 and ECFFT2 with the emphasis to produce notes on CFFT and ECFFT.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nExamine libp2p-nym\nRead GossipSub specs.\nBegan work on an initial proposed model. Performed calculations for the probability of deanonymization with a high fraction of malicious nodes (35-40%) for random mixed nodes. Results similar to top 5 AS-level adversaries.\n\n\n\nvac:nes: §\n\nvirtual-machine-creation:vac:vm-foundations\n\nwork on list of ZkVMs\n\nFinished entering data on Nexus, Jolt, o1VM.\nStarted going through codebases ov zkVMs.\nCovered and fulfilled the table for Stellar and Cairo in zkVM table.[ACZ]\nSanity checked RISC0 and Valida from Marvin, Nexus and Jolt from Rostyslav, Cairo and Stellar from Moudy.[ACZ]\n\n\n\n\nproofsystems:vac:research-existing-proof-systems\n\nContinue working on a writeup about Greco zk proofs.\n\n\nstate-separation:vac:state-separation-architecture-01\n\nStudy on the racing conditions for state-separation prototype. [ACZ]\n\n\n"},"vac/updates/2024-06-17":{"title":"2024-06-17 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/06/17 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nFix nim-mbedtls MacOS installation\nMerge small chore PR https://github.com/vacp2p/nim-webrtc/pull/13\nDTLS ready to review https://github.com/vacp2p/nim-webrtc/pull/10\n\n\nnimlibp2p:vac:maintenance\n\nhttps://github.com/vacp2p/nim-libp2p/pull/843\n\nOlder PR about races conditions; Find/implement solutions to fix it\n\n\nfix(CI): rebuild website job https://github.com/vacp2p/nim-libp2p/pull/1125\nfix(readme): update links https://github.com/vacp2p/nim-libp2p/pull/1126\nfix(CI): generate website job https://github.com/vacp2p/nim-libp2p/pull/1124\nfix(tests): testautorelay https://github.com/vacp2p/nim-libp2p/pull/1121\nfix(tests): flaky testdaemon https://github.com/vacp2p/nim-libp2p/pull/1123\nchore(formatting): format the whole codebase using nph 0.5.1 https://github.com/vacp2p/nim-libp2p/pull/1118\nfix(gossipsub): pubsubpeer is created with wrong gossipsub version https://github.com/vacp2p/nim-libp2p/pull/1116\n\n\n\nvac:tke: §\n\nadmin\n\n2 (Frederico) + 5 (Martin) days off\nchanged the TKE milestones after getting feedback (Frederico)\nanalysis of Risk Quant Lead candidate task (Frederico)\nMet with Martin to discuss hand-off (Juan)\n\n\ncodex:cdx\n\ncleaned up Litepaper (Frederico)\nKept working on simulations code, greatly improved efficiency (Juan)\nWrote piece on Filecoin government (Juan)\n\n\ncodex:testnet-incentive\n\ncaught up the current thinking of the Codex team (Frederico)\n\n\nstatus:SNT-staking\n\nCommented Cyp’s blogpost (Juan)\nDiscussed further directions on the swap aggregator (Juan)\n\n\nstatus:L2-deployment\n\nStarted work on catsfishing (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nMeeting with Codex team members comparing DSNs and offering a competive analysis\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nRunning attempts at “10k with metrics”, new tests with noise dampening\nBrought back missing nodes\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nContinued debugging waku regression\nRepeated deployments with 0.28, and compared with 0.27.\nGave feedback to Gabriel@Waku about change in Waku logging\n0.28 deployment for Ivan/Hanno, plotting message time distribution to all peers.\n\nIvan specifically requested different sizes and latencies- vac:dst:deployment-and-analysis:waku:midscale\n\n\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nContinue work on injecting elastic information in visualiser\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nTried to repeat simulations with different message size and latency witn 1.2.0 and 1.3.0\n\nCouldn’t obtain data, still trying to figure out why\n\n\n\n\n\nvac:qa: §\n\nwaku:test-automation-status-go-cli\n\ncontact request tests - merged(@Florin)\nprivate groups tests - in progress(@Florin)\nreviewed Pablos’s PR where he fixed and added new functionality to status-cli(@Florin)\n\n\nwaku:interop-testing-02\n\nTest/peer connection management in progress(@Roman)\n\n\nnomos:test-automation-cryptarchia\n\nchore: cryptarchia unit tests update on hold till 17th June(@Roman)\nchore: cryptarchia ledger unit tests update in progress(@Roman)\n\n\nwaku:test-automation-rln\n\nInvestigate and fix waku-simulator issues with docker/podman on windows and fedora(@Alex)\nBegan running tests(@Alex)\n\n\nwaku:maintenance-nwaku\n\nAnswer open issues(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nchore(tests): add kats test for merkle proof\nchore: integrate uups proxy\nchore: scaffold deployments\nmerged tests PR after addressing reviews\n\n\nstealth-address-kit:vac:maintenance\n\nchore: refactor into 2 crates, example and sdk\nchore: v0.2.0-beta release\nchore: refactor deps, make lib lighter\n\n\nvalidator-privacy:nimbus:productionize-tor-push\n\nreviewed codebase and paper\n\n\nsecure-channels:waku:mls-design\n\nStudy on login and authentication options for MLS design in terms of decentralization, adding a conclusion to doc\nExamine login mechanism of a self-hosted messaging app based on matrix named element see in github\nFinished the (first version) of the presentation for the EthCC Brussels.\n\n\nsecure-channels:waku:mls-poc\n\ntried to implement poc using openmls and centralised DS -> not finished, found that using decentralised approach is better\nstarted to investigate how to use waku as DS\n\n\nconsulting:codex:proxy-re-encryption\n\nattended kick-off call, meeting notes with action points for next steps\n\n\nadmin/misc\n\nadded codex proxy re-encryption to roadmap pr and merged\n\n\n\nvac:sc:: §\n\nvac:maintenance/misc\n\nSetting up first certora rules in Codex repo\nENS usernames migrate remaining tests to forge\nENS usernames forge\n\nhttps://github.com/status-im/ens-usernames/issues/129\nhttps://github.com/status-im/ens-usernames/tree/foundry-template-test\n\n\nResearched EIP4626 tokenized vaults and security vulnerabilities\nPresented research to team\nMeeting with Finance and Security to discuss plans with Zodiac modules\n\nFinance will set up deploy script to create a SAFE with multisig and zodiac roles modifier + scope guard\n\nSC team and Security team will review deploy scripts\nSC team will deploy contracts on behalf of finance\n\n\n\n\nRebased Ricardos work on ENS username repo refactor\n\nBranch: https://github.com/status-im/ens-usernames/commits/foundry-template/\nAlso had session with him about ironing out some processes\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:compiler\n\nFix an issue in nimsuggest where unknown files werent being handled: https://github.com/nim-lang/Nim/pull/23696\nBackports: https://github.com/nim-lang/Nim/pull/23702 and https://github.com/nim-lang/Nim/pull/23701\nFix: “#23695: On Linux, “nimsuggest” crashes if Nim is installed in /usr/bin and the library in /usr/lib/nim” https://github.com/nim-lang/Nim/pull/23697\n\n\ntooling:vac:lsp\n\nImplements the extension/status endpoint (https://github.com/nim-lang/langserver/commit/3879966eed20f04ce4254b67c5c6496c06358b79)\nIt’s useful for asserting in tests in a reliable way as it exposes the langserver and nimsuggest instances current status (i.e. main file, known files, etc.) It can also be useful to create a specific window in extension to quickly inspect the current status for a given project\n\n\ntooling:vac:editor\n\nImplements Show NimLangServer Status command. (https://github.com/nim-lang/vscode-nim/pull/67)\nRight now is just outputing into the output window. In the near future we are going to build a separate window to inspect it.\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nWorked on data availability rfc, not ready for feedback, still in draft - https://github.com/vacp2p/rfc-index/pull/41\n\n\nadmin/misc\n\nClosed and moved issues from rfc old repo; archived old repo (https://github.com/vacp2p/rfc)\nUpdated readme on rfc-website - https://github.com/vacp2p/rfc.vac.dev/pull/2\n\n\n\nvac:dr: §\n\nvac:admin\n\nTeam synced outside of standup for additional feedback.\n(Marvin) Began investigating gossipsub lazy message issue as prep for testing.\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nBegan work on research blog post for gossipsub improvements for large messages: WIP draft\n\n\nzk:codex:zk-consulting\n\nWrote notes on a binding issue in Codex proposal notes along with a solution.\nWrote brief notes for PolyMath.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nStarted writing Anonymized GossipSub Transport Protocol (AGTP) specification -WiP.\n\n(AGTP will be renamed as the name is not fitting; just WiP atm)\nResearched ways to prevent adversarial senders from abusing the mixnet to DoS single exit nodes; current issue: this could potentially lead to honest exit nodes being penalized and ignored.\n\n\nInvestigated mining techniques; selected proof of work for now.\n\n\n\nvac:nes: §\n\nvirtual-machine-creation:vac:vm-foundations\n\nwork on list of ZkVMs\n\nFinished entering data on missing Zkvms info. [Moudy]\nStarted going through codebases ov zkVMs. [Rostyslav]\nUpdated and integrated additional information on Github and Table lists. [Moudy]\nStarted discussions about the selection of Zkvms and how to add privacy requirements.[Team]\n\n\n\n\nstate-separation:vac:state-separation-architecture-01\n\nReviewed the state separation architecture prototype. [Moudy]\nStarted defining important traces and working through a first draft. [Moudy]\nReviewed the prototype and extracted the rest of possible topics to obtain the scope of the blogpost. [UGUR] [ACZ]\nWork on a demo example of state separation execution for the prototype for each kind of TX. [UGUR + MOUDY] [ACZ]\nExamine the private execution project named sarma\n\n\n"},"vac/updates/2024-06-24":{"title":"2024-06-24 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/06/24 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nMerged new PeerEvent https://github.com/vacp2p/nim-libp2p/pull/843/\nMerged Yamux: change a Future into a AsyncEvent because it makes more sense https://github.com/vacp2p/nim-libp2p/pull/1133/\nfeat: add maxSize to TimedCache https://github.com/vacp2p/nim-libp2p/pull/1132\nchore: add .git-blame-ignore-revs https://github.com/vacp2p/nim-libp2p/pull/1130\nchore: delete branch folders from gh-pages https://github.com/vacp2p/nim-libp2p/pull/1127\n\n\nnimlibp2p:vac:webrtc-transport\n\nDTLS https://github.com/vacp2p/nim-webrtc/pull/10\n\nAdds testing\nSome refactorization (remove useless code/change names/comments/splitting files etc..\n\n\n\n\nnimlibp2p:vac:gossipsub-perf-improvements\n\nImprovements related to Gossipsub 1.2 https://github.com/vacp2p/nim-libp2p/issues/1131\n\n\n\nvac:tke: §\n\nadmin\n\n2 CC days-off\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nperformed statistical analysis of simulation results (Frederico)\nread paper about StakeSure (Frederico)\nDiscussed statistical analysis of simulation results w/Frederico (Juan)\n\n\ncodex:cdx\n\nfinalized the Litepaper (Frederico)\nprepared a “Codex in one slide” doc (Frederico, Juan)\nworked on simulations (Juan)\n\n\ncodex:testnet-incentive\n\nkicked off the testnet incentives report (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed all docs (Frederico, Juan)\nMeeting with Swiss legal councel for status (Frederico, Juan)\nWorked on CowSwap comparison (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:10k\n\nVarious (1-10k) 0.27 deployments with full hardware, measurements\n\n“Right on the edge” with Prometheus\nWill be backing up Prometheus and replacing with VictoriaMetrics\n\n\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nRepeat multiple simulations for Gabriel(Waku) until found the issue\nSimulations for version v0.29\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nCall and chat with Zoltan. Helped him analyze some waku-simulator results with visualizer.\nStarted cleaning/creating more utilities for Zoltan so he can use it on his own.\nDeployed VictoriaLogs to replace Loki and finally get logs from each container\nPrep work for switching to VictoriaMetrics for better telemetry\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nDo simulations, gather data and perform analysis for nimlibp2p\n\nAnalysis with 50KB and 500KB, 1.2 and 1.3 versions, with mplex and yamux\n\n\n\n\n\nvac:qa: §\n\nwaku:test-automation-status-go-cli(@Florin)\n\nprivate groups tests - merged\ncommunity actions tests - in progress\n\n\nwaku:interop-testing-02(@Roman)\n\nTest/peer connection management\nPR 45 - merged <- issues processed\nbug: could not register RLN\nIssue 2837 - open - new implementation TBD\n\n\nnomos:test-automation-cryptarchia(@Roman)\n\nchore: cryptarchia unit tests update\nPR 657 - in progress\nchore: cryptarchia ledger unit tests update\nPR 660 - in progress - one last state not simulated\n\n\nvac:test-automation-nim-tooling(@Roman)\n\ntest: use Nimble to manage Nim\nPR 71 and PR 222\n\n\nwaku:test-automation-rln(@Alex)\n\nRLN v2 Testing\n\nRun tests both in old and new (waku:v0.30.0-rc.0) nwaku image\nVarious fixes and two helper scripts - PR\nFound Issues:\n\nRLN_RELAY_MSG_LIMIT error handling\nRestarting node containers don’t load keystore\nExcessive memory usage on nodes with big message sizes\n\n\n\n\n\n\n\nvac:acz: §\n\nsecure-channels:waku:mls-poc\n\nCreate PR with de-MLS PoC\nFixed most of comments after first review\nStarted to work with applying redis pub-sub approach\n\n\nsecure-channels:waku:mls-design\n\nPreparation of the talk for EthCC Brussels.\n\n\nconsulting:codex:proxy-re-encryption\n\nResearch on alternative approaches to PRE.\nCreation of report on research.\n\n\nadmin/misc\n\n1 CC was ooo 18th, 19th and 20th (public holiday)\n\n\nrlnp2p:waku:rlnv2-e2e\n\nrlnv2 fork fully merged into nwaku\nchore(zerokit): bump submodule\nfix(rln-relay): clear nullifier log only if length is over max epoch gap\nassist with waku-simulator testing\n\n\nstealth-address-kit:vac:maintenance\n\nchore(StealthAddressOnCurve): reuse scalar field from Projective\nfix: gitattributes, github pages deployment\nchore: add benchmarks\nchore(release): v0.2.0\nvarious documentation added, 1, 2 and 3, visible on docsrs\n\n\nzerokit:vac:maintenance\n\nchore(rln): further refactoring of interface\nchore(release): v0.5.1 released to crates.io now that confirmed compatibility with nwaku\n\n\n\nvac:sc:: §\n\nstatus::ens-usernames-maintenance\n\nFinshed the migration to foundry\n\nhttps://github.com/status-im/ens-usernames/pull/130\n\n\n\n\nfinance::access-control-safes-support\n\nMet with finance and went through deployment scripts for access control safes\n\n\nstatus:staking-contracts-v1\n\nRefactored staking contract functions to be more descriptive\n\nhttps://github.com/logos-co/staking/pull/93\n\n\nFixed a bug that lock() increases account.initialMP\n\nhttps://github.com/logos-co/staking/pull/94\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:editor\n\nImplements a panel to inspect the lsp status so we can easily debug it https://github.com/nim-lang/vscode-nim/pull/68\n\n\ntooling:vac:lsp\n\nwip project setup. Improves status, better handling on unknown files #209 https://github.com/nim-lang/langserver/pull/209\nReuses nimsuggests instances in kwnon files (https://github.com/nim-lang/langserver/pull/211)\nImplements entryPoint (https://github.com/nim-lang/langserver/pull/212)\nWIP Project Setup pending PR\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nContinued work on data availability rfc, still in draft. Currently believe all sections are included but all sections are not to elaborate. - https://github.com/vacp2p/rfc-index/pull/41\n\n\ncodex:specs-init\n\nMoved marketplace spec to codex org repo, and made some changes based on feedback - https://github.com/codex-storage/codex-spec/pull/1\nreading for vaildator role rfc\n\n\n\nvac:dr: §\n\nvac:admin\n\nRead Nomos’ notes on Proof of Equivalence\nBegan writing Fiat-Shamir blog\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nWorked on blog post for gossipsub improvements for large messages. Still a WiP, need to add summary and references. (ready for review)\n\n\nzk:codex:zk-consulting\n\nMet with Balazs to discuss IPA and binding.\nBegan reading Blazas’ most recent proposal\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinue documenting Anonymized GossipSub Protocol (AGP) specification.\n\nFinished PoW section\n\n\nInvestigate issues related to wrapping published messages into Sphinx Packet Format\n\n\n\nvac:nes: §\n\nvirtual-machine-creation:vac:vm-foundations\n\nwork on list of ZkVMs\n\nSanity check of the entire list of Zkvms.[Moudy]\nUpdated and integrated additional information on Github and Table lists.[Moudy]\nAdded a new table with score for Zkvm implementation.[Moudy]\nPrepared a document with a list of primitives and privacy requirements needed to implement on top of existing Zkvms.[Moudy + Marvin] + [DR]\nProvided data on why zkLLVM, Lurk, Novanet, Ola, SnarkOS are not zkVMs. [Rostyslav]\nSanity checks Cairo and Piecrust. [Rostyslav]\nAdded missing data on zkVMs. [Rostyslav]\nScored SP1, JOLT, Nexus, RISC0, Valida, O1VM. [Rostyslav]\nProvided information why SP1, zkMIPS, Miden, and Aleo(SnarkVM) are zkVM and why zkOS, Powdr are not. [Ugur][ACZ]\nProvide why (or why not zkVM) zkVM for Valida, Nexus, Jolt, Ceno and RISC0. [Marvin][DR]\n\n\n\n\nstate-separation:vac:state-separation-architecture-01\n\nWorked on defining and answering several questions about Nesceince. [Moudy]\nReviewed part of the prototype. [Moudy]\nStarted to answering some questions related to blogpost for state separation. [Ugur][ACZ]\n\n\n"},"vac/updates/2024-07-01":{"title":"2024-07-01 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/01 §\nvac:p2p: §\n\nnimlibp2p:vac:maintenance\n\nremoving asyncspawn on yamux\n\nIssue: https://github.com/vacp2p/nim-libp2p/issues/1134\nPR: https://github.com/vacp2p/nim-libp2p/pull/1140\nfix: spamming peer is disconnected and seen cache doesn’t grow indefinitely https://github.com/vacp2p/nim-libp2p/pull/1139\n\n\n\n\nnimlibp2p:vac:webrtc-transport\n\nTrying to fix the linking issue on Windows/MBed-TLS\nFix of the trackers (opening / closing connections and transports)\n\n\nnimlibp2p:vac:quic\n\nQuic Transport https://github.com/vacp2p/nim-libp2p/pull/725\n\n\nnimlibp2p:vac:gossipsub-perf-improvements\n\nfeat: iDontWant is sent only for gossipsub 1.2 or higher https://github.com/vacp2p/nim-libp2p/pull/1135\n\n\n\nvac:tke: §\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\ncontinued the statistical analysis of simulation results (Frederico)\nprepared and ran more simulations (Frederico)\n\n\ncodex:testnet-incentive\n\ncontinued developing the testnet incentives report (Frederico)\n\n\ncodex:cdx\n\nlight work on simulations, will retake this week (Juan)\n\n\nwaku:general-incentives\n\nreviewed the latest incentivization proposal (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed the catsfishing project (Frederico)\nreviewed the past work on GMX and veSNT (Frederico)\nworked CowSwap comparison, caught a few bugs. Mostly focused on this (Juan)\nreviewed and provided coments on the past work on GMX and veSNT (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nRan version 1.1 deployments @ 500KB\nhttps://www.notion.so/Nim-libp2p-report-June-2024-7e6fa14c829d4660be6739817e07956f\n\n\nvac:dst:tooling:vac:visualizer-tool\n\nWorked with Zoltan, handed over some new utils/features\nTweaked VictoriaLogs deployment to enable new visualiser\nCreated new experimental realtime visualiser (separate codebase for now)\n\nUses VictoriaLogs to scrape\nWill look at crossover/integration down the track\n\n\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nRan Waku v0.29 deployments to measure Waku without peer discovery and get a baseline idea of DiscV5’s performance (in terms of mesh behaviour) and bandwidth usage.\n\nRan into scaling issues, could not go beyond low (~40-80) number of well connected peers in a 1000 node cluster\nRepeated attempts with same results consistently\nWill repeat with new parameters\n\n\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\nchore: refactor setup relay node for sharding (@Roman)\nPR 48 - in progress(@Roman)\n\n\nnomos:test-automation-cryptarchia\n\nchore: cryptarchia unit tests update(@Roman)\nPR 657 - merged\nchore: cryptarchia ledger unit tests update (@Roman)\nPR 660 - merged\n\n\nvac:test-automation-nim-tooling\n\ntest: use Nimble to manage Nim (@Roman)\nPR 222 - report created\n\n\nwaku:test-automation-rln\n\nRun more simulations(@Alex)\nFound two possible issues with waku simulator that need some investigating:(@Alex)\n\nNodes don’t receive all messages\nNot all nodes are sending messages\n\n\nPost issue mentioned in past weekly: Memory usage issue(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nchore(rln-relay): add chain-id flag to wakunode and restrict usage if mismatches rpc provider\ndeployed waku-rlnv2-contract to linea sepolia\nredeployed waku-rlnv2-contract to linea sepolia & polygon zkevm testnet (cardona) with new params decided by Waku team\ncreated linea sepolia testnet faucet to bootstrap new operators for Waku\nassist with waku-simulator testing of rln-relay-v2\n\n\nstealth-address-kit:vac:maintenance\n\nmaintenance release v0.3.1\nupdated benchmarks with clean testing bench\n\n\nsecure-channels:waku:mls-design\n\nPreparation of the talk for EthCC Brussels.\n\n\nsecure-channels:waku:mls-poc\n\nupdated interface regarding smart contract integration in this PR and merged it into main\nchanged delivery service provider to redis in redis-approach PR\nfeat(sc_keystore): initialize smart contract template\nchore(sc_keystore): add interface of smart contract\nchore(sc_keystore): initial implementation\n\n\nconsulting:codex:proxy-re-encryption\n\nFinish the PRE report.\n\n\nadmin/misc\n\nCCs getting ready for ethcc Brussels\n1 CC day OOO\n\n\n\nvac:sc:: §\n\ncodex::contracts-formal-verification\nfinished base certora setup and first specs but blocked on a few errors\nstatus:staking-contracts-v1\n\nReseach on MP estimation\nMeeting with Tokeneconimcs\nPaired with Ricardo to clarify misunderstanding of the semantics of initialMultiplierPoints and currentMultiplierPoints\n\nEnded up making changes to these so that they match the semantics\n\nhttps://github.com/logos-co/staking/pull/95#event-13284131380\n\n\n\n\nRebased pending work on cooldown period implementations\n\nhttps://github.com/logos-co/staking/pull/92\n\n\n\n\nfinance::access-control-safes-support\n\nFinished reviewing the deployment scripts of the access control safes\nDeployed the access control safes together with finances team\n\nRepository\n\nhttps://github.com/logos-co/access-control-safes\n\n\nRecording (private, can be requested)\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:lsp\n\nCompletes projectsetup (Note tests are missing but will add them after the chronos refactor)\nTrim Nimsuggest instances, improve heuristics: https://github.com/nim-lang/langserver/commit/fe0d9edff537f2dd653e011963c1b56ee95b9536\nIntroduces extension/statusChanged #215 (https://github.com/nim-lang/langserver/pull/215)\n\nTest it works in multiple combinations of Nim/Nimble versions\n\n\n\n\ntooling:vac:editor\n\nHooks into the nimlangserver statusChanged notification https://github.com/nim-lang/vscode-nim/pull/69\n\n\ntooling:vac:compiler\n\nbump nimble https://github.com/nim-lang/Nim/pull/23766\n\n\ntooling:vac:nimble\n\nAutomatically adds binaries to entryPoints #1230 https://github.com/nim-lang/nimble/pull/1230\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nOpened pr for first draft of data availability rfc for feedback - https://github.com/vacp2p/rfc-index/pull/41\n\n\ncodex:specs-init\n\nDid some reading of proof of storage codex articles for validator rfc\n\n\n\nvac:dr: §\n\nvac:admin\n\nFinished draft for Bloom filters blog; ready for review.\nWorked on draft for Fiat-Shamir blog; almost ready for review.\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nCompleted blog post for gossipsub improvements for large messages.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nLearned about shadow simulator.\nStarted learning testground simulator. Done with installation and basic reads.\nCurrently going through other gossipsub and gossipsub hardening repos for testground to learn about making/running testplans\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued working on Anonymized GossipSub Transport Protocol (AGP) specification. Specifically, worked on the mix context and sphinx packet creation section, corrected deanonymization probability, and addressed feedback.\n\n\nzk:codex:zk-consulting\n\nProvided feedback on Blazas’ most recent proposal\nContinued research on foreign arithmetic.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nWork on the document of Execution Types as part of our Q2 Milestones:\n\nWorked on the document [Ugur][ACZ]\nReviewed and integrated the document for publication [Moudy]\n\n\nWork on the document of Cryptographic Infrastructure and Nullification Strategy as part of our Q2 Milestones:\n\nWorked on the document [Ugur][ACZ]\nReviewed and integrated the document for publication [Moudy]\n\n\nRevisit the type of authenticated data storage such as SMT, Mutator Sets for blogpost. [Ugur][ACZ]\nStudy about the “Nescience state-separation as an add-on for the Dapps”. [Ugur][ACZ]\nAnswered questions related to Nescience (needs some polishing). [Moudy][Ugur][ACZ]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nReviewed Cairo and Piecrust [Rostyslav]\nFinished Scoring zkVMs [Rostyslav]\nStaring going through materials on ring signatures provided by Marvin [Rostyslav]\nProvide Rostyslav with a list of resources for ring signatures [Marvin][DR]\n\n\nBegin compiling a list comparing privacy zkVMs from the list to Nescience. [Marvin][DR]\n\n\n"},"vac/updates/2024-07-08":{"title":"2024-07-08 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/08 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nadd proper tracker management: https://github.com/vacp2p/nim-webrtc/pull/17\nfix the DTLS windows compilation bug\n\n\nmisc/admin\n\nreviewing stuff\nfix old unittest2 issue: https://github.com/status-im/nim-unittest2/pull/44\n\n\nnimlibp2p:vac:quic\n\nfix: make the tests pass https://github.com/status-im/nim-quic/pull/41\nchore: add initial logging https://github.com/status-im/nim-quic/pull/42\nchore: upgrade ngtcp2 to 1.6.0 https://github.com/status-im/nim-ngtcp2/pull/6\n\n\n\nvac:tke: §\n\nadmin\n\n2 + 5 + 1 CC days off\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nran simulations and analyze results related to the wealth concentration (Frederico)\n\n\nstatus:L2-deployment\n\nanalysed the SNT token utility (Frederico)\nstarted rewriting the GMX/veSNT model with the newest constraints (Frederico)\ncontinued research on cow swap, finally cor enough data and context to tell a story (Juan)\nMet with Agata to discuss legal aspect of swap aggregator; need to discuss paraswap with broader team (Juan)\nlight catch up on catsfishing (Juan)\n\n\n\nvac:dst: §\n\nadmin/misc\n\n2 + 4 CC days off\ncatch up last week conversations\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nStarted discv5 analysis and simulations\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nRun and test nimlibp2p v1.4.0\n\n\nvac:dst:tooling:vac:visualizer-tool\n\nNew “DST Visualiser”/NodeJS Visualiser tool for realtime visualisation\n\nused for Waku marketing\n\n\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\nretested bug fixes and removed xfailed tests for fixed bugs(@Florin)\nfix connection error message(@Florin)\nadd peer store capacity to go-waku start flags(@Florin)\nchore: refactor setup relay node for sharding(@Roman)\nPR 48 - merged\nTest/peer exchange(@Roman)\nPR 51 - in progress\n\n\nwaku:test-automation-status-go-cli\n\ndiscussions on the community actions PR regarding how to make the tests create less data(@Florin)\n\n\nvac:test-automation-nim-libp2p\n\nstart creating test plan for YAMUX(@Florin)\n\n\nwaku:test-automation-rln\n\nRun simulations(@Alex)\nDebugged a missmatch between expected sent messages vs actual received messages(@Alex)\n\nRoot cause: Injection script (Simulation tool). Explains a lot of issues I had.\nIssue: Reported by Tanya a couple days prior without me knowing\n\n\n\n\nadmin/misc\n\nOOO 1 + 1 CC Day\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\ntest(rln-relay): aggressive polling for networks with short block times\nfix(rln_keystore_generator): improve error handling for unrecoverable failure\nassistance with deploying rlnv2 fork on waku.test fleet\n\n\nstealth-address-kit:vac:maintenance\n\nchore: deduplicate ffi types generated per elliptic curve by using a prelude for the ffi module\nchore: add Makefile targets to generate bindings for foreign languages (C, Nim), some other trivial Makefile changes\n\n\nsecure-channels:waku:mls-poc\n\nIntegrated smart contract into project PR\nStarted to work with CLI interface for demo: open PR\nfeat: initial implementation of smart contract for de-mls\nchore: add anvil to de-mls for prototyping\nchore: deploy contracts with broadcast modifier\nchore: add Makefile target to run full example e2e\ngeneral debugging\nreview of the repo before demo @ ethcc\n\n\nadmin/misc\n\nupdated acz milestones\nadmin work for CCs traveling to brussels (ethcc).\nFirst review cycle retro with Ekaterina\n\n\n\nvac:sc:: §\n\ncodex::contracts-formal-verification\n\ntalked with the Certora team and we found a bug in their prover and they are fixing it\nthey also helped with some changes in the setup and we are waiting for a PR from them\nPRs updating our foundry template\n\nhttps://github.com/vacp2p/foundry-template/pull/29\nhttps://github.com/vacp2p/foundry-template/pull/30\n\n\n\n\nstatus:staking-contracts-v1\n\nResearch & dev on MP estimation\n\n\n\nvac:nim: §\n\ntooling:vac:nimble\n\nImproves nim installation by using csources (same as atlas)\n(https://github.com/nim-lang/nimble/pull/1233)\nIssues:\n\nRemove nimble from nim compilation Fixes #1175 (above)\nnimble -v may bootstrap Nim compiler from sources #1232\n(https://github.com/nim-lang/nimble/issues/1232)\nhelp should not download package list on a clean setup #1227\n(https://github.com/nim-lang/nimble/issues/1227)\nFix https://github.com/nim-lang/nimble/pull/1234\n\n\nAdds a test that verifies that the required Nim is the one used by nimble when compiling and running the package\nhttps://github.com/nim-lang/nimble/pull/1235\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nreading for codex vaildator rfc, started first draft\n\n\nadmin/misc\n\nchanges to 1/COSS - https://github.com/vacp2p/rfc-index/pull/4\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nLooked into blogposts from probelabs: duplicates in gossipsub and mesh dynamicity\nFollowed libp2p spec meeting, and tried following open PR related to gossipsub 1.3.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nWorked on understanding testground simulator; required learning docker.\nFound a ping test plan for nim-libp2p.\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued work on Anonymized GossipSub Transport Protocol (AGP) specification. Specifically, mixnode setup section, finished peer ID and key generation, key management, key rotation and libp2p host configuration for a dedicated mix context, and completed outline for the mixnet protocol.\nWorked on a peer discovery mechanism using Discv5.\n\nExamined Sphinx packet construction and a Golang implementation.\n\n\n\n\nzk:codex:zk-consulting\n\nWork on a document that provides more details to Codex’s Dynamic Storage Proposal\nWorked on updatable rows proof, and considered repeated data issue.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nWork on the document of Execution Types as part of our Q2 Milestones:\n\nHandeled Marvin’s questions and feedback about state separation [Moudy]\n\n\nWork on the document of Cryptographic Infrastructure and Nullification Strategy as part of our Q2 Milestones:\n\nReviewed and added some specific topics [Moudy]\n\n\nWorked on the missing components and started prioritizing some of them [Moudy]\nPrepare document comparing Nescience to other privacy zkVMs [Marvin] [DR]\nReviewed and provided feedback on Execution Types document [Marvin] [DR]\nExtracting the missing components for State-separation and add them into a notion page [Ugur] [ACZ]\nDiscussed with Moudy and choose the two bullets from the missing components list namely, key management & addresses and Nullifiers [Ugur] [ACZ]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nWent through materials on ring signatures provided by Marvin and through CCS repos [Rostyslav]\nStarted going through MPC materials prepared by Marvin [Rostyslav]\nStaring going through materials on ring signatures provided by Marvin [Rostyslav]\nProvided Rostyslav some additional information on MPCs [Marvin][DR]\nReviewed SP1, Nexus, Risc0 and zkMIPS for scoring [Oleksandr]\n\n\nReviewed the list of comparison between existing ZkVMs and Nescience and added some specific details [Moudy]\nDiscussed with Rostyslav and Oleksandr about how to proceed for implementing primitives and what to focus on for scoring [Moudy]\n\n\n"},"vac/updates/2024-07-15":{"title":"2024-07-15 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/15 §\nvac:p2p: §\nLast week:\n\nnimlibp2p:vac:maintenance\n\nchore: enable Nim 2.0.x and fix compilation issues\nfix: support ipv6 dual stack\nchore: update os images on ci\ngcc 14 support\n\n\nnimlibp2p:vac:quic\n\nQuic Transport\n\n\n\nvac:tke: §\n\nadmin:\n\nETHcc (Juan)\n5 CC days off\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nfixed a bug in the wealth concentration code (Frederico)\nran again all simulations and analyze all results related to the wealth concentration (Frederico)\nstarted developing the code to analyse the selfish behavior when choosing the fork rule (Frederico)\n\n\nwaku:general-incentives\n\nanalysed the current RLN incentivization proposal (Frederico)\n\n\nstatus:L2-deployment\n\nanalysed and expanded the SNT token utility (Frederico)\ncontinued rewriting the GMX/veSNT model with the newest constraints (Frederico)\ndiscussed the current demands of the cats fishing project (Frederico & Juan)\nFinalised analysis on CoWSwap (Juan)\n\n\ncodex:testnet-incentive\n\ndiscussed the testnet incentives with the Codex team (Frederico & Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:10k\n\nInstall and configure VictoriaMetrics\n3x 10k simulations\n\nStill running into OOM issues\nGot to 9000 nodes at one point accounted for\nStill needs tuning\n\n\n\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nAnalyse behaviour and bandwidth usage of discv5 when establishing/stabilising mesh\nDiscussed discv5 logging with Gabriel\nMeasure time-to-stable-mesh with different numbers of nodes.\nFound an issue with relay connections.\nLots of simulations and deployments to get VictoriaMetrics implemented and stable\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\ninvestigated interop failures(@Florin)\nupdate interop tests to use cluster_id != 0(@Florin)\nTest/peer exchange - PR 51 - merged(@Roman)\nfix: cluster_id 0 for peer store related tests - PR 56 - in progress(@Roman)\n\n\nwaku:test-automation-status-go-cli\n\nimplement community reuse and merge PR(@Florin)\n\n\nvac:test-automation-nim-libp2p\n\ncreated test plan for YAMUX(@Florin)\nGot familiar with existing tests(@Roman)\nGenerated actual coverage report for Yamux(@Roman)\nTest 2.0.6 compilation fixes(@Alex)\nFinish Cleanup CI PR(@Alex)\n\n\nwaku:test-automation-rln\n\nMeeting with Tanya to solve reproducibility issues(@Alex)\nRan simulations to debug Tanya’s found bugs(@Alex)\n\nFound behaviour differs between computers.\nMetrics bug\n\n\nRan simulations to try to isolate Tanya’s bug’s variables(@Alex)\n\n\nadmin/misc\n\nreview challenges and interview QA Candidates(@Florin)\nstart creating slides for QA presentation(@Florin)\nOOO 1 CC Day\n\n\n\nvac:acz: §\n\nadmin/misc\n\n3 CCs at ethcc\n1 CC ooo full week\n\n\n\nvac:sc:: §\n\nadmin/misc\n\n5 CC days ooo\n\n\ncodex::contracts-formal-verification\n\nintegrated changes from the Certora team\nfixed foundry template PRs\n\n\nstatus:staking-contracts-v1\n\ncont’ reseach on MP estimation\n\n\n\nvac:nim: §\n\ntooling:vac:editor\n\nImplement notification panel in the extension: https://github.com/nim-lang/vscode-nim/pull/72\nPrepare release (to be sync up with Nims) https://github.com/nim-lang/vscode-nim/pull/73\n\n\ntooling:vac:nimble\n\nFix an issue with the CI and win https://github.com/nim-lang/nimble/pull/1\n\n\n\nvac:rfc: §\n\nadmin/misc\n\n@ ethcc\n\n\n\nvac:dr: §\n\nadmin/misc\n\nFinish rlog for Bloom filters and Cuckoo filters\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued work on Anonymized GossipSub Protocol (AGP) specification. Specifically, details of the custom mixnet protocol [WiP], and encode next hop and delays into beta.\nLooked into the Sphinx implementation in Go.\nLooked into the overall implementation and algorithm design choices.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nLooked into testground documentation and example test plans in more detail. Currently, issues with extended delays and occasional failure reports the test ground daemon.\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nProvide feedback on gossipsub rlog\n\n\nzk:codex:zk-consulting\nExamined proof of replication, and discussion whether this is relevant for software level.\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nWorked on execution types and completed private and shielded executions. [Moudy]\nGave a structure to the blogpost. [Moudy]\nSelected some components to focus on. [Moudy]\nReviewed and added some specific topics to the document of Cryptographic Infrastructure and Nullification Strategy as part of our Q2 Milestones. [Moudy]\nProvided feedback on Cryptographic Infrastructure and Nullifications document. [Marvin][DR]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nWent through MPC materials [Rostyslav]\nReviewed scuttlebutt repo [Rostyslav]\nRead about Power of Tau ceremony paper [Rostyslav]\nReviewed powersoftau repo [Rostyslav]\nReviewed all of the zkVM’s in the list [Oleksandr]\nProvide Rostyslav with partial homomorphic resources. [Marvin][DR]\nAdd supplemental resources for primitives to Primitives Document. [Marvin][DR]\n\n\n\n\n"},"vac/updates/2024-07-22":{"title":"2024-07-22 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/22 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nready to review: https://github.com/vacp2p/nim-webrtc/pull/10\nPR for testing + fixing: https://github.com/vacp2p/nim-webrtc/pull/16\nmbedtls : fix missing import (only on windows)\nfix windows library linking\nfix nim-devel error on the stack (value not stored)\nfix macos error with asynchronous closing stun\n\n\nnimlibp2p:vac:maintenance\n\ngcc 14 support - https://github.com/status-im/nim-bearssl/pull/62\nadd ubuntu 24 and gcc 14 - https://github.com/status-im/nim-chronos/pull/553\n\n\n\nvac:tke: §\n\nadmin\n\nWorking towards ETHcc report (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nunderstood the cryptoeconomic perspective of PoW for Executors (Frederico)\ncontinued developing the code to analyse the selfish behavior when choosing the fork rule (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed the work about CoW swap (Frederico)\nunderstood how fishs are modeled in the Cats Fishing project (Frederico)\nFinalised CoWSwap comparisson work and simulations (Juan)\nWrote a presentation for the CowSwap comparison (Juan)\nDiscussed legal aspects of sucha model (Juan)\nWorked on CatsFishing (Juan)\ncatch up on current state (Martin)\n\n\ncodex:testnet-incentive\n\nreviewed discussion with Codex team and mapped out next steps (Frederico)\n\n\nwaku:general-incentives\n\ncatch up on current state (Martin)\n\n\ncodex:cdx\n\nMinor work on simulations (J\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nDiscussions with Hanno about what to check in DiscV5\nAdd parsing code for VictoriaMetrics compatibility\nWhile measuring reliability, found three separate issues:\n\nProblems with logging. Missing messages were not logging because of REST (fixed)\nProblem with duplicated hash messages (TODO)\nProblem with missing messages\n\n\nRun simulations for Waku v0.31\n\nhttps://www.notion.so/2039-78aeac4f220a49ea97e780b7bb60c412\n\nIssue still present: https://github.com/waku-org/nwaku/issues/2892\n\n\nComments can be found here\n\n\nInvestigated network issues reported that affected even very small deployments\n\nUnable to reproduce, but switches were rebooted between report and tests\n\n\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nContinue metrics scaling + VictoriaMetrics fixes\n10K report - multiple simulations to prepare for it\n\n10k being reliably reached, metrics still choking\n\n\n\n\nvac:dst:tooling:vac:visualiser-tool\n\nMeeting (Alberto x Wings) to discuss Visualiser split and show each other the tools created\n\n“DST Visualiser” (nodejs/react) to be used for live analysis\n“Debug Visualiser” (python3) to be for more extensive post-simulation analysis/“playback”\n\n\nTesting visualiser on a 10K swarm\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\nfix light push failures(@Florin)\nadjust tests to new rate limits(@Florin)\nfix: cluster_id 0 for peer store related tests.PR 56 - merged(@Roman)\n\n\nvac:test-automation-nim-libp2p\n\nstarted creating test plan for Gossipsub(@Florin)\n\n\nwaku:test-automation-status-go-cli\n\ndiscussions with waku and status team regarding future work(@Florin)\n\n\nnomos:test-automation-cryptarchia\n\nchore: Da full replication unit tests update\nPR 675 - in review(@Roman)\nchore: Da kzgrs unit tests update\nPR 676 - in progress(@Roman)\n\n\nvac:test-automation-nim-libp2p\n\nUpdate CI Cleanup PR with suggestions(@Alex)\n\n\nwaku:test-automation-rln\n\nFix coverage and run(@Alex)\nRun simulations to give more data for these issues(@Alex)\n\nbug: restarting compose fails loading keystore\nPossible memory consumption issue\n\n\nUpdate MAX_MESSAGE_LIMIT README PR(@Alex)\n\n\nadmin/misc\n\ncreated slides for QA presentation(@Florin)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nInvestigated and found root cause of invalid messages in nwaku & spam messages in nwaku, discussing with team for mitigation\n\n\nsecure-channels:waku:mls-poc\n\nPreparing the inclusion of the on-chain component in the RFC: reading the repos and figuring out the architecture.\nResearch on finality times on different L2s for onchain component.\nFinished work with CLI integration and merged PR\nMerged small fix regarding getting own message PR\nCreated a demo of using cli video link\nStarted fixing the functionality regarding the smart contract and local cache - adding multiple keys during registration, remove unused functionality open PR\n\n\nzerokit:vac:maintenance\n\nstarted a discussion about improving zkey processing time by switching to preprocessing (more details in discord thread)\n\n\nadmin/misc\n\nSubmission of proposal for delivering a talk in Devcon Bangkok. Same presentation as for EthCC Brussels but including latest advances.\nCCs getting tickets for devcon\nUpdate the ethcc notes (for full doc in notion)\n\n\n\nvac:sc:: §\n\ncodex::contracts-formal-verification\n\nmerge certora PR + cleanup and rebase to make PR ready\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/113\n\n\nHad kick-off meeting with Certora and Codex to get Marketplace contracts formally verified\n\nWaiting for certora to provide first properties to work on\nNext session we’ll discuss list of properties to work on after that\n\n\n\n\nstatus:staking-contracts-v1\n\nHad a couple of pair programming sessions with Ricardo to tackle MP estimation\n\nFew problems we ran into:\n\nPrecision loss results in wrong calculation\nEpochs beyond limit epoch generate wrong pending MP estimations\n\n\nCreated a fuzz test that demos the issue\n\nhttps://github.com/logos-co/staking/commit/60d80bf4b2cf0fd14e9de70bc39c31c42b0a4e34#diff-2561530a5f24910605d8693b034e64a26a98817f46fd17ae12004dab5c943bfdR688-R718\n\n\nWould like to learn how to turn that fuzz test into a Certora rule\n\n\nMeeting with Status Chain and TKE\n\nDiscussed high level goals\nSome details about staking protocol still unclear\nConsidering moving MP calculation out of staking entirely and do it offchain (as XP)\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:lsp\n\nResearch the correct approach to refactor the lsp so changes as small as possible.\nMost things are figured but we still need to find the best way to support stdio.\nSmall changes needed to json_rpc so we can use it for the lsp\nhttps://github.com/status-im/nim-json-rpc/pull/222\nBump lsp so it can be released\nhttps://github.com/nim-lang/langserver/pull/219\n\n\ntooling:vac:nimble\n\nFixed a regression introduced by wrongly taggin a Nim release: https://github.com/nim-lang/nimble/pull/1245\nImprove test on Nim versioning https://github.com/nim-lang/nimble/pull/1235\n\n\ntooling:vac:editor\n\nFix Nim version and improve coloring of the notifications:\nhttps://github.com/nim-lang/vscode-nim/pull/75\n\n\n\nvac:rfc: §\n\nnomos:specs-init\n\nMade some changes to DA rfc, still need to revisit - https://github.com/vacp2p/rfc-index/pull/41\n\n\ncodex:specs-init\n\nwas able to work on Codex validator rfc, still in draft - https://github.com/vacp2p/rfc-index/pull/83\n\n\n\nvac:dr: §\n\nvac/admin\n\nAdded section on filters in RLN to the Bloom Filter rlog; rlog posted.\nWorked on Fiat-Shamir rlog.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nContinued worked on testground simulator. Specifically, developed understanding about writing test plans, and run/play with different example test plans (from other libp2p implementations).\n\n\nvac:dr:anon:vac:gossipsub-anonymity\n\nContinued working on Anonymized GossipSub Protocol (AGP) specification. Specifically, completed the implementation details of the custom mixnet protocol, extend Sphinx to support address + destination of combined size tk, recommend appropriate cryptographic algorithms, made some changes to the approach followed in Sphinx Go implementation, to improve performance.\nBegin to implement Sphinx library in Go.\n\n\nzk:codex:zk-consulting\n\nBegan notes on Testudo.\nProvide feedback on proof of replication\nContinued work on document for Codex’s storage proof.\n\n\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nFinished working on execution types covering the 3 different types (Private, Shielded, Deshielded) [Moudy]\nWorked on different components for the state separation Blogpost. [Moudy]\nReviewed key management and lists of primitives from Ugur and Marvin. [Moudy]\nCreate a doc for cryptographic primitives inside and ouside of the kernel circuits in notion. [Ugur + Moudy][ACZ]\nExpand the missing components for State-Separation file in notion. [Ugur + Moudy][ACZ]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nContinued going through partial homomorphic encryption schemes’ materials [Rostyslav]\nReviewed elgamal-encryption, rsa-algorithm repo [Rostyslav]\nInvestingated workaround to use Rust code for Valida [Oleksandr]\nWork on cryptographic primitives list needed to be added for zkVMs. [Marvin][DR]\n\n\n\n\n"},"vac/updates/2024-07-29":{"title":"2024-07-29 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/07/29 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nhttps://github.com/vacp2p/nim-webrtc/pull/11\nChange files architecture similarly to others WebRTC PRs\nMake different changes in anticipation of Diego’s future comments\nSolve TODOs\nAdapt SCTP closing to DTLS change\nFix examples\n\n\nnimlibp2p:vac:maintenance\n\nFinish CI Cleanup PR\nDouble check gcc14 support\nCheck failing Windows test, locally it passes\nCheck failing interop test\n\n\n\nvac:tke: §\n\nadmin:\n\n1 CC day off (Frederico)\nWorked on ETHcc report (Juan)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\nadvanced reports of studies 1 and 2 of the wealth concentration (Frederico)\nreviewed the state of the whole Nomos project (Frederico)\n\n\nstatus:L2-deployment\n\nreviewed the state of the SN (Frederico)\nreviewed the state of Cats Fishing project (Frederico)\nassisting defining the incentive structures (Martin)\nworking towards a minimal economy formalization for cats fishing (Martin)\nworking towards a minimal economy formalization for cats fishing (Juan)\n\nDocument on monetisation for the game\n\n\nRecorded swap agregator status document (Juan)\n\n\nstatus:SNT-staking\n\nidentifying functional overlap with the need of the L2 incentive structure (Martin)\n\n\ncodex:cdx\n\nreviewed the simulation code (Frederico)\nworking on simulation code (Juan)\n\n\ncodex:testnet-incentive\n\nreviewing latest progress, identifying missing pieces (Martin)\n\n\nwaku:general-incentives\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale:\n\nContinue work with Gabriel re: stuck node bug\n\n~150 simulations performed with different versions to hunt down bug\n\nWas able to reproduce the bug\nAll signs point to nim-chronos/chronicles.\n\n\n\n\nFound issue with publisher\nRedeployed VictoriaLogs to fix issues with Midscale logging\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nRedeployed and tuned VictoriaMetrics for 10K simulation scale\n\nAbout 7 changes discovered, primarily to do with resource allocation\n\n\nVarious 10K simulations to gather data/test stability\n\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nCall with Ben from Codex to ensure testnet deployment works\n\nStill hitting permissions bugs\n\n\n\n\nadmin/misc\n\nProvided TKE team with a dedicated fileshare + password protected frontend\n\n\n\nvac:qa: §\n\nwaku:test-automation-status-go-cli\n\nadded hybernate tests(@Florin)\nfixed management of big log files(@Florin)\nmake tests more stable(@Florin)\n\n\nwaku:interop-testing-02\n\nadjust store propagation delay(@Florin)\nIssue 2837 - closed - RLNv2 registration works(@Roman)\n\n\nvac:test-automation-nim-libp2p\n\nstarted creating test plan for PubSub(@Florin)\nFinish CI Cleanup PR(@Alex)\nDouble check gcc14 support(@Alex)\nCheck failing Windows test, locally it passes(@Alex)\nCheck failing interop test(@Alex)\n\n\nnomos:test-automation-data-availability\n\nchore: Da full replication unit tests update(@Roman)\nPR 675 - merged\nchore: Da kzgrs unit tests update(@Roman)\nPR 676 - in progress ~70%\n\n\nwaku:test-automation-rln\n\nFix gcc14 support, but gabriel beat me to the PR (@Alex)\nBring RLN PR up to date and fix tests(@Alex)\n\nFound couple flaky tests, I think, need further checking\n\n\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nFixed an issue in an nwaku PR to validate user message limit\nattempted to finish deprecating the tree sync strategy, discovered a blocker in upstream library\n\n\nsecure-channels:waku:mls-poc\n\nPreparation of notes regarding the onchain component of the RFC.\nReview of smart contract\nMerged PR about fixing the functionality regarding the smart contract and local cache - adding multiple keys during registration, remove unused functionality.\nDiscussion on discord about on-chain component\nStarted integration new on-chain api with current code (will open PR on this week)\nchore(sc_keystore): add Ownable to the contracts for access control\nfix(makefile): account for change in run function signature\nchore(bindings): regenerate contract bindings\nchore(contract): remove keypackage refs, regen bindings\n\n\nzerokit:vac:maintenance\n\nAnalysed current code in case of data serialization result in discord\nAdd small benchmark for different solution: benchmarks\n\n\nconsulting:codex:proxy-re-encryption\n\nReview of a proposal by Balasz with potential interest.\n\n\nadmin/misc\n\nscoped out next release of zerokit, v0.6.0\n\n\n\nvac:sc:: §\n\nstatus:staking-contracts-v1\n\nCreated explainer videos about staking protocol, it’s implementation and challenges we’re solving\nMet with Status Chain + TKE to discuss path forward\n\nConsidering dropping XP/MP compounding in staking protocol and simplifying it\nXP program and next staking version still to be finalized\n\n\n\n\ncodex::contracts-formal-verification\n\nHad a call with certora to discuss first application properties for us to implement\n\nDocument can be found here\n\nhttps://www.notion.so/Certora-Application-Properties-V2-b93f70fbaa0744a785460413f37afa6a\n\n\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:nimble\n\nBump and auto detect version: https://github.com/nim-lang/nimble/pull/1247\nTroubleshooting release issues\nRelease: https://github.com/nim-lang/nimble/releases/tag/v0.16.0\n\n\ntooling:vac:editor\n\nRelease https://github.com/nim-lang/vscode-nim/releases/tag/v1.0.0\nTroubleshooting release issues\n\n\ntooling:vac:lsp\n\nRefactor in preparation to chronos migration: https://github.com/nim-lang/langserver/pull/222\nTroubleshooting release issues\n\n\n\nvac:rfc: §\n\nadmin/misc\n\nooo\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:gossipsub-simulation\n\nWas able to compile nim-testground-sdk and run basic ping tests. Some manually selected commit dependencies to avoid compilation failures of newest commits.\nWas able to integrate simulation script with sdk, and install nim-libp2p (commit dating to staggered sending) along with other dependencies (manually). Still facing a few compilation errors (expecting to fix these errors in a couple of days).\n\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nLooked into the possibility of handling large message counts in gossipsub. Required looking into some abstract details about farcaster network.\n\n\nzk:codex:zk-consulting\nFinished notes on Testudo.\nContinued work on document for Codex’s storage proof.\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\n\n\nWorked and expanded different components of state separation (executions, addresses, keys, nullification) [Moudy]\n\n\nMake progress with the blogpost [Moudy]\nAssisted with keys and addresses. [Moudy + Marvin + Ugur] [DR][ACZ]\n\nExamine how Ola/zcash keys system works: Ola1, Ola2, and zcash technical specs.\nDiscussed potential modifications to streamline this approach for Nescience, and possible concrete choices to be made.\n\n\nAssisted with lifecycles of UTXOs; provided answers to various questions. [Moudy + Marvin + Ugur] [DR][ACZ]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nWent through partial homomorphic encryption schemes’ materials. [Rostyslav]\nSet up SP1, RISC0. [Rostyslav]\nContinue looking for suitable repos + testing the base case. [Rostyslav]\nRead RISC0’s Poseidon254 implementation. [Oleksandr]\nRead Reinforced Concrete whitepaper. [Oleksandr]\nSet up Valida, zkMIPS, zkWASM. [Oleksandr]\n\n\n\n\n"},"vac/updates/2024-08-05":{"title":"2024-08-05 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/08/05 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDTLS: address Diego’s comments https://github.com/vacp2p/nim-webrtc/pull/10\n\n\nnimlibp2p:vac:maintenance\n\nDiscuss with Ivan about https://github.com/vacp2p/nim-libp2p/pull/1155\nReview PRs\n\n\nnimlibp2p:vac:maintenance\n\nfix: add gcc 14 support\nfix(ci): windows-amd64 (Nim version-1-6)\nfix(test): interop transport\nreviewing PRs\nCI Cleanup - PR\n\nUpdate with windows fix, now tests pass (except interop, which is not yet merged, but currently not required)\nRollback ubuntu-24.04 on i386, errors out\nDiscovered another flaky - Logs\n\n\nFix windows issue - PR\n\nInvestigate thoroughly. Quite sure it’s a Nimble issue, later today I’ll post an issue on their github.\n\n\n\n\nnimlibp2p:vac:quic\n\nevaluating quic implementations - https://github.com/cloudflare/quiche\n\n\n\nvac:tke: §\n\nadmin:\n\n1 CC day off (Frederico)\nFinalized first draft of strategy doc (Juan)\nupdated the TKE milestones (Status Network, Frederico)\n\n\nnomos:cryptarchia-wealth-concentration-known-stake\n\ncontinued writing the reports of studies 1 and 2 of the wealth concentration (Frederico)\nReviewed and provided feedback to Frederico’s work here (Juan)\n\n\nstatus:L2-deployment\n\nmodeled the location of fishes (Frederico)\nassisting defining the incentive structures, revising new proposed XP system (Martin)\nworking towards a minimal economy formalization for cats fishing based on feedback from Ned (Martin)\nMeeting with Ned, worked towards monetization document (Juan)\nFinished work on NPV analysis for swap aggregator (Juan)\n\n\nstatus:SNT-staking\n\nidentifying functional overlap with the need of the L2 incentive structure - again with the new XP proposal (Martin)\n\n\nwaku:general-incentives\n\npreparing for the call next week, identifying discussion points and actionable items (Martin)\n\n\ncodex:cdx\n\ncleaned up code (Juan)\n\n\n\nvac:dst: §\n\nvac:dst:deployment-and-analysis:codex:testnet\n\nAttempt to fix Codex Kubernetes access\n\n\nvac:dst:deployment-and-analysis:waku:10k\n\nTest runs of 10K on latest Waku\nContinued metrics instability around 10k\n\n\nvac:dst:deployment-and-analysis:waku:midscale:\n\nRefactor log analysis code for Waku to use with Waku Simulator\nGet extended logs regarding future logging\n\nPotential bug in nimlibp2p’s yamux protocol\nmplex looks more promising\n\n\nExtended libp2p report\n\nAdd 1.1 results with other sizes than 500KB\nhttps://www.notion.so/Nim-libp2p-v1-3-0-regression-testing-June-2024-7e6fa14c829d4660be6739817e07956f\n\n\n\n\nadmin/misc\n\nPrepare DST presentation for Waku team\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\nupdate CI to use images from docker hub(@Florin)\nchore: RLNv2 tests update(@Roman)\nPR 62 - in progress - Lightpush remaining to test\n\nIssue 2946 - open\nIssue 2949 - open\n\n\n\n\nvac:test-automation-nim-libp2p\n\ncreated test plan for PubSub(@Florin)\ncreated test plan for FloodSub(@Florin)\nCI Cleanup - PR(@Alex)\n\nUpdate with windows fix, now tests pass (except interop, which is not yet merged, but currently not required)\nRollback ubuntu-24.04 on i386, errors out\nDiscovered another flaky - Logs\n\n\nFix windows issue - PR(@Alex)\n\nInvestigate thoroughly. Quite sure it’s a Nimble issue, later today I’ll post an issue on their github.\n\n\nBegin checking interop issue(@Alex)\n\n\nnomos:test-automation-data-availability\n\nchore: DA kzgrs unit tests update(@Roman)\nPR 676 - in review - kzgrs-backend will undergo rewrite for the next 2 weeks\n\n\nwaku:test-automation-rln\n\nMerge RLN PR(@Alex)\n\n\n\nvac:acz: §\n\nrlnp2p:waku:rlnv2-e2e\n\nAssisted qa team in debugging nwaku tests\nchore(keystore): verbose error message when credential is not found\n\n\nsecure-channels:waku:mls-poc\n\nImprove the notes on the onchain component of the RFC.\nSync with team on payloads and ordering of the involved steps in adding members to groups.\nIntegration with new on-chain api branch\nfix(contract): convert to acl\n\n\nconsulting:codex:proxy-re-encryption\n\nFinish reading the proposal.\n\n\nanon:vac:gossipsub-anonymity\n\nTeam reviewed rfc and relevant protocols\n\n\n\nvac:sc:: §\n\nstatus:staking-contracts-v1\n\nfixed estimation of multiplier points (still needs tests)\nStill have to keep in mind that Status Chain decides against such a path\n\nhttps://github.com/logos-co/staking/commit/c1f283876cb47408d4e0db3b253ad1662004ecfa\n\n\nReviewed CovNFT from Optimism to see if we can take ideas from it\n\nhttps://github.com/GovNFT/contracts/blob/b7ce6ad869a8136a36f8130577ec7d21b2f785e4/src/GovNFT.sol\n\n\nUpgraded certora-cli on CI\n\nhttps://github.com/logos-co/staking/pull/96\n\n\n\n\ncodex::contracts-formal-verification\n\nWorked on implementing CVL rule described in https://github.com/codex-storage/codex-contracts-eth/issues/132\n\nTogether with Certora we’ve concluded that it’s likely not worth it anymore because those fields aren’t used for anything (they used to be used for fuzz tests it seems)\n\n\n\n\nstatus:community-contracts-maintenance\n\nUpgraded certora-cli on CI\n\nhttps://github.com/status-im/communities-contracts/pull/63\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:nimble\n\nReturns the nim directory prioritising the one used by the project instead of the one in the installed pkg list dir: https://github.com/nim-lang/nimble/pull/1250\n\n\ntooling:vac:lsp\n\nshould not crash when the projectMapping fileRegex is set to a non existing file fixes #221 (https://github.com/nim-lang/langserver/pull/223)\n\nFixes https://github.com/nim-lang/langserver/issues/221\n\n\nMigration to LSP\n\nComplete preparation refactor https://github.com/nim-lang/langserver/pull/222\nResearch best way to combine stdio and socket\n\n\n\n\ntooling:vac:editor\n\nIssue: New version of the plugin does not work on Windows https://github.com/nim-lang/vscode-nim/issues/78\n\n\ntooling:vac:compiler\n\nbump nimble https://github.com/nim-lang/Nim/pull/23918\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nWorked on codex validator, reading updated docs. Still in draft - https://github.com/vacp2p/rfc-index/pull/83\nHad a sync meeting with codex marketplace\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nWorked on large message handling blogpost. All comments are addressed; still WIP.\nLooked into IHAVE/IWANT message processing, small messages and peer scoring function for libp2p specs meeting\n\n\nzk:codex:zk-consulting\nBegan notes on Spartan.\nRead optimization of sumcheck for use in Spartan improvements.\n\nvac:nes: §\n\nstate-separation:vac:state-separation-architecture-01\n\nMainly worked on the blogpost [Moudy]\nWorked on making keys and addresses concrete and riefly reviewed Aztec keys and addresses scheme. [Marvin][DR]\n\n\nzkvm:vac:vm-foundations\n\nWork on the lits of ZkVMs:\n\nContinued going through primitives and looking for suitable repos. [Rostyslav]\nPrepared testing for the base case for SP1 and RISC0. [Rostyslav]\nWrote simple arithmetic tests for Valida, zkMIPS, zkWASM. [Oleksandr]\n\n\nStarted working on blogpost. [Moudy]\n\n\n"},"vac/updates/2024-08-12":{"title":"2024-08-12 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2024/08/12 §\nvac:p2p: §\n\nnimlibp2p:vac:webrtc-transport\n\nDTLS: lot of fixes / changes\n\nhttps://github.com/vacp2p/nim-webrtc/pull/10\nadd trackers\nremove asyncspawn\na lot of fields are no longer exposed\nimprove comments\n\n\n\n\nnimlibp2p:vac:maintenance\n\nYamux Future leaks\n\nhttps://github.com/vacp2p/nim-libp2p/pull/1171\nhttps://discord.com/channels/864066763682218004/1270398374293667950\nFind a fix to the leak\n\n\nStart looking at the async exception tracking\n\nhttps://github.com/vacp2p/nim-libp2p/pull/1172\n\n\nfix: infinite loop when connection is aborted before being accepted\nfix(transport): tcp accept fixes\nInvestigate interop status and begin working towards solution\nBegin test plans: Implement gossipsub’s peer discovery test cases, some utility code and small refactor\n\nDraft PR\n\n\nDeeply investigate “unsub-sub backoff” test case, seemingly weird behaviour\nIssues: Rendezvous: Unsubscribed peers may be discovered - Issue\nPrepare interview and interview candidat\n\n\nnimlibp2p:vac:quic\n\ncreate a nim wrapper for cloudflare quiche\n\n\n\nvac:tke: §\nvac:dst: §\n\nvac:dst:deployment-and-analysis:waku:midscale\n\nFinish log analysis PR (ready for review)\nHelp Gabriel with mplex Future logging investigation\nRevisit message hash duplication issue\n\n\nvac:dst:deployment-and-analysis:vac:libp2p-version-testing\n\nPerformed regression analysis for nim libp2p 1.5:\n\nRepeated 100-bytes results with version 1.2\nInitial 1.5 tests\nAfter Diego’s loop fix: https://github.com/vacp2p/nim-libp2p/pull/1166\n\n\n\n\nadmin/misc\n\nWings OOO last week\nHelping Jakub remove old DST-DeepResearch infra\n\nStill in progress\n\n\nDST Presentation for Status/Waku\n\n\n\nvac:qa: §\n\nwaku:interop-testing-02\n\ncheck lighpush errors and report issue(@Florin)\nadjust tests based on the latest lightpush changes(@Florin)\nstart looking at e2e tests(@Florin)\nchore: RLNv2 tests update(@Roman)\nPR 62 - merged\n\n\nnomos:test-automation-data-availability\n\nTest plan for Data Availability(@Florin)\nchore: Da kzgrs unit tests update(@Roman)\nPR 676 - merged\n\n\nvac:test-automation-nim-libp2p\n\nPost nimbledeps issue - Issue(@Alex)\nInvestigate interop status and begin working towards solution(@Alex)\nBegin test plans: Implement gossipsub’s peer discovery test cases, some utility code and small refactor.(@Alex)\n\nDraft PR\n\n\nIssues(@Alex)\n\nRendezvous: Unsubscribed peers may be discovered - Issue\n\n\nDeeply investigate “unsub-sub backoff” test case, seemingly weird behaviour(@Alex)\nPrepare interview and interview candidate(@Alex)\n\n\n\nvac:acz: §\n\nsecure-channels:waku:mls-poc\n\nFinished a new version of the onchain component in the RFC\nReviewed and left comments onchain component doc in notion\nFinished new flow for adding members to the group, update api regarding new smart contract: PR\n\n\nconsulting:codex:proxy-re-encryption\n\nIncluded a review of the proposal to Codex’s Notion document on plausible deniability.\n\n\nrlnp2p:waku:rlnv2-e2e\n\nwip implementation of new rln contract spec\n\n\nanon:vac:gossipsub-anonymity\n\nContinued implementing the Mix protocol PoC in Nim\nImplemented manual serialization, Proof of Work (PoW), tag manager, and Sphinx packet wrapping.\n\n\nadmin/misc\n\nStarted considering a new organization for the ACZ Notion page. The idea of the new organization is to highlight the cryptographic research done (and forthcoming) in ACZ.\n1 cc ooo one day\n\n\n\nvac:sc:: §\n\nstatus:staking-contracts-v1\n\nReviewed Status chain team work, written suggestions for the project\nMeeting with Status chain\n\nOnce again talked about desired features\nConcluded that we’ll keep MP within the staking protocol as internal measurement unit\nStake SNT -> gain MP -> get XP\n\n\nReviewed work on MP estimation\n\nFixed Estimation of MPs when staking on middle of epoch (normal user case)\nFound and fixed bugs: staking too low amounts (less than 53), doubled totalStaked on estimation\nDebugged the whole estimation and MP generation code on many different cases (see debug code here)\nAlso discussed outstanding things to be done for estimation\nCreated PR as base for discussion\n\nhttps://github.com/logos-co/staking/pull/97\n\n\n\n\n\n\ncodex::contracts-formal-verification\n\nMeeting with Certora\n\nClarified some open questions about Codex\nDiscussed open questions about CVL\n\nFound a bug in the prover that will be fixed by certora\n\n\n\n\nImplemented certora rules\n\nRequest state changes\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/142\n\n\nTotal supply == sumOfBalances\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/146\n\n\nTotal sent <= total received\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/147\n\n\nProof can’t be missing when in period\n\nhttps://github.com/codex-storage/codex-contracts-eth/pull/148\n\n\n\n\n\n\n\nvac:nim: §\n\ntooling:vac:lsp\n\nChronos migration WIP: https://github.com/nim-lang/langserver/pull/225\n\n\ntooling:vac:editor\n\nFixes parameters for running nimlangserver.cmd on Windows fixes #80 #84\n\nhttps://github.com/nim-lang/vscode-nim/pull/84\n\n\nRelease https://github.com/nim-lang/vscode-nim/pull/85 https://github.com/nim-lang/vscode-nim/releases/tag/v1.0.1\n\n\ntooling:vac:compiler\n\nBump nimble https://github.com/nim-lang/Nim/pull/23918\n\n\nmisc\n\nTroubleshoot issues, review PRs\n\n\n\nvac:rfc: §\n\ncodex:specs-init\n\nWorked on codex validator rfc, after discussion will be added to marketplace rfc\nMade some changes to marketplace rfc - https://github.com/codex-storage/codex-spec/pull/1\n\n\n\nvac:dr: §\n\ngsub-scaling:vac:unstructured-p2p-improvements-survey\n\nFinalized large message handling blogpost. The revised version is ready for review\nParticipated in libp2p specs meeting. Had to go through some potential suggestions regaring IHAVE/IWANT message handling.\n\n\ngsub-scaling:vac:gossipsub-simulation\n\nFinally able to compile and run staggered message sending simulation in test ground. Had to play with nimble/sdk files to get it compiled.\n\nStill facing issues regarding network reachability. But that can be resolved (looking into other testground SDKs for network connectivity)\nStill need to be able to parse and analyze output files.\n\n\n\n\nzk:codex:zk-consulting\n\nRead Mova and began notes\nContinued notes on Spartan\nWorked on in-node aggregation\n\n\n\nvac:nes: §"},"waku/2023-milestones":{"title":"2023 Milestones","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\nLink: https://github.com/waku-org/pm/issues/92\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1929\nhttps://github.com/fryorcraken/milestone-update/\n\n\n\nEpic: Simulation with 10k nodes\n\nLink: https://github.com/waku-org/pm/issues/85\nIssues in Epic:\nhttps://github.com/vacp2p/research/issues/191\n\nEpic: PostgreSQL in service node: Further optimisations\n\nLink: https://github.com/waku-org/pm/issues/84\nIssues in Epic:\nhttps://github.com/waku-org/nwaku/issues/1894\nhttps://github.com/waku-org/nwaku/issues/1893\nhttps://github.com/waku-org/nwaku/issues/1888\nhttps://github.com/waku-org/nwaku/issues/1885\nhttps://github.com/waku-org/nwaku/issues/1842\nhttps://github.com/waku-org/nwaku/issues/1841\nhttps://github.com/waku-org/nwaku/issues/1840\nhttps://github.com/waku-org/nwaku/issues/1604\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\nLink: https://github.com/waku-org/pm/issues/87\n\nEpic: 3.4: Further memberships\n\nLink: https://github.com/waku-org/pm/issues/72\n\nEpic: 3.3: Membership for Status Communities\n\nLink: https://github.com/waku-org/pm/issues/71\n\nEpic: 3.2: Basic DoS protection in production\n\nLink: https://github.com/waku-org/pm/issues/70\nIssues in Epic:\n\nhttps://github.com/waku-org/go-waku/issues/732\nhttps://github.com/waku-org/go-waku/issues/731\nhttps://github.com/waku-org/go-waku/issues/655\n\n\n\nEpic: 1.5: Launch and dogfood integrated public Waku Network MVP\n\nLink: https://github.com/waku-org/pm/issues/68\nIssues in Epic:\n\nhttps://github.com/waku-org/research/issues/1\n\n\n\nEpic: 1.4: Sharded peer management and discovery\n\nLink: https://github.com/waku-org/pm/issues/67\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1941\nhttps://github.com/waku-org/nwaku/issues/1940\nhttps://github.com/waku-org/js-waku/issues/1505\nhttps://github.com/waku-org/js-waku/issues/1504\nhttps://github.com/waku-org/go-waku/issues/727\nhttps://github.com/waku-org/go-waku/issues/680\nhttps://github.com/waku-org/go-waku/issues/679\nhttps://github.com/waku-org/go-waku/issues/678\n\n\n\nEpic: 1.3: Node bandwidth management mechanism\n\nLink: https://github.com/waku-org/pm/issues/66\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1947\nhttps://github.com/waku-org/nwaku/issues/1946\nhttps://github.com/waku-org/nwaku/issues/1945\nhttps://github.com/waku-org/nwaku/issues/1938\nhttps://github.com/waku-org/js-waku/issues/1503\nhttps://github.com/waku-org/go-waku/issues/677\n\n\n\nEpic: 1.2: Autosharding for autoscaling\n\nLink: https://github.com/waku-org/pm/issues/65\nNo issues in Epic description.\n\nEpic: 2.3: Basic distributed Store services\n\nLink: https://github.com/waku-org/pm/issues/64\n\nEpic: 2.2: Sharded capability discovery for light protocols\n\nLink: https://github.com/waku-org/pm/issues/63\nIssues in Epic:\n\nhttps://github.com/waku-org/js-waku/issues/1506\n\n\n\nEpic: 2.1: Production testing of existing protocols\n\nLink: https://github.com/waku-org/pm/issues/49\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1950\nhttps://github.com/waku-org/nwaku/issues/1948\nhttps://github.com/waku-org/nwaku/issues/1888\nhttps://github.com/waku-org/js-waku/issues/1463\nhttps://github.com/waku-org/js-waku/issues/914\n\n\n\nEpic: Dogfood RLN in production\n\nLink: https://github.com/waku-org/pm/issues/51\nNo issues in Epic description.\n\nEpic: Open membership mechanism\n\nLink: https://github.com/waku-org/pm/issues/52\n\nEpic: RLN validation in production\n\nLink: https://github.com/waku-org/pm/issues/55\n\nEpic: Autosharding - dogfooding\n\nLink: https://github.com/waku-org/pm/issues/58\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\nLink: https://github.com/waku-org/pm/issues/90\nIssues in Epic:\n\nhttps://github.com/fryorcraken/milestone-update/\nhttps://github.com/waku-org/js-waku/issues/1589\nhttps://github.com/waku-org/js-waku/issues/1435\nhttps://github.com/waku-org/js-waku/issues/337\nhttps://github.com/waku-org/js-waku/issues/1595\nhttps://github.com/waku-org/js-waku/issues/1597\n\n\n\nEpic: Automated Release processes\n\nLink: https://github.com/waku-org/pm/issues/86\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1889\nhttps://github.com/waku-org/js-waku/issues/1543\nhttps://github.com/waku-org/waku-rust-bindings/issues/67\n\n\n\nEpic: End-to-end testing\n\nLink: https://github.com/waku-org/pm/issues/34\nIssues in Epic:\n\nhttps://notes.status.im/s/iylE6wdli#\nhttps://github.com/waku-org/go-waku/issues/608\n\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\nLink: https://github.com/waku-org/pm/issues/88\nIssues in Epic:\n\nhttps://github.com/waku-org/go-zerokit-rln/issues/5\nhttps://github.com/waku-org/go-waku/issues/732\nhttps://github.com/waku-org/nwaku/issues/2033\nhttps://github.com/fryorcraken/milestone-update/\n\n\n\nEpic: REST API service node\n\nLink: https://github.com/waku-org/pm/issues/82\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1988\nhttps://github.com/waku-org/nwaku/issues/1985\nhttps://github.com/waku-org/nwaku/issues/1910\nhttps://github.com/waku-org/nwaku/issues/1909\nhttps://github.com/waku-org/nwaku/issues/1872\nhttps://github.com/waku-org/nwaku/issues/1652\nhttps://github.com/waku-org/nwaku/issues/1214\nhttps://github.com/waku-org/nwaku/issues/1076\nhttps://github.com/waku-org/nwaku/issues/938\nhttps://github.com/waku-org/go-waku/issues/264\n\n\n\nEpic: NodeJS Library\n\nLink: https://github.com/waku-org/pm/issues/81\nIssues in Epic:\n\nhttps://github.com/waku-org/nwaku/issues/1332\n\n\n"},"waku/2024-gantt":{"title":"2024-gantt","links":[],"tags":[],"content":"Waku Roadmap 2024 Gantt Chart §\nStatus short term work only:\n\nreliability for 1:1 chat and communities\nup to 100 communities\n\nColour legend:\n\nRed: engineering work to deliver the feature.\nOther: test and telemetry work to ensure quality\n\nAnything prefixed TBC is pending confirmation of estimate with the team.\nCompletion dates are delivery of the code + dogfooding.\nIf too hard to read, try to see this fine in GitHub.\ngantt\n dateFormat YYYY-MM-DD\n axisFormat %d-%b\n weekday monday\n \n%% Milestones overview with deliverables\n section Store Service Upgrade\n Store v3-beta (msg hash): crit, milestone, after storev3-br, 0\n Store v3 (sync): crit, milestone, after storev3-r storev3-g storev3-n, 0\n DoS protection for req-res protocols: crit, milestone, after dosreqresn dosreqresj dosreqresg, 0\n PostgreSQL maintenance: crit, milestone, after pgsql, 0\n (metric) Count store messages: milestone, after count-store-msg, 0\n section Direct Message Reliability\n (testing) direct messages: milestone, after test-direct-msg, 0\n Review connection management: crit, milestone, after review-conn-mgmt-1 review-conn-mgmt-2, 0\n (tooling) filter and light push protocols: milestone, after lite-proto-tester, 0\n (telemetry) Fleet logging: milestone, after telem-fleet-logging, 0\n (telemetry) direct message reliability: milestone, after telem-d-msg-rel, 0\n Reliability Protocol for Relay: crit, milestone, after rel-relay-g rel-relay-n, 0\n Reliability Protocol for Resource-Restricted Clients: crit, milestone, after rel-reqres-g rel-reqres-j, 0\n Review MVDS usage and fail path: crit, milestone, after mvds, 0\n TBC User apps for large scale dogfooding: milestone, after user-app-gui, 0 \n section E2e reliability protocol\n (telemetry) Multicast message reliability: milestone, after telem-m-msg-rel, 0\n E2e reliability protocol PoC: milestone, crit, after e2e-rel-r, 0\n E2e reliability protocol Status integration: milestone, crit, after e2e-rel-g, 0\n section Static Sharding - dedicated shards\n (telemetry) Measure Bandwidth: milestone, after telem-bandwidth, 0\n Sharding peer mgmt and discovery hardening: crit, milestone, after sh-peer-mgmt-j sh-peer-mgmt-n sh-peer-mgmt-g, 0\n (testing) Custom shard impl of Communities: milestone, after test-custom-shard, 0\n\n%% Tasks\n section golang eng 1\n %% Estimation TBC - Prem says fine, waiting on 2nd opinion\n TBC Review connection management: crit, review-conn-mgmt-1, 2024-05-13, 8w\n Review MVDS usage and fail path: crit, mvds, after review-conn-mgmt-1, 6w\n Investigation and fixing of bugs discovered during dogfooding/usage/simulations: go-bugs-1, after mvds, 8w\n section golang eng 2\n Reliability Protocol for Relay (go): crit, rel-relay-g, 2024-05-13, 12w\n (testing) direct messages: test-direct-msg, after rel-relay-g, 4w\n TBC (testing) Custom shard impl of Communities: test-custom-shard, after test-direct-msg, 4w\n %% TBC estimate\n TBC E2e reliability protocol Status integration: crit, e2e-rel-g, after e2e-rel-r, 6w\n section golang eng 3\n Store v3 (go-waku client only): crit, storev3-g, 2024-02-26, 2024-05-24\n %% Estimate TBC - assuming parallel work possible\n TBC Review connection management: crit, review-conn-mgmt-2, after storev3-g, 8w\n Sharding peer mgmt and discovery hardening (go-waku): crit, sh-peer-mgmt-g, after review-conn-mgmt-2, 8w\n section golang eng 4\n Store v3 (sync): crit, 2024-02-08, 2024-04-26\n Reliability Protocol for Resource-Restricted Clients (go): crit, rel-reqres-g, 2024-05-13, 10w\n (metric) Count store messages: count-store-msg, after rel-reqres-g, 2w\n Investigation and fixing of bugs discovered during dogfooding/usage/simulations: go-bugs-2, after count-store-msg, 8w\n section golang eng 5\n DoS protection for req-res protocols (go-waku client only): crit, dosreqresg, 2024-05-20, 4w\n (telemetry) Multicast message reliability: telem-m-msg-rel, after dosreqresg, 4w\n section golang eng 6\n (telemetry) direct message reliability: telem-d-msg-rel, 2024-05-13, 6w\n (telemetry) Measure Bandwidth: telem-bandwidth, after telem-d-msg-rel, 8w\n section test eng 1\n Peer and connection management tests: sim-conn-mgmt, 2024-05-13, 4w\n (simulation) Functionality and stress test store v3: sim-storev3, after sim-conn-mgmt, 4w\n %% This is Store Service Upgrade - item (2) in DST simulation - start with small scale to get faster results\n (simulation) Compare store topologies: sim-store-cmp, after sim-storev3, 6w\n (simulation) relay reliability performance impact: sim-relay-rel, after sim-store-cmp sim-req-res rel-relay-g rel-relay-n, 4w\n (simulation) req-res reliability performance impact: sim-reqres-rel, after sim-relay-rel rel-reqres-g, 6w\n section research eng 1\n End-to-end reliability protocol - PoC: crit, e2e-rel-r, 2024-05-23, 20w\n section research eng 2\n %% Only dogfooding remaining\n Store v3-beta (msg hash): crit, storev3-br, 2024-01-01, 2024-05-23\n Store v3 (sync) research + RFC: crit, storev3-r, 2024-03-25, 14w\n Store v3 - follow-up: after storev3-r, 8w\n Peer mgmt - follow-up: after storev3-r, 8w\n section nim eng 1\n PostgreSQL Maintenance: crit, pgsql, 2024-01-01, 2024-07-31\n Reliability Protocol for Relay (nwaku + RFC): crit, rel-relay-n, 2024-06-19, 12w\n section nim eng 2\n DoS Protection for Req-Res Protocols: crit, dosreqresn, 2024-02-01, 18w\n (tooling) filter and light push protocols: lite-proto-tester, 2024-05-13, 2024-07-03\n Store v3-beta + v3 (dogfooding placeholder): storev3-df, after storev3-br storev3-r, 4w\n %% More hardening expected to deprecate or separate store v2 from v3 driver\n TBC Store v3-beta + v3 (nwaku hardening): crit, storev3-n, after storev3-df dosreqresn, 3w\n (telemetry) Fleet logging: telem-fleet-logging, after dosreqresn, 4w\n section nim eng 3\n Sharding peer mgmt and discovery hardening (nwaku): crit, sh-peer-mgmt-n, 2024-05-13, 12w\n section js eng 1\n Reliability for Req-Res Protocols (light client + RFC): crit, rel-reqres-j, 2024-05-01, 12w\n section js eng 2\n %% Buidling idle apps and integrating in telemetry service to learn\n Reliability for Req-Res Protocols (light client + RFC): crit, rel-reqres-j, 2024-05-01, 12w\n Sharding peer mgmt and discovery hardening (light client + RFC): crit, sh-peer-mgmt-j, 2024-06-01, 12w\n section js eng 3 (dev rel)\n %% TBC timing and estimate\n TBC User apps for large scale dogfooding - GUI and Gamification: user-app-gui, 2024-06-01, 4w\n"},"waku/2024-milestones":{"title":"2024 Milestones","links":[],"tags":[],"content":"Milestone Store Service Upgrade §\nDue Date: 2024-09-20\nWith this milestone, the store protocol becomes more easily usable for reliability purposes.\nMoreover, nwaku PostgreSQL implementation will enable better disk space management and enable operators to hard cap the used disk space.\nDeliverable: Store v3-beta - Message Hashes §\nEnable the Waku Network to provide distributed and synchronised store services.\nAn improved version of the Store protocol, marking a crucial increment towards a synchronisation protocol:\n\nintroduces the concept of deterministic message hashes to index messages\nconsiders the Store as a key-value store\nallows for querying a list of keys (message hashes) from the Store\nallows for querying for the full message content (values) of a set of keys from the Store\nkeeps all previous value-based filtering (e.g. content topic, timestamp) in place\n\nDeliverable: Store v3 - store synchronisation §\nUpgrade the Store service capability in the network from a collection of local, unsynchronised,\nsemi-centralised (trusted) service nodes to a decentralised service capability in the network with inter-node synchronisation.\nBuilding on Store v3-beta, this version of Store includes basic synchronisation between nodes. This will probably include:\n\na protocol/heuristic to resume store services after an offline period\na protocol/heuristic to periodically compare local key-value store with other nodes and find missing keys\na protocol/heuristic to periodically download the messages (values) for missing keys from other store nodes\n\nDeliverable: DoS protection for req-res protocols and metrics §\nAdd local DoS protection service nodes by applying request rate limitation on non relay protocols, including store.\n\nApply some limited bandwidth limitation on service protocols\nProvide failsafe mechanisms to third party apps / client side help for request rejection mechanisms\n\nDeliverable: PostgreSQL Maintenance §\nProvide a solution on how to best handle PostgreSQL database growth and pruning, so that node operators can predict database size and avoid disruptions due to full disk space.\nDeliverable: Metric: Count store messages §\nMessage-finder is used to compare the number of Status messages across Status nodes to understand the potential discrepancies and odd behaviour of messages being inserted in the past in a given channel.\nThis deliverable captures the message count on all Waku fleets to use as a metrics of the efficacy of store sync.\nMilestone Direct Message Reliability §\nDue Date: 2024-09-02\nWith this milestone, connectivity issues in Status Mobile and Desktop are solved and tested.\nUsage of store v3-beta casts a wide net on potential message loss, at the cost of bandwidth overhead (but still lower than current usage of storev2).\nReview of MVDS usage for all direct messages is done to ensure that critical messages (request to join, contact request, 1:1 messages, private group) are delivered.\nDeliverable: Enable testing of direct messages §\nProduce a CLI that enables black-box testing of the Waku integration in status-go. Focus should be on direct messages, including peer management and strategies when network connectivity is lost. This is to enable (1) of the Vac/QA dependencies. Note the CLI should sit under the Status Communities logic layer and focus on message delivery.\nDirect messages are used for critical chat features: contact request, community join request and response, 1:1 chat and private group.\nCurrently, if the connection is dropped, the recovery strategies implemented in status-go often fail.\nThe Waku team would provide a set of binaries to enable Vac/QA team to setup non-regression functional test (black box/e2e) as well as Vac/DST to run simulations in unreliable environments (latency, connection drop) to ascertain the reliability of the software, before it is touched by Status QA team.\nThe API of such binaries would be defined based on the needs from the Vac/QA-DST team.\nVac QA team is not expected to proceed with an extensive testing of the Communities functionality, but instead proceed with testing of direct message sending/reception considering various potential network faults.\nDeliverable: Review connection management strategy and back-off and fix long disconnection issues §\nReview disconnection and peer management in status-go and go-waku for both relay and light client protocols.\nEnsure that broken scenarios from dogfooding and Vac/QA testing are covered. Including but not limited to desktop sleep/hibernate and failure to send messages after current backoff strategy.\nThis includes moving peer management logic from status-go to go-waku for better separation of concerns.\nDeliverable: Tooling: filter and light push protocols §\nImplement a testing telemetry tool, a.k.a. lite-protocol-tester, that can measure the reliability of light push and filter from nwaku PoV. That tool should enable injecting messages, and produce the right logging. DST’s log tracing tool can then be used to create reports. This will help us to measure the current estate and evolution of the upcoming enhancements.\nDeliverable: Telemetry: fleet logging §\nEnsure that nwaku nodes in the status fleet log messages to enable traceability on both relay and filter/light push. Also ensure that sync (store v3) does highlight missed messages and related time to enable investigation on why 2 nodes were not synced.\nDeliverable: Telemetry: direct message reliability §\nReview and ensure the telemetry service can provide accurate statistics on message reliability with a mix of online presence report, message sending and receiving.\nThe measurement should be specific to direct messages to ensure that deliverables above do improve reliability in real usage.\nThis should include content topic data, to be used for later optimization.\nFor both Desktop and Mobile. Telemetry service should also be updated to ensure it covers the disconnection scenario for itself.\nNote that from Status’ team experience, the telemetry statistics have usually been more optimistic than reality, especially when there is a full network drop (ie, no messages going out).\nDeliverable: Reliability Protocol for Relay §\nDefine a protocol that leverages store v3-beta, to improve reliability when using Waku Relay, for both delivery and reception of messages.\nThis enables a local node to ensure it has the same view of the network as its peers.\nDeciding on how store v3-beta queries should be triggered and how often should be part of the protocol specifications.\nNote this does not provide end-to-end delivery as it only permits a local node to verify that its view of the network is similar to connected peers (and not peers further away in the network).\nThe reference implementation will be done in nwaku: The API should be simple and remove the need for protocol knowledge by the developer (e.g. send/receive verbs).\nThis should also be used by the light push and filter service (as service nodes).\nA similar logic should be implemented in Golang and used in status-go. RFC and collaboration with the nwaku team is expected to ensure similar implementation in both languages.\nDeliverable: Reliability Protocol for Resource-Restricted Clients §\nDefine and implement a protocol that improves reliability in web and mobile environments.\nIn this particular instance, js-waku will be the reference implementation of the designed protocol to enable focus of the js-waku team on resource-restricted environment and of the nwaku team on relay and service node matters/usage.\nThis deliverable includes the implementation of this protocol in go-waku (nwaku excluded). Work should be done in parallel and feed from each other.\nThe intent is to compose light push, filter and store v3-beta in combination.\nDeliverable: User apps for large scale dogfooding §\nNote: new deliverable, stemmed from discussion with js-waku team who have been working on resource-restricted reliability since earlier this year. Yet to be estimated and planned.\nJustification: testing and simulations have limitations in the context of heterogeneous network behaviour. The best testing comes from the real world/network environment, with real users.\nIt is expected that not all users will enable opt-in telemetry and that there will be a delay between library improvements and roll out.\nDeliverable: Review MVDS usage and fail path §\nReview MVDS usage for direct messages and ensure that the fail path is handled correctly with either feedback on the UI or automated retries.\nMVDS protocol is already in use for some direct messages. Ensure it is the case for contact requests, join requests, 1:1 chat and private groups.\nAlso review the fail path for MVDS (are messages retried later or is there feedback/retry on the UI)?\nThe output of this is likely to include GUI change recommendations to add retry buttons or just simply retry indefinitely (for contact requests etc) in addition to some logic change (e.g. ensure the retry happens after reconnection).\nMilestone End-to-end reliability protocol §\nDue Date: 2024-09-02\nTo solve reliability is to solve two problems:\n\nHigh heuristic that messages are received and sent\nAbility to know whether messages are received or sent\n\nProblem (1) can never be 100% reliable in a network environment. The previous milestones focused on it.\nTo solve (2), is to create an end-to-end protocol, sender to recipient, that enables the ability to know whether recipient(s) have received messages.\nWith this milestone, we design and deliver a first PoC for an end-to-end reliability protocol.\nThis protocol will be specified and implemented in the Status app for Status Communities chat rooms.\nDeliverable: Telemetry: multicast message reliability §\nReview and ensure the telemetry service can provide accurate statistics on message reliability with a mix of online presence report, message sending and receiving.\nThe measurement should be specific to multicast messages to ensure that deliverables above do improve reliability in real usage.\nThis should include content topic data, to be used for later optimization.\nFor both Desktop and Mobile.\nNote that from Status’ team experience, the telemetry statistics have usually been more optimistic than reality, especially when there is a full network drop (ie, no messages going out).\nDeliverable: End-to-end reliability protocol - PoC §\nDesign a protocol that enables end-to-end reliability for Status Communities channels.\nThe output is an agnostic RFC and a reference implementation in Golang (similar to MVDS library). However, it should take in account the context of Status Communities and leverage related properties (e.g. mostly online community owner nodes).\nThis deliverable does not include the integration in status-go, but it should provide enough information to then review with the Status app team how this protocol should be used in Status Communities. Parameters such as bandwidth usage and reliability level (e.g. N% of users acks) can then be discussed with the app team before implementation, as well as the type of messages that need such functionality (e.g. status update vs chat message in channel).\nDeliverable: End-to-end reliability protocol - Status integration §\nIntegrate the previously designed protocol in status-go with parameters agreed with the Status product team. Provide the right REST API (if needed) to ensure this is tested by Vac/QA.\nHarden the library as needed.\nMilestone Static Sharding - dedicated shards §\nDue Date: 2024-09-30\nCreating a new community on its dedicated shard would be tested and working, including assigning a pre-shared key for opt-in message signing (weak DoS protection).\nCommunity creation on a default shard (32) to remain (up to app team to hide button or not) to enable mass creation of communities on shared shard for QA testing purposes.\nVac QA and DST are asked to look at Status Communities behaviour, whereas previously the focus was on direct messages reliability (one layer lower).\nFinally, telemetry service will be updated to include bandwidth usage statistics, with a fine breakdown to understand top bandwidth consumers (control msg, chat msg, etc). Additionally, the DST team is asked to run simulations with a focus on bandwidth usage.\nDeliverable: Telemetry: Measure Bandwidth §\nAdd bandwidth measurements to the self-report (opt-in) telemetry service, including a message type breakdown (ctrl, chat, etc) when possible as well as other protocols such as discovery.\nUsage of non-waku bandwidth should also be considered (bittorrent, RPC) to have a full picture in case of report of high bandwidth usage by users.\nDeliverable: Sharding peer management and discovery hardening §\nFurther testing and improvement of peer management in the context of sharding in all Waku implementations. The aim is to ensure that nodes are connected to other nodes of interested shards. As the number of shards (several communities) increase, some improvement on the logic should be needed.\n(1) nwaku and go-waku need to follow the same pattern here in terms of relay peer management. For Relay peer management:\n\nremove named sharding to simplify peer management\nreview per-shard peer management metrics (e.g. mesh health per subscribed shard)\nmonitor and adapt peer management strategy across both go-waku and nwaku for various shard subscription scenarios (e.g. up to 100 pubsub topic subscriptions) in an integrated deployment\n\n(2) go-waku and nwaku should also follow the same patterns in terms of managing filter/ligh tpush clients (i.e. always keep a predictable amount of open slots for clients) with similar steps to the above to harden the strategy\n(3) go-waku and js-waku should follow the same patterns in terms of managing service peers within clients.\n(4) Capture recommendations in an RFC and use it as a discussion and decision medium across implementations.\nDeliverable: Enable testing of custom shard implementation for Communities §\nCreate/update CLI with REST API to enable creation and usage of static communities on own dedicated shard for Vac/QA to proceed with testing of various scenarios.\nThis CLI should also enable running simulations of bandwidth usage by communities, including ctrl messages.\nThis includes the setup of a pre-shared key to protect the shard and fixing any bug reported.\nNote that the ability to create communities on a custom shard and assign a pre-shared key for DoS protection is already implemented in status-go.\nNote that telemetry service should include shard specific reports.\nMilestone Bandwidth optimization and protocol review §\nDue Date: TBD\nBandwidth measurement from the previous milestone may lead to improvement that should be tackled with this milestone. This should be done in tandem with tackling low-hanging/high value items of the Status Community protocols potential scaling problems.\nFinally, usage of content topics should be reviewed to align with Waku’s recommendation, clear migration strategy, caveat and benefits should be outlined, such as future usage of auto-sharding and reduction of topics used by a single user for more efficient use of services.\nDeliverable: Status Communities protocol scaling/bandwidth optimization recommendation §\nSome of the Status Communities protocols potential scaling problems have already been mitigated. However, further work may be needed and identified from simulations and telemetry.\nThe output of this deliverable is to compile a list of recommendations, for both Waku and Status Communities protocol. This should include potential benefits of changes and enable scheduling the work between Status and Waku teams.\nDecision on the work to be done and planning it should be part of the output of this milestone.\nThis could include review of discv5 implementation in go-waku and nwaku if bandwidth usage is excessive.\nDeliverable: Review usage of content topics in Status Chat and Communities protocol §\nThe usage of content topics in Status is aligned with Wakuv1. Waku v2 comes with a new recommended format that enables auto-sharding.\nMoreover, single Status users currently use a high number of content topics, which may have an impact on performance of req-res protocols such as store and filter.\nSuch impact is to be measured in a previous milestone by Vac DST.\nThe output of this deliverable should be an RFC update on how content topics should be used, backed with simulations when performance improvement is expected.\nIt should include migration strategy and potential impact on the product.\nMilestone Scale up number of Communities §\nDue Date: TBD\nProceed with next steps to scale up the number of communities with a focus on testing and configure rendezvous which would enable a large number of communities on their own shard, with the caveat of a more federated global topology.\nThe rendezvous nodes of a community would be a centralised infra to a community.\nAlso proceed with enhancing of the current decentralised discovery protocol to pave the way towards less centralised topology.\nDeliverable: Usage of rendezvous §\nTest libp2p rendezvous in nwaku (server) and go-waku (client) to have it ready as a replacement of discv5 to enable over 100 communities.\nThis should mainly be around configuration, testing and potential bug fixing.\nRendezvous discovery is federated-like and non-private. It is an existing libp2p protocol.\nDeliverable: DoS protection for req-res protocols and metrics (go-waku as service node) §\nReplicate the DoS protection (local rate limit) logic from nwaku to go-waku as Status Desktop do serve filter and light push node.\nIf Desktop nodes get DoS via light push/filter service, then it can be disabled, however this may compromise scalability of mobile and would involve deploying more fleet.\nAs the desktop/mobile ratio is uncertain, best to have this implemented.\nMilestone Nwaku in Status Desktop (Relay, *nix) §\nDue Date: TBD\nWith this milestone, Status Desktop builds on Linux and Mac can use nwaku instead of go-waku.\nGo-waku will still be used for Windows (Desktop) and Status Mobile.\nDeliverable: Nwaku in Golang desktop §\nProvide a Golang library that uses the nwaku bindings (relay+store API) in a desktop environment. The bindings must be usable without RLN for the context of Status Desktop application.\nDeliverable: Nwaku in Golang: Relay §\nExpose and demonstrate the usage of relay protocols/API usef on go-waku by status-go in the Golang nwaku bindings.\nBuild on the previous by adding the APIs used by status-go in relay mode. Proceed with dogfooding of said APIs in PoC app to confirm their behaviour in Golang Desktop environment.\nThis includes work to ensure that the relay reliability protocol implemented in nwaku is used and other libp2p protocols such as autonat, circuit-relay client and hole-punching.\nLight client protocols are out of scope.\nDeliverable: Nwaku in Status Desktop (Relay, *nix) §\nUse nwaku instead of go-waku in Status Desktop and produce a working and distributable special (no light client) build for Linux and Mac OS environments.\n“Light client” mode should be disabled for this build as only relay protocols are implemented.\nWindows builds are also out of scope.\nThis includes an abstraction layer to enable the other builds to still use go-waku:\n\nDesktop Windows\nDesktop “prod” (with both light client and relay modes, via go-waku)\nMobile\n\nCLIs created for Vac/QA should also be produced with nwaku to enable QA and DST to run tests/simulations.\nMilestone Scale 1:1 chat messages PoC §\nDue Date: 2024-11-30\nImproved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.\nMoving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.\nDeliverable: RLNv2 in nwaku §\nImproved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.\nMoving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.\nNote this only concerns native libraries using nwaku.\nDeliverable: Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap §\nA review of RLN security parameters and functionality in preparation for mainnet deployment.\nAnalyse RLN deployment in the Waku proto-network and evaluate its DoS protection performance as well as review with the Status app team the potential cost mode of RLN:\n\nShould staking be introduced, especially to improve resilience against adversarial membership registrations?\nShould slashing be introduced or does the existing gossipsub scoring method provide enough protection?\nWhich chain or L2 should we target for memberships?\nWhat token should be used?\nDo we need a combination of msg/sec and msg allocation/day rate limiting?\n\nDeliverable: Provision RLN for light push clients PoC §\nDesign and implement a protocol that attaches RLN proof for messages received by light push services, enabling light clients to use the network without RLN.\nWith this deliverable, nwaku nodes deployed as service nodes lend their RLN memberships to light clients. Enabling Status app to offer a free tiers usage of RLN Relay for 1:1 chat messages.\nThis is a first PoC, learnings around RLN rate limit parameters, need of multiple RLN managements and service capability are expected to drive further development.\nDeliverable: Pay for RLN provision first PoC §\nProof of concept of paying for RLN provision to a light client by a service node.\nA POC payment mechanism that incorporates PoC versions of the three Waku service marketplace elements:\n\na price offer/negotiation mechanism\na proof of payment system\na local reputation mechanism to distinguish between “good” and “bad” service nodes\n\nSuch a PoC would enable discussion with the Status app team on a potential way to provide a paid tier to 1:1 chats users."},"waku/collaboration/guidelines-for-collaboration":{"title":"Guidelines for Collaboration","links":[],"tags":["waku","collaboration"],"content":"Guidelines for Collaboration §\nVisibility Into Work and Productivity §\n\nDaily Standup The stand-up channel on the Waku Discord server is where core contributors share their daily stand up summarizing their daily planned tasks.\nWeekly Report: Every Friday, all team members must add a comment to the Epic GH issue they own and worked on the past week or planned to work on next week. See Waku project management for more.\nTrack your work with Github issues: Make sure to always have an open Github issue corresponding to your current task. Follow the following post for some insights on how to write good Github issues.\nQuality Github pull requests: Github issues are (typically) followed by one or multiple Github pull requests (PR) to address the task(s) set out in the issue. PRs should be of reasonable size and with proper documentation. All commits within the PR should be signed. Do not forget to request PR review from your peers when your PR is ready. Before merging an open PR, all commits should be rebased on master and squashed into a single commit with a semantic commit message. Use the following guides on how to make a good PR\n\nAnatomy of a perfect pull request\nHow to write a perfect pull request. This post expands on good PR documentation and communication.\n\n\nPR Reviews: Spend a portion (10-20%) of your daily work reviewing other team members’ Pull requests. This will allow a swift and smooth development process.\nSeek feedback Do not hesitate to seek feedback from the senior members of the team, especially those who work closely with you.\nCommunicate effectively: Know the team members that are relevant to your project and get their feedback and comments on your project when need be.\n\nCommunication media §\n\nBasic principle: Waku is an open-source protocols and software. We are part of a wider community. As such, your first instinct should be to communicate as openly as possible in the forum/channel most suited to your query. That said, we have channels for team-internal communications that relate to project management, team travel or other more personal conversations.\nDiscord server: it takes a while to get used to the bewildering number of channels on the Waku Discord server. Here are some guidelines to help you get started:\n\n#intros: a good place to introduce yourself to the community once you’ve joined\n#gm: a quick “good morning” when you start your day adds to a friendly environment and shows other community members that you’re online\n#stand-up: daily one-liners indicating what your focus will be for the day\n#support: general support questions related to Waku protocols or the organisation\n#nwaku-contribute, #go-waku-contribute, #js-waku-contribute: discussions related to the nim, go and JavaScript Waku v2 clients respectively\n#team-pm-private: team-internal discussions related to Waku Product project management.\nWe maintain various team-internal channels, including #afk, #watercooler, #events, and more, which facilitate sharing while we work\n\n\nExamples:\n\nYou’re getting started and have a question related to the nwaku codebase: ask away in the open #nwaku-contribute channel. Feel free to tag specific people that you think may help, but don’t be too surprised if other community members jump in with an answer.\nWhile reading a Waku RFC you have a suggestion on how to improve the protocol: ping the team on the open #support channel for general question about protocols, or #rfc if it is about phrasing or clarity in the RFC. You could also create a GH issue in the vacp2p/rfc repository.\nYou want to inform the team that you’re off sick: use the team-internal #afk channel.\n\n\n\nAutonomy and Motivation §\n\nAlignment with principles: Waku follows a set of principles as described in https://status.im/about/, a good understanding of those is vital to making a meaningful contribution to the team. Should you have any questions regarding the principles, do not hesitate to reach out to your team members for more insights and explanations.\nFamiliarize yourself with relevant tools and tech Your work involves knowledge of the basics of Git and Github e.g., creating issues, pull requests (PRs), branches, merging, rebasing, etc. Spend some time and familiarize yourself with these concepts.\n"},"waku/collaboration/nwaku-release-process":{"title":"nwaku Release Process","links":["waku/collaboration/test-nwaku-on-status"],"tags":["waku","collaboration","nwaku"],"content":"Testing week §\nOn each release, we establish a testing period of one week, when we lock the waku.test fleet so that it only runs the target version. During that period, we need to continuously stress that fleet from the sandbox machine, for example.\nIt is important to make sure the waku-simulator works as expected and the nodes can establish connections among themselves.\nDuring that week, the release owner needs to check the Kibana logs from the previous month (since the last release was deployed) looking for possible crashes or errors in waku.test & waku.sandbox. These are the most relevant logs to check:\n\n(fleet: "waku.test" OR fleet: "waku.sandbox") AND message: "SIGSEGV"\n\nMake sure that Status client works properly when connected to a fleet running on the release candidate version. For it, please follow its corresponding guide.\nRelease Calendar §\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nNameDateRelease Ownernwaku-versionwakuv2.test deployment2024-01-15SP0.24.0wakuv2.prod deployment2024-01-22SP0.24.xwakuv2.test deployment2024-02-12Zoltan0.25.0wakuv2.prod deployment2024-02-19Zoltan0.25.xwaku.test deployment2024-03-11Zoltan0.26.0waku.sandbox deployment2024-03-18Zoltan0.26.xwaku.test deployment2024-04-15Gabriel0.27.0waku.sandbox deployment2024-04-22Gabriel0.27.xwaku.test deployment2024-05-13Gabriel0.28.0waku.sandbox deployment2024-05-20Gabriel0.28.xwaku.test deployment2024-06-10Ivan0.29.0waku.sandbox deployment2024-06-17Ivan0.29.xwaku.test deployment2024-06-24Ivan0.30.0waku.sandbox deployment2024-06-26Ivan0.30.xwaku.test deployment2024-07-22Ivan0.31.0waku.sandbox deployment2024-07-24Ivan0.31.xwaku.test deployment2024-08-26Zoltan0.32.0waku.sandbox deployment2024-08-28Zoltan0.32.xwaku.test deployment2024-09-23Zoltan0.33.0waku.sandbox deployment2024-09-25Zoltan0.33.xwaku.test deployment2024-10-28Gabriel0.34.0waku.sandbox deployment2024-10-30Gabriel0.34.x"},"waku/collaboration/onboarding-guide":{"title":"Onboarding Guide","links":[],"tags":["waku","collaboration"],"content":"Onboarding guide §\nWelcome to Waku! There’s quite a lot to learn so take your time. Here are a few links and some things to start with.\nVac & Waku §\nVac is a wide team that builds public good protocols for the decentralized web - vac.\nWaku originated as an incubation project within Vac with the goal of defining and implementing decentralized communication protocols. We have since evolved into a standalone team, while maintaining close collaboration with Vac, which continues to facilitate the RFC process - waku.\nAt Waku, each team member may split their working hours between research and sw development, depending on the team goals and personal interests.\n\nResearch: describe protocols in a formal/scientific way - https://github.com/waku-org/research.\nSW development: materialization of the protocols into software components - https://github.com/waku-org.\n\nCollaboration Guideline §\nHave a read at our Collaboration Guidelines to acquaint yourself with our collaboration best practices.\nStarter tasks §\n\n\nComplete the BambooHR tasks (can be followed in parallel with other tasks.).\n\n\nTry out the Status app\n\n\nGet familiar with Nim.\nRecommendations:\n\nStatus Nim Style Guide\nNim Language\n“Nim in Action” book (Dominik Picheta)\n“Mastering Nim” book (Andreas Rumpf)\nExercism course on Nim\n“Computer Programming with the Nim Programming Language” book (Stefan Salewski)\n\n\n\nMeet the Waku specification\nWaku is a communication layer for Web3.\nThere are three main Waku-client implementations:\n\nnwaku: Nim implementation aimed to be used by the infrastructure nodes.\ngo-waku: Golang implementation aimed to be used by the Desktop app.\njs-waku: JavaScript implementation designed to be run by web browsers.\n\nAside from the Waku project, Vac also gives a big contribution in the next ones:\n\nLogos, a Blockchain protocol whose clients would be built in Nim and Rust - Logos.\nCodex, a decentralized storage protocol (IPFS) - code-research, nim-codex.\n\n\n\nBuild nwaku. We encourage all core contributors to run a long-lived nwaku node as an operator. More details here.\nUseful resources:\n\nExamples\nDocs\n\n\n\nSkim specs (primarily Vac, but also Status) and try to get a picture of how things fit together. You do not have to read all the specifications all at once (it may get a bit confusing). We suggest start reading them in the following order, it is just a suggestion, feel free to do it the way you want!:).\n\n\nWhile reading RFCs note that there are two versions of WAKU namely WAKU1 and WAKU2. Vac RFCs related to WAKU2 are WAKU2 prefixed whereas other ones are prefixed by WAKU or WAKU1. For example, 8/WAKU-MAIL and 13/WAKU2-STORE are RFCs for WAKU1 and WAKU2, respectively.\n- 1/COSS\n- 10/WAKU2\n- 16/WAKU2-RPC\n- 11/WAKU2-RELAY | 14/WAKU2-MESSAGE | 23/WAKU2-TOPICS | 26/WAKU2-PAYLOAD\n- 12/WAKU2-FILTER\n- 19/WAKU2-LIGHTPUSH\n- 13/WAKU2-STORE\n- 18/WAKU2-SWAP\n- 27/WAKU2-PEERS\n- 15/WAKU2-BRIDGE\n\nJoin the Vac, Waku, and Nimbus Discord servers and say hi!\nRecommended: go through the list of existing open issues in the project repo (nwaku, go-waku or js-waku) you’ll mostly be working on and familiarise yourself with the current state of the project. This may take a while, but is an excellent exercise to get acquainted with some important conversations and project history. We encourage new contributors to ask questions in the comment sections of any past issues. You could even self-assign some issues that’s currently unassigned which you’d like to tackle! For this, the good-first-issue tag on Github may come in as a handy filter.\n\nResources §\nVac §\n\nVac overview\nVac.dev writeups\nVac RFCs/Specs\nCOSS process\n10/WAKU2 main spec\nVac forum\nVac 2021 Q3 priorities\nWaku v2 training session\nVac Sustainability and business workshop\n\nStatus §\n\nStatus whitepaper\nStatus principles\nStatus main client spec\nStatus specs\nStatus Discuss\nNimbus team\nnim-libp2p\n\nEcosystem §\n\nEthereum\nlibp2p\nlibp2p specs\n"},"waku/collaboration/test-nwaku-on-status":{"title":"Test nwaku on Status","links":[],"tags":["waku","status","collaboration","nwaku"],"content":"This document is based on the following recorded session\nIn order to test Nwaku on Status, you need to first deploy your release candidate to the shards.staging fleet. You will also need to build status-desktop by following the instructions here.\nOnce we are able to run status-desktop locally, run\nmake run ARGS="--enable-fleet-selection --datadir=./datadir1"\nThis will open Status Desktop. Create a new account, and once logged in go to Settings->Advanced->Fleet and select shards.staging\n\nAfter selecting the fleet, Status Desktop will close and you will need to run again\nmake run ARGS="--enable-fleet-selection --datadir=./datadir1"\nLog in with the password you set previously, and check thatshards.staging is configured\n\nIn the Advanced section again, please enable the following options:\n\nFull developer mode\nDebug\nNode Management\nEnable creation of sharded communities\nEnable Community Creation\n\nSome of these options might also close your Status Desktop window. If so, run again Status Desktop with the same command as before and check that all the above configurations are enabled.\nNow, open a new terminal and run a new instance of Status Desktop using a different directory for its database. For example\nmake run ARGS="--enable-fleet-selection --datadir=./datadir2"\nFollow the same steps as with the other Status Desktop instance, only changing the datadir flag\nWith the previous step completed, enter the Node Management section and check that both instances are connected to peers\n\nIn one of the accounts, copy the link to its profile\n\nAnd then, in the other account, send it a contact request\n\nMake sure you get a notification for it in your other window and accept the contact request\n\nChat between both accounts and check that messages get delivered properly\n\nFinally, test that the Store nodes work properly.\nFor it, close one of the windows and from the open window send messages to it.\nRe-run the Status Desktop instance you just closed and check that you receive the messages sent to you when you were offline.\nSome extra operations that we can run to double check everything is ok are:\n\nIn Node Management run the RPC method {"method":"settings_nodeConfig"} and check in the output that you are connected to the right fleet\nSimilarly, you can run the RPC method {"method":"wakuext_peers"} to get the list of peers\nCheck in Settings→Advanced→History nodes the history nodes we are connected to\n\nTo do: define how to test Status Communities"},"waku/index":{"title":"Waku Roadmap","links":["waku/collaboration","waku/process","tags/waku-updates","waku/reports","waku/2024-milestones","waku/2023-milestones"],"tags":["waku","roadmap","overview"],"content":"Roadmap Overview §\nTo learn more about Waku please visit the website, github, and docs.\n\nCollaboration\nProcess\nWeekly updates\nReports\n2024 Milestones\n2023 Milestones\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/process":{"title":"Process","links":[],"tags":["waku"],"content":"Resources §\n\nWaku Github: https://github.com/waku-org/\nEngineering Processes: https://github.com/waku-org/pm/blob/master/PROCESS.md\n\nMotivation and Goal §\nImplement the following attribute when delivering:\n\nClear tracking of work across the teams so that when we says that a milestone is delivered, then:\n\nit is usable by all types of users (operators, web devs, system devs).\nIt is documented (docs, dev rel)\nIt is of high quality (QA, Dogfooding)\n\n\nItems (epic, milestones) can be easily be closed and marked as complete thanks to:\n\nMinimal external dependencies\nMinimal intra-team dependency\nFinite, well-define scope.\n\n\nEach milestone and the effort needed to achieve it has a clear value thanks to a well-defined, value-driven, minimal, scope.\n\nTerminology and Scope §\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nNameNumber ofTimeframeTeam ScopeOwnerDescriptionMilestone?Pencilled for the year, planned for 2 quartersMost subteamsWaku LeadA, or cohesive set of, feature(s).EpicSeveral per milestoneSet for a milestoneUsually one subteam or external team (e.g. DST)Subteam Lead or MemberMilestone work for a given subteam.TaskMany per EpicSet monthly-ish, delivered weeklyOne subteam or individualTeam MemberMay be one or several piece of work, client specific.\nMilestone Definition §\nA Milestone:\n\nProvides a tangible user benefit: The milestone should aim to provide a distinct benefit or feature to the user, whether they are end users, operators or developers. In some case, a milestone may be a bundle of small features. The bundle of features should be cohesive and the benefit to the users should be easy to summarize. Most likely, a bundle milestone will be scoped to a given track.\nMinimal Scope: The milestone should be trimmed to a minimal scope, encompassing only what is just enough to assess the potential impact of these features on the project’s metrics (e.g. number of users, revenue). This means descoping any advanced features and aiming for a MVP-level delivery.\nTransversal: While the vertical scope of a milestone should be minimal, the delivery should be complete in terms of research, engineering, QA, documentation and dev rel assets so that the feature can be pushed to users once the milestone is marked as complete. Feedback loops should be as small as possible to ensure the value of a milestone is measured in a timely manner.\nAttached Estimate: An estimate should be associated with the milestone to facilitate the measurement of potential ROI. Additionally, tracking the estimate versus the actual progress is crucial for identifying any deviation and making informed decisions (e.g., deciding whether to continue if we learn the estimate is likely to be overrun).\n\nMilestone scoping process flow §\nPhase 1: Waku lead defines the scope within the Milestone. The scope is then discussed asynchronously in the comments of the GitHub issue by relevant subteams and stakeholders, scope of Epics and subtasks are defined.\nPhase 2: During a Waku PM call, the team reviews the Milestone to confirm scope or identify areas that require additional scoping.\nPhase 3: If the scope is agreed upon, the team can proceed to create Epics and schedule work for kickoff.\nEpics and Workflow §\nA milestone is divided in Epics. Each epic is assigned to a given subteam.\nEach Waku subteam lead (or selected member) is accountable for the delivery of their epic.\nTypically, each milestone will be divided in the following epics:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nEpic Label PrefixOwner Sub-teamOutputDescriptionE:researchWaku ResearchPoC, RFC, Protocol Simulations/StudiesInitial work done by the research team to create or change a protocol. Engineering-only Milestones may not have such epicE:nwakunwakuMVP quality softwareBring software to MVP level, proceed with re-architecture of PoC if needed, ensure functionality is usable, refine APIs, auto-generated/API documentation, ensure interoperability worksE:js-wakujs-wakuMVP quality software, including all supported env (e.g. React Native & Web)Implement protocol in js-waku, same as nwaku.E:bindingsnwakuMVP quality software for supported bindings (WIP)Expose new protocol/features on binding APIs.E:go-wakugo-wakuMVP quality software, include all supported bindings (i.e. C and Rust)Implement protocol in go-waku, only if needed by Status app.E:qaVac/DSTRFC-based + functionality based tests, both unit and integration tests.Test engineers take over and complete unit tests + add scenarios in integration test framework. In future, also add scenario to benchmark suite.E:dogfoodjs-waku, nwaku, bindingsLab example updates, own nodes updated, etc.Each dev team proceed by dogfooding the feature/API by using it themselves. Whether it is running their own node, or updating a selected number of examples. Go-waku can dogfood directly in status-go.E:docsDocDocumentation (not auto-generated)Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. This includes both coding guides but also a presentation ready visual documentation of the protocol behaviour.E:eco-devEco DevDev Rel assets (examples, video tutorial, etc), comms plan (X threads, blog posts)Dev Rel can now prepare assets to push the feature to developers, comms can prepare copies to communicate about it, BD can push it to projects and partners.\nflowchart LR\n subgraph milestone [Milestone]\n scope[Define scope and estimate] \n end\n subgraph researchE [E:research]\n scope-->research[RFC + Protocol Simulation + PoC] \n end\n subgraph nwakuE [E:nwaku]\n research-- Handover -->nwaku[MVP, API, Code doc, unit test]\n end\n subgraph js-wakuE [E:js-waku]\n research-- Handover -->js-waku[MVP, API, Code doc, unit test]\n end\n subgraph go-wakuE [E:go-waku]\n research-- Handover -->go-waku[MVP, API, Code doc, unit test]\n end\n subgraph go-wakuE [E:bindings]\n research-- Handover -->go-waku[API, Code doc, unit test]\n end\n subgraph qaE [E:qa]\n nwaku--Handover-->QA[QA, extended, interop and RFC-based testing]\n js-waku--Handover-->QA\n go-waku--Handover-->QA\n end\n subgraph dogfoodE [E:dogfood]\n nwaku-->Dogfooding[Developer use new software and API, interoperability]\n js-waku-->Dogfooding\n go-waku-->Dogfooding\n end\n subgraph docsE [E:docs]\n Dogfooding-- Handover -->Docs[Update and create guides and protocol documentation]\n end\n subgraph ecodevE [E:eco-dev]\n Dogfooding-- Handover -->Eco-Dev[Dev Rel and BD assets, plan Comms]\n Docs-->Eco-Dev\n end\n\nEngineering-Only Milestones §\nSome milestones may not involve the Waku Research team. In this case, the flow still applies but E:research is skipped.\nChat SDK and other Special SDK Work §\nThe Chat SDK team is focusing on go-waku integration in status-go and follows Status’ PM for issues and labelling.\nOnce the team starts building an independent Chat (or other) SDK, the flow will be as above but with research handled by VAC/ACZ and only one dev team:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nEpic PrefixOwner Sub-teamOutputDescriptionE:aczVac/ACZRFCRFC describing a specific, likely agnostic protocolE:chat sdkChat SDKPoC and then MVP quality software, Application RFCImplement the ACZ RFC, define API and application protocol\nHandover to QA, Docs, Eco Dev with MVP quality software is still expected down the track but may be pending growing teams.\nAccountability §\nEach epic should have an owner per subteam.\nMost epics will have a unique owner (e.g. a Waku Research team member owns a E:research epic).\nFor Dogfood and QA epics, one owner per client should be set.\nThe epic owner is responsible for breaking down the work in smaller issues in the related repo.\nFor research team, it is expected that most of the research work is done by the epic owner, which includes:\n\nCapturing problem statement\nDesigning protocol/solution\nImplementing PoC in reference implementation\nRunning tests/simulations to confirm behaviour (to be offloaded to test engineer)\n\nFor development teams, it is expected that design/break down is done by the epic owner.\nBut actual work can be picked up by other team member.\nEpic owner must:\n\nUnderstand the change and its implications,\nLiaise with researcher for any doubt or questions or design issues related to specific client/use case,\nCreate issues (Tasks) to break down work in client repo, include an acceptance criteria in each issue to ensure that the objective/end goal/behaviour is clearly described.\n\nIt is likely that the epic owner will do the core change or first change for a given epic.\nHowever, subsequent/other changes may be picked up in parallel or sequentially by other team members.\nHence:\n\ndependencies must be clearly stated in Task issue description\nTeam members must assign Task issues to themselves when work starts\nTeam members must update issues to track progress\n\nThe program manager should ensure that epics are getting the right assignee in a timely fashion.\nFor example, when research work starts for a given milestone, epic owners from development team should be assigned, so they know to participate in discussions.\nProgram manager should also ensure that issues are being created in a timely fashion,\nan is encouraged to use client PM call as a forum to check epics to be assigned, for example when a given epic is near completion.\nHandovers §\nThe following handovers are defined:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nHandoverExpectations when handing overExpectations when accepting handoverResearch to development teams- RFC PR is merged - PoC PR is merged- RFC content and PoC are reviewed - Own code and functionality - Own minor RFC changesDevelopment teams to QA- Happy path and selected error path tests exist - APIs are implemented to enable interop testing- Review RFC - Review existing testsDevelopment teams to Docs- Working usage of API is provided - Auto-generated documentation for public API is present- Review examples - Understands functionality Docs to Eco Dev- Docs PR is merged with functioning code- Understands functionality - Execute guides\nThe group or person handing over is expected to initiate a sync (meeting) or async (chat or GitHub) discussion to go through the output and overview.\nOnce the handover is accepted, the given epic can be closed.\nGitHub Usage §\nA Milestone:\n\nMUST have a matching GitHub issue in the https://github.com/waku-org/pm repo with milestone label assigned.\nMUST have a GitHub Milestone in https://github.com/waku-org/pm repo, to which relevant Epics are added.\nThe GitHub milestone MUST be used to track progress.\n\nAn Epic:\n\nMUST have a matching GitHub issue in the https://github.com/waku-org/pm repo.\nMUST have a label with format E:<prefix> <epic name>.\nSHOULD be added to a GitHub Milestone.\nSHOULD have a Planned Start and Due Date set (these are GitHub projects fields you can find in the Projects section of the issue view sidebar).\nMAY list Tasks present in other repos.\nMUST have assignee(s), who represent the epic owner (see accountability)\n\nA Task:\n\nMAY be tracked as a todo item in a GitHub Issue (Task or Epic),\nOR MAY be tracked as a single GH issue\n\nthat MUST be labelled with related Epic label (E:...),\n\n\nOR MAY be tracked as a GH Pull Request\n\nthat MUST have a reference to the related GitHub Task or Epic issue\n\n\nMUST have an acceptance criteria and/or a list of tasks (that can be other GH issues).\n\nFinally, for Tasks that do not belong to a given Epic or Milestone:\n\nMUST have either labels:\n\nbug: This is a bug, likely reported by a user\nenhancement: This is an enhancement out of the scope of the technical roadmap, likely reported by a user\n\nMajor enhancements should be carefully reviewed and prioritized.\n\n\ndocumentation: Documentation improvement or correction.\ndependencies: Upgrade dependencies in a timely manner to avoid time wasting when the dependency upgrade becomes critical.\n\n\n\nWhich means, in terms of navigation:\n\nWork for a Milestone is described in the related GitHub issue and tracked in the GitHub milestone.\nIn the GitHub milestone, we have a list of Epics to be achieved, the Epics are being closed as the work is done and handed over.\nTo look at remaining work for an Epic, one need to look at all issues (Tasks) with the corresponding Epic label (E:...)\n"},"waku/reports":{"title":"Waku Reporting","links":["waku/monthly-reports/2023-sept","waku/monthly-reports/2023-oct"],"tags":["wakureporting"],"content":"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\nMonthly Reports §\n\n2023 September\n2023 October\n"},"waku/templates/weekly-update-template":{"title":"TEMPLATE 2024-MM-DD Waku Weekly","links":[],"tags":[],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\nnext:\nblockers:\n\n\n\nStore v3 - store synchronisation\n\nachieved:\nnext:\nblockers:\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\nnext:\nblockers:\n\n\n\nPostgreSQL Maintenance\n\nachieved:\nnext:\nblockers:\n\n\n\nMetric: Count store messages\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - Direct Message Reliability §\n\n\nEnable testing of direct messages\n\nachieved:\nnext:\nblockers:\n\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\nnext:\nblockers:\n\n\n\nTooling: filter and light push protocols\n\nachieved:\nnext:\nblockers:\n\n\n\nTelemetry: fleet logging\n\nachieved:\nnext:\nblockers:\n\n\n\nTelemetry: direct message reliability\n\nachieved:\nnext:\nblockers:\n\n\n\nReliability Protocol for Relay\n\nachieved:\nnext:\nblockers:\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\nnext:\nblockers:\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\nnext:\nblockers:\n\n\n\nReview MVDS usage and fail path\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - End-to-end reliability protocol §\n\n\nTelemetry: multicast message reliability\n\nachieved:\nnext:\nblockers:\n\n\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\nnext:\nblockers:\n\n\n\nEnd-to-end reliability protocol - Status integration\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\n\nTelemetry: Measure Bandwidth\n\nachieved:\nnext:\nblockers:\n\n\n\nSharding peer management and discovery hardening\n\nachieved:\nnext:\nblockers:\n\n\n\nEnable testing of custom shard implementation for Communities\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nRLNv2 in nwaku\n\nachieved:\nnext:\nblockers:\n\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\nnext:\nblockers:\n\n\n\nProvision RLN for light push clients PoC\n\nachieved:\nnext:\nblockers:\n\n\n\nPay for RLN provision first PoC\n\nachieved:\nnext:\nblockers:\n\n\n\nMilestone - Scale up number of Communities §\n\n\nUsage of Rendezvous\n\nachieved:\n\nnext:\nblockers:\n\n\n\n\n\nDoS protection for req-res protocols and metrics (go-waku as service node)\n\nachieved:\n\nnext:\nblockers:\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\nnext:\nblockers:\n\nBugs §\n\nachieved:\nnext:\nblockers:\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:\n\nPresented two talks last week. Logos + Waku at Web3Privacy meetup and RLN at DCxPrague.\nEthGlobal Istanbul - 20 projects submitted and contributed with production and mentorship\nsecured talks and presented at Libp2p day and EthGlobal\nrepresented Waku in pragma booth\nHelped organise Status-wide meetup during DevConnect\n\n\nnext:\n\npublish tic-tac-toe blog post\nmigrate examples from personal repository to examples repository and take responsibility of examples repo\nedit and send video tutorials for review for comms\nwrite event proposal for co-hosting LibP2P day in EthIndia along with Protocol Labs during the Waku hacker house\nEthIndia production works (finding venue, vendors for swag and booth)\nprocess and deliver devconnect feedback\nhelp draft devconnect winner promotions\nonboard the devconnect winners to Waku discord to Hackathon-winners channel\nprepare event report of Devconnect with help from Lou\nprepare KPI document for Eth India with help from Lou\n\n\n"},"waku/updates/2023-11-27":{"title":"2023-11-27 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Network Can Support 10K Users §\n\n\nachieved:\n\nconfirmed no unknown blockers from Waku’s side to continue dogfooding in conversation with Status Communities\ncontinuing team-internal dogfooding of a test community using static sharding https://github.com/waku-org/pm/issues/97. See dogfooding report\nfleet ownership training: held session for stakeholders on responsibilities - https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741\n\n\n\nnext:\n\ncontinue dogfooding of Status Desktop with Status staging fleet with test community (https://github.com/waku-org/pm/issues/97)\nfix issue of store fleet not connecting to bootstrap fleet due to enr shards mismatch https://github.com/status-im/infra-shards/issues/23\n\n\n\nrisks:\n\nFleet Ownership doc defines fleet maintainer and owner. Status team yet to clarify who is the fleet owner for Status Communities.\nQA by Status team to be planned on staging static sharding fleet; Waku team has done internal dogfooding (report). Any change to the staging static sharding fleet should then be tested by QA before being deployed to prod (e.g. # of Postgres instances). Status has committed to this testing on 28Nov call.\nStatus team expressed will to deploy static sharding prod fleet and use it for all users: This is not recommended until proper QA is done on stagning static sharding fleet as it could impact other Status app activities.\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 team since November 2023 to drive effort.\nDependency on Vac/DST to conclude ~1k nodes simulations; lack 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.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: fix issue of using default clusterID as 16 for shards fleet, dogfooding of status-desktop with shards fleet, debug issues in connection to fleet. See dogfooding report\nnext: continue dogfooding\nachieved: fix pubsub topic used for store queries, logic for finding free port when initializing torrent service, add back changes related to default shard that were reverted before, store clusterID in app database, refactor mailserver cycle to not require having an active connection to a store node\nnext: dogfooding\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nnext: Pending DST simulations of 10k nodes gossipsub network.\nrisks:\n\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked under vac:dst:eng-10ktool.\n\n\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.\n\n\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\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\n\nWaku Network Gen 0 - 2023-12-01 §\n\nachieved:\n\nInternal dogfooding of proto-network continues.\njs-waku work continues.\nnwaku optimization around peer management are underway.\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. Tracked with #102\n\n\n\n4.1: Basic front end for node operator §\n\nachieved: follow ups and reduction of FE image;\nnext: double check with cors solved, minor improvements and fixes\n\n1.5: Launch and dogfood integrated public Waku Network MVP §\n\nachieved: come up with go-waku-compose to run a go-waku node in order to dogfood the public waku network\nnext: fix issues in go-waku-compose to support secure websockets and auto-fetch public IP\n\n1.4: Sharded peer management and discovery §\n[nwaku] chore: add sharding information to peer storage\n\nachieved: merged and closed\n\n[nwaku] chore: add sharding information to peer storage\n\nachieved: updated peer storage to include ENR\nnext: review feedback cycle\n\n[js-waku] feat: Deprecate Named Sharding and Update Lightpush Client API\n\nachieved: PR ready and currently in review-iteration phase ( #1697 )\nnext: to be merged\n\n[js-waku] feat: add new metadata protocol\n\nnext: unblock this issue by merging #1697\n\n1.2: Autosharding for autoscaling §\n[nwaku] chore: allow fetching cached messages by content or pubsub topic\n\nachieved: PR merged DONE!\n\n2.1: Production testing of existing protocols §\n[nwaku] feat: Migrate deployments to PostgreSQL\n\nachieved: Preparing environment to stress one single database with multiple Postgres clients writing and reading simultaneously.\nnext: Extend Postgres benchmarking report from previous results and start analyzing the performance of status.test fleet where three nodes will use one single database.\n\nPresentation Readiness §\n[js-waku] feat: filter subscription API\n\nachieved: PR opened and currently under review-iteration phase ( #1725 )\nnext: merge PR\n\nOther Work §\nEnhancements §\n[nwaku] chore(REST): adding to /admin/v1/peers response lightpush and filter v2 peer info\n\nachieved: merged PR and closed issue\n\n[js-noise] feat: allow parameterization of handshakes\n\nachieved: implemented parameterization of DH, Cypher and Hash\n\nBugs §\n[nwaku] bug: incomplete data sent or received log appearing when WSS is enabled\n\nachieved: attempted reproducing, haven’t gotten it to happen yet\nnext: succeed reproducing and fix\n\n[nwaku] bug: relay publish fails with 400 Bad Request when message contains meta field\n\nachieved: analyzed issue and started implementing fixes\nnext: continue implementing the solution\n\n[nwaku] bug: relay push with malformed timestamp crashes nwaku\n\nachieved: analyzed issue, found and implemented fix, raised PR in nim-json-serialization repo and implemented feedback. Merged fix and opened a PR in nwaku updating the dependency.\nnext: get nwaku PR reviewed y merge\n\n[go-waku] bug: duplicate validator for topic error when trying to re-subscribe to previously unsubscribed topic\n\nachieved: fix relay subscribe API issue causing failure in resubscription to a pubsubtopic, return appropriate errors in relay REST API\n\nDocumentation §\n[docs.waku.org] Advanced docs for js-waku\n\nachieved: published manage filter guide, finished react docs\nnext: ECIES and symmetric encryption/decryption\n\n[docs.waku.org] Docs general improvement/incorporating feedback (2023)\n\nachieved: added light mode toggle, updated the logos preset, added TWN guide, updated docs design and structure\n\nEcosystem Development §\n\n\nachieved:\n\nDocumentation refactor based on feedback\nPreparing react hooks for release\nEthIndia organizing\nWaku hackerhouse organizing\nETHIstanbul winner tweets\n\n\n\nnext:\n\nAnnounce react hooks\nWaku hackerhouse\n\n\n"},"waku/updates/2023-12-04":{"title":"2023-12-04 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Network Can Support 10K Users §\n\nachieved:\n\nconfirmed no unknown blockers from Waku’s side to continue dogfooding in conversation with Status Communities\ncontinuing team-internal dogfooding of a test community using static sharding https://github.com/waku-org/pm/issues/97. See dogfooding report\nfleet ownership training: held session for stakeholders on responsibilities - https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741\n\n\nnext:\n\ncontinue dogfooding of Status Desktop with Status staging fleet with test community (https://github.com/waku-org/pm/issues/97)\nfix issue of store fleet not connecting to bootstrap fleet due to enr shards mismatch https://github.com/status-im/infra-shards/issues/23\n\n\nrisks:\n\nFleet Ownership doc defines fleet maintainer and owner. Status team yet to clarify who is the fleet owner for Status Communities.\nQA by Status team to be planned on staging static sharding fleet; Waku team has done internal dogfooding (report). Any change to the staging static sharding fleet should then be tested by QA before being deployed to prod (e.g. # of Postgres instances). Status has committed to this testing on 28Nov call.\nStatus team expressed will to deploy static sharding prod fleet and use it for all users: This is not recommended until proper QA is done on stagning static sharding fleet as it could impact other Status app activities.\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 team since November 2023 to drive effort.\nDependency on Vac/DST to conclude ~1k nodes simulations; lack 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.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: fix issue of using default clusterID as 16 for shards fleet, dogfooding of status-desktop with shards fleet, debug issues in connection to fleet. See dogfooding report\nnext: continue dogfooding\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nnext:\n\nPending DST simulations of 10k nodes gossipsub network.\n\n\nrisks:\n\nDependency on Vac/DST to run 10k nodes simulations. Tracked undervac: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.\njs-waku work continues.\nnwaku optimization around peer management are underway.\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. Tracked with #102\n\n\n\n4.1: Basic front end for node operator §\n[nwaku] bug: access-control-allow-origin should be set to localhost\n\nachieved: understood and applied initial fixes, tested, found bug and got it to work\nnext: add tests for changes in presto, raise PRs in both presto and nwaku\n\n1.4: Sharded peer management and discovery §\n[nwaku] feat: Peer management with shard as a dimension\n\nachieved: sharded peer management final version in review\nnext: review feedback\n\n1.2: Autosharding for autoscaling §\n[nwaku] chore: allow fetching cached messages by content or pubsub topic\n\nachieved: PR merged DONE!\n\n[js-waku] feat: Autosharding API for req-resp protocols\n\nachieved: config node for static/autosharding, test all protocols against autosharding RPC endpoints on nwaku\nnext: config application and version on node creation, only discover nodes of same shard\n\n[js-waku] (https://github.com/waku-org/js-waku/issues/1500)\n\nachieved: all protocols can be configured to use autosharding for determining pubsub topics\nnext: make autosharding the default behavior when running js-waku\n\nOther Work §\nEnhancements §\n[go-waku] feat: use current timestamp when not provided in relay rest api\n\nachieved: return error in relay API when message gossipsub threshold is crossed, fill messageTimestamp if RLN is enalbed and not set in WakuMessage, improve errors returned for filter unsubscribe APIs\n\nBugs §\n[nwaku] bug: incomplete data sent or received log appearing when WSS is enabled\n\nachieved: reproduced it, did superficial checks but couldn’t get deep enough to find the root cause\nnext: continue investigating\n\n[go-waku-compose] fix: automatic fetching of public ip not working\n\nachieved: made go-waku-compose ready to run go-waku node to support the public waku network\n\nDocumentation §\n[go-waku] doc: best practice to handle disconnection when sending messages over relay\n\nachieved: provided a short-term approach to address message send/receive issues during disconnections, intiated discussions in nimbus and vac channels to find out possible approaches being used in other protocols using gossipsub\n\nEcosystem Development §\n\nachieved:\n\nReviewed upcoming Waku press release\nCreated new bounties: 1, 2\nReviewed expectations for EthIndia and the Waku Network\n\n\n\nChat SDK §\nchat-sdk-tracking\n\nachieved: Running custom built desktop with status-go, working on community store node\nnext: continue working on community store node\nblocker: no so far\n\nProject Management §\n\nachieved:\n\nOpen discussion around project management, milestones and expectations from Logos Program.\nEnsure critical work for Status app is tracked and planned: 1, 2\nVarious hiring activies: BD, Growth lead and how to handle js-libp2p maintenance\nReview Status plans around testing static sharding and ensure potential risks are understood.\nFind a spot to host studies and simulation output as part of our commitment to build in the open and awarness of potential deplatforming: [1, Waku Discord]\nDrafting updated PM tracking proposal\n\n\nnext:\n\nResume discussion around Nim usage and multiple clients in Waku: 1\nReview 2023 achievements and start planning 2024 milestones.\nShare proposal doc to Waku cc’s for review\n2024 Research milestone tracking\n\n\n\nBasic Dev Rel Assets\n\nachieved: Lead conversion process and community engagement process docs completed\n"},"waku/updates/2023-12-11":{"title":"2023-12-11 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Network Can Support 10K Users §\n\nachieved:\n\nfixed issue of store fleet not connecting to bootstrap fleet due to enr shards mismatch https://github.com/status-im/infra-shards/issues/23\ncontinuing team-internal dogfooding of a test community using static sharding https://github.com/waku-org/pm/issues/97. See dogfooding report\nbenchmarked various ways for large postgresql deployments: https://github.com/status-im/infra-status/issues/37\n\n\nnext:\n\ncontinue dogfooding of Status Desktop with Status staging fleet with test community (https://github.com/waku-org/pm/issues/97)\n\n\nrisks:\n\nFleet Ownership doc defines fleet maintainer and owner. Status team yet to clarify who is the fleet owner for Status Communities.\nQA by Status team to be planned on staging static sharding fleet; Waku team has done internal dogfooding (report). Any change to the staging static sharding fleet should then be tested by QA before being deployed to prod (e.g. # of Postgres instances). Status has committed to this testing on 28Nov call.\nStatus team expressed will to deploy static sharding prod fleet and use it for all users: This is not recommended until proper QA is done on stagning static sharding fleet as it could impact other Status app activities.\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 team since November 2023 to drive effort.\nDependency on Vac/DST to conclude ~1k nodes simulations; lack 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.\n\n\n\nTargeted dogfooding for Status Communities §\n\nachieved: fix peer manager to take into account the ENR seq to determine if a peer is new or not and fix incorrect number of connected peers per topic. Register lightpush protocol correctly in go-waku. Drop pubsub topic bridging. Use shards.test fleet as default (in status-go and desktop)\nnext: continue dogfooding / fixing issues\n\nWaku Network can Support 1 Million Users - 2023-11-30 §\n\nachieved:\n\nResearched various ways of deploying shared postgresql instances for large deployments: https://github.com/status-im/infra-status/issues/37\n\n\nnext:\n\nPending DST simulations of 10k nodes gossipsub network.\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 §\n1.4: Sharded peer management and discovery §\n[nwaku] feat: Peer management with shard as a dimension\n\nachieved: sharded peer management and store pruning PR merged\n\n1.2: Autosharding for autoscaling §\n[js-waku] feat: make autosharding default node behavior\n\nachieved: open PR to reintroduce (but deprecate) name sharding alongside auto/static sharding without breaking APIs\nnext: update all examples to use autosharding\nblocker: need review on https://github.com/waku-org/js-waku/pull/1723\n\nSupport Many Platforms - 2024-04-30 §\nREST API service node §\n[docs.waku.org] REST API/ NodeJS\n\nachieved: added references for the REST API\n\nOther Work §\nResearch §\n[research] Onchain RLN tree+root: Proof Of Concept\n\nachieved: We present a proof of concept change in the RLN contract to store the whole membership tree on-chain + its Merkle root. This lowers sync time from several minutes to a few seconds, but at a cost of x10 the membership insertion cost. It also makes light clients lighter since proof verification becomes stateless (Merkle root can be accessed onchain, without having to sync the tree). We also present go-waku-light, to showcase the newly introduced features and how they are meant to be used.\n\nEnhancements §\n[nwaku] chore: avoid blocking the whole waku node when retention policy is being applied\n\nachieved: avoid blocking the whole waku node when the retention policy is being applied\n\nDocumentation §\n[docs.waku.org] Encryption documentation\n\nachieved: push initial draft for symmetric, ECIES, message signing\nnext: merge and deploy encryption docs #145\n\n[docs.waku.org] Docs general improvement/incorporating feedback (2023)\n\nachieved: add RN warning, add certbot instructions, improve nwaku-compose guide\n\nChores §\n[nwaku] Bump vendor dependencies for release 0.23.0\n\nachieved: bumped nim-dnsdisc dependencies\nnext: bump nim-waku dependencies\n\nEco Dev §\n\nachieved: 51 projects submitted at EthIndia hackathon\n"},"waku/updates/2023-12-18":{"title":"2023-12-18 Waku weekly","links":[],"tags":["waku-updates"],"content":"2023-12-18 Waku weekly §\nTargeted dogfooding for Status Communities §\n\nachieved: fix panic on logout, publish messages async, fix loading message history for communities, fix invalid bootnodes being used on status desktop, status dogfooding, raise issues and optimizations needed wrt light protocols usage in status-go and improvements to be done in nwaku,\nnext: continue dogfooding / fixing issues\n\nSupport Many Platforms - 2024-04-30 §\nPresentation Readiness §\n[js-waku] feat: filter subscription API\n\nachieved: rebasing\nnext: error handling via event emitter as well. plan if restructuring is required.\n\nOther Work §\nEnhancements §\n[nwaku] feat: Have additional Admin REST API endpoints that helps node operator in monitoring\n\nachieved: improved logging and merged. Created locally a new REST endpoint that returns the information of all the filter subscriptions on a service node\nnext: add unit tests, update documentation and open PR\n\n[research] Sync store baseline understanding\n\nachieved: PoC of Prolly Tree (fixing a Bug), insertion and deletion of data into it.\nnext: a writeup about Prolly trees PoC in issue, further testing, generating some operational data details such as memory consumption using RLN specs.\n\nBugs §\n[nwaku] bug/regression: Relay connection works no more\n\nachieved: reproduced the issue both in testing framework and with local nodes, analyzed logs and narrowed down to the commit where things got broken\nnext: continue investigating, find root cause and fix\n\n[nwaku] bug: no messages returned from store node when multiple content topics and start/end time are used\n\nachieved: bug fix store service in nim-waku when the query used more than one content topic\n\nDocumentation §\n[docs.waku.org] Document how to use k-anonymity with content topic\n\nachieved: add content topic buckets consideration #153\n\nChores §\n[nwaku] Bump vendor dependencies for release 0.23.0\n\nachieved: bump all nim-waku vendor dependencies\n"},"waku/updates/2023-12-25":{"title":"2023-12-25 Waku weekly","links":[],"tags":["waku-updates"],"content":"Happy Holidays!\n1.3: Node bandwidth management mechanism §\n\nachieved: make configurable the max message size in nim-waku https://github.com/waku-org/nwaku/pull/2298\n\n1.2: Autosharding for autoscaling §\n[js-waku] feat: make autosharding default node behavior\n\nachieved: merged PR that implements autosharding after feedback. PR to reintroduce named sharding ready for review\nnext: update all examples to use autosharding\n\nOther Work §\nChat SDK §\n[chat-sdk] chat-sdk tracking\n\nachieved: close connections for filter light client, draft a doc about messages on the relay\nnext: work on user cannot join the community bug\n\nResearch §\n[nwaku] feat: experimental incentivize store protocol\n\nachieved: continued discussion on incentivization RFC\nnext: move towards implementation\n\nEnhancements §\n[nwaku] feat: Have additional Admin REST API endpoints that helps node operator in monitoring\n\nachieved: improved initial implementation. Added unit tests, updated documentation, opened and got approved PR.\nnext: verify if there’s other places where the new endpoint should be document before merging\n\n[research] Sync store baseline understanding\n\nachieved: PoC of Prolly Tree feature complete, Postgres retention policy PR, diff protocol ground work started.\nnext: pending technical writeup about Prolly trees PoC in issue, Diff protocol, generating some operational data details such as memory consumption using RLN specs.\n\nBugs §\n[nwaku] bug/regression: Relay connection works no more\n\nachieved: reproduced, investigated, found root causes and fixed\n\n[nwaku] bug: lack of error checking in publish\n\nachieved: reproduced, investigated and started improving error handling\nnext: continue with the implementation\n\nPM §\n\nachieved: proposed Waku strategy draft to team and started discussions\nnext: continue Waku strategy discussion, publish strategy/discuss with Logos leadership, continue drafting Waku roadmap for 2024\n"},"waku/updates/2024-01-08":{"title":"2024-01-08 Waku weekly","links":[],"tags":["waku-updates"],"content":"2024-01-08 Waku weekly §\nWaku Network Can Support 10K Users §\nTargeted dogfooding for Status Communities §\n\nachieved: status-mobile dogfooding, debug and attempt to identify root cause of filter delay issue\nachieved: attempt to identify root cause of filter delay issue, work on upgrading status-go to use Go 1.21 (to use latest go-libp2p), use latest go-waku version and identify missing commits between release and develop branch\nnext: continue dogfooding / fixing issues\n\nWaku Network Gen 0 - 2023-12-01 §\n1.5: Launch and dogfood integrated public Waku Network MVP §\n\nachieved: add new metrics and make go-waku-compose dashboard functional, dogfooding the network with go-waku node\nnext: fix few pending items in dashboard\n\nOther Work §\nEnhancements §\n[nwaku] feat: Have additional Admin REST API endpoints that helps node operator in monitoring\n\nachieved: got feedback about improved error handling. Added it to the code, got a segfault from the testing framework, investigated and found the root cause.\nnext: define how to proceed based on the testing issue and merge the PR\n\n[nwaku] feat: Have additional Admin REST API endpoints that helps node operator in monitoring\n\nachieved: improved initial implementation. Added unit tests, updated documentation, opened and got approved PR.\nnext: verify if there’s other places where the new endpoint should be documented before merging\n\n[waku-rust-bindings] Peer discovery & management \n\nachieved: Added dns discovery parameters to the node config\n\n[research] Sync store baseline understanding\n\nachieved: 1-day work this week due to time off, nim implementation of Prolly trees\nnext: Diff protocol discussion, Sync mechanism on wire query protocol discussion, generating some operational data details such as memory consumption using RLN specs.\n\n[go-waku] feat: parameterizable number of connections per IP\n\nachieved: Maintain parity between nwaku and go-waku clients\n\nBugs §\n[nwaku] bug: sort order ignored in store nodes\n\nachieved: created v0.23.1-rc.0 and deployed in status.test fleet.\nnext: Deploy v0.23.1 to both status.test and status.prod after having the approval from @richard-ramos and @mprakhov\n\n[nwaku] bug: lack of error checking in publish\n\nachieved: fixed compilation errors, got it to work and tested it\nnext: add test cases to the codebase and open PR\n\n[go-waku] bug: filter/v2/subscriptions take a lot of time and even timeout sometimes\n\nachieved:fix panic when static peer is also discovered dynamically, fix ENR Waku field population for Fitler, analyze data races identified\n\n[go-waku] bug: update examples to use autosharding\n\nachieved: update basic_relay example to use static and autosharding\n\nDocumentation §\n[go-waku] bug: update examples to use autosharding\n\nachieved: update basic_relay example to use static and autosharding\n\n[go-waku] chore: create docs for setting up a systemd service and exit codes\n\nachieved: Added systemd template and docs\nnext: Add env variables suggested by infra\n\nPM §\n[pm] Waku Research - Post Gen 0 Milestones and Epics\n\nachieved: Significantly refined milestones and epics and started getting feedback from stakeholders\nnext: Further stakeholder engagement. Define work needed to improve RFC process.\n\nChores §\n[nwaku] Bump vendor dependencies for release 0.24.0\n\nachieved: bump dependencies to prepare the v0.24.0.\n"},"waku/updates/2024-01-22":{"title":"2024-01-22 Waku weekly","links":[],"tags":["waku-updates"],"content":"Waku Update §\n\nCurrently the Waku team is focused on completing the remaining critical TWN Generation 0 Milestone Epics, the Status Integration, and various bug fixes and enhancements.\nWaku’s development is divided among 5 teams: nwaku, go-waku, js-waku, chat-sdk, and ecosystem-development.\n2024 Milestones and Epics are currently being structured, kickoffs slated begin first week of February.\nThe go-waku and chat-sdk teams were at the Status integration Doha offsite January 13 - 21.\n\nWaku Network Gen 0 §\nOpen Epics\n\nAutosharding for autoscaling | js-waku | critical | 66%\nNode bandwidth management mechanism | nwaku | not critical | 0%\nSharded peer management and discovery | js-waku | critical | 87%\nLaunch and dogfood integrated public Waku Network MVP | nwaku | critical | 0%\nProduction testing of existing protocols | js-waku & nwaku | critical | 40%\nSharded capability discovery for light protocols | js-waku & go-waku | critical | 0%\nBasic DoS protection in production | go-waku & research | critical | 28%\nBasic front end for node operator | js-waku & nwaku | critical | 83%\n\nJanuary 22 Update §\nnwaku §\nTWN Connectivity\nPrepare release 0.24.0\n\nachieved: big picture solutions for TWN connectivity problem , coordinate nwaku v0.24 release candidate\nnext: Nwaku v0.24.0 test and release, autosharding/cluster-id error handling, moar connectivity research\n\nbug: restart loop of current master\n\nachieved: investigated, found the root cause and solution. Afterwards, got requested a change in logging, implemented it and raised PR.\nnext: get confirmation that the change in logging meets Infra’s needs and get the PR reviewed and merged\n\nfeat: REST API - large messages does not seem to be rejected by relay auto api\n\nachieved: developed and tested an initial working implementation\nnext: after talking to Franck, will implement it differently with a more generalized message verification logic\n\nchore: improve POST /relay/v1/auto/messages/{topic} error handling\n\nachieved: fix compilation errors, open PR, implement feedback and merge\n\nbug: incomplete data sent or received log appearing when WSS is enabled\n\nachieved: investigated code, ran private images with logs on nim-libp2p and analyzed results. Talked to nim-libp2p team to further understand where the failure happens\nnext: investigate further with the new understanding after talking with nim-libp2p team\n\nchore: review waku-simulator deployment and improve tracking processes\n\nachieved: found that simulator’s nwaku image wasn’t getting updated with latest master. Requested Infra for the fix and verified afterwards that it’s working properly\nnext: talk with stakeholders to see what metrics/logs we should keep track of and how\n\nbug: Filter doesn’t receive messages after subscribing and restarting\n\n_achieved:_ investigated and fixed cause of failing test\n\nchore: Refactor of FilterV2 subscription management with Time-to-live maintenance\n\nachieved: Filter V2 subscription management reworked: new Time-to-live tracking, configurable limits of peers served and suvbscriptions per peer. Subscription per request is raised from 30 to 100 (hardcoded)\n\nbug: access-control-allow-origin should be set to localhost\n\nachieved: Alignment with Eugen (presto and chronos maintainer) is made upon the solution to be applied on presto rest server class.\nnext: Once new desing is ready and pushed to presto library, we can add the already prepared “allowed origin” matching mechanism that will enable proper CORS header in response to rest request.\n\nfeat: Enforce service specific rate limits\n\nnext: measurement of usage rates of store protocol to be added (also add to grafana dashboard), add configurable limits (query per sec/min)\n\njs-waku §\nchore: upgrade lip2p\nfeat: set cluster ID as optional when specifying shard info\nfeat: Peer management with shard as a dimension\n\nachieved:\n\nupgrade libp2p to 1.X\nimproved how params are handled between consumer-facing and internal functions\nfix failing tests for autosharding peer mgmt\n\n\n\nallow user to pass content topic to createSubscription\nfeat: sdk function to setup autosharding node with application and version\nfeat: determine bootstrap behavior based on sharding type\n\nnext:\n\nallow creating subscriptions with just content topics\nsetup node with just application and version\ndetermine boostrap behavior based on sharding type\n\n\n\nDecouple sharding logic from internal classes to SDK\n\nblockers:\n\nneed review of issue for decoupling sharding logic\n\n\n\nfeat: simplify rln-js\nfeat: simplify API of bootstrapping, connection to MetaMask\nchore: investigate interop test failures\nchore: fix go-waku interop tests\n\nachieved:\n\nSimplified rln-js\nStep 1 to improve API\ninterop tests with nwaku\nidentified problems with go-waku\n\n\n\nUser Pays Own RLN Membership\n\nnext:\n\nnew cred registration example (based on prev examples)\ncontinue with improvements\naction if needed to improve testability with go-waku\nsome bugs found in rln\n\n\n\nfeat!: protocols filter peers per shard\nfeat: SDK for redundant usage of filter/lightpush\n\nachieved:\n\nmerged: sharded peer management\nmerged: redundant peers for lightpush & filter\n\n\n\nfeat: local storage as a discovery layer\nfeat: SDK for redundant usage of filter/lightpush\n\nnext:\n\nIntroducing Local Storage as a discovery layer, handle renewing of faulty redundant peers (TODO 3) on feat: SDK for redundant usage of filter/lightpush\n\n\n\ngo-waku §\nbug: filter delay errors\n\n\nachieved:\n\ninvestigated and identified the root-cause of bug: filter delay errors and provided a solution\nstarted documenting tips/approach to help message loss debug issues for status QA both from status-go and waku perspective Debugging\n\n\n\nnext:\n\ninvestigate and identify root-cause of message loss while using relay ⁠Unable to Receive msgs while us…\nfinish documenting message loss debugging\n\n\n\nbug: filter delay errors\nContact requests are not received without restart\n\n\nachieved:\n\ninvestigation with Jakub and Igor to find out the reason why store request were taking a long time to be retrievedsage reliability issues were present on CI for filter.\ninvestigate and fix Contact requests are not received without restart (some commits were missing in desktop master branch.\nStatus x Waku war room at Doha\n\n\n\nnext:\n\nfix issues reported in ⁠status\n\n\n\neco-dev §\n[BOUNTY] Build dApp of Your Choice Using Waku (Decentralized Communication) and Vue.js\n\nachieved:\n\nthorough review and feedback\n\n\nnext:\n\nfinal review and approval\n\n\n\nadd content topic buckets consideration\n\nachieved:\n\nmerged add content topic buckets consideration on content topic consideration, playing around with Noise encryption\n\n\n\n[Epic] Encryption documentation\n\n\nnext:\n\ncreating an initial draft for Noise docs, go-waku docs migration\n\n\n\nachieved :\n\ncompleted and recorded videos with 2 teams for builder spotlight, positioning call is completed, revised the cheatsheet based on ethindia feedback\n\n\n\nnext :\n\nget the videos reviewed\n\n\n"},"waku/updates/2024-01-29":{"title":"2024-01-29 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Update §\n\n2024 Milestones have been defined, to be structured and prioritized this week, subject to change pending approval from stakeholders.\nRemaining open TWN Gen 0 Milestone items to be priorirized in 2024 Milestones and Epics.\n\nWaku Network Gen 0 §\nOpen Epics\n\nAutosharding for autoscaling | js-waku | critical | 75%\nNode bandwidth management mechanism | nwaku | not critical | 0%\nSharded peer management and discovery | js-waku | critical | 87%\nLaunch and dogfood integrated public Waku Network MVP | nwaku | critical | 0%\nProduction testing of existing protocols | js-waku & nwaku | critical | 40%\nSharded capability discovery for light protocols | js-waku & go-waku | critical | 0%\nBasic DoS protection in production | go-waku & research | critical | 28%\nBasic front end for node operator | js-waku & nwaku | critical | 83%\n\nBlocked : Add implementation of PRESTO middleware.\n\n\n\nJanuary 29 Update §\nWaku’s development is divided among 6 teams: research, nwaku, go-waku, js-waku, chat-sdk, and ecosystem-development.\nResearch §\nrln-proof-witness\nCreate RLN proof without having the whole tree\n\nachieved:\n\nCreate proof of concept where light clients can generate their own rln proofs without having to sync the whole tree.\nDog food above PoC and get feedback\nStart with rln in gossipsub paper\n\n\n\nWaku Research - Post Gen 0 Milestones and Epics\n\nachieved: created outline doc for new Specs/RFC process: https://www.notion.so/Waku-Specs-Process-Improvements-3bca80fe10804aeaa7a184143bdca07d, first designs for new Store protocol, refined effort estimates\nnext: implement new Specs process, create milestone/epic related issues, work on draft Store protocol improvement\n\nTWN Connectivity\n\nachieved: read Meridian paper and wrote how it could be used in TWN, reading on Discv5 topic advert design problems\nnext: discuss with VAC topic experts?\n\nnwaku §\nfeat: Enforce service specific rate limits\n\nachieved: implemented a simple lightpush and store request rate limit with configurable defaults\nnext: prior PR need to finish some more tests\n\nbug: access-control-allow-origin should be set to localhost\n\nblocked: Eugen done a presto PR utilizing new chronos middleware design, added comments due we need some change on it prior able to use it.\n\nfeat: sharded peer management Round 2\n\nachieved: added sharded peer management config flag, feedback\nnext: review & merge\n\nchore: improved error handling when config uses cluster-id and pubsub topics\n\nachieved: improved error handling for cluster and shard config\nnext: review & merge\n\nbug: restart loop of current master\n\nachieved: got feedback for the PR, implemented fix and merged\n\nbug: RLN validator is only added for statically configured pubsub topics\n\nachieved: analyzed issue, implemented a solution, tested and raised PR\nnext: get feedback on the PR, implement it and merge\n\nfeat: REST API - large messages does not seem to be rejected by relay auto api\n\nachieved: investigated how to approach the issue using generalized validators, implemented a solution, tested and raised PR\nnext: get feedback on the PR, implement it and merge\n\ngo-waku §\n\n\nachieved:\n\ndocument tips and how to debug message loss for status team Debugging\nfix updating lastProcessedBlock even if no RLN membership event is present fix: update lastProcessedBlock even if no RLN membership event is present\nfix issue in connectionStatus reporting fix: minor issues in connectionstatus report\ninclude a basic lightClient example chore: example update\nimprove logging chore: set log level for all loggers based on logger passed , https://github.com/waku-org/nwaku/pull/2366\nsupport for multiple peer selection for filter feat: support multiple peer selection for filter client\n\n\n\nnext:\n\ninvestigate message loss in status-mobile ci\ninvestigate if gossipsub scoring can be monitored and reported to app as unhealthy https://github.com/waku-org/go-waku/issues/1017\ndogfooding status desktop and mobile and investigate and support status team for any other message reliability issues\n\n\n\nachieved:\n\nfix: add support to aarch64-linux-android in go-zerokit-rln-arm: fix: add support to aarch64-linux-android\nfix: handle community shard unassignment: fix: handle community shard unassignment and update\n\n\n\nnext:\n\nwork on status/waku integration items\n\n\n\njs-waku §\n\n\nachieved:\n\nsimplified rln-js example;\nreleased part of improvements for User Pays Own RLN Membership\ndone with investigating test\n\n\n\nnext:\n\nnew cred registration example (based on prev examples)\nfinish improvements for rln\nbugs found in rln\nimprove tests (issue tbd)\n\n\n\nachieved:\n\ndecouple sharding params out of core classes Decouple sharding logic from internal classes to SDK\n\n\n\nnext:\n\nallow creating subscriptions with just content topics allow user to pass content topic to createSubscription\n\n\n\nachieved:\n\nlightpush & filter use multiple peers instead of one feat: lightpush & filter send requests to multiple peers\nlocal storage as a discovery layer (in progress)\nfixing interop tests (in progress) fix(tests): append p2p with the multiaddrs from ENR, chore(tests): update max content topics on lightpush from 30 to 100\n\n\n\nnext:\n\nmerge local storage discovery (https://github.com/waku-org/js-waku/pull/1811),\nmoving message-hash into core (https://github.com/waku-org/js-waku/pull/1810),\n\n\n\nEcosystem-development §\nCommunity/Partners §\n\nachieved: Waku Community Space https://twitter.com/Waku_org/status/1750927368644919722\nnext: Logos x HOPR space, 30 days of web3 presentation\n[BOUNTY] Build dApp of Your Choice Using Waku (Decentralized Communication) and Vue.js\nachieved: final reviews, approved\n\nPost by community member bounty hunter: https://x.com/wolz_codelife/status/1751955673603002459?s=20\nwaku-org/bounties\n\n\nachieved: collected and reviewed a few options for Bounty platforms\nnext: create dummy bounties to see how things work\n\nDocs §\nIntegrate benchmark and research into website\n\nachieved: review of linked PR https://github.com/waku-org/docs.waku.org/pull/157\nnext: follow up on integrating spell check into the research and nwaku repos\n[Epic] Encryption documentation\nnext: (still ongoing) initial noise encryption docs\nCreate a FAQ and troubleshooting guide\nnext: starting the technical FAQ drafting\n\nDevRel §\n\nachieved:\n\nbuilder spotlight video with MrFox team\n2 tutorial videos reviewed by comms\nmonthly community twitter space: https://twitter.com/Waku_org/status/1750927368644919722\n\n\nnext:\n\ncomplete all the tutorial videos\nworkshop presentations for ethlatam\nmore builder spotlight videos\ncalls with node operators\n\n\n\nStatus Integration §\nchat-sdk §\n\nachieved: started the conversation with Hanno on permission-less communities\nnext: agree on an approach on permission-less communities.\nachieved: research and draft hash based message query to store node spec\nnext: discuss on the iteration of hash based message query\n"},"waku/updates/2024-02-05":{"title":"2024-02-05 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Waku Update §\n\n2024 Milestone work breakdowns underway. Target date estimates, Epics and sub-tasks to be created following scope sign off.\n\nResearch §\n\nachieved:\n\nscript to benchmark rln\nstarted rln+gossipsub paper, some plots\ntidying TWN Connectivity Research issue\nWaku Sync overview first draft\nstarted implementation of incentivization RFC\nstarting on protobuf codec for eligibility proofs\nfirst draft for new Store protocol that is simpler, more feature-rich and store-sync ready\n\n\nnext:\n\nContinue onchain merkle proofs PoC + paper\nWaku Sync overview finalization and Sync protocol first draft\naddress review comments, refine design of new Store protocol\n\n\nblocked:\n\nMerkle proofs from onchain blocked by this suspected bug in zk-kit\n\n\n\nnwaku §\n\nachieved:\n\nREST endpoint can serve its own messages as well as act as store-client\nadd simple dictionary with known words so that cSpell doesn’t complain\nworked on how to make the tests not to core dump\nstart creating basic py-waku structure that allows to create a py-waku module that can be imported in Python projects.\nstart using nph formatter extension\nPR is under review - covers LightPush and Store request rate limiting\n“bug fix” in README.md\nAdd new panel to show num msgs per shard\napplied all the feedback from the reviews. Changed the validation logic in our codebase so that the same validator runs for all pubsub topics. Applied fixes for autosharding endpoint. Merged PRs, closed issue.\nfixed decoding error when trying to send a message with the new meta field\nadded debug logs in nim-websock dependency and reproduced the issue with them for further investigation\nhelped debug and find root cause of a long-standing failed test for dynamically added pubsub topics\nmerged better error handling when cluster id and shards are used\nmerged sharded peer manager experiment\nmerged vendor bump for version 0.25.0\n\n\nnext:\n\nfinalize demo implementation (demo in terms uses Presto un-released feature) on refactor Waku RestService to utilize middleware approach and solve CORS headers issue.\nprepare Release 0.25.0 release and test it.\nwrap up the py-waku repository and make it clear that it is a PoC and is not going to be continued in short-term.\nwait until the 0.4 version of the nph extension is released and then we perform the actual migration.\nadd metrics and dashboard, update configuration doc\ndebug failed tests\n\n\n\njs-waku §\n\nDecouple sharding logic from internal classes to SDK\nachieved:\n\nSDK functions for creating a subscription to a content topic using a callback or returning a stream\n\n\nnext:\n\nfunction like above but starts a node with default settings as well\n\n\nblocker:\n\nremove requirement to pass a peer ID to above function\n\n\n\ngo-waku §\n\nachieved :\n\nSupport getting peers by shard via PeerExchange\nIdentified some improvements/changes to be done in go-waku based on status use-case to status-go feat: notify app when peer scores for all connected relay peers goes below thresholds & feat: Report shard/pubsubTopic specific connection health/status\nAdded rate limiter option to lightpush\nAdded support for multiple public keys per topic (likely to not get merged due to issues found)\n\n\nnext:\n\nImplement\n\n\n\nChatSDK §\n\nachieved:\n\nClarify the data flow for a community creation when external operator is paid to provide resources\n\n\nnext:\n\ncontinue store rfc reviews, continue analysis of filter unsubscribe issue\ncontinue permissionless communities setup\n\n\n\nEcoDev §\nDocs §\n\nachieved:\n\nspell check has been integrated into the research and nwaku repos\n\n\nnext:\n\nre-review the linked PR and close it\n\n\nblocker:\n\nI’ve been unable to get the noise-js example to pair with another peer\n\n\n\nEcosystem Development §\n\nachieved:\n\nRecorded 2 builder spotlight videos\nAdded faqs\nStarted drafting the optimism grant proposal\nLogos x HOPR space, Web3Privacy, 30 days of web3\n\n\nnext:\n\nTidied up metrics dashboard and host it with help from vaclav/infra\nCreate rln/node setup cheatsheet\nPrepare for ethdenver\nKick off out-of-band node incentivization discussion\n\n\n\nSolutions §\nPrometheus metrics view\n\nachieved:\n\nbasic metrics (num of connectable nodes and avg ping) added to the dashboard\n\n\nnext:\n\nmodify NetworkMonitor to work with The Waku Network\n\n\n\nStatus Integration §\n\nachieved:\n\nInvestigated and found out root-cause for message loss issue identified in status-desktop\nInvestigated and found out root-cause for message loss issue identified in status-mobile CI\nReview status-go usage of Waku to identify improvements/changes\nfixed missing cluster ID in node config\nadded peer count to logs when sending msg via relay\nfixed history sync regardless of using a data plan or wifi\nfix: full nodes will run filter and lightpush\n\n\nnext:\n\nSupport status integration in case of message loss or Waku related issues\nContinue reviewing status-go code from Waku usage perspective of sharding\nContinue working on bug fixes or issues related to status-go x waku integration\n\n\n"},"waku/updates/2024-02-19":{"title":"2024-02-19 Waku Weekly","links":[],"tags":["waku-updates"],"content":"This update covers the two week span between February 5th -19th.\nresearch §\n\nachieved:\n\nCreated a C wrapper API for negentropy and moved it as a submodule into nwaku https://github.com/waku-org/negentropy/pull/2, https://github.com/waku-org/nwaku/pull/2448\nRerun nwaku latency measurements with latest nwaku release + new plots: https://github.com/waku-org/research/pull/86\nDraft for “practical use of rln in gossipsub” paper ready, peer review ongoing.\nfurther work in PoC incentivization https://github.com/waku-org/nwaku/pull/2419\nonboarding and local ethereum chain tools research\nOpened up the discussions of waku as a sovereign chain: https://github.com/waku-org/research/issues/84\nWaku latency simulations in a real environment: https://github.com/waku-org/research/pull/85\nWork on practical usage of rln in gossipsub paper: https://github.com/waku-org/research/pull/82\nBenchmarked rln in different platforms: https://github.com/waku-org/nwaku/pull/2410\nimplemented the first version of a codec for incentivization PoC: https://github.com/waku-org/nwaku/issues/1961\nresearch post tidying, negentropy C++ bindings first draft, https://github.com/waku-org/research/issues/80 https://github.com/waku-org/nwaku/pull/2403\nrefined new Store protocol design based on community input https://github.com/waku-org/research/issues/81\n\n\nnext:\n\nimprove the C API and integrate into nwaku and test the integration\ncontinue modifications in zk-kit library to allow onchain merkle proofs: https://github.com/privacy-scaling-explorations/zk-kit/pull/162\nPoC implementation and research papers - continued\ndeploy local ethereum chain for waku-simulator https://github.com/waku-org/waku-simulator/issues/17\nResume work on onchain proofs, upstream bug fixed\nAnalyze data + report on latency simulations\ngather feedback, continue PoC implementation; plan working on the academic conference submission (Waku poster)\nnegentropy C++ bindings continues\nmore reviewers and comments, gain consensus, start plan for PoC implementation https://github.com/waku-org/research/issues/81\n\n\n\nnwaku §\n\nachieved:\n\nNwaku Sync protocol bindings improvements https://github.com/waku-org/nwaku/issues/2426\nNwaku Store v3 first draft\nfound fixes for keystore generation error and for running nwaku-compose without keystore. Validated fixes, and merged both PRs. Closed issue https://github.com/waku-org/nwaku-compose/issues/32\ndesigned and started refactor https://github.com/waku-org/nwaku/issues/2441\nimplemented fix, opened PR, improved the solution after feedback and merged https://github.com/waku-org/nwaku/issues/2406\nimplemented feedback and merged https://github.com/waku-org/nwaku/issues/2214\napply PoC to handle disk through partitions management https://github.com/waku-org/nwaku/issues/1885\nshare knowledge on waku-nodejs-bindings https://github.com/waku-org/nwaku/issues/2420\naccept base64 payloads; make private key optional by generating a random one if not defined; simplified error handling. https://github.com/waku-org/nwaku/issues/2420\npublish and subscribe to waku messages using nwaku, fixed event callback setup. https://github.com/waku-org/waku-rust-bindings/pull/87\nHelped to define the C-bindings milestone https://github.com/waku-org/pm/issues/121\nsimpler ctx mgmt. Param now receiving void* instead of void** https://github.com/waku-org/nwaku/pull/2398\noverview the partition approach https://github.com/waku-org/nwaku/issues/1885\ndefined part of bindings milestone with emphases in go (for status-go) and rust https://github.com/waku-org/pm/issues/121\nstarted the integration of nwaku with waku-rust-bindings, compiling and doing FFI nwaku succesfully. https://github.com/waku-org/pm/issues/121\nadded support to yamux https://github.com/waku-org/nwaku/issues/2331\nfinished implementation, debugged and fixed failed tests, opened PR https://github.com/waku-org/nwaku/issues/2214\nimplemented solution, opened PR, implemented feedback and merged https://github.com/waku-org/nwaku/issues/2349\ninvestigated, tried to reproduce. Found out that it got unintentionally fixed by a recent PR, closed issue https://github.com/waku-org/nwaku/issues/2371\ngetting introduced to our C-bindings codebase https://github.com/waku-org/pm/issues/121\nPR is under review - covers LightPush and Store request rate limiting next: fix nim-chronos’ TokenBucket wrong replenis. https://github.com/waku-org/nwaku/issues/2032\nRC release done, test has ran, changelog done https://github.com/waku-org/nwaku/issues/2402\n\n\nnext:\n\ncontinue with the refactor https://github.com/waku-org/nwaku/issues/2441\narchive update to fullfill Store v3 requirements https://github.com/waku-org/nwaku/issues/2425\nmanual tests to ensure it works properly https://github.com/waku-org/nwaku/issues/1885\nexpose additional bindings functions and add function to free alloc memory https://github.com/waku-org/waku-rust-bindings/pull/87\nContinue defining C-binding epics https://github.com/waku-org/pm/issues/121\ntry the “partition table” implementation approach plus “partition truncate”. https://github.com/waku-org/nwaku/issues/1885\nexpose existing nwaku’s bindings functions and test rust-bindings. Investigate packaging nwaku for mobile. https://github.com/waku-org/waku-rust-bindings/pull/87\nlast mile of implementation (demo in terms uses Presto un-released feature) on refactor Waku RestService to utilize middleware approach and solve CORS headers issue. https://github.com/waku-org/nwaku/issues/2223\n\n\nblocker:\n\nPostgres doesn’t provide a native mechanism to limit the maximum stored size. If the partition+truncate approach doesn’t work properly, we will dismiss the “size” retention policy and just keep the “capacity” and “time” for Postgres. https://github.com/waku-org/nwaku/issues/1885\n\n\n\njs-waku §\n\nachieved:\n\nimplemented and merged @waku/local-discovery to store healthy connected peers in the local state, and use these peers to connect with when an application restarts https://github.com/waku-org/js-waku/issues/1463\nreplaced all use of nwaku’s deprecated JSON RPC API with REST API https://github.com/waku-org/js-waku/issues/1826\nadded SDK functions for creating a node and subscription given a peer id and content topic https://github.com/waku-org/js-waku/issues/1764\nmade improvements based on feedback and merged decoupling of sharding logic out of core protocol logic https://github.com/waku-org/js-waku/issues/1808\nfinished SDK function for creating a subscription (with or without a node) using a content topic and peer id next: implement fixes/improvements from review https://github.com/waku-org/js-waku/issues/1764\n\n\nnext:\n\ncycling stored peers with new peers (discover new peers with peer-exchange) to increase decentralisation\norient protocol implementations to be strictly based on the RFCs https://github.com/waku-org/pm/issues/114#issuecomment-1934535353\nmove WakuNode class to SDK with above functions as private class functions\n\n\n\ngo-waku §\n\nachieved:\n\nexecuted a version of bindings with updated dependencies in go-waku for a couple of days to confirm memory leak is gone. https://github.com/waku-org/waku-rust-bindings/issues/86\narrive at approach and implement topic connection health reporting based on sharding https://github.com/waku-org/go-waku/issues/1021\ninitial version of client side for storev3 https://github.com/waku-org/go-waku/pull/1028\n\n\nnext:\n\nrelease a new version of rust bindings\n\n\n\nchat-sdk §\n\nachieved:\n\ndraft the comparison doc about build client with REST API\nattempting to merge: https://github.com/status-im/status-go/pull/4532\ncreating test code for the selection of store nodes in communities: https://github.com/status-im/status-go/issues/4357\n\n\n*next:\n\ncontinue work on the sending messages with cli\nplan next permission-less community tasks\n\n\n\neco-dev §\n\nachieved:\n\nevents page\npresentation for ETHLATAM\nworking on metrics dashboard https://github.com/waku-org/metrics.waku.org/issues/14\ndeployed the research section of the docs https://github.com/waku-org/docs.waku.org/issues/155\nadded the new filter configurations per nwaku 0.25.0 release https://github.com/waku-org/docs.waku.org/pull/158\nSecret Network space\nminor tweak to nwaku metrics https://github.com/waku-org/nwaku/pull/2430\nupdated instructions, added ENV file configuration, recommended docker as the default way to run nodes https://github.com/waku-org/docs.waku.org/issues/154\nsome repo org for waku metrics and restarted supabase https://github.com/waku-org/metrics.waku.org/issues/6\nworkshop and prize descriptions handed over to ethlatam\ncomposing cheatsheets for RLN membership and how to run a node\nnetworkmonitor now supports RLN and thus can be deployed for The Waku Network https://github.com/waku-org/nwaku/pull/2401\ntested and provided a minor fix for py-waku, create new issues for cbindings based on this https://github.com/waku-org/py-waku/pull/1\n\n\nnext:\n\ncomplete metrics dashboard improvements, start drafting protocols comparison blog and send presentations to comms for review\nfinish up the FAQ section for the docs platform https://github.com/waku-org/docs.waku.org/issues/152\ndeploy the new pages on the docs https://github.com/waku-org/docs.waku.org/pull/166\nreview PR https://github.com/waku-org/research/pull/83 to add cspell to the research repo\nsome ui improvements in the metrics dashboard\ncommunity call agenda for february\nethlatam presentation\nblog post : unbiased comparison of web3 communication protocols\ndeploy new version of NM, add new metrics to internal and public dashboards\n\n\n\nwaku-status-integ §\n\nachieved:\n\ninvestigate contact ack loss issue identified in mobile-CI after filter-manager PR https://github.com/status-im/status-mobile/pull/18769\n\n\nnext:\n\nsupport status integration in case message loss or Waku related issues\n\n\n"},"waku/updates/2024-04-26":{"title":"2024-04-26 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Research Milestones §\nStore Incentivisation\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/17\n\nachieved: discuss incentivization with Akhil\nnext: plan out incentivization PoC (Lightpush instead of Store?)\nblockers: (no longer a blocker) the deadline for the academic paper final version\n\n\n\nRLN in resource-restricted clients\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/18/views/1\n\nachieved: New Merkle tree integration (LazyIMT) integrated https://github.com/alrevuelta/go-waku-light/pull/2 and new version of contract using said tree https://github.com/vacp2p/rln-contract/pull/31 (with Ar. help). PoC ready to get Merkle proofs from the contract using the finally merged https://github.com/privacy-scaling-explorations/zk-kit/pull/162. With this tree, we can assume the increase in gas cost and in exchange we get roots and merkle proofs onchain.\nnext: Continue work in go-waku-light and prepare an end to end PoC to showcase this new feature. Write a report with findings and tradeoffs for future reference.\nblocker: “VacRlnContract” is not compatible with “WakuRlnContract”. This https://github.com/vacp2p/rln-contract/pull/31 should be adapted to work with waku nodes (required for the PoC). Awaiting Vac’s support.\n\n\n\nRLNv2\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/21/views/1\n\nachieved: merged PR to remove go-waku from waku-simulator\nnext: update to RLNv2\nblockers: deployment still not working on wakusim host, but there is an issue for infra to debug and I can continue by using the wakudev host\n\n\n\nStore v3 - Waku Sync\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/20/views/1\n\nStore v3 - message hashes\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/16/views/1\n\nStatus Integration §\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/5/views/2\n\nin-progress:\n\n[nwaku] Add logging of hashes to all nodes\n\n\n\n\n\nEngineering Milestones §\nJSON RPC Deprecation\n\nStatus: Completed\nProject: https://github.com/orgs/waku-org/projects/8/views/1\n\nComposing Waku Protocols to Improve Reliability\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/9/views/1\n\ncompleted:\n\n[js-waku] chore: protocol implementations in @waku/core should be as unopinionated as possible\n\n\nin-progress:\n\n[js-waku] feat: Store reliability\n\n\n\n\n\nOperator Feature Requests\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/13/views/1\n\ncompleted:\n\n[nwaku] chore: detailed json report on /health endpoint\n[nwaku] chore: Extend node isReady with more mature checks and result returned\n\n\n\n\n\nBindings (Rust, NodeJS, Golang)\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/6/views/6\n\nin-progress:\n\n[nwaku] chore: migrate DiscV5 and DNS Discovery from app.nim to waku_node.nim\n\n\nnext:\n\n[nwaku] chore: support setting DiscV5 and DNS-discovery in libwaku\n\n\n\n\n\nNode Bandwidth Management Mechanism\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/11\n\nin-progress:\n\n[js-waku] feat: prefer error code for req-res protocol over exception\n\n\n\n\n\nOther Work §\nBugs §\nIn Progress §\n\n[js-waku] bug: lightPush is not able to keep node connections\n[js-waku] bug: remote peer fault\n[js-waku] bug: filter subscription stops without occasional pings\n[nwaku] bug: wakunode2 systemd unit restarts about 10-15x per day\n[nwaku] bug: SIGSEGV with RLN\n[nwaku] bug: build error on new AMD cpu’s (ubuntu 22.04 LTS)\n[nwaku] bug: Peer Reconnection not working?\n[nwaku] bug: nwaku <> js-waku interop tests failing\n\nNext §\n\n[nwaku] bug/regression: node ca be started on multiple clusters\n[nwaku] bug: autosharding resolves content topics to wrong shard\n[nwaku] bug: Store REST API returns invalid digest\n\nEnhancements §\nIn Progress §\n\n[nwaku] chore: review waku-simulator deployment and improve tracking processes\n[nwaku] feat: add WakuMessage’s meta field to db schema\n[nwaku] chore: Address more attack vectors in rate limiting non-relay protocols\n[js-waku] feat: filter.createSubscription accept ShardParams\n\nNext §\n\n[js-waku] chore: move to js-waku repo\n[js-waku] feat: better developer experience\n\nEcosystem Development §\nBD §\n\nCalls with prospects\nAdvancing ongoing going leads\nQualified prospects\nCreated a validation tracking database\nEvent planning done for the upcopming quarters\n\nSolution Engineering §\n\nWorking on slides for talks in May/June\nTrying to get js-waku working in projects again - so far resulted in filed issues\nupdated nwaku to 0.27.0 in awesome-akash\ncalls with BD\nassisting Portrait with some architectural decisions\nassisting Dria with nwaku REST API\n\nDev Rel §\n\ntoken2049 (20+ leads)\nlibp2p rpgf nomination completed\nsorting out ethdenver leads, sorting out crm\ndrafting Railgun blog article\nforwarding portrait.so interview to comms\ninterview preparation for Railgun <> waku\nEthdam feedback/summary\n\nComms and Events §\n\nX: 1441 new followers ( +11%), 47.8% engagement rate ( +58%), 15889 likes (+47%) - we hit 10k on Twitter - yay!\nLinkedin: 11 new followers\nDiscord: +44 (2.6%)\n1 PR went live, about W3PN and Logos, mentioning Waku - https://cointelegraph.com/press-releases/logos-partners-with-web3privacy-now-to-advance-digital-privacy\nWe’v interviewed Portrait founder at ETHDam - video sent for editing\n\nEvents §\n\nIvan gave a presentation and spoke at the panel at https://web3fc.xyz/\nGuru attended token2049\nETHDam summary doc - https://docs.google.com/document/d/1kgR8q-WMWJ56kGav6MiFYqkA2eDudc_lFUpdYM3sQ8s/edit and photos\n\nDocs §\n\nmerged the general FAQ\ndeprecated the JSON-RPC RFC spec\nWaku RFC website followup\n"},"waku/updates/2024-05-15":{"title":"2024-05-15 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Research Milestones §\nStore Incentivisation\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/17\n\nin-progress:\n\n[nwaku] feat: experimental incentivize store protocol\n\n\n\n\n\nRLN in resource-restricted clients\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/18/views/1\n\nachieved: PR for message validation in lightpush before relaying.\nnext: continue lightpush attaching RLN proofs to messages received from clients.\n\n\n\nRLNv2\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/21/views/1\n\nachieved: Test implementation WIP.\nnext:\n\nContinue planning for next waku fork (RLNv2 + onchain root/proofs) See: https://github.com/waku-org/research/issues/96 (future section). RLN v2 testing. New smart contract with both features. Prepare presentation for DLT conference.\nTest implementation continued and testing.\n\n\n\n\n\nStore v3 - Waku Sync\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/20/views/1\n\nachieved:\n\nExplored if there is a way to prune the negentropy storage based on timestamp.\nTtype state machine implementation and pruning mechanism.\n\n\nnext:\n\nwrite subrange wrappers for negentropy and use subranges to sync.\nusing hashes to fill the archive with the missing messages.\n\n\n\n\n\nStore v3 - message hashes\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/16/views/1\n\nachieved:\n\nbug fixes\n\n\nnext:\n\nfix compatability with Waku sync\n\n\n\n\n\nEngineering Milestones §\nComposing Waku Protocols to Improve Reliability\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/9/views/1\n\ncompleted:\n\n[js-waku] refine Filter\n[js-waku] chore: protocol implementations in @waku/core should be as unopinionated as possible\n[js-waku] feat: SDK for redundant usage of filter/lightpush\n[js-waku] bug: lightPush is not able to keep node connections\n[js-waku] https://github.com/waku-org/js-waku/issues/2002\n\n\nin-progress:\n\n[js-waku] feat: peer management for protocols (with disconnection management)\n\n\nnext:\n\n[js-waku] investigate suspended js-waku in suspended mode\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/11/views/1\n\ncompleted:\n\n[nwaku] chore: Address more attack vectors in rate limiting non-relay protocols\n\n\nin-progress:\n\n[nwaku] feat: Rate limit phase#3 - peer request rate registration and prioritization\n[nwaku] feat: Proper bandwidth metrics per shard\n[nwaku] feat: Enforce service specific rate limits\n\n\nnext:\n\n[nwaku] feat: Failsafe mechanism (guide) for BW limiting\n\n\n\n\n\nBindings\n\nStatus: In Progress\nProject: https://github.com/orgs/waku-org/projects/6/views/6\n\n[nwaku] chore: support setting DiscV5 and DNS-discovery in libwaku\n\n\n\nOther Work §\nBugs §\nIn Progress §\n\n[js-waku] feat: map/use correct bootstrap nodes fleet according to the configured pubsub topic\n[js-waku] test: create scripts for running light-push/filter and measuring ratio of messages sent and received\n[nwaku] bug: flaky test fails on MacOS\n[nwaku] bug: nwaku <> js-waku interop tests failing\n[nwaku] bug: Peer Reconnection not working?\n[nwaku] bug: build error on new AMD cpu’s (ubuntu 22.04 LTS)\n[nwaku] bug/regression: node ca be started on multiple clusters\n\nNext §\n\n[js-waku] bug: ApplicationInfo to PubsubTopic doesn’t take clusterId into consideration\n[nwaku] bug: Deserialization error on POST /relay/v1/auto/messages with ephemeral field in body\n[nwaku] bug: running testwaku can hang in some cases of UPnP or nat-pmp networking\n[nwaku] bug: Store REST API returns invalid digest\n[nwaku] bug: autosharding resolves content topics to wrong shard\n\nEnhancements §\nIn Progress §\n\n[js-waku] feat: map/use correct bootstrap nodes fleet according to the configured pubsub topic\n[nwaku] feat: light protocol tester application\n\nNext §\n\n[js-waku] feat: improve reuse of pubsub/content topic configuration\n[js-waku] feat: better developer experience\n[nwaku] feat: RLN-proofs as a lightpush service\n[nwaku] Add a flag to require minimum number of peers to publish a message on relay\n\nEcosystem Development §\nBD §\n\nQualified two leads\nAdvanced one lead toward deal\nSet up two meetings with potential partners\n\nDev Rel §\n\nThe Waku Network hit 500 nodes - yay!\nEvents page update\nThe Graph blog article draft\nThe Graph interview\n\nComms and Events §\n\nX: +489\nLinkedin: +7\nDiscord: +44\nWaku intro finalized - https://www.youtube.com/watch?v=nIWx5Vp_Qxk\n2 “how to run nodes” tutorials went live\nPublished Montly newsletter\nRailgun interview went live\nBuilder Spotlight went live\n\nDocs §\n\nImplemented a script on waku.org for automatic creation and updating of the specs section\nSubmitted a pull request to the specs repository to fix broken links and adjust the front matter\nGot the specs repo PR approved and merged Follow up with Hanno on RFC website plans Added high level overview of waku simulation results\n"},"waku/updates/2024-06-24":{"title":"2024-06-24 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[nwaku] PR bug fixes\n[chat] hash based query for outgoing messages https://github.com/status-im/status-go/pull/5217\n\n\nblockers:\n\n[chat] awaiting reviews\n[chat] unable to reproduce CI failures\n\n\n\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[nwaku] waku-simulator testing\n[chat] Dogfooding and fixes for routine that checks for missing messages https://github.com/status-im/status-go/pull/5281\n\n\nblockers:\n\n[chat] awaiting reviews\n[chat] unable to reproduce CI failures\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] Rate limit phase3: implemented per peer request rate checks\n[nwaku] BW metrics per shard: implemented per shard metric collection\n\n\nnext:\n\n[nwaku] Rate limit phase3: Some polishing and test cases needed to finish\n[nwaku] Rate limit phase3: add rate limit metrics to dashboard\n[nwaku] BW metrics per shard: needs some tests and add section onto dashboard\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] enhance partition creation: https://github.com/waku-org/nwaku/issues/2783\n[nwaku] validate that time retention policy works well: https://github.com/waku-org/nwaku/issues/2807\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nEnable testing of direct messages\n\nachieved:\n\n[chat] set up nightly tests & 1:1 messages tests https://github.com/status-im/status-cli-tests/pull/1\n[chat] set up nightly tests for contact requests https://github.com/status-im/status-cli-tests/pull/3\n[chat] CLI bugs and improvements for usage in nightly tests https://github.com/status-im/status-go/issues/5266\n\n\nnext:\n\n[chat] set up nightly tests for group chats and community join requests\n[chat] investigate remaining tests failing\n\n\n\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] Pause peer connector if node is offline https://github.com/status-im/status-go/pull/5340, https://github.com/waku-org/go-waku/pull/1125\n[chat] Fix usage of context for DiscV5 https://github.com/status-im/status-go/pull/5347\n[chat] Fix in status-go to filter peers by shard\n[chat] Dogfood light client with peer exchange enabled\n\n\nnext:\n\n[chat] Investigate / fix DiscV5 not finding valid peers in shards.test fleet\n[chat] make filter working along with peer exchange and debug connectivity issues with peers returned via peerExchange\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[nwaku] lite-protocol-tester works on waku-simulator\n[nwaku] configurable stress conditions\n[nwaku] intensive stress test had been ran (45 nodes (relay + service nodes) + multiple publisher light client and a filter client receiver)\n[nwaku] ran with different conditions\n[nwaku] in co-op with Alberto analyzing topology and message flows\n\n\nnext:\n\n[nwaku] exclude docker limitations from the seen failed message deliveries\n\n\n\n\n\nTelemetry: direct message reliability\n\nachieved:\n\n[nwaku] implemented two different ways to log received message information. One based on libp2p observers https://github.com/waku-org/nwaku/pull/2800 which we won’t use in practice. And one by adding the logs in a new nim-libp2p branch https://github.com/vacp2p/nim-libp2p/pull/1128\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] started to look at the current status-go implementation\n\n\nnext:\n\n[nwaku] carry on with the implementation in nwaku - https://github.com/waku-org/nwaku/issues/2819\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[chat] Improve filter subscription management in LightClient: various fixes wrt filter subscriptions and making lightNode work with peerExchange enabled https://github.com/status-im/status-go/pull/4665\n[chat] dogfooding light client in desktop\n[chat] fixed issue found while dogfooing, remove stale subs and update ping interval https://github.com/waku-org/go-waku/pull/1119\n[js-waku] improved peer management for light push protocol https://github.com/waku-org/js-waku/issues/2002\n[js-waku] worked on updating js-waku to store v3 https://github.com/waku-org/js-waku/issues/2029\n[js-waku] improving offline recoverability for Filter https://github.com/waku-org/js-waku/issues/2024\n\n\nnext:\n\n[js-waku] continue with moving to store v3 https://github.com/waku-org/js-waku/issues/2029\n[js-waku] continue with offline recoverability for Filter https://github.com/waku-org/js-waku/issues/2024\n\n\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\n\n[js-waku] settled on the base implementation of dogfooding app https://github.com/waku-org/lab.waku.org/pull/68\n\n\nnext:\n\n[js-waku] provide front end for dogfooding app\n[js-waku] provide basic telemetry framework\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] draft changes for reset MVDS epoch for online peers https://github.com/status-im/status-go/pull/5349\n\n\nnext:\n\n[chat] continue MVDS review https://github.com/orgs/waku-org/projects/33\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[nwaku] continued gathering wide input on e2e reliability proposal: https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/\n[nwaku] performed basic calculations to understand mathematical properties of proposed protocol, probabilistic model\n\n\nnext:\n\n[nwaku] stakeholders sync on next steps\n[nwaku] set scope for POC implementation\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] start testing and investigating discv5 performance and possible issues https://github.com/waku-org/nwaku/issues/2810\n[nwaku] started deep review of peer manager logic opened PR with small fix to be able to update peers’ ENRs https://github.com/waku-org/nwaku/pull/2818\n[nwaku] reproduced with DST team issues forming stable mesh https://github.com/waku-org/nwaku/issues/2780 and analyzed logs. Found that connections aren’t being answered and started investigating a prospective problematic place in the code.\n\n\nnext:\n\n[nwaku] continue with discv5 and peer manager investigations\n[nwaku] continue investigating issuer forming a stable mesh\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\nRLNv2 in nwaku\n\nachieved:\n\n[research] Published The Waku Simulator book: https://waku-org.github.io/waku-simulator/. It explains how to use waku-simulator to test different scenarios.\n[research] completed RLNv2 test plan, waku-simulator updates\n\n\nnext:\n\n[research] Integrate waku spammer: https://github.com/waku-org/nwaku/pull/2821\n[research] Assist with rlnv2 testing.\n[research] execute RLNv2 test plan\n\n\n\n\n\nOther Work §\nResearch §\n\n[Deliverable] Store Incentivisation (first iteration/POC)\n\n[research] achieved: opened a PR for a PoC incentivization testing: https://github.com/waku-org/nwaku/pull/2816\n[research] next: start outlining a minimal specification for RLN-as-a-service\n\n\n\nReliability §\n\nachieved\n\n[chat] Increase store query pagesize https://github.com/status-im/status-go/pull/5341\n[chat] Fix peer counter for statsu-desktop https://github.com/status-im/status-go/pull/5348\n[chat] Change order of rpc text input https://github.com/status-im/status-desktop/pull/15169\n\n\n"},"waku/updates/2024-07-01":{"title":"2024-07-01 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[chat] set lower max delivery attempts for outgoing messages https://github.com/status-im/status-go/pull/5382\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] BW metrics per shard: implemented per shard metric collection - https://github.com/waku-org/nwaku/issues/1945\n[nwaku] Added dashboard panels for relay per shard traffic\n[nwaku] Added dashboard panels for non-relay protocols data traffic\n[nwaku] Added dashboard panels for non-relay protocols request rates\n\n\nnext:\n\n[nwaku] Rate limit phase3: Some polishing and test cases needed to finish\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] analyse a database blocking issue: https://github.com/waku-org/nwaku/issues/2838\n\n\nnext:\n\n[nwaku] fix database blocking issue with solution detailed in https://github.com/waku-org/nwaku/issues/2838\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nEnable testing of direct messages\n\nachieved:\n\n[chat] small logging cli issue\n[chat] testing private group chats https://github.com/status-im/status-cli-tests/pull/4\n\n\n\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] investigating connectivity and discv5 issues\n[chat] fix peerExchange to filter peers by shard https://github.com/status-im/status-go/pull/5350/\n[chat] filter peers used for circuit-relay based on shards https://github.com/waku-org/go-waku/pull/1130\n[chat] Dogfood lightClient by enabling peerExchange\n\n\nnext:\n\n[chat] missing messages verification https://github.com/status-im/status-go/pull/5281\n[chat] store node query after sleep https://github.com/status-im/status-go/pull/5422\n[chat] investigate further peer connectivity issues by dogfooding\n[chat] refactor peer-manager for lightClient\n[chat] remove limit on connections when using relay\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[chat] lite-protocol-tester works on waku-simulator\n[chat] configurable stress conditions\n[chat] re-run some critical test for nicer logs for analysis\n[chat] analysed run results\n[chat] waku dogfooding telemetry https://github.com/status-im/telemetry/pull/20\n\n\nnext:\n\n[chat] new run with analysis on Alberto’s log analysis tool\n[chat] run lite-protocol-tester on shards.staging\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] started the implementation in nwaku - https://github.com/waku-org/nwaku/issues/2819\n\n\nnext:\n\n[chat] spec the reliability protocol for relay\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[js-waku] continued with using pool approach for protocols https://github.com/waku-org/js-waku/pull/2047\n[js-waku] store v3 migration https://github.com/waku-org/js-waku/pull/2036\n\n\nnext:\n\n[js-waku] complete ongoing efforts\n[js-waku] get back to offline state handling https://github.com/waku-org/js-waku/issues/2024\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] Improve MVDS: reset epoch for online users https://github.com/status-im/mvds/pull/5\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] Discovery on e2e reliability and bloom filters. Started working on a POC on a standalone repo.\n\n\nnext:\n\n[research] move to go-waku and continue with the POC\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] analyse discv5 performance and possible issues https://github.com/waku-org/nwaku/issues/2810\n[nwaku] fixed issues forming mesh by DST team https://github.com/waku-org/nwaku/issues/2780 https://github.com/waku-org/nwaku/pull/2824\n[nwaku] Added small enhancements to the peer manager https://github.com/waku-org/nwaku/pull/2823, https://github.com/waku-org/nwaku/pull/2831\n[nwaku] Opened PR adding logs requested by DST for discv5 investigation https://github.com/waku-org/nwaku/issues/2841 https://github.com/waku-org/nwaku/pull/2811\n[nwaku] Opened PR adding peer origin information to the /admin/v1/peers REST endpoint https://github.com/waku-org/nwaku/pull/2848\n\n\nnext:\n\n[nwaku] continue with discv5 and peer manager investigations\n[nwaku] Implement a permanent customizable logging solution for nim-libp2p\n[nwaku] deprecate named sharding\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nRLNv2 in nwaku\n\nachieved:\n\n[research] Various debugging and bug fixing, executing https://github.com/waku-org/pm/issues/168\n\n\nnext:\n\n[research] Deliver 0.30.0 with RLNv2 in nwaku\n\n\n\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\n\n[research] RLNv2 debugging, test plan, waku-simulator updates\n\n\nnext:\n\n[research] RLNv2 release candidate testing\n\n\n\n\n\nProvision RLN for light push clients PoC\n\nachieved:\n\n[research] continued testing of merged feature\n\n\nnext:\n\n[research] deploy service to existing fleets and dogfood with js-waku\n\n\n\n\n\nPay for RLN provision first PoC\n\nachieved:\n\n[research] PR for incentivization PoC (without on-chain interaction yet)\n\n\nnext:\n\n[research] add on-chain interaction to the PoC - txid lookup as proof of payment\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[chat] status-go: expose wakuext_enr\n[chat] use UTC format for geth.log timestamp\n[chat] use IP addresses instead of dns to store multiaddresses\n[chat] waku enr decoder tool https://github.com/waku-org/enr-decoder/\n[js-waku] remove relay dependency https://github.com/waku-org/js-waku/pull/2040\n\n\n\nBugs §\n\nachieved:\n\n[chat] do not write tcp port 0 and remove 100 chars length limit for multiaddresses\n[chat] fix ctx not available when starting telemetry client\n[nwaku] Mount Metadata in wakucanary https://github.com/waku-org/nwaku/issues/2720\n[nwaku] duplicate message forwarding to filter client https://github.com/waku-org/nwaku/issues/2320\n\n\nnext:\n\n[nwaku] peer exchanges return nodes that no longer exist. - https://github.com/waku-org/nwaku/issues/2414\n\n\n"},"waku/updates/2024-07-08":{"title":"2024-07-08 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] take up reported bugfixes after afk; continue with service rollout\n[chat] tuning store hash query to shorten the confirmation time of outgoing messages Reset MVDS epoch after peer is online\n\n\nnext:\n\n[research] start with storev3 benchmarking test plan\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[Epic: nwaku] Node Bandwidth Management Features\n\nBW metrics per shard: implemented per shard metric collection - feat: Proper bandwidth metrics per shard\nAdded dashboard panels for relay per shard traffic\nAdded dashboard panels for non-relay protocols data traffic\nAdded dashboard panels for non-relay protocols request rates\n\n\n[nwaku] feat: Enforce service specific rate limits\n\nFinalizing last phase of the feature:\n\nAdded per peer filtering of high users\nFilter service specific limits for ping and subscribe per peer\n\n\n\n\n\n\nnext:\n\n[nwaku] [Epic: nwaku] Node Bandwidth Management Features\n\nAdd distinction between gross/net inbound traffic of shards.\n\n\n[nwaku] feat: Enforce service specific rate limits\n\nfinish testing, add more unit tests\n\n\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] new issue to create sonda tool, a canary for store services: chore: create sonda tool\n\n\nnext:\n\n[nwaku] start implementation of sonda tool\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] feat: filter peers stored in cache by cluster-id in peer-exchange\n[chat] feat: expose router and mesh peers to obtain list of peers in mesh\n[chat] improve relay peer connectivity and refactor peerManager to support lightMode feat: modify peer-manager to consider relay target peers\n[chat] enable peerExchange in relay for better peer discovery chore: enable pxClient in relay and increase relay peer connections\n[chat] fix peerExchange peer source and enable peerExchange in lightClient fix: enable pxclient and filter peerExchange peers returned\n[chat] query store node when back from sleep: missing communityRequestToJoin message\n[chat] IMO of what to do regarding receive reliability: Receive message reliability for Status desktop\n\n\nnext:\n\n[chat] expose rpc methods to obtain list of peers by topic, and list of peers in mesh\n[chat] lightClient topic health reporting and peer connectivity improvements\n[chat] when back online only request from store node since last time not 24 hours\n[chat] investigate connection management for outgoing messages\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[chat] optimize filter subscriptions by aggregating them feat: optimize filter subs and feat: aggregate filter subscriptions to do bulk subs with peer\n[nwaku] stress test on waku-simulator\n\n\nnext:\n\n[nwaku] add rln support\n[nwaku] run lite-protocol-tester on shards.staging\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[chat] draft reliability for relay protocol spec feat: reliability for relay protocol\n[nwaku] carry on with the implementation in nwaku - feat: enhance reliability thanks to StoreV3\n\n\nnext:\n\n[chat] continue with the reliability protocol\n[nwaku] submit first PR in nwaku - feat: enhance reliability thanks to StoreV3\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[nwaku] Accepted new lightpush protocol definition with detailed fail case support - Enhance light push protocol\n[js-waku] filter uses dynamic peer management feat(filter): peer/subscription renewal with recurring Filter pings\n[js-waku] reliability with renewals due to offline state feat!: improve offline state handling for Filter subscription\n[js-waku] reliability RFC Add “req-res protocol reliability” spec\n\n\nnext:\n\n[nwaku] Implement: feat: Enhance lightpush protocol error handlingwaku-org/nwaku/issues/2722\n[js-waku] reliability RFC Add “req-res protocol reliability” spec\n[js-waku] reliability with renewals due to offline state feat!: improve offline state handling for Filter subscription\n\n\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\n\n[js-waku] minor improvements to feat: add first version of dogfooding app and getting unblocked with latest nwaku release\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] reset MVDS epoch after peer is back online Reset MVDS epoch after peer is online\n\n\nnext:\n\n[chat] continue mvds review\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] started exploring POC in go-waku as an example application\n[research] researched Vac’s de-MLS protocol for possible integration\n\n\nnext:\n\n[research] continue with the POC starting with a minimal working version first\n\n\nblockers:\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] added origin of peers in admin rest endpoint as per request, to debug and further understand discovery performance chore: adding origin to peers admin endpoint\n[nwaku] discussed with nim-libp2p team and tested a version of logging errors on publish to understand how often messages are not sent without returning errors\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nRLNv2 in nwaku\n\nachieved:\n\n[research] RLNv2 config for the Waku Network: chore: add TWN parameters for RLNv2\n[research] bug fix in RLN, vulnerability: fix(rln): nullifierlog vulnerability\n\n\nnext:\n\n[research] assist to deploy 0.30.0 release and integrate it in The Waku Network\n\n\n\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\n\n[research] continuing the execution of RLN in resource-restricted network: [Epic: Dogfooding] Deliver RLN v2 + RLN in resource-restricted to The Waku Network\n[research] simulations using the waku simulator for different purposes\n[research] expanded RLNv2 testing, assisted with simulating and debugging vulnerabilities\n\n\nnext:\n\n[research] assist to deploy 0.30.0 release and integrate it in The Waku Network\n[research] complete execution of RLNv2 test scenarios\n\n\n\n\n\nPay for RLN provision first PoC\n\nachieved:\n\n[research] added chain interaction to incentivization POC\n\n\nnext:\n\n[research] draft a specification for RLN mainnet deployment\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] deployment of release v0.30.1, which adds RLNv2\n[js-waku] prepare for next release\n\n\nnext:\n\n[js-waku] release last reliability improvements\n\n\n\nBugs §\n\nachieved:\n\n[chat] fix: panic due to enr having more than 300 bytes\n[chat] fix: ignore ws from circuit relay addresses, and allow non multiaddresses in multiaddrs ENR key\n[chat] fix failing wakuv2 tests\n[nwaku] bug: build error on new AMD cpu’s\n[nwaku] Various bug fixes:\n\nFrom chat team:\n\nbug: timestamp should be set to 0 if not provided in REST API\nbug: Store REST API returns invalid digest\n\n\nFrom Vac-QA:\n\nbug: Some PeerStore metadata is not filled in\nbug: PeerInfo instance affects listed protocols\nbug: Lightpush’s publish type error\nbug: Relay publish returns Failed to publish: timedout when a peer filter node is disconnected\nbug: Test failure on test_all\nhandle rln_msg_limit issue\n\n\nNim 2.0 readiness:\n\n[nwaku] bug: incorrect import paths pointing outside the repository\n\n\n\n\n\n\nnext:\n\n[nwaku] peer exchange returns nodes that no longer exist\n\n\n"},"waku/updates/2024-07-15":{"title":"2024-07-15 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] improved migration script & migration tests\n\n\nnext:\n\n[research] storev3 benchmark test plan\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] BW metrics per shard: implemented per shard metric collection feat: Proper bandwidth metrics per shard\n[nwaku] Added dashboard panels for relay per shard traffic\n[nwaku] Added dashboard panels for non-relay protocols data traffic\n[nwaku] Added dashboard panels for non-relay protocols request rates\n[nwaku] Finished and under review: feat: DOS protection of non relay protocols - rate limit phase3\n[nwaku] Added per peer filtering of high users\n[nwaku] Load balancing compensation applied to token replenish\n[nwaku] Filter service specific limits for ping and subscribe per peer\n\n\nnext:\n\n[nwaku] Separate add distinction between gross/net inbound traffic of shards.\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] Designed and implemented the first version of the Sonda tool chore: create sonda tool, which is about to open for review.\n[nwaku] Better partition creation approach to avoid database AccessExclusiveLock - fix: postgres_driver - better partition creation without exclusive access\n\n\nnext:\n\n[nwaku] Get Sonda reviewed and implement feedback\n[nwaku] Tackle the following so that the cursor bug is fulfilled chore(archive): archive and drivers refactor\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nEnable testing of direct messages\n\nachieved:\n\n[chat] chore: allow cli to run on a different fleet\n\n\n\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] refactor: ping a subset of connected peers, feat: bump go-waku to introduce new keep alive interval\n[chat] feat: wakuext_relayPeersByTopic\n[chat] fix: missing messages delay should be substracted\n[chat] feat: use mesh peers instead of all peers for determining topic health\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[chat] refactor and merge the spec for relay reliability feat: reliability for relay protocol\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[js-waku] RFC clarifications Add “req-res protocol reliability” spec\n[js-waku] peer cycling complete feat: peer management for protocols (with disconnection management)\n\n\nnext:\n\n[nwaku] Implement: feat: Enhance lightpush protocol error handling\n\n\n\n\n\nUser apps for large scale dogfooding\n\nblockers:\n\n[js-waku] waiting for release of nwaku 0.30.2\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] summarize the message types that are using MVDS\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] raised a draft PR for e2e reliability POC in go-waku with new message structure, lamport timestamp, bloom filter, buffer and sync\n\n\nnext:\n\n[research] ACK handling, request missing messages, resend message\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] investigating connectivity issues. Decreased connectivity loop interval chore: setting connectivity loop interval to 30 seconds\n[nwaku] final checks and deprecating named sharding chore: deprecating named sharding\n\n\nnext:\n\n[nwaku] Refactor code now that named sharding is removed, and deprecate pubsub-topic configuration\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nRLNv2 in nwaku\n\nachieved:\n\n[research] Completed milestone shipping RLNv2 and stateless light clients: [Epic: Dogfooding] Deliver RLN v2 + RLN in resource-restricted to The Waku Network\n\n\n\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\n\n[research] Blog post announcing the new feature: Post RLN-V2 + Stateless Light Clients\n[research] completed RLNv2 e2e testing\n\n\nnext:\n\n[research] Some work with go-waku-light to showcase stateless light clients in The Waku Network\n[research] Conference presenting Waku poster\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] bumped vendor dependencies for v0.31.0. Start using Nim 2.0.8 - chore: Bump dependencies for v0.31.0\n[chat] refactor: remove namedsharding usage in status-go refactor: only use shards\n[chat] fix : filter uninstall and reinstall issue in status-go fix: don’t resubscribe filters unless there is a change in shard for community\n\n\n\nBugs §\n\nachieved:\n\n[nwaku] bug: peer exchange returns nodes that no longer exist\n\n\nnext:\n\n[nwaku] bug: failed to retrieve peer info via peer exchange protocol\n\n\n"},"waku/updates/2024-07-22":{"title":"2024-07-22 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] Proof of concept of store testing with waku-simulator\n\n\nnext:\n\n[research] Storev3 test plan and integrating tools for testing\n\n\nblockers:\n\n[research] Some complexities around merging/testing, currently handled by nwaku team\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] BW metrics per shard: implemented per shard metric collection feat: Proper bandwidth metrics per shard\n[nwaku] Added dashboard panels for relay per shard traffic\n[nwaku] Added dashboard panels for non-relay protocols data traffic\n[nwaku] Added dashboard panels for non-relay protocols request rates\n[nwaku] Released feat: Enforce service specific rate limits\n\nAdded per peer filtering of high users\nLoad balancing compensation applied to token replenish\nFilter service specific limits for ping and subscribe per peer\n\n\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] Improved and merged Sonda - canary service to check liveness of store nodes\n[nwaku] Merged store-v3 cursor fix chore(archive): archive and drivers refactor\n\n\nnext:\n\n[nwaku] PostgreSQL query optimizations chore: query performance in PostgreSQL by avoiding ordering in queries\n[nwaku] PostgreSQL enhance retention policy: bug: retention policy does not work when postgres db is over loaded\n[nwaku] PostgreSQL enhance query performance chore: improve postgres query performance\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] feat: flag to enable/disable missing message verification\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[chat] added support for 2 lightpush peers to be used for better reliability feat: support for lightpush to use more than 1 peer\n[chat] fix metadata protocol from disconnecting light-clients and only use clusterID and accept connections from lightclients fix: for light node do not check for matching shards but only clusterID\n\n\nnext:\n\n[nwaku] Little enhancement for network connectivity, use bootstrap enr’s to connect to any kind of network and detect shardings\n[nwaku] Auto select service peers and use them randomly for testing on both sides.\n[nwaku] run lite-protocol-tester on shards.staging\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] started local sqlite registry implementation feat: enhance reliability thanks to StoreV3\n[chat] config to enable/disable storev3 confirmations for sent messages feat: flag to enable/disable sent message store query confirmations\n\n\nnext:\n\n[nwaku] carry on with implementation feat: enhance reliability thanks to StoreV3\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[js-waku] improved renewal of peers for Filter feat(filter): peer/subscription renewal with recurring Filter pings\n[js-waku] check for missing messages from Filter subscriptions feat: validate messages for individual filter nodes & perform renewals\n[js-waku] peer renewal and keep alive improvements feat: fix peer renewal, change Filter keep alive\n\n\nnext:\n\n[nwaku] Implementing: feat: Enhance lightpush protocol error handling\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] status messages need for e2e reliability collected\n[chat] fix_: delivered message should not send envelope sent signal\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] implemented ACK handling, request missing messages, resend message\n\n\nnext:\n\n[research] comprehensive tests for the poc\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[research] review of discv5 both spec and nim implementation\n[research] compiled audit of discovery status quo and potential future strategies\n[nwaku] Creating versions for DST team to test discv5 and message reliability\n[nwaku] Proposing new solution to log received message info from nim-libp2p. Created custom version for DST team to use chore: creating branch to test Waku’s received messages\n[nwaku] Started investigating and implementing improvements for connection management of bootstrap only nodes bug: Node accepts connections when configured for just discovery\n[nwaku] Improved logging chore: improving logging under debugDiscv5 flag, chore: logging content topic of spam messages\n[nwaku] Investigated at depth discv5’s implementation bug: discv5 not returning enough peers\n\n\nnext:\n\n[research] review other discovery methods and state of implementation in nim\n[research] review metrics collected and add more if needed\n[research] implement identified discv5 improvement strategies\n[nwaku] Get feedback on nim-libp2p’s logging solution\n[nwaku] Refactor code now that named shading is removed, and deprecate pubsub-topic configuration\n[nwaku] Continue discussing and analyzing discv5’s performance and possible improvements\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[chat] chore: rename shards.staging to status.staging\n[chat] chore: rename shards.staging to status.staging\n[chat] chore: bump go-libp2p\n[chat] enable metadata protocol regardless of cluster-ID used\n[js-waku] chore: enforce access modifiers\n[js-waku] chore: bump @waku peer dependencies\n[js-waku] improve network options handling chore: throw if more than one network config is passed\n\n\nnext:\n\n[nwaku] deploy release v0.31.0 Prepare release 0.31.0\n\n\n\nBugs §\n\nachieved:\n\n[chat] investigation of slowness to retrieve messages in storenode message counter\n[nwaku] Build nwaku image for Windows - feature: support Windows 11\n\n\nnext:\n\n[nwaku] Manage stale peers dynamically with better reliability fix: peer-exchange issue\n[nwaku] bug: failed to retrieve peer info via peer exchange protocol\n\n\n"},"waku/updates/2024-07-29":{"title":"2024-07-29 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] completed first draft of storev3 benchmark test plan\n\n\nnext:\n\n[research] implementing test tools, finalising test plan\n\n\nblockers:\n\n[research] not clear on HW setup on which benchmarking should be done\n\n\n\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[research] last online timestamp periodically saved to new sqlite db, store client query for last messages, tests\n\n\nnext:\n\n[research] reviews, hand-off to nwaku team for merging\n\n\n\n\n\nDOS protection for req-res protocols and metrics\n\nachieved:\n\n[nwaku] Node Bandwidth Management Features\n[nwaku] Enforce service specific rate limits\n[nwaku] Separate add distinction between gross/net inbound traffic of shards. chore: Distinction between gross/net trafic in bandwidth per shard metric\n\n\nnext:\n\n[nwaku] dogfooding\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] Improved Sonda’s Grafana dashboard chore: show relative metrics instead of absolute in Sonda\n[nwaku] Improved Sonda’s logging chore: including UTC time in Sonda logs\n[nwaku] Analysed that messages_lookup is a good approach chore: improve postgres query performance\n\n\nnext:\n\n[nwaku] Implement messages_lookup to enhance hashes-only queries chore: improve postgres query performance\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nReview connection management strategy and back-off and fix long disconnection issues\n\nachieved:\n\n[chat] Rate limit message publishing\n[chat] Disconnect all peers if ping to randomly choosen peers fails twice, chore: disconnect on subsequent ping failures\n[chat] improve lightclient connectivity by publishing their shard info in metadata fix: lightclient enr shards and fix: check for lightclient only if req doesn’t contain shards\n[chat] record connection failures for req/resp protocols\n\n\n\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[chat] Lightpush and Filter bandwidth metrics, feat: store filter and lightpush stats\n[nwaku] Little enhancement for network connectivity, use bootstrap enr’s to connect to any kind of network and detect shardings\n[nwaku] Auto-select service peers and use them randomly for testing on both sides.\n[nwaku] Run lite-protocol-tester on shards.staging\n\n\n\n\n\nTelemetry: direct message reliability\n\nachieved:\n\n[chat] Fix concurrent RW on map in telemetry server: fix: concurrent rw on map\n[chat] Improve storednode message counter dashboard: storenode-message-counter\n\n\n\n\n\nReliability Protocol for Relay\n\nnext:\n\n[nwaku] ongoing implementation in nwaku: feat: Enhance lightpush protocol error handling\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[chat] lightclient error handling\n[js-waku] health state of nodes feat: node and protocols health\n[js-waku] improve continuous peer discovery feat(peer-exchange): support continuous peer information updates\n\n\nnext:\n\n[js-waku] complete review for health state of node and continuous peer discovery\n\n\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\n\n[js-waku] dogfooding app is up and running https://lab.waku.org/dogfooding/\n\n\nnext:\n\n[js-waku] need to fix HTTP headers on the serving site, build basic dashboard\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] added comprehensive tests for the e2e reliability POC\n\n\nnext:\n\n[research] fixes arising from tests, some cleanup and prepare for dogfooding\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[research] adding metrics, manual testing\n[nwaku] Creating versions for DST team to test discv5 and message reliability\n[nwaku] improved nim-libp2p PR with custom logging observer chore: creating branch to test Waku’s received messages\n[nwaku] Opened issue and investigated the phenomenon of some nodes getting stuck and missing messages in DST simulations bug: node getting stuck and missing messages\n\n\nnext:\n\n[nwaku] Continue with the implementation of the bootstrap nodes connection limiting\n[nwaku] Refactor code now that named shading is removed, and deprecate pubsub-topic configuration\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] Revised nwaku nodes’ logging and moved added PRs in nwaku and nim-libp2p to downgrade particularly spammy logs chore: reduce loglevel to some too frequent or unnecessary logs\n[nwaku] Added a CI job verifying that new code is properly linted chore: adding lint job to the CI\n[nwaku] Started going over failed interop tests bug: nwaku <> js-waku interop tests failing\n[nwaku] Release candidate v0.31.0 looks nice from Status-QA PoV Prepare release 0.31.0\n[nwaku] Have the interop tests fixed and a working CI\n[nwaku] Little enhancement on tooling, now single file build/test-run available right from make\n[js-waku] better linting for classes chore: enforce access modifiers\n[js-waku] fix peer exchange tests chore(peer-exchange): use an event listener to gauge if the service is mounted\n[js-waku] remove a bit of tech debt chore: remove content_topic specific API\n\n\nnext:\n\n[nwaku] Perform release v0.31.0\n[js-waku] Release\n\n\n\nBugs §\n\nachieved:\n\n[nwaku] bug: RLN_RELAY_MSG_LIMIT handling\n[nwaku] feature: support Windows 11 made little progress on this it’s ongoing.\n[nwaku] bug: peer exchange returns nodes that no longer exist\n\n\nnext:\n\n[nwaku] bug: failed to retrieve peer info via peer exchange protocol\n[nwaku] building test-peer exchange app on top of the network to analyze peer-exchange behaviour again cache refresh rate.\n\n\n"},"waku/updates/2024-08-05":{"title":"2024-08-05 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[research] implemented basic testing tools for storev3 benchmarking\n\n\nnext:\n\n[research] run some tests against status.prod to get an idea of query times and bottlenecks, expand testing from there\n\n\n\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[research] store resume PR updates\n\n\nnext:\n\n[research] merge store resume PR\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] Simplification of store legacy code to prevent wrong partition creation - chore: Simplification of store legacy code\n[nwaku] Validate the need for bigger database servers because they were swapping too much\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nTelemetry: direct message reliability\n\nachieved:\n\n[chat] report peer id and number of connection failures to telemetry feat(telemetry)_: send connection failure metric, feat: handle metric for peer connection failure\n\n\nnext:\n\n[chat] update dial function in go-waku to propagate dial failures to status-go\n\n\nblockers:\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] Simplify implementation and start using callbacks for API clients feat: enhance reliability thanks to StoreV3\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[js-waku] validating filter messages, and performing renewals feat: validate messages for individual filter nodes & perform renewals\n[js-waku] health metric for node and protocols: feat: node and protocols health\n\n\nnext:\n\n[nwaku] ongoing implementation feat: Enhance lightpush protocol error handling\n[js-waku] message send retries for lightpush: feat(lightpush): add retries to failing peers\n\n\nblockers:\n\n[js-waku] store v3 blocked by nwaku 0.32 release: feat!: store v3\n\n\n\n\n\nUser apps for large scale dogfooding\n\nachieved:\n\n[js-waku] add light push error metric and generic metric to dogfooding app feat: add light push error and generic waku metric, feat: record light push errors in dogfooding\n\n\nnext:\n\n[js-waku] remove metric from queue on duplicate key error dogfooding: remove metric from queue on duplicate key error\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] bump mvds for clearing old states chore_: bump mvds\n\n\nnext:\n\n[chat] move message hash query for outgoing messages to go-waku\n[chat] continue the request to join community test\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] Investigated bug: node getting stuck and missing messages. Created images for DST team to run and analyzed the resulting logs\n[research] added new metric and grafana dashboard focused on discovery, PR adding cluster filtering to Waku peer exchange\n\n\nnext:\n\n[nwaku] Continue investigating the issue, now trying to understand how async futures are handled by the dispatcher\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\nProvision RLN for light push clients PoC\n\nnext:\n\n[research] Investigate how to use Paymasters aka gasless transactions for users, paid by a smart contract. Goal, PoC with go-waku-light\n\n\n\n\n\nMilestone - Scale up number of Communities §\n\nUsage of Rendezvous\n\nnext:\n\n[research] rendez-vous discovery\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] Fixed failing js-waku interop tests and got CI to work again chore: changing default pubsub topic to its static sharding version\n[nwaku] Improving docs chore: updating doc reference to https rpc, switching RPC provider instructions from websocket to https, updating readme\n[nwaku] Bumped dependency for gcc 14 support chore: bumping nim-bearssl\n[nwaku] Deploy v0.31.0 in waku.prod and status.prod\n[chat] refactor: move rate limiter and priority queue from status-go to API package\n[chat] refactor: move missing messages logic from status-go to go-waku, \n[chat] remove unused code from wakuv2 refactor: extract missing messages logic to go-waku\n\n\nnext:\n\n[js-waku] peers used by different protocols to be different from one-another to increase footprint: feat: peer selection for protocols\n[js-waku] filter API to be simple (reliability user story): feat: use decoder as a seed for subscription\n\n\n\nBugs §\n\nachieved:\n\n[nwaku] building testing tools to analyze peer-exchange protocol and its behavior test: peer exchange testing tool\n[js-waku] continuous discovery updates for node information chore(peer-exchange): support updates of previously discovered peer’s addresses\n[chat] fix: missing wakuv2 fields in createAccountRequest toJson func fix: missing wakuv2 fields in createAccountRequest toJson func\n[chat] fix: storenode multiaddresses\n[chat] fix: handle scenario where the node’s ENR has no shard (due to shard update)\n\n\nnext:\n\n[nwaku] bug: failed to retrieve peer info via peer exchange protocol\n[chat] verify missing messages to determine if storenode sync was executed\n\n\n"},"waku/updates/2024-08-12":{"title":"2024-08-12 Waku Weekly","links":[],"tags":["waku-updates"],"content":"Milestone - Store Service Upgrade §\n\n\nStore v3-beta - Message Hashes\n\nachieved:\n\n[js-waku] feat!: store v3\n\n\n\n\n\nPostgreSQL Maintenance\n\nachieved:\n\n[nwaku] PR almost merged with optimizations in messageHash queries through lookup table chore: Optimize hash queries with lookup table\n[nwaku] submitted PR in infra-status to fine-tune the Postgres settings after having increased the hw specs store-db add more appropriate db settings for current db hw\n\n\n\n\n\nStore v3 - store synchronisation\n\nachieved:\n\n[nwaku] PR review WIP to add Waku Sync feat: Nwaku Sync\n\n\n\n\n\nMilestone - Direct Message Reliability §\n\n\nTooling: filter and light push protocols\n\nachieved:\n\n[nwaku] Started using liteprotocoltester tool to send lightpush msgs from a node located in Frankfurt and receiving through waku-filter in a node located in Sydney. Both are connected to one node in status.prod fleet.\n[nwaku] liteprotocoltester tool helped to discover duplicated messages problem\n\n\nnext:\n\n[nwaku] carry on with duplicated messages issue\n\n\n\n\n\nTelemetry: direct message reliability\n\nachieved:\n\n[chat] report peer id and number of connection failures to telemetry feat(telemetry)_: send connection failure metric, feat: handle metric for peer connection failure\n\n\n\n\n\nReliability Protocol for Relay\n\nachieved:\n\n[nwaku] Development of subscription awareness for delivery_monitor module feat: enhance reliability thanks to StoreV3\n\n\n\n\n\nReliability Protocol for Resource-Restricted Clients\n\nachieved:\n\n[nwaku] ongoing implementation in nwaku feat: Enhance lightpush protocol error handling\n[js-waku] filter API refactor for ease and DX: feat(filter)!: new simpler filter API\n\n\n\n\n\nReview MVDS usage and fail path\n\nachieved:\n\n[chat] bump mvds for clearing old states chore_: bump mvds\n\n\n\n\n\nMilestone - End-to-end reliability protocol §\n\nEnd-to-end reliability protocol - PoC\n\nachieved:\n\n[research] peer retrieval of missing messages, reconnect capability for tests, conflict resolution; and raised a final PR for POC\n\n\nnext:\n\n[research] address review comments, dogfooding\n\n\n\n\n\nMilestone - Static Sharding - dedicated shards §\n\nSharding peer management and discovery hardening\n\nachieved:\n\n[nwaku] Continued investigating bug: node getting stuck and missing messages\n[nwaku] Found “Futures” leak in yamux and confirmed that it doesn’t happen on mplex. Opened an issue in nim-libp2p bug: yamux Futures leak and a PR in nwaku switching back to mplex chore: using mplex instead of yamux\n[nwaku] Got feedback from Nimbus and new potential ways to debug bug: node getting stuck and missing messages\n[nwaku] Completed bug: Node accepts connections when configured for just discovery, optimizing the connection management of discv5-only nodes\n[research] libp2p rendezvous wrapper impl. at the waku layer\n\n\nnext:\n\n[nwaku] Try the recommended debugging techniques\n[research] namespace definition, discovery strategy\n\n\n\n\n\nMilestone - Scale 1:1 chat messages PoC §\n\n\nMaturing RLN variables/parameters revision\n\nachieved:\n\n[research] raw spec PR for RLN contract mainnet deployment: Add WAKU2-RLN-CONTRACT spec for mainnet deployment\n\n\nnext:\n\n[research] continue the discussion around the PR, finalize the initial version of the spec\n\n\n\n\n\nPay for RLN provision first PoC\n\nachieved:\n\n[research] PoC with a paymaster in zksync, written in golang\n\n\nnext:\n\n[research] continue work with paymaster to sponsor tx fees in zksync\n\n\nblockers:\n\n[research] lots of issues deploying rln to zksync\n\n\n\n\n\nOther Work §\nEnhancements §\n\nachieved:\n\n[nwaku] upgraded the peer exchange mounting procedure - chore: upgrade peer exchange mounting](https://github.com/waku-org/nwaku/pull/2953)\n[nwaku] Successfully reproduced the PR exchange issue - bug: failed to retrieve peer info via peer exchange protocol\n[nwaku] Made progress on testing tools - test: peer exchange testing tool\n[chat] refactor: move rate limiter and priority queue from status-go to API package refactor: move rate limiter and priority queue from status-go to api package\n[chat] refactor: move missing messages logic from status-go to go-waku, refactor: extract missing messages logic to go-waku\n[chat] refactor: remove unused code from wakuv2\n\n\nnext:\n\n[nwaku] Resolve the PR exchange issue bug: failed to retrieve peer info via peer exchange protocol\n[nwaku] Complete peer exchange testing tools test: peer exchange testing tool\n\n\n\nBugs §\n\nachieved:\n\n[nwaku] fix: missing wakuv2 fields in createAccountRequest toJson func\n[chat] fix: storenode multiaddresses\n[chat] fix: handle scenario where the node’s ENR has no shard (due to shard update)\n\n\n"},"what-is-a-milestone":{"title":"What's in a Milestone","links":[],"tags":[],"content":"Rationale and Reasoning §\nA project’s goals and priorities are described at its top level by a list of Milestones. The list of these milestones should serve as a guidepost to anyone who is interested in what the project is working on, what the deliverables are of that work, and how that work is going.\n\n\n \n If you don't like "Milestone", call it whatever you want as long as it's in line with this description. \n \n \n\nThis document is an outline of how you should think about creating milestones for your project, and what information should be included in them such that the IFT Grant Process can be completed and everyone stays on the same page.\nProjects work to produce things for people, and a milestone describes, plans, and tracks those things. To that end, the deliverables are the key components to reason around what a milestone is for your project. Who are you building for, what are you building for them, and why do they care? A small group of deliverables and the justified impact they have towards their targeted audience should be enough to help someone understand what a project is doing.\nIn effect, a given milestone is a declaration of:\n\nHere’s what we want to happen\nThis is why this needs to happen\nHere’s how we’re going to make that happen\nThis is what we need to do it\nHere’s how you can watch\nThis is how confident we are that we can get it done (in time)\n\nThe scope of a given milestone is such that the total amount of work you plan for the year equates to ~4-5 individual milestones. For a small project, that’s focused and tight. For a large project, that’s cross-functional and broad. It is expected that larger projects have the appropriate project management resources to sub-divide their milestones in to sub-milestones, epics, and issues as appropriate.\nWe ask that the structure of the milestone is somewhat standardized across the IFT, as we have a lot of derivative and automation tasks to perform.\nHere’s a list of the sections that need to be included in each milestone:\n\nMilestone Title §\nA short name of the milestone that succinctly describes its aim and scope.\nEstimated Delivery Date §\nA timeline in which the work is expected to be delivered\nDescription §\nMore detail as to what you’re aiming to accomplish with this milestone and the justification for its inclusion to the project. This is the human readable encapsulation of the milestone. Someone reading it should be able to understand the general scope of the entire thing, with all other sections adding context and detail.\nResources Required §\n\nroles and % application to it\nexternal services consumed (Vac/IFT)\ninfrastructure\n\nThis information here, in combination with the IFT Finance team, should be enough to yield the required budget for the milestone. This allows for private financial information to stay appropriately separated while still allowing us to publish and broadcast the roadmaps (and their progress) to the broader communities.\nDeliverables §\nWhat are the tangible items that are the result of this milestone’s work, and who is the targeted audience for those items?\nIt is important to note that we’ve included the intended audience here. Is this a research PoC to be delivered to the Engineering team? Is this a mainnet launch that we need wide community broadcasting on? Is this an SDK being delivered to another IFT project? The appropriate communication of the deliverable should be considered here.\nTracking Metrics §\nHow we track progress on a given milestone is dependent upon what the goal of the milestone is and deliverables it aims to accomplish. As per Jarrad’s Strategy Document and mantra from previous talks, metrics around User Acquisition and Revenue Generation should be included wherever possibly appropriate. If it isn’t directly aimed at these two, its impact on how it facilitates it should be understood.\nNOTE: The IFT Insights team will closely monitor all of these and provide dashboards to relevant stakeholders such that progress and status can be monitored and acted upon.\nWork Breakdown §\nSince this is the highest level of “work package” that is considered throughout the org, a description of the way this is going to be broken up and managed should be itemized here. This section is a process of showing “this is explicitly how we plan to deliver this milestone.”\nNOTE: It is recommended that the broken down work is structured similarly so it can be understood and tracked, e.g. Milestone -> Epics -> Issues by the IFT Insights team, with each layer more narrowed in scope and explicit in detail. Each project has a significant level of autonomy on how they deliver on the agreed upon milestones and the associated project management and organization that entails it.\nPerceived Risks §\nEach milestone should include a section of what dependencies/assumptions/potential market changes there are that add risk to its completion. What factors come into play that can potentially affect the project delivery date, and how do each of them affect its delivery?"}} \ No newline at end of file diff --git a/tags/index.html b/tags/index.html index a5c39d466..784f425c4 100644 --- a/tags/index.html +++ b/tags/index.html @@ -1,5 +1,5 @@ -Tag: #index

Logos Collective Project Roadmaps

Search

SearchSearch

Tag: #index

Found 30 total tags.

#team-updates

1 item with this tag.

#zkvm

1 item with this tag.

#nim

1 item with this tag.

#p2p

2 items with this tag.

#rfc

1 item with this tag.

#sc

1 item with this tag.

#head

1 item with this tag.

#wakureporting

1 item with this tag.

Logos Collective Project Roadmaps

Search

SearchSearch

Tag: #index

Found 30 total tags.

#team-updates

1 item with this tag.

#zkvm

1 item with this tag.

#nim

1 item with this tag.

#p2p

2 items with this tag.

#rfc

1 item with this tag.

#sc

1 item with this tag.

#head

1 item with this tag.

#wakureporting

1 item with this tag.

Logos Collective Project Roadmaps

Search

SearchSearch

Tag: #waku-updates

38 items with this tag.

Logos Collective Project Roadmaps

Search

SearchSearch

Tag: #waku-updates

38 items with this tag.

Logos Collective Project Roadmaps

Search

SearchSearch

2024-08-12 Waku Weekly

Aug 13, 2024, 4 min read

Milestone - Store Service Upgrade

+2024-08-12 Waku Weekly

Logos Collective Project Roadmaps

Search

SearchSearch

2024-08-12 Waku Weekly

Aug 16, 2024, 4 min read

Milestone - Store Service Upgrade

Milestone - Direct Message Reliability