<li>Set up a calculation for the probability of anonymity (communication) failure in the mix network of a large size, sampled from a large population of nodes, such that mix network size is comparable with the node population size. The latter is the most challenging regime to analyse but potentially can give us much more accurate estimates of probabilities. Previously we have analysed regimes when mix network size is much smaller than network size and when all nodes in the network are also used in the mix network.</li>
<li>Notes on “Anonymity Trilemma: Strong Anonymity, Low Bandwidth Overhead, Low Latency - Choose Two” paper provided in the overleaf document. <ahref="https://www.overleaf.com/read/rybwvjftfrrg"class="external">https://www.overleaf.com/read/rybwvjftfrrg</a> ; The latter derives necessary conditions for anonymous communication in terms of latency, amount of noise messages and some measure of anonymity.</li>
<li>Mixnet development specifications: went through the Loopix paper again - writing the draft specs: <ahref="https://www.notion.so/WIP-Mixnet-Development-Specifications-807b624444a54a4b88afa1cc80e100c2"class="external">https://www.notion.so/WIP-Mixnet-Development-Specifications-807b624444a54a4b88afa1cc80e100c2</a> (covering the current Loopix-based implementation + Future work: cover traffic, multicasting (TBD), incentivization (TBD))</li>
<li>Save block contents to storage - <ahref="https://github.com/logos-co/nomos-node/pull/464"class="external">https://github.com/logos-co/nomos-node/pull/464</a></li>
<li>Refactoring for future content - <ahref="https://github.com/logos-co/nomos-node/pull/461"class="external">https://github.com/logos-co/nomos-node/pull/461</a></li>
<li>Services state watchers - added a first version so overwatch can await for other services signal that they are ready to work. First version using relay did not work (among other things, too complicated). Second version uses an aditional handle per service, it is morestraight forward. It may add more intricated relationship among services, and they cannot be handled/caught on runtime. Testing only for now.</li>
<li>Failing services status PR: <ahref="https://github.com/logos-co/Overwatch/pull/29"class="external">https://github.com/logos-co/Overwatch/pull/29</a></li>
<li>Working services status PR: <ahref="https://github.com/logos-co/Overwatch/pull/30"class="external">https://github.com/logos-co/Overwatch/pull/30</a></li>
<li>Human readable ser/deser for array based types: <ahref="https://github.com/logos-co/nomos-node/pull/468"class="external">https://github.com/logos-co/nomos-node/pull/468</a></li>
<li>Finished mixnodes in docker testnet: <ahref="https://github.com/logos-co/nomos-node/pull/467"class="external">https://github.com/logos-co/nomos-node/pull/467</a> - The testnet in docker compose is now merged and has a README. There are still room for improvement, like spawning some nodes sequentially (like in <ahref="https://github.com/logos-co/nomos-node/pull/425"class="external">https://github.com/logos-co/nomos-node/pull/425</a>), but this will be solved in added in a new PRs or solved by other node improvements.</li>
<li>Improvements for node config: <ahref="https://github.com/logos-co/nomos-node/pull/460"class="external">https://github.com/logos-co/nomos-node/pull/460</a>, <ahref="https://github.com/logos-co/nomos-node/pull/471"class="external">https://github.com/logos-co/nomos-node/pull/471</a> - These changes were required for spawning nodes in testnet, will be useful for our endusers too</li>
<li>Single-staking - reviewed and updated the design up to the construction section.</li>
<li>Multi-staking - all comments have been addressed, but new are coming.</li>
<li>Right now we are investigating a scenario where we are limiting the amount of validators in the Single-Staking case by diverging from the requirement of having multiples of validators by removing the economical incentives. In other words, we are considering to allow registering validators that have at least a threshold of stake (that is or is not capped) and a single (unitary) voting power. This way we are limiting the economical need for having multiple validators hosted by a single node, and at the same time limiting the network overhead of the single-staking design.</li>
<li>The “Delegation and Validation Rewards” document (WIP): <ahref="https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4"class="external">https://www.notion.so/Delegation-and-Validation-Rewards-d4af3f87a0b240739ff99b15af11cb3f?pvs=4</a></li>
<li>Incorporating notes in the architecture whitepapers. These readings are not as deeply technical as papers, but more about understanding the directions currently explored at the edge of blockchain architectures (namely rollups, modular architectures and intent-centric architectures).</li>
<li>Working on the problem of PPoS, one of the most critical points of focus right now, to have at least an understanding of the available options</li>
<li>Hyrax, Dory and Dark schemes were studied, comparisons here: <ahref="https://www.notion.so/Polynomial-Commitment-Schemes-59bf8f6fe39840babe819c5c0a9628fc"class="external">https://www.notion.so/Polynomial-Commitment-Schemes-59bf8f6fe39840babe819c5c0a9628fc</a> ; It was concluded that schemes with verifier time above logarithmic are not a good option for data availability.</li>
<li>FRI is a structure that should be used not for now, (at this stage especially, due to large proof size - higher than KZG), but can be used for quantum resistance in the future. Here are some sources that say this can be used in later stages (the reasons are the same as ours). - <ahref="https://scroll.io/blog/kzg#user-content-fn-6"class="external">https://scroll.io/blog/kzg#user-content-fn-6</a> and <ahref="https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Why-use-the-hash-of-the-KZG-instead-of-the-KZG-directly"class="external">https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Why-use-the-hash-of-the-KZG-instead-of-the-KZG-directly</a></li>
