mirror of https://github.com/logos-co/roadmap.git
56 lines
5.4 KiB
Markdown
56 lines
5.4 KiB
Markdown
|
---
|
||
|
title: 2024-01-08 Nomos weekly
|
||
|
tags:
|
||
|
- nomos-updates
|
||
|
date: 2024-01-08
|
||
|
lastmod: 2024-01-09
|
||
|
draft: false
|
||
|
description: Weekly update of Nomos
|
||
|
---
|
||
|
## `network privacy and mixnet`
|
||
|
|
||
|
### `research`
|
||
|
|
||
|
- The [Mixnet specification doc](https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#af141ade3e8147ec900cf3599953f4da) has been updated with new details after a discussion was help in terms of establishing connections in advance - Whenever a Mixnet topology is reconstructed, each mix node in the layer l establishes connections optimistically with all mix nodes in the layer L+1 , in order to reduce the latency of individual packet delivery - more details in the relevant comments in the linked Notion doc.
|
||
|
|
||
|
### `development`
|
||
|
|
||
|
- No updates
|
||
|
## `testnet`
|
||
|
|
||
|
### `development`
|
||
|
|
||
|
- Increased the storage limit in addition setting up firewall rules for the Nomos http ports - they are set in the same range for containers and host - more details [here](https://github.com/logos-co/nomos-node/pull/553).
|
||
|
- Opened TCP ports 18080-18083 for HTTP - more details [here](https://github.com/status-im/infra-misc/pull/222). Also opened some [additional ports](https://github.com/status-im/infra-misc/issues/221)
|
||
|
- Added missing configuration and fixed conflicting rules for ports: Limit number of committed blocks in info requests - more info [here](https://github.com/logos-co/nomos-node/pull/552); Receive blocks blobs in parallel - more info [here](https://github.com/logos-co/nomos-node/pull/554); Set and get blocks tip without filtering - more info [here](https://github.com/logos-co/nomos-node/pull/548).
|
||
|
- Optimized consensus related methods, the changes allow node to run without problems on a testnet: [CI](https://github.com/logos-co/nomos-node/pull/550) - more work in progress (in terms of DA specification)
|
||
|
|
||
|
## `private PoS`
|
||
|
|
||
|
### `research`
|
||
|
|
||
|
- After trying 6 attempts, we had a breakthrough in understanding variance of our learning process around the fixed point: this latest method shows very good agreement with simulation across the full parameter space that we tested - This sets up to answer some of the burning questions we have had for a while (How big should T be, how small should delta be, how fast does this converge).
|
||
|
- We came up with a good measure of "centrality of stake", this has allowed us to do much more informative simulations across the parameters that matter: More detailed update with plots in Notion: [2024-01-08 Progress](https://www.notion.so/Lottery-Function-65f5ed5522b64c36b625652023318d88?pvs=4#d0e8cab7dae5414a9af20b24db0b28cf)
|
||
|
- Analysis of total stake inference problem: the analytical framework, derived for the algorithm which uses Crypsinous lottery function stochastic process to estimate the total stake, was used to construct the simplest possible theory which describes expectation and variance of the total stake statistical estimator.
|
||
|
- Several approaches were tried, including mapping to the physical thermal relaxation process, but explained simulations but only for a limited scope of parameters.
|
||
|
- The latest approach, which uses large stake expansion, leads to simple theory with a small number of parameters which explains simulations quite well. More details [here](https://www.overleaf.com/read/fzbrxvkwwscq#f2907c).
|
||
|
- Large numbers of validators issue has been documented - something that Carnot doesn't solve implicitly - more details [here](https://www.notion.so/Large-Numbers-of-Validators-9d331b4b7a204e62881453ecb3976ff7).
|
||
|
|
||
|
|
||
|
## `data availability`
|
||
|
|
||
|
### `research`
|
||
|
|
||
|
- We have made a new design - the [2D Data Availability Structure](https://www.notion.so/2D-Data-Availability-Structure-a8ee0b9ffe404a4482ec4eb56d2b033d) based on a problem whether the execution zones perform the RS-encoding process correctly; it has been solved accordingly but it is costly due to the size of the data - more studies to come.
|
||
|
- The protocols we have examined and also designed so far were compared on relevant data. Detailed information can be viewed [here](https://www.notion.so/DA-Layer-Comparison-Table-5848811f0af042e2b24c10d3cea9b0a8). Additionally, the total data size can be accessed by entering the data size and number of nodes [here](https://docs.google.com/spreadsheets/d/1I2hk69hWLVXaATC5048tLcw2qUTjiZORIzL0y90PTLg/edit?pli=1#gid=0)
|
||
|
|
||
|
### `development`
|
||
|
|
||
|
- No updates
|
||
|
|
||
|
### `miscellaneous`
|
||
|
|
||
|
- Architecture whitepaper is being reviewedg.
|
||
|
- Shared sequencing - compiled notes on some of the implications, architectural designs, discussions, inspirations and more, in an article [here](https://www.notion.so/Shared-Sequencing-15ab39a1fab94d008c5011ef27cc0f5e).
|
||
|
- Notes on the MTR Declaration of Decentralization provided [here](https://www.notion.so/Filip-8b260c1bfddd43cc9cd1211478be53e8 [here](https://www.notion.so/Filip-8b260c1bfddd43cc9cd1211478be53e8)- It is in an interesting proof of value approach (mix of PoS on main chain with a sidechain Relay/CER for the PoW, merged every sidechain's 30 blocks), that they are utilizing, but I think that it has too many holes to fulfill - risks and attack vectors. Even though the ecosystem has been live for a couple of years, it never reached the heights they apparently planned. They focused too much on becoming "big" rather than building up from ground zero. However, the interesting design choice is their utilization of sidechains (more precisely their adaptors and connectors) in the attempt to connect to other ecosystems. The paper didn't provide too many details about it though.
|