logos-co
/
roadmap
mirror of https://github.com/logos-co/roadmap.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

chore: Vac has moved to a separate repo deployed on roadmap.vac.dev

This commit is contained in:
ksr 2024-10-15 17:46:14 +02:00
parent c22aef5c39
commit ce1f370e69
No known key found for this signature in database
GPG Key ID: E4EB341A3BB26FA5
274 changed files with 0 additions and 16891 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/index.md
View File

@ -14,5 +14,3 @@ Every year (starting this year), each project defines its plans in a number a mi
- [Codex](codex/overview.md)
- [[nomos/index|Nomos]]
### Services
- [Vac](vac/index.md)

38
content/vac/acz/consulting/codex/proxy-re-encryption.md
View File

@ -1,38 +0,0 @@
## `vac:acz:consulting:codex:proxy-re-encryption`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Proxy Re-Encryption: , 2024-05-27, 2024-09-30
```
- status: 50%
- CC: Ramses + 1
### Description
To embed and assist codex with their proxy re-encryption primitive.
### Justification
Proxy re-encryption is necessary to provide plausible deniability to storage providers.
### Deliverables
- [x] A Document describing possible solutions: https://www.notion.so/Approaches-to-plausible-deniability-87c6fef92df946fcbc1327d51d936ce1?pvs=4
- [ ] Agreement and hardening of specification for the Codex team

40
content/vac/acz/consulting/nescience/zk-consulting.md
View File

@ -1,40 +0,0 @@
---
title: Nescience ZK Consulting
---
## `vac:acz:consulting:nes:zk-consulting`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Nescience ZK Consulting: , 2024-01-01, 2024-12-31
```
- status: 30%
- CC: Ugur
### Description
To assist the Nescience team with their ZK needs.
### Justification
Ugur has the expertise to assist Nescience with their zk research tracks.
### Deliverables

1
content/vac/acz/consulting/nomos/init.md
View File

@ -1 +0,0 @@
init cryptography consulting for nomos

57
content/vac/acz/index.md
View File

@ -1,57 +0,0 @@
---
title: Applied Cryptography and Zero-knowledge Service Unit
tags:
- acz
- vac
date: 2023-09-12
lastmod: 2024-07-04
---
## `vac:acz:`
---
### `rlnp2p:waku:`
* [x] [[vac/acz/rlnp2p/waku/production-readiness|production-readiness]]
* [x] [[vac/acz/rlnp2p/waku/rln-membership-management|rln-membership-management]]
* [x] [[vac/acz/rlnp2p/waku/rln-relay-enhancements|rln-relay-enhancements]]
* [x] [[vac/acz/rlnp2p/waku/rln-relay-enhancements_02|rln-relay-enhancements_02]]
* [[vac/acz/rlnp2p/waku/rln-relay-erc20|rln-relay-erc20]]
- [x] [[vac/acz/rlnp2p/waku/rlnv2-relay-integration|rlnv2-relay-integration]]
* [x] [[vac/acz/rlnp2p/waku/rln-multi-epoch-constraints|rln-multi-epoch-constraints]]
* [x] [[vac/acz/rlnp2p/waku/rlnv2-e2e|rlnv2-e2e]]
### `rlnp2p:vac:`
* [x] [[vac/acz/rlnp2p/vac/rln-doc-and-outreach|rln-doc-and-outreach]]
* [x] [[vac/acz/rlnp2p/vac/light-rln-verifiers|light-rln-verifiers]]
* [x] [[vac/acz/rlnp2p/vac/rln-light-clients|rln-light-clients]]
### `rlnp2p:status:`
* [ ] [[vac/acz/rlnp2p/status/rln-usage|rln-usage]]
### `zerokit:vac:`
* [x] [[vac/acz/zerokit/vac/zerokit-v0-4|zerokit-v0.4]]
* [x] [[vac/acz/zerokit/vac/zerokit-v0-5|zerokit-v0.5]]
* [ ] [[vac/acz/zerokit/vac/zerokit-v0-6|zerokit-v0.6]]
* [[vac/acz/zerokit/vac/maintenance|maintenance]]
### `secure-channels:waku:`
* [x] [[vac/acz/secure-channels/waku/mls-design|mls-design]]
* [x] [[vac/acz/secure-channels/waku/mls-poc|mls-poc]]
* [ ] [[vac/acz/secure-channels/waku/fd-design|fd-design]]
* [ ] [[vac/acz/secure-channels/waku/fd-poc|fd-poc]]
### `consulting:codex:`
* [ ] [[proxy-re-encryption|proxy-re-encryption]]
### `consulting:nomos:`
* [[vac/acz/consulting/nomos/init|init]]
### `consulting:nes:`
* [ ] [[vac/acz/consulting/nescience/zk-consulting|zk-consulting]]
### `stealth-address-kit:vac:`
* [ ] [[vac/acz/stealth-address-kit/maintenance|maintenance]]
* [ ] [[vac/acz/stealth-address-kit/research|research]]
### `validator-privacy:nimbus:`
- [ ] [[vac/acz/validator-privacy/nimbus/productionize-tor-push|productionize-tor-push]]

41
content/vac/acz/rlnp2p/status/rln-usage.md
View File

@ -1,41 +0,0 @@
---
title: Status RLN Usage
---
## `vac:acz:rlnp2p:status:rln-usage`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
RLN Usage: , 2024-05-13, 2024-06-13
```
- status: 0%
- CC: Aaryamann
### Description
To describe an end-to-end user flow for a new user of the status app on how they can acquire an RLN membership.
### Justification
Status will use RLN in the future, and we must first consult them on how to use it for seamless integration.
### Deliverables
- [ ] Document describing end-to-end user flow

45
content/vac/acz/rlnp2p/vac/light-rln-verifiers.md
View File

@ -1,45 +0,0 @@
---
title: Light RLN Verifiers
---
## `vac:acz:rlnp2p:vac:light-rln-verifiers`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Light RLN Verifiers: done, 2024-03-01, 2024-05-01
```
- status: 100%
- CC: Aaryamann
### Description
Make use of cryptography techniques to improve trust assumptions and reduce off-chain complexity while verifying RLN proofs.
### Justification
A node attempting to verify RLN proofs takes nearly ~10 minutes to sync all the leaves. We should explore cost-effective solutions to make the root of the tree accessible onchain.
### Deliverables
- [x] PoC using tiered commitment trees: https://github.com/vacp2p/rln-contract/pull/37
- [x] Deployed to sepolia and load tested: https://sepolia.etherscan.io/address/0xE7987c70B54Ff32f0D5CBbAA8c8Fc1cAf632b9A5
- [x] Ethresearch post: https://ethresear.ch/t/tiered-commitment-trees-to-reduce-gas-costs-and-offchain-complexity/19484
- [x] Vac forum post: https://forum.vac.dev/t/light-rln-verifiers-using-a-tiered-commitment-tree/290
- [x] Vac blog post: https://vac.dev/rlog/rln-light-verifiers/

52
content/vac/acz/rlnp2p/vac/rln-doc-and-outreach.md
View File

@ -1,52 +0,0 @@
---
title: "RLN Doc and Outreach"
---
## `vac:acz:rlnp2p:vac:rln-doc-and-outreach`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
RLN doc and outreach: done, 2023-08-01, 2024-12-31
```
- status: 100%
- CC: Aaryamann
### Description
* Waku doc: How can a user setup Waku + RLN?
- even though Waku RLN does not support slashing yet, we can see RLN as that provides an additional datapoint regarding message validity
* doc explaining how the components of RLN (zerokit, contract, and a project using it, e.g. Waku, work together)
- this can be in notion at first
* rlog post based on the two points above
* talk @ progcrypto and logos event in Istanbul (co-located with devconnect)
### Justification
### Deliverables
* [x] talk at progcrypto on RLN: https://www.youtube.com/watch?v=7xDxv8F70Jg&pp=ygUOcHJvZ2NyeXB0byBybG4%3D
* [x] presented rln: zero to hero to nwaku+chatsdk team @ status all hands, explained all versions of rln and their trade-offs
- [x] blog post/RFC on Light RLN verifiers: https://github.com/vacp2p/vac.dev/pull/136
- [x] updated docs for rln-relay in nwaku-compose: [https://github.com/waku-org/nwaku-compose/pull/52](https://github.com/waku-org/nwaku-compose/pull/52)
- [x] Present rln-v2 and v3 at logos research call: https://docs.google.com/presentation/d/1lcE5E3WKenueIULR_rhjtZU8Tdqv-7sPr6lpXPTaQSk/edit?usp=sharing
- [x] RLN rlog on vac.dev: https://vac.dev/rlog/rln-anonymous-dos-prevention

51
content/vac/acz/rlnp2p/vac/rln-light-clients.md
View File

@ -1,51 +0,0 @@
---
title: RLN Light Clients
---
## `vac:acz:rlnp2p:vac:rln-light-clients`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
RLN Light Clients: done, 2024-04-01, 2024-05-01
```
- status: 100%
- CC: Aaryamann
### Description
Make use of zk-kit's [LazyIMT](https://github.com/privacy-scaling-explorations/zk-kit/blob/12447adf0bca1f752b1bd6b7acf5b87e0cadccc6/packages/imt.sol/contracts/LazyIMT.sol)to have the merkle proof of a leaf accessible onchain, and the root as well, to allow for light rln provers and verifiers.
### Justification
A node attempting to verify RLN proofs takes nearly ~10 minutes to sync all the leaves. We should attempt to see if it is cheap *enough* to use the LazyIMT structure so that we can have the merkle proof accessible onchain.
### Deliverables
- [x] PoC (rln-v1): https://github.com/vacp2p/rln-contract/pull/31
- [x] Deployed to cardona zkevm testnet: https://cardona-zkevm.polygonscan.com/address/0x16abffcab50e8d1ff5c22b118be5c56f801dce54
- [x] PoC (rln-v2): https://github.com/vacp2p/rln-contract/pull/39
- [x] Downstreamed to waku-rln-contract to estimate gas: https://github.com/vacp2p/rln-contract/pull/38
| RLN Version | Gas estimate for insertion |
| ---------------- | -------------------------- |
| rln-v1 | 90k |
| rln-v1 (lazyIMT) | 130k |
| rln-v2 | 135k |
| rln-v2 (lazyIMT) | 210k |

33
content/vac/acz/rlnp2p/waku/production-readiness.md
View File

@ -1,33 +0,0 @@
---
title: "RLNP2P Waku Pruduction Readiness Details"
---
## `vac:acz:rlnp2p::waku:production-readiness`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
dateFormat YYYY-MM-DD
section Status
Production Readiness :done, 2023-01-20, 2023-07-31
```
- due: 2023/07/31
- status: 100%
### Description
membership management is out of scope for this milestone
### Deliverables
TBD

52
content/vac/acz/rlnp2p/waku/rln-membership-management.md
View File

@ -1,52 +0,0 @@
---
title: Waku RLN Membership Management Details
---
## `vac:acz:rlnp2p::waku:rln-membership-management`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
dateFormat YYYY-MM-DD
section Status
RLN Membership Management :done, 2023-01-20, 2023-09-30
```
- due: 2023/09/30
- status: 100%
### Description
Enhancing the first simple CC membership list
### Risks
- depends on input from [[waku/index|Waku]]
### Info
#### 2023/09/04 - 2023/09/11
* added documentation for rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1993
#### 2023/08/28 - 2023/09/04
* fixed makefile target for rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1960
* log the membership index out upon registration in the rln_keystore_generator - https://github.com/waku-org/nwaku/pull/1963
#### 2023/08/21 - 2023/08/28
* Demo of rln_keystore_generator: https://github.com/waku-org/nwaku/pull/1956
* Wrote a tool rln_keystore_generator
* https://github.com/waku-org/nwaku/pull/1925
* https://github.com/waku-org/nwaku/pull/1928
* https://github.com/waku-org/nwaku/pull/1931

51
content/vac/acz/rlnp2p/waku/rln-multi-epoch-constraints.md
View File

@ -1,51 +0,0 @@
---
title: "Multi Epoch Constraints"
---
## `vac:acz:rlnp2p:waku:multi-epoch-constraints`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Multi epoch constraints: 2023-09-15, 2023-11-15
```
- status: 90%
- CC:
- Ramses
- Aaryamann
### Description
Currently, RLN v1 allows for a fixed message rate of 1/msg per epoch while RLN v2 allows for n msgs/epoch.
The goal of this milestone is designing the key derivation and related cryptographic components for allowing several n msgs/epoch constraints.
For example: 24 msg / day && 1 msg/10 seconds.
* the nullifier defined in the [RLN RFC](https://rfc.vac.dev/spec/32/#slashing-and-shamirs-secret-sharing) has to be adapted accordingly.
### Justification
Dynamic epoch sizes are required for users who have smaller messaging needs, to optimize for stake used.
rln-v3 will allow that.
### Deliverables
* [x] design document: https://www.notion.so/rln-v3-PoC-b05af585f52f4b15a249184d4a627096
* [x] PoC: https://github.com/vacp2p/gnark-rln/blob/9b05eddc89901a06d8f41b093ce8ce12fd0bb4e0/rln/rln.go
* [ ] blog post/ethresearch crosspost

95
content/vac/acz/rlnp2p/waku/rln-relay-enhancements.md
View File

@ -1,95 +0,0 @@
---
title: Waku RLN-RELAY Enhancements Details
---
## `vac:acz:rlnp2p::waku:rln-relay-enhancements`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
dateFormat YYYY-MM-DD
section Status
RLN-RELAY enhancements :done, 2023-06-01, 2023-09-30
```
- due: 2023/09/30
- status: 100%
### Description
- simple membership management setup (fixed CC list)
- instruction on how to register to the membership set / setup up (for Waku CCs)
#### Goal
Run RLN relay on the Waku production fleet. Waku CCs can use it
### Info
## 2023/09/04 - 2023/09/11
* if only one key exists in the keystore, use it - https://github.com/waku-org/nwaku/pull/1984
* fix log levels for some logs - https://github.com/waku-org/nwaku/pull/1986
* updated documentation for rln-relay - https://github.com/waku-org/nwaku/pull/1993
* clean nullifier table every `MaxEpochGap` - https://github.com/waku-org/nwaku/pull/1994
* created `rln_db_inspector` tool, allows inspection into merkle tree structure - https://github.com/waku-org/nwaku/pull/1999, https://github.com/waku-org/nwaku/pull/2012
* fixed missing memberships between history sync and new memberships sync with @alrevuelta - https://github.com/waku-org/nwaku/pull/2015
* remove `rln` from waku's experimental features - https://github.com/waku-org/nwaku/pull/2001
* fix metric calculation for registered members - https://github.com/waku-org/nwaku/pull/2018
* uups proxy for waku-rln-registry - https://github.com/waku-org/waku-rln-contract/pull/9
## 2023/08/28 - 2023/09/04
* rln was enabled by default in the Makefile - fixed - https://github.com/waku-org/nwaku/pull/1964
* ordered pubsub validator execution - https://github.com/waku-org/nwaku/pull/1966
* fixed deserialization of valid merkle roots - https://github.com/waku-org/nwaku/pull/1973
* confirm that the fetched credential from the keystore is registered to the membership set - https://github.com/waku-org/nwaku/pull/1980
* fixed makefile target for zerokit's `librln.a` - https://github.com/waku-org/nwaku/pull/1981
* converted zero-based indexing to 1-based indexing on vacp2p/rln-contract - https://github.com/vacp2p/rln-contract/pull/28
* downstreamed zero-based indexing to waku-org/waku-rln-contract - https://github.com/waku-org/waku-rln-contract/pull/8 -
* deployed new version of the registry contract on sepolia - `0xc04937d502E0ae671cedFC2A0BCD6692055520f3`
#### 2023/08/21 - 2023/08/28
* tree metadata should include chainId and contractAddress - https://github.com/waku-org/nwaku/pull/1932
* set flush_interval appropriately -https://github.com/waku-org/nwaku/pull/1933
* integrate new WakuRlnRegistry contract - https://github.com/waku-org/nwaku/pull/1943
* bump zerokit to v0.3.2
* https://github.com/waku-org/nwaku/pull/1951
* tree metadata should include window of roots - https://github.com/waku-org/nwaku/pull/1953
* sync tree state from contract deployed block number - https://github.com/waku-org/nwaku/pull/1955
* optimization to waku_keystore - https://github.com/waku-org/nwaku/pull/1956
* fixed a forceProgression bug in the WakuRlnRegistry contract - https://github.com/waku-org/waku-rln-contract/pull/6
#### 2023/08/14 - 2023/08/21
* rpc handler for waku rln relay - https://github.com/waku-org/nwaku/pull/1852
* fixed ganache’s change in method to manage subprocesses, fixed timeouts related to it - https://github.com/waku-org/nwaku/pull/1913
* should error out on rln-relay mount failure - https://github.com/waku-org/nwaku/pull/1904
* fixed invalid start index being used in rln-relay - https://github.com/waku-org/nwaku/pull/1915
* constrain the values that can be used as idCommitments in the rln-contract - https://github.com/vacp2p/rln-contract/pull/26
* assist with waku-simulator testing
* remove registration capabilities from nwaku, it should be done out of band - https://github.com/waku-org/nwaku/pull/1916
* add deployedBlockNumber to the rln-contract for ease of fetching events from the client - https://github.com/vacp2p/rln-contract/pull/27
#### 2023/08/07 - 2023/08/14
* Created tracking issue to manage status of this milestone - https://github.com/waku-org/nwaku/issues/1906
#### 2023/07/31 - 2023/08/07
* [Waku RLN contract registry](https://github.com/waku-org/waku-rln-contract/pull/3)
* [Mark duplicated messages as spam](https://github.com/waku-org/nwaku/pull/1867)
* [Use `waku-org/waku-rln-contract` as a submodule in `nwaku`](https://github.com/waku-org/nwaku/pull/1884)
### Deliverables
* https://github.com/waku-org/nwaku/issues/1906

43
content/vac/acz/rlnp2p/waku/rln-relay-enhancements_02.md
View File

@ -1,43 +0,0 @@
---
title: Waku RLN-RELAY Enhancements 02
---
## `vac:acz:rlnp2p::waku:rln-relay-enhancements_02`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
dateFormat YYYY-MM-DD
section Status
RLN-RELAY enhancements 02:done, 2023-09-01, 2023-11-30
```
- status: 100%
- CC: Aaryamann
### Description
* continuation of [[rln-relay-enhancements|rln-relay-enhancements]]
* comprises further enhancements of RLN relay, requested by the Waku team
### Justification
### Risks
### Deliverables

41
content/vac/acz/rlnp2p/waku/rln-relay-erc20.md
View File

@ -1,41 +0,0 @@
---
title: "RLN relay ERC20"
description: "ERC20 token support for RLN relay."
---
## `vac:acz:rlnp2p:waku:rln-relay-erc20`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
```
- status: 0%
- CC: Aaryamann
### Description
* future work
### Justification
### Deliverables

44
content/vac/acz/rlnp2p/waku/rlnv2-e2e.md
View File

@ -1,44 +0,0 @@
---
title: RLN v2 E2E integration
---
## `vac:acz:rlnp2p:waku:rlnv2-e2e`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
dateFormat YYYY-MM-DD
section Status
RLN v2 e2e Integration : done, 2024-05-20, 2024-06-20
```
- due: 2024-06-20
- status: 100%
### Description
- [x] Come up with final gas estimation after the optimizations (RLN v2 + RLN in resource-restricted)
- [x] Deliver end-to-end PoC working in The Waku Network showcasing the new features.
- [x] Bug fixes found along testing
- [x] New smart contract with both RLNv2 and RLN in resource-restricted clients changes.
- [x] Deploy and consider using a L2 testnet.
- [ ] ~Deprecate tree sync in nwaku~ (deferred because blocked)
#### Goal
Run RLN relay v2 on TWN.
### Deliverables
- [x] https://github.com/waku-org/pm/issues/168
- [x] https://github.com/waku-org/nwaku/issues/2758

47
content/vac/acz/rlnp2p/waku/rlnv2-relay-integration.md
View File

@ -1,47 +0,0 @@
---
title: "RLN v2 Waku Relay Integration"
description: "Integrating RLN v2 into Waku Relay."
---
## `vac:acz:rlnp2p:waku:rlnv2-relay-integration`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
RLN v2 relay integration:done, 2023-11-01, 2024-02-29
```
- status: 100%
- CC: Aaryamann
### Description
* also involves
- TKE
- implemenations in various Waku versions
### Justification
rln-v2 brings multi message per epoch signaling which is favourable for all users of rln instead of abiding by one global rate limit.
### Deliverables
- [x] https://github.com/waku-org/nwaku/issues/2345

49
content/vac/acz/secure-channels/waku/fd-design.md
View File

@ -1,49 +0,0 @@
---
title: "Secure Channels - fully decentralized design"
---
## `vac:acz:secure-channels:waku:fd-design`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
FD Design: 2023-04-29, 2024-12-15
```
- status: 5%
- CC: Ramses, Ugur
### Description
* follow up of [[vac/acz/secure-channels/waku/mls-design|mls-design]]
While MLS, an established protocol, allows us to quicker release a secure key setup protocol with an Ethereum authenticator,
MLS is federated in nature and makes reliability assumptions in regards to the underlying message dissemination layer.
We work towards mitigating this using on-chain components in the planned deliverables for the milestone linked above.
However, we still desire a fully decentralized version that ideally does not require an on-chain component.
This Milestone tracks this effort.
### Justification
### Deliverables
* specification (RFC)

39
content/vac/acz/secure-channels/waku/fd-poc.md
View File

@ -1,39 +0,0 @@
---
title: "Secure Channels - PoC of fully decentralized protocol"
---
## `vac:acz:secure-channels:waku:fd-poc`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
FD PoC: 2024-12-01, 2025-06-30
```
- status: 0%
- CC:
### Description
* PoC implementation of [[vac/acz/secure-channels/waku/fd-design|fd-design]]
### Justification
### Deliverables

56
content/vac/acz/secure-channels/waku/mls-design.md
View File

@ -1,56 +0,0 @@
---
title: "Secure Channels - MLS design"
---
## `vac:acz:secure-channels:waku:mls-design`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Ethereum Chat: done, 2023-09-12, 2024-05-31
```
- status: 100%
- CC: Ramses
### Description
The goal of this milestone is having
* using the [noise](http://noiseprotocol.org/noise.html) framework
* Ethereum Wallet address used to derive authentication key for noise
* Design an Ethereum address-based 1:1 chat
- should be transport agnostic
- toy eth chat: https://rfc.vac.dev/spec/20/
- this milestone requires forward secrecy (see limitations section of the toy eth chat RFC)
- consider using https://eips.ethereum.org/EIPS/eip-5564
* Naive Groupchat functionality (using `n` 1:1 chat channels)
* involve metamask here (metamask im team)
* a follow up milestone will cover running Ethereum chat on top of Waku
* follow up goal: develop this into an EIP
### Justification
### Deliverables
* [x] https://github.com/vacp2p/rfc-index/blob/main/vac/raw/eth-secpm.md (specification)

55
content/vac/acz/secure-channels/waku/mls-poc.md
View File

@ -1,55 +0,0 @@
---
title: "Secure Channels - MLS PoC"
---
## `vac:acz:secure-channels:waku:mls-poc`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
MLS PoC: done, 2024-04-29, 2024-07-15
```
- status: 100%
- CC:
- Ekaterina
- Aaryamann
### Description
* proof of concept implementation of [[vac/acz/secure-channels/waku/mls-design|mls-design]]
* repo: https://github.com/vacp2p/de-mls
* issues:
* https://github.com/vacp2p/de-mls/issues/1
* https://github.com/vacp2p/de-mls/issues/2
* https://github.com/vacp2p/de-mls/issues/3
### Justification
### Deliverables
* Engineers implementing the researchers advice on how to proceed with the PoC
- [x] https://github.com/vacp2p/de-mls/issues/1
- [x] https://github.com/vacp2p/de-mls/issues/2
- [x] https://github.com/vacp2p/de-mls/issues/3
- [x] https://github.com/vacp2p/de-mls/issues/4
- [x] https://github.com/vacp2p/de-mls/issues/5
- [x] https://github.com/vacp2p/de-mls/issues/6

45
content/vac/acz/stealth-address-kit/maintenance.md
View File

@ -1,45 +0,0 @@
---
title: Stealth Address Kit Maintenance
---
## `vac:acz:stealth-address-kit:maintenance`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Stealth Address Kit Maintenance: , 2024-02-01, 2024-12-31
```
- status: 80%
- CC: Aaryamann
### Description
Continue supporting and maintaining the [stealth-address-kit](https://github.com/vacp2p/erc-5564-rs) repo.
### Justification
This will be a viable privacy solution for status (private transfers) and waku (rln membership insertion)
### Deliverables
- [x] rename erc-5564-rs to `stealth-address-kit`
- The following releases have been made -
- [x] https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.3.1
- [x] https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.2.0
- [x] https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.1.0

16
content/vac/acz/stealth-address-kit/research.md
View File

@ -1,16 +0,0 @@
---
title: Stealth Address Kit Research
---
## `vac:stealth-address-kit:research`
---
> note: there is no gantt chart for this milestone
### Description
Further the research of the [stealth address scheme](https://eips.ethereum.org/EIPS/eip-5564) and collaborate with EF researchers to do so.
### Justification
This will be a viable privacy solution for status (private transfers) and waku (rln membership insertion)
### Deliverables

39
content/vac/acz/validator-privacy/nimbus/productionize-tor-push.md
View File

@ -1,39 +0,0 @@
---
title: Productionize Tor Push in Nimbus
---
## `vac:acz:validator-privacy:nimbus:productionize-tor-push`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Productionize tor push: , 2024-05-13, 2024-08-13
```
- status: 0%
- CC: Aaryamann
### Description
To make the tor push feature as accessible as running `--tor-push:true` while running a nimbus validator.
### Justification
Improved privacy guarantees for ethereum validators
### Deliverables
- [ ] TBD

1
content/vac/acz/zerokit/vac/maintenance.md
View File

@ -1 +0,0 @@
ongoing: zerokit maintenance

48
content/vac/acz/zerokit/vac/zerokit-v0-4.md
View File

@ -1,48 +0,0 @@
---
title: Zerokit v0.4 Release Details
---
## `vac:acz:zerokit::vac:zerokit-v0.4`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
dateFormat YYYY-MM-DD
section zerokit
v0.4 Release :done, 2023-01-20, 2023-09-07
```
- due: 2023/09/07
- status: 100%
### Description
- Release Planning - [Github Issue #197](https://github.com/vacp2p/zerokit/issues/197)
### Deliverables
* https://github.com/vacp2p/zerokit/releases/tag/v0.4.0
### Info
## 2023/08/14 - 2023/08/21
* substitute id_commitments for rate_commitments and update tests in rln-v2 - https://github.com/vacp2p/zerokit/pull/205
* rln-v2 working branch - https://github.com/vacp2p/zerokit/pull/204
## 2023/08/07 - 2023/08/14
* Serde api’s updated - https://github.com/vacp2p/zerokit/pull/202
## 2023/07/31 - 2023/08/07
* zerokit v0.4.0 release planning - https://github.com/vacp2p/zerokit/issues/197

40
content/vac/acz/zerokit/vac/zerokit-v0-5.md
View File

@ -1,40 +0,0 @@
---
title: Zerokit v0.5 Release
---
## `vac:acz:zerokit::vac:zerokit-v0.5`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
v0.5 Release: done, 2023-10-01, 2024-06-01
```
- status: 100%
- CCs:
- Ekaterina
- Aaryamann
### Description
* Release Planning issue: https://github.com/vacp2p/zerokit/issues/237
### Deliverables
- [x] https://github.com/vacp2p/zerokit/pull/239
- [x] https://github.com/vacp2p/zerokit/pull/242
- [x] https://github.com/vacp2p/zerokit/pull/243
- [x] https://github.com/vacp2p/zerokit/pull/245
- [x] https://github.com/vacp2p/zerokit/pull/246

43
content/vac/acz/zerokit/vac/zerokit-v0-6.md
View File

@ -1,43 +0,0 @@
---
title: Zerokit v0.6 Release
---
## `vac:acz:zerokit::vac:zerokit-v0.6`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
v0.6 Release: , 2024-08-12, 2024-10-12
```
- status: 40%
- CCs:
- Ekaterina
### Description
* Release Planning issue: https://github.com/vacp2p/zerokit/issues/263
This release's major feature is stateless RLN.
### Deliverables
- [x] https://github.com/vacp2p/zerokit/pull/265
- [x] https://github.com/vacp2p/zerokit/pull/266
- [x] https://github.com/vacp2p/zerokit/pull/267
- [ ] https://github.com/vacp2p/zerokit/pull/270
- [ ] https://github.com/vacp2p/zerokit/pull/269

25
content/vac/create_dirs.bash
View File

@ -1,25 +0,0 @@
# DST
mkdir -p dst/wakurtosis/waku && touch $_/techreport.md
mkdir -p dst/wakurtosis/waku && touch $_/techreport_02.md
mkdir -p dst/wakurtosis/waku && touch $_/gossipsub-topology-analysis.md
mkdir -p dst/wakurtosis/waku && touch $_/features.md
mkdir -p dst/wakurtosis/vac && touch $_/rlog.md
mkdir -p dst/wakurtosis/vac && touch $_/retrospective-rlog.md
mkdir -p dst/wakurtosis/nomos && touch $_/ci-integration.md
mkdir -p dst/wakurtosis/vac && touch $_/maintenance.md
mkdir -p dst/analysis/nomos && touch $_/nomos-simulation-analysis.md
mkdir -p dst/analysis-gsub-model/vac && touch $_/refactoring.md
mkdir -p dst/analysis-gsub-model/status && touch $_/control-messages.md
mkdir -p dst/analysis-shadow/vac && touch $_/shadow-gossipsub-analysis.md
mkdir -p dst/analysis-shadow/waku && touch $_/shadow-waku-relay-analysis.md
mkdir -p dst/eng/vac && touch $_/bundle-simulation-data.md
mkdir -p dst/eng-10ktool/vac && touch $_/bandwidth.md
mkdir -p dst/eng-10ktool/waku && touch $_/waku-protocols.md
mkdir -p dst/software-testing/waku && touch $_/test-plans.md
mkdir -p dst/software-testing/waku && touch $_/test-automation-js-waku.md
mkdir -p dst/software-testing/waku && touch $_/test-automation-nwaku.md
mkdir -p dst/software-testing/waku && touch $_/test-automation-go-waku.md
mkdir -p dst/software-testing/waku && touch $_/interop-testing.md

48
content/vac/dr-ice/consensus/nomos/blockchain-security-in-crypto-economic-models.md
View File

@ -1,48 +0,0 @@
---
title: "Blockchain Security in Crypto-economic Models"
---
## `vac:dr:consensus:vac:blockchain-security-in-crypto-economic-models`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Blockchain Security in Crypto-economic Models: 2023-11-01, 2024-02-29
```
- status: 0%
- CC: Moh
### Description
This research will provide a comprehensive security analysis of Carnot under the Crypto Economic Model.
This is a new security model for distributed consensus algorithms in which economic attacks on the protocol will be considered.
### Justification
The combination of PoS and distributed consensus, necessitates a new comprehensive security model for blockchain ecosystem.
### Risks
This is a new research direction.
### Deliverables
* conference paper

59
content/vac/dr-ice/consensus/nomos/carnot-2-3rds-vote-aggregation.md
View File

@ -1,59 +0,0 @@
---
title: "Carnot 2/3 Vote aggregation"
---
## `vac:dr:nomos:nomos:carnot-vote-2-3rds-vote-aggregation`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Carnot 2/3 Vote Aggregation: 2023-08-01, 2023-10-15
```
- status: 20%
- CC: Moh
### Description
This research will use the Carnot flexible design to make it collect more than 2/3rd of cryptographic proof of votes cast for a block.
* write a research log post
* desciption of the solution
* support by the DST team: [[ roadmap/vac/dst/dr-support/vac/carnot-2-3rds-executable-spec | carnot-2rds-executable-spec ]]
### Risks
Might slightly increase the protocol overhead. But we make sure this overhead is minimal.
### Justification
### Deliverables
* [x] Presentation slides (logos research)
* Pseudocode (potentially paper in a future milestone)
* notion doc describing the solution
* research log post
* python code, support by the DST team [[ roadmap/vac/dst/dr-support/vac/carnot-2-3rds-executable-spec | carnot-2rds-executable-spec ]]
* RFC on rfc.vac.dev containing executable spec
Note: Need to be discussed: The Pseudocode can be completed earlier so that devs can began implementation, whereas the paper can be completed later.

64
content/vac/dr-ice/consensus/nomos/carnot-bribary-article.md
View File

@ -1,64 +0,0 @@
---
title: "Carnot Bribary Article"
---
## `vac:dr:consensus:nomos:carnot-bribary-article`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Carnot Bribary Article: 2023-08-01, 2023-08-31
```
- status: ?%
- CC:
### Description
The article describes how multi-dimensional bribery attacks cannot be addressed at the consensus layer alone.
A proper game theoretical, economic analysis also needs to be done. The solution to this problem will also touch on several aspects
including the economy, distributed systems, and cryptography.
This Milestone also comprises a presentation:
This presentation slide describes how multi-dimensional bribery attacks cannot
be addressed at the consensus layer alone. By combining PoS with the
distributed consensus a new dimension is introduced into the ecosystem. Now the
security of the protocol should also be considered against economic attacks.
The presentation provides an example based on the Crypto Economic security
model of how any PoS consensus protocol can fail against a bribing attack. The
presentation emphasizes that a proper game theoretical, and economic analysis
also needs to be done. It also suggests a solution for addressing bribing
attacks in Carnot consensus.
### Risks
This problem has not been properly addressed for PoS protocols.
### Justification
### Deliverables
* A report on how bribery attacks can be addressed in PoS. This will ultimately give a new research direction.
* [presentation slides](https://www.notion.so/Roadmap-Deep-Research-DR-561a864c890549c3861bf52ab979d7ab?pvs=4#5873a631da964b34a24e5a05307b29ae)
* [current status](https://hackmd.io/oCOmQD6sSLOsjqr7sh7jNw)

53
content/vac/dr-ice/consensus/nomos/carnot-paper_02.md
View File

@ -1,53 +0,0 @@
---
title: "Carnot Paper 02"
---
## `vac:dr:consensus:nomos:carnot-paper_02`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Carnot Paper: 2023-09-01, 2024
```
- status: 10%
- CC: Moh
### Description
* complete experimental results
* publish the paper at a scientific conference or journal
* present the paper at the conference
* the goal is to submit before end of 2023
### Risks
* We need to find a fitting conference and the respective deadlines might not align.
* review process takes a long time
(No fixed deadline because of these risks.)
### Justification
### Deliverables

46
content/vac/dr-ice/consensus/nomos/detecting-reporting-attacks-carnot.md
View File

@ -1,46 +0,0 @@
---
title: "Detecting Reporting Attacks Carnot"
---
## `vac:dr:consensus:nomos:detecting-reporting-attacks-carnot`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Detecting Reporting Attacks Carnot: 1970-01-01, 1970-01-02
```
- status: 0%
- CC: Moh
### Description
This research work will describe the mechanism of how various attacks can be detected, reported, and slashed in the consensus.
### Justification
### Deliverables
* algorithm
* pseudocode
* spec
* rlog post

24
content/vac/dr-ice/consensus/nomos/inter-chain-protocol.md
View File

@ -1,24 +0,0 @@
---
title: "Inter Chain Protocol"
---
## `vac:dr:consensus:nomos:inter-chain-protocol`
---
- status: 0%
- CC: Moh
### Description
Exploring the interplay between the main chain and execution zones or chains is a pivotal aspect of our research.
Our inquiry delves into how these zones are initiated from the main chain, ensuring their security and data availability.
Additionally, we address the optimization of interaction among independent chains, facilitating efficient cross-chain communication and collaboration.
### Justification
### Deliverables
* Algorithm
* spec

30
content/vac/dr-ice/consensus/nomos/multi-leader-and-multi-overlay-carnot.md
View File

@ -1,30 +0,0 @@
---
title: "Multi-Leader and Multi-Overlay Carnot"
---
## `vac:dr:consensus:nomos:multi-leader-and-multi-overlay-carnot`
---
- status: 0%
- CC: Moh
### Description
In pursuit of heightened resilience and performance optimization, our research extends to multi-leader and multi-overlay Carnot configurations.
This direction seeks to bolster the protocol's resistance against Denial of Service (DoS) and bribery attacks.
By introducing multiple leadership nodes and overlay structures, we envision a protocol that thrives in adversarial environments while maintaining exceptional performance standards.
As we navigate this deep research trajectory, our collective efforts contribute to the advancement of blockchain technology, ushering in a new era of consensus, privacy, and scalability.
Has to adhere to Nomos architecture (specific specifications)
* Nomos Whitepaper
* has to adhere to privacy requirements
### Justification
### Deliverables
* Algorithm
* spec

76
content/vac/dr-ice/consensus/nomos/stake-privacy-timing-attacks.md
View File

@ -1,76 +0,0 @@
---
title: "Network Privacy Stack - Stakeholder Privacy"
description: "Main goal: finding in-protocol (carnot) mechanisms to solve the problem of timing attacks."
---
## `vac:dr:consesus:nomos:stake-privacy-timing-attacks`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Stake Privacy - Timing Attacks:
```
- status: 0%
- CC: Moh
### Description
This milestone comprises component 3 of the [Nomos network privacy stack](https://www.notion.so/Network-Privacy-Stack-2a2a86647d2a42ca9de6940c55f99851)
in the context of consensus privacy:
The main goal of this work is finding in-protocol (carnot) mechanisms to solve the problem of timing attacks.
Upper layer protections of the network from the sender: Simplest solution to prevent attacks to private PoS: minimum age of transaction for inclusion.
Certain types of timing attacks and network observation to identify high stake participants are already being worked on at the network level.
However, this problem should be considered at the PoS/consesus layer as well.
#### more info
* [paper: On the Anonymity Guarantees of Anonymous Proof-of-Stake Protocols](https://eprint.iacr.org/2021/409.pdf)
From the abstract:
```
[...] focus on anonymizing the
messages of the blockchain protocol, but suggest that potential identity leaks from the networklayer can be removed as well by employing anonymous broadcast channels.
In this work we show that this intuition is flawed.
```
Generally, our endeavor in stake privacy research centers on preserving the confidentiality of validator stakes.
By leveraging cryptographic techniques and innovative approaches, we aim to enhance the privacy and security of staking operations within the Carnot ecosystem.
Older docs:
* Hash-based Node Id encryption Hash-based-Node-Id-encryption-7bfb11941a6840c49bfe065f535877c9?pvs=24
* Carnot PoS Discussion notion.so/Carnot-PoS-Discussion-f2ef371102f6433da81fb1b1b9213c2b?pvs=24
Potential future solutions (outside the scope of this mile stone) comprise: proof of mixing + modifications to the base mixnet design. This seems like a difficult path, for long-term research if feasible.
### Justification
This is and important step towards achieving the Nomos privacy requirements.
### Deliverables
* specification

30
content/vac/dr-ice/index.md
View File

@ -1,30 +0,0 @@
---
title: Deep Research Service Unit - Icebox Milestones
tags:
- dr
- vac
date: 2024-05-14
lastmod: 2024-05-14
---
## `vac:dr:valpriv:vac:`
* [[vac/dr-ice/valpriv/vac/tor-push-rln|tor-push-rln]]
* [[vac/dr-ice/valpriv/vac/priv-validator-network|priv-validator-network]]
* [[vac/dr-ice/valpriv/vac/mix-net-solution|mix-net-solution]]
## `vac:dr:valpriv:nomos:`
* [[vac/dr-ice/valpriv/nomos/validator-privacy|validator-privacy]]
## `vac:dr:consensus:nomos:`
* [[vac/dr-ice/consensus/nomos/carnot-paper_02|carnot-paper_02 ]]
* [[vac/dr-ice/consensus/nomos/carnot-bribary-article|carnot-bribary-article]]
* [[vac/dr-ice/consensus/nomos/carnot-2-3rds-vote-aggregation|carnot-2-3rds-vote-aggregation]]
* [[vac/dr-ice/consensus/nomos/blockchain-security-in-crypto-economic-models|blockchain-security-in-crypto-economic-models]]
* [[vac/dr-ice/consensus/nomos/detecting-reporting-attacks-carnot|detecting-reporting-attacks-carnot]]
* [[vac/dr-ice/consensus/nomos/stake-privacy-timing-attacks|stake-privacy-timing-attacks]]
* [[vac/dr-ice/consensus/nomos/inter-chain-protocol|inter-chain-protocol]]
* [[vac/dr-ice/consensus/nomos/multi-leader-and-multi-overlay-carnot|multi-leader-and-multi-overlay-carnot ]]

0
content/vac/dr-ice/valpriv/nomos/validator-privacy.md
View File

0
content/vac/dr-ice/valpriv/vac/mix-net-solution.md
View File

0
content/vac/dr-ice/valpriv/vac/priv-validator-network.md
View File

0
content/vac/dr-ice/valpriv/vac/tor-push-rln.md
View File

73
content/vac/dr/anon/vac/gossipsub-anonymity.md
View File

@ -1,73 +0,0 @@
---
title: "Gossipsub Anonymity Layer"
---
## `vac:dr:anon:vac:gossipsub-anonymity`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Gossipsub Anonymity Layer: 2024-04-15, 2024-12-15
```
- status: 50%
- CC: Akshaya
### Description
This Milestone entails designing an anonymization layer for gossipsub, and by extension, IFT projects.
The primary objective of this anonymization layer is to serve as a cohesive anonymization solution for gossip-based projects,
with a specific focus on integrating it with the Logos projects Waku and Codex.
Currently, we're uncertain whether the complete anonymization layer can be situated between gossipsub and the protocols of IFT projects.
It appears more plausible that we'll establish a foundational element atop gossipsub,
with project-specific components integrated into the projects themselves,
or introduce an intermediary layer between the general gossip anonymization protocol and the project protocols.
The Nomos team is crafting their own anonymization solution due to their unique requirements and their ability to leverage specific traffic patterns to enhance efficiency.
Nonetheless, the overarching objective for our anonymization network is to render our solution modular, enabling the inclusion of traffic pattern plugins that Nomos can define.
Our initial exploration will revolve around extending our [Tor push proposal](https://rfc.vac.dev/spec/46/).
In this approach, messages will traverse through an anonymization network before being disseminated via gossip protocols upon exiting the anonymization network.
Additionally, we aim to investigate the concept of embedding anonymization capabilities directly into gossipsub,
rather than routing messages through a separate anonymization network before entering a standard gossipsub network operation.
Currently we view this anonymization solution as a P2P base layer, which the Vac P2P team will offer as part of libp2p.
This effort could potentially spawn an incubation project.
This effort would act as a basis for the Validator Privacy Network incubation project.
### Justification
Currently, IFT projects do not provide enough anonymity guarantees.
Privacy protection, which entails anonymity, is part of the [logos manifesto](https://logos.co/manifesto/).
#### Deliverables
* report comparing various approaches to realizing a gossipsub anonymization layer for IFT projects
- this might entail identifying the need for in-project components (see description)
- has to provide arguments why the proposed approach is expected to provide sufficient anonymity guarantees
* document describing benefits for each of Waku, Status, Codex, and Nimbus
* Paper on arxiv.com
- including security/privacy analysis
- should offer improvements over Tor push.
- spam protection (integrate RLN)
- the proposed solution MUST be practically applicable, efficient, and relevant (product-market fit)
* draft specification of the base functionality (a usable subset of the functionality)
* PoC implementation of the base functionality
- [x] https://github.com/vacp2p/rfc-index/pull/97/

44
content/vac/dr/consensus/nomos/carnot-paper.md
View File

@ -1,44 +0,0 @@
---
title: "Carnot Paper"
---
## `vac:dr:consensus:nomos:carnot-paper`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Carnot Paper: done, 2023-01-20, 2023-09-30
```
- status: 100%
- CC: Moh
### Description
First version of a scientific carnot paper.
Publish on arxiv.
### Justification
### Deliverables
* https://arxiv.org/pdf/2308.16016.pdf

20
content/vac/dr/g/nomos/reviews.md
View File

@ -1,20 +0,0 @@
---
title: "Reviews"
description: "research consulting: reviews of documents / papers"
---
## `vac:dr:g:nomos:reviews`
---
- status: ongoing
- CC: team
### Description
### Justification
### Deliverables

47
content/vac/dr/gsub-scaling/vac/gossipsub-improvements-paper.md
View File

@ -1,47 +0,0 @@
---
title: "Gossipsub Improvements Paper"
---
## `vac:dr:gsub-scaling:vac:gossipsub-improvements-paper`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Gossipsub Improvements paper: 2023-06-01, 2023-10-31
```
- status: 70%
- CC: Farooq
### Description
[background + first results + potential improvements](https://hackmd.io/X1DoBHtYTtuGqYg0qK4zJw)

* comprehensive current/related work study on gossipsub scaling (including relevant work outside of gossipsub, in the broader area of unstructured P2P networks in general)
* complete technical report on gossip scaling / gossipsub improvements (containing, but not limited to, our previous research)
* research log post (vac.dev) based on the techreport
* talk @ Logos research call
* scientific paper ready for publication
### Justification
### Deliverables

42
content/vac/dr/gsub-scaling/vac/gossipsub-simulation.md
View File

@ -1,42 +0,0 @@
---
title: "Gossipsub Simulation"
---
## `vac:dr:gsub-scaling:vac:gossipsub-simulation`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Gossipsub Simulation: 2023-06-31, 2023-09-30
```
- status: 20%
- CC: Farooq
### Description
* simple gossipsub node (in nim) for DST/Wakurtosis simulations
* PoC [shadow](https://github.com/shadow/shadow) simulation
### Justification
### Deliverables

42
content/vac/dr/gsub-scaling/vac/unstructured-p2p-improvements-survey.md
View File

@ -1,42 +0,0 @@
---
title: "Unstructured P2P Improvements Survey"
---
## `vac:dr:gsub-scaling:vac:unstructured-p2p-improvements-survey`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Unstructured P2P Improvements Survey: 2023-08-15, 2023-12-31
```
- status: 20%
- CC: Farooq
### Description
* survey techreport
* survey scientific paper if there is enough to justify a paper
### Justification
### Deliverables

36
content/vac/dr/index.md
View File

@ -1,36 +0,0 @@
---
title: Deep Research Service Unit
tags:
- dr
- vac
date: 2023-08-25
lastmod: 2024-05-14
---
## `vac:dr:valpriv:vac:`
* [x] [[vac/dr/valpriv/vac/tor-push-poc|tor-push-poc]]
* [x] [[vac/dr/valpriv/vac/tor-push-rel-work|tor-push-rel-work]]
* [[vac/dr/valpriv/vac/tor-push-paper|tor-push-paper]]
## `vac:dr:gsub-scaling:vac:`
* [[vac/dr/gsub-scaling/vac/gossipsub-simulation|gossipsub-simulation]]
* [[vac/dr/gsub-scaling/vac/gossipsub-improvements-paper|gossipsub-improvements-paper]]
* [[vac/dr/gsub-scaling/vac/unstructured-p2p-improvements-survey|unstructured-p2p-improvements-survey]]
## `vac:dr:consensus:nomos:`
* [x] [[vac/dr/consensus/nomos/carnot-paper|carnot-paper]]
## `vac:dr:zk:codex:`
* [x] [[ vac/dr/zk/codex/storage-proofs-open-problems-review | storage-proofs-open-problems-review ]]
* [[ vac/dr/zk/codex/zk-consulting | zk-consulting ]]
## `vac:dr::nomos:`
* [[ vac/dr/g/nomos/reviews | reviews ]]
## `vac:dr:anon:vac:`
* [[ vac/dr/anon/vac/gossipsub-anonymity | gossipsub-anonymity ]]

46
content/vac/dr/valpriv/vac/tor-push-paper.md
View File

@ -1,46 +0,0 @@
---
title: "Tor Push Paper"
---
## `vac:dr:valpriv:vac:tor-push-paper`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Tor Push Paper: 2023-08-01, 2023-11-30
```
- status: 30%
- CC: Umar
### Description
Comprises:
* thorough anonymity/sec analysis of Tor push for Validator privacy
* thorough latency analysis of Tor push
* paper (for workshop) on introducing and analysing Tor-push
### Justification
### Deliverables

52
content/vac/dr/valpriv/vac/tor-push-poc.md
View File

@ -1,52 +0,0 @@
---
title: "Tor Push PoC"
---
## `vac:rc:valpriv:vac:tor-push-poc`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Tor Push PoC: 2023-06-01, 2023-09-15
```
- status: 80%
- CC: Umar
### Description
* [x] first PoC of Tor push in Nimbus (testnet Goerli) https://github.com/vacp2p/nimbus-eth2-experimental/issues/1
- first latency measurements (comprehensive analysis in next milestone)
* research log post on Tor push / Nimbus PoC incl first latency measurements
* add epoch support as described in the [RFC](https://rfc.vac.dev/spec/46/)
* update/adjust Tor push spec
* talk @ Logos research call
* refine PoC (should fully cover the RFC)
* thorough latency measurements for[[vac/dr/valpriv/vac/tor-push-paper|tor-push-paper]]
#### Info
* The epochs
### Justification
### Deliverables
* [WIP] https://github.com/vacp2p/nimbus-eth2-experimental/pull/3

44
content/vac/dr/valpriv/vac/tor-push-rel-work.md
View File

@ -1,44 +0,0 @@
---
title: "Tor Push Related Work"
---
## `vac:dr:valpriv:vac:tor-push-rel-work`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Tor Push Related Work: done, 2023-06-01, 2023-09-15
```
- status: 100%
- CC: Umar
### Description
Background and motivation [here](https://ethresear.ch/t/a-tor-based-validator-anonymity-approach-incl-comparison-to-dandelion/14134).
* comprehensive current/related work study on Validator Privacy
- focus on network layer but also including: network vs consesus layer privacy (SSLE), as well as combinations
### Justification
### Deliverables

45
content/vac/dr/zk/codex/storage-proofs-open-problems-review.md
View File

@ -1,45 +0,0 @@
---
title: "Storage Proofs: Open Problems Review"
description: "Review Codex' storage proof ZK related open research problems."
---
## `vac:dr:zk:codex:open-problems-review`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Open Problems Review: 2023-09-20, 2023-11-30
```
- status: 100%
- CC: Marvin
### Description
* https://github.com/codex-storage/zk-research-artifacts/blob/master/storage_proofs/storage_proof_musings.md
### Justification
### Deliverables
* [x] sanity checks of existing documents

55
content/vac/dr/zk/codex/zk-consulting.md
View File

@ -1,55 +0,0 @@
---
title: "Codex Deep Research ZK consulting"
description: "consulting Codex on various ZK related subtasks"
---
## `vac:dr:zk:codex:zk-consulting`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
zk-consulting: 2024-04-14, 2024-12-31
```
- status: 10%
- CC: Marvin
### Description
This Milestone comprises deep research ZK consulting for Codex:
Here is a high level description of Codex ZK research problems: https://hackmd.io/1IZiFSiYSdyrbaKxKeUevg
1) summarizing existing research relevant for us (exactly which papers is kind of dynamically determined), in form of PDF notes and face-to-face explanations. We agreed with Marvin that this is probably the easiest way to get something going
2) finding a suitable set commitment scheme (for tracking which proofs are present / not present in an aggregated proof)
3) figuring out the details of recursion for elliptic-curve-and-pairing based schemes (while this is solved, more clarity on this is required)
Regarding 3): Even if we end up using a non EC scheme for "large data", KZG (and thus EC pairings) seems to be a much better choice for "small data",
so we will probably need this in any case (unless we can efficiently verify KZG proofs in a small field / FRI setting).
Some of these tasks are explorative. Expected outputs are regular reports.
A follow-up milestone for the next reporting period is expected.
### Justification
### Deliverables
* regular reports.

43
content/vac/dst-ice/analysis-gsub-model/status/control-messages.md
View File

@ -1,43 +0,0 @@
---
title: "Control Messages"
---
## `vac:dst:analysis-gsub-model:status:control-messages`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Control Messages: 2023-07-01, 2023-09-15
```
- status: 85%
- CC: Ganesh
### Description
### Justification
### Info
* delayed because of extending Nomos analysis milestone
### Deliverables

40
content/vac/dst-ice/analysis-gsub-model/vac/refactoring.md
View File

@ -1,40 +0,0 @@
---
title: "Refactoring"
---
## `vac:dst:analysis-gsub-model:vac:refactoring`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Refactoring: 2023-08-01, 2023-09-30
```
- status: 40%
- CC: Ganesh
### Description
### Justification
### Deliverables

41
content/vac/dst-ice/analysis-shadow/vac/shadow-basic-simulation.md
View File

@ -1,41 +0,0 @@
---
title: "Basic Shadow Simulation"
---
## `vac:dst:analysis-shadow:vac:basic-shadow-simulation`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Basic Shadow Simulation: 2023-08-01, 2023-08-31
```
- status: 90%
- CC: Jordi
### Description
* simple 10k shadow sim of the gossipsub node as a PoC.
### Justification
### Deliverables

44
content/vac/dst-ice/analysis-shadow/vac/shadow-gossipsub-analysis.md
View File

@ -1,44 +0,0 @@
---
title: "Shadow Gossipsub Analysis"
---
## `vac:dst:analysis-shadow:vac:shadow-gossipsub-analysis`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Shadow Gossipsub Analysis: 2023-09-01, 2023-10-31
```
- status: 0%
- CC: Jordi
### Description
* develop a gossipsub node with allows to set desired message rates and other properties
* try to get to a higher node number (50k?)
* research log post
### Justification
### Deliverables

40
content/vac/dst-ice/analysis-shadow/waku/shadow-waku-relay-analysis.md
View File

@ -1,40 +0,0 @@
---
title: "Shadow Waku Relay Analysis"
---
## `vac:dst:analysis-shadow:waku:shadow-waku-relay-analysis`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Shadow Waku Relay Analysis: done, 2023-10-01, 2023-11-30
```
- status: 0%
- CC: Jordi
### Description
### Justification
### Deliverables

43
content/vac/dst-ice/dr-support/vac/carnot-executable-spec.md
View File

@ -1,43 +0,0 @@
---
title: "Carnot 2-3rds Vote Aggregation Python Implementation"
---
## `vac:dst:dr-support:vac:carnot-2-3rds-python-impl`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Carnot 2/3rds Python Impl: 2023-09-15, 2023-10-31
```
- status: 0%
- CC: Ganesh
### Description
* support the DR team with writing the python code for a executable specification of the Carnot 2/3rds vote aggregation
- [[carnot-2-3rds-vote-aggregation| see DR milestone: carnot-2-3rds-vote-aggregation]]
### Justification
### Deliverables

40
content/vac/dst-ice/index.md
View File

@ -1,40 +0,0 @@
---
title: Distributed Systems Testing Service Unit - Milestone Icebox
tags:
- dst
- vac
date: 2024-05-14
lastmod: 2024-05-14
---
## `vac:dst:`
---
### `wakurtosis:waku:`
* [[vac/dst-ice/wakurtosis/waku/gossipsub-topology-analysis|gossipsub-topology-analysis ]]
### `wakurtosis:nomos:`
* [x] [[vac/dst-ice/wakurtosis/nomos/ci-integration|ci-integration ]]
### `wakurtosis:vac:`
* [[vac/dst-ice/wakurtosis/vac/rlog|rlog]]
### `analysis:nomos`
* [x] [[vac/dst-ice/analysis/nomos/nomos-simulation-analysis|simulation-analysis ]]
### `analysis-gsub-model:vac`
* [[vac/dst-ice/analysis-gsub-model/vac/refactoring|refactoring ]]
### `analysis-gsub-model:status:`
* [[vac/dst-ice/analysis-gsub-model/status/control-messages|control-messages ]]
### `analysis-shadow:vac:`
* [[vac/dst-ice/analysis-shadow/vac/shadow-basic-simulation|shadow-basic-simulation ]]
* [[vac/dst-ice/analysis-shadow/vac/shadow-gossipsub-analysis|shadow-gossipsub-analysis ]]
### `analysis-shadow:waku:`
* [[vac/dst-ice/analysis-shadow/waku/shadow-waku-relay-analysis|shadow-waku-relay-analysis ]]
### `dr-support:`
* [[roadmap/vac/dst-ice/dr-support/vac/carnot-2-3rds-executable-spec|carnot-2-3rds-executable-spec ]]

48
content/vac/dst-ice/nomos/nomos-simulation-analysis.md
View File

@ -1,48 +0,0 @@
---
title: "Simulation Analysis"
---
## `vac:dst:analysis:nomos:simulation-analysis`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Simulation Analysis: 2023-08-01, 2023-09-15
```
- status: 100%
- CC: Ganesh
### Description
### Justification
### Info
Extended:
* include signature aggregation into analysis
* write analysis section in Carnot paper
* [nomos node](https://github.com/logos-co/nomos-node)
* [nomos simulations](https://github.com/logos-co/nomos-simulations)
### Deliverables

45
content/vac/dst-ice/wakurtosis/vac/retrospective-rlog.md
View File

@ -1,45 +0,0 @@
---
title: "Rlog: Wakurtosis Retrospective"
---
## `vac:dst:wakurtosis:waku:retrospective-rlog`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Wakurtosis Retrospective: 2023-08-01, 2023-09-30
```
- status: 50%
- CC: Jordi
### Description
Research log discussing what would we have needed from Wakurtosis to make it work for us beyond our smaller solution.
Why did we decide to drop Kurtosis and work towards a Kubernetes-based solution now.
### Justification
### Info
* [Alberto's Opinion](https://www.notion.so/Alberto-s-Opinion-5f1af38a2e274f42baad0e322629f3a9)
### Deliverables

45
content/vac/dst-ice/wakurtosis/vac/rlog.md
View File

@ -1,45 +0,0 @@
---
title: "Wakurtosis Rlog"
---
## `vac:dst:wakurtosis:waku:rlog`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Rlog Wakurtosis: 2023-06-01, 2023-08-31
```
- status: 90%
- CC: Jordi
### Description
Research log post based on the Wakurtosis tech reports and addendum.
### Justification
### Info
* delayed because of holidays / other prios
### Deliverables

60
content/vac/dst-ice/wakurtosis/waku/gossipsub-topology-analysis.md
View File

@ -1,60 +0,0 @@
---
title: "Gossipsub Topology Analysis"
---
## `vac:dst:wakurtosis:waku:gossipsub-topology-analysis`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Gossipsub Topology Analysis: 2023-07-01, 2023-10-15
```
- status: 60%
- CC: Ganesh
### Description
Analysis of the topology of a gossipsub topic mesh.
Comprises:
* research log post
* shadow integration
* Logos research call talk; also get input during the discussion regarding which areas we should go deeper into, and what would help Logos projects the most.
### Info
Extended deadline because:
* added research log post to the milestone goals + more analysis goals (e.g stability/dynamics)
* added analysing simple gossipsub node (in addition to Waku relay)
- Relevant data has to be collected on the gossipsub-layer which increased the complexity of this milestone
* shadow integration
* more focus on nomos simulation analysis + extended analysis
Note: This analysis module will be usable outside of Wakurtosis, too.
This is the reason we continue on this milestone, even though Wakurtosis is deprecated now.
### Justification
### Deliverables

43
content/vac/dst/deployment-and-analysis/codex/testnet.md
View File

@ -1,43 +0,0 @@
---
title: "Testnet"
description: "Help Codex deploy and run a testnet. Provide support and advice."
---
## `vac:dst:deployment-and-analysis:codex:testnet`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Testnet: 2024-05-01, 2024-12-31
```
- status: 15%
- CC: Wings
### Description
Assist the Codex team with deploying and running a testnet for the Codex network.
- Provide a 256TB Storage Provider deployment, which should later build towards 1PiB
- Provide various support and analysis for how the testnet operates and help improve Codex
### Justification
### Deliverables
- Materially assist Codex with rolling out testnet
- Working SP storing real data

44
content/vac/dst/deployment-and-analysis/nomos/mixnet.md
View File

@ -1,44 +0,0 @@
---
title: "Mixnet"
description: "Help the Nomos team deploy and run a mixnet."
---
## `vac:dst:deployment-and-analysis:nomos:mixnet`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Mixnet: 2024-05-01, 2024-12-31
```
- status: 10%
- CC: Wings
### Description
Assist the Nomos team with deploying and running a mixnet at scale within VacLab.
- Provide analysis of the VacLab mixnet
- Through [Visualiser](../../tooling/vac/visualiser-tool.md), provide visualisation tools and work with the Nomos team to implement privacy preserving metrics and measurements in Nomos to help understand the mixnet's performance.
- Work with the Nomos team to deploy the visualisation tools for their own purposes.
### Justification
### Deliverables
- Lab version of mixnet fully operational and rolled out
- Working metrics via Visualiser Tool

51
content/vac/dst/deployment-and-analysis/vac/libp2p-version-testing.md
View File

@ -1,51 +0,0 @@
---
title: "Ongoing testing of specific monthly libp2p releases"
description: "On a monthly cadence, test specific releases of libp2p and provide feedback."
---
## `vac:dst:deployment-and-analysis:vac:libp2p-version-testing`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
LibP2P: 2024-05-15, 2024-12-31
```
- status: Ongoing
- CC: Wings
### Description
The Vac P2P team is transitioning nim-libp2p to a monthly release cycle.
This process involves selecting a commit hash to designate as the monthly version a week prior to release.
DST will conduct stability tests on this version.
This also comprises analysing results as well as identifying and pinpointing bugs if any arise.
Specific issues might require several test runs and thorough analysis.
Our aim is to increasingly automate this process.
Additional testing outside the scope of DST and this milestone comprises:
* testing on a Nimbus test fleet
* testing on a Waku test fleet
### Justification
### Deliverables
- Monthly report of libp2p testing outcomes

48
content/vac/dst/deployment-and-analysis/waku/10k.md
View File

@ -1,48 +0,0 @@
---
title: "10k Node Cluster"
description: "Run 10,000 Waku nodes in one cluster, with a pipeline for analysis and measurements."
---
## `vac:dst:deployment-and-analysis:waku:10k`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
10k: 2024-05-01, 2024-11-01
```
- status: 90%
- CC: Wings
### Description
Run 10,000 Waku nodes actively passing messages in one network.
Gather bandwidth details, deliverability rate, retrieval times. Measure reliability, improve reliability and document deployment and analysis processes.
Gather QoS details such as latency, dropped packets, etc.
### Justification
### Deliverables
Documentation of both the deployment process and actual deployments.
Useful analytics for the Waku team that can be used to improve the Waku software.
Research articles such as blog posts about the large scale clusters.

62
content/vac/dst/deployment-and-analysis/waku/midscale.md
View File

@ -1,62 +0,0 @@
---
title: "Midscale"
description: "Run smaller 1K-5K node Waku deployments, with a pipeline for analysis and measurements."
---
## `vac:dst:deployment-and-analysis:waku:midscale`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Midscale: 2024-05-01, 2024-11-01
```
- status: 40%
- CC: Wings
### Description
Run deployments of between 1000 and 5000 Waku nodes actively passing messages in one network.
Testing is to be done in this order of priority:
1. Measure relay bandwidth
2. Measure reliability of Waku message relaying
3. Measure usage of the DiscV5 protocol in the same scenario as (1).
4. Test Store protocol at scale
5. Test Waku relay+store reliability with nodes going offline/online
- If nodes go online/offline, we should be able to retrieve missing messages from the store. This will also test Waku message relaying in a different way.
6. Measure (1) and (3) in heterogenous clusters involving different node implementations such as nwaku and go-waku
7. Test waku shard behaviour and stability with various of numbers of shards
8. Filter and lightpush tests
9. Measure (3) with Waku peer exchange protocol used for discovery by a subset of nodes.
10. Measure (1) with a mix of nodes using Resource-restricted device reliability protocol and peer exchange, meaning a small number of nwaku nodes serve store, light push and filter protocols and a high number of clients consume them. For example, 6-10 service nodes, 200 relay nodes and 1000 light nodes.
This should include connection and node churn impact on reliability for both relay and light clients.
Additionally, perform monthly regression tests against a chosen version of Waku to ensure that no new bugs have been introduced. Produce a report on the results of the tests and any interesting findings.
### Justification
Provide a greater understanding of Waku's performance and reliability in midsized networks.
### Deliverables
Frequent deployments of 1000-5000 node networks.
Documentation of both the deployment process and actual deployments.
Useful analytics for the Waku team that can be used to improve the Waku software.
Research articles such as blog posts about findings from the midscale deployments.

20
content/vac/dst/eng/vac/bundle-simulation-data.md
View File

@ -1,20 +0,0 @@
---
title: "Bundle Simulation Data"
---
## `vac:acz:rlnp2p:waku:production-readiness`
---
- status: ongoing
- CC:
### Description
The Vac DST engineering team runs simulations, bundles the resulting data, and delivers.
### Justification
### Deliverables

36
content/vac/dst/index.md
View File

@ -1,36 +0,0 @@
---
title: Distributed Systems Testing Service Unit
tags:
- dst
- vac
date: 2023-08-25
lastmod: 2024-05-14
---
## `vac:dst:`
---
### `tooling`
* [[vac/dst/tooling/vac/deployer-tool|deployer-tool ]]
* [[vac/dst/tooling/vac/visualiser-tool|visualiser-tool ]]
## `deployment-and-analysis`
* [[vac/dst/deployment-and-analysis/waku/10k|10k ]]
* [[vac/dst/deployment-and-analysis/waku/midscale|midscale ]]
* [[vac/dst/deployment-and-analysis/nomos/mixnet|mixnet ]]
* [[vac/dst/deployment-and-analysis/codex/testnet|testnet ]]
* [[vac/dst/deployment-and-analysis/vac/libp2p-version-testing|libp2p-version-testing ]]
### `wakurtosis:waku:`
* [x] [[vac/dst/wakurtosis/waku/techreport|techreport ]]
* [x] [[vac/dst/wakurtosis/waku/techreport_02|techreport_02 ]]
* [x] [[vac/dst/wakurtosis/waku/features|wakurtosis:features ]]
### `wakurtosis:nomos:`
* [x] [[vac/dst/wakurtosis/nomos/ci-integration|ci-integration ]]
### `wakurtosis:vac:`
* [[vac/dst/wakurtosis/vac/retrospective-rlog|retrospective-rlog ]]
* [x] [[vac/dst/wakurtosis/vac/maintenance|maintenance ]]

48
content/vac/dst/tooling/vac/deployer-tool.md
View File

@ -1,48 +0,0 @@
---
title: "Deployer Tool"
description: "Build a tool that makes it easy to deploy large numbers of nodes in a controlled network."
---
## `vac:dst:tooling:vac:deployer-tool`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Deployer Tool: 2024-05-01, 2024-11-01
```
- status: 90%
- CC: Alberto, Wings
### Description
A first version of tool that allows deploying >10k gossipsub / waku relay nodes.
The tool should measure bandwidth usage per node and bundle the measurement data for analysis.
The tool should be built in such a way that it can be used for other deployments as well.
It should allow automated, repeatable and accountable deployments.
### Justification
### Deliverables
* https://github.com/vacp2p/10ksim
* https://github.com/vacp2p/vaclab/argocd

57
content/vac/dst/tooling/vac/visualiser-tool.md
View File

@ -1,57 +0,0 @@
---
title: "Visualiser Tool"
description: "Build a web app that displays a map of a project's network, showing the flow of messages between nodes."
---
## `vac:dst:tooling:vac:visualiser-tool`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Visualiser Tool: 2024-05-01, 2024-11-01
```
- status: 75%
- CC: Alberto, Alberto
### Description
The visualiser tools are two tools that can be used for visualising the message flow of a Waku network. They are adaptable to other network types too (particularly Nomos, Codex).
They rely on either Grafana Loki or VictoriaLogs to store and query logs.
The live visualiser is used for viewing the network in real time.
The debug visualiser is used for viewing a deployment that has already taken place.
### Justification
To make it easy and intuitive to understand the message flow and propagation patterns and properties of a Waku network and apply that same understanding to other networks.
### Deliverables
A peer to peer network mapper that creates a visualisation something like this:
![alt text](image.png)
[![Visualiser Tool](visualiser-tool.png)](visualiser-tool.png)
The tool should be able to visualise the message flow of a Waku network, by lighting up nodes in a graph as they receive messages, flashing a different colour for each message (or message type).
The live visualiser is feature complete, needing only minor tweaks and bug fixes:
https://github.com/vacp2p/dst-live-visualiser
The debug visualiser is still under development, but the core functionality is available already.

BIN
content/vac/dst/tooling/vac/visualiser-tool.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 206 KiB

49
content/vac/dst/wakurtosis/nomos/ci-integration.md
View File

@ -1,49 +0,0 @@
---
title: "CI Integration"
---
## `vac:dst:wakurtosis:nomos:ci-integration`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
CI Integration: done, 2023-07-01, 2023-07-31
```
- status: 100%
- CC: Alberto
### Description
Add Nomos integration to wakurtosis so Nomos can be also used in it.
### Justification
Nomos is under constant developmet.
With this integration, each time a change is done, a continuous integration test is done, making sure the consensus protocol works properly with a few nodes.
### Info
We stopped working on a follow up milestone since we deprecated Wakurtosis in favour of our new 10ktool.
### Deliverables
* first version of Nomos CI integration (https://github.com/vacp2p/wakurtosis/pull/141)

46
content/vac/dst/wakurtosis/vac/maintenance.md
View File

@ -1,46 +0,0 @@
---
title: "Wakurtosis Maintenance"
---
## `vac:dst:wakurtosis:vac:maintenance`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Wakurtosis Maintenance: done, 2023-01-01, 2023-08-31
```
- status: 100%
- CC: Alberto
### Description
Keep up to date the tool if there are crashing changes in the services that are being used in it (Waku, Nomos…)
### Justification
Services being used are in constant change, thus it can lead wakurtosis to break.
### Info
* Wakurtosis is deprecated. We do not actively maintain it anymore.
### Deliverables

45
content/vac/dst/wakurtosis/vac/retrospective-rlog.md
View File

@ -1,45 +0,0 @@
---
title: "Rlog: Wakurtosis Retrospective"
---
## `vac:dst:wakurtosis:waku:retrospective-rlog`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Wakurtosis Retrospective: 2023-08-01, 2023-09-30
```
- status: 50%
- CC: Jordi
### Description
Research log discussing what would we have needed from Wakurtosis to make it work for us beyond our smaller solution.
Why did we decide to drop Kurtosis and work towards a Kubernetes-based solution now.
### Justification
### Info
* [Alberto's Opinion](https://www.notion.so/Alberto-s-Opinion-5f1af38a2e274f42baad0e322629f3a9)
### Deliverables

43
content/vac/dst/wakurtosis/waku/features.md
View File

@ -1,43 +0,0 @@
---
title: "Wakurtosis Features"
---
## `vac:dst:wakurtosis:waku:wakurtosis-features`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Wakurtosis Features: done, 2023-04-01, 2023-07-31
```
- status: 100%
- CC: Alberto
### Description
* Features requested by Waku for the simulations done in wakurtosis (e.g. discv5 support).
### Justification
* Discv5 is an important protocol to test. Also, we should be able to work with offline data once the simulation is finished.
### Deliverables

41
content/vac/dst/wakurtosis/waku/techreport.md
View File

@ -1,41 +0,0 @@
---
title: "Techreport"
---
## `vac:dst:wakurtosis:waku:techreport`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Techreport: done, 2023-06-01, 2023-07-31
```
- status: 100%
- CC: Jordi
### Description
### Justification
### Deliverables
* [techreport](https://docs.google.com/document/d/1U3bzlbk_Z3ZxN9tPAnORfYdPRWyskMuShXbdxCj4xOM/edit?usp=sharing)

45
content/vac/dst/wakurtosis/waku/techreport_02.md
View File

@ -1,45 +0,0 @@
---
title: "Techreport_02"
---
## `vac:dst:wakurtosis:waku:techreport_02`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Techreport_02: done, 2023-08-01, 2023-08-31
```
- status: 100%
- CC: Jordi
### Description
Run extra batches of simulations of the non-Discv5 case with average degree K=13, and K=50.
### Justification
To be able to better compare non-Discv5 and Discv5 Waku behaviours, the Waku team asked us to run new simulation batches with maximum fanout.
Current simulation batches are hard to compare due to the dynamic nature of network generated by the Discv5 protocol.
### Deliverables
* [techreport addendum](https://docs.google.com/document/d/18gU7Pxn7eBBwhtlj7kz4zbRR_Ae7txaUexo3MJQLbIY/edit#heading=h.3h1xpjk9k603)

39
content/vac/index.md
View File

@ -1,39 +0,0 @@
---
title: Vac Roadmap
---
## `vac`
### Structure
`vac:<unit>:<tag>:<for_project>:<title>_<counter>`
- `vac` indicates it is a vac milestone
- `unit` indicates the vac unit `p2p`, `dst`, `tke`, `acz`, `sc`, `zkvm`, `dr`, `rfc`
- `tag` tags a specific area / project / epic within the respective vac unit, e.g. `nimlibp2p`, or `zerokit`
- `for_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)
- `title` the title of the milestone
- `counter` an optional counter; `01` is implicit; marked with a `02` onward indicates extensions of previous milestones
### Vac Unit Roadmaps
#### R&D Service Units
- `p2p:` [[vac/p2p/index|Peer-to-peer]]
- `tke:` [[vac/tke/index|Token Engineering]]
- `dst:` [[vac/dst/index|Distributed Systems Testing]]
- `qa:` [[vac/qa/index|Quality Assurance]]
- `acz:` [[vac/acz/index| Applied Cryptography and Zero-knowledge]]
- `sc:` [[vac/sc/index| Smart Contracts]]
- `nim:` [[vac/nim/index|Nim]]
- `rfc:` [[vac/rfc/index|RFC (Specifications)]]
#### Deep Research
- `dr:` [[vac/dr/index|Deep Research]]
#### Incubator Projects
- `nes:` [[vac/nes/index|Nescience]]
### Weekly Updates
- [weekly updates](tags/vac-updates)

115
content/vac/monthly-reports/2023-aug.md
View File

@ -1,115 +0,0 @@
# Vac Monthly Report - August 2023
## vsu::P2P
### Achievements
- Improved gossipsub DDoS resistance
- Implemented and tested Perf protocol
- Progress on WebRTC integration
- Worked on becoming a Validator in the Nimbus Consensus client
- Addressed issues with IWANT replies in pubsub
### Key PRs and Issues
- [Improve gossipsub DDoS resistance](https://github.com/status-im/nim-libp2p/pull/920)
- [Perf protocol implementation](https://github.com/status-im/nim-libp2p/pull/925)
- [IWANT replies size issue](https://github.com/status-im/nim-libp2p/issues/887)
## vsu::Tokenomics
### Projects
- Codex: Economic analysis, including Filecoin comparison and miner perspectives
- Status: SNT-staking contract development and debugging
- Nomos: Focused on quantifying bribery attacks and assessing delegated staking risks
- Waku: Discussions on RLN and potential solutions
### Key Activities
- Analyzed Filecoin's economic structure and timeline vs competitors
- Debugged and verified Multiplier Points calculation for SNT-staking
- Engaged with project teams to align on economic models and incentives
## vsu::Distributed Systems Testing (DST)
### Achievements
- Completed Wakurtosis Tech Report v2 and started on v2.5
- Developed basic Shadow simulation of gossipsub nodes
- Improved analysis tools for Nomos simulations
- Advanced Waku protocol analysis and topology studies
### Key Deliverables
- [Wakurtosis Research Blog draft](https://github.com/vacp2p/vac.dev/pull/123)
- Nomos simulation analysis CLI supporting 10k nodes
- Waku protocols topology analysis improvements
## vsu::Smart Contracts (SC)
### Projects
- Status: Community contracts (ERC721 and ERC20)
- Ongoing upskilling through Secureum courses
### Key Activities
- Delivered ERC721 community contracts
- Started work on ERC20 community contracts
- Moved community contracts to new foundry-template
- Progressed through Secureum slots, focusing on various smart contract concepts
### Maintenance
- Introduced Vac's own `foundry-template` for smart contract projects
## vsu::Applied Cryptography & ZK (ACZ)
### Projects
- RLN-relay enhancements for Waku
- Zerokit maintenance and v0.4 development
### Key Achievements
- Multiple improvements and fixes for RLN-relay in nwaku
- Released zerokit v0.3.1 and v0.3.2
- Progress on RLN-v2 implementation
- Developed `rln_keystore_generator` tool
### Notable PRs
- [RPC handler for waku rln relay](https://github.com/waku-org/nwaku/pull/1852)
- [Exposed `seq_atomic_operation` FFI API](https://github.com/vacp2p/zerokit/pull/206)
## vip::zkVM
### Research
- Conducted in-depth research on various proof systems including Nova, Sangria, HyperNova, and Plonky2
- Started work on ProtoStar and Nova alternatives
- Drafted Nova Benchmarks document
### Documentation
- Updated the Nova questions document
- Prepared Plonky2 research document
- Started work on a blog post to explain findings and alternatives
## vc::Deep Research
### Validator Privacy (ValPriv)
- Continued development and refinement of Tor-push PoC
- Enhanced the research paper with theoretical analysis and attack scenarios
### GossipSub Scaling
- Conducted literature study on scalability and overlay design in P2P networks
- Executed various gossipsub simulations using shadow simulator
- Started writing a survey report on efficient broadcast in large-scale P2P networks
### Consensus (Nomos/Carnot)
- Progressed on the article about bribery attacks, PoS, and Carnot
- Began work on a Carnot variant that aggregates the majority of votes
- Analyzed Carnot test results, focusing on latency variations
## vc::RFC
- Updated RFC spec for Community History Archive protocol
- Started porting `/spec/6/PAYLOADS` to Vac
## Challenges and Next Steps
1. Continue refining and optimizing the Tor-push method for validator privacy
2. Further development and testing of RLN-relay enhancements for Waku
3. Advance the research and benchmarking of various proof systems for zkVM
4. Progress on scaling solutions for gossipsub and large-scale P2P networks
5. Finalize and publish various research reports and articles in progress
The Vac team has made significant strides across multiple domains in August, with notable progress in P2P networking, cryptography, distributed systems testing, and blockchain research. The team continues to balance cutting-edge research with practical implementations and improvements to existing systems.

8
content/vac/monthly-reports/2023-oct.md
View File

@ -1,8 +0,0 @@
---
title: 2023 October Vac Monthly Report
date: 2023-10-30
lastmod: 2023-11-14
tags:
- monthly-report
draft: true
---

63
content/vac/monthly-reports/2023-sept.md
View File

@ -1,63 +0,0 @@
---
title: 2023 September Vac Monthly Report
draft: true
lastmod: 2023-09-13
---
## Executive Summary
## Key Updates
### Personnel
- Moh will be leaving the Deep Research team at the end of Oct.
- Tanguy left the Peer-to-peer team mid Oct.
- Roman joined the ACZ team at the end of Sept.
### Vac Core
#### RFC Process and Maintenance
#### Deep Research
### Support Services
#### Peer-to-peer
#### Distributed Systems Testing
#### Token Engineering
#### Applied Cryptography and Zero-Knowledge
#### Smart Contract Development
### Incubation Projects
#### Nescience (formerly zkVM)
The zkVM team officially changed its name to Nescience and will run with that as it grows. On Aug 28th, the team released a [detailed article](https://vac.dev/rlog/Nescience-A-zkVM-leveraging-hiding-properties/) describing the overall project and its ambitions. If you haven't read it, you should.
The team performed a Logos Research Call presentation on the Frozen Heart Vulnerability. A summary and associated links to content can be found [in the minutes]()
## Perceived Changes in Project Risk
## Future Plans
### Insight
### Project
## Sources and Useful Links
Weekly Updates
- [[vac/updates/2023-09-18|2023-09-18]]
- [[vac/updates/2023-09-25|2023-09-25]]
- [[vac/updates/2023-10-02|2023-10-02]]
- [[vac/updates/2023-10-09|2023-10-09]]
- [[vac/updates/2023-10-16|2023-10-16]]

27
content/vac/nes/index.md
View File

@ -1,27 +0,0 @@
---
title: Nescience Incubation Project
description: Nescience Zero-knowledge Virtual Machine Environment
tags:
- zkvm
- vac
date: 2023-08-25
lastmod: 2024-06-27
---
### `vac:nes:state-separation`
* [[vac/nes/state-separation/vac/state-separation-architecture-01 | state-separation-architecture-01 ]]
* [[vac/nes/state-separation/vac/state-separation-architecture-02 | state-separation-architecture-02 ]]
### `vac:nes:proofsystems`
* [[vac/nes/proofsystems/vac/research-existing-proofsystems|research-existing-proofsystems ]]
* [[vac/nes/proofsystems/vac/benchmarks|benchmarks]]
### `vac:nes:zkvm`
* [[vac/nes/zkvm/vac/vm-foundations|vm-foundations ]]
* [[vac/nes/zkvm/vac/vm-ecosystem|vm-ecosystem ]]

66
content/vac/nes/proofsystems/vac/benchmarks.md
View File

@ -1,66 +0,0 @@
---
title: "Benchmarks"
---
## `vac:nes:proofsystems:vac:benchmarks`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Benchmarks: 2023-03-01, 2024-05-31
```
- status: 70%
- CC: team
### Description
Since Nescience's main goal is to be innovative in privacy technology (by building a virtual machine that prioritizes privacy,
utilizing mainstream and specialized instruction sets optimized for Zero-Knowledge (ZK) applications),
a key focus is the evaluation of different proof systems especially new ones like the Nova-based proof system against alternatives to identify the best fit for our needs.
This milestone is important for advancing privacy-preserving technologies, setting a benchmark for the fair and effective comparison of ZKP systems.
It's important for both our project's infrastructure and the broader field. The diversity of ZKP system designs necessitates a standardized benchmarking approach to ensure fair comparison,
respecting each system's unique features (which we are aiming to achieve and accomplish)
Comprises:
* research log post
* make benchmark repo public + README (explaining how to execute benchmarks)
* benchmarks (recursive) for all current proof-systems (unless there is a good reason not to include one)
* scientific paper
### Work Breakdown
* By conducting deep investigation of ZKP systems, we aim to demystify the complexities of cryptographic benchmarking and highlight our findings' relevance to privacy technology advancement.
* By rewriting circuits and using same techniques as recursive approach and Poseidon hash functions, we ensure that the comparison focuses on inherent system properties rather than external variables.
This approach will help normalize one of the key variables across systems, allowing for a more direct and fair comparison of their efficiency, scalability, and other critical metrics.
### Deliverables
* Research blog post
* Public benchmark repo on Github (it includes and overall explanation, full circuits implementation and explanation, instructions to execute benchmarks, and testing results on diffferent machines)
* Implementation of recursive circuitsfor all current proof-systems (unless there is a good reason not to include one)
* scientific paper
**Impact:** By selecting the most effective proof system, such as potentially Nova-based ones, based on superior performance,
we aim to strengthen our project's foundation and contribute valuable insights to the privacy field and the scientific community.
This milestone can be useful to any team within the organization to help choose the correct proof system based on their needs
and in general it help the scientific community to get useful insights to progress on different projects within the blockchain field.

54
content/vac/nes/proofsystems/vac/research-existing-proofsystems.md
View File

@ -1,54 +0,0 @@
---
title: "Research Existing Proofsystems"
---
## `vac:nes:proofsystems:vac:research-existing-proofsystems`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
Research Existing Proofsystems: 2023-01-01, 2024-12-31
```
- status: ongoing
- CC: team
### Description
This milestone demonstrates our commitment to a continuous and long-term effort aimed at the comprehensive analysis and study of various proof systems, both established and emerging.
The primary objective is to maintain cutting-edge relevance by staying alongside of the latest developments in proof systems, ensuring our projects are at the forefront of privacy technology.
This is important for sustaining our competitive edge and fostering innovation within our projects.
This milestone is foundational to our strategy, enabling us to swiftly adapt to new technologies and incorporate groundbreaking methods that enhance our privacy objectives.
### Work Breakdown
Our approach involves a systematic review of current and nascent proof systems, identifying those with the potential to advance our research and project goals.
This includes evaluating their applicability, efficiency, and the privacy enhancements they offer.
By doing so, we aim to uncover novel insights and techniques that can be integrated into our work, furthering our mission to deliver robust privacy solutions.
### Deliverables
* Blog posts
* Potential benchmarks
**Impact:** The ongoing research and analysis conducted under this milestone are expected to yield multiple benefits:
identification of promising proof systems that could revolutionize our approach to privacy, generation of innovative ideas for future development,
and ensuring our projects remain relevant and impactful in the rapidly advancing field of blockchain and privacy technologies.
This milestone is valuable both internally and externally. Within our organization, it caters to the diverse needs of various teams that utilize proof systems for distinct purposes.
Similarly, it offers the scientific community access to essential insights across different systems without the need to delve into each one individually.

155
content/vac/nes/state-separation/vac/state-separation-architecture-01.md
View File

@ -1,155 +0,0 @@
---
title: "State Separation Architecture 01"
description: "Designing and refining a sophisticated model of state separation within the Nescience project"
---
## `vac:nes:state-separation:vac:state-separation-architecture-01`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
State Separation Architecture 01: 2024-01-02, 2024-12-31
```
- status: 40%
- CC: Team
### Description
The main goal is to design and refine a sophisticated model of state separation within the Nescience project,
which is aimed at distinctly segregating and managing public and private computational processes, including specialized operations such as shielded and deshielded activities.
This model is focused on improving privacy through the use of Zero-Knowledge Proofs (ZKPs) and overcoming obstacles related to the traceability
and linkability of transactions by employing cutting-edge cryptographic methods and frameworks.
The goal is to create a nuanced architecture that adeptly balances public and private computational needs.
It will utilize an account-based system for public interactions and a UTXO (Unspent Transaction Output)-based method for private transactions,
effectively combining the benefits of public state efficiency and transparency with the strong privacy safeguards of private states.
This effort aims to tackle critical issues in enhancing privacy, engaging deeply with a zero-knowledge virtual machine (zkVM), and achieving significant advances in privacy assurance.
The Nescience project elevates the concept of state separation to a new level, striking an unparalleled balance between privacy and scalability by enabling simultaneous public and private computations.
Unlike existing initiatives, our model not only integrates these two states but also innovates within the private state to support trusted computing,
achieving scalability without sacrificing privacy. We aim to redefine privacy-oriented technologies,
which are often criticized for their sluggish performance, by introducing a fast, intuitive, and developer-friendly approach to state separation.
Furthermore, we envision the public state serving as a vigilant monitoring layer, safeguarding privacy against any potential ZKP vulnerabilities or attacks,
thereby assuring users of their data security.
Our project distinguishes itself by offering a well-defined theoretical representation of state separation,
complete with graphical analyses for a clearer comparison with other privacy-preserving solutions, thus addressing the lack of specificity and clarity in existing models.
Interactions with the virtual machine (VM) are pivotal, involving two critical junctures.
Initially, on the user (client) side, transactions that may contain multiple executions, including private, shielded, or deshielded types, are generated as ZK proofs.
These proofs, representing each execution, are then amalgamated into a single ZK proof for submission to the sequencer (VM).
The sequencer's role is to aggregate transactions from users, verify the proofs, validate nullifiers for conflict detection,
and then compile all verified proofs within an epoch to formulate a block.
This process also entails adjustments to the public state in response to the varied executions (public modifications, shielded, and deshielded executions).
The design criteria for the zkVM include the necessity for high recursion capabilities and sufficient efficiency to ensure usability in terms of memory and computational time on the user side.
This requirement is critical for compatibility with complex tasks like concealing certain information within zkVM operations,
accommodating a significant volume of public and private inputs. The efficiency of verification, even in systems like Groth16 that offer theoretically constant-size verification times,
can be affected as the quantity of inputs grows, underscoring the need for a VM architecture that remains practical and responsive under varying loads.
This nuanced understanding underscores the project's comprehensive approach to leveraging state separation for enhanced privacy and scalability,
all while ensuring compatibility with an advanced zkVM framework.
The most significant impact of our state separation approach in the Nescience project lies in its innovative privacy features,
which employ an account-based model for the public state and a UTXO-based model for the private state, allowing for individual or group-specific private states.
This method stands out by offering four distinct types of executions: public, private, shielded, and deshielded, each with unique characteristics to maintain privacy and scalability.
Public executions are transparent and swift, modifying accounts without the need for Zero-Knowledge Proofs (ZKPs).
In contrast, private, shielded, and deshielded executions, which involve transferring between public and private states or within private states,
utilize ZKPs to protect sensitive information like addresses, transaction amounts, and smart contract invocations through kernel circuits.
These executions are further enriched by allowing transactions to comprise various execution types,
ensuring that sensitive data is processed on the user side with ZKPs to prevent exposure in the public state.
For example, transactions involving private tokens or smart contract interactions remain confidential, with minimal information reflected publicly.
This architecture addresses potential risks like linkability and double-spending through the innovative use of nullifiers and accumulators, enhancing privacy without sacrificing security.
Our approach also introduces Private Directed Acyclic Graphs (PDAGs) as a tool for analyzing and enhancing privacy.
As an extension of Transaction Directed Acyclic Graphs (TDAGs), PDAGs are specifically designed to address and measure two critical aspects of privacy:
unlinkability and untraceability. Unlinkability refers to the property that ensures individual transactions cannot be linked to each other,
making it impossible to trace the flow of assets between transactions from an external observer's perspective.
This feature is crucial for protecting user identities and preventing the exposure of transaction histories.
Untraceability, on the other hand, ensures that it is infeasible to trace transactions back to their source or destination,
providing a further layer of privacy by obscuring the relationship between senders and receivers.
This means that, even if an entity were to observe the network, they would not be able to determine the parties involved in any given transaction.
PDAGs incorporate these principles by structuring transaction records in a way that leverages the benefits of directed acyclic graphs (DAGs),
a type of data structure that allows for efficient data management and retrieval without the limitations of linear or hierarchical arrangements.
In the context of blockchain, DAGs enable faster transactions and greater scalability, while PDAGs extend these benefits with a focus on privacy.
By calculating unlinkability and untraceability metrics within a PDAG framework, it becomes possible to quantitatively assess the privacy level of a blockchain network.
This analytical approach allows for comparisons with other privacy-centric solutions, such as CoinJoin, Tornado Cash, and privacy-focused blockchains like Monero and Zcash.
Through PDAGs, developers can identify potential weaknesses in privacy measures and enhance the network's resistance to analysis and tracking, ensuring a secure and private environment for users.
By incorporating decoy inputs in shielded and deshielded transactions, we further obscure the link between public and private states, significantly reducing the risk of privacy breaches.
In essence, the Nescience project's state separation method not only advances privacy and scalability in blockchain technology
but also sets new standards in protecting user data through a sophisticated blend of theoretical models and practical implementations.
This approach not only addresses current privacy concerns but also lays the groundwork for future investigations into efficient and secure private state exchanges.
To provide a structured approach to the development of the advanced State Separation Architecture for the Nescience project,
focusing on privacy enhancement, we can break down the milestone into distinct sub-milestones, each with its own specific work breakdown and deliverables.
---
### Justification
### Work Breakdown and Deliverables
* * [x] Sub Milestone 1 (Q2 2024): Execution Types and Privacy Mechanism Design
**Work Breakdown:** Define and design the distinct execution types (public, private, shielded, and deshielded) and their respective privacy mechanisms, integrating Zero-Knowledge Proofs (ZKPs) for enhanced privacy.
* * [x] **Deliverables:** Set of comprehensive deliverables, including an Execution Type Design Document that offers an in-depth analysis of the specifications and workflows for public, private, shielded, and deshielded executions in the Nescience state separation architecture -> [Execution Types Document](https://notes.status.im/s/5NsmY46LB).
* * [x] Sub Milestone 2 (Q2 2024): Cryptographic Infrastructure and Nullification Strategy
**Work Breakdown:** Develop the cryptographic infrastructure necessary for the state separation architecture, including nullifiers and accumulators, to prevent double-spending and ensure unlinkability of notes. First step would be identifying and selecting suitable cryptographic primitives for nullifiers and accumulators, then implementing the selected primitives in the architecture.
* * [x] **Deliverables:** A document providing a comprehensive guide on the implementation and integration of nullifiers and accumulators within the state separation model, detailing their specific roles and functions within the overall architecture -> [Nullification Strategy Document](https://notes.status.im/s/iN82QzydC).
* * [x] Sub Milestone 3 (Q3 2024): State Separation Document
**Intro:** In this milestone, the first part (https://vac.dev/rlog/Nescience-A-zkVM-leveraging-hiding-properties) focuses on conducting detailed exploration of the multifaceted challenges,
potential solutions, and alternatives that lay ahead building Nescience, a privacy-first blockchain project aiming to enable private transactions and provide a general-purpose execution environment
for classical applications. The second part aims to delve deeper into the selected strategic paths for developing a privacy-first blockchain, detailing the methodologies for addressing the identified challenges,
the decisions made to enhance privacy, and the expected outcomes.
**Work Breakdown:** Document all the research findings, the development steps and the methodologies, explaining the utility and adoption process of each solution to reinforce privacy within the project and the shift in focus towards detailing the chosen paths for the project development, including the rationale behind these decisions and their alignment with privacy enhancements. Finally, Review future directions, potential areas of research, and ongoing development efforts to continue advancing privacy within the Nescience project
** [x] Deliverables:** Blog posts and/or scientific papers -> [Nescience: A User-Centric State-Separation Architecture](https://vac.dev/rlog/Nescience-state-separation-architecture)
**Impact:** By clearly articulating the exploration from identifying challenges to implementing solutions,
Part Two of the State Separation Document aims to serve as a comprehensive guide and reference for enhancing privacy in blockchain technologies,
marking a significant milestone in the Nescience project's development.
* * [ ] Sub Milestone 4 (Q3 2024): Enhancing Transaction Privacy with Decoy Inputs
**Work Breakdown:** Incorporate empty notes as decoy inputs for shielded and deshielded executions to enhance the untraceability and unlinkability of transactions. First we aim to design the mechanism for integrating decoy inputs into transactions to act as noise; then we develop a prototype that demonstrates the effectiveness of decoy inputs in enhancing transaction privacy.
**Deliverables:** A prototype showcasing the implementation of decoy inputs, accompanied by evaluation results highlighting their impact on privacy enhancement.
* * [ ] Sub Milestone 5 (Q4 2024): Nescience devnet deployment
**Work Breakdown:** Deploy a Nescience Devnet by integrating simplified components into the zkVM and state separation architecture to achieve a fully functional Nescience environment. Add the necessary simplified components to the zkVM and state separation architecture such as P2P communication layer, Consensus layer, and Network layer. Focus on node deployment (Configure and start Nescience nodes on designated machines and ensure nodes operate independently, with a full structure that includes the consensus layer, network layer, etc.). Ideally, the Nescience Devnet should function autonomously, without reliance on external blockchain environments whereas existing components can be utilized ensuring that the system should be able to run on its own.
**Deliverables:** A fully operational Nescience Devnet, capable of running nodes independently with integrated P2P communication, consensus, and network layers, all within the zkVM and state separation framework.
### Risks
We currently have 2 open positions for hiring a 1) Zero Knowledge Research Engineer and a 2) Zero Knowledge Researcher.
Currently we are finding some difficulties in finding the best candidates for these positions and therefore we need to consume Vac resources (namely Ugur and Marvin) for a longer time to focus on Nescience projects.

97
content/vac/nes/state-separation/vac/state-separation-architecture-02.md
View File

@ -1,97 +0,0 @@
---
title: "State Separation Architecture 02"
description: "Designing and refining a sophisticated model of state separation within the Nescience project"
---
## `vac:nes:state-separation:vac:state-separation-architecture-02`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
State Separation Architecture 02: 2025-01-02, 2025-12-31
```
- status: 0%
- CC: Team
### Description
contiunation of `vac:nes:state-separation:vac:state-separation-architecture-02`
### Justification
### Work Breakdown and Deliverables
* Sub Milestone 1 (2025): TDAG & PDAG Integration for Privacy Enhancement
**Work Breakdown:** Use Transaction Directed Acyclic Graphs (TDAGS) and Private Directed Acyclic Graphs (PDAGs) for a comparative analysis of the Nescience architecture's privacy features. The main idea is to implement PDAGs to improve unlinkability and untraceability within the project, enhancing privacy features. This can be done by developing and integrating PDAG structure, oncluding data structures, algorithms and the integration mechanism with the existing system; by conducting thorough testing of the PDAG implementation to identify issues or areas of improvements; and by monitoring its performance and impact on privacy enhancement.
**Deliverables:**
* Report on PDAG reearch and analysis.
* PDAG integration technical specifications and design documents.
* A functioning PDAG implementation with testing reports.
* Documentation on PDAG privacy improvements and security analysis.
* Sub Milestone 2 (2025): Kernel-based Architecture Implementation
**Work Breakdown:** Develop a kernel-based framework for verifying private function executions accurately, using a recursive SNARKs approach to build and validate a call stack. This is to ensure robust proof of execution sacrificing computational resources (raising gas fees due to the intensive nature of generating SNARK proofs and handling recursive computations). We will focus on balancing the precision of recursive verification with its computational costs, aiming for a system that guarantees the integrity of private functions while managing resource use efficiently.
**Deliverables:**
* A data structure to manage recursive function calls, ensuring efficiency and security.
* A system to securely accumulate and manage proof data for recursive calls, facilitating tamper-resistant proof handling.
* Generation of intermediary SNARK proofs for each recursive call, with aggregation capabilities for comprehensive stack validation.
* Establishment of a maximum recursion depth with enforcement mechanisms to prevent computational overflow.
* A fully integrated recursive verification system with extensive testing to ensure functionality, security, and performance under varied conditions.
* Sub Milestone 3 (2025): Seamless Interaction Design
**Work Breakdown:** Address the challenge of potential information leakage between private and public transactions by ensuring composability between contracts and secure integration of functions. Moreover, we would like to be able to create secure channels for contract composability and interaction layers that prevent private data exposure by implementing strategic safeguards against information leakage.
**Deliverables:**
* Intermediary smart contracts for secure public-private interactions.
* Confidential sidechains and cross-chain protocols employement.
* Fragmentation of data across shards for private interaction.
* Sub Milestone 4 (2025 / 2026): zkVM deployment
**Work Breakdown:** Our aim is to deploy our work in progress state separation architecture within a privacy-first zero knowledge virtual machine since it places an emphasis on privacy enhancements (which we need for our privacy-first zkVM).
**Deliverables:** A functioning privacy-first zkVM that ensures that while private state data remains undisclosed, public state transitions can still be carried out and subsequently verified by third parties.
* Sub Milestone 5 (2025 / 2026): State Separation Doc
**Description**: This open milestone is crucial for ensuring that our development aligns with the evolving needs and expectations of users and organization.
We aim not only to address the immediate challenges of developing a privacy-first blockchain but also to lay the groundwork for future innovations in blockchain privacy and security.
Note: This is an ongoing and long term milestone with possible deliveries within the year 2024. The timing and nature of these deliveries are contingent upon our continuous findings
and their subsequent impact on privacy for both the organization and the community.
**Work Breakdown:**
* Document all the research findings, the development steps and the methodologies.
* Explain the utility and adoption process of each solution to reinforce privacy within the project
* Explain the shift in focus towards detailing the chosen paths for the project development, including the rationale behind these decisions and their alignment with privacy enhancements.
* Review future directions, potential areas of research, and ongoing development efforts to continue advancing privacy within the Nescience project
**Deliverables**
* Blog posts.
* Scientific papers.

54
content/vac/nes/zkvm/vac/vm-ecosystem.md
View File

@ -1,54 +0,0 @@
---
title: "VM Ecosystem"
---
## `vac:nes:zkvm:vac:vm-ecosystem`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
VM ecosystem: 2025-01-01, 2025-12-31
```
- status: 0%
- CC: team
### Description
### Work Breakdown & Deliverables
* Sub Milestone 1 (2025): Deployment and Real-World Application Testing
**Work Breakdown:** Deploy the privacy-centric zkVM in a controlled environment and test its real-world applicability and performance, focusing on privacy-preserving computations.
**Deliverables:** An outline for deploying the zkVM in a test env, including infrastructure and security considerations, along with results of testings focusing on ptivacy preservation.
* Sub Milestone 2 (2025): Community Engagement and Open-Source Contributions
**Work Breakdown:** Engage with the cryptographic and privacy communities and teams within the organization to gather feedback, share insights, and contribute to the open-source ecosystem, fostering wider adoption and collaboration.
**Deliverables:** Release of the developed cryptographic libraries and zkVM source code to the open-source community, accompanied by comprehensive documentation and guides for implementation and use.
**Impact:** This plan underscores the goal for delivering a zkVM with strong focus on privacy enhancements. By identifying and integrating advanced cryptographic primitives, and considering the deployement within environments like Nexus VM or similar VMs, this milestone aims to make significant contributions to the field of privacy-preserving computation. Sub milestones may slightly change and some of them might be accomplished faster than others especially that during the previous period, we have focused on existing zkVMs and extensively studied the integration of cryptographic primitives to enhance pivacy.

66
content/vac/nes/zkvm/vac/vm-foundations.md
View File

@ -1,66 +0,0 @@
---
title: "VM Foundations"
---
## `vac:nes:zkvm:vac:vm-foundations`
---
```mermaid
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#BB2528',
'primaryTextColor': '#fff',
'primaryBorderColor': '#7C0000',
'lineColor': '#F8B229',
'secondaryColor': '#006100',
'tertiaryColor': '#fff'
}
}
}%%
gantt
tickInterval 1month
dateFormat YYYY-MM-DD
section Status
VM Foundations: 2024-03-01, 2024-12-31
```
- status: 40%
- CC: team
### Description
The focus of this milestone is on the significant adaptation of a Zero-Knowledge Virtual Machine (zkVM) that places an emphasis on privacy enhancements. By modifying existing zkVM frameworks, the goal is to integrate advanced cryptographic primitives to create a highly secure, privacy-preserving computational environment. This includes exploring and implementing cutting-edge research in cryptographic techniques and ensuring these can be efficiently executed within our zkVM framework, with an example pathway through Nexus VM for specific Rust-based cryptographic implementations. The analysis includes RISC Zero, GKR-based VMs, and Layer 2 zkVMs, with a focus on their instruction set architectures, privacy capabilities, proof complexities, and specific innovations or limitations. This milestone will be divided in several sub-milestones in order to understand which paths to take and which path would better fit in order to get tangible output (see Work Breakdown and Deliverables)
---
### Work Breakdown & Deliverables
* * [x] Sub Milestone 1: Privacy Cryptography Research and Selection
**Work Breakdown:** Conduct exhaustive research into cryptographic primitives that enhance privacy, determining which are most applicable and promising for integration into a zkVM.
**Deliverables:**
* * [x] A comprehensive review of current cryptographic techniques that enhance privacy, including signature schemes and MPC schemes, focusing on those with potential for zkVM integration -> [1. List of zkVMs](https://notes.status.im/s/_4MmpSCc9) and [2. In-depth Review](https://github.com/vacp2p/zk-explorations/issues/40).
* * [x] Analysis of selected cryptographic primitives for implementation in Rust, considering their compatibility with the zkVM environment, specifically within frameworks like Nexus VM -> [List of Primitives and Privacy Requirements](https://notes.status.im/s/AFBtW3Prj).
* * [x] A blogpost reflecting the research that have been conducted. -> [Exploring zkVMs: Which Projects Truly Qualify as Zero-Knowledge Virtual Machines?](https://vac.dev/rlog/zkVM-explorations)
* * [ ] Sub Milestone 2: Cryptographic Implementation and Testing (Related to Sub Milestone 1)
**Work Breakdown:** Implement the selected cryptographic primitives in Rust (From Sub Milestone 1), ensuring they are optimized for privacy enhancement within the zkVM framework.
**Deliverables:** Repo documenting the testing processes, performance evaluations, and optimizations applied to the cryptographic implementations to ensure privacy efficiency and scalability within the zkVM.
* * [ ] Sub Milestone 3: zkVM Adaptation for Privacy
**Work Breakdown:** Adapt an existing zkVM to integrate the implemented cryptographic primitives, prioritizing privacy preservation. For instance we can think about replacing Merkle trees with Verkle trees within existing VMs, or adding proof compression layer to replace logarithmic proof sizes with constant sized proofs. The possible prototype could potentially incorporate selected features and optimizations from the previous phases. This involves implementing privacy-preserving properties, selecting appropriate instruction sets, and integrating advancements such as Nova-based proof systems.
**Deliverables:**
* Potential Privacy-Centric zkVM Prototype: A zkVM that integrates the Rust-based cryptographic libraries, showcasing enhanced privacy capabilities.
* Detailed documentation on performance metrics and comparative analysis with existing systems.
**Impact:** This plan underscores the goal for delivering a zkVM with strong focus on privacy enhancements. By identifying and integrating advanced cryptographic primitives, and considering the deployement within environments like Nexus VM or similar VMs, this milestone aims to make significant contributions to the field of privacy-preserving computation. Sub milestones may slightly change and some of them might be accomplished faster than others especially that during the previous period, we have focused on existing zkVMs and extensively studied the integration of cryptographic primitives to enhance pivacy.

0
content/vac/nim/core-libs/vac/chronos-maintainance.md
View File

22
content/vac/nim/index.md
View File

@ -1,22 +0,0 @@
---
title: Nim Unit
tags:
- nim
- vac
date: 2024-06-01
lastmod: 2024-06-18
---
## `vac:nim:`
---
### `tooling:vac:`
* [ ] [[vac/nim/tooling/vac/nim-suggest|nim-suggest]]
* [ ] [[vac/nim/tooling/vac/nimble|nimble]]
* [ ] [[vac/nim/tooling/vac/compiler|compiler]]
* [ ] [[vac/nim/tooling/vac/editor|editor]]
* [ ] [[vac/nim/tooling/vac/lsp|lsp]]
### `core-libs:vac:`
* [ ] [[vac/nim/core-libs/vac/chronos-maintainance|chronos-maintainance]]

0
content/vac/nim/tooling/vac/compiler.md
View File

0
content/vac/nim/tooling/vac/editor.md
View File

0
content/vac/nim/tooling/vac/lsp.md
View File

0
content/vac/nim/tooling/vac/nim-suggest.md
View File

0
content/vac/nim/tooling/vac/nimble.md
View File

27
content/vac/p2p/index.md
View File

@ -1,27 +0,0 @@
---
title: P2P Service Unit
tags:
- p2p
- vac
date: 2023-08-25
lastmod: 2023-09-05
---
## `vac:p2p:`
---
### `nimlibp2p:vac:`
The P2P Service unit develops `nim-libp2p`.
nim-libp2p roadmap on github: https://github.com/status-im/nim-libp2p/issues/777
* [x] [[vac/p2p/nimlibp2p/vac/gossipsub-improvements-eip-4844|gossipsub-improvements-eip-4844]]
* [[vac/p2p/nimlibp2p/vac/webrtc-transport|webrtc-transport]]
* [[vac/p2p/nimlibp2p/vac/gossipsub-ddos-mitigation|gossipsub-ddos-mitigation]]
* [[vac/p2p/nimlibp2p/vac/gossipsub-stagger-send|gossipsub-stagger-send]]
* [[vac/p2p/nimlibp2p/vac/maintenance|maintenance]]
### `nimchronos:vac:`
* [[vac/p2p/nimchronos/vac/maintenance|maintenance]]

Some files were not shown because too many files have changed in this diff Show More