mirror of
https://github.com/vacp2p/vac.dev.git
synced 2026-01-09 14:47:59 -05:00
217 lines
13 KiB
Markdown
217 lines
13 KiB
Markdown
---
|
||
title: 'Vac 2024 Year in Review'
|
||
date: 2025-01-09 18:30:00
|
||
authors: Vac
|
||
published: true
|
||
slug: 2024-recap
|
||
categories: research
|
||
|
||
|
||
toc_min_heading_level: 2
|
||
toc_max_heading_level: 5
|
||
---
|
||
|
||
In this post, we recap Vac's achievements in 2024 and look forward to 2025.
|
||
|
||
{/* truncate */}
|
||
|
||
With 2024 now behind us and a new year ahead,
|
||
Vac is proud to reflect on the milestones and breakthroughs that defined another year of researching and developing free and open digital public goods for the [Institute of Free Technology](https://free.technology/) and wider web3 ecosystem.
|
||
|
||
Vac comprises various subteams and service units, each with its own focus.
|
||
Below, we celebrate each unit's achievements and look forward to its 2025 plans.
|
||
|
||
## Nescience
|
||
Nescience is our state separation architecture that aims to enable private transactions and provide a general-purpose execution environment for classical applications.
|
||
|
||
### Highlights
|
||
This year, the Nescience state separation architecture moved from exploration to real progress,
|
||
taking significant steps towards building a functional and reliable system.
|
||
The team focused on turning ideas into something real,
|
||
testing the proposed architecture,
|
||
and understanding its strengths and weaknesses.
|
||
|
||
* ZkVM exploration and benchmarks
|
||
* Published [deep reviews of 23 existing zkVMs](https://vac.dev/rlog/zkVM-explorations/)
|
||
* [Benchmarked the performance of the six zkVMs](https://vac.dev/rlog/zkVM-testing/) that best fit Nescience
|
||
* Defined the NSSA architecture
|
||
* Brought clarity to NSSA’s design and explained the system’s architecture [in a lengthy exploratory blog post](https://vac.dev/rlog/Nescience-state-separation-architecture/)
|
||
* Built the sandboxed testnet
|
||
* Designed the first version of the node specification
|
||
* All core components (execution types, UTXOs, cryptographic primitives) implemented and being tested
|
||
* Testing the performance of all execution types in various scenarios
|
||
|
||
We also made progress on the essential parts of NSSA’s system, including:
|
||
|
||
* Key protocol for secure key management
|
||
* Execution types and circuits for reliable computation
|
||
* UTXO specification to manage state transitions effectively
|
||
* Cryptography module to ensure privacy and security
|
||
|
||
### Looking forward
|
||
In 2025, the Nescience team plans to double down on what works, fix what doesn’t, and push NSSA closer to real-world use.
|
||
|
||
* Sandboxed testnet data analysis – the sandboxed testnet will be our primary data source that we will analyse to identify issues, limitations, and areas for improvement.
|
||
* Expanding the node – expand sandboxed components into a full node implementation with rigorous testing and iterative optimization (to bridge the gap between proof of concept and production readiness).
|
||
* Finalizing the architecture and RFC – after completing NSSA’s architecture, we will draft an RFC to ensure transparency and enable greater collaboration with the broader ecosystem.
|
||
* Testing real-life scenarios – applying NSSA to diverse, practical use cases to assess its adaptability, performance, and impact.
|
||
* Ongoing optimization – ensure NSSA is robust, efficient, and ready to scale.
|
||
|
||
## Token Economics (TKE)
|
||
The TKE Service Unit works closely with IFT portfolio projects to design and implement crypto-economic incentive structures.
|
||
|
||
### Highlights
|
||
* Formalized and implemented [Codex](https://codex.storage/) economic incentives in the Litepaper and simulations
|
||
* Orchestrated Status Network incentive structure and smart contract implementation
|
||
* Started building [Nomos’s](https://nomos.tech/) economic model
|
||
* Consulted and provided analysis of incentives for the Logos Operators ordinals project
|
||
* Drove discussions on the economic sustainability of [Waku](https://waku.org/);
|
||
helped define RLN membership and its payment mechanism
|
||
|
||
### Looking forward
|
||
In 2025, TKE will continue to support IFT portfolio projects,
|
||
working toward economic sustainability while strengthening relationships within the organization.
|
||
Additionally, the service unit aims to continue building its external reputation through partnerships and publications of relevant work on the [Vac forum](https://forum.vac.dev/).
|
||
|
||
## Quality Assurance (QA)
|
||
The QA Service Unit focuses on the development and execution of comprehensive test plans,
|
||
including implementing unit and interoperability testing.
|
||
|
||
### Highlights
|
||
* Matured Waku interoperability testing framework with coverage for all major protocols and features
|
||
* Began collaboration with Nomos, contributing to unit and integration testing
|
||
* Partnered with the [Status](https://status.app/) team to test message reliability under unstable network conditions
|
||
|
||
### Looking forward
|
||
* Extend collaboration with the Waku team on go-waku bindings and message reliability testing
|
||
* Cement working relationship with the Nomos team through the building of an E2E testing framework for higher-level node validation
|
||
* Work closely with Status’s QA team to enhance the functional testing framework
|
||
* Continue work on nim-libp2p testing
|
||
* Expand collaboration to additional projects
|
||
|
||
## RFC
|
||
The RFC Service Unit takes on the responsibility of shepherding and editing specifications for IFT projects.
|
||
The unit acts as a linchpin for ensuring standardized and interoperable protocols within the IFT ecosystem.
|
||
|
||
### Highlights
|
||
* Working to implement RFC culture across the IFT ecosystem
|
||
* Began editorial work for several IFT portfolio projects: Status, Nomos, Waku, and Codex.
|
||
* Reworked our standards with regard to writing RFCs to a consensus-oriented specification system
|
||
|
||
### Looking forward
|
||
* Continue to implement RFC culture across the IFT ecosystem
|
||
* Broaden the number of RFCs produced
|
||
– particularly for IFT portfolio projects nearing public releases
|
||
* Include new projects with the [rfc-index](https://rfc.vac.dev/)
|
||
* Encourage external projects requiring RFCs to establish relationships with the service unit
|
||
|
||
## Applied Cryptography and ZK (ACZ)
|
||
The ACZ Service Unit focuses on cryptographic solutions and zero-knowledge proofs,
|
||
enhancing the security, privacy, and trustworthiness of IFT portfolio projects
|
||
and contributing to the overall integrity and resilience of the decentralized web ecosystem.
|
||
|
||
### Highlights
|
||
* Researched a libp2p mix protocol and first proof-of-concept implementation (including ping and GossipSub over mix)
|
||
* Researched a decentralized version of MLS (message layer security) with a first proof of concept
|
||
* Released Zerokit [v0.6.0](https://github.com/vacp2p/zerokit/releases/tag/v0.6.0)
|
||
and [v0.5.0](https://github.com/vacp2p/zerokit/releases/tag/v0.5.0)
|
||
* Added [gnark RLN implementation](https://github.com/vacp2p/gnark-rln)
|
||
* Released Stealth Address Kit [v0.3.1](https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.3.1),
|
||
[v0.2.0](https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.2.0),
|
||
and [v0.1.0](https://github.com/vacp2p/stealth-address-kit/releases/tag/v0.1.0)
|
||
* Published:
|
||
* [Verifying RLN Proofs in Light Clients with Subtrees](https://vac.dev/rlog/rln-light-verifiers/)
|
||
* [RLN-v3: Towards a Flexible and Cost-Efficient Implementation](https://vac.dev/rlog/rln-v3/)
|
||
|
||
### Looking forward
|
||
* Ensure libp2p mix protocol is production-ready
|
||
and support with the publishing of a paper and blog posts
|
||
* Ensure decentralized MLS is production-ready
|
||
and support with the publishing of a paper and blog posts
|
||
* Begin explorations of additional research topics
|
||
* Release [Zerokit v0.7](https://github.com/vacp2p/zerokit/issues/271) and future versions
|
||
|
||
## P2P
|
||
The P2P Service Unit specializes in peer-to-peer technologies
|
||
and develops nim-libp2p, improves the libp2p GossipSub protocol, and assists IFT portfolio projects with the integration of P2P network layers.
|
||
|
||
### Highlights
|
||
* Analysis and work on libp2p GossipSub improvements
|
||
* Published:
|
||
* [Libp2p GossipSub IDONTWANT Message Performance Impact](https://vac.dev/rlog/gsub-idontwant-perf-eval/)
|
||
* PR to libp2p specifications about specific lib2p GossipSub improvements we researched and tested https://github.com/libp2p/specs/pull/654
|
||
|
||
### Looking forward
|
||
* Add new features to nim-libp2p:
|
||
QUIC transport, web transport
|
||
* Update specifications for libp2p GossipSub,
|
||
aiming to significantly improve its performance
|
||
|
||
## Distributed Systems Testing (DST)
|
||
The DST Service Unit’s primary objective is to assist IFT portfolio projects in understanding the scaling behavior of their nodes within larger networks.
|
||
By conducting thorough regression testing, the DST unit helps ensure the reliability and stability of projects.
|
||
|
||
### Highlights
|
||
* DST compute resources transitioned from a hosted environment to a dedicated Vac Lab,
|
||
enabling better customization of resources and adding significantly more compute power
|
||
– enabled much higher and more stable simulations (several hundred nodes to several thousand) and enhanced environmental control.
|
||
* Maintained monthly regression simulations for both Waku and Nim-libp2p,
|
||
helping us to detect several issues and ensure that future versions do not introduce new ones.
|
||
* Successfully simulated and obtained results for all Waku protocols, relaying feedback to the team.
|
||
|
||
### Looking forward
|
||
* More testing and simulations for Codex and Nomos
|
||
* Develop useful tools for all IFT portfolio projects – e.g. a Log Parser tool and data dashboard
|
||
|
||
## Nim
|
||
Several IFT portfolio projects use the Nim ecosystem for its efficiency.
|
||
The Nim Service Unit is responsible for the development and maintenance of Nim tooling.
|
||
|
||
### Highlights
|
||
* Released Nim-libp2p ([v1.7.1](https://github.com/vacp2p/nim-libp2p/releases/tag/v1.7.1),
|
||
[v1.7.0](https://github.com/vacp2p/nim-libp2p/releases/tag/v1.7.0),
|
||
[v1.6.0](https://github.com/vacp2p/nim-libp2p/releases/tag/v1.6.0),
|
||
[v1.5.0](https://github.com/vacp2p/nim-libp2p/releases/tag/v1.5.0),
|
||
[v1.4.0](https://github.com/vacp2p/nim-libp2p/releases/tag/v1.4.0),
|
||
[v1.3.0](https://github.com/vacp2p/nim-libp2p/releases/tag/v1.3.0),
|
||
[v1.2.0](https://github.com/vacp2p/nim-libp2p/releases/tag/v1.2.0))
|
||
* Introduced SAT solver to the Nimble package manager that significantly improves dependency resolution
|
||
* Nim VSCode Extension
|
||
* Stabilized Nim Language Server
|
||
|
||
## Smart Contracts (SC)
|
||
Vac's Smart Contracts Service Unit ensures the smart contracts deployed across the various IFT portfolio projects are secure, robust, and aligned with project requirements.
|
||
|
||
### Highlights
|
||
* Deployed the SNT staking protocol testnet following Status's [governance vote](https://our.status.im/snt-vote-results/) to develop SNT staking and Status Network
|
||
* Wrote specifications for [Codex's architectural components](https://github.com/codex-storage/codex-contracts-eth/tree/master/certora/specs) and [Status's staking contracts](https://github.com/vacp2p/staking-reward-streamer/tree/main/certora/specs)
|
||
* Delivered several learn-up sessions on a variety of topics for IFT contributors, including:
|
||
* Stealth addresses
|
||
* Tokenized vaults
|
||
* Rental NFTs
|
||
* Merkle trees
|
||
* Account abstraction
|
||
* EVM deep dive
|
||
|
||
### Looking forward
|
||
* Deploy the SNT staking protocol on the Status Network testnet
|
||
* Encourage community security audits via contests
|
||
* Provide smart contract consultation services for IFT portfolio products
|
||
* Engage in more learn-up sessions to promote org-wide knowledge sharing.
|
||
|
||
## Heading into 2025
|
||
This year has seen Vac involved with many research, development, and testing undertakings in support of IFT portfolio projects.
|
||
The digital public goods that emerge from our efforts not only support the organization itself but are open and free to use by any project that would benefit.
|
||
|
||
As we move into 2025, we aim to nurture a stronger RFC culture across the IFT to encourage greater collaboration and knowledge sharing among portfolio projects.
|
||
Our goal is to serve as an internal conduit of expertise within the organization, supported by a strong RFC culture, maintaining a repository of internal knowledge creation, and identifying and facilitating IFT project synergies.
|
||
Such an approach should lead to greater efficiencies across the organization.
|
||
|
||
We also aim to establish a diverse research community around Vac, and our efforts in this regard are already underway.
|
||
In the final quarter of 2024, Vac stepped up its collaboration with the libp2p community and made a concerted effort to engage the community on the [Vac forum](https://forum.vac.dev/).
|
||
In 2025, we aim to continue working closely with those communities to which we already have ties, such as the libp2p, Ethereum, and Nim ecosystems.
|
||
|
||
We look forward to continuing our journey with you\!
|
||
|
||
*Follow [Vac on X](https://x.com/vacp2p), join us in the [Vac Discord](https://discord.gg/FPSXQ9afJE), or take part in the discussions on the [Vac forum](https://forum.vac.dev/) to stay up to date with our research and development progress.*
|