mirror of https://github.com/logos-co/roadmap.git
75 lines
5.1 KiB
Markdown
75 lines
5.1 KiB
Markdown
|
---
|
|||
|
|
title: 2024-05-06 Nomos weekly
|
|||
|
|
tags:
|
|||
|
|
- nomos-updates
|
|||
|
|
date: 2024-05-13
|
|||
|
|
lastmod: 2024-05-13
|
|||
|
|
draft: false
|
|||
|
|
description: Weekly update of Nomos
|
|||
|
|
---
|
|||
|
|
## `P2P Privacy`
|
|||
|
|
|
|||
|
|
### `Research`
|
|||
|
|
|
|||
|
|
- Clarified the adversary model further (WIP); we'll develop it more by simulation. Attacks to be simulated are listed [here](https://www.notion.so/Mixnet-v2-Proof-of-Concept-102d0563e75345a3a6f1c11791fbd746?pvs=4#6f964a5ac1144239a17ad5d3e648746d), and are based on the adversary model in the same document. The [related studies](https://www.notion.so/Mixnet-v2-Proof-of-Concept-102d0563e75345a3a6f1c11791fbd746?pvs=4#12f00f18441049a893687f011ee3c683) were referred to, including Waku's documentation about adversarial models (provided by the Waku team).
|
|||
|
|
- Analysis of anonymity and communication failures in the mix gadget: Assuming that _n_ nodes sample (with replacement) _k_ nodes from the population with _N_ nodes, where at most _M_ nodes are adversarial, the average number of _k_-paths with anonymity and communication failures are, respectively, given by n \left( \frac{M}{N} \right)^k and n \left(1 - \left(1 - \frac{M}{N}\right)^k\right). Calculated an upper bound on the probability that the number of _k_-paths with these failures are greater than their respective averages by the factor 1+𝛾1+γ, where 𝛾>0γ>0. compared the above bounds with simulations showing that they are tight. Analysis of different cases of 𝑀/𝑁={½,⅓,¼,1/10}M/N={½,⅓,¼,1/10} suggests that, for **reliability** purposes, some combinations of _n_ and _k_ could be more advantageous than others. The summary of this work is provided [here](https://www.notion.so/Analysis-of-the-mix-gadget-6246ab47a8e34ac0bc7b561d32680e34?pvs=4#e8c26a0e832c4f438f9a06ae2be209f0).
|
|||
|
|
- Started the investigation of the problem regarding mixing over a broadcasting channel, which is an interesting form of mixing in a sparse network. Using a broadcasting channel makes it impossible for an observer to learn who the recipient of the message is (assuming proper message relaying strategy). Making nodes indistinguishable requires a single cover traffic message per time slot, which is a step closer to ideal privacy. However, this has a great network overhead cost, which limits the scalability of the network significantly assuming a fixed bandwidth requirement per node. Also, made an observation about the impossibility of stake hiding, which is based on the fact that the network behavior of a node is reflected on the ledger and any disturbance of the node behavior must also be seen on the ledger. [Document](https://www.notion.so/Security-of-Mixing-over-Broadcasting-Channel-e09184fa14614d78829f76fdb4aa65d3#642beedb44674143ba25e5e21c23f860) for reference.
|
|||
|
|
|
|||
|
|
### `Development`
|
|||
|
|
|
|||
|
|
- Implemented the simulation of "basic" mixnet behaviors (Modified Sphinx, Cover traffic, Broadcasting). They're very naive but should be enough for running basic adversary simulations. The simulator is being implemented in the `mixnet-v2-sim` branch in the nomos-specs repository. Basic usage and development progress can be found in the [README](https://github.com/logos-co/nomos-specs/tree/mixnet-v2-sim/mixnet/v2/sim), though it's still heavily WIP. Sphinx size: If the payload size is 330 bytes (32 bytes block hash + 288 bytes validator proof) and an incentive tx is 512 bytes (which may not be enough), and if the number of mix layers is 3, a Sphinx packet is 1937 bytes (subject to change).
|
|||
|
|
|
|||
|
|
## `Data Availability`
|
|||
|
|
|
|||
|
|
### `Research`
|
|||
|
|
|
|||
|
|
- No updates this week.
|
|||
|
|
|
|||
|
|
### `Development`
|
|||
|
|
|
|||
|
|
- Did benchmarks on DA, lib performance was way below expected and targets. Debugged issues, what was found is that the most problematic is proof generation. Discussed options for improvements: Parallelization (which is not really possible as is internally parallelized already) and amortized proof generation method. Ruse evaluation + Benchmarks can be found [here](https://github.com/logos-co/nomos-node/pull/647).
|
|||
|
|
|
|||
|
|
## `PPoS/Consensus`
|
|||
|
|
|
|||
|
|
### `Research`
|
|||
|
|
|
|||
|
|
- [Wealth concentration update](https://www.notion.so/Does-Crypsinous-Leader-Election-Function-lead-to-wealth-concentration-in-PoS-b81f07a791b745438443f51f00ac258f): changes related to the introduction of the study structure, rearrangement based on new sections, and expanded/improved explanations.
|
|||
|
|
|
|||
|
|
### `Development`
|
|||
|
|
|
|||
|
|
- No updates this week.
|
|||
|
|
|
|||
|
|
## `Coordination Layer`
|
|||
|
|
|
|||
|
|
### `Research`
|
|||
|
|
|
|||
|
|
- Study on DA fast proof generation: research was conducted on fast proof generation in the DA domain. The Feist-Khovratovich technique was examined, and libraries implementing this method were investigated. The general structure of the method and the approach it attempts to implement are explained [here](https://www.notion.so/Feist-Khovratovic-Algorithm-b5d089d1c66c417db2ddd6dfc536ef76).
|
|||
|
|
- Wrote a potential design for [Mailboxes & Sovereign Transactions](https://www.notion.so/Coordination-Layer-Specification-9a60bd41167d426abb0cd07a01aab905?pvs=4#9af0ddc28dd84e3b90a5976a95cce90e).
|
|||
|
|
|
|||
|
|
### `Development`
|
|||
|
|
|
|||
|
|
- No updates this week.
|
|||
|
|
|
|||
|
|
## `Testnet + Insights`
|
|||
|
|
|
|||
|
|
### `Research`
|
|||
|
|
|
|||
|
|
- No updates this week.
|
|||
|
|
|
|||
|
|
### `Development`
|
|||
|
|
|
|||
|
|
- No updates this week.
|
|||
|
|
|
|||
|
|
## `User Tools`
|
|||
|
|
|
|||
|
|
### `Research`
|
|||
|
|
|
|||
|
|
- No updates this week.
|
|||
|
|
|
|||
|
|
### `Development`
|
|||
|
|
|
|||
|
|
- No updates this week.
|
|||
|
|
|
|||
|
|
## `Miscellaneous`
|
|||
|
|
|
|||
|
|
- No updates this week.
|