Create 2024-08-12.md (#108)

2024-08-14 15:32:53 +02:00 · 2024-08-14 15:32:53 +02:00 · 714b58d2b8
parent 67bd70cfd1
commit 714b58d2b8
1 changed files with 88 additions and 0 deletions
--- a/content/nomos/updates/2024-08-12.md
+++ b/content/nomos/updates/2024-08-12.md
@ -0,0 +1,88 @@
+---
+title: 2024-08-12 Nomos weekly
+tags:
+  - nomos-updates
+date: 2024-08-12
+lastmod: 2024-08-12
+draft: false
+description: Weekly update of Nomos
+project tracking: https://www.notion.so/Project-Tracking-4fb69250b0114573a71c57882165eec3
+---
+## `P2P Privacy`
+
+### `Research`
+
+- Improved the simulation to avoid out-of-memory (OOM) issues—an unexpected bug. If we run heavy simulations with 90+ processes on the server, the total usage of system memory is very high, and OOM occurs after 10+ hours. We modified the handling of intermediate results to minimize memory usage.
+- Measuring the Message Dissemination Time by Queue Type (Session 2.1) - because the session 2.1 simulations are too slow, we are profiling the internal behaviour of the simulation to find if something is wrong. So far, everything looks fine. The amount of computations looks correct. But, there are still more things that we need to check at the moment.
+- Working on reducing the time complexity of the experiments from the parameters perspective and prepared reduced parameters for session 2, called 2.1. Afterwards, designed Session 3, and Session 4 for evaluating the behavior of a node with non-homogeneous peering degree. Finally, defined experiment 5 which should deprecate all previous experiments as it simulates most closely the behavior of the network. Relevant [document](https://www.notion.so/Nomos-Mix-Queueing-Mechanism-Experimentation-Methodology-d629af5a2d43473c9ec9ba191f6d904d?pvs=4#39be9cf2ed08456da855b373bed71db8).
+- Designed a responsive version (two flavors) of the queuing mechanism, that alters the probability of releasing the message from the queue when the same message is received from another queue by the node. This is a more elegant solution which should deprecate all others if performing well (delay and statistically wise). Relevant [document](https://www.notion.so/Nomos-Mix-Peer-to-Peer-Mix-Network-over-Gossip-Channel-11e9c70a656d4ff1858bc46a715f4c59?pvs=4#b37a8fdcfafe49d2880c06c3a09e6882).
+- Started drafting some high-level requirements for the pay-per-mix design. Heavy work in progress - relevant [document](https://www.notion.so/Nomos-Mix-Peer-to-Peer-Mix-Network-over-Gossip-Channel-11e9c70a656d4ff1858bc46a715f4c59?pvs=4#dee3a11560834b689f41447c678ad2e6).
+- Analysis of the queuing system in the Nomos Mixnet node: continued with the analysis of the FIFO (First In First Out) attack where two sender nodes, observed by an adversary, send messages through kkk mix nodes to the receiver node, corrupted by the adversary. Considered a scenario when a message is delayed by the sender node by 1qS\frac{1}{q_S}qS1 (on average) and by the mix node by 1qM\frac{1}{q_M}qM1 (on average). Here qSq_SqS and qMq_MqM are, respectively, probabilities of removing a message from the out-queue of sender and mix nodes. Computed the probability of success of the FIFO attack for different ratios ρ=qSqM\rho = \frac{q_S}{q_M}ρ=qMqS. The probability of success of the FIFO attack approaches the lower bound 12\frac{1}{2}21, where the adversary doesn’t have any advantage over random guessing, with an increasing number of mix nodes kkk much faster for higher values of ρ\rhoρ. However, even for higher values of ρ\rhoρ the probability of success of the FIFO attack is increasing if the difference in latencies of connections, of two sender nodes to the first mix node, is greater than some threshold. This work is summarized in this [document](https://www.notion.so/Analysis-of-the-Nomos-Mixnet-Anonymous-Communication-AC-System-c97d73a7b8894cf7830e8345f0cc37a4?pvs=4#73b50a8df0364dee8754979e81f3b9ed).
+
+### `Development`
+
+- No updates this week.
+
+## `Data Availability`
+
+### `Research`
+
+- Updated the [DA Technical Specification](https://www.notion.so/DA-Technical-Specification-c6664294d630470ba20aefb21a218f8c?d=dc11993b05bd484da36a858ac83fdbd8#3529ba28472b40ce8ae14cfc8f7a6132).
+
+### `Development`
+
+- [PR #688](https://github.com/logos-co/nomos-node/pull/688) - Finished implementing/fixing the DA network dispersal layer: implemented executor behavior, implemented validator behavior and implemented interaction test for both behaviors.
+- (WIP) [PR #689](https://github.com/logos-co/nomos-node/pull/689) - Finished implementing/fixing the DA network sampling layer.
+- (WIP) [PR #690](https://github.com/logos-co/nomos-node/pull/690) - DA Mock network service for CLI app: all parts (services, adapters, etc.) are defined and interconnected, finishing up mock implementations. Progress is a bit slower than initially anticipated with the CLI App.
+
+## `PPoS/Consensus`
+
+### `Research`
+
+- [Concluded](https://www.notion.so/Previous-version-8b4de84c221e430fa0bd4e5393e5be7d?pvs=4#39161d9c6bce4c2ab5aee9e663aa782d) that Caulk is not that interesting for improving proof of membership.
+- Finalized the [section](https://www.notion.so/Does-Crypsinous-Leader-Election-Function-lead-to-wealth-concentration-in-PoS-b81f07a791b745438443f51f00ac258f#1df422f6cc204cb8b362f41cda260b8b) about "Follow the Protocol" on the wealth concentration work.
+- Dropped the analysis of the PoV based on PoL analysis.
+- PoV spec: The main motivation for implementing Caulk was its fast update process. We examined how many operations are required for Merkle-tree updates at specific depths and compared this with point addition and multiplication on the Caulk side. For Caulk, if the updates are to be made, this value is added linearly to the process, whereas this isn't necessary for Merkle-tree. It was observed that at 2122^{12}212 notes, the values are almost equal, and even at 2202^{20}220 notes, the difference isn't significant. For this reason, we agreed that itisn't necessary to spend too much time on Caulk. Additionally, for Caulk, the proof of Pedersen equivalence would also disadvantage us in terms of proof size and constraints. The spec work for PoV has been completed. [This](https://www.notion.so/Proof-of-Validator-Specification-5cd02f594d4d4a66be5e9f1ebf95d7d8) is the latest version using a Merkle tree.
+
+### `Development`
+
+- No updates this week.
+
+## `Coordination Layer`
+
+### `Research`
+
+- [PR #15](https://github.com/logos-co/nomos-pocs/pull/15) - Added strong zone notes validation by zone ID.
+- [PR #16](https://github.com/logos-co/nomos-pocs/pull/16) - Added metadata to zone notes to allow for correct funds/state note validation.
+- [PR #19](https://github.com/logos-co/nomos-pocs/pull/19) - Refactored zone auth.
+- [PR #20](https://github.com/logos-co/nomos-pocs/pull/22) and [PR #22](https://github.com/logos-co/nomos-pocs/pull/22) - Added support for atomic transactions.
+- Created a [table](https://www.notion.so/Possible-ZKVM-s-for-CL-Design-310996a4924149b986f28ed7d387a363) for notable zkVMs in the literature, currently filling in the details by reviewing the designs.
+- Added the necessary details and definitions for ZCash in the relevant [document](https://www.notion.so/ZCash-Spec-Details-2c1f31a465dc44b884bfef20bfb1508f).
+- [PR #21](https://github.com/logos-co/nomos-pocs/pull/21) - Integrated the zone deposit scenario.
+- [PR #23](https://github.com/logos-co/nomos-pocs/pull/23) - User side of the atomic transfer transaction.
+- [PR #24](https://github.com/logos-co/nomos-pocs/pull/26) - Full atomic transfer transaction.
+- With the previous three PRs (in combination with previous work), we've got the full atomic transfer transaction working end-to-end! We still need to do some performance work to ensure executors can build a transaction within the 20s target block time (current proof time is ~400s).
+
+### `Development`
+
+- No updates this week.
+
+## `Testnet + Insights`
+
+### `Development`
+
+- No updates this week.
+
+## `User Tools`
+
+### `Research`
+
+- No updates this week.
+
+### `Development`
+
+- No updates this week.
+
+## `Miscellaneous`
+
+- No updates this week.