diff --git a/index.xml b/index.xml index de2111ddd..2b984d36b 100644 --- a/index.xml +++ b/index.xml @@ -258,12 +258,6 @@ https://roadmap.logos.co/roadmap/vac/tke/overview vac:tke:: § status:SNT-litepaper § due: 2023/07/31 status: 70% - delayed: other milestones taking precedence more details status:SNT-governance-proposal § due: TBD status: NA - taking precedence over SNT-litepaper CC: Matty status:SNT-staking § due: 2023/08/30 status: 82% more details codex:economic-analysis § due: 2023/08/30 status: 50% more details nomox:economic-analysis § due: 2023/10/31 status: 30% CC: Frederico . Fri, 25 Aug 2023 00:00:00 GMT - - Zero-knowledge Virtual Machine Incubation Project - https://roadmap.logos.co/roadmap/vac/zkvm/overview - https://roadmap.logos.co/roadmap/vac/zkvm/overview - vac:zkvm §. - Fri, 25 Aug 2023 00:00:00 GMT 2023-07-10 Vac Weekly https://roadmap.logos.co/roadmap/vac/updates/2023-07-10 @@ -316,8 +310,14 @@ 2023-09-04 Vac weekly https://roadmap.logos.co/roadmap/vac/updates/2023-09-04 https://roadmap.logos.co/roadmap/vac/updates/2023-09-04 - Vac 2023/09/04 § Vac Milestones [Vac Github Repos] (Vac-Repositories-75f7feb3861048f897f0fe95ead08b06) vsu::P2P § vac:p2p:nim-libp2p:vac:maintenance Becaming a Validator in the Nimbus Consensus client (95%) IWANT replies can be bigger than the pubsub message limit (100%, on review) 887 Improve gossipsub DDoS resistance (98%) 920 vsu::Tokenomics § vac:tke::codex:economic-analysis Presenting Filecoin findings to Codex team Litepaper: assumptions on collateral vac:tke::status:SNT-staking Highlighted multiple design requirements not met by SC implementation for SC team notion doc Open questions w/ John, epoch duration Staking governance proposal for when John returns Sep 12 vac:tke::nomos:economic-analysis Delegated staking specifications w/Marcin, update for privacy constraints Bribery attacks analysis, Moh asked to followup early/mid Sep vac:tke::waku:economic-analysis Formalized RLN thoughts shared w/ Aaryamann, will push for additional feedback once Martin returns vsu::Distributed Systems Testing (DST) § vac:dst:analysis:nomos:nomos-simulation-analysis Took over data generation on Tuesday Found a bug in simulations, working around it The comparison runs are now fully automated got the first full set of comparison plots: everything appears to be explainable for a fixed probability Tree runs now scale to 15k nodes vac:dst:wakurtosis:vac:retrospective-rlog Gather info and wrote summary of why we decided to stop using Kurtosis. + Vac 2023/09/04 § Vac Milestones Vac Github Repos vsu::P2P § vac:p2p:nim-libp2p:vac:maintenance Becaming a Validator in the Nimbus Consensus client (95%) IWANT replies can be bigger than the pubsub message limit (100%, on review) 887 Improve gossipsub DDoS resistance (98%) 920 vsu::Tokenomics § vac:tke::codex:economic-analysis Presenting Filecoin findings to Codex team Litepaper: assumptions on collateral vac:tke::status:SNT-staking Highlighted multiple design requirements not met by SC implementation for SC team notion doc Open questions w/ John, epoch duration Staking governance proposal for when John returns Sep 12 vac:tke::nomos:economic-analysis Delegated staking specifications w/Marcin, update for privacy constraints Bribery attacks analysis, Moh asked to followup early/mid Sep vac:tke::waku:economic-analysis Formalized RLN thoughts shared w/ Aaryamann, will push for additional feedback once Martin returns vsu::Distributed Systems Testing (DST) § vac:dst:analysis:nomos:nomos-simulation-analysis Took over data generation on Tuesday Found a bug in simulations, working around it The comparison runs are now fully automated got the first full set of comparison plots: everything appears to be explainable for a fixed probability Tree runs now scale to 15k nodes vac:dst:wakurtosis:vac:retrospective-rlog Gather info and wrote summary of why we decided to stop using Kurtosis. Mon, 04 Sep 2023 00:00:00 GMT + + Zero-knowledge Virtual Machine Incubation Project + https://roadmap.logos.co/roadmap/vac/zkvm/overview + https://roadmap.logos.co/roadmap/vac/zkvm/overview + vac:zkvm §. + Fri, 25 Aug 2023 00:00:00 GMT 2023-07-24 Waku weekly https://roadmap.logos.co/roadmap/waku/updates/2023-07-24 diff --git a/roadmap/vac/updates/2023-09-04.html b/roadmap/vac/updates/2023-09-04.html index d7bc928c3..ce55c6cb1 100644 --- a/roadmap/vac/updates/2023-09-04.html +++ b/roadmap/vac/updates/2023-09-04.html @@ -1,8 +1,8 @@ -2023-09-04 Vac weekly

Logos Collective Project Roadmaps

Search

SearchSearch

2023-09-04 Vac weekly

Sep 04, 2023, 4 min read

Vac 2023/09/04

+2023-09-04 Vac weekly

Logos Collective Project Roadmaps

Search

SearchSearch

2023-09-04 Vac weekly

Sep 04, 2023, 4 min read

Vac 2023/09/04

vsu::P2P

    diff --git a/sitemap.xml b/sitemap.xml index 873ddf43d..dd6f90cb4 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -124,9 +124,6 @@ https://roadmap.logos.co/roadmap/vac/tke/overview 2023-08-25T00:00:00.000Z - - https://roadmap.logos.co/roadmap/vac/zkvm/overview - 2023-08-25T00:00:00.000Z https://roadmap.logos.co/roadmap/vac/updates/2023-07-10 2023-07-16T00:00:00.000Z @@ -154,6 +151,9 @@ https://roadmap.logos.co/roadmap/vac/updates/2023-09-04 2023-09-04T00:00:00.000Z + + https://roadmap.logos.co/roadmap/vac/zkvm/overview + 2023-08-25T00:00:00.000Z https://roadmap.logos.co/roadmap/waku/updates/2023-07-24 2023-08-04T00:00:00.000Z diff --git a/static/contentIndex.json b/static/contentIndex.json index 29d3ecaa5..971208638 100644 --- a/static/contentIndex.json +++ b/static/contentIndex.json @@ -1 +1 @@ -{"configuration":{"title":"Configuration","links":["layout","RSS-Feed","SPA-Routing","popover-previews","hosting","private-pages","graph-view","syntax-highlighting","making-plugins","Latex"],"tags":[],"content":"Quartz is meant to be extremely configurable, even if you don’t know any coding. Most of the configuration you should need can be done by just editing quartz.config.ts or changing the layout in quartz.layout.ts.\n\n\n \n Tip \n \n \nIf you edit Quartz configuration using a text-editor that has TypeScript language support like VSCode, it will warn you when you you’ve made an error in your configuration, helping you avoid configuration mistakes!\n\nThe configuration of Quartz can be broken down into two main parts:\nquartz.config.tsconst config: QuartzConfig = {\n configuration: { ... },\n plugins: { ... },\n}\nGeneral Configuration §\nThis part of the configuration concerns anything that can affect the whole site. The following is a list breaking down all the things you can configure:\n\npageTitle: title of the site. This is also used when generating the RSS Feed for your site.\nenableSPA: whether to enable SPA Routing on your site.\nenablePopovers: whether to enable popover previews on your site.\nanalytics: what to use for analytics on your site. Values can be\n\nnull: don’t use analytics;\n{ provider: 'plausible' }: use Plausible, a privacy-friendly alternative to Google Analytics; or\n{ provider: 'google', tagId: <your-google-tag> }: use Google Analytics\n\n\nbaseUrl: this is used for sitemaps and RSS feeds that require an absolute URL to know where the canonical ‘home’ of your site lives. This is normally the deployed URL of your site (e.g. quartz.jzhao.xyz for this site). Do not include the protocol (i.e. https://) or any leading or trailing slashes.\n\nThis should also include the subpath if you are hosting on GitHub pages without a custom domain. For example, if my repository is jackyzha0/quartz, GitHub pages would deploy to https://jackyzha0.github.io/quartz and the baseUrl would be jackyzha0.github.io/quartz\nNote that Quartz 4 will avoid using this as much as possible and use relative URLs whenever it can to make sure your site works no matter where you end up actually deploying it.\n\n\nignorePatterns: a list of glob patterns that Quartz should ignore and not search through when looking for files inside the content folder. See private pages for more details.\ntheme: configure how the site looks.\n\ntypography: what fonts to use. Any font available on Google Fonts works here.\n\nheader: Font to use for headers\ncode: Font for inline and block quotes.\nbody: Font for everything\n\n\ncolors: controls the theming of the site.\n\nlight: page background\nlightgray: borders\ngray: graph links, heavier borders\ndarkgray: body text\ndark: header text and icons\nsecondary: link colour, current graph node\ntertiary: hover states and visited graph nodes\nhighlight: internal link background, highlighted text, highlighted lines of code\n\n\n\n\n\nPlugins §\nYou can think of Quartz plugins as a series of transformations over content.\n\nplugins: {\n transformers: [...],\n filters: [...],\n emitters: [...],\n}\n\nTransformers map over content (e.g. parsing frontmatter, generating a description)\nFilters filter content (e.g. filtering out drafts)\nEmitters reduce over content (e.g. creating an RSS feed or pages that list all files with a specific tag)\n\nBy adding, removing, and reordering plugins from the tranformers, filters, and emitters fields, you can customize the behaviour of Quartz.\n\n\n \n Note \n \n \nEach node is modified by every transformer in order. Some transformers are position-sensitive so you may need to take special note of whether it needs come before or after any other particular plugins.\n\nAdditionally, plugins may also have their own configuration settings that you can pass in. For example, the Latex plugin allows you to pass in a field specifying the renderEngine to choose between Katex and MathJax.\ntransformers: [\n Plugin.FrontMatter(), // uses default options\n Plugin.Latex({ renderEngine: "katex" }), // specify some options\n]\nIf you’d like to make your own plugins, read the guide on making plugins for more information."},"hosting":{"title":"Hosting","links":["RSS-Feed","configuration"],"tags":[],"content":"Quartz effectively turns your Markdown files and other resources into a bundle of HTML, JS, and CSS files (a website!).\nHowever, if you’d like to publish your site to the world, you need a way to host it online. This guide will detail how to deploy with either GitHub Pages or Cloudflare pages but any service that allows you to deploy static HTML should work as well (e.g. Netlify, Replit, etc.)\n\n\n \n Tip \n \n \nSome Quartz features (like RSS Feed and sitemap generation) require baseUrl to be configured properly in your configuration to work properly. Make sure you set this before deploying!\n\nCloudflare Pages §\n\nLog in to the Cloudflare dashboard and select your account.\nIn Account Home, select Workers & Pages > Create application > Pages > Connect to Git.\nSelect the new GitHub repository that you created and, in the Set up builds and deployments section, provide the following information:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nConfiguration optionValueProduction branchv4Framework presetNoneBuild commandnpx quartz buildBuild output directorypublic\nPress “Save and deploy” and Cloudflare should have a deployed version of your site in about a minute. Then, every time you sync your Quartz changes to GitHub, your site should be updated.\nTo add a custom domain, check out Cloudflare’s documentation.\nGitHub Pages §\nLike Quartz 3, you can deploy the site generated by Quartz 4 via GitHub Pages.\nIn your local Quartz, create a new file quartz/.github/workflows/deploy.yml.\nquartz/.github/workflows/deploy.ymlname: Deploy Quartz site to GitHub Pages\n \non:\n push:\n branches:\n - v4\n \npermissions:\n contents: read\n pages: write\n id-token: write\n \nconcurrency:\n group: "pages"\n cancel-in-progress: false\n \njobs:\n build:\n runs-on: ubuntu-22.04\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0 # Fetch all history for git info\n - uses: actions/setup-node@v3\n with:\n node-version: 18.14\n - name: Install Dependencies\n run: npm ci\n - name: Build Quartz\n run: npx quartz build\n - name: Upload artifact\n uses: actions/upload-pages-artifact@v2\n with:\n path: public\n \n deploy:\n needs: build\n environment:\n name: github-pages\n url: ${{ steps.deployment.outputs.page_url }}\n runs-on: ubuntu-latest\n steps:\n - name: Deploy to GitHub Pages\n id: deployment\n uses: actions/deploy-pages@v2\nThen:\n\nHead to “Settings” tab of your forked repository and in the sidebar, click “Pages”. Under “Source”, select “GitHub Actions”.\nCommit these changes by doing npx quartz sync. This should deploy your site to <github-username>.github.io/<repository-name>.\n\n\n\n \n Tip \n \n \nIf you get an error about not being allowed to deploy to github-pages due to environment protection rules, make sure you remove any existing GitHub pages environments.\nYou can do this by going to your Settings page on your GitHub fork and going to the Environments tab and pressing the trash icon. The GitHub action will recreate the environment for you correctly the next time you sync your Quartz.\n\nCustom Domain §\nHere’s how to add a custom domain to your GitHub pages deployment.\n\nHead to the “Settings” tab of your forked repository.\nIn the “Code and automation” section of the sidebar, click “Pages”.\nUnder “Custom Domain”, type your custom domain and click “Save”.\nThis next step depends on whether you are using an apex domain (example.com) or a subdomain (subdomain.example.com).\n\nIf you are using an apex domain, navigate to your DNS provider and create an A record that points your apex domain to GitHub’s name servers which have the following IP addresses:\n\n185.199.108.153\n185.199.109.153\n185.199.110.153\n185.199.111.153\n\n\nIf you are using a subdomain, navigate to your DNS provider and create a CNAME record that points your subdomain to the default domain for your site. For example, if you want to use the subdomain quartz.example.com for your user site, create a CNAME record that points quartz.example.com to <github-username>.github.io.\n\n\n\nThe above shows a screenshot of Google Domains configured for both jzhao.xyz (an apex domain) and quartz.jzhao.xyz (a subdomain).\nSee the GitHub documentation for more detail about how to setup your own custom domain with GitHub Pages.\n\n\n \n Why aren't my changes showing up? \n \n \nThere could be many different reasons why your changes aren’t showing up but the most likely reason is that you forgot to push your changes to GitHub.\nMake sure you save your changes to Git and sync it to GitHub by doing npx quartz sync. This will also make sure to pull any updates you may have made from other devices so you have them locally.\n"},"index":{"title":"","links":["roadmap/waku/overview","roadmap/codex/overview","roadmap/nomos/overview","roadmap/vac/overview","roadmap/innovation_lab/overview","roadmap/acid/overview"],"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.\n\n\n \n Note \n \n \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.\nIt is our aim to continuously get closer to that target, but we will continuously fail at that. If you know something is out of date or incorrect, raise an issue or make a PR.\n\nNavigation §\n\nWaku\nCodex\nNomos\nVac\nInnovation Lab\nComms (Acid Info)\n"},"index_default":{"title":"Welcome to Quartz 4","links":["showcase","authoring-content","configuration","layout","build","hosting","migrating-from-Quartz-3","Obsidian-compatibility","full-text-search","graph-view","wikilinks","backlinks","Latex","syntax-highlighting","popover-previews","features","creating-components","SPA-Routing","making-plugins","philosophy","architecture","upgrading"],"tags":[],"content":"Quartz is a fast, batteries-included static-site generator that transforms Markdown content into fully functional websites. Thousands of students, developers, and teachers are already using Quartz to publish personal notes, wikis, and digital gardens to the web.\n🪴 Get Started §\nQuartz requires at least Node v18.14 to function correctly. Ensure you have this installed on your machine before continuing.\nThen, in your terminal of choice, enter the following commands line by line:\ngit clone https://github.com/jackyzha0/quartz.git\ncd quartz\nnpm i\nnpx quartz create\nThis will guide you through initializing your Quartz with content. Once you’ve done so, see how to:\n\nAuthor content in Quartz\nConfigure Quartz’s behaviour\nChange Quartz’s layout\nBuild and preview Quartz\nHost Quartz online\n\n\n\n \n Info \n \n \nComing from Quartz 3? See the migration guide for the differences between Quartz 3 and Quartz 4 and how to migrate.\n\n🔧 Features §\n\nObsidian compatibility, full-text search, graph view, wikilinks, backlinks, Latex, syntax highlighting, popover previews, and many more right out of the box\nHot-reload for both configuration and content\nSimple JSX layouts and page components\nRidiculously fast page loads and tiny bundle sizes\nFully-customizable parsing, filtering, and page generation through plugins\n\nFor a comprehensive list of features, visit the features page. You can read more about the why behind these features on the philosophy page and a technical overview on the architecture page.\n🚧 Troubleshooting + Updating §\nHaving trouble with Quartz? Try searching for your issue using the search feature. If you haven’t already, upgrade to the newest version of Quartz to see if this fixes your issue.\nIf you’re still having trouble, feel free to submit an issue if you feel you found a bug or ask for help in our Discord Community."},"layout":{"title":"Layout","links":["tags/component","creating-components","configuration"],"tags":[],"content":"Certain emitters may also output HTML files. To enable easy customization, these emitters allow you to fully rearrange the layout of the page. The default page layouts can be found in quartz.layout.ts.\nEach page is composed of multiple different sections which contain QuartzComponents. The following code snippet lists all of the valid sections that you can add components to:\nquartz/cfg.tsexport interface FullPageLayout {\n head: QuartzComponent // single component\n header: QuartzComponent[] // laid out horizontally\n beforeBody: QuartzComponent[] // laid out vertically\n pageBody: QuartzComponent // single component\n left: QuartzComponent[] // vertical on desktop, horizontal on mobile\n right: QuartzComponent[] // vertical on desktop, horizontal on mobile\n footer: QuartzComponent // single component\n}\nThese correspond to following parts of the page:\n\n\n\n \n Note \n \n \nThere are two additional layout fields that are not shown in the above diagram.\n\nhead is a single component that renders the <head> tag in the HTML. This doesn’t appear visually on the page and is only is responsible for metadata about the document like the tab title, scripts, and styles.\nheader is a set of components that are laid out horizontally and appears before the beforeBody section. This enables you to replicate the old Quartz 3 header bar where the title, search bar, and dark mode toggle. By default, Quartz 4 doesn’t place any components in the header.\n\n\nQuartz components, like plugins, can take in additional properties as configuration options. If you’re familiar with React terminology, you can think of them as Higher-order Components.\nSee a list of all the components for all available components along with their configuration options. You can also checkout the guide on creating components if you’re interested in further customizing the behaviour of Quartz.\nStyle §\nMost meaningful style changes like colour scheme and font can be done simply through the general configuration options. However, if you’d like to make more involved style changes, you can do this by writing your own styles. Quartz 4, like Quartz 3, uses Sass for styling.\nYou can see the base style sheet in quartz/styles/base.scss and write your own in quartz/styles/custom.scss.\n\n\n \n Note \n \n \nSome components may provide their own styling as well! For example, quartz/components/Darkmode.tsx imports styles from quartz/components/styles/darkmode.scss. If you’d like to customize styling for a specific component, double check the component definition to see how its styles are defined.\n"},"migrating-from-Quartz-3":{"title":"Migrating from Quartz 3","links":["configuration","hosting","folder-and-tag-listings","creating-components"],"tags":[],"content":"As you already have Quartz locally, you don’t need to fork or clone it again. Simply just checkout the alpha branch, install the dependencies, and import your old vault.\ngit fetch\ngit checkout v4\ngit pull upstream v4\nnpm i\nnpx quartz create\nIf you get an error like fatal: 'upstream' does not appear to be a git repository, make sure you add upstream as a remote origin:\ngit remote add upstream https://github.com/jackyzha0/quartz.git\nWhen running npx quartz create, you will be prompted as to how to initialize your content folder. Here, you can choose to import or link your previous content folder and Quartz should work just as you expect it to.\n\n\n \n Note \n \n \nIf the existing content folder you’d like to use is at the same path on a different branch, clone the repo again somewhere at a different path in order to use it.\n\nKey changes §\n\nRemoving Hugo and hugo-obsidian: Hugo worked well for earlier versions of Quartz but it also made it hard for people outside of the Golang and Hugo communities to fully understand what Quartz was doing under the hood and be able to properly customize it to their needs. Quartz 4 now uses a Node-based static-site generation process which should lead to a much more helpful error messages and an overall smoother user experience.\nFull-hot reload: The many rough edges of how hugo-obsidian integrated with Hugo meant that watch mode didn’t re-trigger hugo-obsidian to update the content index. This lead to a lot of weird cases where the watch mode output wasn’t accurate. Quartz 4 now uses a cohesive parse, filter, and emit pipeline which gets run on every change so hot-reloads are always accurate.\nReplacing Go template syntax with JSX: Quartz 3 used Go templates to create layouts for pages. However, the syntax isn’t great for doing any sort of complex rendering (like text processing) and it got very difficult to make any meaningful layout changes to Quartz 3. Quartz 4 uses an extension of JavaScript syntax called JSX which allows you to write layout code that looks like HTML in JavaScript which is significantly easier to understand and maintain.\nA new extensible configuration and plugin system: Quartz 3 was hard to configure without technical knowledge of how Hugo’s partials worked. Extensions were even hard to make. Quartz 4’s configuration and plugin system is designed to be extended by users while making updating to new versions of Quartz easy.\n\nThings to update §\n\nYou will need to update your deploy scripts. See the hosting guide for more details.\nEnsure that your default branch on GitHub is updated from hugo to v4.\nFolder and tag listings have also changed.\n\nFolder descriptions should go under content/<folder-name>/index.md where <folder-name> is the name of the folder.\nTag descriptions should go under content/tags/<tag-name>.md where <tag-name> is the name of the tag.\n\n\nSome HTML layout may not be the same between Quartz 3 and Quartz 4. If you depended on a particular HTML hierarchy or class names, you may need to update your custom CSS to reflect these changes.\nIf you customized the layout of Quartz 3, you may need to translate these changes from Go templates back to JSX as Quartz 4 no longer uses Hugo. For components, check out the guide on creating components for more details on this.\n"},"philosophy":{"title":"Philosophy of Quartz","links":[],"tags":[],"content":"A garden should be a true hypertext §\n\nThe garden is the web as topology. Every walk through the garden creates new paths, new meanings, and when we add things to the garden we add them in a way that allows many future, unpredicted relationships.\n(The Garden and the Stream)\n\nThe problem with the file cabinet is that it focuses on efficiency of access and interoperability rather than generativity and creativity. Thinking is not linear, nor is it hierarchical. In fact, not many things are linear or hierarchical at all. Then why is it that most tools and thinking strategies assume a nice chronological or hierarchical order for my thought processes? The ideal tool for thought for me would embrace the messiness of my mind, and organically help insights emerge from chaos instead of forcing an artificial order. A rhizomatic, not arboresecent, form of note taking.\nMy goal with a digital garden is not purely as an organizing system and information store (though it works nicely for that). I want my digital garden to be a playground for new ways ideas can connect together. As a result, existing formal organizing systems like Zettelkasten or the hierarchical folder structures of Notion don’t work well for me. There is way too much upfront friction that by the time I’ve thought about how to organize my thought into folders categories, I’ve lost it.\nQuartz embraces the inherent rhizomatic and web-like nature of our thinking and tries to encourage note-taking in a similar form.\n\nA garden should be shared §\nThe goal of digital gardening should be to tap into your network’s collective intelligence to create constructive feedback loops. If done well, I have a shareable representation of my thoughts that I can send out into the world and people can respond. Even for my most half-baked thoughts, this helps me create a feedback cycle to strengthen and fully flesh out that idea.\nQuartz is designed first and foremost as a tool for publishing digital gardens to the web. To me, digital gardening is not just passive knowledge collection. It’s a form of expression and sharing.\n\n“[One] who works with the door open gets all kinds of interruptions, but [they] also occasionally gets clues as to what the world is and what might be important.”\n— Richard Hamming\n\nThe goal of Quartz is to make sharing your digital garden free and simple. At its core, Quartz is designed to be easy to use enough for non-technical people to get going but also powerful enough that senior developers can tweak it to work how they’d like it to work."},"showcase":{"title":"Quartz Showcase","links":[],"tags":[],"content":"Want to see what Quartz can do? Here are some cool community gardens:\n\nQuartz Documentation (this site!)\nJacky Zhao’s Garden\nBrandon Boswell’s Garden\nScaling Synthesis - A hypertext research notebook\nAWAGMI Intern Notes\nCourse notes for Information Technology Advanced Theory\nData Dictionary 🧠\nsspaeti.com’s Second Brain\noldwinterの数字花园\nAbhijeet’s Math Wiki\nMike’s AI Garden 🤖🪴\nMatt Dunn’s Second Brain\n\nIf you want to see your own on here, submit a Pull Request adding yourself to this file!"},"upgrading":{"title":"Upgrading Quartz","links":["migrating-from-Quartz-3"],"tags":[],"content":"\n\n \n Note \n \n \nThis is specifically a guide for upgrading Quartz 4 version to a more recent update. If you are coming from Quartz 3, check out the migration guide for more info.\n\nTo fetch the latest Quartz updates, simply run\nnpx quartz update\nAs Quartz uses git under the hood for versioning, updating effectively ‘pulls’ in the updates from the official Quartz GitHub repository. If you have local changes that might conflict with the updates, you may need to resolve these manually yourself (or, pull manually using git pull origin upstream).\n\n\n \n Tip \n \n \nQuartz will try to cache your content before updating to try and prevent merge conflicts. If you get a conflict mid-merge, you can stop the merge and then run npx quartz restore to restore your content from the cache.\n\nIf you have the GitHub desktop app, this will automatically open to help you resolve the conflicts. Otherwise, you will need to resolve this in a text editor like VSCode. For more help on resolving conflicts manually, check out the GitHub guide on resolving merge conflicts."},"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."},"roadmap/acid/milestones-overview":{"title":"Comms Milestones Overview","links":[],"tags":["milestones"],"content":"\nComms Roadmap\nComms Projects\nComms planner deadlines\n"},"roadmap/acid/overview":{"title":"Comms Roadmap Overview","links":["roadmap/acid/milestones-overview","tags/acid-updates"],"tags":["overview"],"content":"Welcome to the Comms Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/codex/milestones-overview":{"title":"Codex Milestones Overview","links":[],"tags":["milestones-overview"],"content":"Milestones §\n\nZenhub Tracker\nMiro Tracker\n"},"roadmap/codex/overview":{"title":"Codex Roadmap Overview","links":["roadmap/codex/milestones-overview","tags/codex-updates"],"tags":["overview"],"content":"Welcome to the Codex Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/innovation_lab/milestones-overview":{"title":"Innovation Lab Milestones Overview","links":[],"tags":["milestones"],"content":"iLab Milestones can be found on the Notion Page"},"roadmap/innovation_lab/overview":{"title":"Innovation Lab Roadmap Overview","links":["roadmap/innovation_lab/milestones-overview","tags/ilab-updates"],"tags":["overview"],"content":"Welcome to the Innovation lab Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/nomos/milestones-overview":{"title":"Nomos Milestones Overview","links":[],"tags":["milestones"],"content":"Milestones Overview Notion Page"},"roadmap/nomos/overview":{"title":"Nomos Roadmap Overview","links":["roadmap/nomos/milestones-overview","tags/nomos-updates"],"tags":["overview"],"content":"Welcome to the Nomos Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/vac/milestones-overview":{"title":"Vac Milestones Overview","links":[],"tags":["milestones"],"content":"Overview Notion Page - Information copied here for now\nInfo §\nStructure of milestone names: §\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 §\n\nRoadmap: P2P\nRoadmap: Token Economics\nRoadmap: Distributed Systems Testing (DST))\nRoadmap: Applied Cryptography and ZK (ACZ)\nRoadmap: Smart Contracts (SC)\nRoadmap: zkVM\nRoadmap: Deep Research (DR)\nRoadmap: RFC Process\n\n\nP2P §\n"},"roadmap/vac/overview":{"title":"Vac Roadmap","links":["roadmap/vac/p2p/overview","roadmap/vac/tke/overview","roadmap/vac/dst/overview","roadmap/vac/acz/overview","roadmap/vac/sc/overview","roadmap/vac/zkvm/overview","roadmap/vac/dr/overview","roadmap/vac/rfc/overview","tags/vac-updates","roadmap/vac/milestones-overview"],"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\nGroups §\n\np2p: Peer-to-peer\ntke: Token Engineering\ndst: Distributed Systems Testing\nacz: Applied Cryptography and Zero-knowledge\nsc: Smart Contracts\nzkvm: Zero-knowledge Virtual Machine\ndr: Deep Research\nrfc: RFC Process and Maintenance\n\nWeekly Updates §\n\nweekly updates\n\n\n\nMilestones\n"},"roadmap/waku/milestone-waku-10-users":{"title":"Milestone: Waku Network supports 10k Users","links":[],"tags":[],"content":"%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Scaling\n\t\t10k Users :done, 2023-01-20, 2023-07-31\n\nCompletion Deliverable §\nTBD\nEpics §\n\nGithub Issue Tracker\n"},"roadmap/waku/milestones-overview":{"title":"Waku Milestones Overview","links":["roadmap/waku/milestone-waku-10-users"],"tags":[],"content":"\n90% - Waku Network support for 10k users\n80% - Waku Network support for 1MM users\n65% - Restricted-run (light node) protocols are production ready\n60% - Peer management strategy for relay and light nodes are defined and implemented\n10% - Quality processes are implemented for nwaku and go-waku\n80% - Define and track network and community metrics for continuous monitoring improvement\n20% - Executed an array of community growth activity (8 hackathons, workshops, and bounties)\n15% - Dogfooding of RLN by platforms has started\n06% - First protocol to incentivize operators has been defined\n"},"roadmap/waku/overview":{"title":"Waku Roadmap","links":["roadmap/waku/milestones-overview","tags/waku-updates"],"tags":["waku-roadmap","overview"],"content":"Welcome to the Waku Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/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"},"roadmap/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"},"roadmap/codex/updates/2023-07-21":{"title":"2023-07-21 Codex weekly","links":["tags/479","tags/166"],"tags":["codex-updates","479","166"],"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\n1500.pdf\npcs-multiproofs.html\n1544.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 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 - 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 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 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 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\ndata-availability-sampling\n\n\ndas-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\ndas-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 - 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"},"roadmap/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 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 - edit\n\nInitial analysis of block discovery - 1067876\nInitial block discovery simulator - block-discovery-sim\n\n\n\nMilestone: Distributed Client Testing §\n\nLots of work around log collection/analysis and monitoring\n\nDetails here 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 - 483\n\n\n\nMilestone: Reservations and slot management §\n\nLots of work around slot reservation and queuing 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"},"roadmap/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 - 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 - _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 41\nMore related issues/PRs:\n\n20\n20\n\n\n\n\nTesting and debugging Condex in continuous testing environment\n\nDebugging continuous tests 44\npod labeling 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 - 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 - py-dht.\n\nNOTE: Several people are/where out during the last few weeks, so some milestones are paused until they are back"},"roadmap/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:\nwaku-objects-playground.vercel.app\nLink to Payggy design files:\n64ae9e965652632169060c7d\nMain development repo:\nwaku-objects-playground\nContact:\nYou can find us at 1118949151225413872 or join our discord at 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: waku-objects-playground\n\n"},"roadmap/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:\nwaku-objects-playground.vercel.app\nMain development repo:\nwaku-objects-playground\nGrayscale design:\ngrayscale.design\nLuminance package on npm:\nluminance\nContact:\nYou can find us at 1118949151225413872 or join our discord at 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 status-js-api Also I also found the 56/STATUS-COMMUNITIES 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 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: js Which also does not have documentation I assume that package is built from this: 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"},"roadmap/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:\nwww.wakuplay.im\nMain development repo:\nwaku-objects-playground\nContact:\nYou can find us at 1118949151225413872 or join our discord at eaYVgSUG"},"roadmap/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 (carnot_simulation_psuedocode.py)\nTest pseudocode (test_carnot_simulation.py)\nDescription of the simulation (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 (262)\nVote tally fix (268)\nIncreased run duration of integration tests (263)\nWarding improvements (269)\n\n\n"},"roadmap/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: 278, 279, 280, 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 (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"},"roadmap/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: 273#issuecomment-1661386628)\nDiscussions about how to manage the mixnet topology.\n(Link: 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: 288)\nAdded support for libp2p in tests.\n(Link: 287)\nAdded support for libp2p in nomos node.\n(Link: 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: 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: 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: 282)\n(Link: 289)\n(Link: 293)\n(Link: 295)\nRan simulations with 10K nodes.\nUpdated integration tests in CI to use waku or libp2p network.\n(Link: 290)\nFix for the node throughput during simulations.\n(Link: 295)\n"},"roadmap/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 [Mixnet-Architecture-613f53cf11a245098c50af6b191d31d2]\n\nDevelopment §\n\nMixnet PoC implementation starting [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 [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 2D-Reed-Solomon-Encoding-KZG-Commitments-benchmarking-b8340382ecc741c4a16b8a0c4a114450\nStudy documentation on Danksharding and set of questions for Leonardo [2D-Reed-Solomon-Encoding-KZG-Commitments-benchmarking-b8340382ecc741c4a16b8a0c4a114450]\n\n\nTesting, CI and Simulation App §\nDevelopment §\n\nSim fixes/improvements [299], [298], [295]\nSimulation app and instructions shared [300], [291], [294]\nCI: Updated and merged [290]\nParallel node init for improved simulation run times [300]\nImplemented branch overlay for simulating 100K+ nodes [291]\nSequential builds for nomos node features updated in CI [290]\n"},"roadmap/vac/acz/overview":{"title":"Applied Cryptography and Zero-knowledge Service Unit","links":["roadmap/vac/acz/rlnp2p/waku/production-readiness","roadmap/vac/acz/rlnp2p/waku/rln-relay-enhancements","roadmap/vac/acz/rlnp2p/waku/rln-membership-management","roadmap/vac/acz/zerokit/zerokit-v0.4"],"tags":["acz","vac"],"content":"vac:acz §\n\nrlnp2p:: §\n\n waku:production-readiness\n\ndue: 2023/07/31\nstatus: 100%\nmore info\n\n\nwaku:rln-relay-enhancements\n\ndue: 2023/09/30\nstatus: 50%\nmore info\n\n\nwaku:rln-membership-management\n\ndue: 2023/09/30\nstatus: 10%\nmore info\n\n\n\nzerokit:: §\n\nvac:zerokit-v0.4\n\ndue: 2023/09/07\nstatus: 0%\nmore details\n\n\nvac:maintenance\n\ndue: ongoing\nstatus: ongoing\n\n\n"},"roadmap/vac/dr/overview":{"title":"Deep Research Service Unit","links":[],"tags":["dr","vac"],"content":"vac:dr §"},"roadmap/vac/dst/overview":{"title":"Distributed Systems Testing Service Unit","links":[],"tags":["dst","vac"],"content":"vac:dst: §\n\nwakurtosis:: §\n\n waku:techreport\nwaku:techreport_02\nwaku:gossipsub-topology-analysis\nwaku:wakurtosis:features\nvac:rlog\nnomos:ci-integration\nnomos:ci-integration_02\nvac:maintenance\n\nanalysis::nomos:nomos-simulation-analysis §\ngsub-model:: §\n\nvac:refactoring\nstatus:control-messages\n\nshadow:: §\n\nvac:shadow-gossipsub-analysis\nwaku:shadow-waku-relay-analysis\n\n10ksim:: §\n\nvac:10ksim-bandwidth-test\nvac:10ksim-QoS\nvac:10ksim-waku-protocols\n\neng::vac:bundle-simulation-data §\nsoftware-testing:: §\n\nwaku:test-plans\nwaku:test-automation-js-waku\nwaku:test-automation-nwaku\nwaku:test-automation-go-waku\nwaku:test-automation-iterop-testing\n"},"roadmap/vac/p2p/overview":{"title":"P2P Service Unit","links":[],"tags":["p2p","vac"],"content":"vac:p2p: §\n\nnimlibp2p::vac:gossipsub-improvements-eip-4844 §\n\ndue: 2023/07/31\nstatus: 100%\n\nnimlibp2p::vac:webrtc-transport §\n\ndue: 2023/07/31\nstatus: 70%\n\nnimlibp2p::vac:maintenance §\n\nrepo: nim-libp2p\n\nnimchronos::vac:maintenance §\n\nrepo: nim-chronos\n"},"roadmap/vac/rfc/overview":{"title":"RFC Specifications Service Unit","links":[],"tags":["rfc","vac"],"content":"vac:rfc §"},"roadmap/vac/sc/overview":{"title":"Smart Contracts Service Unit","links":["roadmap/vac/sc/status/staking-contract","roadmap/vac/sc/status/staking-contract-02","roadmap/vac/sc/status/staking-contract-maintenance","roadmap/vac/sc/status/governance","roadmap/vac/sc/vac/rln-contract-support"],"tags":["sc","vac"],"content":"vac:sc:: §\n\nstatus: §\n\n snt-staking-contract\n\ndue: 2023/08/31\nstatus: 100%\nmore details\n\n\nsnt-staking-contract_02\n\ndue:\nstatus:\nmore details\n\n\nsnt-staking-contract-maintenance\n\ndue:\nstatus:\nmore details\n\n\ngovernance\n\ndue:\nstatus:\nmore details\n\n\n community-contracts-ERC721\n\ndue: 2023/08/31\nstatus: 100%\n\n\ncommunity-contracts-maintenance\n\ndue:\nstatus:\n\n\ncommunity-contracts-ERC20\n\ndue:\nstatus:\n\n\n\nvac: §\n\nsecureum-upskilling\n\ndue: 2023/10/15\nstatus: TBDd\n\n\nrln-contract-support\n\ndue: 2023/09/15\nstatus: 10%\nmore details\n\n\n"},"roadmap/vac/tke/overview":{"title":"Token Engineering Service Unit","links":["roadmap/vac/tke/status/snt-litepaper","roadmap/vac/tke/status/snt-staking","roadmap/vac/tke/codex/economic-analysis"],"tags":["p2p","vac"],"content":"vac:tke:: §\n\nstatus:SNT-litepaper §\n\ndue: 2023/07/31\nstatus: 70% - delayed: other milestones taking precedence\nmore details\n\nstatus:SNT-governance-proposal §\n\ndue: TBD\nstatus: NA - taking precedence over SNT-litepaper\nCC: Matty\n\nstatus:SNT-staking §\n\ndue: 2023/08/30\nstatus: 82%\nmore details\n\ncodex:economic-analysis §\n\ndue: 2023/08/30\nstatus: 50%\nmore details\n\nnomox:economic-analysis §\n\ndue: 2023/10/31\nstatus: 30%\nCC: Frederico\n"},"roadmap/vac/zkvm/overview":{"title":"Zero-knowledge Virtual Machine Incubation Project","links":[],"tags":["zkvm","vac"],"content":"vac:zkvm §"},"roadmap/vac/updates/2023-07-10":{"title":"2023-07-10 Vac Weekly","links":[],"tags":["vac-updates"],"content":"\nvc::Deep Research\n\nrefined deep research roadmaps 190, 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 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 - rln-contract\nfixed homebrew issue that prevented zerokit from building - 8a365f0c9e5c4a744f70c5dd4904ce8d8f926c34\nrln-relay: verify proofs based upon bandwidth usage - 3fe4522a7e9e48a3196c10973975d924269d872a\nRLN contract audit cont’ B195lgIth\n\n\n"},"roadmap/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 (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"},"roadmap/vac/updates/2023-07-24":{"title":"2023-08-03 Vac weekly","links":["tags/139"],"tags":["vac-updates","139"],"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 ( 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 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: 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 (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 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” (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 (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"},"roadmap/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 (934) & Limit flood publishing (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 (142, DST-Analysis)\nhiring\n\n\nmilestone (99%, 2023/07/31) Wakurtosis Waku Report\n\nRe-run simulations\nmerge Discv5 PR (129).\nfinalize Wakurtosis Tech Report v2\n\n\nmilestone (100%, 2023/07/31) Nomos CI testing\n\ndelivered first version of Nomos CI integration (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: 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 ark-circom\nachievment :: publish zerokit_utils zerokit_utils\nachievment :: publish rln 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 - rln-contract and waku-rln-contract\nDeployed to sepolia\nFixed rln enabled docker image building in nwaku - 1853\n\n\nzerokit:\n\nachievement :: zerokit v0.3.0 release done - v0.3.0 (𝕏 jointly with zkVM)\n\n\n\n\n"},"roadmap/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):\nVac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac week 32 August 7th\n\nvsu::P2P\n\nvac:p2p:nim-libp2p:vac:maintenance\n\nImprove gossipsub DDoS resistance 920\n\n\nvac:p2p:nim-chronos:vac:maintenance\n\nRemove hard-coded ports from test 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 (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 (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 ( SuperNova-research-document-8deab397f8fe413fa3a1ef3aa5669f37 )\nresearched starky\n80% Halo2 notes ( 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 - 3\nmark duplicated messages as spam - 1867\nuse waku-org/waku-rln-contract as a submodule in nwaku - 1884\n\n\nvac:acz:zerokit:vac:maintenance\n\nFixed atomic_operation ffi edge case error - 195\ndocs cleanup - 196\nfixed version tags - 194\nreleased zerokit v0.3.1 - 198\nmarked all functions as virtual in rln-contract for inheritors - a092b934a6293203abbd4b9e3412db23ff59877e\nmake nwaku use zerokit v0.3.1 - 1886\nrlnp2p implementers draft - rln-impl-w-waku\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nzerokit v0.4.0 release planning - 197\n\n\n\n\nvc::Deep Research\n\nvac:dr:valpriv:vac:tor-push-poc\n\nredesigned the torpush integration in nimbus 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"},"roadmap/vac/updates/2023-08-14":{"title":"2023-08-17 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac Milestones: Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac week 33 August 14th §\n\nvsu::P2P §\nvac:p2p:nim-libp2p:vac:maintenance §\n\nImprove gossipsub DDoS resistance 920\ndelivered: Perf protocol 925\ndelivered: Test-plans for the perf protocol perf-nim\nBandwidth estimate as a parameter (waiting for final review) 941\n\nvac:p2p:nim-chronos:vac:maintenance §\n\ndelivered: Remove hard-coded ports from test 429\ndelivered: fixed flaky test using REUSE_PORT 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 (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 eip-1967\nC3 Linearization 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: foundry-template\n\n\n\n\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:zerokit:vac:maintenance\n\nPR reviews 200, 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 1106 and Protostar 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"},"roadmap/vac/updates/2023-08-21":{"title":"2023-08-21 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac Milestones: Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac Github Repos: 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) 262\nWebRTC: Merge all protocols (60%: slowed down by some complications and bad planning with Mbed-TLS) 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 (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 - 1852\nfixed ganache’s change in method to manage subprocesses, fixed timeouts related to it - 1913\nshould error out on rln-relay mount failure - 1904\nfixed invalid start index being used in rln-relay - 1915\nconstrain the values that can be used as idCommitments in the rln-contract - 26\nassist with waku-simulator testing\nremove registration capabilities from nwaku, it should be done out of band - 1916\nadd deployedBlockNumber to the rln-contract for ease of fetching events from the client - 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 - 206\nuse pmtree instead of vacp2p_pmtree now that changes have been upstreamed - 203\nPrepared a PR to fix a stopgap introduces by PR 201 207\nPR review 202, 206\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nsubstitute id_commitments for rate_commitments and update tests in rln-v2 - 205\nrln-v2 working branch - 204\nmisc research while ooo:\nstealth commitment scheme inspired by erc-5564 - erc-5564-bn254, associated circuit - 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 (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 (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"},"roadmap/vac/updates/2023-08-28":{"title":"2023-08-28 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac week 35 §\n\nVac Milestones: Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac Github Repos: 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) 887\nImprove gossipsub DDoS resistance (98%) 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 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: 11954#issuecomment-1694591812\nupdating ERC2470 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 : 1925, 1928, 1931\n\n\nvac:acz:rlnp2p:waku:rln-relay-enhancments\n\ntree metadata should include chainId and contractAddress - 1932\nset flush_interval appropriately -1933\nintegrate new WakuRlnRegistry contract - 1943\nbump zerokit to v0.3.2 1951\ntree metadata should include window of roots - 1953\nsync tree state from contract deployed block number - 1955\noptimization to waku_keystore - 1956\nfixed a forceProgression bug in the WakuRlnRegistry contract - 6\n\n\nvac:acz:zerokit:vac:maintenance\n\nprevent tree db from being recreated if it exists - 209\nreleased zerokit v0.3.2 - v0.3.2\nmerged PR to fix a stopgap introduced by PR 201 207\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nPrepared a PR to deal with message_id range check 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 zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#01301b98f3af4157b932112ed998cff2\nWrite notes on Protostar\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nminor fixes plonky2 PR 5\nREADME’s to make zk-explorations repo public 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 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\n610\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"},"roadmap/vac/updates/2023-09-04":{"title":"2023-09-04 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac 2023/09/04 §\n\nVac Milestones\n[Vac Github Repos] (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) 887\nImprove gossipsub DDoS resistance (98%) 920\n\n\n\nvsu::Tokenomics §\n\nvac:tke::codex:economic-analysis\n\nPresenting Filecoin findings to Codex team\nLitepaper: assumptions on collateral\n\n\nvac:tke::status: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\nvac:tke::nomos:economic-analysis\n\nDelegated staking specifications w/Marcin, update for privacy constraints\nBribery attacks analysis, Moh asked to followup early/mid Sep\n\n\nvac:tke::waku:economic-analysis\n\nFormalized RLN thoughts shared w/ Aaryamann, will push for additional feedback once Martin returns\n\n\n\nvsu::Distributed Systems Testing (DST) §\n\nvac:dst:analysis: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\nvac:dst:wakurtosis:vac:retrospective-rlog\n\nGather info and wrote summary of why we decided to stop using Kurtosis.\n\n\nvac:dst:10ksim:vac:10ksim-bandwidth-test\n\nCode diagrams + structurization\nChats with Ben (Codex)\n\n\nvac:dst:wakurtosis: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\nvac:dst:software-testing:waku:test-plans\n\nAdded test plans for filter, lightpush and store: Test-Plans-09c8c7b7f6784c459fb774792665e37c\n\n\nvac:dst:software-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\nvsu:Smart Contracts (SC) §\n\nvac:sc::vac:secureum-upskilling\n\nNo progress; busy with CommunityTokenDeployer contract\n\n\nvac:sc::status: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\nvac:sc::status: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\nvac:sc::status: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\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:rlnp2p:waku:membership-management\n\nfixed makefile target for rln-keystore-generator - 1960\nlog the membership index out upon registration in the rln-keystore-generator - 1963\n\n\nvac:acz:rlnp2p:waku:rln-relay-enhancments\n\nrln was enabled by default in the Makefile - fixed - 1964\nordered pubsub validator execution - 1966\nfixed deserialization of valid merkle roots - 1973\nconfirm that the fetched credential from the keystore is registered to the membership set - 1980\nfixed makefile target for zerokit’s librln.a - 1981\nconverted zero-based indexing to 1-based indexing on vacp2p/rln-contract - 28\ndownstreamed zero-based indexing to waku-org/waku-rln-contract - 8 -\ndeployed new version of the registry contract on sepolia - 0xc04937d502E0ae671cedFC2A0BCD6692055520f3\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nMerged a PR to deal with message_id range check 210\nresearched tree_size issue for the 0.4 release\nresearched idCommitment/rateCommitment issue for the 0.4 release\n\n\n\nvip::zkVM §\n\nvac:zkvm::vac:research-existing-proof-systems\n\n[blog post] (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 (zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#cce2cc365a384126b2a5041900bd3ce9)\nContinued Lasso research (introducing-lasso-and-jolt)\nNotes for Protogalaxy; 100%\nNotes for Protostar\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nAdded an introductory section for Benchmark in zk-explorations repo: 10\n\n\n\nvc::Deep Research §\n\nvac:dr:gsub-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\nvac:dr:valpriv:vac:tor-push-poc\n\nDebugged various appraoches(tcp, gossip, tor). Triaged why attestations not working\n\n\nvac:dr:valpriv:vac:tor-push-relwork\n\ncompleted related work all\n\n\nvac:dr:consensus:nomos:carnot-paper\n\nPublishing the Carnot paper (Done) 2308.16016.pdf\nBegin work on writing up Carnot’s specification in RFC format\n\n\nvac:dr:consensus:nomos:carnot-bribery-article\n\nFinishing (describing research directions and their pros and cons, polishing the article) and publishing the article (Done) WIP-Bribery-Attacks-in-Consensus-Protocols-Challenges-and-Solutions-e4e108c17dba421abe83de49076c8f25\n\n\nvac:dr:consensus: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\nvc::RFC §\n\nvac:rfc:rfc:status: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"},"roadmap/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"},"roadmap/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"},"roadmap/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 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 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 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 persistance 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\nincorporating 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"},"roadmap/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 1894\nSetting up a staging fleet for Status to try static sharding\nRunning simulations for Store protocol: 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 (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"},"roadmap/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 responsable 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"},"roadmap/vac/acz/zerokit/zerokit-v0.4":{"title":"Zerokit v0.4 Release Details","links":["tags/197"],"tags":["197"],"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: 0%\n\nDescription §\n\nRelease Planning - Github Issue #197\n"},"roadmap/vac/sc/status/governance":{"title":"Status Governance Contract Details","links":[],"tags":[],"content":"\ndue date: 2023\nstatus: TBD\n\nDescription §"},"roadmap/vac/sc/status/staking-contract-02":{"title":"Status Staking Contract - next - Details","links":[],"tags":[],"content":"vac:sc::status:staking-contract_02 §\n\n\ndue date: TBD\nstatus: TBD\n\nDescription §\nTBD"},"roadmap/vac/sc/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"},"roadmap/vac/sc/status/staking-contract":{"title":"Status Staking Contract","links":[],"tags":[],"content":"vac:sc::status:staking-contract §\n\n%%{ \n init: { \n 'theme': 'base', \n '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"},"roadmap/vac/sc/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"},"roadmap/vac/tke/codex/economic-analysis":{"title":"Codex Economic Analysis Details","links":[],"tags":[],"content":"vac:tke::codex:economic-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Codex\n\t\tEconomic Analysis :, 2023-01-20, 2023-08-30\n\n\ndue: 2023/08/30\nstatus: 50%\nCC: Matty\n\nDescription §\nCodex economic analysis, Codex token utility, Codex collateral management"},"roadmap/vac/tke/nomos/economic-analysis":{"title":"Nomos Economic Analysis Details","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-01-20, 2023-10-31\n\n\ndue: 2023/10/31\nstatus: 30%\nCC: Frederico\n\nDescription §\nNomos economic analysis, Nomos token utility, requirements and constraints"},"roadmap/vac/tke/status/snt-governance-proposal":{"title":"SNT Governance Proposal","links":[],"tags":[],"content":"vac:tke::status:SNT-governance-proposal §\n\ndue: TBD\nstatus: TDB\nCC: Matty"},"roadmap/vac/tke/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 Llitepaper :, 2023-01-20, 2023-08-30\n\n\nCompletion: TBD\nCC: Matty\n"},"roadmap/vac/tke/status/snt-staking":{"title":"SNT Staking Details","links":["roadmap/vac/sc/overview"],"tags":[],"content":"vac:tke::status:SNT-staking §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tSNT Staking :, 2023-01-20, 2023-08-30\n\n\ndue: 2023/08/30\nstatus: 82%\nCC: Frederico (Python), Martin\ncollab: smart contracts team\n\nDescription: §\nTBD"},"roadmap/vac/tke/waku/economic-analysis":{"title":"Waku Economic Analysis Details","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-01-20, 2023-11-30\n\n\ndue: 2023/10/31\nstatus: 10%\nCC: Martin\n\nDescription §\nWaku economic analysis, Nomos token utility, requirements and constraints"},"roadmap/vac/acz/rlnp2p/waku/production-readiness":{"title":"RLNP2P Waku Pruduction Readiness Details","links":[],"tags":[],"content":"vac:acz:rlnp2p::waku:production-readiness §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tProduction Readiness :done, 2023-01-20, 2023-07-31\n\n\ndue: 2023/07/31\nstatus: 100%\n\nDescription §\nmembership management is out of scope for this milestone\nDeliverables §\nTBD"},"roadmap/vac/acz/rlnp2p/waku/rln-membership-management":{"title":"Waku RLN Membership Management Details","links":["roadmap/waku/overview"],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-membership-management §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN Membership Management :, 2023-01-20, 2023-09-30\n\n\ndue: 2023/09/30\nstatus: 10%\n\nDescription §\nEnhancing the first simple CC membership list\nRisks §\n\ndepends on input from Waku\n\n"},"roadmap/vac/acz/rlnp2p/waku/rln-relay-enhancements":{"title":"Waku RLN-RELAY Enhancements Details","links":[],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-relay-enhancements §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN-RELAY enhancements :, 2023-01-20, 2023-09-30\n\n\ndue: 2023/09/30\nstatus: 50%\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\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\n"}} \ No newline at end of file +{"configuration":{"title":"Configuration","links":["layout","RSS-Feed","SPA-Routing","popover-previews","hosting","private-pages","graph-view","syntax-highlighting","making-plugins","Latex"],"tags":[],"content":"Quartz is meant to be extremely configurable, even if you don’t know any coding. Most of the configuration you should need can be done by just editing quartz.config.ts or changing the layout in quartz.layout.ts.\n\n\n \n Tip \n \n \nIf you edit Quartz configuration using a text-editor that has TypeScript language support like VSCode, it will warn you when you you’ve made an error in your configuration, helping you avoid configuration mistakes!\n\nThe configuration of Quartz can be broken down into two main parts:\nquartz.config.tsconst config: QuartzConfig = {\n configuration: { ... },\n plugins: { ... },\n}\nGeneral Configuration §\nThis part of the configuration concerns anything that can affect the whole site. The following is a list breaking down all the things you can configure:\n\npageTitle: title of the site. This is also used when generating the RSS Feed for your site.\nenableSPA: whether to enable SPA Routing on your site.\nenablePopovers: whether to enable popover previews on your site.\nanalytics: what to use for analytics on your site. Values can be\n\nnull: don’t use analytics;\n{ provider: 'plausible' }: use Plausible, a privacy-friendly alternative to Google Analytics; or\n{ provider: 'google', tagId: <your-google-tag> }: use Google Analytics\n\n\nbaseUrl: this is used for sitemaps and RSS feeds that require an absolute URL to know where the canonical ‘home’ of your site lives. This is normally the deployed URL of your site (e.g. quartz.jzhao.xyz for this site). Do not include the protocol (i.e. https://) or any leading or trailing slashes.\n\nThis should also include the subpath if you are hosting on GitHub pages without a custom domain. For example, if my repository is jackyzha0/quartz, GitHub pages would deploy to https://jackyzha0.github.io/quartz and the baseUrl would be jackyzha0.github.io/quartz\nNote that Quartz 4 will avoid using this as much as possible and use relative URLs whenever it can to make sure your site works no matter where you end up actually deploying it.\n\n\nignorePatterns: a list of glob patterns that Quartz should ignore and not search through when looking for files inside the content folder. See private pages for more details.\ntheme: configure how the site looks.\n\ntypography: what fonts to use. Any font available on Google Fonts works here.\n\nheader: Font to use for headers\ncode: Font for inline and block quotes.\nbody: Font for everything\n\n\ncolors: controls the theming of the site.\n\nlight: page background\nlightgray: borders\ngray: graph links, heavier borders\ndarkgray: body text\ndark: header text and icons\nsecondary: link colour, current graph node\ntertiary: hover states and visited graph nodes\nhighlight: internal link background, highlighted text, highlighted lines of code\n\n\n\n\n\nPlugins §\nYou can think of Quartz plugins as a series of transformations over content.\n\nplugins: {\n transformers: [...],\n filters: [...],\n emitters: [...],\n}\n\nTransformers map over content (e.g. parsing frontmatter, generating a description)\nFilters filter content (e.g. filtering out drafts)\nEmitters reduce over content (e.g. creating an RSS feed or pages that list all files with a specific tag)\n\nBy adding, removing, and reordering plugins from the tranformers, filters, and emitters fields, you can customize the behaviour of Quartz.\n\n\n \n Note \n \n \nEach node is modified by every transformer in order. Some transformers are position-sensitive so you may need to take special note of whether it needs come before or after any other particular plugins.\n\nAdditionally, plugins may also have their own configuration settings that you can pass in. For example, the Latex plugin allows you to pass in a field specifying the renderEngine to choose between Katex and MathJax.\ntransformers: [\n Plugin.FrontMatter(), // uses default options\n Plugin.Latex({ renderEngine: "katex" }), // specify some options\n]\nIf you’d like to make your own plugins, read the guide on making plugins for more information."},"hosting":{"title":"Hosting","links":["RSS-Feed","configuration"],"tags":[],"content":"Quartz effectively turns your Markdown files and other resources into a bundle of HTML, JS, and CSS files (a website!).\nHowever, if you’d like to publish your site to the world, you need a way to host it online. This guide will detail how to deploy with either GitHub Pages or Cloudflare pages but any service that allows you to deploy static HTML should work as well (e.g. Netlify, Replit, etc.)\n\n\n \n Tip \n \n \nSome Quartz features (like RSS Feed and sitemap generation) require baseUrl to be configured properly in your configuration to work properly. Make sure you set this before deploying!\n\nCloudflare Pages §\n\nLog in to the Cloudflare dashboard and select your account.\nIn Account Home, select Workers & Pages > Create application > Pages > Connect to Git.\nSelect the new GitHub repository that you created and, in the Set up builds and deployments section, provide the following information:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nConfiguration optionValueProduction branchv4Framework presetNoneBuild commandnpx quartz buildBuild output directorypublic\nPress “Save and deploy” and Cloudflare should have a deployed version of your site in about a minute. Then, every time you sync your Quartz changes to GitHub, your site should be updated.\nTo add a custom domain, check out Cloudflare’s documentation.\nGitHub Pages §\nLike Quartz 3, you can deploy the site generated by Quartz 4 via GitHub Pages.\nIn your local Quartz, create a new file quartz/.github/workflows/deploy.yml.\nquartz/.github/workflows/deploy.ymlname: Deploy Quartz site to GitHub Pages\n \non:\n push:\n branches:\n - v4\n \npermissions:\n contents: read\n pages: write\n id-token: write\n \nconcurrency:\n group: "pages"\n cancel-in-progress: false\n \njobs:\n build:\n runs-on: ubuntu-22.04\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0 # Fetch all history for git info\n - uses: actions/setup-node@v3\n with:\n node-version: 18.14\n - name: Install Dependencies\n run: npm ci\n - name: Build Quartz\n run: npx quartz build\n - name: Upload artifact\n uses: actions/upload-pages-artifact@v2\n with:\n path: public\n \n deploy:\n needs: build\n environment:\n name: github-pages\n url: ${{ steps.deployment.outputs.page_url }}\n runs-on: ubuntu-latest\n steps:\n - name: Deploy to GitHub Pages\n id: deployment\n uses: actions/deploy-pages@v2\nThen:\n\nHead to “Settings” tab of your forked repository and in the sidebar, click “Pages”. Under “Source”, select “GitHub Actions”.\nCommit these changes by doing npx quartz sync. This should deploy your site to <github-username>.github.io/<repository-name>.\n\n\n\n \n Tip \n \n \nIf you get an error about not being allowed to deploy to github-pages due to environment protection rules, make sure you remove any existing GitHub pages environments.\nYou can do this by going to your Settings page on your GitHub fork and going to the Environments tab and pressing the trash icon. The GitHub action will recreate the environment for you correctly the next time you sync your Quartz.\n\nCustom Domain §\nHere’s how to add a custom domain to your GitHub pages deployment.\n\nHead to the “Settings” tab of your forked repository.\nIn the “Code and automation” section of the sidebar, click “Pages”.\nUnder “Custom Domain”, type your custom domain and click “Save”.\nThis next step depends on whether you are using an apex domain (example.com) or a subdomain (subdomain.example.com).\n\nIf you are using an apex domain, navigate to your DNS provider and create an A record that points your apex domain to GitHub’s name servers which have the following IP addresses:\n\n185.199.108.153\n185.199.109.153\n185.199.110.153\n185.199.111.153\n\n\nIf you are using a subdomain, navigate to your DNS provider and create a CNAME record that points your subdomain to the default domain for your site. For example, if you want to use the subdomain quartz.example.com for your user site, create a CNAME record that points quartz.example.com to <github-username>.github.io.\n\n\n\nThe above shows a screenshot of Google Domains configured for both jzhao.xyz (an apex domain) and quartz.jzhao.xyz (a subdomain).\nSee the GitHub documentation for more detail about how to setup your own custom domain with GitHub Pages.\n\n\n \n Why aren't my changes showing up? \n \n \nThere could be many different reasons why your changes aren’t showing up but the most likely reason is that you forgot to push your changes to GitHub.\nMake sure you save your changes to Git and sync it to GitHub by doing npx quartz sync. This will also make sure to pull any updates you may have made from other devices so you have them locally.\n"},"index":{"title":"","links":["roadmap/waku/overview","roadmap/codex/overview","roadmap/nomos/overview","roadmap/vac/overview","roadmap/innovation_lab/overview","roadmap/acid/overview"],"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.\n\n\n \n Note \n \n \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.\nIt is our aim to continuously get closer to that target, but we will continuously fail at that. If you know something is out of date or incorrect, raise an issue or make a PR.\n\nNavigation §\n\nWaku\nCodex\nNomos\nVac\nInnovation Lab\nComms (Acid Info)\n"},"index_default":{"title":"Welcome to Quartz 4","links":["showcase","authoring-content","configuration","layout","build","hosting","migrating-from-Quartz-3","Obsidian-compatibility","full-text-search","graph-view","wikilinks","backlinks","Latex","syntax-highlighting","popover-previews","features","creating-components","SPA-Routing","making-plugins","philosophy","architecture","upgrading"],"tags":[],"content":"Quartz is a fast, batteries-included static-site generator that transforms Markdown content into fully functional websites. Thousands of students, developers, and teachers are already using Quartz to publish personal notes, wikis, and digital gardens to the web.\n🪴 Get Started §\nQuartz requires at least Node v18.14 to function correctly. Ensure you have this installed on your machine before continuing.\nThen, in your terminal of choice, enter the following commands line by line:\ngit clone https://github.com/jackyzha0/quartz.git\ncd quartz\nnpm i\nnpx quartz create\nThis will guide you through initializing your Quartz with content. Once you’ve done so, see how to:\n\nAuthor content in Quartz\nConfigure Quartz’s behaviour\nChange Quartz’s layout\nBuild and preview Quartz\nHost Quartz online\n\n\n\n \n Info \n \n \nComing from Quartz 3? See the migration guide for the differences between Quartz 3 and Quartz 4 and how to migrate.\n\n🔧 Features §\n\nObsidian compatibility, full-text search, graph view, wikilinks, backlinks, Latex, syntax highlighting, popover previews, and many more right out of the box\nHot-reload for both configuration and content\nSimple JSX layouts and page components\nRidiculously fast page loads and tiny bundle sizes\nFully-customizable parsing, filtering, and page generation through plugins\n\nFor a comprehensive list of features, visit the features page. You can read more about the why behind these features on the philosophy page and a technical overview on the architecture page.\n🚧 Troubleshooting + Updating §\nHaving trouble with Quartz? Try searching for your issue using the search feature. If you haven’t already, upgrade to the newest version of Quartz to see if this fixes your issue.\nIf you’re still having trouble, feel free to submit an issue if you feel you found a bug or ask for help in our Discord Community."},"layout":{"title":"Layout","links":["tags/component","creating-components","configuration"],"tags":[],"content":"Certain emitters may also output HTML files. To enable easy customization, these emitters allow you to fully rearrange the layout of the page. The default page layouts can be found in quartz.layout.ts.\nEach page is composed of multiple different sections which contain QuartzComponents. The following code snippet lists all of the valid sections that you can add components to:\nquartz/cfg.tsexport interface FullPageLayout {\n head: QuartzComponent // single component\n header: QuartzComponent[] // laid out horizontally\n beforeBody: QuartzComponent[] // laid out vertically\n pageBody: QuartzComponent // single component\n left: QuartzComponent[] // vertical on desktop, horizontal on mobile\n right: QuartzComponent[] // vertical on desktop, horizontal on mobile\n footer: QuartzComponent // single component\n}\nThese correspond to following parts of the page:\n\n\n\n \n Note \n \n \nThere are two additional layout fields that are not shown in the above diagram.\n\nhead is a single component that renders the <head> tag in the HTML. This doesn’t appear visually on the page and is only is responsible for metadata about the document like the tab title, scripts, and styles.\nheader is a set of components that are laid out horizontally and appears before the beforeBody section. This enables you to replicate the old Quartz 3 header bar where the title, search bar, and dark mode toggle. By default, Quartz 4 doesn’t place any components in the header.\n\n\nQuartz components, like plugins, can take in additional properties as configuration options. If you’re familiar with React terminology, you can think of them as Higher-order Components.\nSee a list of all the components for all available components along with their configuration options. You can also checkout the guide on creating components if you’re interested in further customizing the behaviour of Quartz.\nStyle §\nMost meaningful style changes like colour scheme and font can be done simply through the general configuration options. However, if you’d like to make more involved style changes, you can do this by writing your own styles. Quartz 4, like Quartz 3, uses Sass for styling.\nYou can see the base style sheet in quartz/styles/base.scss and write your own in quartz/styles/custom.scss.\n\n\n \n Note \n \n \nSome components may provide their own styling as well! For example, quartz/components/Darkmode.tsx imports styles from quartz/components/styles/darkmode.scss. If you’d like to customize styling for a specific component, double check the component definition to see how its styles are defined.\n"},"migrating-from-Quartz-3":{"title":"Migrating from Quartz 3","links":["configuration","hosting","folder-and-tag-listings","creating-components"],"tags":[],"content":"As you already have Quartz locally, you don’t need to fork or clone it again. Simply just checkout the alpha branch, install the dependencies, and import your old vault.\ngit fetch\ngit checkout v4\ngit pull upstream v4\nnpm i\nnpx quartz create\nIf you get an error like fatal: 'upstream' does not appear to be a git repository, make sure you add upstream as a remote origin:\ngit remote add upstream https://github.com/jackyzha0/quartz.git\nWhen running npx quartz create, you will be prompted as to how to initialize your content folder. Here, you can choose to import or link your previous content folder and Quartz should work just as you expect it to.\n\n\n \n Note \n \n \nIf the existing content folder you’d like to use is at the same path on a different branch, clone the repo again somewhere at a different path in order to use it.\n\nKey changes §\n\nRemoving Hugo and hugo-obsidian: Hugo worked well for earlier versions of Quartz but it also made it hard for people outside of the Golang and Hugo communities to fully understand what Quartz was doing under the hood and be able to properly customize it to their needs. Quartz 4 now uses a Node-based static-site generation process which should lead to a much more helpful error messages and an overall smoother user experience.\nFull-hot reload: The many rough edges of how hugo-obsidian integrated with Hugo meant that watch mode didn’t re-trigger hugo-obsidian to update the content index. This lead to a lot of weird cases where the watch mode output wasn’t accurate. Quartz 4 now uses a cohesive parse, filter, and emit pipeline which gets run on every change so hot-reloads are always accurate.\nReplacing Go template syntax with JSX: Quartz 3 used Go templates to create layouts for pages. However, the syntax isn’t great for doing any sort of complex rendering (like text processing) and it got very difficult to make any meaningful layout changes to Quartz 3. Quartz 4 uses an extension of JavaScript syntax called JSX which allows you to write layout code that looks like HTML in JavaScript which is significantly easier to understand and maintain.\nA new extensible configuration and plugin system: Quartz 3 was hard to configure without technical knowledge of how Hugo’s partials worked. Extensions were even hard to make. Quartz 4’s configuration and plugin system is designed to be extended by users while making updating to new versions of Quartz easy.\n\nThings to update §\n\nYou will need to update your deploy scripts. See the hosting guide for more details.\nEnsure that your default branch on GitHub is updated from hugo to v4.\nFolder and tag listings have also changed.\n\nFolder descriptions should go under content/<folder-name>/index.md where <folder-name> is the name of the folder.\nTag descriptions should go under content/tags/<tag-name>.md where <tag-name> is the name of the tag.\n\n\nSome HTML layout may not be the same between Quartz 3 and Quartz 4. If you depended on a particular HTML hierarchy or class names, you may need to update your custom CSS to reflect these changes.\nIf you customized the layout of Quartz 3, you may need to translate these changes from Go templates back to JSX as Quartz 4 no longer uses Hugo. For components, check out the guide on creating components for more details on this.\n"},"philosophy":{"title":"Philosophy of Quartz","links":[],"tags":[],"content":"A garden should be a true hypertext §\n\nThe garden is the web as topology. Every walk through the garden creates new paths, new meanings, and when we add things to the garden we add them in a way that allows many future, unpredicted relationships.\n(The Garden and the Stream)\n\nThe problem with the file cabinet is that it focuses on efficiency of access and interoperability rather than generativity and creativity. Thinking is not linear, nor is it hierarchical. In fact, not many things are linear or hierarchical at all. Then why is it that most tools and thinking strategies assume a nice chronological or hierarchical order for my thought processes? The ideal tool for thought for me would embrace the messiness of my mind, and organically help insights emerge from chaos instead of forcing an artificial order. A rhizomatic, not arboresecent, form of note taking.\nMy goal with a digital garden is not purely as an organizing system and information store (though it works nicely for that). I want my digital garden to be a playground for new ways ideas can connect together. As a result, existing formal organizing systems like Zettelkasten or the hierarchical folder structures of Notion don’t work well for me. There is way too much upfront friction that by the time I’ve thought about how to organize my thought into folders categories, I’ve lost it.\nQuartz embraces the inherent rhizomatic and web-like nature of our thinking and tries to encourage note-taking in a similar form.\n\nA garden should be shared §\nThe goal of digital gardening should be to tap into your network’s collective intelligence to create constructive feedback loops. If done well, I have a shareable representation of my thoughts that I can send out into the world and people can respond. Even for my most half-baked thoughts, this helps me create a feedback cycle to strengthen and fully flesh out that idea.\nQuartz is designed first and foremost as a tool for publishing digital gardens to the web. To me, digital gardening is not just passive knowledge collection. It’s a form of expression and sharing.\n\n“[One] who works with the door open gets all kinds of interruptions, but [they] also occasionally gets clues as to what the world is and what might be important.”\n— Richard Hamming\n\nThe goal of Quartz is to make sharing your digital garden free and simple. At its core, Quartz is designed to be easy to use enough for non-technical people to get going but also powerful enough that senior developers can tweak it to work how they’d like it to work."},"showcase":{"title":"Quartz Showcase","links":[],"tags":[],"content":"Want to see what Quartz can do? Here are some cool community gardens:\n\nQuartz Documentation (this site!)\nJacky Zhao’s Garden\nBrandon Boswell’s Garden\nScaling Synthesis - A hypertext research notebook\nAWAGMI Intern Notes\nCourse notes for Information Technology Advanced Theory\nData Dictionary 🧠\nsspaeti.com’s Second Brain\noldwinterの数字花园\nAbhijeet’s Math Wiki\nMike’s AI Garden 🤖🪴\nMatt Dunn’s Second Brain\n\nIf you want to see your own on here, submit a Pull Request adding yourself to this file!"},"upgrading":{"title":"Upgrading Quartz","links":["migrating-from-Quartz-3"],"tags":[],"content":"\n\n \n Note \n \n \nThis is specifically a guide for upgrading Quartz 4 version to a more recent update. If you are coming from Quartz 3, check out the migration guide for more info.\n\nTo fetch the latest Quartz updates, simply run\nnpx quartz update\nAs Quartz uses git under the hood for versioning, updating effectively ‘pulls’ in the updates from the official Quartz GitHub repository. If you have local changes that might conflict with the updates, you may need to resolve these manually yourself (or, pull manually using git pull origin upstream).\n\n\n \n Tip \n \n \nQuartz will try to cache your content before updating to try and prevent merge conflicts. If you get a conflict mid-merge, you can stop the merge and then run npx quartz restore to restore your content from the cache.\n\nIf you have the GitHub desktop app, this will automatically open to help you resolve the conflicts. Otherwise, you will need to resolve this in a text editor like VSCode. For more help on resolving conflicts manually, check out the GitHub guide on resolving merge conflicts."},"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."},"roadmap/acid/milestones-overview":{"title":"Comms Milestones Overview","links":[],"tags":["milestones"],"content":"\nComms Roadmap\nComms Projects\nComms planner deadlines\n"},"roadmap/acid/overview":{"title":"Comms Roadmap Overview","links":["roadmap/acid/milestones-overview","tags/acid-updates"],"tags":["overview"],"content":"Welcome to the Comms Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/codex/milestones-overview":{"title":"Codex Milestones Overview","links":[],"tags":["milestones-overview"],"content":"Milestones §\n\nZenhub Tracker\nMiro Tracker\n"},"roadmap/codex/overview":{"title":"Codex Roadmap Overview","links":["roadmap/codex/milestones-overview","tags/codex-updates"],"tags":["overview"],"content":"Welcome to the Codex Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/innovation_lab/milestones-overview":{"title":"Innovation Lab Milestones Overview","links":[],"tags":["milestones"],"content":"iLab Milestones can be found on the Notion Page"},"roadmap/innovation_lab/overview":{"title":"Innovation Lab Roadmap Overview","links":["roadmap/innovation_lab/milestones-overview","tags/ilab-updates"],"tags":["overview"],"content":"Welcome to the Innovation lab Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/nomos/milestones-overview":{"title":"Nomos Milestones Overview","links":[],"tags":["milestones"],"content":"Milestones Overview Notion Page"},"roadmap/nomos/overview":{"title":"Nomos Roadmap Overview","links":["roadmap/nomos/milestones-overview","tags/nomos-updates"],"tags":["overview"],"content":"Welcome to the Nomos Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/vac/milestones-overview":{"title":"Vac Milestones Overview","links":[],"tags":["milestones"],"content":"Overview Notion Page - Information copied here for now\nInfo §\nStructure of milestone names: §\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 §\n\nRoadmap: P2P\nRoadmap: Token Economics\nRoadmap: Distributed Systems Testing (DST))\nRoadmap: Applied Cryptography and ZK (ACZ)\nRoadmap: Smart Contracts (SC)\nRoadmap: zkVM\nRoadmap: Deep Research (DR)\nRoadmap: RFC Process\n\n\nP2P §\n"},"roadmap/vac/overview":{"title":"Vac Roadmap","links":["roadmap/vac/p2p/overview","roadmap/vac/tke/overview","roadmap/vac/dst/overview","roadmap/vac/acz/overview","roadmap/vac/sc/overview","roadmap/vac/zkvm/overview","roadmap/vac/dr/overview","roadmap/vac/rfc/overview","tags/vac-updates","roadmap/vac/milestones-overview"],"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\nGroups §\n\np2p: Peer-to-peer\ntke: Token Engineering\ndst: Distributed Systems Testing\nacz: Applied Cryptography and Zero-knowledge\nsc: Smart Contracts\nzkvm: Zero-knowledge Virtual Machine\ndr: Deep Research\nrfc: RFC Process and Maintenance\n\nWeekly Updates §\n\nweekly updates\n\n\n\nMilestones\n"},"roadmap/waku/milestone-waku-10-users":{"title":"Milestone: Waku Network supports 10k Users","links":[],"tags":[],"content":"%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Scaling\n\t\t10k Users :done, 2023-01-20, 2023-07-31\n\nCompletion Deliverable §\nTBD\nEpics §\n\nGithub Issue Tracker\n"},"roadmap/waku/milestones-overview":{"title":"Waku Milestones Overview","links":["roadmap/waku/milestone-waku-10-users"],"tags":[],"content":"\n90% - Waku Network support for 10k users\n80% - Waku Network support for 1MM users\n65% - Restricted-run (light node) protocols are production ready\n60% - Peer management strategy for relay and light nodes are defined and implemented\n10% - Quality processes are implemented for nwaku and go-waku\n80% - Define and track network and community metrics for continuous monitoring improvement\n20% - Executed an array of community growth activity (8 hackathons, workshops, and bounties)\n15% - Dogfooding of RLN by platforms has started\n06% - First protocol to incentivize operators has been defined\n"},"roadmap/waku/overview":{"title":"Waku Roadmap","links":["roadmap/waku/milestones-overview","tags/waku-updates"],"tags":["waku-roadmap","overview"],"content":"Welcome to the Waku Roadmap Overview\n\nMilestones\nweekly updates\n"},"roadmap/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"},"roadmap/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"},"roadmap/codex/updates/2023-07-21":{"title":"2023-07-21 Codex weekly","links":["tags/479","tags/166"],"tags":["codex-updates","479","166"],"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\n1500.pdf\npcs-multiproofs.html\n1544.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 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 - 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 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 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 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\ndata-availability-sampling\n\n\ndas-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\ndas-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 - 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"},"roadmap/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 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 - edit\n\nInitial analysis of block discovery - 1067876\nInitial block discovery simulator - block-discovery-sim\n\n\n\nMilestone: Distributed Client Testing §\n\nLots of work around log collection/analysis and monitoring\n\nDetails here 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 - 483\n\n\n\nMilestone: Reservations and slot management §\n\nLots of work around slot reservation and queuing 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"},"roadmap/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 - 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 - _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 41\nMore related issues/PRs:\n\n20\n20\n\n\n\n\nTesting and debugging Condex in continuous testing environment\n\nDebugging continuous tests 44\npod labeling 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 - 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 - py-dht.\n\nNOTE: Several people are/where out during the last few weeks, so some milestones are paused until they are back"},"roadmap/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:\nwaku-objects-playground.vercel.app\nLink to Payggy design files:\n64ae9e965652632169060c7d\nMain development repo:\nwaku-objects-playground\nContact:\nYou can find us at 1118949151225413872 or join our discord at 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: waku-objects-playground\n\n"},"roadmap/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:\nwaku-objects-playground.vercel.app\nMain development repo:\nwaku-objects-playground\nGrayscale design:\ngrayscale.design\nLuminance package on npm:\nluminance\nContact:\nYou can find us at 1118949151225413872 or join our discord at 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 status-js-api Also I also found the 56/STATUS-COMMUNITIES 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 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: js Which also does not have documentation I assume that package is built from this: 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"},"roadmap/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:\nwww.wakuplay.im\nMain development repo:\nwaku-objects-playground\nContact:\nYou can find us at 1118949151225413872 or join our discord at eaYVgSUG"},"roadmap/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 (carnot_simulation_psuedocode.py)\nTest pseudocode (test_carnot_simulation.py)\nDescription of the simulation (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 (262)\nVote tally fix (268)\nIncreased run duration of integration tests (263)\nWarding improvements (269)\n\n\n"},"roadmap/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: 278, 279, 280, 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 (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"},"roadmap/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: 273#issuecomment-1661386628)\nDiscussions about how to manage the mixnet topology.\n(Link: 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: 288)\nAdded support for libp2p in tests.\n(Link: 287)\nAdded support for libp2p in nomos node.\n(Link: 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: 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: 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: 282)\n(Link: 289)\n(Link: 293)\n(Link: 295)\nRan simulations with 10K nodes.\nUpdated integration tests in CI to use waku or libp2p network.\n(Link: 290)\nFix for the node throughput during simulations.\n(Link: 295)\n"},"roadmap/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 [Mixnet-Architecture-613f53cf11a245098c50af6b191d31d2]\n\nDevelopment §\n\nMixnet PoC implementation starting [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 [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 2D-Reed-Solomon-Encoding-KZG-Commitments-benchmarking-b8340382ecc741c4a16b8a0c4a114450\nStudy documentation on Danksharding and set of questions for Leonardo [2D-Reed-Solomon-Encoding-KZG-Commitments-benchmarking-b8340382ecc741c4a16b8a0c4a114450]\n\n\nTesting, CI and Simulation App §\nDevelopment §\n\nSim fixes/improvements [299], [298], [295]\nSimulation app and instructions shared [300], [291], [294]\nCI: Updated and merged [290]\nParallel node init for improved simulation run times [300]\nImplemented branch overlay for simulating 100K+ nodes [291]\nSequential builds for nomos node features updated in CI [290]\n"},"roadmap/vac/acz/overview":{"title":"Applied Cryptography and Zero-knowledge Service Unit","links":["roadmap/vac/acz/rlnp2p/waku/production-readiness","roadmap/vac/acz/rlnp2p/waku/rln-relay-enhancements","roadmap/vac/acz/rlnp2p/waku/rln-membership-management","roadmap/vac/acz/zerokit/zerokit-v0.4"],"tags":["acz","vac"],"content":"vac:acz §\n\nrlnp2p:: §\n\n waku:production-readiness\n\ndue: 2023/07/31\nstatus: 100%\nmore info\n\n\nwaku:rln-relay-enhancements\n\ndue: 2023/09/30\nstatus: 50%\nmore info\n\n\nwaku:rln-membership-management\n\ndue: 2023/09/30\nstatus: 10%\nmore info\n\n\n\nzerokit:: §\n\nvac:zerokit-v0.4\n\ndue: 2023/09/07\nstatus: 0%\nmore details\n\n\nvac:maintenance\n\ndue: ongoing\nstatus: ongoing\n\n\n"},"roadmap/vac/dr/overview":{"title":"Deep Research Service Unit","links":[],"tags":["dr","vac"],"content":"vac:dr §"},"roadmap/vac/dst/overview":{"title":"Distributed Systems Testing Service Unit","links":[],"tags":["dst","vac"],"content":"vac:dst: §\n\nwakurtosis:: §\n\n waku:techreport\nwaku:techreport_02\nwaku:gossipsub-topology-analysis\nwaku:wakurtosis:features\nvac:rlog\nnomos:ci-integration\nnomos:ci-integration_02\nvac:maintenance\n\nanalysis::nomos:nomos-simulation-analysis §\ngsub-model:: §\n\nvac:refactoring\nstatus:control-messages\n\nshadow:: §\n\nvac:shadow-gossipsub-analysis\nwaku:shadow-waku-relay-analysis\n\n10ksim:: §\n\nvac:10ksim-bandwidth-test\nvac:10ksim-QoS\nvac:10ksim-waku-protocols\n\neng::vac:bundle-simulation-data §\nsoftware-testing:: §\n\nwaku:test-plans\nwaku:test-automation-js-waku\nwaku:test-automation-nwaku\nwaku:test-automation-go-waku\nwaku:test-automation-iterop-testing\n"},"roadmap/vac/p2p/overview":{"title":"P2P Service Unit","links":[],"tags":["p2p","vac"],"content":"vac:p2p: §\n\nnimlibp2p::vac:gossipsub-improvements-eip-4844 §\n\ndue: 2023/07/31\nstatus: 100%\n\nnimlibp2p::vac:webrtc-transport §\n\ndue: 2023/07/31\nstatus: 70%\n\nnimlibp2p::vac:maintenance §\n\nrepo: nim-libp2p\n\nnimchronos::vac:maintenance §\n\nrepo: nim-chronos\n"},"roadmap/vac/rfc/overview":{"title":"RFC Specifications Service Unit","links":[],"tags":["rfc","vac"],"content":"vac:rfc §"},"roadmap/vac/sc/overview":{"title":"Smart Contracts Service Unit","links":["roadmap/vac/sc/status/staking-contract","roadmap/vac/sc/status/staking-contract-02","roadmap/vac/sc/status/staking-contract-maintenance","roadmap/vac/sc/status/governance","roadmap/vac/sc/vac/rln-contract-support"],"tags":["sc","vac"],"content":"vac:sc:: §\n\nstatus: §\n\n snt-staking-contract\n\ndue: 2023/08/31\nstatus: 100%\nmore details\n\n\nsnt-staking-contract_02\n\ndue:\nstatus:\nmore details\n\n\nsnt-staking-contract-maintenance\n\ndue:\nstatus:\nmore details\n\n\ngovernance\n\ndue:\nstatus:\nmore details\n\n\n community-contracts-ERC721\n\ndue: 2023/08/31\nstatus: 100%\n\n\ncommunity-contracts-maintenance\n\ndue:\nstatus:\n\n\ncommunity-contracts-ERC20\n\ndue:\nstatus:\n\n\n\nvac: §\n\nsecureum-upskilling\n\ndue: 2023/10/15\nstatus: TBDd\n\n\nrln-contract-support\n\ndue: 2023/09/15\nstatus: 10%\nmore details\n\n\n"},"roadmap/vac/tke/overview":{"title":"Token Engineering Service Unit","links":["roadmap/vac/tke/status/snt-litepaper","roadmap/vac/tke/status/snt-staking","roadmap/vac/tke/codex/economic-analysis"],"tags":["p2p","vac"],"content":"vac:tke:: §\n\nstatus:SNT-litepaper §\n\ndue: 2023/07/31\nstatus: 70% - delayed: other milestones taking precedence\nmore details\n\nstatus:SNT-governance-proposal §\n\ndue: TBD\nstatus: NA - taking precedence over SNT-litepaper\nCC: Matty\n\nstatus:SNT-staking §\n\ndue: 2023/08/30\nstatus: 82%\nmore details\n\ncodex:economic-analysis §\n\ndue: 2023/08/30\nstatus: 50%\nmore details\n\nnomox:economic-analysis §\n\ndue: 2023/10/31\nstatus: 30%\nCC: Frederico\n"},"roadmap/vac/updates/2023-07-10":{"title":"2023-07-10 Vac Weekly","links":[],"tags":["vac-updates"],"content":"\nvc::Deep Research\n\nrefined deep research roadmaps 190, 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 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 - rln-contract\nfixed homebrew issue that prevented zerokit from building - 8a365f0c9e5c4a744f70c5dd4904ce8d8f926c34\nrln-relay: verify proofs based upon bandwidth usage - 3fe4522a7e9e48a3196c10973975d924269d872a\nRLN contract audit cont’ B195lgIth\n\n\n"},"roadmap/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 (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"},"roadmap/vac/updates/2023-07-24":{"title":"2023-08-03 Vac weekly","links":["tags/139"],"tags":["vac-updates","139"],"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 ( 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 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: 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 (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 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” (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 (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"},"roadmap/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 (934) & Limit flood publishing (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 (142, DST-Analysis)\nhiring\n\n\nmilestone (99%, 2023/07/31) Wakurtosis Waku Report\n\nRe-run simulations\nmerge Discv5 PR (129).\nfinalize Wakurtosis Tech Report v2\n\n\nmilestone (100%, 2023/07/31) Nomos CI testing\n\ndelivered first version of Nomos CI integration (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: 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 ark-circom\nachievment :: publish zerokit_utils zerokit_utils\nachievment :: publish rln 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 - rln-contract and waku-rln-contract\nDeployed to sepolia\nFixed rln enabled docker image building in nwaku - 1853\n\n\nzerokit:\n\nachievement :: zerokit v0.3.0 release done - v0.3.0 (𝕏 jointly with zkVM)\n\n\n\n\n"},"roadmap/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):\nVac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac week 32 August 7th\n\nvsu::P2P\n\nvac:p2p:nim-libp2p:vac:maintenance\n\nImprove gossipsub DDoS resistance 920\n\n\nvac:p2p:nim-chronos:vac:maintenance\n\nRemove hard-coded ports from test 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 (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 (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 ( SuperNova-research-document-8deab397f8fe413fa3a1ef3aa5669f37 )\nresearched starky\n80% Halo2 notes ( 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 - 3\nmark duplicated messages as spam - 1867\nuse waku-org/waku-rln-contract as a submodule in nwaku - 1884\n\n\nvac:acz:zerokit:vac:maintenance\n\nFixed atomic_operation ffi edge case error - 195\ndocs cleanup - 196\nfixed version tags - 194\nreleased zerokit v0.3.1 - 198\nmarked all functions as virtual in rln-contract for inheritors - a092b934a6293203abbd4b9e3412db23ff59877e\nmake nwaku use zerokit v0.3.1 - 1886\nrlnp2p implementers draft - rln-impl-w-waku\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nzerokit v0.4.0 release planning - 197\n\n\n\n\nvc::Deep Research\n\nvac:dr:valpriv:vac:tor-push-poc\n\nredesigned the torpush integration in nimbus 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"},"roadmap/vac/updates/2023-08-14":{"title":"2023-08-17 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac Milestones: Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac week 33 August 14th §\n\nvsu::P2P §\nvac:p2p:nim-libp2p:vac:maintenance §\n\nImprove gossipsub DDoS resistance 920\ndelivered: Perf protocol 925\ndelivered: Test-plans for the perf protocol perf-nim\nBandwidth estimate as a parameter (waiting for final review) 941\n\nvac:p2p:nim-chronos:vac:maintenance §\n\ndelivered: Remove hard-coded ports from test 429\ndelivered: fixed flaky test using REUSE_PORT 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 (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 eip-1967\nC3 Linearization 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: foundry-template\n\n\n\n\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:zerokit:vac:maintenance\n\nPR reviews 200, 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 1106 and Protostar 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"},"roadmap/vac/updates/2023-08-21":{"title":"2023-08-21 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac Milestones: Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac Github Repos: 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) 262\nWebRTC: Merge all protocols (60%: slowed down by some complications and bad planning with Mbed-TLS) 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 (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 - 1852\nfixed ganache’s change in method to manage subprocesses, fixed timeouts related to it - 1913\nshould error out on rln-relay mount failure - 1904\nfixed invalid start index being used in rln-relay - 1915\nconstrain the values that can be used as idCommitments in the rln-contract - 26\nassist with waku-simulator testing\nremove registration capabilities from nwaku, it should be done out of band - 1916\nadd deployedBlockNumber to the rln-contract for ease of fetching events from the client - 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 - 206\nuse pmtree instead of vacp2p_pmtree now that changes have been upstreamed - 203\nPrepared a PR to fix a stopgap introduces by PR 201 207\nPR review 202, 206\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nsubstitute id_commitments for rate_commitments and update tests in rln-v2 - 205\nrln-v2 working branch - 204\nmisc research while ooo:\nstealth commitment scheme inspired by erc-5564 - erc-5564-bn254, associated circuit - 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 (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 (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"},"roadmap/vac/updates/2023-08-28":{"title":"2023-08-28 Vac weekly","links":[],"tags":["vac-updates"],"content":"Vac week 35 §\n\nVac Milestones: Vac-Roadmap-907df7eeac464143b00c6f49a20bb632\nVac Github Repos: 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) 887\nImprove gossipsub DDoS resistance (98%) 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 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: 11954#issuecomment-1694591812\nupdating ERC2470 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 : 1925, 1928, 1931\n\n\nvac:acz:rlnp2p:waku:rln-relay-enhancments\n\ntree metadata should include chainId and contractAddress - 1932\nset flush_interval appropriately -1933\nintegrate new WakuRlnRegistry contract - 1943\nbump zerokit to v0.3.2 1951\ntree metadata should include window of roots - 1953\nsync tree state from contract deployed block number - 1955\noptimization to waku_keystore - 1956\nfixed a forceProgression bug in the WakuRlnRegistry contract - 6\n\n\nvac:acz:zerokit:vac:maintenance\n\nprevent tree db from being recreated if it exists - 209\nreleased zerokit v0.3.2 - v0.3.2\nmerged PR to fix a stopgap introduced by PR 201 207\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nPrepared a PR to deal with message_id range check 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 zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#01301b98f3af4157b932112ed998cff2\nWrite notes on Protostar\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nminor fixes plonky2 PR 5\nREADME’s to make zk-explorations repo public 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 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\n610\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"},"roadmap/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\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) 887\nImprove gossipsub DDoS resistance (98%) 920\n\n\n\nvsu::Tokenomics §\n\nvac:tke::codex:economic-analysis\n\nPresenting Filecoin findings to Codex team\nLitepaper: assumptions on collateral\n\n\nvac:tke::status: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\nvac:tke::nomos:economic-analysis\n\nDelegated staking specifications w/Marcin, update for privacy constraints\nBribery attacks analysis, Moh asked to followup early/mid Sep\n\n\nvac:tke::waku:economic-analysis\n\nFormalized RLN thoughts shared w/ Aaryamann, will push for additional feedback once Martin returns\n\n\n\nvsu::Distributed Systems Testing (DST) §\n\nvac:dst:analysis: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\nvac:dst:wakurtosis:vac:retrospective-rlog\n\nGather info and wrote summary of why we decided to stop using Kurtosis.\n\n\nvac:dst:10ksim:vac:10ksim-bandwidth-test\n\nCode diagrams + structurization\nChats with Ben (Codex)\n\n\nvac:dst:wakurtosis: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\nvac:dst:software-testing:waku:test-plans\n\nAdded test plans for filter, lightpush and store: Test-Plans-09c8c7b7f6784c459fb774792665e37c\n\n\nvac:dst:software-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\nvsu:Smart Contracts (SC) §\n\nvac:sc::vac:secureum-upskilling\n\nNo progress; busy with CommunityTokenDeployer contract\n\n\nvac:sc::status: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\nvac:sc::status: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\nvac:sc::status: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\nvsu:Applied Cryptogarphy & ZK (ACZ) §\n\nvac:acz:rlnp2p:waku:membership-management\n\nfixed makefile target for rln-keystore-generator - 1960\nlog the membership index out upon registration in the rln-keystore-generator - 1963\n\n\nvac:acz:rlnp2p:waku:rln-relay-enhancments\n\nrln was enabled by default in the Makefile - fixed - 1964\nordered pubsub validator execution - 1966\nfixed deserialization of valid merkle roots - 1973\nconfirm that the fetched credential from the keystore is registered to the membership set - 1980\nfixed makefile target for zerokit’s librln.a - 1981\nconverted zero-based indexing to 1-based indexing on vacp2p/rln-contract - 28\ndownstreamed zero-based indexing to waku-org/waku-rln-contract - 8 -\ndeployed new version of the registry contract on sepolia - 0xc04937d502E0ae671cedFC2A0BCD6692055520f3\n\n\nvac:acz:zerokit:vac:zerokit-v0.4\n\nMerged a PR to deal with message_id range check 210\nresearched tree_size issue for the 0.4 release\nresearched idCommitment/rateCommitment issue for the 0.4 release\n\n\n\nvip::zkVM §\n\nvac:zkvm::vac:research-existing-proof-systems\n\n[blog post] (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 (zkVM-cd358fe429b14fa2ab38ca42835a8451?pvs=4#cce2cc365a384126b2a5041900bd3ce9)\nContinued Lasso research (introducing-lasso-and-jolt)\nNotes for Protogalaxy; 100%\nNotes for Protostar\n\n\nvac:zkvm::vac:proof-system-benchmarks\n\nAdded an introductory section for Benchmark in zk-explorations repo: 10\n\n\n\nvc::Deep Research §\n\nvac:dr:gsub-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\nvac:dr:valpriv:vac:tor-push-poc\n\nDebugged various appraoches(tcp, gossip, tor). Triaged why attestations not working\n\n\nvac:dr:valpriv:vac:tor-push-relwork\n\ncompleted related work all\n\n\nvac:dr:consensus:nomos:carnot-paper\n\nPublishing the Carnot paper (Done) 2308.16016.pdf\nBegin work on writing up Carnot’s specification in RFC format\n\n\nvac:dr:consensus:nomos:carnot-bribery-article\n\nFinishing (describing research directions and their pros and cons, polishing the article) and publishing the article (Done) WIP-Bribery-Attacks-in-Consensus-Protocols-Challenges-and-Solutions-e4e108c17dba421abe83de49076c8f25\n\n\nvac:dr:consensus: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\nvc::RFC §\n\nvac:rfc:rfc:status: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"},"roadmap/vac/zkvm/overview":{"title":"Zero-knowledge Virtual Machine Incubation Project","links":[],"tags":["zkvm","vac"],"content":"vac:zkvm §"},"roadmap/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"},"roadmap/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"},"roadmap/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 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 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 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 persistance 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\nincorporating 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"},"roadmap/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 1894\nSetting up a staging fleet for Status to try static sharding\nRunning simulations for Store protocol: 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 (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"},"roadmap/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 responsable 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"},"roadmap/vac/acz/zerokit/zerokit-v0.4":{"title":"Zerokit v0.4 Release Details","links":["tags/197"],"tags":["197"],"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: 0%\n\nDescription §\n\nRelease Planning - Github Issue #197\n"},"roadmap/vac/sc/status/governance":{"title":"Status Governance Contract Details","links":[],"tags":[],"content":"\ndue date: 2023\nstatus: TBD\n\nDescription §"},"roadmap/vac/sc/status/staking-contract-02":{"title":"Status Staking Contract - next - Details","links":[],"tags":[],"content":"vac:sc::status:staking-contract_02 §\n\n\ndue date: TBD\nstatus: TBD\n\nDescription §\nTBD"},"roadmap/vac/sc/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"},"roadmap/vac/sc/status/staking-contract":{"title":"Status Staking Contract","links":[],"tags":[],"content":"vac:sc::status:staking-contract §\n\n%%{ \n init: { \n 'theme': 'base', \n '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"},"roadmap/vac/sc/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"},"roadmap/vac/tke/codex/economic-analysis":{"title":"Codex Economic Analysis Details","links":[],"tags":[],"content":"vac:tke::codex:economic-analysis §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Codex\n\t\tEconomic Analysis :, 2023-01-20, 2023-08-30\n\n\ndue: 2023/08/30\nstatus: 50%\nCC: Matty\n\nDescription §\nCodex economic analysis, Codex token utility, Codex collateral management"},"roadmap/vac/tke/nomos/economic-analysis":{"title":"Nomos Economic Analysis Details","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-01-20, 2023-10-31\n\n\ndue: 2023/10/31\nstatus: 30%\nCC: Frederico\n\nDescription §\nNomos economic analysis, Nomos token utility, requirements and constraints"},"roadmap/vac/tke/status/snt-governance-proposal":{"title":"SNT Governance Proposal","links":[],"tags":[],"content":"vac:tke::status:SNT-governance-proposal §\n\ndue: TBD\nstatus: TDB\nCC: Matty"},"roadmap/vac/tke/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 Llitepaper :, 2023-01-20, 2023-08-30\n\n\nCompletion: TBD\nCC: Matty\n"},"roadmap/vac/tke/status/snt-staking":{"title":"SNT Staking Details","links":["roadmap/vac/sc/overview"],"tags":[],"content":"vac:tke::status:SNT-staking §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection Status\n\t\tSNT Staking :, 2023-01-20, 2023-08-30\n\n\ndue: 2023/08/30\nstatus: 82%\nCC: Frederico (Python), Martin\ncollab: smart contracts team\n\nDescription: §\nTBD"},"roadmap/vac/tke/waku/economic-analysis":{"title":"Waku Economic Analysis Details","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-01-20, 2023-11-30\n\n\ndue: 2023/10/31\nstatus: 10%\nCC: Martin\n\nDescription §\nWaku economic analysis, Nomos token utility, requirements and constraints"},"roadmap/vac/acz/rlnp2p/waku/production-readiness":{"title":"RLNP2P Waku Pruduction Readiness Details","links":[],"tags":[],"content":"vac:acz:rlnp2p::waku:production-readiness §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tProduction Readiness :done, 2023-01-20, 2023-07-31\n\n\ndue: 2023/07/31\nstatus: 100%\n\nDescription §\nmembership management is out of scope for this milestone\nDeliverables §\nTBD"},"roadmap/vac/acz/rlnp2p/waku/rln-membership-management":{"title":"Waku RLN Membership Management Details","links":["roadmap/waku/overview"],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-membership-management §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN Membership Management :, 2023-01-20, 2023-09-30\n\n\ndue: 2023/09/30\nstatus: 10%\n\nDescription §\nEnhancing the first simple CC membership list\nRisks §\n\ndepends on input from Waku\n\n"},"roadmap/vac/acz/rlnp2p/waku/rln-relay-enhancements":{"title":"Waku RLN-RELAY Enhancements Details","links":[],"tags":[],"content":"vac:acz:rlnp2p::waku:rln-relay-enhancements §\n\n%%{ \n init: { \n 'theme': 'base', \n 'themeVariables': { \n 'primaryColor': '#BB2528', \n 'primaryTextColor': '#fff', \n 'primaryBorderColor': '#7C0000', \n 'lineColor': '#F8B229', \n 'secondaryColor': '#006100', \n 'tertiaryColor': '#fff' \n } \n } \n}%%\ngantt\n\tdateFormat YYYY-MM-DD \n\tsection rlnp2p-waku\n\t\tRLN-RELAY enhancements :, 2023-01-20, 2023-09-30\n\n\ndue: 2023/09/30\nstatus: 50%\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\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\n"}} \ No newline at end of file diff --git a/tags/index.html b/tags/index.html index bb5f77761..1f4ec66fc 100644 --- a/tags/index.html +++ b/tags/index.html @@ -1,5 +1,5 @@ -Tag: #index

    Logos Collective Project Roadmaps

    Search

    SearchSearch

    Tag: #index

    Found 23 total tags.

    #waku-roadmap

    1 items with this tag.

    #479

    1 items with this tag.

    #166

    1 items with this tag.

    #team-updates

    1 items with this tag.

    #dr

    1 items with this tag.

    #dst

    1 items with this tag.

    #p2p

    2 items with this tag.

    #rfc

    1 items with this tag.

    #sc

    1 items with this tag.

    #139

    1 items with this tag.

    #197

    1 items with this tag.

    Logos Collective Project Roadmaps

    Search

    SearchSearch

    Tag: #index

    Found 23 total tags.

    #waku-roadmap

    1 items with this tag.

    #479

    1 items with this tag.

    #166

    1 items with this tag.

    #team-updates

    1 items with this tag.

    #dr

    1 items with this tag.

    #dst

    1 items with this tag.

    #p2p

    2 items with this tag.

    #rfc

    1 items with this tag.

    #sc

    1 items with this tag.

    #139

    1 items with this tag.

    #197

    1 items with this tag.